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

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Aug 2003 20:18:30 +0300

Tom Hu writes:
> 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? 

No. In IKEv1 we needed to have vendor ID, because we needed to know if
the other end supported NAT-T discovery payloads or not.

In the IKEv2 ALL implementations MUST be able to at least ignore the
NAT_DETECTION_* notification payloads, i.e there is no need to know if
the other end supports NAT_DETECTION_* notifications or not (see
section 3.10.1 third paragraph saying that unknown status
notifications MUST be ignored if not recognized). If initiator
supports NAT-T, it includes NAT_DETECTION_* notifications to all
requests. If responder supports NAT-T, and it received NAT_DETECTION_*
notifications from the initiator it includes its own NAT_DETECTION_*
notifications.

There is no point for the responder to include those notifications if
it didn't receive them from the initiators, is it knows that the other
end does not support NAT-T (or it is disabled), because it didn't
include NAT_DETECTION_* notifications. The initiator must still be
able to ignore those if the responder decides to include them.

Both ends should only enable NAT-T if they have both sent and received
NAT_DETECTION_* notifications, and detected that there is NAT between.
If the NAT-T is disabled by configuration then the end MUST NOT send
NAT_DETECTION_* payloads, because if there is NAT between the other
end will enable the NAT-T and there is no way to tell it otherwise. 

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

If the NAT is detected inside the IKE_SA_INIT exchange then the
initiator should change the source and destination port to 4500 (the
responder MUST support listening of port 4500 if it has NAT-T
supported and enabled (2.23 second last paragraph)).

I.e the AUTH exchange is done over port 4500. The initiator can
initiate IKE_SA_INIT on port 4500 if it knows by some other means that
the other end supports and allows NAT-T (i.e either by manual
configuration, or because other end supported it earlier etc). The
initiator can also always start by using port 500 if it wants to. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Aug 2003 20:25:40 +0300

Francis Dupont writes:
> => 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.

I think the easier is to start by using port 500 unless you know from
somewhere else that NAT-T is supported and enabled. You cannot trust
ICMP port unreachable messages, i.e initiating to 4500 to host which
does not listen it would cause timeout. 

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

It is mandatory to be able to ignore those packets. It is not
mandatory to be able to reply to them. 

>  - does the support of UDP port 4500 imply the support of NAT-T?

No. 

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

To detect that NAT-T is supported AND enabled, you must have both
received and sent NAT_DETECTION_* notifications. If those payloads
are only going in one direction, that means that other end either does
not support NAT-T or it is disabled. 

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

Use of port 4500 only implies that the other end supports the
different format used for that port. It does not imply support of the
NAT-T (altought I see no point of supporting the format only used by
NAT-T if you do not support NAT-T). It also does not imply whether the
NAT-T is enabled.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Aug 2003 10:31:47 +0200

In your previous mail you wrote:

=> I don't understand how the second sentence applies to the responder:
when a NAT is detected and NAT-T not supported or enabled, the IKE
session has to be dropped before the end of the IKE_AUTH exchange.
Not to put NAT_DETECTION_* notifications will enable the initiator
to send the third message but it is not enough.

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Aug 2003 10:22:38 +0200

=> in my idea to make NAT detection mandatory there are two parts:
 - the initiator must put NAT_DETECTION_* notifications in the
   first message.
 - the responder must reply to the NAT_DETECTION_* notifications.
I agree this is a change from the current specs.

   
=> this makes sense only if NAT detection is not mandatory...
Obviously my idea to use NAT detection to indirectly protect
the peer addresses has an impact here but it is the simplest
way to avoid attacks on the peer addresses and one can still
reject IKE_AUTH what a NAT is detected but not accepted.

=> fine with me (when it will be in the document or its companion tutorial).

Thanks

---

From: Ari Huttunen <[email-masked]>
Date: Wed, 06 Aug 2003 13:23:14 +0300

> I agree this is a change from the current specs.

I would hesitate to make NAT detection mandatory, just for patenting
reasons. I'm not saying there is necessarily any problem with that,
but I remember that detection of a NAT was one thing being claimed by
an SSH patent application. So, if we assume that there are relatively
paranoid people out there who are paranoid about the patent issues, they
wouldn't want NAT detection being mandatory.

