On 10/2/13 1:57 AM, Fernando Gont wrote: > 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).
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.
>
> 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.
>
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.
>
>
>> 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 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.
>
>> If so, it would be good to have some guidance on what those stack
>> vendors should do.
>
> 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.
>
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.
>
>> 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?
>
I much prefer this type of error being reported to minimize long
timeouts. In the end, it is up to the WG to decide.
>
>> 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").
>
> ?
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
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
