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

From: Francis Dupont <[email-masked]>
Date: Wed, 01 May 2002 10:39:05 +0200

What the attacker acheives is an eavesdrop in one direction for the 
   duration of the registration. Because the redirect is only valid for the 
   traffic going from the HA to the MN, the traffic from HA to MN is 
   unaffected.
   
=> I don't understand at all...

   For this he has to actively change the source address of the RRQ in an 
   intermediate node to an address which most probably is topologically 
   incorrect and risk to have the packets dropped.

=> to rely on ingress filtering is a bit dangerous here.

   This instead of just passively listening from the position he has,
   in the path, and get both directions.
   
=> there are two parts to the threat:
 - get traffic: mobility doesn't make a major difference (see previous
   messages about this point) and the counter-measure is to use IPsec
   (efficient both with and without mobility).
 - redirect traffic to a victim: this is new and there is no proposed
   defense against it, just some ideas to limit the effect.

   given this and the fact that it's a given and well known fact that 
   mobile ip doens't supply you with integrety I think that it will rather 
   confuse than enlight people to start recommending ipsec becuase of these 
   extensions.

=> I disagree: to recommend IPsec as a way to improve security is IMHO
a typical "security consideration". Only valid objections should be in
the wording.

   It will just raise new issues adn new questions. Is it the 
   control messages that should be ipseced ? what ipsec, AH? Is it related 
   to port 443 ?
   
=> IPsec can't help to protect the CoA because the CoA is changed en route.
But this is a NAT traversal issue, the UDP tunneling by itself can be
made as secure as we'd like (so it should when security is needed).

   So yes, inform people of the new threats but I don't think we should 
   recomend ipsec as some kind of saviour.

=> IPsec is the proper answer to the fist part of the threat.

   Because it's not.

=> I disagree: we have only to explain IPsec can't help for the second
part of the threat.

   He could eavesdrop before and he could do it now.

=> as I've explained with mobility the possibilities of eavesdropping
are a bit different and we can't say today if these differences are
really minor or not. So we should explain the first part of the threat
even it is not very new.

   So ipsec is equally applicable to pure mobile ip and has very
   little to do with nat traversal extensions.

=> I disagree and don't forget this is for the "security considerations".

   And the dos case ipsec doesn't help at all.
   
=> unfortunately you are 100% right about this point.

Regards

[email-masked]

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 14 May 2002 15:28:19 -0500

and the draft's correct name is
draft-ietf-mobileip-nat-traversal-02.txt

of this thread, right? not draft-levkowetz-mobileip-nat-tunnel-00.txt 
which does not exist.

Milind Kulkarni wrote:

>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
>
>"Madhavi W. Chandra" wrote:
>
>>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
>>
>>On Fri, Apr 26, 2002 at 02:02:29PM +0200, Francis Dupont wrote:
>>
>>>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
>>>

-- 
Behcet