On Wed, Oct 16, 2013 at 1:54 PM, Templin, Fred L
<Fred(_dot_)L(_dot_)Templin(_at_)boeing(_dot_)com> wrote:
On Wed, Oct 16, 2013 at 12:45 PM, Templin, Fred L
<Fred(_dot_)L(_dot_)Templin(_at_)boeing(_dot_)com> 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