Subject: Detailedl review of draft-ietf-6man-oversized-header-chain-06

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Sep 2013 10:21:21 +1200

The 6man chairs asked me to make an additional detailed review
of draft-ietf-6man-oversized-header-chain-06.

The main point of the draft is to point out the problems
caused by fragmented header chains and to update RFC 2460 to
require that the entire header chain is in the first fragment.

This change is an incremental step towards reducing operational
problems with IPv6 extension headers, so it's complementary to
draft-ietf-6man-ext-transmit. It's also an incremental step
towards reducing operational problems with IPv6 fragmentation.
Since the rest of the fragmentation problem remains controversial,
I think it's better to progress draft-ietf-6man-oversized-header-chain
on its own ASAP. (We do have to be realistic though - none of these
improvements will become widely deployed until many IPv6 stacks have
gone through several release cycles.)

IMHO this document is ready to progress, but I did find 3 minor issues
and a nit.

Issues:

In the Introduction:

>    It should be noted that this requirement does not preclude the use of
>    e.g.  IPv6 jumbo payloads but instead ...

Firstly, RFC2675 says "The Jumbo Payload option must not be used in a packet
that carries a Fragment header."

Secondly using "e.g." as a noun is a bit ugly. I suggest:

 It should be noted that this requirement does not preclude the use of
 large payloads but instead ...

In Terminology:

>   IPv6 Header Chain:
> 
>       The header chain contains an initial IPv6 header, zero or more
>       IPv6 extension headers, and optionally, a single upper-layer
>       header.  If an upper-layer header is present, it terminates the
>       header chain.

Maybe the "optionally" would be clearer if you also mentioned the
"No Next Header" case by extending the last sentence

 If an upper-layer header is present, it terminates the header
 chain; otherwise the "No Next Header" value terminates it.

I think it would be useful to mention somewhere (perhaps in
Security Considerations) that stateless DPI may still cause problems.
Something like:

 A firewall that performs stateless deep packet inspection, i.e.,
 it examines application payload content, might still be unable to
 correctly process fragmented packets, even if the IPv6 header
 chain is not fragmented.

Nit:

The reference [IANA-PROTO] needs to be verified by IANA - what is their
preferred URL for the registry?

Regards
   Brian Carpenter

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 5 Sep 2013 16:13:54 +0000

Brian,

Would the following edits address the issues that you raise?

                              Ron

EDITS
=====

OLD>
It should be noted that this requirement does not preclude the use of e.g.  IPv6 jumbo payloads but instead merely requires that all *headers*, starting from IPv6 base header and continuing up to the upper layer header (e.g.  TCP or the like) be present in the first fragment.
<OLD
NEW>
It should be noted that this requirement does not preclude the use of large payloads but instead but instead merely requires that all headers, starting from IPv6 base header and continuing up to the upper layer header (e.g.  TCP or the like) be present in the first fragment.
<NEW

OLD>
IPv6 Header Chain:

<OLD

NEW>
IPv6 Header Chain:

   The header chain contains an initial IPv6 header, zero or more
   IPv6 extension headers, and optionally, a single upper-layer
   header.  If an upper-layer header is present, it terminates the
   header chain; otherwise the "No Next Header" value terminates it.
<NEW

OLD>
As with all ICMPv6 error/diagnostic messages, deploying Source Address Forgery Prevention filters helps reduce the chances of an attacker successfully performing a reflection attack by sending forged illegal packets with the victim/target's IPv6 address as the
IPv6 Source Address of the illegal packet [RFC2827] [RFC3704].
<OLD

NEW>
As with all ICMPv6 error/diagnostic messages, deploying Source Address Forgery Prevention filters helps reduce the chances of an attacker successfully performing a reflection attack by sending forged illegal packets with the victim/target's IPv6 address as the
IPv6 Source Address of the illegal packet [RFC2827] [RFC3704].