(If that didn't contain enough disclaimers) I would point out that it's
a long while since I read those patent applications, and I've no idea
about their current status. Nor do I care about their status.

Ari

-- 
I play it cool and dig all jive,
  that's the reason I stay alive.
   My motto as I live and learn,
    is dig and be dug in return. <Langston Hughes>

Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com

F(ully)-Secure products: Securing the Mobile Enterprise

---

From: Ari Huttunen <[email-masked]>
Date: Wed, 06 Aug 2003 16:06:37 +0300

I don't have any disagreement with what you said, but you shouldn't have

Ari

Yoav Nir wrote:

> The minimum support mandated by the draft is to ignore NAT detection.  I
> doubt if even the most paranoid would be afraid of SSH suing over ignoring
> notification payloads with message type 24582 and 24583.
> 
> If we interpret the draft as requiring you to calculate the hash and verify
> it, there may be something to worry about, but as long as we agree that
> ignoring is acceptable, I don't see the problem with making support
> mandatory.  All we want to do is to make sure that even if you don't support
> NAT traversal, you won't be unable to interoperate just because the peer
> sends the notification.
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ari Huttunen
> Sent: Wednesday, August 06, 2003 12:23 PM
> To: Francis Dupont
> Cc: Tero Kivinen; [email-masked]; ietf ipsec
> Subject: Re: NAT-T, IKEv2, Vendor ID, port floating??
> 
>

---

From: "Yoav Nir" <[email-masked]>
Date: Wed, 6 Aug 2003 15:43:30 +0200

-----Original Message-----

Ari

---

From: Markus Friedl <[email-masked]>
Date: Wed, 6 Aug 2003 13:13:55 +0200

> => in my idea to make NAT detection mandatory there are two parts:

I don't like the idea of having NAT detection mandatory.

How is it possible to avoid potential NAT-T patent problems?

Especially since nobody seems to know the nature of these
problems.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Aug 2003 17:32:20 +0200

=> there is the simplest way to get a defense for attacks
on peer addresses. But perhaps you can propose a better one?

=> IMHO the patent problem is more about NAT-T itself.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Aug 2003 17:27:41 +0200

reasons.

=> I don't believe the NAT detection is patented even if not all
patent applications for trivial things are rejected.

   I'm not saying there is necessarily any problem with that,
   
=> I am not paranoid (about patents or other things) but I'll strongly
object if IKEv2 has no defense against attacks on peer addresses.

=> this is not at all against you but IMHO there is some FUD about IKEv2
and patent issues. This has to be fixed (if some real patents apply)
or to cease (if none applies).

Regards

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 6 Aug 2003 18:55:17 +0300

> session has to be dropped before the end of the IKE_AUTH exchange.

It depends on the implementation. If the NAT-T is disabled on the
responder it might not even check the NAT_DETECTION_* notifications
sent by the initiator, thus it might not even notice there is NAT
between. Anyways it MUST not send NAT_DETECTION_* packets back to
initiator if it does not want to allow NAT-T. 

> to send the third message but it is not enough.

It depends. If the NAT is smart enough and there is only one initiator
behind the NAT the ipsec might still work even when NAT-T is disabled. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Aug 2003 21:40:44 +0200

> session has to be dropped before the end of the IKE_AUTH exchange.
   
   It depends on the implementation.

=> I forgot to specify I considered enviroments where NATs are not smart
and there can be more than one initiator behind, i.e., as we have a
NAT-T mechanism, I considered things work with a NAT only when NAT-T
is used.

   If the NAT-T is disabled on the responder it might not even check
   the NAT_DETECTION_* notifications sent by the initiator, thus it
   might not even notice there is NAT between.

=> I'd like the responder always notices because either there is a
real NAT and NAT-T is needed, or there is an attacker playing NAT
and I'd like to know this.

   Anyways it MUST not send NAT_DETECTION_* packets back to
   initiator if it does not want to allow NAT-T. 
   
=> this MUST is not in the document so at least we should agree
something important is not in the document.

=> I don't believe in this case: we have a nice NAT-T mechanism which
works in all cases.

Thanks

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Aug 2003 08:39:39 +0300

> something important is not in the document.

The current document is missing pieces of the NAT-T text. There have
been text proposed to be added, so I am currently waiting for the next
version of the ikev2 document to see if we still need more text there
or not... I will comment this more when the next version is out, and I
can see what is already added there, and how it was added. 

> => I don't believe in this case: we have a nice NAT-T mechanism which

If the adminstrator decided to disable NAT-T then we have two options,
either we fail immediately always when there is NAT between (your
option), or we just try to see if it works through the NAT without
NAT-T (I said we should leave this option also open). If it does not
work through the NAT and adminstrator has disabled the NAT-T, then
we are going to fail later anyways. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/