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

From: [email-masked]
Date: Mon, 20 Aug 2001 21:04:31 +0200 (MEST)

[manually reposting, mail system is down until tomorrow, sorry for duplicates]

Erik:
> Are you assuming that any CN would (for instance) accept a BU for a /64 prefix
> from anybody? How can the CN verify the authority for such a BU?

What I'm having in mind is very simple and probably too dumb to be considered
as a "prefix authorization solution".

Basically, the CN can send packets to MR's Home Address and to MNN's
Home Address.  Those can only be routed to the right addresses.  If those
two addresses are required (imposed) to be: matching the first 64 bits
and differring at the 65th then the CN can conclude that the maximum
prefix it can trust for this MR is the respective /65.

[email-masked] (please put this in replies, thanks)

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Aug 2001 23:10:22 +0200 (CEST)

> as a "prefix authorization solution". > 

This seems to be erring in allowing updates for too short prefixes
in certain cases.

So if the MR and MNN are from different parts of the space (the train model
as opposed to the PAN model) then MR's home address could be
1234:5:6:7:<something>
and the MNN is 
8999:5:6:7:<something else>
then the addresses differ in the first bit.
Hence by the above rules the MR should be able to send a BU for /0!

What did I get wrong?

  Erik

---

From: "John Leser" <[email-masked]>
Date: Mon, 20 Aug 2001 21:52:01 -0400

Hi folks,

Just to throw some more fuel on the fire, I question the value of allowing
an MR to bind anything other than /128 with a CN.

As an alternative, let's say the MR, when it detects that an MNN is
communicating with some CN, sends a BU just for that MNN's address to the
CN.  In effect, it sends a normal BU on behalf of the MNN, but using the
MR's COA.  The obvious downside is that when multiple MNNs are communicating
with the same CN, more BUs will be sent.  (One BU per MNN, per CN, rather
than just one per CN).   The two upsides are that CN binding cache lookup
remains simple (exact address match), and that BU authentication isn't any
harder than it is in the non-router case (MR must have whatever credentials
needed to bind each MNN's address, just as it would for its own address).

The MR would still bind prefixes with its home agent, which is much easier,
assuming we expect the HA to have been preconfigured with the prefixes to
expect from each MR.  This is the expectation, as I've gathered from
discussion on this list.

-John

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 21 Aug 2001 08:51:23 +0200

> expect from each MR.  This is the expectation, as I've gathered from
Hi John,

This is exactly my position too.

/Mattias

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Aug 2001 11:42:51 +0200

> Hence by the above rules the MR should be able to send a BU for /0!

Yes, that is correct.  Numero uno: this boils down to decide if we put
a requirement on a moving network to accept or not the visits of other
moving networks or of other mobile nodes.  Let's decide.

Numero due: similarly to the requirement on MR's home address and
MNN's home address, another can be put between MR's HA address, MR's
Home Address and MNN's home address.  This could solve the case you
mention above.

Note that in the example you give above, I presume that PAN visits
train.  In that case, CN will probe different HA's (train MR's and PAN
MR's), thus my tests would work.

I need to know, if we talk only PAN case, is it possible to impose
such a restriction (MR's home address and MNN's home address fit on
claimed prefix -1)?

Alex

---

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

> Home Address and MNN's home address.  This could solve the case you

This "delta" thing between addresses will probably allow an attacker
to falsely claim a whole prefix when all he has is in fact some
addresses of that prefix.

This however leads to the question: "could a provider assign a prefix
(except 2 addresses) to somebody and the 2 addresses to somebody
else?"

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Aug 2001 15:38:44 +0200 (CEST)

> moving networks or of other mobile nodes.  Let's decide.

I don't think it matters what we decide on that one.

The key thing is that we need rules that the CN can use to do 
authorization checks.
Those rules better not be circumventable by having any subset
of HA, MR, and MNN conspire to fool the CN.

Or stated differently, given that the CN doesn't trust anything
but the ability of the routing system to deliver packets, on a best
effort basis, to the destination IP address, how can the CN develop any
trust in a remote entity stating that it should receive packets for
a whole prefix?

I don't see how techniques like SUCV can help here - they inherently bind
a key to a single IP address and I don't even think it is meaningful to
bind a key to a prefix.

> Home Address and MNN's home address.  This could solve the case you

The CN would still need to trust untrustworthy entities.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Aug 2001 15:53:37 +0200 (CEST)

> (except 2 addresses) to somebody and the 2 addresses to somebody

[Using IPv4 prefixes since they are shorter than IPv6 - and net 10
to avoid pointing any assigned IP address space.]

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.

  Erik

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 21 Aug 2001 17:28:42 +0200

John Leser wrote:
> than just one per CN).   

We thought about that in the first place. I think that such solution
would lead to flooding the network with BUs.  All your family is in the
same car and each member has a session with grand-ma.  Why would all
members send a BU to grand-ma when you could aggregate it ? 
Prefix-scope BUs leaves room for more optimizations.

