Subject: [Mip6] WG LC: I-D draft-ietf-mip6-precfgkbm-01.txt

From: [email-masked]
Date: Thu, 9 Dec 2004 22:33:15 -0600

Hello,

This is a Working Group last call for the following I-D:
I-D :draft-ietf-mip6-precfgkbm-01.txt
Title: Precomputable Binding Management Key Kbm for Mobile IPv6

The status associated with this I-D is : Informational and will be
progressed as such.

Please review and post your comments by January 1st, 2005.

-Chairs

URL to I-D:
http://ietf.org/internet-drafts/draft-ietf-mip6-precfgkbm-01.txt

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Fri, 10 Dec 2004 12:20:59 +0100

In your previous mail you wrote:

=> why is it not a standard track document?

Thanks

[email-masked]

---

From: Christian Vogt <[email-masked]>
Date: Sat, 25 Dec 2004 17:22:07 +0100

> Title: Precomputable Binding Management Key Kbm for Mobile IPv6

Hi Charlie,

let me get back to the handling of sequence-number rollovers discussed
in section 3 (Security Considerations) of your draft. The draft says:

    [...]                  This method of providing replay protection
    fails when the Binding Update sequence numbers cycle through the 16
    bit counter (i.e., not more than 65,536 distinct uses of Kbm for
    any particular care-of address) [...]
    [...]                        If the mobile node were to send a fresh
    Binding Update to its correspondent node every hour, 24 hours a day,
    every day of the year, and utilize the same care-of address every
    time, this would require changing keys every 7 years.  Even if the
    mobile node were to do so every minute, this would provide protection
    for over a month. [...]

If I don't miss something, I think a mobile node is pretty safe with
respect to replay attacks when it uses the *same* care-of address more
than 65,536 times in a row. In this case, a replayed Binding Update
could only re-register the care-of address that the "right" mobile node
is using anyway (because the care-of address has never changed).
Consequently, this replayed Binding Update would not do any harm.

However, IMO, one should keep in mind that a more realistic (though
possibly negligible) vulnerability to replay attacks does exist when a
mobile node uses *different* care-of addresses in its Binding Updates.
Given a sequence-number rollover in this case, an attacker could replay
an old Binding Update with a care-of address that the mobile node has
used before, but is not using any more. As a consequence, the mobile
node would be unable to continue normal communcations because all its
packets would be redirected to a stale care-of address.

Also, I would say that this problem is more about DoS attacks against
the mobile node rather than about flooding attacks against a third
party, as the draft suggests further down.

What could one do about sequence-number rollovers? - Here are a few
suggestions (and you probably already thought about them):

(1) Don't do anything about sequence-number rollovers, except what is
being proposed in the draft, because rollovers are going to be a
negligible problem in most realistic scenarios anyway. The draft already
mentions that nodes should re-configure a new Kcn when a sequence-number
rollover occurs.

(2) Use timestamps instead of sequence numbers. But then you have the
issue with synchronisation between the mobile node and (possibly
multiple) correspondent nodes.

(3) Use a longer sequence number field. For instance, one may think
about an Extended Sequence Number option for Binding Updates and Binding
Acknowledgements. This option could, e.g., carry a 64-bit sequence
number, which is as long as the timestamps used in MIP4. Due to the
extended length, such an extended sequence number would be as good as a
timestamp, yet it would do without synchronization.

Just as an aside: When the return-routability procedure is used, a
Binding Update is valid only if fresh Home and Care-of Keygen Tokens
are used for computing the authorization data. Consequently, sequence
numbers have to protect only the 3.5-minute interval during which the
Keygen Tokens can be reused. (See section 5.2.8 of RFC 3775.) In all
practical scenarios does this solve the sequence-number rollover
problem. (BTW, you get the same benefit when you combine pre-configured
keys with a care-of-address test.)

So far, so good.  Merry Christmas!

- Christian

--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

"Snowmen fall from Heaven unassembled." (Source unknown)

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 25 Dec 2004 08:41:44 -0800

Hello Chrisitan,

>packets would be redirected to a stale care-of address.
Well, in this situation, the mobile node might try to re-register its 
current care-of address,
if it detects that something is going awry.

>party, as the draft suggests further down.
I can add that language to the draft.

>mentions that nodes should re-configure a new Kcn when a sequence-number
This is my preference.  I do think that when the sequence number rolls over,
it's time to reconfigure a new Kcn.

