rewrite of IKEv2 Section 2.11 Address and Port Agility

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

The current text is:

2.11 Address and Port Agility

   IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
   AH associations for the same IP addresses it runs over. The IP
   addresses and ports in the outer header are, however, not themselves
   cryptographically protected, and IKE is designed to work even through
   Network Address Translation (NAT) boxes. An implementation MUST
   accept incoming connection requests even if not received from UDP
   port 500 or 4500, and MUST respond to the address and port from which
   the request was received.  IKE functions identically over IPv4 or
   IPv6.

There are a lot of details to change:
 - the proxy case
 - clearer rule for responses
 - peer address protection when NAT traversal is not active (i.e.,
   when UDP port 500 is used)
 - peer address set management
The whole stuff is in draft-dupont-ikev2-addrmgmt-02.txt but needs to
be integrated into the current draft.
Here is my proposal:

2.11 Address and Port Agility

   An implementation MUST accept incoming connection requests even if
   not received from UDP port 500 or 4500, and MUST respond to the
   address and port from which the request was received. IKE functions
   identically over IPv4 or IPv6 and is designed to work either
   through Network Address Translation (NAT) boxes or with a
   cryptographically protection of the IP addresses and ports in the
   outer header. IKE runs over UDP ports 500 and 4500, and implicitly
   sets up ESP and AH associations for the same IP addresses it runs
   over, i.e., for the peer addresses.

   The response rule has no exception: the response to a request MUST
   be sent from the destination address and port of the request to the
   source address and port of the request using the same transport
   protocol. In case of a retransmitted request, the last received
   message only SHALL be taken into account.

   The NAT detection is performed in the IKE_SA_INIT exchange. All
   messages following this first exchange are either over UDP port
   4500 if NAT traversal support is active, or over UDP port 500 with
   a REQUIRED cryptographically protection of peer addresses and ports
   by PEER_ADDRESS_SOURCE and PEER_ADDRESS_DESTINATION notifications.
   If multiple peer address notifications for the same peer are
   included in a message, the first one MUST be the used peer address.
   In order to associate some possible peer source addresses to
   possible peer destination addresses, the source and destination
   peer addresses notifications MAY be mixed (i.e., not in the common
   order source(s) first, destination(s) after). For instance S1, S2,
   D1, S3, D2, D3 is a hint: S1 or S2 should be used in conjunction
   with D1, S3 with D2 or D3. According to its policy, a peer MAY
   verify the peer address sets at any time, commonly in the IKE_AUTH
   exchange or when they change, for instance using the SubjAltName
   ASN.1 sequence field of X.509v3 certificates.

   When ESP or AH associations in transport mode are setup with
   different addresses in the traffic selectors, i.e., when IKE is
   acting as a client negotiator on behalf of another party, the
   addresses used in the transport mode SAs are the addresses of the
   traffic selectors. A proper authorization in the local policy of
   peers is REQUIRED and this case SHOULD be supported. Note that the
   IPsec SAs built in this proxy case can not be handled by any
   address management mechanism like NAT traversal support.

Thanks

Francis.Dupont@enst-bretagne.fr

PS: my next message will be about the peer address update which can
be included now or postponed as the rekeying already provides a way
to get the same result (but not at the same price).