> The two upsides are that CN binding cache lookup

I disagree. Authentication is not an upside. A node should not be
allowed to send a BU 'on behalf' of another node.  Here, it's not a
matter of authorization, but a matter of authentication.  Are you
willing the MR to authenticate on behalf of yourself ?   I am not sure
the MR has whatever credentials for this,  particularly if the MNN is a
VMN, nor that it would be such a good idea.You are in a flight, would
you allow the aircraft company to authenticate on-behalf of you ?  I can
imagine transient issues.  

In the prefix-scope BU proposal, the BU is sent by the MR and the MR is
authenticated as being the one it claims to be.   Whether or not MR has
the right to advertise the BU is an authorization issue, not
authentication issue.  I would prefer this scenario.  

BTW, couldn't we rely on certificates to authorize a MR to send a BU for
a prefix /p ?  I am not a securiry guy, then this might not make sense,
but no one gave my a no-reply to this when I first mentioned it.

Thierry.

--
* mailto:[email-masked]  Tel +33 (0) 4 76 61 52 69 
* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52) 
* and MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete/people/ernst/Welcome.html

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Aug 2001 17:45:54 +0200

Thierry Ernst <[email-masked]> writes:

[...]

> but no one gave my a no-reply to this when I first mentioned it.

Thierry, d'après ma compréhension, quand les gens disent
"certificates" alors c'est du pulbic-key infrastructure...

Mais je ne sais pas sûr...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Aug 2001 17:55:22 +0200

> Mais je ne sais pas sûr...

Sorry for that message, it should have been To: Thierry only.  It says
that probably "certificates" are related to PKI.

Alex

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Aug 2001 08:56:51 -0700 (PDT)

> Prefix-scope BUs leaves room for more optimizations.

Keeping the end nodes as ignorant as possible of
routing is certainly a worthwhile goal, but I'm
not convinced that it should be the prime
requirement. Recall that this problem is also
related to network renumbering so at some level
the MN is going to need to integrate its mobility
with network renumbering anyway.

 > imagine transient issues.  

If you consider it, this is exactly what the
relationship between a router and host/router is:
the host delegates responsibility for the packet's
fate to the next router, and so on. This is, I
think, the root of why this is so difficult. In
the current net the trust is built by localized
decisions where the objects which need to trust
each other are usually well known to each other.
Once you bring in any form of tunnel (which route
optimization is) you break the localization
property unless you can somehow find a way to
leverage the current transitive trust model.

 > but no one gave my a no-reply to this when I first mentioned it.

This runs afoul of the same need-a-global-PKI
problem that sent MIPv6 back to the WG to figure
something else out. Considering the likelihood of
very small MR's (your car MR, for example), any
certificate based solution would run into the same
objections.

		Mike

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Aug 2001 19:14:43 +0200

> This creates "holes" thus in your proposal this can be used by A to claim

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:01:42 +0200

Erik Nordmark <[email-masked]> writes:
> authorization checks.  Those rules better not be circumventable by
> having any subset of HA, MR, and MNN conspire to fool the CN.

Very nice wording.  I have sent two constraints in a previous email, I
need example cases to test them against, and this takes time.

> Or stated differently, given that the CN doesn't trust anything but
> the ability of the routing system to deliver packets, on a best
> effort basis, to the destination IP address, how can the CN develop
> any trust in a remote entity stating that it should receive packets
> for a whole prefix?

Wow, sounds like a real challenge.

> I don't see how techniques like SUCV can help here - they inherently
> bind a key to a single IP address and I don't even think it is
> meaningful to bind a key to a prefix.

One can deduce the longest prefix of two addresses from the two
addresses.  A prefix draft would keep that: deduce the longest key of
the prefix from the keys of the two addresses.  So that we can route
acording to keys, not to prefixes :-)

Alex

---

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

> This creates "holes" thus in your proposal this can be used by A to claim

   What this says is that the router(s) which summarizes this
   route (say 10.0.0.0/14) is the one that knows that A claiming
   10.0.0.0/15 (or less) is bogus. 

   Yes?

		   Mike

---

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

>    10.0.0.0/15 (or less) is bogus.

Also, the router that routes 10.1.0.0/16 and 10.3.0./16 to HA knows
that it doesn't route 10.2.0.0/16 to HA.  Thus it can do ingress
filtering on replies from HA to CN probes.  But probably ingress
filtering should not be required.

Alex

---

From: "John Leser" <[email-masked]>
Date: Wed, 22 Aug 2001 11:20:01 -0400

