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

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.
> 
> 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. 

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.

> 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.

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.

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

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

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

Ok.

> 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.

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

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

Fan Zhao wrote:
> 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
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts