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>
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
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>
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>
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
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
> -----Original Message-----
> From: Brian Haberman [mailto:[email protected]]
> Sent: Wednesday, October 02, 2013 11:23 AM
> To: [email protected]
> Cc: 6man WG
> Subject: Re: AD Evaluation: draft-ietf-6man-oversized-header-chain
>
> Hi Ron,
>
> On 10/2/13 10:55 AM, Ronald Bonica wrote:
> > Brian,
> >
> > Thanks for the review. Please see responses, inline.....
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:[email protected]] On Behalf
> >> Of Brian Haberman
> >> Sent: Tuesday, October 01, 2013 3:16 PM
> >> To: [email protected]; 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.
> >>
> >> 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.
> >
> > 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
> >
>
> This works for me.
>
> >> 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.)
> >
>
> 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.
>
> >>
> >> 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.
> >
> > 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.
>
> >>
> >> 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
> >
>
> Works for me.
>
> >
> >>
> >> 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.
> >
> > 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
> >
>
> 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.
>
> >>
> >> 5. I would suggest adding a reference to 2460 for the 1280 minimum
> >> MTU value.
> >
> > 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
>
> That works.
>
> Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
