Re: Predictable IP protocol values

It seems to me that the proposed document is a partial fix to a marginal 
problem.
Yes, I take it as given that if I followed the references I wind find 
descriptions of the attacks.  I do see how one could force fragmented 
packets if one knew that A was talking to B at the current moment.

However, it seems to me that in the vast majority of cases, if the 
attacker knows that A is talking to B, he can probably observe the 
packets between A and B (and it must be a conversation of many round 
trips to allow for observation, triggered behavior, and useful attack.) 
  As such, none of the specified solutions would seem to help much.

Hence, I am left concluding that the right answer is not to publish any 
recommendations in this space.

Yours,
Joel

On 4/27/2012 4:21 AM, Ole Trøan wrote:
> working group,
>
> [changed subject]
>
> in the context of http://tools.ietf.org/html/draft-gont-6man-predictable-fragment-id-02
> any opinion on how to proceed?
>
> - document covering predictable values in IETF protocols in general
> - document predictable IP ID fields in both IPv4 and IPv6
> - fix the predictable fragment ID problem in IPv6
> - do nothing?
>
> cheers,
> Ole
>
>
> On Apr 26, 2012, at 22:53 , Fernando Gont wrote:
>
>> Hi, Ole,
>>
>> On 04/26/2012 08:50 AM, Ole Trøan wrote:
>>>> I think that draft-gont-6man-predictable-fragment-id is also ready
>>>> for wg call for adoption as wg document -- I've rev'ed the
>>>> document since IETF 83 in response to the feedback received during
>>>> my presentation (i.e., just require the Frag ID to be
>>>> unpredictable, without mandating any particular algorithm).
>>>
>>> the chairs have an action item on taking this to the mailing list.
>>> there was an issue that I believe Bob raised, if we were going to
>>> have publish RFCs on every field in TCP/IP protocols that should
>>> have unpredictable values, or if we should have a generic
>>> recommendation applying to protocol design in general.
>>
>> I believe that a generic document about protocol design that discusses
>> this issue would be valuable, such that *new* protocols and protocol
>> implementations do not incur into this problem. However, in this
>> particular case (Fragment ID), the IPv6 standard itself is suggesting
>> to use a counter, and hence the spec should be fixed.
>>
>> That aside, different fields have different requirements. For example,
>> the constraints for randomizing the transport protocol ports are
>> different from those of producing unpredictable IDs, and different from
>> those of say, randomizing the TCP sequence numbers, or randomizing the
>> IPv6 Flow Label. The consequences of the particular approach that you
>> follow vary quite a bit in each case.
>>
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>