Subject: Benoit Claise's Discuss on draft-ietf-6man-oversized-header-chain-08: (with DISCUSS and COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Sun, 17 Nov 2013 14:03:32 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-6man-oversized-header-chain-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

DISCUSS:

RFC 1981:
   IPv6 nodes SHOULD implement Path MTU Discovery in order to discover
   and take advantage of paths with PMTU greater than the IPv6 minimum
   link MTU [IPv6-SPEC]. 

draft-ietf-6man-oversized-header-chain:

   Hosts MAY discover the Path MTU, using procedures such
   as those defined in [RFC1981] and [RFC4821].

So bug, or is the intend for this document to update RFC 1981?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1.
Please engage in the discussion for this one if you disagree.
Abstract

   In those scenarios in which the IPv6 header
   chain or options are unusually long and packets are fragmented, or
   scenarios in which the fragment size is very small, the first
   fragment of a packet may fail to include the entire IPv6 header
   chain. 

I was confused by or in "IPv6 header chain or options".
The options are the hop-by-hop and destination header options, right?
So these are part of the Extension Header, so the IPv6 Header Chain
already, no?
Proposal:
OLD:
         IPv6 header chain or options
NEW:
       IPv6 header chain (including options)

Same remark for

   This document updates the set of IPv6
   specifications to create an overall limit on the size of the
   combination of IPv6 options and IPv6 Extension Headers that is
   allowed in a single IPv6 packet. 

2.
OLD:

   This specification allows nodes that drop the aforementioned packets
   to signal such packet drops with ICMPv6 "Parameter Problem, IPv6
   first-fragment has incomplete IPv6 header chain" (Type 4, Code TBD)
   error messages.

NEW:
   This specification allows nodes or intermediate systems that drop the
aforementioned packets
   to signal such packet drops with ICMPv6 "Parameter Problem, IPv6
   first-fragment has incomplete IPv6 header chain" (Type 4, Code TBD)
   error messages.

3.
In section 4, it would nice to add: "not an issue for statefull
middleboxes"
For this comment, take it or leave it

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Nov 2013 11:44:26 +1300

Personally, I think the intent should be to say:

"Hosts might discover the Path MTU, using procedures such
as those defined in [RFC1981] and [RFC4821]."

The point is that PMTUD often fails anyway, so the MUST
in 1981 (and the fact that 4821 doesn't formally update
1981 either) is a bit irrelevant.

Good catch though!

   Brian

On 18/11/2013 11:03, Benoit Claise wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 18 Nov 2013 00:00:25 +0100

Hi Brian,
> as those defined in [RFC1981] and [RFC4821]."
Removing the MAY solves my issue (MAY versus SHOULD)
I believe it's better to say

    "Hosts discover the Path MTU, using procedures such
    as those defined in [RFC1981] and [RFC4821]."

but no strong feelings about this one. I let the responsible AD decides.
> 1981 either) is a bit irrelevant.
That's a SHOULD, not a MUST.

Regards, Benoit
> .

---

From: Fernando Gont <[email-masked]>
Date: Mon, 18 Nov 2013 06:47:54 +0530

Hi, Benoit,

> So bug, or is the intend for this document to update RFC 1981?

The idea was that we didn't want to mantate PMTUD in this document
(i.e., this document is not about whether you should PMTUD or not).

However, I see your point and wouldn't mnd s/MAY/SHOULD/ if yu think
that's the proper way to address your concern.

Or even just "IPv6 header chain"?

>    allowed in a single IPv6 packet. 

I'd probably use just "IPv6 header chain" here, as above.

>    first-fragment has incomplete IPv6 header chain" (Type 4, Code TBD)

"nodes" stands for "host or routers". I believe this term is used
troughout the IPv6 specs.

> For this comment, take it or leave it

Ok.

Thanks so much! (and thanks a lot for actually proposing a way to
address your concerns!).

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 18 Nov 2013 08:26:14 +0100

> that's the proper way to address your concern.
As discussed with Brian, the proper way is to remove MAY  and refer to 
RFC1981 for the spec.
> Or even just "IPv6 header chain"?
That's the ideal solution + if you want to be complete, a reminder in 
the intro that the options hop-by-hop and destination header are 
variable length
> troughout the IPv6 specs.
If it's clear for everybody, then fine.
Regards, Benoit

