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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 15 Aug 2001 16:44:24 +0200

>  > > Actually Binding Updates for prefixes do not disable route optimization
>  > > feature. Clearly, the authorization process is trickier. It can however
>  > > be performed provided that it makes use of the knowledge the HA has
>  > > about the binding 'Mobile Prefix' / 'Mobile Router'. HA can then be
>  > > asked by the CN before CN updates its Binding Cache upon receiption of a
>  > > prefix BU.
>  > 
>  > I don't understand how the CN checking with the HA solves the trust issue
>  > for using BUs to redirect whole prefixes.
>  > 
>  > Example:  I run a MN and a HA . My MN sends a BU for a /3 to a CN
>  > the fact that my MN says "yes" when the CN asks if the binding is ok.
>  > 
>  > The redirection of a prefix must be related to the routing for that whole
>  > prefix going to the HA. In general you can't verify that this is the case
>  > for a prefix without actually sending packets to all IP addresses in the
>  > prefix and seeing that you get a response back from the HA.
> 
> In fact, it's not necessarily the HA. It's the
> topologically closest router to the CN which
> advertises that prefix. For a /3 (wow, where'd you
> get one of those??) that's probably going to be a
> core router which wants the Yea or Nay vote on
> that, not the HA or anything else.
> 
	=> I think the point is that you can really redirect a LOT of 
	traffic depnding on the length of the prefix that you choose to
	steal. This will probably not happen with a HA but when it 
	comes to the MN - CN it is very difficult to get that 
	to work. 

> Another thing to consider is that the HA can
> be evil and in collusion with the MR.
> 
	=> Yes that's the example that Erik gave above. Therefore
	a CN checking the authenticity of MR's BU on an entire
	prefix doesn't solve the problem for a prefix based BU.

	Hesham

>  > But, what problem are we really trying to solve by being able to send
>  > a BU for a whole prefix?
>  > This seems like optimizing something which is close to a non-problem.
> 
> Er, if I could smooth the triangular routing for,
> say, an aircraft carrier through it's MR's home
> agent, that sounds like a pretty big win to me.
> In fact, it's arguable that the larger the prefix,
> the larger the motivation to optimize (hence
> renumbering too.)
> 
> 			Mike

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 16 Aug 2001 17:09:50 +0200

> > Yes. Then, the conclusion would be that we should add something like the
> > following in the MIPv6 spec:
> > "MIPv6 is a solution to support mobile nodes.  It does not support nodes
> > behind a mobile router".  Dot.  I don't remember who, but someone said
> > that we have to insure that what is in the mipv6 draft does not pretend
> > to support mobile networks.  Then, mobile networks will be addressed in
> > an other spec.
> 
> If the WG decides to go that path, which is definitely an option,
> to be constitent with the above wording the WG needs to remove 
> the "R (Router)" bit from the binding update option.
> 
> If the WG instead likes to keep that bit the above note needs be written 
> to take into account that the R bit can be used to support some very 
> limited form of MRs.
> 
	=> Without having the prefix scoped BU to the HA, I don't really 
	see a lot of value for the R flag. In fact I never really understood
	what the intention was. So unless there is a meaning behind it
	I would ote for removng it, since we already had concensus on 
	removing the prefix based BU suboption. 

	Hesham

---

From: James Kempf <[email-masked]>
Date: Thu, 16 Aug 2001 10:19:54 -0700 (PDT)

I think it would be appropriate to remove the "R" bit. There are too
many issues involved in mobile routers that are not well understood.
If BUs ultimately turn out to be the right way to go to route optimize
for mobile routers, then we can rev the spec and add something to
support prefixes.

		jak
		
>Date: Thu, 16 Aug 2001 16:10:46 +0200 (CEST)
>From: Erik Nordmark <[email-masked]>
>Subject: Re: [mobile-ip] Mobile Routers support without optimization
>To: Thierry Ernst <[email-masked]>
>Cc: [email-masked]
>
>Just to be consistent,
>  Erik

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 17 Aug 2001 15:02:13 +0200

> > 
> > > In that case, as Mattias suggested, a NAT on the PAN side would work
> > > just fine (yes, I know NATs are evil, but they are a practical,
> > > short term solution that should be discussed).
> > 
> > Whoa - what a can of worms. Should we really dive into that one?
> 
> So you prefer this Mobile IPv6 can of worms instead? I wouldn't say we
> are completely clean here either... :)
> 
> We are a bit more end-to-end, but NAT has obviously been more deployed
> than Mobile IP and seems to be of some use at least.
> 
> Sorry for being ironical (or cynical). I don't support NAT, but it could
> solve a few things here:
>  - No complex trust model, the mobile network will look like a single
> MN.
>  - No additional support in CNs.
>  - No routing problems at home with other routers.
>  - As the mobile network is maybe very small, it will require little
> configuration.
>  - If the user wants e2e, he could use the MR.
> 
> Now, if mobile-ip was moderated, I would have been kicked off this list
> by now. ;) Should have use my hotmail account...
> 
	=> Is this the right Mattias ? :))

	I think we're discussing solutions under different assmptions. 
	I can understand the MR being used to upate the HA with 
	a prefix scoped BU, however I can not imagine how we could generically
	solve the authorisation problem if we consider route optimisation
	being initiated by the MR. So in my mind I always assume 
	that the CN operations are not affected. Ie. BU from the MR to the
	HA (prefix scoped) and e2e route opt. 
	If we want to to delegate route opt to the MR I think we should 
	start by solving the authorisation problem first. The routing problem
	will seem trivial after that IMHO.

	Hesham

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 17 Aug 2001 16:50:58 +0200 (CEST)

