Fernando,
Can you please re-send in plaintext, as all of the other messages in this thread
have been? Richly formatted text makes annotation impossible.
Thanks - Fred
From: fernando(_dot_)gont(_dot_)netbook(_at_)gmail(_dot_)com
[mailto:fernando(_dot_)gont(_dot_)netbook(_at_)gmail(_dot_)com] On Behalf Of
Fernando Gont
Sent: Wednesday, October 16, 2013 9:09 AM
To: Templin, Fred L
Cc: Ole Troan; 6man-chairs(_at_)tools(_dot_)ietf(_dot_)org; 6man Mailing List;
ietf(_at_)ietf(_dot_)org; Ray Hunter; Fernando Gont
Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>
(Implications of Oversized IPv6 Header Chains) to Proposed Standard
Hi, Fred,
On Wed, Oct 16, 2013 at 12:45 PM, Templin, Fred L
<Fred(_dot_)L(_dot_)Templin(_at_)boeing(_dot_)com<mailto: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. 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