Re: AD Evaluation: draft-ietf-6man-predictable-fragment-id

[Brian Haberman <[e-mail]>]

On 8/24/15 8:43 AM, Fernando Gont wrote:

>>>> * Section 5.3's discussion of a hash-based id generation scheme says
>>>> this in the drawbacks:
>>>>
>>>>    o  Since the Fragment Identification values are predictable by the
>>>>       destination host...
>>>>
>>>> How are the ID values predicted by the destination host?  The source is
>>>> using secret values that presumably are not shared with the destination.
>>>> So how does this prediction work?
>>>
>>> These Frag ID values are predictable because the hash-based approach
>>> leads to a monotonically-increasing sequence (e.g., 1, 2, 3, 4) then
>>> it's easy to predict the sequence *by the destination host*. Of course,
>>> such sequence is not predictable by an off-path attacker.
>>>
>>
>> Monotonically-increasing?  The text in 5.3 clearly says:
>>
>>    With such a scheme, the Fragment Identification value of
>>    each fragment datagram would be selected with the expression...
>>
>> That, to me, indicates that each time a Fragment ID is generated, the
>> hash function is invoked.  How is it monotonically increasing if the
>> hash is invoked for each packet being fragmented?
> 
> A simplified version of the expression in Section 5.3 would be:
> 
>    Identification = F(Src IP, Dst IP, secret1)  +  counter.
> 
> 
> If you're receiviving packets from the same src IP, to your same dst IP,
> those two addresses will be constant. secret1 is also constant. Then the

Where in the text does it say that secret1 is constant?

As I noted in my last comment, it seems like the Fragment ID is
re-generated any time a Fragment Header is needed.  Is there any reason
why secret1 couldn't/shouldn't be changed each time a Fragment Header is
needed?


> expression results in:
> 
>  ID= F() + counter = random_number +  counter
> 
> 
> for each (src IP, dst IP) (whre "counter" is a variable that is
> incremented for each fragmented packet that is sent). Hence successive
> packets will contain monotonically-increasing IDs (say {1, 2, 3..} ,
> {345556, 345557, 345558,..} or whatever ).
> 
> 
> FWIW, the expression in Section 5.3 replaces the "counter" variable
> (from the simplified expression I wrote above) with an array of
> counters, such that we can avoid the use of a single global counter (to
> avoid e.g.  [Sanfilippo1998b] and [Sanfilippo1999])

Right, the counter[] contains 8K elements or more where an element is
randomly selected via a hash function.  If that is the case, how does
the destination know what the next Fragment ID will be?

Regards,
Brian