Subject: Re: [mobile-ip] Draft on Mobile IP Architecture and Reorg

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 3 Mar 2003 13:51:17 +0900

Dear James

Thanks for helpful jobs. Here are some of my comments.

For me, the separation between local and global routing is not clear. 
I have some guesses but can't be sure that I grasp it correctly. Is it 
only the matter of scale? It will be useful if you show that they have 
different requirements and functionality as OSPF and BGP do. 

In 3.0 [Page 2]

>   Mobile IP has received much less attention, until very recently. The 
>   local routing problem consists of two parts: 
>    
>  1) The need for a mechanism by which the Mobile Node obtains a new 
>     care of address on a new link,  

In Fast Handover draft, there are three phases of mobility operation, 
movement detection, IP address configuration and location update phases. 
Does '1)' include both 'Movement Detection' and 'IP configuration'. How 
about separate it into two problems like below

1) The need for a mechanism by which the Mobile Node detects its 
   movement to a new link.

2) The need for a mechanism by which the Mobile Node obtains a new 
   care of address on a new link,
  
>  2) The need for a mechanism to temporarily repair the local routing 
>     failure due to a switch in link prior to the change in global 
>     routing at the Home Agent (and, in route optimized, Mobile IPv6 
>     Correspondent Nodes) taking place. 
 
What is the definition of local route repair? As before, I have some guesses 
about its meaning but can't be sure that my understanding is correct. 
Does it only mean the tunnel between old AR and new AR?

It seems that HMIPv6 doesn't do local route repair because it takes time 
to send BU to MAP. Then does it mean that local route repair should happen 
instantly when route failure occurs? Is it possible for us to repair route failure 
without taking some time?   

In 4.2 [Page 5]

>   switch happens too late. Preconfiguration with local route repair 
>   performs better, but when the preconfiguration signaling is also 
>   tightly coupled with handover, the signaling can occasionally be 
>   disrupted by the handover causing the handover to fail over to 
>   standard Mobile IP on-link configuration after the Mobile Node has 
>   performed the link switch [18]. 

What does it mean that 'Preconfiguration signaling is tightly coupled with 
handover'. That I can only guess. :-) And the above paragraph is also not 
easy to understand neither.  

>   the Mobile IP 
>   Working Group might want to consider setting up a separate working 
>   group specifically to address local link mobility. 

Currently there is a suggestion to divide mobileip WG into two WGs, 
MIPv4 and MIPv6. And you suggest an another separate WG specializing
in local link mobility. So does it mean there be three WGs?

---

From: "James Kempf" <[email-masked]>
Date: Mon, 3 Mar 2003 09:48:05 -0800

Rajeev,

> >
> > >     However, a key question is whether you have a security
> > >     association with your router. If you do, I don't see why you
> > >     could not use it regardless of where you are.
> > >
> >
> > I'm assuming we are talking about IPsec security associations, yes? That is
to
> > say, an entry in the node's and router's SPD and SAD.
> >
> > The security assocation may only be valid for nodes on the local link. In
> > principle, there is no reason why a node needs to have any other kind of
> > security association with a random last hop router, or am I missing
something?
> >
>
> So, in principle, there is no reason _not_ have an SA for the router's
> global address if an SA can be established at all in the first place, right ?
>

The scope of the address isn't the point (if you are keeping score, score one
for you :-). The point is whether the host is on link or not. ND requires
participants to set the TTL to 255 to detect whether a message was sent from off
link. In addition to limiting traffic, this ensures that some random attacker
from the other side of the Internet can't send traffic as if it were on the
link. While the same effect can be accomplished by cryptographic protection on
the packet, cryptographic protection is much more expensive to check, leaving
the router open to a cycle DoS attack. With a TTL check, the node can quickly
see whether the TTL is 255 and discard the packet if not. After the TTL check is
passed, the router proceeds to the more laborious cryptographic check.

A design that allows a host to send an FBU from another router is unable to
provide this fast, basic kind of security. It is dependent on the cryptographic
protection, and hence open to the cycle DoS attack, or requires a protocol like
RR that lengthens the handover time. RR is necessary across the Internet, or
course, but it isn't necessary for the local link.

> > I'm not sure why you say that the MN is in charge of receiving its packets.
What
> > happens if the last hop router goes down and it is the only router on the
link?
> > It's a co-operative effort. I believe there is widespread confusion on the
> > application of the end to end principle to routing among people in the
Mobile IP
> > community, please see draft-iab-e2e-futures-01.txt for a short discussion of
how
> > end to end applies to mobility.
> >
>
> For that matter, _any_ router on the end-to-end path can go down.
> Are you extrapolating that BGP handles mobility ?
>

No, of course it doesn't, that's why Mobile IP is needed.
draft-ietf-mobileip-ipv6-21.txt handles global mobility. Even in that case, it
is a co-operative effort between the HA and the MN. If a failure in HA is
detected in the home network, the HA functionality must roll over to a new HA
quickly or the MN is left high and dry. The MN doesn't have to "authorize"
rolling over to the new HA if the IP address, IPsec SA, etc. are the same.

> I think there needs to be a distinction between the robustness
> of packet delivery (something a routing algorithm addresses) and
> movement of a node.
>

I don't understand your point.

