Subject: AD Evaluation: draft-ietf-6man-oversized-header-chain

From: Brian Haberman <[email-masked]>
Date: Tue, 01 Oct 2013 15:16:24 -0400

All,
     I have completed my AD evaluation for
draft-ietf-6man-oversized-header-chain.  I found the document to be
concise and well-written.  Thank you.

     I only have a few things I would like to see addressed prior to
starting an IETF Last Call on this document.

1. The 2nd paragraph of Section 4 (Motivation) could be made more clear.
 For example, you could indicate if the example first fragment does or
does not match the stateless firewall rule.  It is inferred that the
first fragment does not match the target TCP port since it was dropped,
but I like to err on the explicit side.  As an aside, wouldn't the
subsequent fragments be dropped as well or does the IP destination match
the forward rule?

2. I would like to get some clarification on the rule in section 5 that
says "A host that receives a first-fragment that does not satisfy the
above-stated requirement SHOULD discard that packet".  Can you provide
some justification for the SHOULD when you made it a MUST for a sending
node to ensure the upper-layer header is in the first fragment?  Are you
assuming some flexibility to support compatibility with older stacks?
If so, it would be good to have some guidance on what those stack
vendors should do.

3. Why is sending an ICMP error message a MAY?

4. It would be better to be explicit that a host sending an ICMP error
message is sending the same ICMP error specified for routers/middleboxes.

5. I would suggest adding a reference to 2460 for the 1280 minimum MTU
value.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Oct 2013 02:57:06 -0300

Hi, Brian,

On 10/01/2013 04:16 PM, Brian Haberman wrote:
> 1. The 2nd paragraph of Section 4 (Motivation) could be made more 
> clear. For example, you could indicate if the example first 
> fragment does or does not match the stateless firewall rule.  It
> is inferred that the first fragment does not match the target TCP
> port since it was dropped, but I like to err on the explicit side.

mmm.. no. The first fragment presents this sample scenario:

A firewall is configured to block traffic to some specific TCP port.
IN the presence of normal fragmented traffic where a packet is
destined to such port, the first fragment will be dropped, and th
others will be passed (the policy is applied only to the first
fragment, where the upper layer information is present).

In a pathological scenario (third paragraph), it is impossible to
apply the policy to the received fragments (because even the first
fragment does not contain the upper layer information).

> As an aside, wouldn't the subsequent fragments be dropped as well 
> or does the IP destination match the forward rule?

In the case of a stateless firewall, you only enforce the policy on
first-fragments, under the assumption that if you properly filter
them, the rest of the fragments won't reassemble into a complete
datagram, and hence they will be eventually dropped.

> 2. I would like to get some clarification on the rule in section 5 
> that says "A host that receives a first-fragment that does not 
> satisfy the above-stated requirement SHOULD discard that packet". 
> Can you provide some justification for the SHOULD when you made it 
> a MUST for a sending node to ensure the upper-layer header is in 
> the first fragment?  Are you assuming some flexibility to support 
> compatibility with older stacks?

We meant to allw some flexibility. Although, me, I'd make it a "MUST
discard", too.

> If so, it would be good to have some guidance on what those stack 

I think the idea is "well, if you have some weird scenario, you may
want to allow this packets" -- that's why we recommend to have a knob
to change this behavior in specific scenarios. -- me, I don't expect
this to be employed.

> 3. Why is sending an ICMP error message a MAY?

When this text was suggested, I think the idea was that since these
messages shouldn't really exist in a real network, you might want to
just drop them. Although I can see that you could argue that this
could/shuld be a "SHOULD" rather than a "MAY".

Thoughts?

> 4. It would be better to be explicit that a host sending an ICMP 
> error message is sending the same ICMP error specified for 
> routers/middleboxes.

You mean in addition to:
   If a host or intermediate system discards a first-fragment because it
   does not satisfy the above-stated requirements, and sends an ICMPv6
   error message due to the discard, then the ICMPv6 error message MUST
   be Type 4 ("Parameter Problem") and MUST use Code TBD ("First-
   fragment has incomplete IPv6 Header Chain").

?

> 5. I would suggest adding a reference to 2460 for the 1280 minimum 
> MTU value.

Will do.

Thanks!

Cheers,
- -- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian Haberman <[email-masked]>
Date: Wed, 02 Oct 2013 10:38:18 -0400

> fragment, where the upper layer information is present).

