Fwd: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery

Folks,

FYI. -- this is an important piece when it comes to First Hop (i.e.,
"local link") Security.

Cheers,
Fernando




-------- Original Message --------
Subject: RFC 6980 on Security Implications of IPv6 Fragmentation with
IPv6 Neighbor Discovery
Date: Tue, 13 Aug 2013 15:13:21 -0700 (PDT)
From: rfc-editor@rfc-editor.org
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
CC: drafts-update-ref@iana.org, ipv6@ietf.org, rfc-editor@rfc-editor.org

A new Request for Comments is now available in online RFC libraries.


        RFC 6980

        Title:      Security Implications of IPv6 Fragmentation
                    with IPv6 Neighbor Discovery
        Author:     F. Gont
        Status:     Standards Track
        Stream:     IETF
        Date:       August 2013
        Mailbox:    fgont@si6networks.com
        Pages:      10
        Characters: 20850
        Updates:    RFC 3971, RFC 4861

        I-D Tag:    draft-ietf-6man-nd-extension-headers-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6980.txt

This document analyzes the security implications of employing IPv6
fragmentation with Neighbor Discovery (ND) messages.  It updates RFC
4861 such that use of the IPv6 Fragmentation Header is forbidden in
all Neighbor Discovery messages, thus allowing for simple and
effective countermeasures for Neighbor Discovery attacks.  Finally,
it discusses the security implications of using IPv6 fragmentation
with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971
to provide advice regarding how the aforementioned security
implications can be mitigated.

This document is a product of the IPv6 Maintenance Working Group of the
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see
http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


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






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

On Wed, Aug 14, 2013 at 05:19:13AM -0300, Fernando Gont wrote:

Folks,

FYI. -- this is an important piece when it comes to First Hop (i.e.,
"local link") Security.

Thanks for the heads-up, Fernando!

I sketched up a patch to protect the receiving side. I still don't know if I
should make this behaviour default or configurable via a sysctl knob. I really
don't want to break existing installations.

As an extra plus, we now discard packets with nested fragment headers at once.
Those packets should never have been accepted.

Thanks,

  Hannes

diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 77a4784..9ac5047 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h

@@ -103,6 +103,7 @@ struct inet6_skb_parm {
 #define IP6SKB_FORWARDED	2
 #define IP6SKB_REROUTED		4
 #define IP6SKB_ROUTERALERT	8
+#define IP6SKB_FRAGMENTED      16
 };
 
 #define IP6CB(skb)	((struct inet6_skb_parm*)((skb)->cb))

diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 79aa965..5c91616 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c

@@ -1524,6 +1524,9 @@ int ndisc_rcv(struct sk_buff *skb)
 	if (skb_linearize(skb))
 		return 0;
 
+	if (IP6CB(skb)->flags & IP6SKB_FRAGMENTED)
+		return 0;
+
 	msg = (struct nd_msg *)skb_transport_header(skb);
 
 	__skb_push(skb, skb->data - skb_transport_header(skb));

diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 790d9f4..1aeb473 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c

@@ -490,6 +490,7 @@ static int ip6_frag_reasm(struct frag_queue *fq, struct sk_buff *prev,
 	ipv6_hdr(head)->payload_len = htons(payload_len);
 	ipv6_change_dsfield(ipv6_hdr(head), 0xff, ecn);
 	IP6CB(head)->nhoff = nhoff;
+	IP6CB(head)->flags |= IP6SKB_FRAGMENTED;
 
 	/* Yes, and fold redundant checksum back. 8) */
 	if (head->ip_summed == CHECKSUM_COMPLETE)

@@ -524,6 +525,9 @@ static int ipv6_frag_rcv(struct sk_buff *skb)
 	struct net *net = dev_net(skb_dst(skb)->dev);
 	int evicted;
 
+	if (IP6CB(skb)->flags & IP6SKB_FRAGMENTED)
+		goto fail_hdr;
+
 	IP6_INC_STATS_BH(net, ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_REASMREQDS);
 
 	/* Jumbo payload inhibits frag. header */

@@ -544,6 +548,7 @@ static int ipv6_frag_rcv(struct sk_buff *skb)
 				 ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_REASMOKS);
 
 		IP6CB(skb)->nhoff = (u8 *)fhdr - skb_network_header(skb);
+		IP6CB(skb)->flags |= IP6SKB_FRAGMENTED;
 		return 1;
 	}
 

Hi, Hannes,

