[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. 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 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). Also, common security policy is "default deny" -- so if the attacker plays dirty, his packets will be dropped. > 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. Thanks, Fernando