Subject: Re: [mobile-ip] Thoughts on using handover capability extensio

From: Rajeev Koodli <[email-masked]>
Date: Thu, 14 Nov 2002 11:13:04 -0800

Hello folks,

we had a good discussion on the topic. Let me try
to summarize.

- it seems to me that folks prefer moving the PrRtSol
   and PrRtAdv messages to an earlier time. Perhaps
   we should recommend that the MN should send
   PrRtSol after router discovery (RS/RA) or during router
   discovery (see the next issue) ? In this message,
   the MN sends a wildcard for target APs. The router
   sends a map of neighboring AP-AR information.
   The MN may send PrRtSol any time. However, the
    tunnel between the ARs is only established upon
    processing the FBU message. This should avoid
    handover state establishment and management between
    PrRtAdv and FBU processing instances.

- Should the "handover capability request/response"
    messages be options in RS/RA or separate messages ?
    There were some arguments that if we propose them
    as options, we need them standardized in IPv6 WG.
    If this is the case, I would stick with the current types.
    Otherwise, I would like to propose making them options,
    since that could reduce the number of messages sent.

Comments ?

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Nov 2002 13:38:56 -0800

>    the MN sends a wildcard for target APs.

The MN should also send some indication of the link technology, for intertech
handover, in addition.

>   The router

FBU is the wrong message, since when it is sent, the new CoA hasn't been
configured yet. BU is only an appropriate semantic when the MN does, in fact,
want to change its CoA.  RS/RA to the new router with the IP address of the old
AR and old CoA are right. The RS/RA must be done anyway before the BU to get the
L2 address of the router. The new AR signals HI/HAck to the old to start the
tunnel.

The old AR should also have the option of starting the tunnel if it gets a
secure link down trigger from L2. Else there is no hope of eliminating packet
loss due to L2 blackout.

Or did you have in mind the MN starting the tunnel while it was still on the old
link (and thus having packets be sent to the new AR before the MN shows up)?

>     since that could reduce the number of messages sent.

I think they should be a separate type of the FMIP prehandover messages. They
should not be in RS/RA. The MN should be able to query for this information when
it wants, or not if it doesn't need it.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 14 Nov 2002 15:53:57 -0800

> L2 address of the router. The new AR signals HI/HAck to the old to start the

I hear you. However, one could argue that purpose of BU is to
provide authorization to bind two addresses. In MIPv4, e.g.,when the
MN is using FA's CoA, it does not have a "new CoA".
In addition, even after you do HI/HAck upon receiving RS above,
you still need to send the FBU to authorize redirection.

> secure link down trigger from L2. Else there is no hope of eliminating packet

Establishing tunnel via link-specific knowledge is allowed.
Forwarding is still contingent  upon receiving FBU authorization.

> link (and thus having packets be sent to the new AR before the MN shows up)?

This as well.

> it wants, or not if it doesn't need it.

Ok.

-Rajeev

---

From: Greg Daley <[email-masked]>
Date: Fri, 15 Nov 2002 14:04:18 +1100

Hi Rajeev,

I've seen a the other arguments about handover capability
and I'm inclined to think (like james says) that this information
is useful only some of the time, and may be better in
a separate message to RS/RA, or maybe even solicited
through option(s) in the RS.

About IPv6 WG support of an option, I'm not sure that
they really care what options we would put in the RA.
The ICMP options are well defined TLVs which are explicitly
skipped if they are not understood (in icmpv6).
Polluting their number/namespace may be an issue though.

The important thing is that our options don't interfere
with other nodes/networks, and don't change existing nodes'
required function, which is becoming more important as IPv6
networks become deployed.

If things are going to be more general (with CARD capabilities
for example) we'll want a different message to put options in,
specifically so we don't overrun the ICMP option namespace
(like has happened in RADIUS &etc).  Of course, that may
be an issue for Seamoby WG.

Greg Daley

---

From: "James Kempf" <[email-masked]>
Date: Fri, 15 Nov 2002 04:11:34 -0800