>multiple) correspondent nodes.
There is a new draft with such an option specified.  But I wouldn't want 
this
draft to make normative references to the newer draft.

>timestamp, yet it would do without synchronization.
If there's already going to be such a new timestamp field, then option (3)
isn't so attractive as an additional measure for improving the robustness in
case of rollovers, which I believe will be extremely rare anyway.

>Keygen Tokens can be reused. (See section 5.2.8 of RFC 3775.)
>  
>
Maybe, except that I'd be a lot happier if the 3.5 minute interval were 
extended to,
say, 3.5 hour intervals.  I am pretty sure we are jousting at windmills 
here -- even,
perhaps, at windmills that no one has ever seen.  But, that's politics, 
and we must
check millions of shoes every day.

Happy holidays!

Regards,
Charlie P.

---

From: Marc Manthey <[email-masked]>
Date: Sat, 25 Dec 2004 22:41:15 +0100

On 25. Dec 2004, at 17:41 Uhr, Charles E. Perkins wrote:
> I am pretty sure we are jousting at windmills here  even, perhaps, at 
> windmills that no one has ever seen.  But, that's politics, and we 
> must  check millions of shoes every day.

god evening all , charles
what about a "3,5 hour foundation "?
*scnr*
cheers
and happy holidays
marc

from battle overseas:)

    "If the doors of perception were cleansed,
    everything would appear to man as it is, infinite."
    William Blake, The Marriage of Heaven and Hell

         http://www.nosoftwarepatents.com/

---

From: Christian Vogt <[email-masked]>
Date: Wed, 29 Dec 2004 16:14:39 +0100

Hi Charlie.

>> (1) Don't do anything about sequence-number rollovers, except what 
>> is being proposed in the draft, because rollovers are going to be a
>> negligible problem in most realistic scenarios anyway. The draft 
>> already mentions that nodes should re-configure a new Kcn when a 
>> sequence-number rollover occurs.

> This is my preference.  I do think that when the sequence number 
> rolls over, it's time to reconfigure a new Kcn.

This makes perfect sense to me.

>> (2) Use timestamps instead of sequence numbers. But then you have 
>> the issue with synchronisation between the mobile node and 
>> (possibly multiple) correspondent nodes.
>> 
> There is a new draft with such an option specified.  But I wouldn't 
> want this draft to make normative references to the newer draft.

Ok.

A couple of MIP6 extensions are already using timestamps, e.g., the
Authentication Protocol, Certificate-based Binding Updates, and
CGA-OMIP6.  What these protocols usually do not specify is how clock
synchronization is handled in the route-optimization case.  Does a CN
maintain a clock skew for each Binding Cache entry, or does a MN
maintain one for each BUL entry?  Anyway, this is a minor issue.

>> about an Extended Sequence Number option for Binding Updates and 
>> Binding Acknowledgements. This option could, e.g., carry a 64-bit 
>> sequence number, which is as long as the timestamps used in MIP4. 
>> Due to the extended length, such an extended sequence number would 
>> be as good as a timestamp, yet it would do without synchronization.
>> 
> If there's already going to be such a new timestamp field, then 
> option (3) isn't so attractive as an additional measure for improving
> the robustness in case of rollovers, which I believe will be 
> extremely rare anyway.

Alright.

>> Binding Update is valid only if fresh Home and Care-of Keygen 
>> Tokens are used for computing the authorization data. Consequently,
>> sequence numbers have to protect only the 3.5-minute interval 
>> during which the Keygen Tokens can be reused. (See section 5.2.8 of
>> RFC 3775.)

> Maybe, except that I'd be a lot happier if the 3.5 minute interval 
> were extended to, say, 3.5 hour intervals.  I am pretty sure we are 
> jousting at windmills here -- even, perhaps, at windmills that no one
>  has ever seen.  But, that's politics, and we must check millions of 
> shoes every day.

Anyway.  But FWIW, I found that care-of-address test cannot even always 
be used to protect against replay attacks.  Namely, if one ever wanted 
to combine pre-configured keys with care-of-address tests, then one 
would most probably test a new care-of address *concurrently* with using 
it.  The reason is that standard, RFC-3775-compliant care-of-address 
test would damage the whole efficiency benefit that you get through 
pre-configuration.  Yet, once you do care-of-address tests concurrently, 
and you replace the home-address test by pre-configured keys, you no 
longer have the additional protection against replay attacks which was 
mentioned above.

However, this does not affect draft-ietf-mip6-precfgkbm-01.txt.

Happy holidays.

- Christian