[Openswan dev] [PATCH] Openswan 2.2.0/2.3.0dr4 NAT-T source port other than 500/4500

[ilia.sotnikov at asstra.by]

Patch summary:
1. Accept source port other than 500/4500 (any source port) on responder 
when 
  NAT-T is enabled and confirmed by peers;
2. Accept new Main Mode also on port 500 when connection was updated 
   to use port 4500 by NAT-T;
3. Reset port to 500 on a connection after its manual termination 
   (--down, for example).

Description:

During NAT-T testing in Openswan 2.2.0/2.3.0/dr4 we faced that NAT-T in 
some cases
behaves different rather than described in draft-ietf-ipsec-nat-t-ike.

Case 1. NAT box between peers could also do port translation. It's obvious 
and could 
happen in real world. In this case, Main mode will reach responder with 
source port other 
than 500/4500.

draft-ietf-ipsec-nat-t-ike states that "... The NAT may change the IKE UDP 
source port, 
and recipients MUST be able to process IKE packets whose source port is 
different than 500. ..."

Pluto behaves different: it logs "initial Main Mode message received on 
<host>:<port> but no 
connection has been authorized" and stops handling Main mode from that 
peer. The reason of 
this is when NAT-T is activated the function find_host_pair_connections () 
tries to find a connection 
with exact source:source_port and destination:destination_port match. In 
this situation the match 
fails with the above result.

Case 2. When both peers confirm that one of them (or both) is NATed and 
port floating is enabled 
they update their correponding connections to have ports to be 4500 (or 
other if port translation 
occured) as described in draft. Then, if initiator, for example, reboots 
or the connection is replaced, 
it can't complete its initiation because responder waits for connection on 
port 4500, not on 500.

This situation also mentioned in draft-ietf-ipsec-nat-t-ike as "... Once 
port change has occurred, if 
a packet is received on port 500, that packet is old. If the packet is an 
informational packet, it MAY 
be processed if local policy allows. If the packet is a Main Mode or 
Aggressive Mode packet (with 
same cookies than previous packets), it SHOULD be discarded. If the packet 
is new Main Mode or 
Aggressive exchange then it is processed normally (the other end might 
have rebooted, and this is 
starting new exchange). ...".

In this case the reason is that patch sumbitted by Andreas Steffen tries 
to find such connection only 
when a packet is received on port 4500 (when md->iface->ike_float is set) 
and fails because of 
destination port 500.

Case 3. When both peers confirmed NAT and switched to port 4500 and then 
you manual down the 
connection on one of them, port information is preserved. It is optimal 
because both peers know that 
NAT will happen and there is no need to exchange over port 500. 
Considering above mentioned 2nd 
case, this will prevent connection to be finished successfully when 
responder, for example, rebooted 
or Openswan restarted.

Comments:
1. Wildcarding source port (allowd to any) could be seen as security 
issue, but shouldn't be becuse
even in case of connection from another peers it will not succed because 
of autnentication failure.
2. Detecting that peer support NAT-T by checking md->quirks.nat_traversal_vid is incomplete.
Better solution is to check it with nat_traversal_vid_to_method () 
function but double call will not be
optimal.

Am I missed something?

Feel free to modify it or drop it completely.

P.S. Please, CC me because I'm not on the list.
P.P.S. Please forgive me my English, I'm not a native speaker.

Ilia Sotnikov <ilia.sotnikov at asstra.by>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: openswan-2.2.0-nat_t_sport.diff
Type: application/octet-stream
Size: 4273 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/dev/attachments/20041216/b1383348/openswan-2.2.0-nat_t_sport.obj