Subject: [v6ops] Revised I-D: Advice on RA-Guard Implementation

From: Fernando Gont <[email-masked]>
Date: Wed, 04 Jan 2012 21:58:50 -0300

Folks,

We've published the IETF I-D "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)". It is available at:
<http://www.ietf.org/id/draft-gont-v6ops-ra-guard-implementation-00.txt>

This I-D is based on our original I-D
draft-gont-v6ops-ra-guard-evasion-01, but now focuses on providing
advice to RA-Guard implementations, rather than on the evasion
techniques that have been found effective against most popular
implementations of RA-Guard.

Producing effective RA-Guard implementations is important to provide
feature parity with similar mitigation techniques already available and
employed in the IPv4 world.

Any feedback will be greatly appreciated.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 4 Jan 2012 20:25:34 -0500

- how much is this really about RA Guard? 
- my summary is that whatever device needs to inspect XYZ type packet before doing some processing, make sure to look at extension headers (carefully) since they may be obscuring the data.

Marc.

Le 2012-01-04 à 19:58, Fernando Gont a écrit :

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 04 Jan 2012 22:59:10 -0300

Hi, Mark,

On 01/04/2012 10:25 PM, Marc Blanchet wrote:
> - how much is this really about RA Guard? - my summary is that
> whatever device needs to inspect XYZ type packet before doing some
> processing, make sure to look at extension headers (carefully) since
> they may be obscuring the data.

1) RA-Guard implements packet-filtering at layer-2 (rather than
layer-3), so the trivial answer "reassemble, filter, and forward" does
not apply here. Otoh, Layer-3 devices need to take care of tunnels.. but
that doesn't apply to RA-Guard. In summary, the constraints are very
different. (an I-D on firewall filtering could easily be 10x more
complex than this one).

2) At least one popular RA-Guard implementation is vulnerable to these
issues. Fixing these issues is key to provide FHS (First Hop Security)
feature parity between IPv4 and IPv6.

3) This WG published two documents on RA-Guard (RFC6104 nad RFC6105),
which I'd say indicated that this is an important feature. Given that
the outcome has probalby not been the expected, it seems sensible for
the IETF to provide advice on how to get RA-Guard "right".

Thanks!

Best regards,

---

From: Simon Perreault <[email-masked]>
Date: Thu, 05 Jan 2012 08:50:16 -0500

> <http://www.ietf.org/id/draft-gont-v6ops-ra-guard-implementation-00.txt>

Section 3 (implementation advice) does not explicitly mention fragment handling.
Is this intentional? Does the advice implicitly apply to fragments? Some
clarification is needed IMHO.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Fri, 6 Jan 2012 10:29:10 +0100

Hi Fernando,

Many thanks for taking my comments and guidelines into account. I am
less opposed now, then i was before.
You are correct when stating that a bad implementation of the RA
filtering obscures the effect of RA-Guard.

I do believe that describing how exactly the filtering needs to be 
implemented is a step too far. Most types of filter will have
consequences regarding extension headers.
It is a well known limitation of traditional edge access lists that
routers are using, unless the router is doing inspection beyond L3, and
that is most of the time an expensive operation.

RA-Guard is a poor-man solution for access networks against rogue
RA's... the grown up solution is SeND.

Maybe adding a line in the RA-Guard RFC in the security section would be
a better solution as creating a new RFC explaining the implementation.

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fernando Gont
Sent: donderdag 5 januari 2012 1:59
To: IPv6 Operations
Subject: [v6ops] Revised I-D: Advice on RA-Guard Implementation

Folks,

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 06 Jan 2012 06:56:37 -0300

Gunter,

> less opposed now, then i was before.

My understanting was that, based on our off-list exchange circa Jul 29,
2011, that you were in favor of a document that addressed this issue
from this angle (implementation advice).

So I'm kinda surprised that you're "less opposed"... as this revision
(including change of title and filename) was mostly meant to please you.

> implemented is a step too far. 

The RA-Guard stuff (and RFCs) was meant to be implemented, right?

So we have one problem statement document, one framework (?) document,
but it is still hard to figure out how to get RA-Guard right.

Should live happily with that?

> Most types of filter will have

Huh?  What's the "limitation" you're referring to?

> RA's... the grown up solution is SeND.

You may s/poor-man/deployable/, as well.

> a better solution as creating a new RFC explaining the implementation.

What would that line say? "The rest of the document talks about a
security mitigation, but it can be trivially evaded by using extension
headers", or what?

