Deprecating the *generation* of IPv6 atomic fragments (Fwd: DoS attacks (ICMPv6-based) resulting from IPv6 EH drops)

Deprecating the *generation* of IPv6 atomic fragments (Fwd: DoS attacks (ICMPv6-based) resulting from IPv6 EH drops)

[Fernando Gont]

Folks,

(Heads up):
<http://www.ietf.org/id/draft-gont-6man-deprecate-atomfrag-generation-00.txt>
     -- (Rationale below)

Other than the IPv6 stack update, being able to filter packets based on
the "Next-Hop MTU" field of ICMPv6 Packet Too Big messages could be a
nice thing to have.

Thanks!

Cheers,
Fernando




-------- Forwarded Message --------
Subject: DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
Date: Tue, 19 Aug 2014 09:00:15 -0300
From: Fernando Gont <fgont@si6networks.com>
To: IPv6 Operations <v6ops@ietf.org>
CC: 'opsec@ietf.org' <opsec@ietf.org>

Folks,

Ten days ago or so we published this I-D:
<http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt>

Section 5.2 of the I-D discusses a possible attack vector based on a
combination of "forged" ICMPv6 PTB messages and IPv6 frag drops by
operators, along with proposed countermeasures -- on which we'd like to
hear your comments.

Since Section 5.2 is in the draft, let me offer a more informal and
practical explanation:

1) It is known that filtering of packets containing IPv6 Extension
Headers (including the Fragment Header) is widespread (see our I-D above)

2) Let us assume that Host A is communicating with Server B, and that
some node filters fragments between Host A and Server B.

3) An attacker sends a spoofed ICMPv6 PTB to server B, with a "Next Hop
MTU<1280), in the hopes of eliciting "atomic fragments" (see
<http://tools.ietf.org/rfc/rfc6946.txt>) from now on.

4) Now server B starts sending IPv6 atomic fragments... And since they
include a frag header (and in '2)' above we noted that frags are dropped
on that path), these packets get dropped (i.e., DoS).


"Demo" with the icmp6 tool
(<http://www.si6networks.com/tools/ipv6toolkit>) -- (some addresses have
been changed (anonimized), but it is trivial to pick a victim server...)

"2001:db8:1:10:0:1991:8:25" is the server, and
"2001:5c0:1000:a::e7d" is my own address):

---- cut here ----
***** First of all, I telnet to port 80 of the server, and
everything works as expected ****

fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80
Trying 2001:db8:1:10:0:1991:8:25...
Connected to 2001:db8:1:10:0:1991:8:25.
Escape character is '^]'.
^CConnection closed by foreign host.

**** Now I send the forget ICMPv6 PTB ****

fgont@satellite:~$ sudo icmp6  --icmp6-packet-too-big -d
2001:db8:1:10:0:1991:8:25 --peer-addr 2001:5c0:1000:a::e7d --mtu 1000 -o
80 -v
icmp6: Security assessment tool for attack vectors based on ICMPv6 error
messages

IPv6 Source Address: 2001:5c0:1000:a::e7d (automatically selected)
IPv6 Destination Address: 2001:db8:1:10:0:1991:8:25
IPv6 Hop Limit: 227 (randomized)
ICMPv6 Packet Too Big (Type 2), Code 0
Next-Hop MTU: 1000
Payload Type: IPv6/TCP (default)
Source Address: 2001:db8:1:10:0:1991:8:25 (automatically-selected)
Destination Address: 2001:5c0:1000:a::e7d
Hop Limit: 237 (randomized)
Source Port: 80	Destination Port: 38189 (randomized)
SEQ Number: 734463213 (randomized)	ACK Number: 866605720 (randomized)
Flags: A (default)	Window: 18944 (randomized)	URG Pointer: 0 (default)
Initial attack packet(s) sent successfully.


***** And now I try the same telnet command as above... but it fails,
because the frags from the server to me are getting dropped somewhere ****

fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80
Trying 2001:db8:1:10:0:1991:8:25...
[timeout]
---- cut here ----


Of course, in this particular case I just "shot myself". But one could
do this to DoS connections between mailservers, etc.

A nice question is: what if e.g....

1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and
react (as expected) by generating atomic fragments, *and*,

2) These same BGP servers deem fragmentation as "harmful", and hence
drop such fragments

you could essentially DoS traffic between them

As noted in the I-D, the mitigations seem to be:

1) Artificially limit your packets to 1280, and drop all incoming ICMPv6
PTB, or,

2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU
smaller than 1280.

Thoughts?
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492







-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

[RFC PATCH net-next] ipv6: stop sending PTB packets for MTU < 1280

[Hagen Paul Pfeifer]

Reduce the attack vector and stop generating ICMPv6 packet to big for
packets smaller then the minimal required IPv6 MTU.

See
http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00

Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
---
 net/ipv6/route.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index f74b041..84ebacd 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1154,12 +1154,9 @@ static void ip6_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
 		struct net *net = dev_net(dst->dev);
 
 		rt6->rt6i_flags |= RTF_MODIFIED;
-		if (mtu < IPV6_MIN_MTU) {
-			u32 features = dst_metric(dst, RTAX_FEATURES);
+		if (mtu < IPV6_MIN_MTU)
 			mtu = IPV6_MIN_MTU;
-			features |= RTAX_FEATURE_ALLFRAG;
-			dst_metric_set(dst, RTAX_FEATURES, features);
-		}
+
 		dst_metric_set(dst, RTAX_MTU, mtu);
 		rt6_update_expires(rt6, net->ipv6.sysctl.ip6_rt_mtu_expires);
 	}
-- 
2.1.0

Re: [RFC PATCH net-next] ipv6: stop sending PTB packets for MTU < 1280

[Hannes Frederic Sowa]

Hi Hagen,

On Di, 2014-08-26 at 00:25 +0200, Hagen Paul Pfeifer wrote:
> Reduce the attack vector and stop generating ICMPv6 packet to big for
> packets smaller then the minimal required IPv6 MTU.
> 
> See
> http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00

I wonder if we should wait until this gets RFC status?

I very much welcome this decision! I already raised this problem some
time ago:
http://lists.openwall.net/netdev/2013/12/31/17

I wonder if we should add a mode alike ipv4 ip_no_pmtu_disc mode for
ipv6:

ip_no_pmtu_disc - INTEGER
        Disable Path MTU Discovery. If enabled in mode 1 and a
        fragmentation-required ICMP is received, the PMTU to this
        destination will be set to min_pmtu (see below). You will need
        to raise min_pmtu to the smallest interface MTU on your system
        manually if you want to avoid locally generated fragments.

        In mode 2 incoming Path MTU Discovery messages will be
        discarded. Outgoing frames are handled the same as in mode 1,
        implicitly setting IP_PMTUDISC_DONT on every created socket.

        Mode 3 is a hardend pmtu discover mode. The kernel will only
        accept fragmentation-needed errors if the underlying protocol
        can verify them besides a plain socket lookup. Current
        protocols for which pmtu events will be honored are TCP, SCTP
        and DCCP as they verify e.g. the sequence number or the
        association. This mode should not be enabled globally but is
        only intended to secure e.g. name servers in namespaces where
        TCP path mtu must still work but path MTU information of other
        protocols should be discarded. If enabled globally this mode
        could break other protocols.

        Possible values: 0-3
        Default: FALSE

Not sure yet...

> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
> ---
>  net/ipv6/route.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index f74b041..84ebacd 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1154,12 +1154,9 @@ static void ip6_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
>  		struct net *net = dev_net(dst->dev);
>  
>  		rt6->rt6i_flags |= RTF_MODIFIED;
> -		if (mtu < IPV6_MIN_MTU) {
> -			u32 features = dst_metric(dst, RTAX_FEATURES);
> +		if (mtu < IPV6_MIN_MTU)
>  			mtu = IPV6_MIN_MTU;
> -			features |= RTAX_FEATURE_ALLFRAG;
> -			dst_metric_set(dst, RTAX_FEATURES, features);
> -		}
> +
>  		dst_metric_set(dst, RTAX_MTU, mtu);
>  		rt6_update_expires(rt6, net->ipv6.sysctl.ip6_rt_mtu_expires);
>  	}

This patch is a starter, yes. We can now get rid of the dst_allfrag
function altogether.

Thanks,
Hannes

Re: [RFC PATCH net-next] ipv6: stop sending PTB packets for MTU < 1280

[Hagen Paul Pfeifer]

On 26 August 2014 00:47, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:

Hey Hannes

> I wonder if we should wait until this gets RFC status?

Yes, we should wait until we get Fernando's go (based on v6ops
discussion & consensus). But the discussions seem to boils down to
this action (remove IPv6 PTB generation < 1280). If so we probably
don't want to wait two years with an open "protocol bug".

> I very much welcome this decision! I already raised this problem some
> time ago:
> http://lists.openwall.net/netdev/2013/12/31/17

Thank you for the pointer

> I wonder if we should add a mode alike ipv4 ip_no_pmtu_disc mode for
> ipv6:

Not sure, we should discuss this here (netdev). I tend to remove the
functionality completely. Any use cases where it makes sense to keep
this?

> This patch is a starter, yes. We can now get rid of the dst_allfrag
> function altogether.

Yes right, I am aware of this. Depending on the discussion we should
get rid of the allfrags code or not. Let's see. Thank you Hannes for
the comments.

Hagen

Re: [RFC PATCH net-next] ipv6: stop sending PTB packets for MTU < 1280

[Fernando Gont]

On 08/25/2014 07:47 PM, Hannes Frederic Sowa wrote:
> Hi Hagen,
> 
> On Di, 2014-08-26 at 00:25 +0200, Hagen Paul Pfeifer wrote:
>> Reduce the attack vector and stop generating ICMPv6 packet to big for
>> packets smaller then the minimal required IPv6 MTU.
>>
>> See
>> http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00
> 
> I wonder if we should wait until this gets RFC status?
> 
> I very much welcome this decision! I already raised this problem some
> time ago:
> http://lists.openwall.net/netdev/2013/12/31/17

FWIW, this issue you reported is related, but different from the one
I've described. The one I've described is based on sending ICMPv6
PTB<1280.   RFC2460 states that when you receive an ICMPv6 PTB<1280 you
should add a Fragment Header to all packets sent to that destination
(i.e., produce the so called "IPv6 atomic fragments").

These "atomic fragments" have an offset=0, and MF=0 -- i.e., they are
not really fragmented.

Hence the trivial way to mitigate this attack is to drop incoming ICMPv6
PTB1280 (or, at the very least, don't react to them by sending all
subsequent packets with a Fragment Header).

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: [RFC PATCH net-next] ipv6: stop sending PTB packets for MTU < 1280

[Hagen Paul Pfeifer]

On 27 August 2014 22:33, Fernando Gont <fgont@si6networks.com> wrote:

> Hence the trivial way to mitigate this attack is to drop incoming ICMPv6
> PTB1280 (or, at the very least, don't react to them by sending all
> subsequent packets with a Fragment Header).

Any news from the v6ops people - what is your suggestion Fernando?
Should we wait for more v6ops input?

Hagen

Re: [RFC PATCH net-next] ipv6: stop sending PTB packets for MTU < 1280

[Hannes Frederic Sowa]

Hi Fernando,