> provide authorization to bind two addresses.

My feeling is that we must be precise and clear in what this signaling does. I
believe the BU is not for binding two arbitrary addresses, but for binding a
host's node identifier to its routing identifier.

> In MIPv4, e.g.,when the

Why? If SolPrxyRtAdv/PrxyRtAdv are exchanged prior to the handover, then that
should be sufficient to authorize the tunnel. In draft-kempf-fmipv6-sem-00.txt,
I've outlined several problems with this notion of using the FBU to authorize
redirection. Here is a summary:

1) If the MN moves to the NAR before the FBU is sent, the new router is expected
to route the FBU back through the tunnel prior to the FBU being received at PAR
"authorizing" redirection, since the FBU is sent with source address being the
PCoA. What authorizes the NAR to route an address that is not topologically
correct if PAR is considered to not have authorized it yet?

2) The security for the FBU is unclear.

3) The NAR's address is carried in the AltCoA option. The base MIPv6 spec
requires RR with any AltCoA, but that makes no sense in this case.

4) As a practical matter, once the MN has completed SolPrxyRtAdv/PrxyRtAdv, it
has effectively authorized redirection. The FBU is just another message that can
get cut off by the handover and cause the optimization to fail.

In the signaling sequence I've proposed, the immediate authorization for
redirection to PAR comes from the NAR via HI/HAck, with which PAR has a security
association if the tunnel is set up posthandover, or from the PAR to NAR if the
tunnel is set up prehandover.

The MN authorizes the redirection to PAR prehandover with an authenticated
SolPrxyRtAdv/PrxyRtAdv. The MN authorizes redirection posthandover with a
similarly authenticated RS/RA sequence I described in the original email.

The two signaling sequences are symmetrical, using standard ND messages or
simple extensions (the Prxy's) to signal routing redirection when the MN detects
a (possibly pending) link failure. The SolPrxyRtAdv/PrxyRtAdv sequence risks
getting cut off by the handover if the signaling is tightly tied to Layer 2
handover, so the MN might "preauthorize" by exchanging this sequence
considerably in advance of the handover, so that the PAR could perform the
redirection as soon as it has an indication of movement. This is a slight
extension to what we've been discussing regarding using the PrxyX sequence for
CARD.

A BU is appropriate after the MN has completed change of CoA with HA and CN on
the new link. At that point, it could send a BU to PAR to cancel the tunnel.

                jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 15 Nov 2002 15:49:42 -0800

> host's node identifier to its routing identifier.

IMO, this separation of "node identifier" vs. "routing identifier" is not
helpful
here. As long as the sender node can prove that it's authorized to change
binding
on "an IP address", it can do so. This address can be the "home address of
MN",
or its "previous care-of address used on the old access network". And
"care-of
address" in a BU can be almost "any IP address" as long as MN can receive
packets
sent to it.

Using "node identifier" vs. "routing identifier" can really get things
tangled
if we try applying them to "home address bound to CoA1 on the Home Agent1,
and
CoA1 bound to CoA2 on Home Agent2" (like in forwarding from previous CoA).
So which ones are node id, which ones are routing id? Note that BU was used
in both
cases.

> correct if PAR is considered to not have authorized it yet?

OK, the security concerns on this are already discussed.

> 2) The security for the FBU is unclear.

Yes, it needs to be worked out. But it's certainly not any worse than
the problem of securing ND, PrRtSol, etc.

> requires RR with any AltCoA, but that makes no sense in this case.

This is a home agent registration. Are you sure an RR is required for
AltCoA when BU is sent to the HA?

> has effectively authorized redirection.

Not necessarily. I think you are proposing to change its semantic as such...

> The FBU is just another message that can

Correct.

> similarly authenticated RS/RA sequence I described in the original email.

So, in addition to BU, you are suggesting using two more
signals to achieve the same goal: HI, and PrRtSol. This is complicated.

> the new link. At that point, it could send a BU to PAR to cancel the
tunnel.

alper

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 15 Nov 2002 18:44:03 -0800

