Subject: NAT-T, IKEv2, Vendor ID, port floating??

From: Tom Hu <[email-masked]>
Date: Wed, 30 Jul 2003 14:29:40 -0700

Hi,

In IKEv1, peers should exchange vendor ID to know each other capability
of NAT-T.

In IKEv2, NAT-T implementation is optional. Should we exchange Vendor ID
(NAT-T) at Initial exchange? 

If the answer is yes, that means we have Vendor ID with NAT-Detect
payload on the Initial exchange? We should know the order of payload at
the message.

Another question is that Initiator and Responder exchange the NAT-D to
find the NAT existence at Initial Exchange. Does it mean at the AUTH
exchange, both peers should float the port to 4500?

Thanks,

Tom Hu

---

From: Francis Dupont <[email-masked]>
Date: Thu, 31 Jul 2003 11:10:41 +0200

In your previous mail you wrote:

   In IKEv2, NAT-T implementation is optional.

=> this is in fact unclear:
 - is the support of UDP port 4500 mandatory? Current text says
   it is only when NAT-T is supported. As when there is no listener
   at port 4500 the initiator gets an ICMP port unreachable, IMHO
   we can keep the document idea that no support of port 4500 implies
   no NAT-T support.
 - is the support of NAT detection mandatory? For some other reasons
   (implicit peer address protection) I stronly believe it should be
   mandatory when the IKE_SA_INIT is done over port 500 and to answer
   the next point it should be mandatory in all cases.
 - does the support of UDP port 4500 imply the support of NAT-T?
   I don't think so because a responder can reject the NAT-T in
   IKE_AUTH, i.e., I makes a distinction between no NAT-T support
   and disabled NAT-T support: real no NAT-T support is just
   inconvenience, NAT-T should be supported but can be disabled
   for policy reasons for instance. Note the NAT detection works
   for both the initiator and the responder even only the initiator
   use it, so the next point is:
 - does the use of UDP port 4500 imply the use of NAT-T? As the
   NAT detection (which I want to make mandatory) is reliable for
   both peers, this doesn't really matter but the document should
   be clarified about this point.

   Should we exchange Vendor ID (NAT-T) at Initial exchange?

=> I don't think so: IKEv2 assumes NAT-T support (which should
   be permanently disabled when it is not really implemented).

=> this is a generic question: what is the order of payloads?
Even this is a "Clarified required ordering for payloads" in
changes (:-), the only specifications are in sections 1 and 2
(the document says "the figures in section 2" ??). IMHO we should
get a rule like notifications first, vendor IDs last.

=> yes, the document is (this time :-) very clear:

      The IKE initiator MUST check these payloads (NAT-D)
       if present and if they do not match the addresses in the
      outer packet MUST tunnel all future IKE, ESP, and AH packets
      associated with this IKE_SA over UDP port 4500.

as the NAT-D is in IKE_SA_INIT, IKE_AUTH is included in the future
IKE packets.

Thanks

[email-masked]