Subject: [mobile-ip] Re: FMIPv6 signaling (was: Re: [mipcharter] Proposed Charter for IPv6 Mobility)

From: Rajeev Koodli <[email-masked]>
Date: Tue, 04 Mar 2003 16:54:04 -0800

Hello Jim,

I have Cc'd this to mobile-ip list as well.

James Kempf wrote:

> > The message that triggers HI and HAck exchange is from the
> > MN. Even if the new AR sent HI, which I think is okay personally,
> > it still needs to carry an authorization from the MN to redirect
> > traffic.
> >
>
> A message from MN to new AR requesting a tunnel be opened only has to be
> authenticated as coming from a node that is authorized to use the PCoA, and thus
> to change routing for it. The message back to previous AR doesn't need this
> authorization in it. Routers exchange routing information all the time. All that
>

I think this is the crux of the issue. Whether the MN authorizes the router to
redirect traffic or not. I believe the model where it does is based on Mobile IP
and it is one of the reasons, if not the reason, why the current design is derived
from Mobile IP and is being done in Mobile IP working group.

> is required is that the HI/HAck exchange between the routers have the proper
> authentication and authorization, just as any exchange of routing information
> between routers would.
>

This model does not use an authorization from the MN to effect routing change.
I am not saying that this is unworkable, although I have my set of questions, but
fundamentally different from the Mobile IP model in which the MN decides when
a router changes the routing entry.

The new model is worthy of consideration and further exploration. That perhaps
needs to
be done elsewhere while folks who are familiar with the Mobile IP model can
progress
the work and get the draft closer to a standard.

>
> As to how to achive the auth/authz on the message from MN to new AR, please see
> the SEND protocol draft.
>

While I would be glad to allow using SEND for securing the MN's message to the
old AR, I am confused as to why you need to re-wire the basic protocol the "SEND
way"

-Rajeev

>             jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 04 Mar 2003 17:14:02 -0800

James Kempf wrote:

> > Thanks for clarifying. Just as another reference to
> > compare your results, you might want to consider that
> > if the MN has got the NAR's MAC address, it would be
> > able to send a BU after RS (with FNA option)/RA (with NAACK option)
> > which confirms new CoA configuration.
> > Of course FBU can be sent immediately when needed (for instance, the
> > MN was not able to send it on the previous link). Having PrRtSol/PrRtAdv
> > ahead of handover allows the MN to collect NAR information reliably.
> >
>
> ...and provides the opportunity for handover optimization failure if the MN
> moves before the PrRtSol/PrRtAdv signaling completes.
>

I didn't get your point Jim. I said having these messages _ahead_ of handover,

perhaps at attach time, provides the necessary information reliably. So,
I don't follow your conclusion.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 04 Mar 2003 17:21:18 -0800

James Kempf wrote:

> > What I would like to emphasize is that FMIPv6 provides a mechanism
> > to send and receive packets expeditiously. If the message sequence cannot
> > be exchanged, it would have to fall back to default. Sometimes this "default"
> > may be good enough. What I don't see is why FMIPv6 needs to incorporate
> > all the defaults :-)
> >
>
> It doesn't need to incorporate all the defaults, but I think it needs to be
> clear that not all the signaling must be used if the link layer can provide
> enough support.
>

Isn't that the reason why we allowed tunnel set up based on link
layer indication ?

>
> > Furthermore, there is a clear derivation from Mobile IP in setting up
> > forwarding from the previous AR through the Fast BU message. I believe
> > this is one of the reasons, i.e., using the base Mobile IP concepts, why
> > FMIPv6
> > is being done in the mobile-ip WG.
> >
>
> That's exactly the architectural problem I think we need to eliminate. I think
> the global signaling (BU) needs to be separated from the local link signaling.
> The security issue is pointing to the need for this separation.
>

I don't understand the security issue you are referring to. If you are able
to establish some sort of security association by whatever available means
with the old router, why could not you use that association to secure the
FBU ?

Why do you have to see a BU as a global concept ? I don't agree with your
characterization. To me, it is a message from the MN to a router that securely
binds one address for another for forwarding purposes.

Thanks for the info on handover experience.

-Rajeev

