RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Fernando,

> -----Original Message-----
> From: fgont.si6networks@xxxxxxxxx [mailto:fgont.si6networks@xxxxxxxxx]
> On Behalf Of Fernando Gont
> Sent: Wednesday, October 16, 2013 10:05 AM
> To: Templin, Fred L
> Cc: Ole Troan; Ronald Bonica; Brian E Carpenter; 6man-
> chairs@xxxxxxxxxxxxxx; Ray Hunter; 6man Mailing List; ietf@xxxxxxxx
> Subject: Re: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt>
> (Implications of Oversized IPv6 Header Chains) to Proposed Standard
> 
> 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.

If an underlying encapsulation is IPv4, there is a very good
chance that the IPv4 path MTU is at least 1280. Else, the
underlying link with MTU smaller than 1280 is very likely to
be low speed. That being the case, the middlebox would have to
perform IPv4 reassembly, yes. But, that is truly a corner case,
and only when IPv4 is involved. Again, we should be striving
to do better than 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?

Please don't discount this scenario as contrived or unlikely; there
are certainly such low-end data links in real deployments (civil
aviation networks, DoD networks, etc.) that need DOS protection.

> >> 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.

Most tunneling protocols I am aware of do not specify that additional
extension headers can be added (one exception is the Encapsulation Limit
option specified by RFC2473). So, it should be reasonable for a middlebox 
to drop an encapsulated packet with an unusually long encapsulation
extension header chain inserted by the purported tunnel ingress. 
 
> 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?

The hard-coded limit is 5-6 layers of encapsulation headers fitting
within the IPv6 minMTU but that does not stop tunnels from recursing
indefinitely. What it does do is provide a healthy number of layers
of defense in depth.

> 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).

That's OK. Let the BCP for hosts be 1024, and I am happy.

Thanks - Fred
fred.l.templin@xxxxxxxxxx

> Thanks,
> Fernando





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]