ietf
[Top] [All Lists]

Re: TSVART review of draft-ietf-6man-deprecate-atomfrag-generation

2016-08-28 03:08:02
Hello, Joe,

Thanks so much for your review! -- Please find my responses in-line...

On 08/26/2016 04:29 PM, Joe Touch wrote:

Document: draft-ietf-6man-deprecate-atomfrag-generation 
Title: Generation of IPv6 Atomic Fragments Considered Harmful
Reviewer: J. Touch
Review Date: August 26, 2016
IETF Last Call Date: August 8, 2016

Summary: This draft is on the right track but has open issues, described
in the review.

The document has no issues directly applicable to transport protocols.
The impact on transports is indirect, in the ability of RFC 6145-style
IPv6/IPv4 translators to support IPv6-to-IPv4 translation and deal with
IPv4-side fragmentation.

However, there are some important non-transport issues that are noted below.

Major issues:

The impact of this change does not appear to have been explored. Section
3 ends with a claim that links where this translation issue would be a
problem are rare, but there is no evidence presented as to whether
current RFC 6145 translators would be capable of complying with the
changes in this doc, e.g., to be able to generate IPv4 IDs as needed.
I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4
ID generation MUST be supported (and used), rather than MAY.

RFC 6145 has been revised as RFC7915.



The document concludes that the translator should create IPv4 IDs rather
than relying on atomic fragments as a source of that information (as per
RFC2460) because there is no benefit, but are two reasons why this
method is directly hazardous as well: 1) RFC 2460 does not require that
the IPv6 ID field is generated to ensure that the low 16-bits are unique
as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145
translation could result in collisions where two distinct IPv6
destinations are translated into the same IPv4 address, such that IDs
that might have been generated to be unique in the IPv6 context could
end up colliding when used in the translated IPv4 context. I.e., this
does not require ECMP as implied in Section 3.

mmm.. not sure I follow. When we refer to ECMP in Section 3 we're
actually describing the only possible scenario in which relying on the
ID in the Frag Header could be of use (i.e., possibly result in lower
collision rates).




Minor issues:

IMO, it remains unwise to continue to imply that networks should treat
packets with fragment headers as an attack. Fragmentation support is
critical to tunneling (see draft-ietf-intarea-tunnels) and we need to
find ways to support their use safely. The text should be edited to
explain that the primary motivation here is to avoid generating
erroneous IPv4 ID fields, rather than to react to the incorrect
classification of fragment headers as incompatible with the Internet.

Not sure what you mean.

We're not implying that packets employing FH are an attack. FWIW, I
don't personally think so. We do think that, when employing
fragmentation, you open the door to a number of attack vectors. See
e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt.



The claim that links with IPv6 MTUs smaller than 1260 are rare needs to
be supported with evidence. I appreciate that such evidence may be
difficult to observe. In the absence of evidence, the statement should
be more clear that there is no evidence to the contrary -- which is not
the same as being able to claim that they *are* in fact rare.

I see your point. Any suggestion on how to tweak the text?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492