Subject: Re: bidding down attach on NAT-T

From: "Andrew Krywaniuk" <[email-masked]>
Date: Thu, 06 Mar 2003 20:01:14 -0500

This seems like such an imaginary problem. I mean, what are you going to do 
to prevent it? An international registry of authorized NATs? Bring back 
strick source routing?

A while back when I was working on keepalives, people used to complain that 
the protocol was insecure because the intermediate router could simply drop 
the keepalive packets, thus making the link appear dead. To which I replied 
sure, but they could also just drop all the packets, making the link really 
dead.

IPsec is supposed to be secure communication over an insecure medium. Let's 
try to work within that scope.

Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*   
http://join.msn.com/?page=features/junkmail

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Mar 2003 10:17:35 +0100

In your previous mail you wrote:

=> I believe you missed the fact I didn't try to make NAT traversal
secure (I clearly wrote I believe it is near impossible): you are
in my side, i.e., you consider that NAT traversal has an untrackable
security issue with attackers which behave like NATs.

Regards

[email-masked]

---

From: Derek Atkins <[email-masked]>
Date: 07 Mar 2003 11:41:19 -0500

Francis,

> security issue with attackers which behave like NATs.

While I agree that peers should not use NAT-T if there is no NAT
between them, I do think that NAT-T support should be required.
You never know when there will be a NAT between you and your peer.

Note that you CAN securely detect a NAT (and I consider a pseudo-NAT
to be equivalent to a NAT in this sense) because the IKE messages are
secured.  So the only real attack is some router performing NAT on you
-- but that router could just as easily drop your packets too, so I
don't think this is a credible threat.

Personally, I feel that being able to use IPsec through a NAT is more
important than worrying about some router dropping your packets or
trying to re-NAT you.

> [email-masked]

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Mar 2003 18:19:15 +0100

between them,

=> fine, we agree at 100%.

   I do think that NAT-T support should be required.

=> I have no objection but:
 - configuration must have a knob to disable NAT-T support
 - NAT detection must be secure.

=> I agree but there are some cases where you don't want to support
a NAT between you and your peer.

   secured.

=> yes but the current draft does the NAT detection in the only unsecured
IKE messages, i.e, too soon!

   So the only real attack is some router performing NAT on you
   -- but that router could just as easily drop your packets too, so I
   don't think this is a credible threat.
   
=> this should be the only real attack!

=> I agree but I'd like to have NAT traversal active only when I know
it is possible to get a NAT on the path (i.e., a disable knob in the
config) and when there really is a NAT on the path (i.e., secure the
NAT detection).

Please read the NAT-DETECTION-*-IP stuff and say whether you are happy
with it (I am *not*)?

Thanks

---

From: [email-masked]
Date: Sun, 9 Mar 2003 20:13:07 -0500

> Please read the NAT-DETECTION-*-IP stuff and say whether you are happy

Please do, everyone. I tried to copy the philosophy of the NAT-T documents
into IKEv2, but I may have gotten it wrong and the documents I copied may
have been wrong. Proofreading by people knowledgeable in this space is
vital.

For example, I was just rereading ESP encapsulation and it is different
than I remembered and different than what I wrote in IKEv2-05. It's a
detail, but it's important. How does a packet sent to UDP port 4500 get
identified as ESP or IKE. What I remember (and wrote) was that IKE messages
have four bytes of zero prepended and ESP SPIs are not allowed to be zero.
This leads to no overhead for ESP and 4 bytes for IKE. But reading
draft-ietf-udp-encaps-01.txt (April 2002), it calls for eight bytes of zero
prepended to ESP packets and IKE SPIs are not allowed to be zero. This
results in no overhead for IKE packets and 8 bytes for ESP. Did this change
somewhere along the line, and if so which proposal won? Either design
works, but they can't be mixed on a single port.

> a NAT between you and your peer.

Currently ikev2-05 says that NAT support is optional in an IKE
implementation. There are other statements that could be made. It could say
that implementations MUST support NAT-T but that it MAY be configured off.
It could say that if an implementation supports NAT-T, then it MUST have a
configuration switch to turn it off.

I don't have strong feelings. My priorities are keeping the MUST features
minimal while assuring that any two implementations with the MUST features
can be configured to interoperate. How important is it for everyone to
support NAT-T?

> IKE messages, i.e, too soon!

The current draft does NAT detection in the first two messages, which are
not directly cryptographically protected. They are indirectly protected,
however, because MACs of the first two messages are included in subsequent
messages. So someone faking out the NAT detection messages would not
successfully set up an SA.