The example in draft specifically says "that a stateless firewall
discards all traffic received from an interface unless it destined for a
particular TCP port on a particular IPv6 address".

So, the example focuses on an ALLOW rule.  What I am saying is that the
example needs more details added to clarify why each action is taken.

> datagram, and hence they will be eventually dropped.

But the subsequent fragments need to match *some* part of the rule to
justify forwarding them.  As noted above, there just needs to be some
clarifications in the example.

> We meant to allw some flexibility. Although, me, I'd make it a "MUST

If the WG consensus was to allow some flexibility, it should be noted in
the text that the SHOULD is to allow for interoperability with legacy
stacks.

> to change this behavior in specific scenarios. -- me, I don't expect

Why would you say this is a weird scenario?  Especially during an early
deployment of this feature, I would suspect there to be a myriad of
stacks trying to interact.

This doesn't need explicit guidance on how to allow the flexibility, but
the text should point out that the flexibility is there for backwards
compatibility.

> could/shuld be a "SHOULD" rather than a "MAY".

I much prefer this type of error being reported to minimize long
timeouts.  In the end, it is up to the WG to decide.

>    fragment has incomplete IPv6 Header Chain").

I was more concerned with the nebulous text in the 2nd paragraph in
section 5.  Upon reconsideration, the 3rd paragraph is nebulous on the
message sent by middleboxes but the details are discussed paragraph 4.
So, this comment can be ignored.

Regards,
Brian

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 2 Oct 2013 14:55:33 +0000

Brian,

Thanks for the review. Please see responses, inline.....

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Haberman
> Sent: Tuesday, October 01, 2013 3:16 PM
> To: [email-masked]; 6man WG
> Subject: AD Evaluation: draft-ietf-6man-oversized-header-chain
> 
> All,
>      I have completed my AD evaluation for draft-ietf-6man-oversized-
> header-chain.  I found the document to be concise and well-written.
> Thank you.
> 
> clear.
> but I like to err on the explicit side.  

Does the following edit address your concern?

OLD> 
   For example, assume that a stateless firewall discards all traffic
   received from an interface unless it destined for a particular TCP
   port on a particular IPv6 address.  When this firewall is presented
   with a fragmented packet, and the entire header chain is contained
   within the first fragment, the firewall discards the first fragment
   and allows subsequent fragments to pass.  Because the first fragment
   was discarded, the packet cannot be reassembled at the destination.
   Insomuch as the packet cannot be reassembled, the forwarding policy
   is enforced.
<OLD

NEW>
   For example, assume that a stateless firewall discards all traffic
   received from an interface unless it destined for a particular TCP
   port on a particular IPv6 address.  When this firewall is presented
   with a fragmented packet that is destined for a different TCP port, 
   and the entire header chain is contained within the first fragment, 
   the firewall discards the first fragment and allows subsequent 
   fragments to pass.  Because the first fragment was discarded, 
   the packet cannot be reassembled at the destination. Insomuch as 
   the packet cannot be reassembled, the forwarding policy is enforced.
<NEW

> As an aside, wouldn't the
> subsequent fragments be dropped as well or does the IP destination
> match the forward rule?

They won't be dropped by the firewall filter because the firewall filter has no way of knowing the TCP port to which they are directed. (Remember, we are talking about a stateless firewall.)

However, they will be dropped by the destination IP stack because they cannot be reassembled.

> node to ensure the upper-layer header is in the first fragment?  Are
> you assuming some flexibility to support compatibility with older
> stacks?

I agree. This should be a MUST. 

> 3. Why is sending an ICMP error message a MAY?

On second thought, this should be a SHOULD. So, we have the following change, addressing your second and third points:

OLD>
   A host that receives a first-fragment that does not satisfy the
   above-stated requirement SHOULD discard that packet, and also MAY
   send an ICMPv6 error message to the source address of the offending
   packet (subject to the rules for ICMPv6 errors specified in
   [RFC4443]).