:-----Original Message-----
:From: [email-masked]
:[mailto:[email-masked]]On Behalf Of Thierry Ernst
:Sent: Tuesday, August 21, 2001 11:29 AM
:To: [email-masked]
:Subject: Re: [mobile-ip] Mobile Router Route Optimization
:
:
:John Leser wrote:
:>
:> Hi folks,
:>
:> Just to throw some more fuel on the fire, I question the value
:of allowing
:> an MR to bind anything other than /128 with a CN.
:>
:> As an alternative, let's say the MR, when it detects that an MNN is
:> communicating with some CN, sends a BU just for that MNN's address to the
:> CN.  In effect, it sends a normal BU on behalf of the MNN, but using the
:> MR's COA.  The obvious downside is that when multiple MNNs are
:communicating
:> with the same CN, more BUs will be sent.  (One BU per MNN, per CN, rather
:> than just one per CN).
:
:We thought about that in the first place. I think that such solution
:would lead to flooding the network with BUs.  All your family is in the
:same car and each member has a session with grand-ma.  Why would all
:members send a BU to grand-ma when you could aggregate it ?
:Prefix-scope BUs leaves room for more optimizations.
:
I agree that this is the biggest drawback of handing the BU's this way.
However, there are several drawbacks to the prefix scope BUs.
- They require a longest prefix match lookup, rather then an exact match
lookup in the binding cache on the part of the CN.  Exact match can be
linear on the number of entries in the binding cache, while prefix match
cannot (please correct me if I'm wrong)  If we could predict the future, it
would be easy to see which way this CPU vs. memory tradeoff should go.
Right now, I have no idea.  But, grandma will likely have at least as much
or more TCP or application state as BU state per session.
- They require more trust on the part of the CN to accept the BU.  Of
course, since many of the security issues are somewhat unresolved in the
general senses, I am making an something of an assumption here.

So, if every one tries to opens session with grandma at the same time, is it
better to a.) flood a bunch of single address BUs, or b.) to send a single
prefix BU's, that gets rejected because grandma (or rather, whoever wrote
grandma's IPv6 stack) was afraid of unforeseen security exploits with prefix
BU's, and all packets take a triangular route.

So, in a sense, my argument against the prefix BU is that while it is
superior in the example you gave, it has a more damaging worst case
scenario.

Another possibility is to allow both, but only allow the prefix BU when
strong authentication/authorization is available.  One situation where all
MNNs may have sessions with a single CN is DNS.  Since your DNS is likely to
share in whatever PKI your ISP or organization sets up, it's much easier to
securely set up a prefix-BU.

:> The two upsides are that CN binding cache lookup
:> remains simple (exact address match), and that BU authentication
:isn't any
:> harder than it is in the non-router case (MR must have whatever
:credentials
:> needed to bind each MNN's address, just as it would for its own address).
:
:I disagree. Authentication is not an upside. A node should not be
:allowed to send a BU 'on behalf' of another node.  Here, it's not a
:matter of authorization, but a matter of authentication.  Are you
:willing the MR to authenticate on behalf of yourself ?   I am not sure
:the MR has whatever credentials for this,  particularly if the MNN is a
:VMN, nor that it would be such a good idea.You are in a flight, would
:you allow the aircraft company to authenticate on-behalf of you ?  I can
:imagine transient issues.
:
:In the prefix-scope BU proposal, the BU is sent by the MR and the MR is
:authenticated as being the one it claims to be.   Wether or not MR has
:the right to advertise the BU is an authorization issue, not
:authentication issue.  I would prefer this scenario.
:
:BTW, couldn't we rely on certificates to authorize a MR to send a BU for
:a prefix /p ?  I am not a securiry guy, then this might not make sense,
:but no one gave my a no-reply to this when I first mentioned it.
:
You are correct - I should have said authorization is easier.  But I must
disagree with your reasoning that the MR should not be able to send BU's on
behalf of another node.  Any node behind a router places this kind of trust
in its router - after all, any intermediate router between two nodes can
easily hijack a session.

My reasoning for why authorization is easier is a bit harder to show.  It
really depends on what method (beside strong PKI based methods) is used to
authorize bindings.  I was under the impression, based discussion on this
list, that part of the problem with authorizing prefix BU's was the fact
that the HA can't know for sure whether a certain prefix length is OK for
the MR to bind with an arbitrary CN.  Not using prefix-BUs gets around this.

:
:> The MR would still bind prefixes with its home agent, which is
:much easier,
:> assuming we expect the HA to have been preconfigured with the prefixes to
:> expect from each MR.  This is the expectation, as I've gathered from
:> discussion on this list.
:>
:> -John
:
:--
:* mailto:[email-masked]  Tel +33 (0) 4 76 61 52 69
:* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52)
:* and MOTOROLA Labs Paris
:* http://www.inrialpes.fr/planete/people/ernst/Welcome.html

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Aug 2001 09:33:32 +0200 (CEST)

>    10.0.0.0/15 (or less) is bogus. 

Yes.

Of course, it needs to be able to understand the identities "A" and "B"
in order to answer that question. This might be easy of A and B are IP address
*from the same prefix*. I don't know what trouble multiple global IPv6 
prefixes per subnet will add :-)

   Erik