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

[Fernando Gont <[e-mail]>]

Hi, Brian,

On 08/24/2015 10:00 AM, Brian Haberman wrote:
>>> 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?

You're right: we should mention this explicitly.




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

Frag ID is generated ("Identification" recomputed) for each fragmented
packet. for any given (src, dst), F() will be constant.

So the idea is that F() provides a radom number/offset, which will
remain constant for each pair (src, dst). Since "counter" is a "line",
"Identification" is esentially:

ID = m x + b = counter + F()

i.e. a line with a random offeset.


The reason for using this algorithm is that it results in a sequence
that is not predictable by an off-path attacker. However, since
sbsequent identifications are simply monotonically-increasing numbers
(as a result of counter), the frag id collision rate will be wayyyy
lower than that of simply randmizing the IDs (the collission rate is the
same as that of a global counter).



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

They are "randomly selected", but, as with F(), for each (src ip, dst
ip), you will always select the same counter. So unless another flow
happens to use the same counter, if you receive one fragmented packet
with a frag ID of "M", the next frag packet will have an ID of "M+1".

(again, the reason for this is as before: reduce the frag id reuse
frequency, so that yu get the same frequency as a global counter, but
without its sec implications).

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492