Subject: RE: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T?

From: <[email-masked]>
Date: Sat, 10 Sep 2005 10:52:06 +0300

Francis Dupont wrote:
   
> => you should explain why I'd like to eliminate this "middle
> ground": if none of the NAT_DETECTION_*_IP and NAT_PREVENTION is
> used, the addresses in the IP header are not protected because they
> are not "reflected" inside an IKE message. This opens the door at
> what I call the pseudo-transient NAT attack: an attacker in the path
> can patch headers in order to redirect the IPsec traffic to another
> node, usually in order to flood it. (it is pseudo-NAT because it
> acts like a NAT, it is transient because it has to be on the path
> only for some messages)

Normal IKEv2 also has this problem, and nobody so far has complained
that IKEv2 would be too insecure (well, except you, perhaps). IMHO 
we shouldn't waste time solving imaginary problems that are not
problems in the real world...

>    Or as I put in my IETF63 slides, this is a "trade-off 
>    between DoS-ing yourself and religious beliefs". In my opinion, 
>    we don't need to settle this trade-off in the protocol spec by 
>    saying "MUST use NAT prevention if not using NAT-T": the 
>    functionality is available for those who really want to use it 
>    (and understanding NAT_PREVENTION is mandatory for the responder).
>    
> => it seems you advocate for a SHOULD?

No, I advocate for "NAT prevention SHOULD NOT be enabled by default",
since it is much more likely to DoS yourself than prevent any attacks.

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Sat, 10 Sep 2005 11:55:39 +0200

In your previous mail you wrote:

   Normal IKEv2 also has this problem, and nobody so far has complained
   that IKEv2 would be too insecure (well, except you, perhaps).

=> the default policy is to check the addresses in the IP header
against identity and certificate payloads (cf the pki4ipsec I-D)
so the problem appears only in some scenarios where MOBIKE is
useful...

   IMHO we shouldn't waste time solving imaginary problems that are not
   problems in the real world...
   
=> if you need an exploit this can be done... If you need better
examples of imaginary problems where we've already wasted time
solving them I can give one.

   
=> perhaps you consider that IPv6 is not (yet) the real world but
IPv6 folks do *not* want this "SHOULD NOT" at all. As there is no NAT
in IPv6 NAT prevention DoSes nobody and prevents an easy DoS attack.

And if you'd like to speak about the real world, I'd like to know
the proportion of implentations supporting NAT traversal by default
for IPv4. IMHO we likely get NAT detection for IPv4 and NAT prevention
for IPv6, solving the #41 in a way we can both agree about.

Regards

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Sep 2005 16:06:04 +0300

>since it is much more likely to DoS yourself than prevent any attacks.
This isn't necessarily the case. The most likely dos-yourself
scenario is not enabling NAT traversal, because NATs exists
in almost all public network access. Unless I'm mistaken,
plain old ESP does not get through the most widely deployed
NAT types. There's the small likelihood that you have some
atypical NAT in between, and there NAT prevention makes
a difference in the final outcome. But the typical case dominates,
so we're essentially debating whether the failure in this
configuration has a 95% or 96% probability of occurring...

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Sep 2005 16:15:14 +0300

>for IPv6, solving the #41 in a way we can both agree about.
Is there an IPv6 - IPv4 translation type where the middle
ground would be useful even for an IPv6 host?

If not, I would suggest leaving the middle ground away
from v6 but allowing it in v4. ("NAT preventation SHOULD
be enabled by default in IPv6 if NAT traversal is not enabled.")

If yes, then I think the current text might suffice.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 12 Sep 2005 12:50:53 -0700

> be enabled by default in IPv6 if NAT traversal is not enabled.")
This sounds reasonable to me. 

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Sep 2005 13:41:48 +0300

I think we can close this one. Pasi tells us that there's
a possibility that even in IPv6 some of the translation
schemes could benefit from this. Even so, it may be
quite reasonable to make the IPv6 default on NATs
stricter than in IPv4. This seems to be supported by
Mohan and Francis (and myself), so with the small
number of folks that have participated this discussion,
its propbably as close to consensus as we are going to
get.

So, I think we can make the document leave the
middle ground away from v6 but allowing it in v4.
("NAT preventation SHOULD be enabled by default
in IPv6 if NAT traversal is not enabled.", or words
to that effect.)

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 19 Sep 2005 16:53:52 +0200

=> Mobike is not supposed to support the crossed-version case.

=> I don't like to keep a security hole in a default policy.

=> I find something strange: when I signaled the issue to Mobile IP
folks (the issue is common to signalings with NAT traversal),
they changed immediately their specs to mitigate the issue (cf
RFC 3519). When I signal it to IPsec folks, it seems it is not
a real issue. Usually, arrogance is more for French guys...
So, please do what is needed, and don't believe I'll try to
delay IKEv2 with this (i.e., now it is a Mobike issue).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Sep 2005 12:17:14 +0200

I think we can close this one.

=> but please explain what will be done for the security problem
itself (i.e., don't leave an undocumented security hole).

   This seems to be supported by Mohan and Francis (and myself),
   so with the small number of folks

=> I'll be fair: I won't use this against you (:-).

   that have participated this discussion, its propbably as close to
   consensus as we are going to get.
   
=> the only consensus we have is a MUST is too strong for IPv4.

=> this is a MAY for the opposite.

=> this is far from enough! We need something for IPv4 and if it is
a MAY for the opposite a good security guideline.
BTW I agree with the proposed text, my concern is it is incomplete.

Regards