Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)

From: RJ Atkinson <[email-masked]>
Date: Wed, 22 Jun 2011 07:08:43 -0400

On Weds, 22 June 2011, Fernando Gont wrote:
On 06/16/2011 02:13 PM, Jean-Michel Combes wrote:
>>  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): 
> 
> 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)

I agree with Jean-Michel Combes and disagree with Fernando.  

It absolutely is an implementation issue -- specifically it is 
a  "quality of implementation" issue, not a complexity issue.

More importantly, the implementation approach I described on the IPv6 
list is neither complicated nor computationally expensive.  In fact, 
supporting the limited set of non-silly-for-ND-packet Extension Headers
has tiny incremental memory footprint and tiny increase in the
instruction count.  The instruction count increase only applies if
an actual Extension Header is encountered, btw.  The code for a L2
device to locate the IPv6 header, read that header, and read into
the ICMP message to determine that a packet is an ND packet *dwarfs*
the code to skip past the small set of reasonable Extension Headers
for ND packets.

Please (re-)read this previous note:
	<http://www.ietf.org/mail-archive/web/ipv6/current/msg14241.html>	

Yours,

Ran

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Jun 2011 13:15:26 +0200 (CEST)

On Wed, 22 Jun 2011, RJ Atkinson wrote:

> It absolutely is an implementation issue -- specifically it is a 
> "quality of implementation" issue, not a complexity issue.

I feel that there should be guidance regarding this in the SAVI 
documentation, even if this is only a pointer to another document that 
describes how to parse an IPv6 packet.

Just the same way that it's "obvious" that anyone can spoof RAs on a flat 
L2 lan, it's "obvious" that fragmentation and headers can make parsing 
actual payload harder and needs to be handled. These two "obvious" have 
historically been overlooked numerous times.

Just the same way describing how to do SAVI L2.5 functionality to solve 
different security implications needs to be done to provide guidance to 
vendors, I also feel that they need to be helped to handle fragmentation 
attacks.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 22 Jun 2011 07:25:51 -0400

On 22  Jun 2011, at 07:15 , Mikael Abrahamsson wrote:
> documentation, even if this is only a pointer to another document
> that describes how to parse an IPv6 packet.

That seems useful to me.  

> Just the same way that it's "obvious" that anyone can spoof RAs
> on a flat L2 lan, it's "obvious" that fragmentation and headers
> can make parsing actual payload harder and needs to be handled.
> These two "obvious" have historically been overlooked numerous times.

As the 17th June 2011 note I pointed to earlier today, 
but did not repeat in its entirety, observed:

A) the "Fragmentation Header" is clearly a security risk,
   so banning that makes sense.

B) packet re-assembly can be expensive in (memory footprint, computation).

C) the "Routing Header" better not be in an ND packet in any case,
   since ND packets are supposedly link-local, and therefore not applicable 
   for any ND packet, so banning that makes sense.

That same note pointed out that the above analysis is NOT true
for selected other IPv6 Extension Headers (i.e. the ones that 
might actually be useful with ND), for example:

1) Hop-by-Hop Options header, which safely and trivially
   can be parsed past by a L2 device just implementing an RA Guard

2) Destination Options header, which also safely and trivially
   can be parsed past by a L2 device just implementing an RA Guard.
 
> different security implications needs to be done to provide guidance
> to vendors, I also feel that they need to be helped to handle fragmentation attacks.

That also sounds useful to me.

Cheers,

Ran

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Jun 2011 21:04:51 +0930

On Wed, 22 Jun 2011 13:18:49 +0200
Philip Homburg <[email-masked]> wrote:

> In your letter dated Wed, 22 Jun 2011 07:08:43 -0400 you wrote:
> I have to admit I don't know much about the internals of L2 switches. But
> my mental model of a 10 Gbit/s ethernet switch is that of an ASIC/FPGA that
> does almost all forwarding with the CPU just for management.
> 
> I've no idea how expensive it would be to parse extension headers in an ASIC.
> 
> I think it is a bit ironic that if a L2 device has to parse all extension
> headers, that then L2 switching of IPv6 packets will be more expensive that
> L3 routing them.
> 

It may be getting to the point where it'd probably be easier
to address these issues by taking away hosts' ability to multicast to
other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke
mode of LAN operation, allowing the designated routers to also act as
traffic sanitisers for on-link inter-host traffic.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Jun 2011 13:41:32 +0200 (CEST)

On Wed, 22 Jun 2011, Mark Smith wrote:

> It may be getting to the point where it'd probably be easier to address 
> these issues by taking away hosts' ability to multicast to other hosts 
> on the same segment i.e. switch to an NBMA/hub-and-spoke mode of LAN 
> operation, allowing the designated routers to also act as traffic 
> sanitisers for on-link inter-host traffic.

