Subject: RE: [mobile-ip] draft-ietf-mobileip-nat-traversal-02.txt security

From: "Sami Vaarala" <[email-masked]>
Date: Wed, 15 May 2002 10:22:32 +0300

.. and what's more, about a different draft:

   draft-ietf-mobileip-nat-traversal-02.txt

;)

-Sami

> -----Original Message-----
> From: Sami Vaarala
> Sent: 15 May 2002 10:19
> To: Behcet Sarikaya; [email-masked]
> Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-02.txt
> security
> 
> Hi,
> 
> You're right, this is about -02.
> 
> -Sami
> 
> > -----Original Message-----
> > From: Behcet Sarikaya [mailto:[email-masked]]
> > Sent: 14 May 2002 23:28
> > To: [email-masked]
> > Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt
> > security
> >
> > 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
> > >>>
> > >>>[email-masked]
> > >>>
> >
> > --
> > Behcet
> >
> >
>