Hi Fernando, > -----Original Message----- > From: fgont.si6networks@xxxxxxxxx [mailto:fgont.si6networks@xxxxxxxxx] > On Behalf Of Fernando Gont > Sent: Wednesday, October 16, 2013 9:35 AM > To: Templin, Fred L > Cc: Ole Troan; Ronald Bonica; Brian E Carpenter; 6man- > chairs@xxxxxxxxxxxxxx; Ray Hunter; 6man Mailing List; ietf@xxxxxxxx; > Fernando Gont > Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> > (Implications of Oversized IPv6 Header Chains) to Proposed Standard > > [Resending in plain-txt -- my apologies... I was using a web > interface...] > > Fred, > > On Wed, Oct 16, 2013 at 12:45 PM, Templin, Fred L > <Fred.L.Templin@xxxxxxxxxx> wrote: > > I disagree with the header chain terminating as soon as another IPv6 > > header is encounter. That defeats defense-in-depth, since outer > > perimeter middleboxes would be forced to admit packets with > unexamined > > header chains inward to inner perimeter middleboxes. And, if the > > unexamined header chains contain bad stuff inserted by an attacker, > > the attack is successful. > > The same is true if the underlying encapsulation layer is IPv4. We should not default to doing as badly as IPv4. > Once > you're encapsulating, all bets are off in that respect. You should do > defense-in-depth at the tunnel ingress or egress points. Or, if you > wish, a middle-box could reassemble-inspect/filter-re-fragment If an outer perimeter middlebox connects to a 10Gbps link on its outward facing interface and a 64Kbps link on its inward facing interface, then the middlebox can allow a successful DOS attack against its protected domain if it does not look at headers beyond the outermost IPv6 header. > Note that no matter what hardcoded limit you enforce, an attacker > willing to evade you're security controls can always add an > extra-layer of encapsulation (assuming he controls that). Yes. With a 1024 limit on the amount of extension headers a host can add, approximately 5-6 encapsulations can be added before the tunnel headers cause the header chain to overflow the IPv6 minMTU. But, that means that there would still be 5-6 protected perimeters to penetrate before an attack could penetrate through to the innermost protected domain. This is considerable defense-in-depth. > Also, common > security policy is "default deny" -- so if the attacker plays dirty, > his packets will be dropped. Without looking past the outermost IP header, there is no way to discern the good stuff from the bad stuff. So, default deny will potentially drop good stuff. > > That requirement is also not observed by common middlebox systems > > such as Wireshark and tcpdump. Both will blast past encapsulating > > IPv6 headers through to the header chain inserted by the original > > host without stopping at the outermost IPv6 header. > > They do what a middle-box would do in this case: whatever part of the > header chain is there, it's up to you to inspect it. As noted by Ole, > when you tunnel over IP, IP becomes a link layer... so whatever > "defense in depth" techniques you're using, they should be prepared to > deal with scenarios in which a tunneled packet does not contain the > entire IPv6 header chain, since not all "link layers" (as IPv4 when > IPv6 is tuneled over IPv4) guarantee a minimum MTU of 1280 bytes. The 1024 proposal gives 256 bytes of room for encapsulation headers and still fit within the IPv6 minMTU - enough for 5-6 layers of defense in depth. This is part of the analysis I believe was missing when the IPv6 minMTU of 1280 was established. One clarification I would like to make is that I *like* the 1280 IPv6 minMTU and do not think it was a mistake. It was the missing analysis of what it means for tunnels that I think we are only now exploring. Thanks - Fred fred.l.templin@xxxxxxxxxx > Thanks, > Fernando