I agree, that's the deployment model I advocate for hostile scenarios. Use 
DHCPv6 for stateful addressing, advertise default GW via RA, don't 
advertise any on-link prefix, and make sure hosts can't L2 communicate at 
all with each other by means of enforcement in switches (or just separate 
them into different L2 domains).

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 22 Jun 2011 08:04:39 -0400

On 22  Jun 2011, at 07:18 , Philip Homburg wrote:
> I have to admit I don't know much about the internals of L2 switches.
> But my mental model of a 10 Gbit/s ethernet switch is that of an
> ASIC/FPGA that does almost all forwarding with the CPU just for management.

I spent most of the last decade building high-performance
Ethernet switches.  Your mental model is generally the case,
but that ASIC/FPGA often already includes IPv4/IPv6 routing
capability including some degree of packet parsing capability.

(Even the low-cost "consumer electronics" L2 switches now
often/commonly use a commodity ASIC that includes at least 
some L3 capabilities -- although a given product might or
might not software-enable those chip features.)

Some chips can parse/parse-past any legal combination of IPv4/IPv6
headers at wire-speed.  Some can parse past a subset, again at
wire-speed, with the most common IPv6 subset being the Routing Header, 
Destination Options header, and Hop-by-Hop header.

I know of at least 2 Ethernet switch vendors that already have
sold/deployed ASIC/FPGA-based switches that can parse past IPv6 
extension headers (i.e. to read transport-layer header information 
& provide wire-speed ACLs, to handle an ICMPv6 message, etc.).  

For the genuine L2-only ASIC/FPGA devices, those without ANY
L3 capabilities, any form of Fernando's proposal will require 
that **all** IPv6 packets, anything with (EtherType=0x86dd) 
not just all IPv6 ND packets, be sent via the CPU.  As you noted 
later on, this precise situation leads to real challenges in 
throughput, switch resilience, etc.

In such a pure-L2-only case, the big performance hit is parsing 
INTO the IPv6 packet in the first place.  One won't even be able 
to detect whether a packet is an ND packet until one has parsed
inside the ICMPv6 header.  Best case, getting that far in is
a bunch of CPU instructions for each IPv6 packet.  Once one
has decided to do that, which might or might not be a wise
product-management decision, then parsing past the Dest Opts
Header or Hop-by-Hop Header is a tiny incremental hit that
applies only to those packets with such headers.

Of course, packet reassembly IS expensive.  This is why my
proposal does NOT disagree with Fernando's proposal to
outright ban the IPv6 Fragment Header for IPv6 ND packets.

> extension headers in an ASIC.

Good question.  I have data.

For one implementation I am very familiar with, that Verilog 
did not significantly increase the gate count, did not make gate 
layout/place harder, and did not increase the die size.  Folks I know 
who worked on a genetically different ASIC with similar packet parsing 
capabilities tell me their experience was roughly the same 
(i.e. gate count increase was minor, no new layout/place issues, 
and no increase in chip die size).
 
So my answer would be "not very expensive", based on actual 
experience with this in a commercial product environment.

> I think it is a bit ironic that if a L2 device has to parse
> all extension headers, that then L2 switching of IPv6 packets
> will be more expensive that L3 routing them.

For a pure L2-device, without any L3 hardware capabilities,
one imagines that the most common product-manaagement decision 
would be to ignore Fernando's entire spec (and not claim 
to support it).

Again, for a pure L2-device, the expensive part of Fernando's spec 
is parsing from (EtherType==0x86dd) and start-of-frame to the point 
where the switch can learn that the packet contains ICMPv6 and 
that the ICMP Type indicates an ND packet.  Parsing past the 
Dest Opts header & Hop-by-Hop header is a tiny incremental CPU
hit (a few assembler instructions) on that basic unavoidable cost.

For an L3-capable chip, it often is still possible to use some
of the chip's L3 features (e.g. packet parsing) even when the
chip is bridging a frame instead of routing a packet.  So for
the devices using an L3-capable chip, it is not necessarily
the case that L2 switching would be more expensive than L3
routing.  (Obviously L2 switching with an RA-Guard could be more
expensive than L3 routing with RA-Guard for particular chip
implementations; I have no doubt that some such chips
both exist and are present in some commonly deployed devices.)

I do think there is a real question of how deployable Fernando's
RA Guard proposal will be *in the near term*.  In the longer term,
one would hope that the chipset vendors that need to spin
a chip would plan for this whenever they do such a spin.
(Ultimately, the market will decide whether Fernando's spec 
deploys, even if the IETF endorses it, as is true with so many 
notional capabilities.)

Cheers,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 22 Jun 2011 08:10:27 -0400

