Re: Issue 73: Port numbers in examples

Ok. --Jari

Tero Kivinen wrote:

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