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

[Fernando Gont <[e-mail]>]

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492