> Erik Nordmark <[email-masked]> writes:
> > The modifications to the RA (section 6.2) has a unrelated 'R' bit
> > which has nothing to do with the 'R' bit in the BU. 
> 
> I was thinking that HA should respond to RS's with R bit set if the MN
> is away and is a router.  That RA's R bit would come from R of binding
> cache.  It's not specified, but I thought that should be specified.

No, the RA should always have the R bit set to that other home agents
can discover the global address(es) of the sending HA.
This information is needed for the home agent discovery stuff - each
HA on the home subnet needs to know the IP addresses of the other HAs
since any HA might receive the anycast.

  Erik

---

From: James Kempf <[email-masked]>
Date: Fri, 17 Aug 2001 12:13:32 -0700 (PDT)

Alex,

>> There is a third solution which came out of your previous email,
>> namely that the mobile multihomed host/mobile router does route
>> optimization with the CN but the CN tunnels traffic for the PAN
>> subnet through the MMH/MR.
>
>Gee, I thought _you_ had this in mind when writing previous messages.
>
>Also, tunnelling could mean tunnelling, or routing heading?
>

The point is to defeat any ingress filtering on the visited subnet.
If ingress filtering is done on the destination address without
reference to the route headers, then it would have to be a full-fledged
tunnel. If the ingress filter checks the route headers before discarding
the packet, route headers can be used. Is this specified anywhere? I
imagine it is the kind of thing that might be left up to system
administrators as policy, but not sure.

The only question is whether there needs to be any change to the BU.
I don't think an 'R' flag is enough, and, besides, 
draft-ietf-mobileip-ipv6-13.txt reserves that only for HA BUs only. 
One would at least need both the MMH/MR's new CoA and the
subnet prefix of the subnet behind the MR. I suppose we could
define a prefix extension to the BU, which, when present, indicated
that all traffic to that prefix from CN would have to be tunnelled through
the MMH/MR's CoA.

The other question is, of course, security, but I don't see any
difference between this case and the case of a mobile host (again,
which is why calling it a MMH seems more to the point than
calling it a MR). The MMH is controls all the traffic going to
the leaf subnet.

		jak

---

From: James Kempf <[email-masked]>
Date: Fri, 17 Aug 2001 10:42:35 -0700 (PDT)

Hi Alex,

>The triangular routing would be eliminated by MR's telling CN's an
>association of the form (CoA of MR, MR-subnet prefix).  And not by
>telling CN's extrapolated associations like (CoP, Home Prefix).
>

I can't see how triangle routing to hosts behind the MR can
be eliminated unless their addresses are routable within the
visited subnet. Otherwise, the visited subnet will reject 
incoming packets because the destination address is not
topologically meaningful.

I suppose traffic to/from the CN from hosts on the mobile subnet could tunnel 
through the MR's CoA. That would avoid the CN having to send packets back 
through the home subnet, and vice versa, essentially quadrelateral
routing, which is what I mentioned in my response to Erik's message.

Was that what you were thinking of?

>As I see it, MR is not NAT because its subnet prefix is
>Internet-routable.  By "triangular routing", but still routable.
>
>Also, when CN has learned the MR CoA, it would send a packet to MNN by
>putting MR's CoA and MNN's address into a routing header and off it
>goes over the net, through MR and to MNN.  With a NAT you can't reach
>nodes behind it whatever you try.
>

OK, it does seem to be what you are thinking of! Yes, I agree that
a tunnel from CN through MR would allow route optimization and
thus eliminate quadrilaterial routing. A NAT would avoid the
tunnel, but I think a tunnel is a small price to pay in this case.

It sounds to me like we may be converging on an acceptable solution
for this very specific, limited problem of MR (which I think
is more like a mobile multihomed host). 

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 19 Aug 2001 11:41:42 +0200

> > > I'm not sure how easy this will be since it's used in the binding
> > > cache too and from there into the modified Router Advertisement.
> > > 
> > 	=> Which router advertisement ? I think you're talking about 
> > 	a different R bit maybe ?
> 
> Yes, I was talking about a different R bit.
> 
> Fact is that there are 4 R bits: in BU, in proxy NA, in modified RA
> and in binding cache.  The R's in BU and binding cache are related to
> R in proxy NA and to R in RA.  While the R in proxy NA comes only from
> the R in binding cache, the R in RA can come from other places.
> 
> Thus I think the R bits in BU and binding cache could be removed.
> 
> I was tempted to suggest removal of R from modified RA but that is
> also used for building home agent lists and something else.
> 
	=> I'm getting the list's emails in a strange order but I saw that Erik had
	already replied to this issue.

