Re: Issue 73: Port numbers in examples

Jari Arkko writes:
> I agree with what Tero is writing below. But from
> what I understood we are just describing the port
> numbers in the example, not adding any other new
> text. Correct?

That is my understanding, though I could add something about this to
the design draft under the NAT-T section. 

Something like this at the end of 5.2.3 of the design draft:
----------------------------------------------------------------------
5.2.3.  Moving to behind NAT and back
...
   Enabling NAT-T has few different things, one is to enable the UDP
   encapsulation of ESP packets.  Another is to change the IKE SA ports
   from port 500 to port 4500.  We do not want to do unnecessary UDP
   encapsulation unless there is really a NAT between peers, i.e. it
   should only be enabled when we actually detect NAT.  On the other
   hand as all implementations supporting NAT-T must be able to respond
   to port 4500 all the time, it is simpler from the protocol point of
   view to change the port numbers from 500 to 4500 immediately when we
   detect that other end supports NAT-T.  This way we do not need to
   start changing ports when we detect NAT, which would cause
   complications in the to the protocol.

   If we would do the actual changing of the port only after we detect
   NAT, then the responder would not be able to use the IKE and IPsec
   SAs immediately after their address is changed to be behind NAT, as
   it would need to wait for the next packet from the initiator to see
   what IP and port numbers are used after the initiator changed its
   port from 500 to 4500.  Responder would not also be able to send
   anything to the initiator before the initiator has sent something to
   responder.  If we do the port number changing immediately after the
   IKE_SA_INIT and before IKE_AUTH phase, then we get the rid of this
   problem.
-- 
[email protected]