On Wed, Oct 16, 2013 at 1:54 PM, Templin, Fred L <Fred.L.Templin@xxxxxxxxxx> wrote: >> 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. The point is that this is no worse than IPv4. And it is very likely that one of underlying encapsulations will be 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. Is it me, or there are actually a plethora of attack vectors an attacker would use (instead of this one) in such scenario? >> 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. That depends on whether extension headers are employed in different layer of encapsulation. Besides, what's the different between an attacker exceeding your hardcoded limit and traffic resulting in tunnling packets failing to include the entire header chain? As noted off-list, this hard limit becomes a BCP, rather than a std update: the larger your extension header chain, the higher the chances that your packets get dropped. For instance, your harcoded 1000 (or whatever) value means that there are still *lots* of boxes that will not be able to handle those packets properly, and hence will get dropped (check the 6man and/or v6ops discussions). Thanks, Fernando