Hi Ron, That looks good to me, thanks!
Regards Brian On 06/09/2013 04:13, Ronald Bonica wrote: > 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 --------------------------------------------------------------------