Michael Richardson <[email-masked]> wrote:
>   The thing that we could do, is require some kind of three way handshake
to
> change the UDP port #/IP address. That could be a rekey.
>
>   This assures that the flow doesn't get aimed at some innocent
bystandard
> until the real client speaks again.
>
>   The sequence would go something like this:
>
>       gateway receives new UDP port #/IP
> #1    sends notify to old UDP port #/IP,
>        indicating that it thinks it should change
> #2    sends notify to new UDP port #/IP,
>        indicating that it thinks it is time to rekey

I think you're assuming a feature in the protocol that's not there.

There is no way specified to change the UDP port # / IP address of an
existing SA. The assumption is that if the NAT changes the translation of
ports and addresses in the middle of the SA, packets in at least one
direction will stop being delivered and the SA will fail (by timing out).
One or both endpoints MAY then try to open a new SA with the new addresses
and ports.

Something missing from the spec in general is how often to retry failed SAs
and whether to retry immediately when one fails. One could imagine some
really bad strategies (from a performance point of view). I thought it
unnecessary to specify it because it does not affect interoperability and
prescribing such behavior requires that we agree on what it should be. But
some "implementer's hints" would probably be a good idea.

If we were to support address and port changes in the middle of an SA,
there would be possible attacks of the sort you describe and we should try
to defend against them. But is there really a need? TCP connections fail if
addresses and ports change in the middle of a connection. The endpoints are
expected to start over. With Mobile-IP, this may be a common case, so
perhaps they have to deal with it. But do we?

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Ari Huttunen <[email-masked]>
Date: Mon, 10 Mar 2003 10:58:36 +0200

> works, but they can't be mixed on a single port.

Yes, most of the design decisions have changed at least a couple
of times, along the line. That's a long line too. You should be reading
the latest documents like this
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt

> can be configured to interoperate. How important is it for everyone to

I'd say the MUST part is recognizing NAT-T related payloads and being
able say to the other guy that no-NAT-T-spoken here. I'd also like there
to be no VIDs for that purpose, so you'd be able to put NAT-T payloads
in whatever message is most suitable. Still, I'd say that
it would be highly desirable for IKEv2 to just work in spite of NATs.

As to the details, I think I'll pass that. I just don't have time/interest
to do that, and I'd just get some part wrong.

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: Francis Dupont <[email-masked]>
Date: Mon, 10 Mar 2003 11:39:03 +0100

> Please read the NAT-DETECTION-*-IP stuff and say whether you are happy
   
   Please do, everyone...

=> the first thing I don't understand is why they are in the first
two messages...

=> I really like the last thing (a mandatory config knob to turn NAT-T
off when it is supported).

   How important is it for everyone to support NAT-T?

=> I don't believe a MUST support is a good idea because this makes no
sense for an IPv6 implementation.
   
   > IKE messages, i.e, too soon!
   
   The current draft does NAT detection in the first two messages,

=> this is a point I don't understand the reason of.

   which are
   
=> I prefer direct protection. For instance, it makes the caching of
NAT detection (the only way to reach an initial responder behind a NAT)
far easier to code safely.

   
=> IMHO Michael assumed an implicit peer address update mechanism
which is very common in NAT-T context.

=> this is why the peer address update mechanism is used. And it is not
unsecure, in fact, one can argue it improves security.

=> only the endpoint behind the NAT can. And this is really painful.
Note that rekeying doesn't really solve the issue because the NAT
is by definition out of control: it can change mappings when it likes
and of course never sends notifications to its victims.

=> I disagree, in the case of NAT-T the solution *is* to implement
an implicit peer address update mechanism.

   If we were to support address and port changes in the middle of an SA,
   there would be possible attacks of the sort you describe

=> these attacks are possible as soon as the NAT-T feature is active.
So the implicit mechanism must be enabled only in this case.

   and we should try to defend against them.

=> with NAT-T the best defense is the implicit mechanism: it opens
a race between the attacker and the peer behind the NAT, the attacker
has to stay on the path, i.e., it becomes an ordinary rogue NAT.

   But is there really a need? TCP connections fail if
   addresses and ports change in the middle of a connection.

=> we never assumed that the tunnel mode is no more used (:-).

   The endpoints are
   
=> the two other common cases where an address management is needed,
mobility and multi-homing, need an explicit mechanism with peer address
protection. Today, there is a very inefficient explicit mechanism,
rekeying, and still no good way to protect peer addresses.

Thanks

PS: I noted I have to add a protection against long term bidding down
attacks for NAT-T in my draft. The text will be something like:

   In order to avoid a bidding down attack, the implicit mechanism
   MUST verify the presence of a NAT on the path, i.e., the new
   peer address MUST be checked against the peer address in the
   corresponding peer address notification.

   NOTE: what to do when they match?

PPS: has someone a good idea about the note?

---

From: Derek Atkins <[email-masked]>
Date: 10 Mar 2003 13:54:12 -0500

> sense for an IPv6 implementation.

