Brian,
Would the following edits address the issues that you raise?
Ron
EDITS
=====
OLD>
It should be noted that this requirement does not preclude the use of e.g.
IPv6 jumbo payloads but instead merely requires that all *headers*, starting
from IPv6 base header and continuing up to the upper layer header (e.g. TCP or
the like) be present in the first fragment.
<OLD
NEW>
It should be noted that this requirement does not preclude the use of large
payloads but instead but instead merely requires that all headers, starting
from IPv6 base header and continuing up to the upper layer header (e.g. TCP or
the like) be present in the first fragment.
<NEW
OLD>
IPv6 Header Chain:
The header chain contains an initial IPv6 header, zero or more
IPv6 extension headers, and optionally, a single upper-layer
header. If an upper-layer header is present, it terminates the
header chain.
<OLD
NEW>
IPv6 Header Chain:
The header chain contains an initial IPv6 header, zero or more
IPv6 extension headers, and optionally, a single upper-layer
header. If an upper-layer header is present, it terminates the
header chain; otherwise the "No Next Header" value terminates it.
<NEW
OLD>
As with all ICMPv6 error/diagnostic messages, deploying Source Address Forgery
Prevention filters helps reduce the chances of an attacker successfully
performing a reflection attack by sending forged illegal packets with the
victim/target's IPv6 address as the
IPv6 Source Address of the illegal packet [RFC2827] [RFC3704].
<OLD
NEW>
As with all ICMPv6 error/diagnostic messages, deploying Source Address Forgery
Prevention filters helps reduce the chances of an attacker successfully
performing a reflection attack by sending forged illegal packets with the
victim/target's IPv6 address as the
IPv6 Source Address of the illegal packet [RFC2827] [RFC3704].
A firewall that performs stateless deep packet inspection, i.e., examines
application payload content, might still be unable to correctly process
fragmented packets, even if the IPv6 header chain is not fragmented.
<NEW
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Brian E Carpenter
> Sent: Wednesday, September 04, 2013 6:21 PM
> To: 6man
> Subject: Detailedl review of draft-ietf-6man-oversized-header-chain-06
>
> The 6man chairs asked me to make an additional detailed review of
> draft-ietf-6man-oversized-header-chain-06.
>
> The main point of the draft is to point out the problems caused by
> fragmented header chains and to update RFC 2460 to require that the
> entire header chain is in the first fragment.
>
> This change is an incremental step towards reducing operational
> problems with IPv6 extension headers, so it's complementary to draft-
> ietf-6man-ext-transmit. It's also an incremental step towards reducing
> operational problems with IPv6 fragmentation.
> Since the rest of the fragmentation problem remains controversial, I
> think it's better to progress draft-ietf-6man-oversized-header-chain
> on its own ASAP. (We do have to be realistic though - none of these
> improvements will become widely deployed until many IPv6 stacks have
> gone through several release cycles.)
>
> IMHO this document is ready to progress, but I did find 3 minor issues
> and a nit.
>
> Issues:
>
> In the Introduction:
>
> > It should be noted that this requirement does not preclude the use
> of
> > e.g. IPv6 jumbo payloads but instead ...
>
> Firstly, RFC2675 says "The Jumbo Payload option must not be used in a
> packet that carries a Fragment header."
>
> Secondly using "e.g." as a noun is a bit ugly. I suggest:
>
> It should be noted that this requirement does not preclude the use of
> large payloads but instead ...
>
> In Terminology:
>
> > IPv6 Header Chain:
> >
> > The header chain contains an initial IPv6 header, zero or more
> > IPv6 extension headers, and optionally, a single upper-layer
> > header. If an upper-layer header is present, it terminates the
> > header chain.
>
> Maybe the "optionally" would be clearer if you also mentioned the "No
> Next Header" case by extending the last sentence
>
> If an upper-layer header is present, it terminates the header chain;
> otherwise the "No Next Header" value terminates it.
>
> I think it would be useful to mention somewhere (perhaps in Security
> Considerations) that stateless DPI may still cause problems.
> Something like:
>
> A firewall that performs stateless deep packet inspection, i.e., it
> examines application payload content, might still be unable to
> correctly process fragmented packets, even if the IPv6 header chain is
> not fragmented.
>
> Nit:
>
> The reference [IANA-PROTO] needs to be verified by IANA - what is their
> preferred URL for the registry?
>
> Regards
> Brian Carpenter
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
