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

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 11 Dec 2001 09:54:49 -0600

Erik,

Comments labeled GM2] below: 
 
> > >  - 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.
> 
> Yes, but that home address would not be contained in the packet.
> So when the CN receives a packet from a CoA how can it tell that
> the CoA->HoA mapping has changed?
> 

GM2] See the next sentence. You have to authorize the redirection if you are
going to mandate the reflector check. So let me put it this way. If the HAO
is there in every packet, you still have to have something extra i.e. some
sort of credentials, cookie or digest in some sort of signaling to allow the
CN to verify that the MN is on the level during a handoff. I.e. you do need
the home address on this signaling exchange. The HOA is redundant on
subsequent bearer packets between the MN and CN. If route optimization is
being done then the routing header containing the home address is also
redundant.

> > 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.
> 
> Yes, but who would do this binding update when?
> The old "owner" of the CoA might have just walked out of radio range.
> The new "owner" of the CoA doesn't know which CNs might have 
> a binding cache
> entry.
> 
> BTW: I think it would be useful for you to work out the 
> details perhaps 
> as a short I-D.

GM2] It is on the way but I think some people understand this already. If
someone can find a way to do the reflector check in a stateless manner, then
my point becomes invalid; however, I don't know if this is possible. I
certainly have an open mind, though. BTW, which security signaling mechanism
do you think I use in describing the approach? I am kind of faced with
chicken before the egg problem.

> 
> 
> > 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). 
> 
> Limited resources - e.g. limited memory for the binding update list
> or wanting to limit the total amount of bandwidth or CPU spent on
> the binding update protocol.

GM2] Aaah, I think that if the reflector check is mandated this will result
in the mobile having to keep state and maintaining the state with the CN via
refreshes etc.. So, I guess what I'm saying is that the resources used would
be the same on the MN, as well; irrespective of the tunneling method used.
> 
> > > 
> > > 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.
> 
> I'll do that once there is a complete proposal I can read.
>
 
GM2] Will do.

> 
> 
> > 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. 
> 
> Thanks for the confidence.
> I'm am seriously concerned that we need the right security 
> requirements
> for MIPv6 to avoid creating a new tool for DDoS attacks but I 
> do realize
> that I am on a bit of thin ice since, even without MIPv6, there isn't
> a chosen path or paths for tracing back DoS attacks. So there isn't
> a very well known idea of what it means to not make it harder 
> to deal with
> DDoS.
>  
>    Erik
> 

GM2] You have hit the nail right on the head. I think you doing the right
thing but I must say that the right thing needs to be done to IPv6 itself. I
know this may not be your responsibility but nevertheless, there are massive
gaping DDoS holes in IPv6. The fixes for these holes are not backed up by
MUSTs either. Actually some of the fixes aren't even described in IETF
documentation. This is a reverberation about Charlie's point about being
singled out. Pekka has at least tried to point some of the IPv6 holes out in
his ID. For instance compare the DDoS holes in stateless autoconfiguration
with the reflector problem of MIPv6. It seems to me that stateless
autoconfiguration wouldd not have become an RFC under the same scrutiny.
Anyway, sorry about the micro-rant on the "justice due". Your ice is quite
solid, though. You are doing the right thing. I just wish the other groups
would think a bit more about DDoS and put mandates in to protect against it
with the same vigor i.e. do the right thing.

Thanks,

Glenn

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Dec 2001 19:35:01 +0200

Glenn Morrow wrote:

> GM2] You have hit the nail right on the head. I think you doing the 
> right thing but I must say that the right thing needs to be done to IPv6 
> itself. I know this may not be your responsibility but nevertheless, 
> there are massive gaping DDoS holes in IPv6. The fixes for these holes 

Very much agreed.

> are not backed up by MUSTs either. Actually some of the fixes aren't 
> even described in IETF documentation. This is a reverberation about 
> Charlie's point about being singled out. Pekka has at least tried to 
> point some of the IPv6 holes out in his ID. For instance compare the 
> DDoS holes in stateless autoconfiguration with the reflector problem of 
> MIPv6. It seems to me that stateless autoconfiguration wouldd not have 
> become an RFC under the same scrutiny. Anyway, sorry about the 

There could still be differences in the seriousness of attacks.
In your particular example, I'm not sure autoconfiguration has
similar global problems as MIPv6 has; the autoconfiguration procedures
are full of holes but can we launch attacks against some non-local
parties through them in an easy way while at the same time escaping
to be located?

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 18:53:58 +0100 (CET)

> autoconfiguration wouldd not have become an RFC under the same scrutiny.

Some people feel that RFC 2461 and RFC 2462 should not be draft standards
since there was no interoperability testing of the suggested security mechanism
(use IPsec). This is a case where we learn as we go along. I think that
earlier it was viewed that limiting the threats to attackers on the same link
was good enough protection.

There are known holes (some documented in existing RFCs)
limited to a single link (neighbor discovery and stateless addrconf).
And the tunneling in RFC 2473 is silent on threats related to
blindly decapsulating received packets.

What other security holes are you aware of?

  Erik