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
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
