Hi Fernando,
-----Original Message-----
From: fgont(_dot_)si6networks(_at_)gmail(_dot_)com
[mailto:fgont(_dot_)si6networks(_at_)gmail(_dot_)com]
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(_at_)tools(_dot_)ietf(_dot_)org; Ray Hunter; 6man Mailing List;
ietf(_at_)ietf(_dot_)org;
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(_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.
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(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com
Thanks,
Fernando