My take is that RFC 6105 is underspecified, and lacking a real Security
Considerations section -- not just "a missing line".

Thanks,

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Fri, 6 Jan 2012 11:34:23 +0100

Hi Fernando,

What i wrote to you in a 1-2-1 mail was:

<>start<>
Hi Fernando,

I just read your paper. It indeed removes my concerns.
Many thanks for taking them into consideration.

Speak later,
G/
<>end<>

It means that i will not fight anymore to have this work put in 
the bit-bucket. Its interesting to read, and deals with an interesting 
problem statement. However, the issue is bigger as 'just' RA-Guard
implementation imho.
It is how data-traffic filters really should be implemented, taking ext
headers into account.

I am just not sure it justifies a potential RFC, mainly because its well
known access-list avoidance.

I do agree that security section of RA-Guard is not detailed enough,
particular taking your 
work into consideration, and i take blame for that.
We could respin the security section, however i have no clue on how to
that and how the logistics work for that.

G/

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: vrijdag 6 januari 2012 10:57
To: Gunter Van de Velde (gvandeve)
Cc: IPv6 Operations
Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation

Gunter,

Thanks,

---

From: Gert Doering <[email-masked]>
Date: Fri, 6 Jan 2012 12:09:48 +0100

Hi,

> RA's... the grown up solution is SeND.

We need both.  SeND won't help if network participants are not able
to prime their machines with the certificates needed to authenticate RAs.

Think IETF networks...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Fernando Gont <[email-masked]>
Date: Fri, 06 Jan 2012 08:38:13 -0300

Hi, Gunter,

> What i wrote to you in a 1-2-1 mail was:
[..]

I was referring to the e-mails you sent me off-list right after this I-D
was presented at the IETF meeting in July 2011. You not only agreed with
pursuing this effort, but also put me in contact with one folk at Cisco,
so that we'd "resubmit" the I-D together.

I've just forwarded you those e-mails of list. I can copy an excerpt to
the list, if you want.

> known access-list avoidance.

So essentially your saying that the IETF went through the effort of
publishing RFC 6105 even when it was it was well-known that RA-Guard
could be trivially evaded?

-- Sorry, but I don't buy that.

> work into consideration, and i take blame for that.

There's no "blame" to take. An specs is published, someone finds holes
or "missing stuff", and it gets fixed. That's why we have the "update"
metadata, after all, isn't it?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 08 Jan 2012 23:14:23 -0300

Hi, Simon,

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

> clarification is needed IMHO.

The second bullet in Section 3 is meant to address fragment-handling:

   o  If the layer-2 device is unable to identify whether the packet is
      an ICMPv6 Router Advertisement message or not (i.e., the packet is
      a fragment, and the necessary information is missing), and the
      IPv6 Source Address of the packet is a link-local address or the
      unspecified address (::), block the packet.

The idea is that if that non-first fragments are always forwarded,
whereas first-fragments are blocked if:

a) We've found that what follows the fragment header is an RA packet, or,

b) this is a first-fragment, and it is missing upper-layer protocol
information.

Please let me know if you still feel that further clarification is
needed. And, if so, whether you feel that an additional bullet should be
added, or whether the aforementioned clarification should be added right
after the bullets (i.e., non-bulleted).

Thanks!

Best regards,

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Jan 2012 12:31:22 +0100

>b) this is a first-fragment, and it is missing upper-layer protocol

In theory (when it comes to RA or other ND packets) it should be secure to
let the fragment through if the hop count is not equal to 255.

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 09 Jan 2012 09:03:11 -0800

> to prime their machines with the certificates needed to authenticate RAs.

Think any network where no pre-existing relationship exists.

---

From: Gert Doering <[email-masked]>
Date: Mon, 9 Jan 2012 19:12:12 +0100

Hi,

[..]
> Think any network where no pre-existing relationship exists.

Of course.  IETF networks are just an example that readers on this 
list should recognize, and nothing particularily exotic.

Gert Doering
        -- NetMaster

---

From: Simon Perreault <[email-masked]>
Date: Wed, 11 Jan 2012 08:13:51 -0500

> b) this is a first-fragment, and it is missing upper-layer protocol

Ok, I understand now. Thanks.

I still don't see where in the text it is said that non-first fragments 
are always forwarded. It looks like it makes no difference between first 
and non-first.

Simon

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2012 11:42:22 -0300

Hi, Simon,

> are always forwarded. It looks like it makes no difference between first

You're right. I will improve the corresponding section and send you a
heads up so that you can take a look and comment before I rev the document.

Thanks!

Best regards,