Subject: [mobile-ip] RE: Mobile IP Fast Handover Architecture

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 8 Nov 2002 13:54:58 +0100

> 
  > The architectural issue with this is the same as I've had 
  > for the last two
  > years: latency and congestion in the AR to MAP connection. 
  > If I want to deploy a
  > MAP to cover all of France for good location privacy, then 
  > it may add an
  > addition 20-60 ms onto the handover, and maybe that squared 
  > to the jitter around
  > handover. By handling the handover locally and in a 
  > distributed fashion, this
  > can be reduced to zero, even for anticipated/prereg, if the 
  > prehandover
  > signaling is not interrupted.

=> I think that you're always making an assumption that 
you want to trade off latency for better location
privacy. I will continue to assert that this assumption
is not the main goal of HMIPv6. for instance, if you want to give
location privacy for the whole of France and your HA
is in France, then just use the HA. The MAP is intended
for "local" mobility management. Sure "local" is loosely
defined, but a network designer will have to trade-off some
features for others. The same will go for FMIPv6. The distance
between the ARs is unknown. So the delays and packet reordering
may be a problem if the distance is too large. Of course you will 
need to trade-off, there is no one solution that fixes everything.
It seems like you're making a trade-off decision in favour of 
location privacy (which is fine) but trying to generalise that for 
the use of HMIPv6.

  > 20-60 ms may not sound like a lot 

=> It's a very long way on a wired network using modern
routers.

  > With regard to smoothing, bicasting may work, but I've yet 
  > to see a definitive
  > study that it won't cause problems with TCP traffic, though 
  > there have been lots
  > of arguments here for and against.

=> How about:

http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/index.html

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-alg-06.txt

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-01.txt

There are more papers on this if you're interested.

One thing that was never discussed, is that if the host
receives packets out of order, this will also cause
dup acks causing the CN to get into Fast retransmit
and congestion avoidance. This is what bicasting was 
accused of, but it will happen without bicasting as 
soon as the MN performs RO and the traffic is switched
to the new path. This is one of the negative impacts of 
anchoring the traffic at the old AR.

 Buffering for smoothing 
  > really doesn't work
  > well for real time traffic, since if the latency becomes 
  > too large, "ringing"
  > occurs.

=> Right.

  > It will if you replace the BU by an RS to new AR with old 
  > CoA and old AR IP
  > address, then have new AR signal the tunnel. ND security 
  > can be used on the
  > RS/RA, no need for a new SA for the BU. The MN has to get 
  > auth'ed on the new AP
  > anyway prior to or just after Layer 2 association, probably 
  > by some Layer 2
  > mechanism but possibly by PANA or Seamoby/IAPP CT of auth info.

=> You're replacing the BU with RS, I don't understand
how this helps. Why can you secure the RS but not the 
BU? 
_Anything_ that can secure an RS will also work
for the BU to the oAR.

  > APIs, in general, are hard to standarize because vendors 
  > use them to strategic
  > advantage. 

=> We seem to be doing well enough with the sockets API.

Protocols are easy, because customers demand 
  > interoperability and
  > won't buy products that don't exhibit it. An API that works 
  > on Vendor L's OS is
  > not likely to be of interest to Vendor M, though the wire 
  > protocol will allow
  > the two to talk.
  > 
  > As for working with IEEE, I think this would be an 
  > excellent idea, we should try
  > to figure out how do to do this. Perhaps we could do a BAR 
  > BOF in Atlanta on it,
  > or maybe even get the WG chairs to put it on the agenda. :-)

=> Great, a bar bof sounds good.

  > 
  > They are visible through handover (IAPP) and through AAA.
                             
=> Not to the host's IP layer. 

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 09:26:21 -0800

> location privacy (which is fine) but trying to generalise that for

The problem is the following. I can think of an alternate way to optimize
handover, namely use FMIPv6. It requires modifications to the access routers,
but how many MIPv6 access routers are currently deployed? We've implented draft
03, including interoperability, and we know it works, and works well.

I can't think of an alternate way to achieve location privacy without modifying
some or all the routers in the local routing domain, and some network operators
may not want to use special routers. Since there are already IPv6 routers
deployed (though not many), I tend to trade the optimization aspects of HMIPv6
away because I view the location privacy aspects as more valuable.

