Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6

From: "Christian Vogt" <[email-masked]>
Date: Mon, 16 Feb 2004 16:38:52 +0100

Hi Jari,

my comments are between the snippets of your email. Your complete email is given at the bottom.

> - The base draft already allows caching and re-use of home
>    keygen tokens. (Or maybe I just thought it does? Anyway,
>    it does not matter either way, its good that you draft
>    explains how to do it just before movement.)

Yes, the Mobile IPv6 specification explicitly allows re-using both Home and, where applicable, Care-of Keygen Tokens. This allows a MN to do an anticipated (or periodic) home-address test prior to handover as proposed in [2] without violating the Mobile IPv6 protocol procedure. (See the last two paragraphs of section 5.2.7 in [1] as well as the second paragraph of section 4 in [2].) The possibility of anticipated (or periodic) home-address tests, though, is not mentioned in [1].

> - Your argument that the attacker has to keep a lot of
>    state if multiple CNs are used. Hmm.... I memory is
>    cheap these days. I think it is more interesting to
>    track the bandwidth that the attacker vs. victims have
>    to use.
> 
> - Speaking of bandwidth, why not adopt a packet count
>    lifetime instead of a time based lifetime? Three
>    seconds can be very little on a GPRS link and quite a
>    lot on a fiber...

This is an excellent observation. However, counting bytes in rather than packets would be more accurate. The CN could determine a certain data volume, say D, prior to the MN's handover. (I sketch a way of doing this below.) When the CN received an Early Binding Update (EBU) message from the MN, it would send subsequent packets to the MN's new care-of address as long as these packets, taken together, did not exceed D bytes in size. Once the threshold D was passed, the CN would switch to the MN's home address (which is ok, because the home address had already been verified by a home-address test at that time).

Now, how can the CN determine the data volume D? One way of doing this is adding up the sizes of data packets, which the CN sent to an earlier care-of address of the MN after having received a standard Binding Update message for the care-of address. Note that reception of a (properly authenticated) standard Binding Update implies that a successful care-of-address test has been done for the particular care-of address. As an accumulative sum, D should probably be limited by a constant upper bound, or it should be exponentially reduced over time. Exponentially reducing D would have the advantage that the data volume D is kept fresh. Admittedly, it would imply a higher overhead at the CN's side.

> - Did you specify somewhere what happens if the
>    CN does not support your scheme? Does the MN have
>    to resend the optimistically delivered packets?
>    Do you have simulation results on what that means
>    for performance?

Our current assumption is that the MN should set the A-flag in the Early Binding Update (EBU) message after the very first handover. The A-flag would solicit an Early Binding Acknowledgement (EBA) message from the CN, if the CN supports EBUs. The MN should wait for a returning EBA message before sending data to the CN from the new care-of address. 

This way, the MN would learn whether or not the CN supports EBUs or not because...

(1) ...the CN returns an EBA message if it accepts the EBU message.
(2) ...the CN returns a Binding Error message with Status code 2 ("Unrecognized MH Type value") if it does not accept the EBU message. Of course, for this to be true, the EBU message must have a MH Type different from the MH Type of the standard Binding Update message. (See section 9.2 of [1].)

Consequently, if the MN neither receives an EBA message nor a Binding Error message, the MN knows that either its EBU message or the response got lost.

Best regards

- Christian

[1] Mobility Support in IPv6, 
    http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-24.txt
[2] Early Binding Updates for Mobile IPv6
    http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt

|
| Christian Vogt
| Institute of Telematics, University of Karlsruhe (TH)
| www.tm.uka.de/~chvogt/
|

Jari Arkko wrote:
> After a quick read, this draft looks interesting. Quite
> promising, actually.
> 
> A couple of comments:
> 
> - THe base draft already allows caching and re-use of home
>    keygen tokens. (Or maybe I just thought it does? Anyway,
>    it does not matter either way, its good that you draft
>    explains how to do it just before movement.)
> 
> - Your argument that the attacker has to keep a lot of
>    state if multiple CNs are used. Hmm.... I memory is
>    cheap these days. I think it is more interesting to
>    track the bandwidth that the attacker vs. victims have
>    to use.
> 
> - Speaking of bandwidth, why not adopt a packet count
>    lifetime instead of a time based lifetime? Three
>    seconds can be very little on a GPRS link and quite a
>    lot on a fiber...
> 
> - Did you specify somewhere what happens if the
>    CN does not support your scheme? Does the MN have
>    to resend the optimistically delivered packets?
>    Do you have simulation results on what that means
>    for performance?
> 
> --Jari

Šž¦j)bž	b²Ó"§¨žµú+‚m¦ÏÿÃ"z×è®æj)fjåŠËbú?š*z