Subject: Re: [saag] Looking for guidance re draft-gont-v6ops-ra-guard-evasion

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Jun 2011 09:58:32 +0100

Hi Fred,

On 16/06/11 01:11, Fred Baker wrote:
> I have a request from the authors to present draft-gont-v6ops-ra-guard-evasion in v6ops. The document describes two ways that a motivated attacker could attack RA-Guard (RFC 6105). For the first, he postulates that an RA Guard implementation might look at the first "Next Header" field rather than parsing the full IPv6 header, and as a result an attacker could slide his rogue RA by using a Destination Options header. In the second, he observes that if he fragments the message, the switch will be unlikely to be able to parse it because it can't reassemble it.
> 
> The observations are legitimately true; an implementation that takes shortcuts is likely to miss cases, and fragmentation has that effect. It also seems like the observations are (a) generic to IPv6 datagrams, not just RA messages, and (b) not something an operator can do much about. Hence, I question the value of the draft to the operational community. It seems like a better fit to the security area or to 6man, who might be in a position to do something about it.

Yeah, I had a look at this when it was mentioned for that
ITU-T liaison and I see what you mean. I guess an operator
could look out for this, but can't do much more if their
kit is vulnerable.

I'd say if this isn't a v6ops thing then its more one
for Ralph and Jari though - for example, if someone found
a (non-crypto) problem with a SIP header I reckon we'd
deal with that to somewhere in RAI and I think this is
similar, so 6man looks to me more appropriate than the
security area if it doesn't belong in v6ops.

Maybe another way to look at it would be to ask what
RFC it might UPDATE and then have it land wherever that
came from?

Cheers,
S.

> Looking for advice...

---

From: Sean Turner <[email-masked]>
Date: Thu, 16 Jun 2011 07:57:21 -0400

>> The observations are legitimately true; an implementation that takes shortcuts is likely to miss cases, and fragmentation has that effect. It also seems like the observations are (a) generic to IP…

snip

> RFC it might UPDATE and then have it land wherever that

This was where I was going.

spt

---

From: Fernando Gont <[email-masked]>
Date: Thu, 16 Jun 2011 13:34:45 -0300

>> RFC it might UPDATE and then have it land wherever that

My take is that this document should update the RA-Guard RFC (RFC6105),
which was produced by v6ops, and thus draft-gont-v6ops-ra-guard-evasion
should be pursued within v6ops. Additional, this is an operational
problem, and thus we should be producing possible mitigations for it
(see the proposed filtering in the aforementioned I-D).

My other I-D related to this subject
(draft-gont-6man-nd-extension-headers) is orthogonal to this: having
6man prohibit the use of extension headers in ND packets would
eventually enable for simpler and cleaner mitigations...

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 16 Jun 2011 14:19:29 -0300

On 06/16/2011 01:51 PM, Fred Baker wrote:

> Where I'm scratching my head is implementation. Since ND is a special
> case of ICMPv6, ICMPv6 is a payload of IPv6 (and therefore lacks
> visibility into individual fragments after they have been
> reassembled), and we're talking about an L2 device analyzing the
> packet to decide whether or not to allow it, this comes down pretty
> quickly to having the switch block any packet with extension headers.

No, I'm not suggesting that. See the proposed filter in the I-D. Also,
if extension headers are prohibited in ND messages, then a simple
RA-Guard implementation is possible, without having to affect any other
traffic that uses extension headers.

> I'm pretty sure that's not what you're suggesting, but I suspect it's
> the direction the suggestion goes. It is, for example, what became of
> the IPv4 suggestion that we not allow the various "record route"
> options...

I'm not sure how my proposal relates to the "record route" options.
Record route options are probably blocked because the potential/eventual
legitimate uses for them do not outweigh their security implications.

> The better solution, of course, is to have an end system that
> receives RAs with extensions (assuming the ICMPv6 module can tell)
> discard such messages. That still has the end system dealing with the
> message, which is counter to one of the objectives of RA Guard;
> consuming end system resources is part of the attack.

Not sure what you mean. Are you suggesting that end-systems should deal
with the problem of Rogue-RAs? -- Anyway, the argument was about whether
whether v6ops was an acceptable choice for pursuing this I-D...

Thanks,

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Jun 2011 17:11:33 -0700

Looking for advice...

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Jun 2011 07:18:17 -0700

> RFC it might UPDATE and then have it land wherever that

Thanks. That makes sense.

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Jun 2011 09:51:58 -0700

> (see the proposed filtering in the aforementioned I-D).

That may be the right answer.

> eventually enable for simpler and cleaner mitigations...

That also may be a right answer. 

Where I'm scratching my head is implementation. Since ND is a special case of ICMPv6, ICMPv6 is a payload of IPv6 (and therefore lacks visibility into individual fragments after they have been reassembled), and we're talking about an L2 device analyzing the packet to decide whether or not to allow it, this comes down pretty quickly to having the switch block any packet with extension headers. I'm pretty sure that's not what you're suggesting, but I suspect it's the direction the suggestion goes. It is, for example, what became of the IPv4 suggestion that we not allow the various "record route" options...

The better solution, of course, is to have an end system that receives RAs with extensions (assuming the ICMPv6 module can tell) discard such messages. That still has the end system dealing with the message, which is counter to one of the objectives of RA Guard; consuming end system resources is part of the attack.

In the words of a wise person I once spoke with, all things are possible to him who doesn't have to do it...

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 19 Jun 2011 14:22:19 -0700

I think that's it's fine to socialize it. the analysis is consistent with a general class of problems which have the potential to impact protocols beyond RA such as dhcp6. from my vantage point turning stateless l2 devices into general purpose protocol inspect engines in the process of solving this is probably a mistake.

joel

On Jun 15, 2011, at 5:11 PM, Fred Baker wrote:

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