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

[Christian Vogt <[e-mail]>]

Hi Jari, hi Fan,

one thing up front:

>> 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"?

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/



Jari Arkko wrote:
> Hi Fan and thanks for your review. Inline:
> 
> 
>>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? 
>> 
>>
> 
> 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.
> 
> 
>>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.
>> 
>>
> 
> 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.
> 
> 
>>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,
>>
> 
> Right.
> 
> 
>>what
>>is average overhead (bit/second)? Depending on the mobility pattern,
>>MN may not have the opportunity to enjoy the very low overhead.
>> 
>>
> 
> Yes.
> 
> 
>>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.
>> 
>>
> 
> 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.
> 
> 
>>>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.
>> 
>>
> 
> True. But this depends on the selection of the parameters -- see
> also below.
> 
> 
>>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"?
>> 
>>
> 
> 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.
> 
> 
>>6. The computation of Kcredit in the extended RR test is still
>>vulnerable to the eavesdroppers on both MN-CN and
>>HA-CN path.
>> 
>>
> 
> 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.
> 
> 
>>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.
>> 
>>
> 
> Sure.
> 
> 
>>8. The modified RR test procedure still needs to pass through home
>>agent.
>> 
>>
> 
> Yep.
> 
> 
>>9. The draft may also consider utilizing the fact that MN does not
>>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
> 
> 

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