---

From: Brian Haberman <[email-masked]>
Date: Mon, 18 Nov 2013 09:21:50 -0500

> but no strong feelings about this one. I let the responsible AD decides.

I think the above re-wording captures the correct idea wrt deferring to
RFCs 1981 and 4821.

Regards,
The responsible AD

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 18 Nov 2013 19:27:17 +0000

Brian,

This rewording works for me. Can we handle it with an RFC editor's note or will we need to spin a new version.

                                   Ron

> -----Original Message-----
> From: Brian Haberman [mailto:[email-masked]]
> Sent: Monday, November 18, 2013 9:22 AM
> Cc: [email-masked];
> [email-masked]
> Subject: Re: Benoit Claise's Discuss on draft-ietf-6man-oversized-
> header-chain-08: (with DISCUSS and COMMENT)
> 
> 
> >> "Hosts might discover the Path MTU, using procedures such as those
> >> defined in [RFC1981] and [RFC4821]."
> > Removing the MAY solves my issue (MAY versus SHOULD) I believe it's
> > better to say
> >

---

From: Brian Haberman <[email-masked]>
Date: Mon, 18 Nov 2013 17:39:08 -0500

I can put it in as an RFC Editor's note.  If other feedback warrants an
update, it can be incorporated then.

Regards,
Brian

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 18 Nov 2013 22:51:26 +0000

wfm

> Sent: Monday, November 18, 2013 5:39 PM
> To: Ronald Bonica
> > This rewording works for me. Can we handle it with an RFC editor's
> note or will we need to spin a new version.
> >
> >                                    Ron
> >
> >
> >> I think the above re-wording captures the correct idea wrt deferring
> >> to RFCs 1981 and 4821.
> >>
> >> Regards,
> >> The responsible AD
> >

---

From: Brian Haberman <[email-masked]>
Date: Thu, 21 Nov 2013 17:29:13 -0500

All,
     So, this document is approved but pending several edits.  As I see
it, there are changes needed for:

- Benoit's DISCUSS point (tentatively targeted as an RFC Editor's Note)

- Barry's comment on directing the RFC Editor to replace the TBD's with
the IANA assigned values

- Benoit's 2nd and 3rd points

- *Possible* some text in the Security Considerations section to address
Stewart's comment, just not sure what needs to be said

Given the number of changes, I would prefer if the authors spun a new
version.  Does that work for everyone?

Regards,
Brian

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 22 Nov 2013 02:40:43 +0000

Brian,

Thanks for seeing this through. Look for a new version in a few days.

Regarding Stewart's comment, would the following work:

OLD>
This document describes how improperly-fragmented packets can prevent traditional stateless packet filtering.
This document updates RFC 2460 such that those packets are forbidden, thus enabling stateless packet filtering for IPv6.
<OLD

NEW>
No new security exposures or issues are raised by this document. This document describes how undesirably-fragmented packets can evade stateless packet filtering. Having made that observation, this document updates RFC 2460 so that so undesirably-fragmented packets are forbidden. Therefore, a security vulnerability is removed.
<NEW

                                                 Ron

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Thursday, November 21, 2013 5:29 PM
> To: [email-masked]
> Cc: [email-masked]
> - *Possible* some text in the Security Considerations section to
> address Stewart's comment, just not sure what needs to be said
> 
> >> I can put it in as an RFC Editor's note.  If other feedback warrants
> >> an update, it can be incorporated then.
> >>
> >> Regards,
> >> Brian
> >>
> >>>>>> "Hosts might discover the Path MTU, using procedures such as
> >>>>>> those defined in [RFC1981] and [RFC4821]."
> >>>>> Removing the MAY solves my issue (MAY versus SHOULD) I believe
> >>>>> it's better to say
> >>>>>
> >>>> I think the above re-wording captures the correct idea wrt
> >>>> deferring to RFCs 1981 and 4821.
> >>>>
> >>>> Regards,
> >>>> The responsible AD
> >>>
> >

---

From: Brian Haberman <[email-masked]>
Date: Fri, 22 Nov 2013 08:20:21 -0500

Hi Ron,

> No new security exposures or issues are raised by this document. This document describes how undesirably-fragmented packets can evade stateless packet filtering. Having made that observation, this…

The above works for me.

Regards,
Brian