Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Disco very

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Mon, 1 Oct 2001 14:13:19 +1000

>  1) MN's would send BU's to CN's first-hop routers (e.g. subnet-router
> anycast address); this might scale better especially if IPv6 end-nodes are
> supposed to be simple.
> 
	=> Do you have any idea about how you can secure this BU ?
	Why is this simpler than sendingit to the CN ?
	What about deployment issues, like .. every router has to have MIPv6
	in it ?

> Does anyone really believe that a washing machine, connected to an
> Intranet using IPv6, MUST be able to process e.g. Home Address Destination
> option, or SHOULD be able to process Binding Updates?, or
> 
	=> MUST. It's not that difficult really is it ? Especially if it can
do 
	IPsec !

>  2) Reinstate FA's (e.g. by default all IPv6 routers that implement MIPv6)
> in the picture, or
> 
>  3) Never mind route optimization, always tunnel back to HA
> 
	=> Hmmmm .... could you give reasons for why this is better ? 

	MIPv6 is having a key exchange problem primarily and people are 
	trying to solve it, that is not a reason to start changing
everything.

	Hesham

---

From: Pekka Savola <[email-masked]>
Date: Mon, 1 Oct 2001 09:17:50 +0300 (EEST)

> 	What about deployment issues, like .. every router has to have MIPv6

According to the specs, every IPv6 must be able to do most of these things
anyway, so requiring routers should be able to do this does not seem like
a too big additional requirement.

I'm not sure how BU can be secured.

Why I thought it's simpler is simply because there are about two orders of
magnitude less first-hop routers than hosts.  Which is still a lot, of
course.

> 	=> MUST. It's not that difficult really is it ? Especially if it can do
> 	IPsec !

The simple processing of e.g. Home Address Option is easy.  But if you
want to do it securely, it might get a lot more complicated.

Current MIPv6 draft is long.  BU processing, after it is secured, takes a
lot of that.

> 	=> Hmmmm .... could you give reasons for why this is better ?

2) For example, if there would be 1000 FA's in the world (found e.g. with
anycast), the routes would be reasonably optimized, and ~1000 would still
be a reasonable order of magnitude to manage security associations.

The traffic could be sent using tunneling between CN -> "FA1" -> "FA2" ->
MN.

I've not analyzed in detail whether this would actually help (can MN/CN
trust FA's?), but if one brought the number of mobility management nodes
to much lower rate, one _might_ be able to assume something about the key
management.

What I'm thinking is like current "6to4 router" [RFC3056] approach.

3) is better (in some aspects) because CN's always send through the HA.
This is a corner-case of mobilility.  You basically need only some basic
framework and a tunnel.  Very simple to implement, and to get secure
because HA-MN can be assumed to have some trust relation.  Only major
problem is the route optimization..

> 	trying to solve it, that is not a reason to start changing

Of course not, in itself, but consider:  the key exchange problem creates
a very difficult set requirements.  In the end, it is probably impossible
to fulfill these without compromises. (Otherwise people would have
deployed world-wide PKI already!). If you can, great.  But if not, some
functionality (e.g. CN processing of BU's in general case) might have to
go.  If this would be the case, one could wonder whether one would need
the functionality in the basic draft then at all, whether the basic draft
could be made much simpler than it is now.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords