Subject: identity in binding updates

From: Michael Thomas <[email-masked]>
Date: Tue, 13 Feb 2001 15:04:18 -0800 (PST)

[please keep me on the reply-to line as I'm
 still not subscribed to mip]

The current ip6 version of mobility allows the MN
to cause a routing table change to be made at CN
and HA by use of a Binding Update destination
option. There are somewhat analogous things that
happen ip4, so this discussion is relevant there
too, but I wanted to put it into v6 terms to
illustrate the problem.

Because of the significant denial of service
attack possible, the binding updates must be
cryptograpically secured to make certain that they
arrive from an authenticated and authorized
source. While I readily see how IPsec provides
authentication for the BU's, what seems to be
missing -- and maybe I've just not looked in the
right place which is quite possible -- is any
reference to how the HA/CN _authorizes_ an
incoming binding update: just because I can
authenticate as [email-masked] doesn't mean that I
should be allowed to send a binding update for a
subnet that I don't own. Like, say, 127.0.0.0/8
just for fun.

The seeming implication to my poor head is that
there needs to be a binding between an identity
and the subnet(s) that that identity is allowed to
make routing updates for. Or maybe even that the
actual identity is, in fact, the subnet itself.

I think this issue is compounded when you consider
mobile routers. In the normal IP model, hosts and
routers always implicitly delegate routing update
responsibility/authority to their downstream
containing subnet owner. Also: the non mobile
assumption is that routing adjacencies have static
pairwise trust arrangements.

Mobile IP, and especially mobile routers, turns
that assumption on its head: the routing
adjacencies are dynamic and as a consequence the
trust arrangement must be as well. Also, it
doesn't seem entirely clear what the semantics are
for the necessary binding updates from a mobile
router -- I'm assuming that the BU's ought to come
from the mobile router instead of the host behind
the mobile router, which seems to imply that you
need to have scoping on the identities (eg, the
identity would need to incorporate the subnet mask
too).

Has there been any work on this? The global
implications here seem pretty far reaching, but
I don't see how you can just handwave it away.

	Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Feb 2001 09:49:52 -0800 (PST)

Vijay Devarapalli writes:
 > The HA and MN are assumed to share a security 
 > association with which the HA can authenticate
 > a BU sent by the MN. this security association is
 > static and can be set up when the MN is at home.

   This begs the question of authorization which
   was the essence of my question.

 > This is one of the basic fundamentals of the 
 > mobile IPv6 draft. I advise you to do some reading,
 > before shooting off questions.

   Likewise.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Feb 2001 09:45:29 -0800 (PST)

[FYI: I think that you need to edit the mobile-ip@marvin... 
 to standards.nortelnetworks.com or it will bounce. :( ]

Steve Deering writes:
 > At 3:04 PM -0800 2/13/01, Michael Thomas wrote:
 > >While I readily see how IPsec provides
 > >subnet that I don't own.
 > Mike,
 > In the mobile host (as opposed to mobile router) case, the binding
 > update is for a single address, not a subnet.  The binding update is
 > authenticated as coming from the host with the claimed home address,
 > and the implicit assumption is that that host is authorized to
 > redirect its own traffic anywhere it wants.  As an old-fashioned
 > end-to-endian, I think that's a defensible assumption.

   My contention here is that it is just a subset of the
   larger problem of address ownership. Clearly saying I
   own/control ::1.2.3.4 can be equally written as ::1.2.3.4/128.
   It therefore follows that something ought to be able
   to own/control ::1.2.3.0/120, etc. 
   
 > You may have a good point with respect to mobile subnets, but even
 > there one could imagine the authentication confirming that the sender
 > of the binding update legitimately owns the subnet prefix, and
 > therefore is entitled to redirect its traffic.  

   Correct. Hence why I say that /128 is just a subset
   of a larger dynamic routing update problem across
   non-local adjacencies where you can't rely on peerwise
   trust arrangements (and the implicit reliance on
   transitive trust).

> IPv6 has the notion
 > of a "subnet-router anycast address", which is assigned to every
 > router attached to the subnet.  (It's just the subnet prefix followed
 > by an all-zeros interface ID.)  Perhaps the security association on
 > which the authentication is based could use that anycast address,
 > rather than an individual address of the router (though I suspect
 > that there are problems with using anycast addresses for SAs...)
 
   I don't think the problem lies in the IP
   domain, but in the address namespace ownership
   domain. At some level, there needs to be someone(s) who
   is the ultimate authority on address delegations
   and specifically who controls the owners of
   those address delegations. Note well, that just
   like now that does not necessarily imply a flat namespace.

   For example, say in real life ARIN delegates
   ::1.2.0.0/112 to UUnet. UUnet in turn delegates
   ::1.2.1.0/120 to mtcc.com, and mtcc.com
   delegates ::1.2.1.0/124 to hq.mtcc.com and
   ::1.2.1.16/124 to corpjet.mtcc.com. 
   corpjet.mtcc.com in turn delegates
   ::1.2.1.17/128 to ipbar.corpjet.mtcc.com,
   :1.2.1.16/125 to ar1.corpjet.mtcc.com,
   and ::1.2.1.24/125 to ar2.corpjet.mtcc.com
   At some level, there needs to be a way for
   both ipbar.corpjet.mtcc.com *and*
   corpjet.mtcc.com to have the ability to
   change their CoA to meet the needs of 
   their independent mobility. In the one
   case, it's corpjet moving through the 
   sky, in the second case, it's ipbar moving
   through the cabin to my seat to get me a
   smart cocktail. 

   These cases all need to be handled, and
   poor CN needs to understand that it's OK
   for corpjet to change its CoA, and that
   in turn its OK for ipbar to change its
   CoA address to eliminate the dog leg 
   through its home agent (hopefully somewhere
   on corpjet or this is *really* wacky :-)

   For the trust relationships, one way to solve
   these kinds of problems is positing the Mythical
   Global PKI with a single root without local
   subdelegation, but I doubt that that will work
   in practice (demonstrably). The IP way of
   dealing this is to introduce hierarchy, either
   of the offline kind (CA hierarchy) or an online
   scheme (kerberos-like), or a combination of
   both (my personal fave).

   [so have I just convinced everybody that this
    is an impossible problem?]

 > Of course, there are still lots of open questions about how SAs
 > themselves get established, in the general case.

   Well, we do have IKE, and KINK is coming. These
   kinds of problems are not any easier there
   though (seemingly).

		Mike