Subject: RE: [mobile-ip] Comments on Draft 16

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 2 Apr 2002 12:12:07 -0800

> 
> > => The problem is whether we can allow a node to reverse 
> tunnel to the 
> > HA, when using a site-local address as a home address, without 
> > authenticating the tunnel. The problem is not so much in 
> the reverse 
> > tunnelling part, but rather due to using a Site-local HoA, which
> > is most likely communicating with a Site-local address
> > within the home site. So by not authenticating the tunnel
> > we're allowing anyone to spoof the HoA and start sending 
> > messages to a server within the home site, that perhaps
> > is not meant to be reached from outside the site. 
> > Of course the question is, since the server's replies
> > will be sent to the MN, is this a problem? 
> > But independantly of that, if the tunnel is not
> > authenticated, an outsider is getting a hole
> > that he wouldn't normally get with standard IPv6
> > routers on the border of the site.
> 
> Hesham,
> 
> I don't think allowing reverse tunnels without IPsec 
> protection adds any new residual threats as long as the HA 
> verifies that packets contain an outer source = CoA and an 
> inner source = HoA (where there is a valid binding between 
> HoA and CoA).
> 
So the mipv6 draft does not mandate that the reverse tunnel
from MN to HA  be Ipsec protected. It is only the HA to MN
tunnel that is Ipsec protected. Could you clarify ?

Thanks
mohan

> For example, in the site-local case, if there is no internal 
> ingress filtering within a site then anybody could spoof 
> site-local source addresses without using MIPv6.
> 
> Did you mean "IPsec" when you said "authenticated" or did you 
> mean "verified"? (the term we used for HAO verification by CNs)
> 
>   Erik
> 
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 3 Apr 2002 14:55:33 +0200 (CEST)

> tunnel that is Ipsec protected. Could you clarify ?

It is only the HoT message that MUST/SHOULD be protected by ESP to
prevent attackers between the HA and MN from being able to
spoof BUs.

I think the way to make this fit with IPsec selectors in RFC 2401 is
to make all packets whose terminal payload is the MH protocol
be subject to ESP in both directions.

But that doesn't require data packets (TCP, UDP, whatever) to be
IPsec protected.

  Erik