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

[Brian Haberman <[e-mail]>]

On 8/24/15 9:35 AM, Fernando Gont wrote:

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

As with secret1, where does it say that counter[] is a line?  Wouldn't
it make more sense to initialize counter[] to random values?  That makes
things even less guessable.

> 
> ID = m x + b = counter + F()
> 
> i.e. a line with a random offeset.
> 

I think there is a lot of missing explanatory text.  The above argues
that secret2 is also constant given your above statement.  And your
statement about counter[] being a "line" is no where in the draft.  When
I look at this:

ID = F(Src IP, Dst IP, secret1) + counter[G(src IP, Dst Pref, secret2)]

I can see a number of ways that an implementation could completely
randomize the ID selected so that no one could guess it.  For example,
secret1 or secret2 (or both) could be randomized (e.g., TOD).

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

Various research papers have talked about the number of packets
typically involved in a "flow" between a single pair of devices.  The
math would indicate that randomizing the Fragment ID selection across a
32-bit space given the number of packets in a flow provides a very low
probability of collision.

The destination clearly does not need to be able to guess what the next
Fragment ID would be, so there is no functional reason for the IDs to be
sequential.

My suggestion would be to state the assumptions you are making (e.g.,
secretX is constant, counter[] is a line), why you are making those
assumptions (e.g., ease of implementation), and the performance
tradeoffs you are making.

Regards,
Brian

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