Subject: Re: [mobile-ip] Mobile Routers support without optimization

From: James Kempf <[email-masked]>
Date: Tue, 21 Aug 2001 10:28:39 -0700 (PDT)

Alex,

I think you are missing Erik's point.

The issue is independent of whether the CN knows the subnet relationship
between MN, HA, and MR. The issue is whether the CN can authenticate
that the MR is authorized to route the prefix. It is impossible
to verify this by an exchange between the CN, MR, and HA without
some kind of out-of-band exchange of security material, or a
trust relationship that taps into such an out-of-band exchange.

		jak

>To: [email-masked]
>Cc: [email-masked], James Kempf <[email-masked]>
>Subject: Re: [mobile-ip] Mobile Routers support without optimization
>From: Alexandru Petrescu <[email-masked]>
>Date: 21 Aug 2001 19:14:43 +0200
>User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103
>
>Erik Nordmark <[email-masked]> writes:
>> A provider might assign
>> 	10.1.0.0/16 to user A
>> 	10.2.0.0/16 to user B
>> 	10.3.0.0/16 to user A
>> 
>> This creates "holes" thus in your proposal this can be used by A to claim
>> the space assigned to B.
>
>Indeed.  Then let me refine my constraints: (1) HA and MR should match
>their first n bits and be different on bit n+1 and (2) MNN should
>longest match n+1 bits either with HA or with MR.  Thus CN can
>rightfuly believe a prefix at most /n+1.
>
>For the above case, if MR and HA are on 10.1/16 and MNN on 10.3/16
>then MR and HA would match on first 16 bits but MNN would not match
>that 16 bits.  Thus CN will not believe a claim on 10.2/15.
>
>For same case, if HA and MNN are on 10.1/16 and MR is on 10.3/16 then
>HA and MR would match the first 8 bits, MNN would match the 9 (n+1)
>bits but not longest (it has a longer match 16 with HA).  Thus CN will
>not believe a claim on 10.2/9.
>
>I think this can work.
>
>Alex
>

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Aug 2001 20:34:34 +0200

James Kempf <[email-masked]> writes:
> The issue is independent of whether the CN knows the subnet
> relationship between MN, HA, and MR.

I think that knowing the true MR's prefix by probing MR-HA-MNN does
say a lot about what that MR can claim.  Of course, "probing" will
probably contain keying material.

> The issue is whether the CN can authenticate that the MR is
> authorized to route the prefix.

In the above, you stress "route" or "prefix"?

> It is impossible to verify this by an exchange between the CN, MR,
> and HA without some kind of out-of-band exchange of security
> material, or a trust relationship that taps into such an out-of-band
> exchange.

Indeed, my "probing" is your "out-of-band".

I purposefully minimized it in order to avoid the tendency to put all
solutions into the hands of magic crypto.  There's also the
functional.

Alex

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Aug 2001 11:43:31 -0700 (PDT)

> probably contain keying material.

   The problem is that HA may not a) be trustworthy or
   b) authoratative. Assuming this knowledge is readily
   available anywhere (which I'm not sure), it needs to
   be from a trustworthy and authoratative source.

      Mike

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Aug 2001 20:58:49 +0200

>    be from a trustworthy and authoratative source.

   I was not saying neither that a) HA is
   trustworthy nor that b) authoritative.  I
   was saying that packets get routed to HA,
   as HA claims they are.  You can try to
   route packets to non-existing HA's and
   forge replies from somewhere else, and
   _this_ can be solved by putting keying
   material in the probes.

   Or you question that today's network
   routability can not be trusted?

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 22 Aug 2001 11:02:06 +0200

>    be from a trustworthy and authoratative source.

If you claim that HA can not be trusted, then this applies equally well
to mobile HOSTS, doesn't it ?  As far as standard MIPv6 for mobile HOSTS
is concerned, an implication of this statement is that solutions like
BAKE and cie wouldn't give much help for the authorization of the MH to
send a BU for its home address.  

Just trying to be consistent.
Thierry

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Aug 2001 07:38:59 -0700 (PDT)

> send a BU for its home address.  

   Assuming you are talking about stationary hosts behind
   a mobile router (?) (or even MN's), then sure it can't
   be trusted. It should be noted that "cannot be trusted"
   really has an implicit suffix of "in all cases". Indeed,
   if we can find something which is trustworthy
   and accurate in the proper context to give us a
   truthful answer to "is this BU legitimate" then 
   we've made some progress.

	 Mike

---

From: Mattias Pettersson <[email-masked]>
Date: Wed, 22 Aug 2001 17:04:43 +0200

> probably contain keying material.

A solution such as BAKE tries to prove authorization by "probing" the
return routability. The CN can check that the same MN is reachable both
by its CoA and home address.

It relies on the routing system to deliver packets to the MN's home
address. It is weak, since it is not using out-of-band signalling and is
exposed to some MitM attacks.

However, this method works for single addresses. But you don't do the
same for an entire prefix. You can't probe all (2^64) possible MNNs in a
single /64 claimed by a MR.

/Mattias