Subject: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 02 May 2016 20:17:26 +0200

Hi,

I am an assigned INT directorate reviewer for draft-ietf-6man-
deprecate-atomfrag-generation-06.txt. These comments were written
primarily for the benefit of the Internet Area Directors. Document
editors and shepherd(s) should treat these comments just like they
would treat comments from any other IETF contributors and resolve them
along with any other Last Call comments that have been received. For
more details on the INT Directorate, see http://www.ietf.org/iesg/direc
torate.html.

Overall, the document is mature, well written and I find it useful. I
do not see any reason to hold up publication.

Some minor detailed suggestions follow:

- Section 1: The text says: 'Section 5 of [RFC2460] states that, when a
host receives an ICMPv6 "Packet Too Big" message [RFC4443] advertising
an MTU smaller than 1280 bytes (the minimum IPv6 MTU), the host is not
required to reduce the assumed Path-MTU, but must simply include a
Fragment Header in all subsequent packets sent to that destination.'

RFC2460 actually says 'In response to an IPv6 packet that is sent to an
IPv4 destination (i.e., a packet that undergoes translation from IPv6
to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big
message reporting a Next-Hop MTU less than 1280.'

While the document states later that 'an IPv6 node cannot easily limit
its exposure to the aforementioned attack vector by only generating
IPv6 atomic fragments towards IPv4 destinations behind a stateless
translator', it would help the reader to add that piece of context from
the very beginning of the document.

- Section 2: Again, I think it would help adding the context about
RFC2460 using atomic fragments only for the purpose of helping an IPv6-
to-IPv4 translating router can obtain a suitable Identification value
to use in resulting IPv4 fragments.

- Section 3: when discussing IPv4 Identification collision rates, it
would be helpful adding some numbers/equations there to get an idea of
what rates we are talking about.

- Appendix A: what does 'Linux kernel current' mean? This is very
minor, as this section is probably to be removed, but in case it
remains after publication as RFC, current should be replaced by the
kernel version number.

Thanks,

Carlos

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 2 May 2016 18:33:53 +0000

A few other minor nits when I looked over this document:

In section 3:

- "2.  The IPv4  node ... 1260 bytes". It might be useful to indicate how this 1260 came to be (as someone might easily confuse this with a typo for 1280?). This is really 1280 still but because the IPv4 header is 20 bytes shorter than the IPv6 header, the figure is 1260 for IPv4 packets.

- The text "proposing as a workaround" is odd? Should "as" be dropped?

In section 6, "some of [the] tests" (the is missing). Not a bit deal as I'm sure RFC-Editor would fix.

- Bernie

-----Original Message-----
From: Int-dir [mailto:[email-masked]] On Behalf Of Carlos Jesús Bernardos Cano
Sent: Monday, May 02, 2016 2:17 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation

Hi,

I am an assigned INT directorate reviewer for draft-ietf-6man- deprecate-atomfrag-generation-06.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/direc torate.html.

Overall, the document is mature, well written and I find it useful. I do not see any reason to hold up publication.

- Section 1: The text says: 'Section 5 of [RFC2460] states that, when a host receives an ICMPv6 "Packet Too Big" message [RFC4443] advertising an MTU smaller than 1280 bytes (the minimum IPv6 MTU), the host is not required to reduce the assumed Path-MTU, but must simply include a Fragment Header in all subsequent packets sent to that destination.'

RFC2460 actually says 'In response to an IPv6 packet that is sent to an
IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280.'

While the document states later that 'an IPv6 node cannot easily limit its exposure to the aforementioned attack vector by only generating
IPv6 atomic fragments towards IPv4 destinations behind a stateless translator', it would help the reader to add that piece of context from the very beginning of the document.

- Section 2: Again, I think it would help adding the context about
RFC2460 using atomic fragments only for the purpose of helping an IPv6-
to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments.

- Section 3: when discussing IPv4 Identification collision rates, it would be helpful adding some numbers/equations there to get an idea of what rates we are talking about.

- Appendix A: what does 'Linux kernel current' mean? This is very minor, as this section is probably to be removed, but in case it remains after publication as RFC, current should be replaced by the kernel version number.

Thanks,

Carlos

_______________________________________________
Int-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-dir

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 May 2016 15:09:28 -0400

No problem, just wanted to make sure.  :)

On Mon, May 2, 2016 at 2:33 PM, Bernie Volz (volz) <[email-masked]> wrote:

> - "2.  The IPv4  node ... 1260 bytes". It might be useful to indicate how
> this 1260 came to be (as someone might easily confuse this with a typo for
> 1280?). This is really 1280 still but because the IPv4 header is 20 bytes
> shorter than the IPv6 header, the figure is 1260 for IPv4 packets.
>
> Subject: [Int-dir] INT area directorate review for
> draft-ietf-6man-deprecate-atomfrag-generation
>
> Hi,
>
> deprecate-atomfrag-generation-06.txt. These comments were written primarily
> for the benefit of the Internet Area Directors. Document editors and
> shepherd(s) should treat these comments just like they would treat comments
> from any other IETF contributors and resolve them along with any other Last
> Call comments that have been received. For more details on the INT
> Directorate, see http://www.ietf.org/iesg/direc torate.html.
>
> Overall, the document is mature, well written and I find it useful. I do
> not see any reason to hold up publication.
>
> host receives an ICMPv6 "Packet Too Big" message [RFC4443] advertising an
> MTU smaller than 1280 bytes (the minimum IPv6 MTU), the host is not
> required to reduce the assumed Path-MTU, but must simply include a Fragment
> Header in all subsequent packets sent to that destination.'
>
> IPv4 destination (i.e., a packet that undergoes translation from IPv6 to
> IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message
> reporting a Next-Hop MTU less than 1280.'
>
> While the document states later that 'an IPv6 node cannot easily limit its
> exposure to the aforementioned attack vector by only generating
> translator', it would help the reader to add that piece of context from the
> very beginning of the document.
>
> - Section 3: when discussing IPv4 Identification collision rates, it would
> be helpful adding some numbers/equations there to get an idea of what rates
> we are talking about.
>
> - Appendix A: what does 'Linux kernel current' mean? This is very minor,
> as this section is probably to be removed, but in case it remains after
> publication as RFC, current should be replaced by the kernel version number.
>
> Thanks,
>
> Carlos
>