Thanks so much for your timely response! -- Please find my comments
in-line...

On 08/14/2013 08:06 PM, Hannes Frederic Sowa wrote:

On Wed, Aug 14, 2013 at 05:19:13AM -0300, Fernando Gont wrote:

quoted

Folks,

FYI. -- this is an important piece when it comes to First Hop (i.e.,
"local link") Security.

Thanks for the heads-up, Fernando!

I sketched up a patch to protect the receiving side. I still don't know if I
should make this behaviour default or configurable via a sysctl knob. I really
don't want to break existing installations.

Make it the default behavior. If anything, provide a sysctl knob to
override it.

Note: In the specific case of NS/NA messages, it's impossible nowadays
to find them fragmented in a real network (we don't even have options
(other than padding) to make NS/NAs grow so large!).

As an extra plus, we now discard packets with nested fragment headers at once.
Those packets should never have been accepted.

Is that the "goto fail_hdr" part in your patch?

P.S.: What about RS/RA messages?

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

On Thu, Aug 15, 2013 at 03:28:41AM -0300, Fernando Gont wrote:

Thanks so much for your timely response! -- Please find my comments
in-line...

On 08/14/2013 08:06 PM, Hannes Frederic Sowa wrote:

quoted

On Wed, Aug 14, 2013 at 05:19:13AM -0300, Fernando Gont wrote:

quoted

Folks,

FYI. -- this is an important piece when it comes to First Hop (i.e.,
"local link") Security.

Thanks for the heads-up, Fernando!

I sketched up a patch to protect the receiving side. I still don't know if I
should make this behaviour default or configurable via a sysctl knob. I really
don't want to break existing installations.

Make it the default behavior. If anything, provide a sysctl knob to
override it.

Note: In the specific case of NS/NA messages, it's impossible nowadays
to find them fragmented in a real network (we don't even have options
(other than padding) to make NS/NAs grow so large!).

Yes, I also do favour making this the default behavior.

quoted

As an extra plus, we now discard packets with nested fragment headers at once.
Those packets should never have been accepted.

Is that the "goto fail_hdr" part in your patch?

Yes, still have to check if I should silently ignore them or generate a
parameter problem (that is the current behavior).

P.S.: What about RS/RA messages?

ndisc_rcv, which does now silently discard fragmented packets, is called
for the following types:

        case NDISC_ROUTER_SOLICITATION:
        case NDISC_ROUTER_ADVERTISEMENT:
        case NDISC_NEIGHBOUR_SOLICITATION:
        case NDISC_NEIGHBOUR_ADVERTISEMENT:
        case NDISC_REDIRECT:

So all packet types from RFC6980 should be covered (we do not support SEND,
yet).

Thanks,

  Hannes

On Thu, Aug 15, 2013 at 2:04 PM, Hannes Frederic Sowa
[off-list ref] wrote:

On Thu, Aug 15, 2013 at 03:28:41AM -0300, Fernando Gont wrote:

quoted

Thanks so much for your timely response! -- Please find my comments
in-line...

On 08/14/2013 08:06 PM, Hannes Frederic Sowa wrote:

quoted

On Wed, Aug 14, 2013 at 05:19:13AM -0300, Fernando Gont wrote:

quoted

Folks,

FYI. -- this is an important piece when it comes to First Hop (i.e.,
"local link") Security.

Thanks for the heads-up, Fernando!

I sketched up a patch to protect the receiving side. I still don't know if I
should make this behaviour default or configurable via a sysctl knob. I really
don't want to break existing installations.

Make it the default behavior. If anything, provide a sysctl knob to
override it.

Note: In the specific case of NS/NA messages, it's impossible nowadays
to find them fragmented in a real network (we don't even have options
(other than padding) to make NS/NAs grow so large!).

Yes, I also do favour making this the default behavior.

quoted

quoted

As an extra plus, we now discard packets with nested fragment headers at once.
Those packets should never have been accepted.

Is that the "goto fail_hdr" part in your patch?

Yes, still have to check if I should silently ignore them or generate a
parameter problem (that is the current behavior).

I'm not sure if you got my previous mails, but I'd like to know a
couple of things:

1) How can I test this diff ?

2) It's developed against which git brach ? linux-next ?

3) What will/could break with this diff in a production environment ?

quoted

P.S.: What about RS/RA messages?

ndisc_rcv, which does now silently discard fragmented packets, is called
for the following types:

        case NDISC_ROUTER_SOLICITATION:
        case NDISC_ROUTER_ADVERTISEMENT:
        case NDISC_NEIGHBOUR_SOLICITATION:
        case NDISC_NEIGHBOUR_ADVERTISEMENT:
        case NDISC_REDIRECT:

So all packet types from RFC6980 should be covered (we do not support SEND,
yet).

Thanks,

  Hannes

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

On Thu, Aug 15, 2013 at 02:14:46PM +0400, Loganaden Velvindron wrote:

I'm not sure if you got my previous mails, but I'd like to know a
couple of things:

Ah, you asked me off-list. So, for a wider audience, I copy & paste my answers
from the just answered mail. ;)

1) How can I test this diff ?

Actually, nothing should change at all.

Myself, I used scapy to construct some packets and send it to a system
with the patched kernel and had some printks sprinkeled in the source
while watching tcpdump.

2) It's developed against which git brach ? linux-next ?

Yes, I targeted linux-next. But it should apply to older kernels
without too much fuzz as well.

3) What will/could break with this diff in a production environment ?

RA messages could get fragmented if a speaker puts lots of options in it. I
hope all RA speakers already spread the options over multiple RAs, but I don't
know. In case the RA is fragmented it will now be dropped silently.

Thanks,

  Hannes

On Thu, Aug 15, 2013 at 2:25 PM, Hannes Frederic Sowa
[off-list ref] wrote:

On Thu, Aug 15, 2013 at 02:14:46PM +0400, Loganaden Velvindron wrote:

quoted

I'm not sure if you got my previous mails, but I'd like to know a
couple of things:

Ah, you asked me off-list. So, for a wider audience, I copy & paste my answers
from the just answered mail. ;)

quoted

1) How can I test this diff ?

Actually, nothing should change at all.

Myself, I used scapy to construct some packets and send it to a system
with the patched kernel and had some printks sprinkeled in the source
while watching tcpdump.

quoted

2) It's developed against which git brach ? linux-next ?

Yes, I targeted linux-next. But it should apply to older kernels
without too much fuzz as well.

I've tested with linux-next.

quoted

3) What will/could break with this diff in a production environment ?

RA messages could get fragmented if a speaker puts lots of options in it. I
hope all RA speakers already spread the options over multiple RAs, but I don't
know. In case the RA is fragmented it will now be dropped silently.

My IPv6 gateway machine runs OpenBSD, and so far, no issues with it.
I'm going to test
it at work in a couple of hours and report back.

Thanks,

  Hannes

-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

On Mon, Aug 19, 2013 at 12:52 AM, Loganaden Velvindron
[off-list ref] wrote:

On Thu, Aug 15, 2013 at 2:25 PM, Hannes Frederic Sowa
[off-list ref] wrote:

quoted

On Thu, Aug 15, 2013 at 02:14:46PM +0400, Loganaden Velvindron wrote:

quoted

I'm not sure if you got my previous mails, but I'd like to know a
couple of things:

Ah, you asked me off-list. So, for a wider audience, I copy & paste my answers
from the just answered mail. ;)

quoted

1) How can I test this diff ?

Actually, nothing should change at all.

Myself, I used scapy to construct some packets and send it to a system
with the patched kernel and had some printks sprinkeled in the source
while watching tcpdump.

quoted

2) It's developed against which git brach ? linux-next ?

Yes, I targeted linux-next. But it should apply to older kernels
without too much fuzz as well.

I've tested with linux-next.

quoted

quoted

3) What will/could break with this diff in a production environment ?

RA messages could get fragmented if a speaker puts lots of options in it. I
hope all RA speakers already spread the options over multiple RAs, but I don't
know. In case the RA is fragmented it will now be dropped silently.

My IPv6 gateway machine runs OpenBSD, and so far, no issues with it.
I'm going to test
it at work in a couple of hours and report back.

Works fine @ work with cisco routers.

quoted

Thanks,

  Hannes

--
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

On 08/15/2013 07:25 AM, Hannes Frederic Sowa wrote:

quoted

3) What will/could break with this diff in a production environment ?

RA messages could get fragmented if a speaker puts lots of options in it. I
hope all RA speakers already spread the options over multiple RAs, but I don't
know. In case the RA is fragmented it will now be dropped silently.

My understanding is that some implementations were already dropping
fragmented RAs... so you better avoid fragmentation. Put another way:
you're already in trouble if you rely on fragmented ND messages.

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