[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-ipsec-ikev2-05.txt comments



Francis Dupont writes:
>    The NAT-T protocol does not work with current NAT boxes if you try to
>    run it over port 500. We must change the port from the 500 to 4500
>    immediately when we detect NAT.
> => I am not convinced by this "immediately" and this has an impact on
> legacy authentication or other stuff which add messages to the IKE_AUTH
> "exchange".

I think the easiest place to switch to port 4500 is after hte
IKE_SA_INIT packets, i.e when sending the first IKE_AUTH packets. 

> With implicit peer address update, the NAT detection can be done in IKE_AUTH
> and the switch to UDP 4500 performed only after IKE_AUTH.

There are going to be implementations, that are not supporting the
implicit peer address updates, and for them the state machine goes
much easier if they can store the used address and port from the
IKE_AUTH packet, than to wait for the next UDP enacpsulated packet
after IKE_AUTH.

Also note, that if we switch port after IKE_AUTH, then the responder
CANNOT initiate any exchanges before the responder either initiates
another IKE exchange on new port or sends UDP encapsulated ESP packet.
This would cause wierd problems in such cases. It cannot use the port
500, as there is no keepalives for that port, thus the NAT mapping
goes away quite quickly. 

> There are many advantages to keep same addresses and ports in all
> messages of the initial phase.

For the responder side it does not matter, it will reply back to the
same address where the packet came in. Also when the IKE_AUTH is
finished it can store the last address and port used, and associate
them to the IKE SA so, when it needs remote peer address it can use
them directly.

For the initiator it is also quite easy, simply switch the source and
destination port to 4500 when it detects NAT, and use them from that
on. 

> => so you should agree that the asymmetry of the current draft is bad,
> i.e., the responder cannot be behind the NAT box.

The responder can be behind NAT, but in such case the initiator needs
to find the external address of the NAT box to start the exchange in
first place. Also the NAT must normally be kind of static NAT.

>         Keepalives cannot be used for this purposes as they are not
> => there are many types of keepalives. You should be more accurate,
> for instance "UDP keepalives cannot ...".

I am talking about the keepalives defined in the UDP encapsulation
draft. 

>         authenticated, but any IKE authenticated IKE packet or UDP
> => IKE messages are authenticated if they run over the IKE SA
>         encapsulated ESP packet can be used to detect that the IP address
> => s/ESP/IPsec/

The current NAT traversal does NOT support AH, thus only UDP
encapsulation of ESP packets is defined. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/