Subject: RE: [mobile-ip] Routing header Vs tunneling

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 10 Dec 2001 11:35:03 -0600

GM] Comments in-line below.

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Saturday, December 08, 2001 5:46 PM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: [email-masked]
> Subject: RE: [mobile-ip] Routing header Vs tunneling
> 
> 
> Glenn,
> 
> > That said - what is the use of sending the extra addresses 
> in each packet at
> > all since per-address authorization state must be kept on the tunnel
> > endpoints in order to protect against the reflector attacks?
> 
> Are you suggesting sending packets with just two IP addresses 
> and having the
> endpoint replace the source IP and destination IP based on 
> what it has in
> the binding cache entry?

GM] Yes

> 
> I think such an approach has some robustness problems.

GM] I think it is no less robust than what would have to occur even if we
did send the extra address - but I am certainly open to an attempt to find
some sort of stateless argument for why the extra address needs to be there.
I just don't see it if the reflector attack is mandated to be prevented.

>  - What happens if the MN moves away and other MN appears and 
> acquires the same
>    CoA?

GM]The new mobile would have a new home address which could be used to
distinguish the two. The home address would have had to be conveyed via some
signaling i.e. something like a binding update and the cache maintained.
This signaling needs to be authorized and authenticated in order to protect
against a mobile binding another mobile's home address to a particular COA.

 If there is a stale binding cache entry  for the CoA->old HoA
>    in some CN there will be TCP checksum failures should the 
> new MN/HoA try to
>    communicate with it since it will use the old CoA->HoA mapping.

GM]If there is no cache entry that is valid the packets should be dropped
and perhaps an ICMP error message sent to notify the sender (MN's COA) that
they need to refresh. 

>  - What if a MN wants to have one session (e.g. TCP or VoIP) 
>    with a CN using route optimization and another session  
> (e.g. DNS udp
> lookup)
>    not using route optimization. That CN would not be able to 
> tell whether
>    to apply the address replacement - the source address 
> would be the CoA
>    in both cases.

GM] Why would the mobile not want to use route optimization? I don't see why
a mobile would not want to use route optimization with every node if it were
available (ubiquitous). 

> 
> And I can't even imagine what the security issues would be in 
> such a case.

GM] As far as I can tell, the security issues are exactly the same
irrespective of whether the extra address is sent. The statement doesn't
detail any specific issue - by all means, please do.

> So I think having all packets contain all the necessary IP 
> addresses makes
> sense.

GM] I have to say I am not that optimistic of such a thing gaining wide
acceptance any time soon; however, the protections necessary against
reflector attack with route optimized MIP makes sending the extra address,
useless. If you protect against the reflector, then you have conveyed the
addresses to each side with credentials for authentication and authorization
and the CN is already having to check against DDoS based upon some table.
This information has to be stored in a table unless you want to have to
authenticate and authorize on each bearer packet. 

GM] I think we have already seen some discussion on the IPv6 WG list about
the cache etc.. It does seem that people are beginning to see the point -
but I must say this would be a serious leep of faith. Just keep asking
yourself what will have to be done with the packet when there is no cache
entry - i.e. even if the home address is conveyed in the packet.

GM] Earlier I tried to make the point that if MIP is required to deal with
the reflector attack, then you might as well require that the CN's do route
optimization because the same state will have to be kept on the CN - might
as well go for the gusto. The people making micro cameras and toasters with
IP stacks started freaking out on this though. They want the small cheap
footprint. 

GM] This frustrated me to no end and so now I think we might need to start
looking at having the routers close to the CN's do some of these functions
but gee - I can only imagine the reaction I'll get from that suggestion from
the end to enders. This isn't exactly a new idea, though. Even the first
renditions of MIPv6 had such thoughts in it. We also have GES, TUBA, 8+8,
LAR, MBG, etc.. that explored this concept, although many of these solutions
had the tunneling overhead as well. Putting the cache on the CN was easier
from a signaling semantics point of view because it basically results in a
point to point problem set as apposed to a subnet to subnet problem set.
This is why I think the placement of the route optimization functions on the
routers close to the CN's was discounted in favor of the easier problem set.

GM] Route optimized MIPv6 is turning into a bunch of catch-22's (footprint
vs security). I think route optimization should be ubiquitous irrespective
of the choice of where to put the cache entries. Moore's law should
eventually handle the footprint and economics of microcameras and toasters
etc.. Each time the requirements of nodes for route optimization is relaxed
the specification is complicated and the code size on the mobile goes up
because it has to deal with backoff procedures.

GM]I hum for a MUST on the CN binding update requirement or start having the
WG look at mandating the cache on the routers close to the CNs. I don't
think the footprint and cost people can start complaining about having a
MUST for routers. Whatever the choice I have a strong belief that route
optimization should be ubiquitous, deployable and backed up by MUSTs in the
specs.

GM]One thing is for sure, though. The layer-5 signaling-based node mobility
solutions gain in credibility each day the MIP spec is debated over and
incomplete. It is hard to tell who on the receiver list is FUDing and who is
not. I certainly don't believe you (Erik) are one of the FUD people. 

GM]I mentioned a little timer earlier on the list related to competition
from these layer-5 solutions. The timer has expired for some operators. BTW,
last time I checked on these layer-5 signaled solutions, they don't need
tunnel overhead either. But see - they are layer-5 signaling and it's O.K.
to make a "pseudo-connection" i.e. install and maintain some state. It is
the same thing -  these solutions use IP stack mobility shims and swap the
addresses at the endpoints. 

Regards,

Glenn

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 10 Dec 2001 10:06:57 -0800

> > > endpoints in order to protect against the reflector attacks?

I didn't think that this conclusion had been drawn.
The reflector attack under discussion doesn't seem
to be a horrible problem to me, and it's no worse than
what can be done today wthout any Home Address
destination option.

However, I still can agree that keeping extra state as
you mention will enable protection against the problem
anyway.  I just didn't think that it had been agreed as
a mandated part of a solution.

> > endpoint replace the source IP and destination IP based on

I don't think this is a good idea, unless there is some extra
information in the two-address header that says it is O.K. to
do the replacement.

Currently, it is possible for a mobile node to use both its
home address and its care-of address for communications
with correspondent nodes.  This might well be useful for
two different data applications between the same two nodes.
I think we should try to maintain the usefulness of the care-of
address as a legitimate IPv6 address for applications that,
for whatever reason, do not need mobility support.  Maybe
SMS would be like that, if every "session" only lasted for
a single packet.  But presumably "more" applications would
use the home address in preference to the care-of address
as the IP(v6) address identifying the application endpoint.

Regards,
Charlie P.

---

From: Steve Deering <[email-masked]>
Date: Mon, 10 Dec 2001 10:18:12 -0800

At 11:35 AM -0600 12/10/01, Glenn Morrow wrote:
>GM] Why would the mobile not want to use route optimization?

For privacy reasons, the owner of the mobile device may not wish to reveal
it's current location in the network to its correspondent(s).

Steve