Subject: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers)

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Jun 2011 18:51:12 -0300

Hi,

Some folks have expressed (both on-list and off-list) that they would
prefer a less agressive solution for the RA-Guard evasion vulnerability.
So I'd like to hear comments about the possible alternatives..

The current I-Ds (draft-gont-6man-nd-extension-headers and
draft-gont-v6ops-ra-guard-evasion) basically take this approach:

* Prohibit use of extension headers in ND messages. A host
implementation must not produce these packets, and must discard them if
it receives them
* This results in a RA-Guard implementation that is as simple as
possible (it only has to look at the header following the fixed IPv6
header).

A more relaxed approach would be as follows:
* Extension headers are allowed with ND messages.
* If the packet is fragmented, the upper-layer header (ICMPv6 in this
case) must be present in the first fragment (i.e., hosts must not
generate packets that violate this requirement, and must discard them if
they receive them).
* Possibly have the RA-Guard box enforce a limit on the maximum number
of extension headers that it will process (e.g., if after jumping to
the, say 10th header the upper-layer header is not found, drop the packet)
* This approach is less aggressive than the one proposed in the
aforementioned I-Ds (i.e., more flexibility), but of course would also
mean that the RA-Guard implementation would need to follow the header
chain, thus leading to increased complexity, and possible performance
issues.

Any comments/thoughts will be very much appreciated.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mark Smith <[email-masked]>
Date: Sat, 11 Jun 2011 10:45:37 +0930

Hi Fernando,

On Fri, 10 Jun 2011 18:51:12 -0300