On 22  Jun 2011, at 07:34 , Mark Smith wrote:
> to address these issues by taking away hosts' ability to multicast
> to other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke
> mode of LAN operation, allowing the designated routers to also
> act as traffic sanitisers for on-link inter-host traffic.

That is possible; doing so would create a new and different set 
of operational issues and implementation issues.  It isn't
immediately obvious to me that the alternative set of issues would be 
simpler/cheaper/easier than the issues Fernando's proposal raises.

Another more fundamental question is how much operational risk the 
folks who deploy edge networks believe they have, and how much 
operational risk those folks are comfortable with.  Some or many such 
operational folks might find all of these concepts to have excessive 
capital and operational expense for the perceived risk reduction.
They might conclude that the "cure" is worse than the "disease".

Yours, 

Ran

---

From: Philip Homburg <[email-masked]>
Date: Wed, 22 Jun 2011 13:18:49 +0200

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 22 Jun 2011 08:24:01 -0700

On Jun 22, 2011, at 4:41 AM, Mikael Abrahamsson wrote:

>> It may be getting to the point where it'd probably be easier to address these issues by taking away hosts' ability to multicast to other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke mode of LAN operation, allowing the designated routers to also act as traffic sanitisers for on-link inter-host traffic.
> 
> I agree, that's the deployment model I advocate for hostile scenarios. Use DHCPv6 for stateful addressing, advertise default GW via RA, don't advertise any on-link prefix, and make sure hosts can't L2 communicate at all with each other by means of enforcement in switches (or just separate them into different L2 domains).

controller based wireless deployments can largely do this for ipv4 (and v6 to some extent) today. it's a fairly heavyweight approach for lightly managed networks.

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Jun 2011 08:39:12 -0700

Mark and Mikael,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Mikael Abrahamsson
> Sent: Wednesday, June 22, 2011 4:42 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND 
> and extension headers)
> 

That's just how ISATAP works when the advertising
ISATAP routers do not advertise on-link IPV6 prefixes.
However, the advertising ISATP routers can also send
ICMPv6 Redirects - which is really still in keeping
with your characterization of "traffic sanitiser".

> advertise any on-link prefix,

That's exactly the model I had in mind for ISATAP.

> and make sure hosts can't L2 
> communicate at 

This would certainly enforce a true hub-and-spokes,
but may be overly restrictive in some environments.
For example, if a host has a way of knowing at L2
that a packet has come from a trusted router and not
an anonymous node on the link then there may not be
such a strong requirement for L2 segregation. ISATAP
provides such a means.

Thanks - Fred
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Jun 2011 13:04:35 -0700

On Jun 22, 2011, at 4:15 AM, Mikael Abrahamsson wrote:

> Just the same way that it's "obvious" that anyone can spoof RAs on a flat L2 lan, it's "obvious" that fragmentation and headers can make parsing actual payload harder and needs to be handled. These two "obvious" have historically been overlooked numerous times.

From my perspective, the issue with the RA-Guard evasion draft isn't that the faults are possible or that they are described; it's that the description is specific to RA-Guard. In point of fact, these kinds of attacks are true for any kind of firewall or other middleware that has the notion of identifying a specific non-IP packet and selectively do something to it. I personally think the right way to approach this is to describe the attack and note, in a footnote somewhere, that one of the ten thousand special cases it applies to is RA Guard. Another one that it applies to is any case of deep packet inspection, a specific special case of that being Cleanfeed - anyone that thinks they can use deep packet inspection to eliminate pornography, Al-Queda literature, or dog racing should be advised that overcoming that is as simple as https or obscure fragmentation that splits a "GET" at a difficult place.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jun 2011 16:18:50 -0400

> I agree, that's the deployment model I advocate for hostile scenarios. Use DHCPv6 for stateful addressing, advertise default GW via RA, don't advertise any on-link prefix, and make sure hosts can't…

Huh.   If I had a choice between RA and multicast, I think I'd choose multicast.   When you have to utterly cripple your technology in order to continue using a protocol, I think it's time to ask whether or not the protocol you're using is the right protocol at all.

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Jun 2011 09:55:48 +0930

Hi Ted,

On Wed, 22 Jun 2011 16:18:50 -0400

> Huh.   If I had a choice between RA and multicast, I think I'd choose multicast.   When you have to utterly cripple your technology in order to continue using a protocol, I think it's time to ask w…

You're right, with Ethernet being the wrong protocol. An Ethernet LAN's
nature is peer-to-peer or full mesh - every attached node can send to
any other individual node, many other nodes, or all other nodes. For SPs
who want to bill for, and possibly control/sanitise their inter-customer
traffic, this link layer peer-to-peer nature is a problem.
Hub-and-spoke or point-to-point reachability is what they want. If it
is possible to enforce a hub-or-spoke topology on an Ethernet LAN by
preventing the 1-to-many or 1-to-any capability, in effect making it an
NBMA link-layer, or creating a point-to-point topology via VLANs, then
Ethernet is the best choice because it is both cheap and ubiquitous. 

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Jun 2011 09:59:04 +0930

