[LAC-TF] Fwd: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation

[Fernando Gont]

Estimados,

Hace días publiqué una revision de mi I-D sobre evasión de RA-Guard.

Lo que sigue debajo es mi respuesta a los comentarios recibidos hace
minutos en la lista de correo correspondiente (v6ops).

Si alguien está interesado que el tema se solucione, sugiero que
participe en la discusión correspondiente de la lista de correo del
v6ops WG (IPv6 Operations <v6ops at ietf.org>).

Saludos, y gracias!
Fernando Gont




-------- Original Message --------
Subject: Re: [v6ops] Revised I-D: Advice on RA-Guard Implementation
Date: Fri, 06 Jan 2012 06:56:37 -0300
From: Fernando Gont <fgont at si6networks.com>
Organization: SI6 Networks
To: Gunter Van de Velde (gvandeve) <gvandeve at cisco.com>
CC: IPv6 Operations <v6ops at ietf.org>

Gunter,

On 01/06/2012 06:29 AM, Gunter Van de Velde (gvandeve) wrote:
> Many thanks for taking my comments and guidelines into account. I am
> 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.


> I do believe that describing how exactly the filtering needs to be 
> 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
> 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.

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



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

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


> 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.

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,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492