<OLD

NEW>
   A host that receives a first-fragment that does not satisfy the
   above-stated requirement MUST discard that packet, and also SHOULD
   send an ICMPv6 error message to the source address of the offending
   packet (subject to the rules for ICMPv6 errors specified in
   [RFC4443]).
<NEW

> message is sending the same ICMP error specified for

Does the following change address your comment:

OLD>
   If a host or intermediate system discards a first-fragment because it
   does not satisfy the above-stated requirements, and sends an ICMPv6
   error message due to the discard, then the ICMPv6 error message MUST
   be Type 4 ("Parameter Problem") and MUST use Code TBD ("First-
   fragment has incomplete IPv6 Header Chain").  The Pointer field
   contained by the ICMPv6 Parameter Problem message MUST be set to
   zero.
<OLD

NEW>
   If a host or intermediate system discards a first-fragment because it
   does not satisfy the above-stated requirements, and sends an ICMPv6
   error message due to the discard, then the ICMPv6 error message MUST
   be Type 4 ("Parameter Problem") and MUST use Code TBD ("First-
   fragment has incomplete IPv6 Header Chain").  The Pointer field
   contained by the ICMPv6 Parameter Problem message MUST be set to
   zero. Whether a host or intermediate system originates this ICMP message,
   its format is identical.
<NEW

> 5. I would suggest adding a reference to 2460 for the 1280 minimum MTU

Does the following change address your comment:

OLD>
   As a result of the above mentioned requirements, a packet's header
   chain length cannot exceed the Path MTU associated with its
   destination.  Hosts MAY discover the Path MTU, using procedures such
   as those defined in [RFC1981] and [RFC4821].  However, if a host does
   not discover the Path MTU, it MUST limit the header chain length to
   1280 bytes.  Limiting the header chain length to 1280 bytes ensures
   that the header chain length does not exceed the IPv6 minimum MTU.
<OLD

NEW>
As a result of the above mentioned requirements, a packet's header
   chain length cannot exceed the Path MTU associated with its
   destination.  Hosts MAY discover the Path MTU, using procedures such
   as those defined in [RFC1981] and [RFC4821].  However, if a host does
   not discover the Path MTU, it MUST limit the header chain length to
   1280 bytes.  Limiting the header chain length to 1280 bytes ensures
   that the header chain length does not exceed the IPv6 minimum MTU [RFC 2460].
<NEW

---

From: Brian Haberman <[email-masked]>
Date: Wed, 02 Oct 2013 11:22:54 -0400

Hi Ron,

>    the packet cannot be reassembled, the forwarding policy is enforced.

This works for me.

> They won't be dropped by the firewall filter because the firewall filter has no way of knowing the TCP port to which they are directed. (Remember, we are talking about a stateless firewall.)

In order to pass part of the rule, the destination IPv6 address would
have to match the filter, correct?  No changes needed in the text, just
making sure I understand the nuances.

> However, they will be dropped by the destination IP stack because they cannot be reassembled.

Agreed.

> I agree. This should be a MUST. 

If that is the WG consensus, that is fine.  The exchange with Fernando
indicated some interest in providing some flexibility to interact with
legacy stacks that don't support this spec yet.

I would suggest keeping it a SHOULD and adding a sentence or two that
about allowing flexibility for backwards compatibility.

>    packet (subject to the rules for ICMPv6 errors specified in

Works for me.

>    zero. Whether a host or intermediate system originates this ICMP message,

As I noted to Fernando, my confusion was with the text in the 2nd
paragraph.  No changes are needed, but I would not object to the above
change if the WG/authors thought it is useful.

>    that the header chain length does not exceed the IPv6 minimum MTU [RFC 2460].

That works.

Brian

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 2 Oct 2013 16:23:15 +0000

Hi Brian,

So, merging in you last set of comments, the next draft version will include the changes listed below. Please tell me if these work for you.

                                    Ron

OLD> 

NEW>

OLD>

NEW>
   By default, a host that receives a first-fragment that does not satisfy the
   above-stated requirement MUST discard that packet. However, host implementations
   may include a configuration option that allows them to accept such fragments.

   Furthermore, a host that receives a first-fragment that does not satisfy the
   above-stated requirement SHOULD send an ICMPv6 error message to the source 
   address of the offending packet (subject to the rules for ICMPv6 errors specified in
   [RFC4443]).
<NEW

OLD>

NEW>

OLD>

NEW>

> From: Brian Haberman [mailto:[email-masked]]
> Sent: Wednesday, October 02, 2013 11:23 AM
> To: [email-masked]
> Cc: 6man WG
> Subject: Re: AD Evaluation: draft-ietf-6man-oversized-header-chain
> 
> Hi Ron,
> 
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Brian Haberman
> >>  For example, you could indicate if the example first fragment does
> >> or does not match the stateless firewall rule.  It is inferred that
> >> the first fragment does not match the target TCP port since it was
> >> dropped, but I like to err on the explicit side.
> >
> > They won't be dropped by the firewall filter because the firewall
> > filter has no way of knowing the TCP port to which they are directed.
> > (Remember, we are talking about a stateless firewall.)
> >
> 
> >> Can you provide some justification for the SHOULD when you made it a
> >> MUST for a sending node to ensure the upper-layer header is in the
> >> first fragment?  Are you assuming some flexibility to support
> > On second thought, this should be a SHOULD. So, we have the following
> change, addressing your second and third points:
> >
> > OLD>

---

From: Brian Haberman <[email-masked]>
Date: Wed, 02 Oct 2013 12:35:44 -0400

Hi Ron,

Agreed.

>    address of the offending packet (subject to the rules for ICMPv6 errors specified in

The MUST+however confuses me.  To me, that just reduces to a SHOULD.
How about:

A host that receives a first-fragment that does not satisfy the
above-stated requirement SHOULD discard the packet (e.g., including a
configuration option that allows such fragments to be accepted for
backwards compatibility) and SHOULD send an ICMPv6 error message to the
source address of the offending packet (subject to the rules for ICMPv6
errors specified in [RFC4443]).

?

Agreed.

Agreed.

Regards,
Brian

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 2 Oct 2013 17:14:25 +0000

Brian,

This works for me. So, the complete list of changes follows. Do these work for you?

                                  Ron

CHANGES
=======
OLD> 

NEW>

OLD>

NEW>
  A host that receives a first-fragment that does not satisfy the above-
  stated requirement SHOULD discard the packet (e.g., including a
  configuration option that allows such fragments to be accepted for
  backwards compatibility) and SHOULD send an ICMPv6 error message to the
  source address of the offending packet (subject to the rules for ICMPv6
  errors specified in [RFC4443]).
<NEW

OLD>

NEW>

OLD>

NEW>

> Sent: Wednesday, October 02, 2013 12:36 PM
> > So, merging in you last set of comments, the next draft version will
> include the changes listed below. Please tell me if these work for you.
> >
> >                                     Ron
> >

---

From: Brian Haberman <[email-masked]>
Date: Wed, 02 Oct 2013 13:17:04 -0400

Ron,

> This works for me. So, the complete list of changes follows. Do these work for you?

Works for me!

Brian

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 2 Oct 2013 17:19:26 +0000

Brian,

Thanks much. We will produce an updated draft version ASAP.

                               Ron

> Sent: Wednesday, October 02, 2013 1:17 PM

---

From: Tom Taylor <[email-masked]>
Date: Wed, 02 Oct 2013 19:50:41 -0400

Just a trivial change: "including" -> "subject to"

> This works for me. So, the complete list of changes follows. Do these work for you?
...
>    stated requirement SHOULD discard the packet (e.g., including a
                                                          ^^^^^^^^^
>    errors specified in [RFC4443]).
...

---

From: Fernando Gont <[email-masked]>
Date: Fri, 04 Oct 2013 02:56:31 -0300

> Just a trivial change: "including" -> "subject to"

Agreed. But I can fix it this after IETF LC or even durng AUTH48.

Thanks!

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