Hi Ran,

On Wed, 22 Jun 2011 08:10:27 -0400

> simpler/cheaper/easier than the issues Fernando's proposal raises.

Part of what influenced my suggestion is that mechanisms to implement
these sorts of controls already exist in some layer 2 devices - the
private vlan feature and placing devices into specific VLANs based on
802.1x authentication. So for environments where rouge RAs are a
likelihood, some of these mechanisms, possibly with some necessary
changes or additions to IPv6 (e.g. DUD proxy) might be more a
more effective and more general "traffic sanitation" solution for all
ND based threats, including rogue RAs, spoofed ND NAs etc.

> They might conclude that the "cure" is worse than the "disease".

I completely agree, the security context definitely needs to be
considered. A drawback of making a change as fundamental as, for
example, prohibiting fragmentation in ND messages, is that it implies
that it is necessary in any and all contexts. That may not actually be
true.

In the contexts where rouge RAs are a likelihood (e.g. public wifi,
"IPoE" SP networks, etc.) rather than a rare accident , then some of the
other layer 2 traffic control mechanisms I mentioned are probably going
to be deployed. I wonder if their likely presence reduces the need to
make such fundamental changes to IPv6 as disabling fragmentation in ND.

With the relatively large number of subnets available in IPv6, up to a
point it is practical to have a single host-router pair in a subnet.
Once you do that, the only possible victims of these threats are the
host itself or the router it depends on for off-link reachability, and
those router consequences will or can be limited to the router's host
facing interface. These types of on-link threats have now been mitigated
or eliminated by individually quarantining each host and using their
own self-interest to control their behaviour.

Best regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jun 2011 20:56:52 -0400

On Jun 22, 2011, at 8:25 PM, Mark Smith wrote:
> You're right, with Ethernet being the wrong protocol.

Well, let's be clear here: Ethernet is apparently the wrong protocol *for you*.   You should be running 802.1x, not plain ethernet, because you have specific needs that make plain ethernet an inappropriate choice for you.

But that wasn't what I was talking about.   IPv6 has to work on ethernet.   IPv6 multicast is useful, and we (at least, some of us) want it to work.   The solution to the rogue RA problem is not to get rid of ethernet (or at least, so I claim).   Moreover, even supposing we could get rid of ethernet in the sense that you mean, that would simply paper over the problem, not solve it.   If we want a secure network, we have to use secure protocols.   Firewalls are a great second-level defense (and your hub-and-spoke model is basically a firewall).   But they do not make your network secure: they simply make it harder to attack.

So if in fact it is impossible for RA to be adequately secured on an ethernet, then we need to fix RA, or come up with a different solution, not slap a bandage on it and call it done.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Jun 2011 07:48:32 +0200 (CEST)

On Wed, 22 Jun 2011, Ted Lemon wrote:

> Huh.  If I had a choice between RA and multicast, I think I'd choose 
> multicast.  When you have to utterly cripple your technology in order to 
> continue using a protocol, I think it's time to ask whether or not the 
> protocol you're using is the right protocol at all.

Could you please rephrase the above, I don't understand. Protocol?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Jun 2011 08:34:05 +0200 (CEST)

On Thu, 23 Jun 2011, Mark Smith wrote:

> Hub-and-spoke or point-to-point reachability is what they want. If it is 
> possible to enforce a hub-or-spoke topology on an Ethernet LAN by 

Yes, this has been a very successful model for high speed residential 
connectivity (ETTH) the past 10 years.

And yes, you have to protect the users from each other, so they don't do 
MITM-attacks on each other. This requires some kind of limitation of 
traffic they can send to each other using L2, and full L2 isolation is of 
course the best.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Jun 2011 08:36:26 +0200 (CEST)

On Wed, 22 Jun 2011, Ted Lemon wrote:

> So if in fact it is impossible for RA to be adequately secured on an 
> ethernet, then we need to fix RA, or come up with a different solution, 
> not slap a bandage on it and call it done.

I don't see how it can be fixed. Short of encrypting all traffic and 
pre-distributing keys, ethernet can't be fixed without the "bandaids" you 
seem to call the measures being used widely to assure ethernet can in 
fact be used securely.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jun 2011 16:30:37 -0400

On Jun 23, 2011, at 2:36 AM, Mikael Abrahamsson wrote:
> I don't see how it can be fixed. Short of encrypting all traffic and pre-distributing keys, ethernet can't be fixed without the "bandaids" you seem to call the measures being used widely to assure ethernet can in fact be used securely.