On Mi, 2014-08-27 at 17:33 -0300, Fernando Gont wrote:
> On 08/25/2014 07:47 PM, Hannes Frederic Sowa wrote:
> > Hi Hagen,
> > 
> > On Di, 2014-08-26 at 00:25 +0200, Hagen Paul Pfeifer wrote:
> >> Reduce the attack vector and stop generating ICMPv6 packet to big for
> >> packets smaller then the minimal required IPv6 MTU.
> >>
> >> See
> >> http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00
> > 
> > I wonder if we should wait until this gets RFC status?
> > 
> > I very much welcome this decision! I already raised this problem some
> > time ago:
> > http://lists.openwall.net/netdev/2013/12/31/17
> 
> FWIW, this issue you reported is related, but different from the one
> I've described. The one I've described is based on sending ICMPv6
> PTB<1280.   RFC2460 states that when you receive an ICMPv6 PTB<1280 you
> should add a Fragment Header to all packets sent to that destination
> (i.e., produce the so called "IPv6 atomic fragments").
> 
> These "atomic fragments" have an offset=0, and MF=0 -- i.e., they are
> not really fragmented.

Sure, in this specific thread I was mostly concerned with DNS packet
blackholing in forwarding path. Because of DNSSEC packets also easily
getting bigger than 1280 bytes this effect could also hurt people
without dst_allfrag being true (the function which checks if atomic
fragments are in effect along a route because of a <1280 PtB
notification before). At that time, I had atomic fragments in mind, they
just weren't that much of a problem as we are not concerned about them
in forwarding path and don't check for dst_allfrag there. But we also
had other changes to harden the host side in regard to PtB acceptance,
specifically this also helps to harden against spoofed PtB with mtu <
1280, see below.

At former times Linux used path mtu information in the forwarding path,
so not only the end system would be vulnerable, but all systems along
the way if one could sneak in a PtB error to reduce path mtu. This could
get used to inject PtB notifications even into full quadruple looked up
connections by just letting the router returning the PtB error instead
of directly spoofing it. At least there is no way you could generate
PtBs with mtus smaller than 1280, so no problems in regard to atomic
fragments.

You still had to ensure to hit a live socket, though. On DNS servers
with UDP this could be easily done because on unconnected sockets we
only do a 2-tuple lookup on the socket to validate the PtB error, so it
was easily possible to hit unconnected DNS servers ports on a router.

For protection on the host side:

In case you have an IPv6 socket and you want to ensure that no PtB
information will be accepted by it you already can set IP_MTU_DISCOVER
to IP_PMTUDISC_OMIT (or to IP_PMTUDISC_INTERFACE but kernel will then
start to reject creating fragments at all and will signal error to user
space). This is already implemented in unbound and hopefully already
found its way into BIND to protect DNS.

> Hence the trivial way to mitigate this attack is to drop incoming ICMPv6
> PTB1280 (or, at the very least, don't react to them by sending all
> subsequent packets with a Fragment Header).

Yes, atomic fragments aggravate this problem.

In retrospect, I don't know about other operationg systems, at that time
I only checked Linux and FreeBSD:

FreeBSD only uses interface MTU to check if PtB should be generated in
forwarding path.
Linux used to check path mtu but I converted that to checks for
interface mtu only in fwd path, too.

FreeBSD only accepts PtB information for TCP connections where the inner
data of the ICMP error matches the full quadruple of a tcp connected
socket. FreeBSD also validates that the ICMP(v6) is in the TCP window.

FreeBSD does not deal with PtB information on UDP sockets at all!

Linux does the same for TCP sockets (also checks windowing information).
But Linux also accepts 2-tuple UDP PtB errors (unconnected sockets),
this is now configurable on a per socket basis but we don't have a way
to turn this mode on globally as this is possible for IPv4.

That said, it is not that easy to forge PtB information any more. Only
systems where unconnected UDP sockets are exposed may be easily attacked
(but this is still a big enough attack vector). On TCP connections one
would need to spray a lot of packets against those hosts to match full
quadruple and get into the TCP window.

Bye,
Hannes