-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
> 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.
> 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 protected] || [email protected]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJSS7WSAAoJEJbuqe/Qdv/xX1kIALG7TGSxToeaQRejvhGlGaqh
xH1/Jl4okjqihShVpPDac1HajcVA9tHrL8g886+l9sXW2LEH+IQLKocZv3E0uXgq
uDw6Lf/27X9NfUBDMkgLE1P/+VbK0o3q+Q7YWxnyNNYcy43Ya2zsj19CfskoRBQc
K0gpbhnHBBc5e2bBZP9sm0S1bvXKb6tQ3/Ti+2Ow76Bp/CjdvbEPLAzG6nczMjER
RfskaIyFeEWFeld1qjlSYdRJlf2LoFzfWql++UIX9VNcX13EFT4AwPnuruD3XAxj
AkOe9Po0fydNScQC09wWR8DExzG3sRk8ZFAu/l9cKdh3dVhc/nOLatjnPlf9wXI=
=erpf
-----END PGP SIGNATURE-----
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
