Subject: [Mobopts] Review of draft-arkko-mipv6-binding-lifetime-extension-00

From: "Fan Zhao" <[email-masked]>
Date: Thu, 30 Mar 2006 20:10:58 -0800 (PST)

Hi Christian,

Please see my comments below on draft-arkko-mipv6-
binding-lifetime-extension-00 (in short, BLE). 

In BLE and rr-ext (either mip6-rr-ext or mobopts-rr-ext)
the way hash chain is used is different. rr-ext utilizes
the one-way attribute of hash function to authenticate the
identity without home address test thus hash chain elements
are generated firstly and are used in the reverse order from 
being generated; while BLE uses hash operation
to associate with the previous binding and aggregate 
a sequence of bindings together, thus hash elements are generated
in the chronological order.
 
It is not just a coincidence that both drafts uses hash function,
but it means that hash function has some values in RR test, right? 

1. In abstract, "This requirement results in an average signaling
traffic of around 7 bits per second when the hosts are not moving
around. This traffic load by itself is neglible,"
s/neglible/negligible

2. In abstract, "but can be problematic for hosts in standby mode."
The need of keeping RO state alive in CN when MN is in standby mode 
really depends on the communication pattern of MN. For example, if MN 
sleeps for a long time before communicating with CN again, IMHO, the 
shorter delay of communication when MN wakes up does not justify the 
overhead caused by repeating RO with CN periodically.

This comment is also related to the second paragraph in section 1.

3. In abstract, "that can reduce this signaling load to around 0.1
bits per second"

If I understand this correctly, the overhead is reduced to
0.1 bit/second when the lifetime is 8 hour. I think other metrics
are also useful, for example, how long does it take for MN to achieve
an 8-hour lifetime and to reduce the overhead to 0.1 bits/second, what
is average overhead (bit/second)? Depending on the mobility pattern,
MN may not have the opportunity to enjoy the very low overhead.

Assume that the initial lifetime is 2.1=7*0.3 minutes and after
renewing for n times, the lifetime is 2.1*1.3^n=8*60=480 minutes.
Then the total waiting time is 2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1)
= 1593 minutes = 26.55 hours.

The average overhead is (376*n bytes)/(2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1))
when 2.1*1.3^(n-1)<=8*60.

4. If I understand correctly, Section 4.1 shows the effort-damage
consideration can be applied to the frequency of address tests. A
malicious or compromised MN may not mind investing 26.55 hours to
achieve 8 hour long lifetime binding (MN may solicit a large amount
of traffic and then leave the current location after achieving 8-hour
BU lifetime with CN, which causes the damages to both CN and the
previous access network.), which opens a larger vulnerable window
and thus is still very profitable for attackers.

>From the view of a good MN, it wishes to achieve the longer lifetime
as quick as possible. However, in order to make difficulty for the
malicious MN (CN does not know MN is malicious or not.), a good MN
still has to wait for a very long time to enjoy the benefit of long
binding lifetime. In other words, if MN does not stay for a long
enough time period, MN may experience more overhead than that in MIP6.

5. On page 7, "The requested lifetime in the Binding Update is not
limited to MAX_RR_BINDING_LIFETIME (7 minutes) but rather t * 0.3."

Should be "t * 1.3"?

6. The computation of Kcredit in the extended RR test is still
vulnerable to the eavesdroppers on both MN-CN and
HA-CN path.

7. In Section 4.4, the field of N is defined in Lifetime Credit
Authorization Option. I think probably the sequence number field
in BU message can be reused for this purpose, thus no need to
define a new field.

8. The modified RR test procedure still needs to pass through home
agent.

9. The draft may also consider utilizing the fact that MN does not
change its CoA in order to improve the security.

This draft (BLE in short) proposes to extend the binding lifetime
in order to reduce the signaling overhead and battery consumption
when MN does not change its location. In Section 5 of draft-zhao-
mobopts-rr-ext-00 (rrext in short, and draft-zhao-mip6-rr-ext-01 as well) 
we also consider this case. Below is a short comparison.

1. Both drafts use hash chain to prove MN's identity to CN. BLE
combines the new Kbm with the old ones while rrext uses a one-way
hash chain in the reverse order of hash chain generation.

By doing so, BLE needs less memory, but BLE is still vulnerable
to the eavesdroppers on both MN-CN and HA-CN path. rrext does
need to allocate more memory to keep the unused hash chain elements,
but MN can easily re-generate the hash chain once the old one is
depleted and the memory and hash operation are cheap nowadays.
For example, assume that a hash element is 16 bytes, 1 M memory
can keep hash elements enough for many days use. Also rrext can
detect the eavesdropper on both MN-CN and HA-CN path.

2. BLE works best for a MN staying at the same location for a very
long time, but rrext benefits MN under any mobility pattern.

3. BLE may expose to a larger vulnerable window by extending the
lifetime, but rrext does not.

4. In rrext, the signaling overhead is a little bit more than
(256*8)bits/(7*60)seconds = 4.9 bits/second constantly.