>
> >
> > FYI, we also implemented the base FMIPv6 protocol sometime
> > ago, and the results were published in the October 2001 issue of ACM
> > Computer Communication Review). Overhead due to IP signaling was
> > within 15% of the link-switching delay, which was due to L2 bottlenecks.
> > Which WLAN card are you using (that gives < 40 ms link switching latency) ?
> >
>
> Our results are that it works fine if you have 4 Mbps, but anything less than
> about 360 kbps and you start running into potential failures, particularly with
> respect to prehandover signaling being cut off if you have prehandover
> notification from the L2. If you don't have prehandover notification, as in
> 802.11, then there is no problem, but you lose packets during the L2 blackout
> period.
>
> W.r.t. 802.11  link switching, the MobyDick guys are setting their cards in
> noninfrastructure mode, which won't work in general but is OK for testing. We
> think the 802.11 handover algorithm needs some major surgery: opportunistic
> scanning for example. See Bill Aurbaugh's excellent paper on this topic.
> Alternatively, maybe with 802.20 the link guys will finally get it right and
> come up with a protocol that works well with Mobile IP.
>
>             jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 5 Mar 2003 11:16:25 -0800

> the work and get the draft closer to a standard.

I think the Mobile IP model must be a proper subset of the IP model, and where
they conflict, the IP model should take precedence. I think it would be a
serious mistake, from an IETF wide standpoint, for the Mobile IP group to pursue
a design that does not have this property. As I have outlined in previous
emails, I believe the current design does not have this property.

> old AR, I am confused as to why you need to re-wire the basic protocol the
"SEND

It's not a "SEND way", it is basic security considerations coming out of RFC
2461, which are, in and of themselves, part of more general security
considerations for any protocol. These considerations are:

1) How to confine any heavy cryptographic or other computation to packets that
known to have originated onlink.

2) How to assure that the sender of a packet is authorized to perform the
operation requested and that the packet is authentically from that sender.

I have difficulty seeing how the current design can meet these security
properties.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 5 Mar 2003 11:28:05 -0800

Rajeev,

We have been around this issue now several times. I think we need to either
agree to disagree or something, but I don't think we should continue to load the
mailing list with discussion on it.

> binds one address for another for forwarding purposes.

1) Because an FBU can come from anywhere, allowing a random attacker to mount a
cycle DoS attack on the router. The attack is that the sender bombards the
router with FBUs, tying up  the router in the heavy overhead of cryptographic
verification. By confining the heavy cryptographic processing to nodes that are
known to be on link, such a DoS attack is mitigated. This can be done by setting
the TTL to 255.

2) If the FBU message is sent when the MN is on the newAR, the newAR's ingress
filter will reject the message if the address is PCoA. The MN can't use NCoA
because it might not be configured yet. Other good properties if ND-derived, on
link signaling is used:
    a) The MN can send the message to the all routers multicast address as the
destination. This means the MN doesn't need a specific address of a router, so
the same signaling will work if the MN is either on the old link or the new. It
also means that links with multiple routers can load balance in terms of
handling the tunneling traffic, instead of the MN having to select a router.
    b) Use the link local address for the interface as the source address. This
address will also not change if the MN is on the new or old link. The MN would
have to do oDAD on the link local address if it is on the new link, of course.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 05 Mar 2003 17:29:07 -0800

Hello Jim,

> emails, I believe the current design does not have this property.

The FMIPV6 protocol makes use of Mobile IP deisgn experience and
hence being done as part of mobile-ip group I guess.As I said, other alternatives
must be acknowledged and perhaps explored independently of the
current draft.

> operation requested and that the packet is authentically from that sender.

I don't see why these principles are restricting the current FMIPv6
design. At the explicit risk of repeating myself, why could not these
principles be applied using a security association for the global address
of the router ?

I know you have raised the issue of DoS attack because you revealing the
global address of the router. But, my sense reading others e-mail on this
topic was that one could find out the router's global IP address by other
means. My own comment was that the whole point of establishing an SA
between two nodes is that they could reasonably trust each other. If the MN
either accidentally or intentionally hands out the global IP address of the
router for a malicious node, that very same possibility exists today with
Mobile IP.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 05 Mar 2003 17:44:06 -0800

> mailing list with discussion on it.

I agree we are cycling. But disagree I am the cause of it.

> known to be on link, such a DoS attack is mitigated. This can be done by setting

What stops a rogue node from doing this in Mobile IP today ? I guess the
randmon attacker had an SA with the router. What lifetime are you
assuming for that SA ?

> because it might not be configured yet. Other good properties if ND-derived, on

Didn't the group discuss this around over 6 months ago and felt that
this was not a concern ? The new AR can have an entry for the previous
AR when it does ingress filtering, allowing only those packets with
Dst = PAR to go through.

How does this work with Mobile IPv4 today ?

> handling the tunneling traffic, instead of the MN having to select a router.

You still need to provide the old (new) router's global
address so that the ARs can communicate with each other.
Moreover, in the inter-AR messages, the MN still needs to
include an authorization for traffic redirection. If the MN does
not provide such an authorization, that's not Mobile IP and
needs separate consideration.

> have to do oDAD on the link local address if it is on the new link, of course.

So, how do this help ? Especially with DAD ?

-Rajeev