There are still questions of scalability and deployability around FMIP and HMIP,
of course.

> => It's a very long way on a wired network using modern

Depends on the load, both on the MAP and the network.

> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-01.txt

I'll check them out. I'm interested in actual measurments.

> anchoring the traffic at the old AR.

I'm not convinced of this, but we will certainly look into this on our test bed.

> _Anything_ that can secure an RS will also work

What is the return address of the BU if the MN doesn't have a new CoA because,
like 802.11, it was not able to do prehandover signaling or the prehandover
signaling gets cut off? It can't be the old CoA because the new AR has never
seen that address and its ingress filter will drop the packet. The current draft
also requires the new AR address be carried in an AltCoA option, but the base
MIPv6 draft requires RR with an altCoA. Why should the MN have to do that? What
should the MAC address be on the BU if the MN didn't get any prehandover
signaling like in 802.11 or the prehandover signaling got cut off, and it didn't
have access to CAR discovery? The MN only knows the MAC address of the AP, not
the AR. In the end, the MN is going to have to do the RS/RA to get the MAC
address of the router, if for no other reason, why not use that to start the
tunnel? It also gives the MN a jump start in configuring its CoA if it was
unable to do anticipated CoA configuration.

The MN must undergo some kind of security/auth association before it gets up on
the new access point anyway.
In 802.11, this is either the 802.11 Authorization.Requst/Reply sequence or
802.1x (actually, both). In other protocols, it is the same. Ultimately, we
might be able to get Seamoby CT working to provide this, or IAPP as well. The MN
must authenticate the AP, and the AP must authenticate the MN.

> => We seem to be doing well enough with the sockets API.

The standard is being written, we will see whether the vendors implement it as
written. Are there plans to do code portability tests, to make sure that every
vendor's implementation follows the API? That is what helps enforce
interoperability among wire protocols.

> => Not to the host's IP layer.

Neither is a COPS server distributing routing policy to routers, or an AAA-F
server running Diameter back to the home network.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 8 Nov 2002 12:34:23 -0800

> unable to do anticipated CoA configuration.

It's not a good idea to overload router discovery to perform binding
updates.
We should stick with BU and its variants to allow updating binding cache
on nodes. This is an architecturally clean approach, as opposed to
overloading
another set of signals to do the same (e.g., L2 triggers, router discovery).

> server running Diameter back to the home network.

Access Points, as they are currently used, have a different face
depending on where you are looking from.

A wireless client doesn't identify the AP as an IP-enabled entity.
From its perspective, it's just a L2 bridge.

An access router identifies the AP as an IP-enabled entity. It's
still a bridge, but also a host. AP is used as NAS, and also needs
to be remotely configured, etc. They even run web servers.

Of course, the wireless client could really ping the AP if it wanted to.
But it doesn't care...

alper

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 13:46:43 -0800

> another set of signals to do the same (e.g., L2 triggers, router discovery).

A Binding Update says that the address of the node has changed. At the point
where the tunnel to a MN has to be made, the address hasn't changed. The MN is
still using the old CoA. The new CoA isn't valid until it has completed RO. So
in addition to all the practical problems, a Binding Update isn't the
semantically correct message.

What RS/RA is doing in this case is telling the new router to change the routing
to the old address so it now comes on the new link.

> A wireless client doesn't identify the AP as an IP-enabled entity.

My point was, neither does a wireless (or wired for that matter) client have to
identify a Diameter server as an IP entity. But the Diameter server uses IP for
various purposes that are architecturally part of an IP network. So, too, does
an AP.

If IETF would finally recognize an AP as an IP entity, an L2 triggers protocol
would have a proper architectural place. At the moment, it is hard to justify.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 8 Nov 2002 14:56:37 -0800

> where the tunnel to a MN has to be made, the address hasn't changed.

As far as oldAR is concerned, it has. Now "oldCoA" is "bound to" a
care-of address, which is "newAR". oldAR, which is acting as a home agent
to "oldCoA" does not care if this care-of address is really configured
on the MN. This is all Mobile IP, no need to invent new things here.

> The MN is

