ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)

Fri Jan 13 23:38:52 UTC 2017

In message <954a2fbd-580a-044b-07e7-63a0bf1bbfaa at si6networks.com>, Fernando Gont writes:
> On 01/12/2017 11:14 PM, Mark Andrews wrote:
> > In message <CAG6TeAt5pZJzoU0qDeTHgWEETnnib3hOLg-=bCv_1MBZJbew1g at mail.gmail.com>
> > , Fernando Gont writes:
> >> El 12/1/2017 16:32, "Saku Ytti" <saku at ytti.fi> escribi=C3=B3:
> >>
> >> On 12 January 2017 at 17:02, Fernando Gont <fgont at si6networks.com> wrote:
> >>> That's the point: If you don't allow fragments, but your peer honors
> >>> ICMPv6 PTB<1280, then dropping fragments creates the attack vector.
> >>
> >> Thanks. I think I got it now. Best I can offer is that B could try to
> >> verify the embedded original packet? Hopefully attacker won't have
> >> access to that information. An if attacker has access to that
> >> information, they may as well do TCP RST, right?
> >>
> >> Didn't we have same issues in IPv4 with ICMP unreachable and frag
> >> neeeded, DF set? And vendors implemented more verification if the ICMP
> >> message should be accepted.
> >>
> >>
> >> Yes and no.
> >>
> >> 1) there was no way in v4 to trigger use of fragmentation for an arbitrary
> >> flow.
> >>
> >> 2) in v4 you were guaranteed to get the IP+TCP header in the ICMP payload.
> >> In ipv6, you aren't (think ipv6 EHs)
> > 
> > So drop the packet if you don't get to the end of the extension
> > headers in the ICMPv6 payload.  Has anyone, except in testing, seen
> > a extension header chain that was not fully containable in the
> > ICMPv6 payload?
> 
> Because of the extra IPv6+ICMPv6 headers that you need for sending the
> ICMP error, even if the original packet did have the entire IPv6 header
> chain, you might be unable to include it in the ICMPv6 payload.

1280 - 40 - 8 which give a effective final header fitting in the
initial 1252 bytes.  Still bigger than header chains that you see
in practice today.

> Yes, in practice you'd be fine dropping ICMP errors that don't embed a
> full payload. Whether vendors do it or not, is a different question.

Dropping a payload that don't include the entire header chain.  The
entire packet is another thing.  It is expected to be truncated at
1252 bytes unless you add extension headers to the ICMPv6 packet.

> FWIW, it took me 6 years to publish RFC5927. And, because folks
> *opposed* to it in tcpm wg, it was published as Informational, rather
> than Std Track. RFC4443 points to it, still as informational thing that
> you might want to do.
> 
> If we don't convey the right message in specs, not sure we can expect
> good implementations, and even less flame the folk that tries to run his
> network in the best possible way with "what he gets".

As a DNS developer I actually do look at ICMP packets if I don't
want to timeout.  A PTB can be used to trigger the resend of a DNS
query (unlikely but possible).  You can also remember that and set
IPV6_USE_MIN_MTU=1 on future responses to that client rather than
relying on the lower levels of the stack remembering the PTB and
adjusting the packet size.  You can extract data from the payload
like the query id and even the question.  You can assume that it
is a EDNS response and reconstruct the response to resend assuming
that DNS Cookie/TSIG/SIG(0) is not in use as all of that is at the
end of the packet.   Time exceeded and unreachables can move you
onto the next server faster.

I have code that does some of that after matching addresses, ports
id etc.

None of this is hard to do.  All of this should be obvious to anyone
with a little bit of thinking.  Senders know that ICMPv6 packets
are limited to 1280 bytes.  They can construct their echoed back
packets to fit the headers into the available size.  They want the
traffic to flow and that requires getting back the information to
be able to restart the flow.

Instead the firewall developers do as little as they can.  They
don't think about the ramifications of their actions.

Mark

> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont at si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org