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: fg...@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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
