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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Tue, 2 Oct 2001 11:25:49 +1000

> On Mon, 1 Oct 2001, Hesham Soliman (EPA) wrote:
> > > > >  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 ?
> > >
> > > 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.
> > >
> > 	=> No, according to the specs every node SHOULD do it. If
> > 	a router doesn't do it, it affects the (potentially thousands)
> > 	of CNs attached to it.
> > 	Anyway, making the routers do it will involve routers modifying
> > 	dst addresses, breaking e2e ...etc which in itself is not
> > 	very secure at all.
> 
> Tunneling.
> 
	=> I think you really need to work out the details if you simply
	want to tunnel to the default router. It'll be interesting 
	to see how you would:
	- Setup an SA with the default router
	- send BUs to it
	- Get it to intercept traffic and route it to the right destination
	Once you have a proposal for the above we can compare.

> > > > > 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 !
> > >
> > > 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.
> > >
> > 	=> IP address spoofing is not limited to the Home Address option
> > 	and can happen regardless, unless you have the right access
> > 	control mechanisms.
> 
> Without Home Address Option, the sender's ISP can perform ingress
> filtering thus preventing spoofing.  With HA Option, the validation is
> impossible (it would have to be done in every end node -- not a chance)
> with current mechanisms (HA Option should also be checked in ingress
> filtering).
> 
> So, _at least with current mechanisms for packet filtering_, Home Address
> Option poses a significant threat.
> 
> Of course, in practise, at least in IPv4, a lot of ISP's don't bother with
> ingress spoofing checks...
> 
> I'm thinking of writing a short I-D on additional requirements for IPv6
> packet filters/firewalls (home address option, routing headers, ...), I'll
> probably do this if there is interest on this and this hasn't already been
> tackled.
> 
	=> Sounds good.

> > > > >  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
> ?
> > >
> > > 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.
> > >
> > 	=> Why is managing an SA to a random router easier than a random
> > 	CN ? Just because there are less of them, it doesn't mean it's
> > 	easier. Also I don't think there will only be thousands of default
> > 	routers, probably much more like hundreds of thousands.
> 
> It need not be necessarily first-hop router.  You could get significant
> traffic optimization in most cases if it were 2nd or 3rd hop also.  And if
> two nodes are on the same link, there might be other mechanisms for
> optimization.
> 
	=> That's fine, if you have a proposal for the above points 
	please publish it so we can see how this would work.

	Hesham

---

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 2 Oct 2001 15:32:52 -0500

Using the SAs between existing autonomous systems solves the security
scalability problem of binding updates. i.e. chained trust. The border
routers act as trust brokers just as they do today for normal routing
updates.

-----Original Message-----
From: Hesham Soliman (EPA) [mailto:[email-masked]]
Sent: Monday, October 01, 2001 1:32 AM
To: 'Pekka Savola'
Cc: [email-masked]'
Subject: RE: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn
Disco very

> > >  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.
> > >
> > 	What about deployment issues, like .. every router has to have MIPv6
> > 	in it ?
> 
> 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

> I'm not sure how BU can be secured.
> 
	=> Even more so to an anycast address.

> 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.
> 
	=> Sure, and there is a lot less NATs as well, but they don't make 
	the Internet any more scalable than e2e communication.

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

> Current MIPv6 draft is long.  BU processing, after it is secured, takes a
> lot of that.
> 
	=> Yes but the goal was not to make the draft shorter. RFC2002 is
also
	long and it doesn't have route opt.

> > >  2) Reinstate FA's (e.g. by default all IPv6 routers that implement
> MIPv6)
> > > in the picture, or
> > >
> > 	=> 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

> 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.
> 
	=> Ok maybe a more detailed analysis would better illustrate the
validity of 
	this assumption.

> 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..
> 
	=> Yep - route opt is the problem. 

> > 	MIPv6 is having a key exchange problem primarily and people are
> > 	trying to solve it, that is not a reason to start changing
> > everything.
> 
> 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. 
> 
	=> The requirement is made based on the fact that there will be 
	some compromises. I believe our reference is the current IPv4
	Internet, which is by no means 100% secure.

	Hesham

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Wed, 3 Oct 2001 11:46:34 +1000

Glenn, 

I think this is a very dangerous assertion to make. You seem to imply 
that provided we have our own "secure/closed" ASs with a SG
on the edge, and provided that the edges trust each other, we'll be
ok. 
I don't think that's true.

> From:	Glenn Morrow [SMTP:[email-masked]]
> Sent:	Wednesday, 3 October 2001 6:33
> To:	[email-masked]
> From: Hesham Soliman (EPA) [ <mailto:[email-masked]>]