Subject: RA-guard ... useful or not (draft-vandevelde-v6ops-ra-guard )

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Tue, 4 Dec 2007 23:45:01 -0500

Hello,
 
I would like to follow up on the discussion in the WG regarding
solutions to the rogue RAs problem. As one of the co-authors of the
RA-guard drafts I obviously see value in this work so I wanted to bring
some of the pro arguments up for discussion. In return, I am looking for
the counter arguments which could help reach a conclusion on the
usefulness of this work.
 
Overview:
We see the RA-guard document as providing a framework for several
solutions to the rogue-RA problem. These solutions can span the spectrum
from basic (where the port of the L2 device is statically instructed to
forward or not to forward RAs received from the connected device) to
advanced (where a criteria is used by the L2 device to dynamically
validate or invalidate a received RA, this criteria can even be based on
SEND mechanisms). In its current format, the RA-guard document is a
generalized perspective which could provide explicit examples (the
authors have several) of implementations that could be built within its
framework. 
 
RA-guard as a deployment complement to SEND:
RA-guard does not intend to provide a substitute for SEND based
solutions. It actually intends to provides solutions in those
environments where SEND might not be suitable or immediately available.
I think it might be fair to expect that there will be some time before
SEND is ubiquitous in IPv6 networks and that its large scale deployment
still requires a few things to be sorted out. It is also reasonable to
expect that some devices might not consider implementing SEND at all.
And even when they do, there are some deployment challenges ahead. Many
dealing with provisioning hosts with trust anchor certificates. The
RA-guard "SEND-validating" RA on behalf of hosts would potentially
simplify some of these challenges.
 
RA-guard intends to provide simple solutions to the rogue-RA problem in
such contexts and while in some cases it will do that through a simple
solution in others, it leverages SEND between capable devices (L2 and
routers) to provide protection to devices that do not consistently use
SEND. 

Looking forward to hear everyone's feedback and thoughts on this
perspective and these points.
 
Thank you!
Chip