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

[Fernando Gont <[e-mail]>]

Hi, Brian,

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

I will clarify this in the next rev.


> Wouldn't
> it make more sense to initialize counter[] to random values?  That makes
> things even less guessable.

mmm..not really, since the randomness really comes from F(). But it
wouldn't hurt, either.


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

I will clarify this. And also note that this algorithm is designed after
RFC1948.



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

Given the considerations regarding translators, such math should be done
for 16-bit long Frag IDs, rather than 32-bit long Frag IDs (otherwise
you could get a much worse IPv4 frag id when you're dealing with
translators). Besides, while talking with Linux developers at the time,
a completely random() Frag ID wasn't sensible for them. And IIRC, the
same applies to OpenBSD.



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

The only reason for the Frag IDs being sequential is that such approach
minimizes the frag id reuse frequency.



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

Will do.

Thanks so much!

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