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

From: <[email-masked]>
Date: Tue, 20 Sep 2005 13:23:15 +0300

Francis Dupont wrote:

> BTW I agree with the proposed text, my concern is it is 
> incomplete.

Since you seem to be the one person who thinks this is a 
serious problem, perhaps you could also provide some new 
text that better describes the situation?

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Sep 2005 13:26:56 +0200

=> the one is this list...

   serious problem,

=> the MIP WG considered it as serious too.

   perhaps you could also provide some new 
   text that better describes the situation?
   
=> I'll take some words from draft-dupont-transient-pseudonat-04.txt
where the problem is explained.

Regards

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

---

From: Sami Vaarala <[email-masked]>
Date: Tue, 20 Sep 2005 14:45:23 +0300

Moi,

Francis Dupont wrote:
> [...]

It's been some time but I believe the reaction in MIP WG was that
although the issue is real, it's not terribly serious.  Given the
location of the attacker (on the path), the attacker has many other
modes of attack than just transient traffic forwarding.

Because there's little that can be done in MIPv4 w.r.t. this problem,
namely just tweaking mobility binding lifetimes, it was documented
in RFC 3519 Security Considerations.  It's nice-to-know information
for an implementor.  Of course, having NAT prevention in a NAT traversal
document wasn't an option either :-).

Moreover, from my viewpoint, NAT prevention is something I don't
really understand. The real world is riddled with NATs, and it will
probably be the case with IPv6 too despite hope to the contrary.
So why make things more brittle?  Are transient traffic redirection
attacks serious enough to warrant it?

Best,

-Sami

---

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

Are transient traffic redirection attacks serious enough to warrant it?

=> you miss the point: the attack is transient, not the traffic redirection.

PS: to be secure is a property security protocols are looking for.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Sami Vaarala <[email-masked]>
Date: Tue, 20 Sep 2005 15:27:21 +0300

> => you miss the point: the attack is transient, not the traffic redirection.

In the MIPv4 context the traffic redirection is also transient.
When the MN rebinds, the redirection ends.  Now, if there is no
equivalent mechanism in MOBIKE, the attack is more serious, but
from previous mails it seems that this aspect is covered?

-Sami

---

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

First attempt:

IKE uses addresses it runs over, taken from IP headers, as
endpoint addresses for IPsec SAs it establishes. If the
addresses are left unprotected, an attacker can redirect the IPsec
traffic to a third party just modifying the IP header of some IKE messages.
Either NAT_DETECTION_*_IP or NO_NATS_ALLOWED detect the modification
of the IP header on the path, including this attack.

Regards

---

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

In the MIPv4 context the traffic redirection is also transient.
   When the MN rebinds, the redirection ends.

=> no, it is only short. There is a huge difference between hacking
some signaling messages and hacking the traffic flow.

   Now, if there is no equivalent mechanism in MOBIKE, the attack is
   more serious, but from previous mails it seems that this aspect is
   covered?
   
=> it is not covered but the situation is different for MOBIKE as
explained in previous messages. BTW it seems the current protocol
document requires in fact a NAT detection so now there are many
reasons to drop the "middle ground", i.e., make NAT traversal or
NAT prevention mandatory.

Regards

---

From: Sami Vaarala <[email-masked]>
Date: Tue, 20 Sep 2005 16:41:34 +0300

Hi,

> some signaling messages and hacking the traffic flow.

Ok, this is a difference of terminology.  A couple of minutes worth
of redirection compared to the attacker's effort is transient to me :)

> NAT prevention mandatory.

Ok, this may be.  I haven't followed MOBIKE closely and was
commenting on the MIPv4 part which I thought to be misrepresented
as a serious problem.

-Sami

---

From: Jari Arkko <[email-masked]>
Date: Mon, 26 Sep 2005 18:10:53 +0300

First I wrote:

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

>of the IP header on the path, including this attack.
Looking at this thread, it seems that there seems to be
support for our v6 text. We've since then been discussing
whether stronger language is needed for v4 as well. Right
now I don't see a lot of support for that. But let me ping a
couple of mobikers that I see in the same conference as I
am, to get their view.

The text that your provided above Francis looks like
material that could be included in the security
considerations section. Of course, we'd have to also
mention that under some conditions, the attack is
temporary. For instance, if the real node sends packets
after the attacker has left, the problem is corrected.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Sep 2005 17:28:53 +0200

=> unfortunately this is not true: the problem can be corrected
only with an explicit action (an address update to the right address).

Regards

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Sep 2005 07:46:35 +0300

>only with an explicit action (an address update to the right address).
Right. The real node needs to do an address update.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Sep 2005 08:35:06 +0300

Some further thoughts. Even in v4, the benefit
of the no-preventation-and-no-traversal case is
extremely small.  Basically, its only different
to the NAT preventation case if you happen
to have a rare type of a NAT between. For
normal NATs, the communication would fail.

So I would actually like to say something like
"NAT preventation SHOULD be enabled by default
if NAT traversal is not enabled." I also checked
with Pasi that he seems OK with this approach.

I also reviewed our security considerations
text, and it seems that we have sufficient
text to describe what the impact of the
NAT prevention payloads (or lack of thereof) is.
However, I did not see sufficient text to
talk about how temporary or permanent these
attacks are. I'd like to suggest the following
text be added between paragraphs 2 and 3
in Section 4.1:

  This attack can only be launched by on-path
  attackers that are capable of modifying either
  the initial IKE packets or other packets carrying
  NAT detection payloads (such as Dead Peer Detection
  messages). By modifying the outer addresses in
  these packets, the attackers can make the peers
  believe a new NAT or a changed NAT binding exists
  between them. The attack can continue as long as
  the attacker is on the path, modifying packets. If this
  is no longer the case, IKEv2 and MOBIKE mechanisms
  designed to detect NAT mapping changes will eventually
  recognize that the intended traffic is not getting through,
  and update the addresses appropriately.

Does this work for everyone?

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Tue, 27 Sep 2005 10:30:33 -0700

Yes, this sounds fine to me.

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "Francis Dupont" <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 26, 2005 10:35 PM
Subject: Re: [Mobike] Issue 41: Mandate NAT prevention if not doing NAT-T?

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Sep 2005 19:33:35 +0200

I'd like to suggest the following
   text be added between paragraphs 2 and 3
   in Section 4.1:
   
     the attacker is on the path, modifying packets.

=> it should be clear that the packets are IKE messages.
In fact, we need the whole text to see if a confusion is possible,
and BTW the term "message" is better than "packet"...

     If this

=> this works.

Thanks

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 27 Sep 2005 18:35:54 -0700

>   messages). By modifying the outer addresses in

Hmm.. with issue 34, we are also allowing updates
from ESP packets..

> Does this work for everyone?
Looks okay to me.

-mohan