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

[Fernando Gont <[e-mail]>]

Hi, Brian,

On 08/24/2015 09:18 AM, Brian Haberman wrote:
>> Thanks so much for your feedback! -- Please find my responses in-line....
>>
>> On 08/21/2015 08:16 PM, Brian Haberman wrote:
>>>      I have completed my AD evaluation of this draft as a part of the
>>> publication process.  I only have two comments/questions on this draft.
>>> Once those are resolved, it can move along in the publication process.
>>>
>>> * Section 4 says the following:
>>>
>>>    As a result, at least during the IPv6/IPv4 transition/co-existence
>>>    phase, it is probably safer to assume that only the low-order 16 bits
>>>    of the IPv6 Fragment Identification are of use to the destination
>>>    system.
>>>
>>> I think that statement is making an ill-advised generalization.  The
>>> above is true if one is looking at an atomic fragment. However, even if
>>> we are talking about a transition/co-existence phase, there will still
>>> be significant amounts of fragmented traffic between IPv6 nodes where
>>> the full 32 bits of the fragment id are useful. What was the rationale
>>> for the above generalization?
>>
>> The rationale is that, since you don't really know whether the remote
>> endpoint is really an IPv6 node or an IPv4 node behind a translator, the
>> only safe bet is to assume the worst ("it is a v4 node behind a
>> translator, and hence only the low order 16 bits are meaningful").
> 
> If you are generating atomic fragments, you have a pretty good idea that
> the lower 16 bits are the only ones that are meaningful.

Yes. But if you're generating, say, 1280-byte or even 1500-byte
fragments, you might still be going through a translator.

(i.e., yes, you're right that for the "I'm generating atomic fragments
case" you could infer that you're going through a translator... but
generating atomic fragments is not a necessary condition for going
through a translator -- e.g., think of an 1500-byte MTU on the IPv4 side).



> Has there been
> any data collected on the number of fragmented IPv6 packets that are
> destined for IPv4 nodes where the PMTU is >1280?  Or is this theoretical
> analysis?

I think you cannot really measure that, since you cannot really tell
from the IPv6 address that the corresponding packets are being translated.

So the question really boils down to "is the IPv4 Internet's MTU >1280
in many cases?" (and the answer is, of course, "yes")  -- (in such cases
atomic fragments will not be generated).


>>> * 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
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])

Please let me know if this clarifies your question...

Thanks!

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