There probably is no single solution.   But let's consider the solution Mark proposed: use the fact that you control the infrastructure to control the flow of packets on the network in such a way that rogue RAs cannot reach leaf nodes.   The reason I object to this solution, in addition to the fact that it breaks multicast, is that it's a firewall solution: the client doesn't know it's safe, and as soon as it connects to a network that's not protected in this way, it's vulnerable.   But the model of using infrastructure control as a credential is interesting.

Is there a way that someone who is not running 802.1x can demonstrate that they control layer 2?   It seems to me that for most examples of Layer 2 that we care about, the answer is probably yes.   So then if the secure link to the router can be used to communicate a secret, and the network can provide that secret back to the user in a way that a rogue RA agent could not do, then the end node can discriminate between rogue RAs and legitimate RAs.

E.g., suppose we have a WiFi network secured with WPA.   WPA uses an X.509 cert to establish the identity of the WPA server.   If the private key authenticated by the cert is used to sign the secret the client provides, then the client can be sure that the router it is talking to is controlled by the same entity that controls WPA.   Since WPA is tied directly to the infrastructure, that's proof that the router is managed by the infrastructure provider.
 
Another solution that would work well in the case of frequently-visited networks would be the model that ssh uses: keep a list of good routers.   When you connect to a wire, prefer routers on the "good" list to new routers.   If no RAs come from routers on the "good" list, then you need a heuristic to decide whether or not a new router is good.   The mechanism I described in the previous paragraph could be used to handle some exceptional cases; other heuristics could be used to handle cases where the link is not secured in any way: if I try to establish secure connections, and those connections turn out to be exposed to MITM attacks, then the router (and hence, the RA from that router) are not trustworthy.

The problem with this stuff is not that it's impossible.   It's that it's not simple.   If you want your communications to be secure, you have to secure them.   If all your communications are secure, then a rogue RA can only do two things: deny service, or allow an attacker to do traffic analysis and/or cryptanalysis that would not otherwise be possible.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 23 Jun 2011 15:40:12 -0500

Ted Lemon wrote:

> There probably is no single solution.   But let's consider the solution
> Mark proposed: use the fact that you control the infrastructure to
> control the flow of packets on the network in such a way that rogue RAs
> cannot reach leaf nodes.   The reason I object to this solution, in
> addition to the fact that it breaks multicast, is that it's a firewall
> solution: the client doesn't know it's safe, and as soon as it connects
> to a network that's not protected in this way, it's vulnerable.   But
> the model of using infrastructure control as a credential is
> interesting.

While I too find it hard to accept the ETTH solution as being "real" Ethernet, I believe it is the network that is trying to protect itself here, more than altruistic protection of clients. If clients are protected as a result, great.

Yes, in another network, those same clients might not be protected at all.

Your solutions appear to be more client-oriented.

Bert

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jun 2011 17:25:23 -0400

> Your solutions appear to be more client-oriented.

That's correct.   Ultimately the security of the client depends on the client being secure.   Trying to secure the client by securing the network is a noble cause, but ultimately doomed to failure, because you can't control what networks the client connects to.   Of course there are special cases where this isn't true, but as mobile nodes get more and more capable, the set of all such special cases gets smaller and smaller.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 23 Jun 2011 16:31:07 -0500

Ted Lemon wrote:

> That's correct.   Ultimately the security of the client depends on the
> client being secure.   Trying to secure the client by securing the
> network is a noble cause, but ultimately doomed to failure, because you
> can't control what networks the client connects to.

No, I think you have it backwards.

It is service providers that are interested in protecting their networks, in this discussion. If they also happen to protect their clients, that is just a nice byproduct.

Service providers want to keep malicious clients from degrading their network.

Bert

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jun 2011 17:56:47 -0400

> It is service providers that are interested in protecting their networks, in this discussion. If they also happen to protect their clients, that is just a nice byproduct.

That's fine for service providers, but service providers are not the only interested parties here.   Mark's solution does fine for that use case, but I would not want it on my home network.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jun 2011 18:13:31 -0400

On Jun 23, 2011, at 6:08 PM, Philip Homburg wrote:
> Ideally, clients use end-to-end crypto to keep themselves secure, but the
> network still has to be protected against denial of service attacks.

No, strictly speaking the *clients* need to be protected against DoS attacks.   One way to do this is to strongly control multicast on the network.   But the network itself cannot suffer from rogue RA advertisements: it is other clients on the network that suffer.   I realize that this seems like a trivial distinction, but I think it's important to be clear about it, because it's not always a safe assumption that any given network will be protected, and hence if we really care about DoS attacks as a general problem, we need to address the problem in a way that will work not just on hub-and-spoke networks, but on broadcast networks as well.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Jun 2011 09:41:14 +1000