So, what does exactly this "change the routing" mean? I bet it means
"MN sends an RS to newAR, so that newAR sends an HI to oldAR, and now
oldAR updates its binding cache". OK, now we just added "HI" as another
signal to update a binding cache :(

> would have a proper architectural place. At the moment, it is hard to
justify.

AP concept is not as new... BAS (broadband access server) does the same.
There is a collection of protocols defined for BAS to communicate with
first hop router/network (ISP backend). L2TP, AAA, COPS, etc....

alper

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 11:29:03 -0800

> on the MN. This is all Mobile IP, no need to invent new things here.

In my view, it is Mobile IP that has invented something new. Routing came before
Mobile IP. I see this as a host now having a new router without changing its
address. RFC 2461 has support for this if the router finds out first (ICMP
Redirect) but not if the host does. What I'm proposing is a way to do this when
the host finds out first.

I think it would be a major mistake to apply a concept, namely binding update,
that is specific to solving the disaggregation of the routing identifier and the
node identifier to changing the routing identifier. Binding update is used at
the home agent and the correspondent node for this purpose.

So we clearly have an disagreement about what the proper architectural
perspective is on this problem.

> signal to update a binding cache :(

No, not its binding cache. A binding cache is maintained by a home agent and
correspondent node, not an access router. It is used to maintain the mapping
between the node identifier and the routing identifier.

The old access router inserts a source route pointing at a tunnel interface to
the new router for the old CoA.

            jak

---

From: Pete McCann <[email-masked]>
Date: Mon, 11 Nov 2002 14:15:55 -0600

Hi, James,

 > the new router for the old CoA.

Did you mean "host route"?

What if a correspondent node on the old link wants to send a packet to
PCoA?  Let's say it participated in return routability and has
route-optimized the path to MN.  Normally it would have used neighbor
discovery to find the link-layer address of the on-link MN.  Now that
the MN has moved, doesn't the CN's neighbor cache need updating?  Isn't
this what proxy neighbor advertisements do in Mobile IPv6?  Don't you
think the old AR would need to do something like this, as well as
respond to future neighbor discovery queries on behalf of the MN?

That seems like more than just a host route to a tunnel interface, but
it seems like exactly the kind of thing a Home Agent does.

-Pete

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 11 Nov 2002 12:51:04 -0800

> the host finds out first.

It's much more than that. Fundamental difference is that, two routers are
not
on the same link, so it's beyond simple "ICMP redirect" issue.

> correspondent node, not an access router.

(we discussed this before) one can put home agent functionality on a
access router. Just like putting a dhcp server, NAS, L2TP server on a
access router...."home agent" and "access router" terms are not exclusive.

> It is used to maintain the mapping

It needs to be more than that. See Pete's response. It requires a good
subset
of home agent functionality.

alper

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 13:23:22 -0800

Pete,

Yes, I meant host route, sorry.

Yes, the old router would need to do more, as you indicate.

My fundamental points are:

  - that we need to be clear about what mechanisms are used to support what
architectural processes. Binding update is currently used to support changes to
the mapping between routing identifier and node identifier. We should not
overload this by also using it to support changing the routing to an existing
routing identifier.

   - that we need to be clear about the trust relationships involved. A trust
relationship should exist between a host and its router, and between two
routers, but I can't see any reason why a trust relationship should exist
between a host and a router that the host, sometime, in the past, had visited.
Operationally, the host will need to establish its credentials to get on the new
link anyway, so I don't agree with the assumption that the host will have a
stronger trust relationship with the old router, in fact, I believe once it is
off the link the old router won't have much reason to trust the host (for
example, the host's credentials might have timed out).

I think having the tunnel initiated by an RS to new AR, then HI/HAck new AR to
old AR, should cover these two points. I suppose we could also look into
extending ICMP Redirect to allow the mobile node to redirect its own traffic,
but using the RS/RA also lets the mobile node start CoA configuration if it so
chooses (it may not).

            jak

----- Original Message -----
From: "Pete McCann" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Alper E. YEGIN" <[email-masked]>; "Hesham Soliman (EAB)"
<[email-masked]>; "Karim El-Malki (EAB)"
<[email-masked]>; <[email-masked]>
Sent: Monday, November 11, 2002 12:15 PM
Subject: Re: [mobile-ip] Re: Mobile IP Fast Handover Architecture

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 13:44:18 -0800

Alper,

We clearly have a disagreement about the proper architecture for routing
identifier to node identifier mapping updates v.s. routing changes.

            jak

----- Original Message -----
From: "Alper E. YEGIN" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Hesham Soliman (EAB)"
<[email-masked]>; "'Pete McCann'" <[email-masked]>; "Karim
El-Malki (EAB)" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 11, 2002 12:51 PM
Subject: Re: [mobile-ip] Re: Mobile IP Fast Handover Architecture

---

From: Pete McCann <[email-masked]>
Date: Mon, 11 Nov 2002 16:35:39 -0600

Hi, James,

 > overload this by also using it to support changing the routing to an existing

The distinction you are making between node identifier and routing
identifier seems pretty arbitrary.  In the basic (no mobility) IPv6
model all addresses are attached to some interface.  A CoA, in the
normal v6 addressing architecture, is just another address that is
attached to an interface.

It seems very natural to apply the mobility mechanism recursively, and
yes, in your terminology that would mean splitting a routing
identifier into a "node" part (the old CoA) and a "routing" part (the
new CoA or AR's address).

 > example, the host's credentials might have timed out).

Operationally, the host will have needed to establish its credentials
to get on the old link anyway (back when it was there), so it seems
very natural to keep the security association around for a while.
This is the least-energy thing to do, and doesn't require any
pre-handover (or on-critical-path) signaling, unlike the security
association with the new AR.

Security associations are indexed by IP addresses, so it is perfectly
legal for a node to have SAs with hosts arbitrarily far away on the
Internet.  The lifetime of the SA with the old AR should be for
however long the MN is using the services of PCoA, which includes the
time when it is using it "remotely" from the new AR.  Otherwise, we
should just garbage collect the PCoA and assign it to someone else.

 > but using the RS/RA also lets the mobile node start CoA configuration if it so

The choice of which particular message acts to carry out the packet
redirection and tunnel establishment also seems somewhat arbitrary.
A BU-style message seems the most obvious to me.

-Pete

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 13:44:18 -0800

Alper,

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 06:48:29 -0800

> attached to an interface.

I don't see it as arbitrary, I see it as pretty fundamental to the Mobile IP
architecture. If IP did not have the property of aliasing the node and routing
identifier, Mobile IP would be quite different. HIP, for example, uses a
separate node identifier that never changes sent in a special Layer 3.5. The
architecture of HIP is quite different as a consequence. The only reason it
looks the same in Mobile IP is because both the node identifier and the routing
identifier are IP addresses, but this is just an implementation matter.

> new CoA or AR's address).

I don't agree. The old CoA is used for routing, it is never used as a node
identifier to find a new node. The home address is for this purpose. A
correspondent uses the home address to find a mobile node, not the current CoA.
There cannot be two node identifiers, the old CoA and the home address.

> association with the new AR.

The new link should not let the mobile node on unless the mobile node can prove
that it is authorized for service. The new router should not accept any traffic
from the mobile node unless it can provide the right security credentials.
Otherwise, there is a security hole, no matter how short the grace period
provided. An attacker could use this grace period by sequentially switching IP
addresses to propagate a longer attack.

The problem with 802.11 currently is that it does not correctly allocate AAA
between IP and link layer, so that an expensive protocol (802.1x) is required on
every handover, potentially. It need not be this way. The actual handover
protocol could be much simpler, and thus not pose a major bottleneck in
handover.  But 802.11 does require this, so as far as FMIP and 802.11 is
concerned, if 802.11 requires 802.1x on every handover anyway, there is little
point not utilizing the new authorization.

> Internet.

But the details of the special SPI needed for Neighbor Discovery security might
only be acceptable for on-link nodes. This is currently a topic for discussion
in the SEND working group.

> The lifetime of the SA with the old AR should be for

We're working on the details of this problem in SEND right now. It is not clear
how this will work out, but a time based security association is one way to
achieve some entropy without alot of network traffic, to prevent replay attacks.
If the time runs out while the MN is undergoing handover, it would have to
re-establish the security association. Whereas, it has just established a fresh
security association with the new AR as a result of the handover, so why not use
it?

> A BU-style message seems the most obvious to me.

I don't think it is arbitrary. It has architectural implications, as mentioned
above. It also has practical implications, as I've mentioned in other email on
this list. Both implications seem to make RS/RA more obvious to me. I don't
think we have to use BU just because it was used in MIPv4 for FPCoA.

            jak

---

From: Pete McCann <[email-masked]>
Date: Tue, 12 Nov 2002 14:17:24 -0600

Hi, James,

James Kempf writes:
 > > identifier seems pretty arbitrary.

 > identifier are IP addresses, but this is just an implementation matter.

One of the requirements of Mobile IP is to support existing non-mobile
aware applications on IP devices.  Those applications use IP addresses
as identifiers---it's just a fact of life.  HIP would require a bump
in the stack on every device on the Internet before it can be deployed
successfully.  Even then there would be some porting problems for
existing applications.  "If IP did not have the property..." is an
unrealistic hypothesis that changes the requirements for Mobile IP.

We could get into a theoretical discussion of naming, and perhaps even
debate the finer points of pi-calculus, but I really don't think
that's necessary.  I think most people understand what is going on
here when a mobile node acquires a new CoA.

 > There cannot be two node identifiers, the old CoA and the home address.

So call it two routing identifiers if you want - but the old AR is
doing a little more than just routing, as you agreed.

Note that I could also implement an HA as a "routing table connected
to tunnel interfaces" if I so desired.  However, I'd need also to
implement the proxy neighbor advertisements and to ensure that all the
routing updates are secure.

 > addresses to propagate a longer attack.

I agree.

 > point not utilizing the new authorization.

Yes, I think the IEEE has some work to do in this area.

 > in the SEND working group.

I don't know if SEND is the answer - perhaps the SA is part of the
output of running PANA or a fast-handover version thereof.

 > security association with the new AR as a result of the handover, so why not use

Sure, it should be a time-based security association with refreshes.
It would seem to me quite unlikely that the timeout would coincide
with handover.  In any case, it seems like the (temporary) owner of
PCoA should be responsible for redirecting packets, so even if RS/RA
is the trigger, there should be some information element contained
therein which is a cryptographically authenticated request, verifiable
by old AR, to change the routing for PCoA and to start the proxy
neighbor advertisements.

 > think we have to use BU just because it was used in MIPv4 for FPCoA.

Well, I still think it's arbitrary, but by definition that means I
don't have a strong preference either way. :)  So whatever the WG
consensus is I could live with it.

-Pete

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 06:48:29 -0800

jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 11 Nov 2002 12:51:04 -0800

alper

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 13:44:18 -0800

Alper,

            jak

---

From: Pete McCann <[email-masked]>
Date: Mon, 11 Nov 2002 14:15:55 -0600

Hi, James,

-Pete

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 13:23:22 -0800

Pete,

            jak

---

From: Pete McCann <[email-masked]>
Date: Tue, 12 Nov 2002 14:17:24 -0600

Hi, James,

I agree.

-Pete

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 13 Nov 2002 10:37:29 -0800

> routing updates are secure.

I think this is one of the key issues: the previous AR is not only redirecting
traffic, but also defending the previous CoA. It might be obvious to note that
the only use of ND to defend someone else's address today is for Mobile IP..
And, it might be equally obvious to note that Mobile IP is the only protocol
that allows route updates by a host. In that regard, it is not like traditional
route updates using routing algorithms at all. Yet another obvious thing is
that routing algorithms don't care whether you encapsulate or not; that's a
forwarding issue based on some other criterion, such as a Mobile IP binding
cache, or the result of some tunneling protocol.
So, yes, there is route update, not the traditional route update however. In
addition, there are few other things which look lot like Mobile IP operations
(encapsulation, defending an address when the host is off-link, etc.). This
may be one good reason to do this work in Mobile-IP WG .

My 2 cents,

-Rajeev

> consensus is I could live with it.

ps. I also don't care what the name of the message is.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 13 Nov 2002 10:55:37 -0800

> may be one good reason to do this work in Mobile-IP WG .

Exactly. This is nothing other than our good-old (now homeless) "forwarding
from previous care-of address" method. which is basically Mobile IP. Why
invent a
new thing in the "Mobile IP WG" while reasonable extensions to Mobile IP can
do
the job.

alper