> possible (it only has to look at the header following the fixed IPv6

If changing host implementations is an option, then a simpler idea
might be to have RAs come from a source address from within a well-known
range of link-local addresses. The 11th to 16th bits (or more) after
the fe80 in the link local address could be used to indicate the type
of address e.g.

fe80::/16 - hosts and "legacy untyped" link local address use 
fe81::/16 - neighbor discovery address resolution
fe82::/16 - router functions e.g. RAs, ICMPv6 redirects
fe83::/16 - dhcpv6 server functions
fe84::/16 - RIP messages and next-hops
fe85::/16 - OSPF messages and next-hops
fe86::/16 - IS-IS next hop
fe87::/16 - BGP messages and next-hops
etc.

(I'm not sure if the routing protocol ones would be useful)

so a device acting as a router, a dhcpv6-server and an host would
have 3 link local addresses, using each different one for the
corresponding function as a source address e.g.

fe80::1 - normal link-local unicast communications
fe81::1 - neighbor discovery address resolution functions
fe82::1 - router related functions (RAs, ND redirects)
fe83::1 - dhcpv6 server related functions

I'd think "RA guard" type filtering would then be pretty easy in layer
2 devices, as these bits have a fixed location in the IPv6 header, and
the filtering would be a binary match on a 16 bit value. For a
switch interface facing a router, the switch would only accept
fe80::16, fe81::/16 and fe82::/16 link local source addresses. For a
switch interface facing a host, the switch would only accept fe80::16
and fe81::/16. Some IPv6 switches today are able to implement basic
ACLs including source IPv6 addresses, so once the devices providing
these functions are using these typed source addresses, there would be
an option of implementing this sort of checking today for a number of
people. I think the key advantage to this idea is that very little
intensive packet checking has to occur before a forward/drop decision
can be made.

Hosts would have to implement these checks too. Until they're
implemented in the IPv6 stack, an interim option would be to use the
host's IPv6 firewall to perform these source address type checks. E.g.,
to only accept RAs from an allowed router, check the RA came from a
link-local address with fe82::/16 in it's source address.

I think the only outstanding issue might be is whether existing IPv6
implementations will allow or accept non-fe80::/16 link local
source and destination addresses addresses until their IPv6 stacks are
updated. I think it is possible that they would, as long as they aren't
checking the values of the 54 zero bits between /10 and /64 in today's
link local addresses. I don't have access to much of a test environment
at the moment as I'm between jobs, so I'm limited to what I can test
with a few Linux boxes.

Encoding a device type or function in network layer addresses isn't a
new idea, IIRC in appletalk they had clients use the lower 0 - 127 node
addresses and servers use the higher 128 - 255 addresses on a cable
number.

Regards,
Mark.

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark Smith <[email-masked]>
Date: Sat, 11 Jun 2011 11:21:30 +0930

On Sat, 11 Jun 2011 10:45:37 +0930

> have 3 link local addresses, using each different one for the
       ^
should be 4, realised that there probably would be value in having a
separate category for neighbor discovery address resolution while
writing the email, a few similar related errors below.

> fe80::16, fe81::/16 and fe82::/16 link local source addresses.

should have been fe80::/16, fe81::/16, fe82::/16 and fe83::/16

> For a

fe80::/16

---

From: Philip Homburg <[email-masked]>
Date: Sat, 11 Jun 2011 10:09:15 +0200

>chain, thus leading to increased complexity, and possible performance

Strikes me as a bad tradeoff. This requires all L2 switches to parse IPv6
extension headers at wire speed. So, some of them will get it wrong. 

And the only benefit menioned in the discussion so far is the need to send
RAs large enough that they need to be fragmented.

Another benefit would be that you don't have to change host software.

---

From: Bob Hinden <[email-masked]>
Date: Sat, 11 Jun 2011 18:02:04 +0300

Fernando,

> possible (it only has to look at the header following the fixed IPv6

What is a use case where extension headers would be used in ND (ICMPv6) messages?  Same for Fragmentation?  

I am having a hard time thinking of any, so I like your approach.  Unless I am missing something.

Thanks,

Bob

---

From: Fernando Gont <[email-masked]>
Date: Sat, 11 Jun 2011 17:58:57 -0300

Hi, Mark,

>> the fe80 in the link local address could be used to indicate the type

This might help with attack vectors based on forged RAs, but not with
other vectors (e.g., forged Neighbor Advertisements).

Also, your proposal modifies the addressing architecture -- while this
is not "per se" a bad thing this is a more radical change than the one
proposed in my I-D (which, as far as legitimate traffic is concerned, is
a no-op, since extension headers with ND are not used for any legitimate
purpose).

> writing the email, a few similar related errors below.

If you don't prevent the use of extension headers for ND (in particular,
of the Fragment Header) it's still very painful to perform any kind of
monitoring on the Neighbor Discovery traffic (e.g., with NDPMon and the
like).

>> these functions are using these typed source addresses, there would be

Note that this would also require an update to routers (which might not
be possible), and would also imply a rather radical change for the ops
people (which, imo, at this point in time would be a bad thing).

But there seems to be an even more substantial problem: this seems to
require a flag day. i.e., how do hosts tell if they are receiving
"traditional" RAs because they are under attack, or because the network
has not yet been upgraded to implement your proposal?

>> intensive packet checking has to occur before a forward/drop decision

If extension headers are prohibited, you only need to look at fixed
locations in the packet (IPv6 "Next Header", and then ICMP type).

>> link-local address with fe82::/16 in it's source address.

But the RA-Guard box would still need to deal with the "traditional"
RAs, since there might be legacy hosts that would react to them.

>> link local addresses. 

Oh, yes, they do. :-) KAME discards such packets.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 11 Jun 2011 18:14:08 -0300

> extension headers at wire speed. So, some of them will get it wrong. 

+1

> RAs large enough that they need to be fragmented.

Actually, you can get the same benefit with no fragmentation: just send
multiple RAs.

> Another benefit would be that you don't have to change host software.

I think that, in practice, this is less of an issue. In may cases, this
could be an automatic "security update". In others, the hosts may be
connected to networks that do not yet support v6, and by the time v6 is
deployed on these networks, the corresponding OSes will have already
been updated/upgraded.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 11 Jun 2011 20:24:10 -0300

Hi, Bob,

On 06/11/2011 12:02 PM, Bob Hinden wrote:
>> implementation must not produce these packets, and must discard
>> them if it receives them * This results in a RA-Guard
>> implementation that is as simple as possible (it only has to look
>> at the header following the fixed IPv6 header).
> 
> What is a use case where extension headers would be used in ND
> (ICMPv6) messages?  

I am told that AH could potentially be used with ND. Also, that some
high-security sites might want to use CALIPSO with ND. And that there's
always the possibility that somebody could come up with with an ND
extension/feature that requires IPv6 extension headers.

I personally think that when it comes to possible extensions to ND, most
of them could be implemented with ND options (rather than extension
headers). As for AH or CALIPSO, from my perspective (and if anything)
I'd argue that the I-D could require that hosts include a configuration
switch that can enable the processing of ND packets with extension
headers (such configuration knob would default to "off/disable") --
i.e., for the general case (and by default), ND packets are not allowed
to include IPv6 extension headers.. but if you have a specific scenario
in which you'd need them (unlikely, from my perspective), you can
override this policy such that they are accepted.

> Same for Fragmentation?

As far as I can tell from Pekka's note, at least radvd does not support
fragmentation with ND. So the only *potential* use case is sending
(probably insane) amounts of information in RAs -- but you can always
send the same amount of information using multiple RAs.

> I am having a hard time thinking of any, so I like your approach.

I believe the approach currently outlined in the I-Ds keeps things
simple and allows for simple RA-guard implementation and ND-monitoring
tools like NDPMon. And that's the approach I would prefer to pursue.
However, since some had brought up possible alternatives, I wanted
others to weigh in.

Thanks!

Best regards,

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 13 Jun 2011 23:38:56 +0100

> possible (it only has to look at the header following the fixed IPv6

dhcpv6 suffers from exactly the same problem.  Are there plans to introduce 
dhcpv6-guard?

Nick

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jun 2011 15:44:32 -0700

On Jun 13, 2011, at 3:38 PM, Nick Hilliard wrote:
> dhcpv6 suffers from exactly the same problem.  Are there plans to introduce dhcpv6-guard?

Nobody's proposed it.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jun 2011 22:23:16 -0300

On 06/13/2011 07:38 PM, Nick Hilliard wrote:
> dhcpv6 suffers from exactly the same problem.  

Agreed. This is noted in the I-D, by the way.

> Are there plans to introduce dhcpv6-guard?

This is something that vendors should answer. As long as there are
implementations that may try DHCPv6 even if no RA is received, DHCPv6
should be implemented/deployed along RA-Guard, or else attackers will
switch to teh DHCPv6 vector, and RA-Guard will be circumvented this way.

Thanks,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 14 Jun 2011 06:19:58 +0200 (CEST)

>> dhcpv6 suffers from exactly the same problem.  Are there plans to introduce dhcpv6-guard?

<http://tools.ietf.org/html/draft-ietf-savi-dhcp-06>

I'd be surprised if implementations of this wouldn't also have some kind 
of idea or concept of "client ports" and "server ports"?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Tue, 14 Jun 2011 08:23:37 +0100

> switch to teh DHCPv6 vector, and RA-Guard will be circumvented this way.

I am aware of it being on the roadmap for one significant router vendor.

But that model is familiar from IPv4.

Tim

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 14 Jun 2011 13:25:12 +0100

> switch to teh DHCPv6 vector, and RA-Guard will be circumvented this way.

probably vendors aren't going to do much about dhcp6-guard unless there is 
a standard to work towards.  I'd offer to help out, but my dhcpv6-fu is not 
really up to it.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Jun 2011 14:03:50 +0000

On Jun 14, 2011, at 5:26 AM, "Nick Hilliard" <[email-masked]> wrote:

> probably vendors aren't going to do much about dhcp6-guard unless there is a standard to work towards.  I'd offer to help out, but my dhcpv6-fu is

Can you come to the dhcwg meeting and talk with us about the problem?

---

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 16 Jun 2011 19:13:30 +0200

Hi,

I've read quickly these two drafts. Here are some comments/questions:

o draft-gont-v6ops-ra-guard-evasion

IMHO, this draft should update RFC 6105 (If so, RFC6105 reference
should move from Informative References section to the Normative
References one).
Just a comment about your example for the fragmentation case with 2
Destination extensions: from RFC2460 (section 4.1), this only occurs
when there is also a Routing Header extension, so I have to add a RH
in your example (better chance to get a fragmentation :))

o draft-gont-6man-nd-extension-headers

IMHO, this is not a good idea to forbid the use of IPv6 extension with
NDP messages, especially when the reason is partially based on
implementation issues (i.e. the implementation is not able to process
an IPv6 packet): today, there is no real use of Extension header with
NDP but, tomorrow, if we need such an use for a solution, what will
happen?
Regarding the fragmentation, is it not possible for the RA-Guard
device to reassemble the fragments and so to be able to check whether
this a RA message or not?

Thanks in advance for your reply.

Best regards.

JMC.

---

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 16 Jun 2011 19:16:03 +0200

Hi,

Regarding DHCP SAVI, this is not the main goal of this solution but a
side effect.

Best regards.

JMC.

2011/6/14 Mikael Abrahamsson <[email-masked]>:
> I'd be surprised if implementations of this wouldn't also have some kind of
> idea or concept of "client ports" and "server ports"?
>
> --
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Arturo Servin <[email-masked]>
Date: Thu, 16 Jun 2011 16:46:27 -0300

Jean-Michel,

> NDP but, tomorrow, if we need such an use for a solution, what will

	See below

> this a RA message or not?

	It's possible, perhaps. But the trade-off is to much IMHO. Forcing a L2 device to inspect every packet and re-asemble them is unfeasible or too expensive (similar for a more intelligent device listening for every packet in the network looking for rogue RAs). The same for extension headers in NDP, we are not using it today, may be we will, but the trade-off to have it "just in case" is too much.

> Thanks in advance for your reply.

Cheers,
.as

---

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 16 Jun 2011 22:44:50 +0200

Hi Arturo,

at first, thanks for your reply.

> On 16 Jun 2011, at 14:13, Jean-Michel Combes wrote:

[snip]

>        It's possible, perhaps. But the trade-off is to much IMHO. Forcing a L2 device to inspect every packet and re-asemble them is unfeasible or too expensive (similar for a more intelligent devi…

Why is this unfeasible? Again an implementation issue?
Why is it too expensive? Memory issue? CPU issue? Something else?

Best regards.

JMC.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 16 Jun 2011 13:57:38 -0700

> Why is it too expensive? Memory issue? CPU issue? Something else?

it's expensive because you have to set them aside and re-assemble and nd is going to be reassembled in a control-plane processor, which leads to  cases where the attacker deliberately maximizes the expense associated with doing so.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jun 2011 05:02:15 -0300

Hi, Jean-Michel,

> should move from Informative References section to the Normative

Yep.

> in your example (better chance to get a fragmentation :))

The specs allow for multiple instances of the same extension headers.
Hence, even if possibly non-sensical, the example in Section 4.1 is
legitime.

> an IPv6 packet): 

Well, I'd argue that it is an operational issue, rather than an
implementation issue. -- And chances are that if it is not possible to
implement a simple solution for this concrete problem, some may start
filtering *all* packets that include extension headers (in particular,
those in which the uper layer protocol is not present in the first fragment)

> today, there is no real use of Extension header with

Among the options is that we could state that implementations should
provide a switch to enable the processing of extension headers, but that
it should default to off.

> this a RA message or not?

This would open the door to DoS attacks -- the attacker would simply
fire lots of fragments that would never get to be reassembled. -- then
you're back into the same place (or probably a worse one).

Thanks,