For many years I just filtered out rogue RA's on my laptop at IETF.

I looked at which routers were advertising which prefixes and
configured a allow list in the firewall for those that looked correct
and denied the rest.  Then I removed the bogus addresses, generated
as the result of those RA's, from the interface.  I also remove the
default route when it pointed to a bogus router and performed a
router solicitation.  Making that into a GUI so the user can point
and click should be relatively easy.

Add to that next hop selection where you only send to a router that
is advertising a prefix covering the source address you are using
and trying from multiple source address, you can mostly eliminate
the impact of accidental rogue RA's without needing to filter.

If you want to eliminate malicious RA's then you need the network
operator to help by using CGA's or similar so you can identify
spoofed from non-spoofed RA's.  The node can learn which router is
using CGA's and automatically filter spoofed ones.  By keeping a
little more state it can also automatically cleanup the side effects
from those spoofed RA's.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Jun 2011 10:14:06 +0930

Hi,

On Thu, 23 Jun 2011 16:30:37 -0400
Ted Lemon <[email-masked]> wrote:

> There probably is no single solution.   But let's consider the solution Mark proposed:

Just to be clear, I wasn't suggesting the methods commonly used in ETTH
networks is a universal solution.

It seems to me that organisations that would care the most about
malicious RAs are SPs. Yet they're already likely to have or put
measures in place that naturally mitigate that risk as well as
achieving other goals that they have such as traffic billing. So
malicious RAs may not be as as much of a threat to them as
people might think. Implementing these sorts of measures are just a
natural cost of business, because it is part of ensuring your service is
available, and ensuring one customer has limited ability to disrupt
another's service.

Enterprise networks may be most concerned about accidental RAs, as they
typically tend to have more control over what hosts can do because they
operate them, rather than the customers in the SP case. As Ray
mentioned, if the cost of implementing RA guard is prohibitive, some
enterprises might just accept the risk and consequences of an
occasional accidental RA.

Are there other contexts that I haven't identified? The reason I've
thought about these contexts is that proposals such as
universally preventing fragmentation in ND is a one-size-fits-all
approach to the problem that probably can't be reversed if chosen.

> use the fact that you control the infrastructure to control the flow
> of packets on the network in such a way that rogue RAs cannot reach
> leaf nodes.   The reason I object to this solution, in addition to the
> fact that it breaks multicast, is that it's a firewall solution: the
> client doesn't know it's safe, and as soon as it connects to a network
> that's not protected in this way, it's vulnerable.   But the model of
> using infrastructure control as a credential is interesting.
> 

This is basically Secure Neighbor Discovery (SeND) with the addition of
key distribution via the 802.1x. I'm not sure the combination exists or
is possible, I've been meaning to look into it for a while.

> The problem with this stuff is not that it's impossible.   It's that it's not simple.   If you want your communications to be secure, you have to secure them.   If all your communications are secur…

Agree with it not being simple. A secure protocol to authenticate RAs
already exists - SeND. The problem with it is the lack of
implementations and the key distribution problem. Since we know that
methods such as RA guard aren't really "properly secure" and can't be,
I think it is important to not to have unrealistic security
expectations of them.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Thu, 23 Jun 2011 20:30:05 -0500

On 6/23/11 15:30 CDT, Ted Lemon wrote:
>> I don't see how it can be fixed. Short of encrypting all traffic
>> and pre-distributing keys, ethernet can't be fixed without the
>> "bandaids" you seem to call the measures being used widely to
>> assure ethernet can in fact be used securely.
>
> There probably is no single solution.   But let's consider the
> solution Mark proposed: use the fact that you control the
> infrastructure to control the flow of packets on the network in such
> a way that rogue RAs cannot reach leaf nodes.   The reason I object
> to this solution, in addition to the fact that it breaks multicast,
> is that it's a firewall solution: the client doesn't know it's safe,
> and as soon as it connects to a network that's not protected in this
> way, it's vulnerable.   But the model of using infrastructure control
> as a credential is interesting.

I don't think of RA-Guard and DHCP-Guard filters as security measures, 
they are simply network management and operations techniques.  They 
don't make the network more secure, but they can make operating some 
networks much easier.  They probably also can make some networks more 
reliable and usable too.  But, calling them more secure is probably a 
stretch.

A quick story; 6 years ago we replaced our network and implemented IPv4 
DHCP-Guard filters on all access ports on our network, doing this 
eliminated about 300 trouble tickets a year from rogue IPv4 DHCP servers 
showing up on our network, home routers used as cheep switches without 
disabling DHCP, Internet connection sharing software on laptops, etc... 
  Between staff time to track down the offending devices and lost 