> Also, I'm wondering if it's good to suggest "removal" or it's better
> to copy paste it into a new draft and polish that draft.
> 
	=> well that implies the removal from the MIPv6 draft anyway. 
	The point is, it's not clear to me what it does in the BU. 
	So putting it in another draft is ok once we know what 
	to do with it. I assume the "other" drat would be addressing 
	a solution for Mobile networks so we can decide whether
	the R flag is appropriate or something else. 

	Having it in the MIPv6 draft at the moment seems superfluous.

	Hesham

---

From: James Kempf <[email-masked]>
Date: Mon, 20 Aug 2001 14:12:14 -0700 (PDT)

>> The only issue is that if the BGP routes are aggregated,
>> the MR's prefix won't show up in the CN AS routing
>> tables, though some superprefix will. If as per my
>> followup message to Erik, one constrains the MR subnet
>> prefix to be a subprefix of the HA 's prefix, and the HA prefix
>> to be a subprefix of a prefix in the BGP routing tables,
>> then would that be enough to let the CN validate?
>
>How about an example where this breaks.
>At home I have a small subnet from my ISP (a /48 with IPv6).
>The ISP advertises a large chunk (because it is a large ISP)
>so it might be a /19 that is visible in BGP.
>
>I then have a /64 for e.g. my PAN carved out from from my /64.
>
>Then it seems like, even given the BGP information, a CN could pontentially
>think my MR has authority to express binding for the whole /19 that the ISP
>advertises in BGP.
>

OK, good point. The only thing one can tell from the BGP tables is
that the ISP is allowed to route the /19. It's not possible to
tell whether the MR is allowed to route the whole thing or
just a subset, so it could lie and hijack the whole thing.

So, basically, I'll fall back on my assertion that there is no way
for the CN to authenticate that a MR or HA are allowed to route
a particular prefix without some out of band authentication mechanism.

		jak

---

From: James Kempf <[email-masked]>
Date: Tue, 21 Aug 2001 11:40:33 -0700 (PDT)

>
>> 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"?
>

One issue is whether the CN is allowed to route at all, the other
is whether it is allowed to route the prefix. Answering the second
answers the first, and the second question is the one that
is of relevance here.

		jak

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Tue, 21 Aug 2001 14:57:04 -0500

Folks,

Just want to remind everyone that while the topic of Mobile routers is
interesting, there are other more pressing WG items that need to be
resolved and completed before we can take on this subject and develop
any solutions. So while the mailing list is buzzing with activity, there
is
no real progress being made in terms of what the WG is chartered to
do and accomplish in the near term.

-Basavaraj

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 22 Aug 2001 15:49:37 -0500

Would not the trust relationship between the HA and the CN is analogous to a
router which delivers a packet on the last hop to another non mobile node?
Doesn't the inherent trust relationship (of the IP routers) that the packet
sent to an IP address, the home address, will be delivered to the correct
network, guard sufficiently against this percieved HA, MN collusion threat?

If not, then I guess we can't trust these last hop routers either for even
non-mobile cases and we would have to use AH on every packet send from any
source to any destination? It seems to me that to question whether the HA
can be trusted is to question if any router can be trusted.

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 11:39 AM
To: [email-masked]
Subject: Re: [mobile-ip] Mobile Routers support without optimization

James Kempf writes:
 > Thierry,
 > 
 > >>    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.
 > >
 > >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.
 > 
 > Maybe I'm missing something, but doesn't the MN have a security
 > association with it's HA? So the MN can trust it's HA. The issue
 > here is whether the CN can trust the HA, and without a similar
 > security association, I think Michael's point is correct.

   Ah. Yes, just because I trust my home agent doesn't
   mean that everybody should trust my home agent. The
   home agent *may* be trustable, but if the CN doesn't
   have any way to differentiate trustworthy ones from
   untrustworthy ones, it doesn't do it much good, and
   must therefore assume it is not trustworthy either.

   What may work here is a UN Security Council like
   approach here where the routers in the path between
   CN and HA inclusive all have absolute veto power
   over any proposal. Only by running this gauntlet
   can any request be accepted.

	   Mike

---

From: James Kempf <[email-masked]>
Date: Wed, 22 Aug 2001 14:28:11 -0700 (PDT)

Glenn,

The issue is that the HA is not required to participate in any
standard routing update protocol, so the CN cannot have confidence
that it is authorized to distribute routing information. Telling
the CN that an MN had the right to route a prefix is essentially
distributing routing information.

		jak

>From: "Glenn Morrow" <[email-masked]>
>Subject: RE: [mobile-ip] Mobile Routers support without optimization
>Date: Wed, 22 Aug 2001 15:49:37 -0500
>