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

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   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. 
   
=> perhaps it is too easy:
 - it is less secure than at the end of IKE_AUTH
 - it doesn't work if the responder is behind a NAT
 - it doesn't work if the responder doesn't implement NAT-T
   (i.e., if it is not ready to receive packets on UDP 4500)
 - the detection is made only by the initiator
etc.

   > 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,

=> I recognize I assume peer address updates are a mandatory part of NAT-T.

   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. 
   
=> in my proposal, the node behind the NAT (usually the initiator but
this is not necessary) must send a packet as soon as SAs are up.
If IKE is trigger by some traffic, this traffic will do the job...
In another cases, IMHO the best is to send an IKE keepalive.

   > 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

=> it does matter if it wants to protect itself against attacks using
a spoofed source peer address.

   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.

=> the last statement is exactly the implicit peer address update
mechanism viewed by IKE, i.e., for the IKE SA.
   
   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. 
   
=> and what happens if the responder is behind the NAT? You assume
the mapping is the same of ports 500 and 4500.

   > => 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.
   
=> this is less general, i.e., we should find real world cases where
it doesn't work.

   >         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. 
   
=> I know but I can't say the same thing for a random reader.

   >         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. 

=> and IPCOMP? There is no reason to restrict to ESP here.

Thanks

Francis.Dupont@enst-bretagne.fr