productivity of the effected users, lets use a conservative average cost 
of $500 an incident, that is $150K a year of cost savings to the 
University.  This didn't make our network one bit more secure, it is 
still a wide open network that anyone can use, but it is now cheaper to 
run and provides a more reliable and usable service to our users.

This draft is need, if nothing else to let people know about this issue, 
and if we can find an acceptable way to mitigate the issue great, but 
classic RA-Guard is still a very effective network management and 
operations technique, with or without mitigation of this issue. 
Unintentional rogue RAs are big issues in a LAN environment of any 
substantial size.  However, without mitigation of this issue, RA-Guard 
is not an effective network security technique. It can't deal with 
malicious rouge RAs that are a security threat.

> Is there a way that someone who is not running 802.1x can demonstrate
> that they control layer 2?   It seems to me that for most examples of
> Layer 2 that we care about, the answer is probably yes.   So then if
> the secure link to the router can be used to communicate a secret,
> and the network can provide that secret back to the user in a way
> that a rogue RA agent could not do, then the end node can
> discriminate between rogue RAs and legitimate RAs.
>
> E.g., suppose we have a WiFi network secured with WPA.   WPA uses an
> X.509 cert to establish the identity of the WPA server.   If the
> private key authenticated by the cert is used to sign the secret the
> client provides, then the client can be sure that the router it is
> talking to is controlled by the same entity that controls WPA.
> Since WPA is tied directly to the infrastructure, that's proof that
> the router is managed by the infrastructure provider.

OH... That's an intriguing idea, use 802.1x to securely feed SEND.  That 
might even make using SEND practical in an open network environment like 
a University.  Its a massing protocol layering violation, but most 
things in the security realm are.

> Another solution that would work well in the case of
> frequently-visited networks would be the model that ssh uses: keep a
> list of good routers.   When you connect to a wire, prefer routers on
> the "good" list to new routers.   If no RAs come from routers on the
> "good" list, then you need a heuristic to decide whether or not a new
> router is good.   The mechanism I described in the previous paragraph
> could be used to handle some exceptional cases; other heuristics
> could be used to handle cases where the link is not secured in any
> way: if I try to establish secure connections, and those connections
> turn out to be exposed to MITM attacks, then the router (and hence,
> the RA from that router) are not trustworthy.
>
> The problem with this stuff is not that it's impossible.   It's that
> it's not simple.   If you want your communications to be secure, you
> have to secure them.   If all your communications are secure, then a
> rogue RA can only do two things: deny service, or allow an attacker
> to do traffic analysis and/or cryptanalysis that would not otherwise
> be possible.

Yep, if you secure your communications then these issues are only 
network management and operational issues, not security issues. However, 
depending on the network, you still might want to use RA-Guard to 
prevent such operational issues.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jun 2011 00:17:01 -0300

> traffic sanitisers for on-link inter-host traffic.

Two comments:

* Hosts would still need to multicast RSs
* This does nto prevent attackers from sending ND packets *unicast* to
their victims.

Thanks,
-- 
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: Fri, 24 Jun 2011 13:59:57 +0930

Hi Fernando,

On Fri, 24 Jun 2011 00:17:01 -0300

> * Hosts would still need to multicast RSs

Yes, but the layer 2 device only delivers those multicast RSes to ports
that it has been told are attached to authorised routers.

> * This does nto prevent attackers from sending ND packets *unicast* to

Actually it can.  Have a look at the following -

http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-01

The layer 3 hub-and-spoke forwarding topology described can also be and
is likely to also be enforced at layer 2, by preventing layer 2
forwarding of traffic between designated host ports, limiting it to
host port to router port, or router port to host port.

It's interesting to look back on where we've come from. On simple
10BASE2 and earlier Ethernet, broadcast/multicast was cheap, because it
was the inherent nature of it's bus topology. After we moved to
bridges/switches with individual devices attached to each port, this
broadcast/multicast capability had to be actively emulated, because a
star topology does not have a natural broadcast/multicast capability.
Implementing hub-and-spoke forwarding paths in a bridge/switch is
not much more than reducing the requirement to emulate something that
fundamentally wasn't natural in the first place.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 24 Jun 2011 07:14:52 +0200 (CEST)

On Thu, 23 Jun 2011, Ted Lemon wrote:

> that they control layer 2?

Doesn't 802.1x only control access as a non/off switch? As soon as you're 
connected to the network, I thought it was back to flat L2 default 
ethernet again?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 24 Jun 2011 07:16:07 +0200 (CEST)

On Thu, 23 Jun 2011, Manfredi, Albert E wrote:

> It is service providers that are interested in protecting their 
> networks, in this discussion. If they also happen to protect their 
> clients, that is just a nice byproduct.

We want to protect the Internet from our customers, not our customers from 
the Internet.