Can we agree on "MUST support NAT-T if you support IPv4"?  If you ONLY
support v6, then NAT-T can be relegated to a SHOULD or MAY.

-derek

---

From: Francis Dupont <[email-masked]>
Date: Tue, 11 Mar 2003 09:55:53 +0100

> sense for an IPv6 implementation.
   
   Can we agree on "MUST support NAT-T if you support IPv4"?

=> I am not in favor of a MUST which has nothing to do with
interoperability, IMHO we should let the market do its job...
And I don't believe implementors who still have NAT-T support
in their plans like to become not compliant.

Thanks

---

From: Derek Atkins <[email-masked]>
Date: 11 Mar 2003 10:35:16 -0500

> in their plans like to become not compliant.

HUH?  What do you mean it has nothing to do with interoperability.
If implementations don't implement NAT-T then it wont work across a NAT.
I would certainly call that an interoperability problem, wouldn't you?

I also do not understand your last sentence.  If they are implementing
NAT-T then they WOULD be compliant -- it's only people who DON'T
implement who would be compliant.  Besides, this is only for implementors
who support IPv6.  Your initial complaint about MUST was that it didn't
make sense for v6.  I agree with that, but now you say it doesn't make
sense for v4, either?

If we're not going to make sure that IKEv2 works across NAT, then I
think we should just go home now.  Read after me: A road warrior has
no choice over whether there is a NAT is between them and their home
base.  We should support this (EXTREMELY) common case.

> [email-masked]

-derek, who has been stuck behind a NAT at TOO MANY conferences.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Mar 2003 12:00:50 +0100

=> I should have put an explicit reference to RFC 2119.

=> I disagree. A MUST for NAT-T support doesn't make more sense than
a MUST for IPv6 support for instance.

   I also do not understand your last sentence.

=> easy: if a feature is mandatory then all implementations which don't
(yet) support it are (still) not compliant.

   If they are implementing
   make sense for v6.

=> IPv6 is an example of a real world environment where there is *no* NAT.

   I agree with that, but now you say it doesn't make sense for v4, either?

=> MUST is not about what we'd like to get, it is about what is needed
in order to get the protocol work.

=> we disagree only about the good usage of a MUST in a standard track
document. IMHO here a MUST should not be used and even if we put a MUST
it'll have no direct effect about what we'll get in the real world.

=> yes, I have no NAT at my office or at home, but conferences or
worse, interop events are places where I can keep up my hate for NATs!

Thanks

PS: from RFC 2119:

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

So NAT-T support should not get a MUST, but support of NAT-T detection
(i.e., NAT-DETECTION-*-IP (or better) stuff) should get one.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 12 Mar 2003 07:10:29 -0500

Just a reminder that there are many non-VPN uses for IKE2, such as RPSec's
interest to use IKE/IPSec to secure routing protocols. Such use does not 
require
NAT.

Regards,
Jeff

---

From: Derek Atkins <[email-masked]>
Date: 12 Mar 2003 13:50:11 -0500

"[email-masked]" <[email-masked]> writes:

> interest to use IKE/IPSec to secure routing protocols. Such use does
> not require
> NAT.

Sure, but just because some uses don't require a feature does not
imply that it shouldn't be a "MUST."  For example, VPNs don't use AH,
but AH is still a MUST.  Similarly, if NAT-T is defined as "MUST
implement if you support ipv4", it does not imply that you have to
_USE_ NAT-T.

Just a reminder that "must implement" does not imply "must use."

-derek

---

From: Steve Dispensa <[email-masked]>
Date: 12 Mar 2003 20:23:04 -0600

> base.  We should support this (EXTREMELY) common case.

Let me second this.  The market *is* doing its job - *lots* of 
remote worker products are moving to non-IPSEC encryption protocols.
Look at URoam, Neoteris, Netilla, Aventail, Openreach, SafeWeb, 
Imperito, and lots of others (including us).  And that's just the 
"remote work" industry.  IPSEC (as implemented) is a massive pain wrt 
NAT.  Even if users have a choice to remove their NAT (i.e. their home
Linksys router), they usually don't want to or can't.

I realize there are lots of other ways for IPSEC to be employed, but
remote network access is certainly a key area that is hurting because
of this.  I strongly recommend a MUST for NAT-T.

 -sd

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Mar 2003 22:57:36 +0100

IPSEC (as implemented) is a massive pain wrt NAT.
   Even if users have a choice to remove their NAT (i.e. their home
   Linksys router), they usually don't want to or can't.
   
=> I believe you assume far too much about the power of the IETF.
The only useful thing that IETF can (should!) do is to define
a good NAT traversal mechanism. To make its support mandatory is
only annoying for implementors, this doesn't make it more available
on the market...

=> reread RFC 2119.

Regards