A firewall that performs stateless deep packet inspection, i.e., examines application payload content, might still be unable to  correctly process fragmented packets, even if the IPv6 header  chain is not fragmented.
<NEW

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Wednesday, September 04, 2013 6:21 PM
> To: 6man
> Subject: Detailedl review of draft-ietf-6man-oversized-header-chain-06
> 
> The 6man chairs asked me to make an additional detailed review of
> draft-ietf-6man-oversized-header-chain-06.
> 
> The main point of the draft is to point out the problems caused by
> fragmented header chains and to update RFC 2460 to require that the
> entire header chain is in the first fragment.
> 
> problems with IPv6 extension headers, so it's complementary to draft-
> ietf-6man-ext-transmit. It's also an incremental step towards reducing
> operational problems with IPv6 fragmentation.
> Since the rest of the fragmentation problem remains controversial, I
> think it's better to progress draft-ietf-6man-oversized-header-chain
> Firstly, RFC2675 says "The Jumbo Payload option must not be used in a
> packet that carries a Fragment header."
> 
> Maybe the "optionally" would be clearer if you also mentioned the "No
> Next Header" case by extending the last sentence
> 
>  If an upper-layer header is present, it terminates the header  chain;
> otherwise the "No Next Header" value terminates it.
> 
> I think it would be useful to mention somewhere (perhaps in Security
> Considerations) that stateless DPI may still cause problems.
> Something like:
> 
>  A firewall that performs stateless deep packet inspection, i.e.,  it
> examines application payload content, might still be unable to
> correctly process fragmented packets, even if the IPv6 header  chain is
> not fragmented.
> 
> Nit:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Sep 2013 08:00:45 +1200

Hi Ron,

That looks good to me, thanks!

Regards
   Brian

---

From: t.petch <[email-masked]>
Date: Fri, 6 Sep 2013 12:42:15 +0100

---- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Ronald Bonica" <[email-masked]>
Cc: "6man" <[email-masked]>
Sent: Thursday, September 05, 2013 9:00 PM

> > Would the following edits address the issues that you raise?
<snip>
> >> preferred URL for the registry?

They are not saying:-(

In
draft-leiba-cotton-iana-5226bis-03
the nearest they come to saying, as far as I can see,  how a document
should reference a registry is

"      Providing a URL to precisely identify the registry helps IANA
      understand the request.  Such URLs are usually removed from the
      RFC prior to final publication."

Mmm one of those I-Ds which would benefit from discussion were there a
place designated for discussion.

Tom Petch

---

From: Fernando Gont <[email-masked]>
Date: Fri, 06 Sep 2013 09:28:21 -0300

> place designated for discussion.

This puzzles me. If the URL is removed prior to publication, I guess one
has to navigate IANA's site, or Google for he registry??

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Sep 2013 08:13:12 +1200

> has to navigate IANA's site, or Google for he registry??

Yes. In the ext-transmit draft, we just put the names of the
registries.

    Brian

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 6 Sep 2013 20:12:58 +0000

Tom,

I suspect that we will get this wrong and IANA will fix it during their review. Given that we don't know what the reference should look like, there is no sense guessing.

                                            Ron

> From: t.petch [mailto:[email-masked]]
> Sent: Friday, September 06, 2013 7:42 AM
> To: Brian E Carpenter; Ronald Bonica
> Cc: 6man
> Subject: Re: Detailedl review of draft-ietf-6man-oversized-header-
> chain-06
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 06 Sep 2013 21:01:55 -0300

> Yes. In the ext-transmit draft, we just put the names of the

Doesn't that make things ("slightly", if you want) harder for an
implementer?

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Sep 2013 16:33:34 +1200

> Doesn't that make things ("slightly", if you want) harder for an

I suppose, but IANA would have to solemnly swear never to change
the URL.

   Brian

---

From: Tom Taylor <[email-masked]>
Date: Sat, 07 Sep 2013 14:28:55 -0400

It's normal practice in other WGs I've worked with (e.g, AVT, MMUSIC). 
If you name the registry exactly as shown on the IANA page, implementors 
can always search for it. A URL is transitory, as the text vs. XML 
discussion shows.