Subject: Review of RA Guard, draft-vandevelde-v6ops-ra-guard-01

From: Christian Vogt <[email-masked]>
Date: Fri, 2 May 2008 14:48:00 +0300

Gunter, Eric, Ciprian, Janos,

I read your RA Guard proposal, and I believe this will be a very
useful feature.  Especially the simple operational mode, in which
Router Advertisement messages are allowed only on manually
pre-configured ports, would provide a good level of security at low
cost.  Two comments, nevertheless:

(1)  The RA Guard currently has two separate state machines, one for
      the RA Guard device itself, and one on the per-interface level.  I
      do not see a convincing need for having two state machines instead
      of one.  It seems that you want the RA Guard to operate on a
      per-interface basis, and that it needs "Off", "Learning", and
      "Validating" modes.  Wouldn't one state machine per interface be
      sufficient?  Why do you need the RA-Guard-level state machine in
      addition.

      (Of course, having only the interface-level state machines
      wouldn't prevent an implementation from providing a user
      interface that lets the administrator toggle the mode
      simultaneously for all interfaces on the RA Guard device.  This
      would allow the administrator to switch all interfaces to
      Learning mode, e.g., with a single mouse click.)

(2)  And one editorial comment:  In section 3.2., "RA-Guard state:
      LEARNING", you say:

      "A device or interface in the RA-Guard "Learning" state is
      actively acquiring information about the devices connected to its
      interfaces. The learning process takes place over a pre-defined
      period of time by capturing router advertisments or it can be
      event triggered. The information gathered is compared against
      pre-defined criteria which qualify the validity of the RAs."

      Can you elaborate on what "pre-defined criteria" means in the
      last sentence?

Best regards,
- Christian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 May 2008 13:35:24 -0700

FYI, http://isatap.org has been updated to reflect recent
publications of RFC5214 and linux kernel source code. Links
to other related initiatives have also been added.

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 5 May 2008 18:04:44 +0200 (CEST)

Hi Christian,

Thanks for the comments.

>     Learning mode, e.g., with a single mouse click.)

I think also that interface level state machine is enough + a global 
configuration options. We will clarify the text on the state machine.
We will also discuss among the co-authors.

>     Can you elaborate on what "pre-defined criteria" means in the

This might be some information configured in the switch also - valid mac 
addresses of the routers (e.g. multiple mac address in case of HA setup), 
or valid prefixes or valid lifetime or prefered lifetime. I think it is 
purely optional. I think it should not contain similar configuration 
parameters as routers have since maintaining consistency is would be 
difficult.  We will clarify on this one also.

Best Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: Christian Vogt <[email-masked]>
Date: Mon, 5 May 2008 22:36:35 +0300

Janos,

thanks for addressing my comments.  Good to hear they were useful.

- Christian

On May 5, 2008, at 19:04, Mohacsi Janos wrote:

> This might be some information configured in the switch also - valid  
> mac addresses of the routers (e.g. multiple mac address in case of  
> HA setup), or valid prefixes or valid lifetime or prefered lifetime.  
> I think it is purely optional. I think it should not contain similar  
> configuration parameters as routers have since maintaining  
> consistency is would be difficult.  We will clarify on this one also.
>
>
>
> Best Regards,
>
> Janos Mohacsi