> host's node identifier to its routing identifier.

We are going with the Mobile IP semantics, including RR I can say.
The distinction you bring up perhaps needs a separate discussion.

> correct if PAR is considered to not have authorized it yet?

Right. I believe there has been quite a bit of discussion on this topic.
I guess the feeling is if the destination address is PAR's, the NAR
can allow FBU to go through.

> 2) The security for the FBU is unclear.

This needs to be considered, seprately.

> requires RR with any AltCoA, but that makes no sense in this case.

I don't believe this is a real problem. You could argue that RR needs to
be considered without AltCoA. Since we are dealing with known
addresses here, we ought to be able to do away without RR.

> get cut off by the handover and cause the optimization to fail.

If you do PrRtSol/PrRtadv much ahead of actual handover, like the way
folks want it, then, how does the PAR decide when to redirect traffic modulo
link indication ? I don't believe we can make redirection based on link indication
the _only_ way to do redirection. Indeed, the consensus on the list (right after
the
last IETF) was to require FBU to do redirection no matter how the tunnel is set up.

> similarly authenticated RS/RA sequence I described in the original email.

See above.The problem is still how the PAR decides to do redirection.

> redirection as soon as it has an indication of movement. This is a slight

The indication of movement, in general, comes from FBU.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Sat, 16 Nov 2002 05:13:05 -0800

> The distinction you bring up perhaps needs a separate discussion.

I'm not sure I understand your point.

> can allow FBU to go through.

But if there has been no PrxyRtSol/PrxyRtAdv signaling prior to handover, as in
802.11, the NAR won't know the PCoA.

> last IETF) was to require FBU to do redirection no matter how the tunnel is
set up.

This is one drawback of doing PrRtSol/PrRtAdv much ahead of handover. I think
that if the MN has done PrRtSol/PrRtAdv, that can be considered an
authorization, because the MN must have given credentials. So the AR can
redirect if it gets a prehandover L2 trigger, based on the preauthorization. The
problem is if only the MN gets a prehandover trigger, there is no way for the AR
to know when to redirect.

One way that would be more consistent with the current handling of changes in on
link routing would be to use ICMP Redirect.  If the MN gets a prehandover
trigger, it sends ICMP Redirect to the current AR to redirect routing to the new
AR. This is just one message, instead of three, and therefore less likely to be
cut off. Besides, if the link layer only provides the MN with prehandover
notification, there is no other choice.

There is another issue with moving PrRtSol/PrRtAdv much ahead of handover:
anticipated CoA configuration. Are we going to give up on that? Or is it OK for
the MN to reserve CoAs at various surrounding ARs? If the latter, then how long
should the ARs defend the addresses? I don't have any problem with giving up
anticipated CoA configuration, because the tunnel will provide traffic anyway,
and some of the new optimized ND work, such as FastRA and oDAD should reduce the
on link CoA configuration time.

> The indication of movement, in general, comes from FBU.

We obviously have a disagreement here.

            jak

---

From: Pete McCann <[email-masked]>
Date: Sun, 17 Nov 2002 11:35:48 -0600

James,

 > L2 address of the router. The new AR signals HI/HAck to the old to start the

What if there are multiple ARs on the new link?  If I am not mistaken,
RS is sent to the "all nodes on this link" multicast address, correct?
Which router is supposed to pick up the message and forward it to PAR,
establishing the tunnel state?

Again, I think we are confusing router discovery with tunnel
establishment.  I think it's dangerous to have discovery messages with
stateful side-effects.

-Pete

---

From: "James Kempf" <[email-masked]>
Date: Sun, 17 Nov 2002 11:13:08 -0800

> establishing the tunnel state?

Whichever router sends the RA back.

> establishment.  I think it's dangerous to have discovery messages with

We could make it be an ICMP Redirect from the mobile node. Semantically more
appropriate, but since the mobile must send the RS anyway to get the L2 address
of the router, RS will probably be the first message sent, and thus the tunnel
would get estabished more quickly, and with less over the air traffic.

                    jak