Subject: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security

From: Francis Dupont <[email-masked]>
Date: Fri, 26 Apr 2002 14:02:29 +0200

I've just done a comment about NAT/NATPT traversal security
at IPCN and I believe it is useful to discuss about the raised
issue in this list.

The basic problem is the HA has to trust the CoA found from the
source address in the IP header which can be forged by anyone
in the path (note this is different from my "trust the CoA given
by the MN argument" in a previous mail).

I don't know if this is enough to restrict/reject the NAT traversal
proposal but at least the security section should *not* stay empty!

Regards

[email-masked]

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Fri, 26 Apr 2002 10:11:22 -0400

Francis,

Excellent point which we were going to raise as well.
It is the similar situation as in the Regional Registration
draft...the tunnel end point is set up to an CoA, that is
not part of protected data.  (In the Regional Registration
case, when the GFA IPext is protected by FHAE, this is not
an issue.)

Regarding the NAT draft, the basic need is for the HA to 
somehow verify that the IP SRC address is in fact from a
NAT, and not some man-in-the-middle.  However, I'm not sure
that given the current nature of NAT, if this is possible.
I was looking at the STUN draft in midcomm WG as a possible hook,
but I think this approach is also susceptible to man-in-the-middle.

It seems that establishing a MIP tunnel as above opens up greater
risk for MN traffic hijacking.  However, as I'm not a security
expert, I don't know for sure.  Perhaps you and others can shed
some light on this. 

Since NAT/MIP interaction is a real need in MIP deployments, hopefully
we can ensure that we are not opening up any further security
risks than base MIP.

Regards,
Madhavi

---

From: Milind Kulkarni <[email-masked]>
Date: Fri, 26 Apr 2002 07:45:06 -0700

Francis,

I am sure the authors will correct you as well, but the latest
version for this draft is -02.txt (and not 00). Though even in 
that draft, the scheme is susceptible to man-in-the-middle attack.

Milind

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Fri, 26 Apr 2002 21:34:13 +0200

Francis,

	Thanks for pointing this out. You may want to take a look at
the security section of the current draft, which is 
 http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt

	I believe we have discussed this attack in the security
section of that draft, but if I've mistunderstood or not fully
understood the extent of the attack, I'd be happy to update the
security section or take other action as indicated by input from
the list.

	Best regards,
		Henrik

---

From: Francis Dupont <[email-masked]>
Date: Sat, 27 Apr 2002 17:33:47 +0200

=> I apologize about the draft version (I was at a conference with limited
resources and time) but the basic idea is still the same.

=> I disagree: the fact the CoA cannot be protected is not described
in the security section. In fact this has nothing to do with the
UDP encapsulation or registration extension (which introduce no new
security vulnerability as you explain) but only with the idea of
NAT traversal.
   
Regards

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Sat, 27 Apr 2002 18:27:02 +0200

Francis,

	Ah, I see what you are getting at now. Do you happen to have
some text discussing this already? If not, would you consider the
text below a decent discussion of this problem, and a meaningful
conclusion?

	"Although using UDP tunnelling as such does not introduce new
      vulnerablilities, it has to be pointed out that communicating
      across a NAT in fact does change the situation. Without a NAT, the
      care-of address in the registration request will be directly used
      by the home agent to send traffic back to the mobile node, and the
      care-of address is protected by the mobile-home authentication
      extension. When communicating across a NAT, the effective care-of
      address from the home agent point of view is that of the NAT,
      which is not protected by any authentication extension, but
      inferred from the apparent IP source address of received packets.
      This means that by using the mobile IP registration extensions
      described in this document to enable traversal of NATs, one is
      opening oneself up to having the care-of address of a mobile node
      spoofed. The implication is again that it is RECOMMENDED that this
      mechanism for NAT traversal be used together with IPsec or
      equivalent mechanisms to further mutually authenticate the
      communicating parties, and protect the communication."

	Regards,
		Henrik

---

From: Francis Dupont <[email-masked]>
Date: Sun, 28 Apr 2002 15:19:05 +0200

Ah, I see what you are getting at now. Do you happen to have
   some text discussing this already?

=> no, I raised the issue during a presentation at the IPCN meeting
and it seemed the importance was enough to send a short message
in the list to open a discussion ASAP.

   If not, would you consider the text below a decent discussion of
  this problem, and a meaningful conclusion?

=> as soon as the problem is explained I am happy.
I am afraid you have to consider the use of forged care-of address in
Denial of Service attacks too (IMHO this is far less critical but
I don't believe nobody won't complain).

Thanks

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Mon, 29 Apr 2002 15:18:16 +0200

Francis wrote:
...<snip>...
> => as soon as the problem is explained I am happy.

Ok. I'll make sure some text on this is included. 

> I don't believe nobody won't complain).

Mmm, I don't see that there's a difference in this case at all - a forged
care-of address only exists at the time where a registration request has
been decoded and validated, and a valid UDP tunnel request extension found.
But in a DoS attack, (as opposed to an attack with a cryptographically broken
security association) the attacker will be sending invalid reg. requests to
the HA, to force it to spend time handling them. They will never come as
far as to being validated, and thus there cannot be an issue of a forged
care-of address. As far as I can see, this plays out exactly as in current
MIPv4 - no difference at all.

	Best regards,
		Henrik

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Mon, 29 Apr 2002 16:22:47 +0200

Francis,

Actually, I've been thinking some more about this, and I believe that
the problem is less serious than I first thought.  What can be done by
somebody on the path between MN and HA is to spoof the source address of
the registration request, which will later be used as the care-of
address, i.e.  the destination address of the forward tunnel from the HA
point of view. This will not influence the reverse tunnel, which will
remain unaffected. So the attacker will have to remain on the path in
order to do harm, and then we are back to a situation which is pretty
equivalent to what we have with MIPv4 without NAT traversal, I believe.
Have I missed something here?

	Regards,
		Henrik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 30 Apr 2002 10:50:47 +0200

> I don't believe nobody won't complain).
   
   Mmm, I don't see that there's a difference in this case at all

=> I disagree: a lot of traffic can be redirected with only one packet.

   But in a DoS attack...

=> the man DoS attack is not against the HA but against the real owner
of the forged CoA.

   As far as I can see, this plays out exactly as in current MIPv4.
   
=> in the current MIPv4, only the MN can launch the attack and it is
supposed to be trustable (and its identity is revealed in any packet).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 30 Apr 2002 10:55:13 +0200

=> I agree that if the attacker gets the traffic and the traffic is
protected the only bad effect for the MN is this traffic is lost.
But the DoS side is still annoying because with one packet the bad guy
can redirect a lot of traffic to its victim as I explained in a previous
mail.

Regards