We can also analyze the power consumption in both drafts. For
example, we may compute how much power is consumed during a certain
time period where the amount of power consumed is equal to
c1*f(the number of bits sent and received during BU with CN)
+ c2*g(the length of time period when MN is awake to send the packets.)
+ other consumptions.

rrext sends and receives fewer bits than BLE and spends less time
as well because of home address test procedure in BLE while the
lifetime in BLE may be longer than in rrext.

Sicnerely,
fan

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

---

From: Jari Arkko <[email-masked]>
Date: Sat, 01 Apr 2006 04:23:19 +0300

>but it means that hash function has some values in RR test, right? 
I think the main point is showing that its the same node
all the time; hash function is just a tool for that. Showing
that you are talking to the same node is useful for some things
(such as possibly giving some more "credit" in some form to
it) but is not a sufficient condition by itself for securing RR.
For instance, we also need to verify ownership in some way
(e.g. home address test) and we also need to worry about
setting things back to normal if a node has rebooted or
when an attacker was able to show ownership temporarily
before you.

>overhead caused by repeating RO with CN periodically.
Right. All we are saying is that there are situations where its
problematic. Its hard for me to quantify how frequent or
non-frequent such situations are. Also, it depends on your
preferences: maybe your communication is of such importance
that you actually do want to receive it as soon as possible.

>an 8-hour lifetime and to reduce the overhead to 0.1 bits/second,
>
Right.

> what
Yes.

>and thus is still very profitable for attackers.
But its not merely about the willingness of the malicious
party to invest its own effort. He also needs to be in the
right position in the network to do this. For instance,
in order to run a home test he needs to be on the path
to the home address.

>enough time period, MN may experience more overhead than that in MIP6.
True. But this depends on the selection of the parameters -- see
also below.

>limited to MAX_RR_BINDING_LIFETIME (7 minutes) but rather t * 0.3."
Well, its a design decision. We wanted the method to be both tighter
and looser than original RR, depending on how long your association
has lasted; its an attempt to provide a balanced value based on
information, rather than applying a chosen fixed value. When
we start at 0.3, the initial bindings do in fact last less than 7 mins.

>vulnerable to the eavesdroppers on both MN-CN and
Nothing from the original RR really changes with this draft,
only the lifetimes. Having said that, I'd note that an RR
attack always needs an active attacker, as far as I know.
You can certainly look at the values that go by, but they
are worthless unless you actually intend to send a harmful
BU.

>in BU message can be reused for this purpose, thus no need to
Sure.

>8. The modified RR test procedure still needs to pass through home
Yep.

>change its CoA in order to improve the security.
Oh yes. Anyway, in general I think what we've got in cba-cga is what
would provide most benefit right now, and at least I am not actively
pursuing BLE at this time.

>Below is a short comparison.
>  
>
I'll leave this to Christian, I did not have time to re-read
rr-ext to provide sufficiently good feedback. Thanks for the
comparison in any case!

--Jari

---

From: Fan Zhao <[email-masked]>
Date: Fri, 31 Mar 2006 18:27:43 -0800 (PST)

Hi Jari,

Thanks for your reply.

> when an attacker was able to show ownership temporarily
Exactly.

> that you actually do want to receive it as soon as possible.
OK.

> in order to run a home test he needs to be on the path
Agreed. This is my assumption.

> we start at 0.3, the initial bindings do in fact last less than 7 mins.
OK.

> are worthless unless you actually intend to send a harmful
Agreed.

> rr-ext to provide sufficiently good feedback. Thanks for the
Thanks for your reply too.

Sincerely,
fan

---

From: Christian Vogt <[email-masked]>
Date: Fri, 31 Mar 2006 21:11:33 -0600

Hi Jari, hi Fan,

>> limited to MAX_RR_BINDING_LIFETIME (7 minutes) but rather t * 0.3."

Note that t is the *total* time that the MN's binding did so far exist.
It's not just the previous lifetime.  Therefore, the coefficient must
not be greater than 1.0.

If the coefficient was greater than 1.0, an attacker could get a binding
lifetime that is longer than the time the attacker has been on the right
path to maintain the binding.

- Christian

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

---

From: Christian Vogt <[email-masked]>
Date: Fri, 31 Mar 2006 22:17:03 -0600

Hi Fan,

thanks for reviewing draft-arkko-mipv6-binding-lifetime-extension-00!

Jari did already respond to the first part of your comments.  I will
attend to the rest in the following.

> This draft (BLE in short) proposes to extend the binding lifetime in
> order to reduce the signaling overhead and battery consumption when
> MN does not change its location. In Section 5 of draft-zhao- 
> mobopts-rr-ext-00 (rrext in short, and draft-zhao-mip6-rr-ext-01 as
> well) we also consider this case. Below is a short comparison.
> 
> By doing so, BLE needs less memory, but BLE is still vulnerable to
> the eavesdroppers on both MN-CN and HA-CN path. 

Right.  Actually, being on the HA-CN path, plus the ability to send
messages from there, is already sufficient to impersonate a MN (which
may also be a stationary node, BTW).  But that's a property of the RR,
too.  And as Jari has mentioned, the objective of BLE is to extend the
binding lifetime, not to provide better security than the RR.