> I think this is how packet delivery works and I suspect the host would expect
the
> router to provide robust packet delivery in the presence of faults. But I
didn't
> see that the
> IP address of the host changed in the above description.

Of course, but that is exactly the position the MN is in when the link switch
happens. The MN has switched without having changed its address, and now it must
change it, or, if preconfiguration has occured, it must complete the change. It
must go through DAD (or oDAD hopefully) to get the new address, send BUs to the
HA, CN, etc.

> It resembles, if you don't mind me saying it,"router portability",
> where an existing router gets replaced by a new one
> and the host continues to receive packets. I don't see how the MN itself
> exhibited "IP mobility", where the device actually changed subnets.
> I would agree with you if you point out that there is re-numbering involved.
>
> Is "robust packet delivery = mobility" ?
>

Well, I think what we are talking about for FMIP is robust packet delivery until
the mobility management on the new subnet is accomplished.

> It's one thing for a router to keep forwarding packets in the
> presence of faults without seeking authorization. It's something else
> to re-direct packets without the MN's asking. If I am receiving a call,
> I expect the call to be sent to me, despite the fact that the underlying
> system is subject to faults. And, if the underlying system is capable of
> that, I don't want that system to forward my calls elsewhere without
> my permission.
>

I disagree. As a service provider, I want to provide my customers with reliable,
secure, seamless packet delivery in the face of the routing disruptions caused
by handover. That's what FMIP is all about. Our experiments (references in the
draft) indicate this is possible with FMIP but it requires changes in the local
link protocol (RFC 2461) and changes in the current FMIP design.

This has nothing to do with calls, that's SIP. I agree that I wouldn't want
anyone to do a SIP REGISTER for me without checking with me first.

>
> Again, I think there is confusion between being able to deliver packets
> in the presence of faults and who has the ultimate control in deciding
> where the packets are sent.
>

It is not a question of ultimate control. It is distributed control, with
security  algorithms so that participants in the algorithm know the signaling
came from authorized and authenticated sources. Distributed algorithms always
work better for routing, that's the original contribution of the Internet over
standard circuit-switched networks.

> The mobile ip working group is more than qualified for these
> discussions. And, I believe we have had at least some of these
> discussions.
>

Sorry, the draft was submitted to the MIP group.

> We can discuss architecture. There are many ways to envision
> architecture. We can discuss protocols, and make them work within
> a broad scope of generally agreed principles.
> I don't see the need for another working group.
>

I'll take this discussion to the mipcharter list, where it belongs.

>
> >
> > >     Having said that, the overarching goal should be to allow protocols
> > >     to complement each other as much as possible. Specifically, with
> > >     FMIPv6, I would like to do that. Who would like to offer solution
> > >     for securing the FBU ?
> > >
> >
> > Here's my solution: get rid of it and use a Redirect between the MN and
whatever
> > the current AR is. Use the SEND protocol (draft-ietf-send-ipsec-00.txt) to
> > secure the Redirect. Have the current AR inform the previous AR, if the link
has
> > already switched, and the two ARs set up the tunnel. Use an interrouter
IPsec
> > security association to secure the HI/HAck messages for the tunnel setup.
> >
> > The MN finds out the new router address for the Redirect (i.e. wireless
> > reachability) from CARD/FMIP prehandover signaling, well in advance of the
> > handover, or from a cached RA on the access point (FRA). And those messages
are
> > also secured with SEND.
> >
>
> Good. I encourage you to bring it up as a solution and let the
> folks on the list respond. In fact, let me start it by asking if the
> SA is there between the MN and its AR, why couldn't that be
> used by the MN from the new AR to send a message asking for
> traffic re-direction ?
>

Because the TTL on the signaling would have to be greater that 255, as explained
above, opening the old AR to a cycle DoS attack.

In addition to the previous point I've raised about ingress filtering on the new
AR.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 3 Mar 2003 12:13:39 -0800

JinHyeock,

This response is about the architectural question.

> >     Correspondent Nodes) taking place.

Right, but all these are aspects of local, not global, change. The point the
draft is trying to make is that any design for IP mobility should recognize this
distinction.

> Does it only mean the tunnel between old AR and new AR?

Local route repair means fixing up the gap in routing between local movement to
the new link and the change in care of address that allows the global routing to
direct packets to the new link. Tunnels are the only way with current IP routing
that one can do this. A tunnel from the old to new AR is one possibility, there
are others (tunnels from HMIP MAP, tunnel from aggregation router to access
router, etc.).

> without taking some time?

There are a variety of problems with using HMIP for routing repair, I don't
intend to be drawn into a conversation about the details. :-) Suffice to say,
the basic mechanism and signaling proposed by HMIP are orthogonal to issues
involving local link routing, but like the basic MIPv6 spec, the local link
routing can be used and modified as appropriate if someone wants to use HMIP for
handover. That is why the question is an architectural one.

Making the distinction is important because regional mobility managment using
HMIP has a variety of uses, and not everyone will want to use it for handover.

> easy to understand neither.

It means that the SolPrxyRtAdv/PrxyRtAdv triggers the handover and does
preconfiguration. This is very link protocol dependent, as for many 802.11
implementations it is not possible to use. The WG has been discussing
decoupling.

I'll work on improving the text.

            jak