RE: WGLC for draft-ietf-v6ops-ra-guard-01.txt (was: Re: Rogue RA WGLC)

["Wes Beebee (wbeebee)" <wbeebee@cisco.com>]

I consider the main contribution of this draft to be the interaction
with SeND in order to find out whether an RA sent is legitimate or not,
and then automatically configuring the appropriate ACL.  The fact that
this ACL may go away upon reboot, and may have to be reauthorized is not
sufficient IMHO to block this document at WGLC.  I agree with you that
the intended status should be listed on the document.  The only other
addition I would make to the document (if it can be done at WGLC) would
be to elucidate the protocol-level details of the interaction between RA
Guard and SeND.

Pending such additions, I fully support this document at WGLC.

- Wes 

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Thomas Narten
Sent: Wednesday, November 26, 2008 3:24 PM
To: Fred Baker (fred)
Cc: v6ops@ops.ietf.org; kurtis@kurtis.pp.se; rbonica@juniper.net
Subject: WGLC for draft-ietf-v6ops-ra-guard-01.txt (was: Re: Rogue RA
WGLC)

Fred Baker <fred@cisco.com> writes:

> This is to initiate a two week working group last call of draft-chown-

> v6ops-rogue-ra-02.txt and draft-ietf-v6ops-ra-guard-01.txt.

What is the intended status of the ra-guard document? Informational?
(I would assume it is not going on standards track, since the proposed
behavior only loosely specified.)

At this point, I lean against publishing this document at all (in
fairness, I also opposed taking it on as WG document at all.)

My overall issue with it is that it offers little utility (IMO) beyond
that provided by simple L2 filtering. E.g., just dropping all RAs from
ports other than those that are authorized to send RAs. I would assume
existing switches support this sort of thing, and I can't think of an
example right off where an IETF document was published to encourage such
behavior. I.e., vendors are generally smart enough to provide such
facilities already, and don't need an IETF document to do so. If, the
IETF were to publish a document, I think it would be more useful for it
to clearly describe what sorts of port blocking filters should be
provided (and why), so vendors would understand the benefits of doing
so. But again, IMO, just simple filtering is sufficient, and having an
RA Guard entity that looks at RAs, compares them against detailed
configuration information for validity (which, btw, is yet more one
place where misconfiguration can mess things up), doesn't have
sufficient benefits to recommend.

On details of the "stateful learning", the LEARNING state seems to me to
be rather simplistic and would be ineffective after, say, a power
failure. Given it's overall lack of robustness, I have doubts it is
worth recommending this.

Thomas