>                                                 rrext does need to
> allocate more memory to keep the unused hash chain elements, but MN
> can easily re-generate the hash chain once the old one is depleted
> and the memory and hash operation are cheap nowadays. For example,
> assume that a hash element is 16 bytes, 1 M memory can keep hash
> elements enough for many days use. 

I don't think the memory is such a big deal for rrext.  It's just a bit
of a disadvantage that the MN must start over from the very beginning
when its hash elements are used up.

>                                    Also rrext can detect the
> eavesdropper on both MN-CN and HA-CN path.

This is based on the assumption that the MN and the CN never lose state.
 You propose that the hash elements must be kept in stable storage.
Where this is feasible, yes, rrext is immune against an attacker on the
HA-CN path.

Having said that, I'm still a bit sceptical about not having a fallback
mechanism.  In scenarios where stable storage at both the MN and the CN
is not feasible, the fallback mechanism would allow an attacker on the
HA-CN path to reset the hash chain.  (It is always like that because the
fallback mechanism will, by definition, have to work without knowledge
of the hash chain.)  Therefore, the existence of a fallback mechanism
would in fact eliminate rrext's immunity against attackers on the HA-CN
path.

> long time, but rrext benefits MN under any mobility pattern.

Wait a moment:  Be it BLE or rrext, the MN will have to register anew
when it changes its c/o address.  Also in both cases, the new binding
lifetime is always higher (modulo a small start-up period in BLE) than
the lifetime in RFC3775.

Note that, in BLE, a new lifetime is calculated as 0.3*t, where t is the
*total* time during which the binding has been in existance.  It is not
just the lifetime used during the previous registration, neither is it
reset in case the c/o address changes.  In other words, t may cover
multiple registrations for multiple c/o addresses.

> lifetime, but rrext does not.

But that is a matter of choosing protocol-configuration variables, right?

> (256*8)bits/(7*60)seconds = 4.9 bits/second constantly.

Ok.

> time period where the amount of power consumed is equal to c1*f(the
> number of bits sent and received during BU with CN) + c2*g(the length
> of time period when MN is awake to send the packets.) + other
> consumptions.

Right.  You can also compare just the signaling overhead during a
certain time period.  That would actually be more meaningful IMO.

> rrext sends and receives fewer bits than BLE and spends less time as
> well because of home address test procedure in BLE while the lifetime
> in BLE may be longer than in rrext.

Are you saying that rrext omits the home-address test?

- Christian

Fan Zhao wrote:
> In BLE and rr-ext (either mip6-rr-ext or mobopts-rr-ext) the way hash
> chain is used is different. rr-ext utilizes the one-way attribute of
> hash function to authenticate the identity without home address test
> thus hash chain elements are generated firstly and are used in the
> reverse order from being generated; while BLE uses hash operation to
> associate with the previous binding and aggregate a sequence of
> bindings together, thus hash elements are generated in the
> chronological order.
> 
> It is not just a coincidence that both drafts uses hash function, but
> it means that hash function has some values in RR test, right?
> 
> If I understand this correctly, the overhead is reduced to 0.1
> bit/second when the lifetime is 8 hour. I think other metrics are
> also useful, for example, how long does it take for MN to achieve an
> 8-hour lifetime and to reduce the overhead to 0.1 bits/second, what 
> Then the total waiting time is 2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1) =
> 1593 minutes = 26.55 hours.
> 
> The average overhead is (376*n bytes)/(2.1 + 2.1*1.3 + ... +
> 2.1*1.3^(n-1)) when 2.1*1.3^(n-1)<=8*60.
> 
> previous access network.), which opens a larger vulnerable window and
> thus is still very profitable for attackers.
> 
> vulnerable to the eavesdroppers on both MN-CN and HA-CN path.
> 
> Authorization Option. I think probably the sequence number field in
> BU message can be reused for this purpose, thus no need to define a
> new field.
> 
> This draft (BLE in short) proposes to extend the binding lifetime in
> order to reduce the signaling overhead and battery consumption when
> MN does not change its location. In Section 5 of draft-zhao- 
> mobopts-rr-ext-00 (rrext in short, and draft-zhao-mip6-rr-ext-01 as
> well) we also consider this case. Below is a short comparison.
> 
> By doing so, BLE needs less memory, but BLE is still vulnerable to
> the eavesdroppers on both MN-CN and HA-CN path. rrext does need to
> allocate more memory to keep the unused hash chain elements, but MN
> can easily re-generate the hash chain once the old one is depleted
> and the memory and hash operation are cheap nowadays. For example,
> assume that a hash element is 16 bytes, 1 M memory can keep hash
> elements enough for many days use. Also rrext can detect the
> eavesdropper on both MN-CN and HA-CN path.
> 
> time period where the amount of power consumed is equal to c1*f(the
> number of bits sent and received during BU with CN) + c2*g(the length
> of time period when MN is awake to send the packets.) + other
> consumptions.
> 
> rrext sends and receives fewer bits than BLE and spends less time as
> well because of home address test procedure in BLE while the lifetime
> in BLE may be longer than in rrext.
> 
> Sicnerely, fan