> Service providers want to keep malicious clients from degrading their 

Exactly.

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Jun 2011 15:35:15 +0930

On Fri, 24 Jun 2011 07:14:52 +0200 (CEST)

> connected to the network, I thought it was back to flat L2 default 

The thing I've been intending to investigate was whether 802.1x could
deliver non-authentication related attributes to the supplicant upon
successful authentication, similar to RADIUS Access-Accept messages. If
it could, I think that could be used to perform the key distribution to
bootstrap SeND.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Jun 2011 00:08:12 +0200

In your letter dated Thu, 23 Jun 2011 17:56:47 -0400 you wrote:
>> It is service providers that are interested in protecting their networks, in
> this discussion. If they also happen to protect their clients, that is just a
> nice byproduct.
>
>That's fine for service providers, but service providers are not the only inte
>rested parties here.   Mark's solution does fine for that use case, but I woul
>d not want it on my home network.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Jun 2011 11:06:46 +0200

In your letter dated Thu, 23 Jun 2011 18:13:31 -0400 you wrote:
>> Ideally, clients use end-to-end crypto to keep themselves secure, but =
>the
>No, strictly speaking the *clients* need to be protected against DoS =
>attacks.   One way to do this is to strongly control multicast on the =
>network.   But the network itself cannot suffer from rogue RA =
>advertisements: it is other clients on the network that suffer.   

You are right if we just limit ourselves to RAs. But my comment was meant to
be broader than that. 

If a malcious client configures a router's MAC address on his ethernet card
then it is not the clients' faults if L2 switches route traffic to the wrong
port. Same thing if a malicious client uses another client's IP address and
the router gets confused.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Jun 2011 11:12:10 +0200

>things in the security realm are.

I'm not sure how that's supposed to improve things. To make 802.1x secure
(for the client) the client needs to have the server's certificate. Otherwise
there can be a man-in-the-middle attack.

If you have a way of providing clients with certificates, why not distribute
the keys for SEND directly?

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jun 2011 09:08:10 -0300

On 06/23/2011 10:30 PM, David Farmer wrote:
> networks much easier.  

If they can mitigate specific attack vectors, they do make the network
more secure.

Thanks,

---

From: David Farmer <[email-masked]>
Date: Fri, 24 Jun 2011 08:39:01 -0500

> the keys for SEND directly?

 From a technical and theoretical point of view you are correct, they 
are fundamentally the same problem. However, from a practical point of 
view, there are available solutions and tools, even some commercially 
available, for dealing with securely configuring 802.1x, especially in 
the wireless realm with WPA2, at many different scales, from the home 
user network all the way up to multinational enterprise.

The issue even has some mind share with the non-technical end users 
world, thanks to the virus like spread of wireless home gateways.

So, the key/certificate distribution problem is hard enough to do right 
once.  We are getting close with 802.1x and WPA2, why not build on that 
for SEND?  I'm not saying you shouldn't be able to configure SEND 
separately if you wish, and if you can that might be even more secure. 
But, being able to securely generate keys or obtain certificates for 
SEND using 802.1x and/or WPA2 would create a much lower barrier to entry 
for SEND.

But even with all that, we don't eliminate the usefulness of RA-Guard in 
may situations.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jun 2011 09:08:10 -0300

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jun 2011 10:23:19 -0300

> host port to router port, or router port to host port.

I think that deploying this only for dealing with ND-based attacks would
be overkill.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Sat, 25 Jun 2011 00:34:50 +0930

On Fri, 24 Jun 2011 10:23:19 -0300

> I think that deploying this only for dealing with ND-based attacks would

Depends on who you are.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jun 2011 16:31:26 -0300

On 06/22/2011 05:04 PM, Fred Baker wrote:

>> From my perspective, the issue with the RA-Guard evasion draft
>> isn't that the faults are possible or that they are described; it's
>> that the description is specific to RA-Guard. In point of fact,
>> these kinds of attacks are true for any kind of firewall or other
>> middleware that has the notion of identifying a specific non-IP
>> packet and selectively do something to it. 

There some specific considerations for RA-Guard:

* RA-Guard has been specified, whereas firewall behaviour hasn't.

* Many networks employ DHCPv4-guard and/or arp-monitoring, and probably
expect to be able to do the same thing with IPv6 -- but these evasion
techniques apply only to the v6 case

* RA-Guard is implemented in layer-2 devices, where fragment reassembly
would be too onerous.

>> to eliminate pornography, Al-Queda literature, or dog racing should
>> be advised that overcoming that is as simple as https or obscure
>> fragmentation that splits a "GET" at a difficult place.

Parsing the app stream was already difficult with v4. Not being able to
even find the upper-layer header is new with v6.

Thanks,