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

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

My only concern with this document is that, if the RA-Guards
become too aggressive, they can block legitimate RAs that
should get through and thereby mount an untraceable denial
of service attack. How can we be sure, for example, that the
potentially diverse RA guard implementations within the same
L2 infrastructure would implement the same policies and
mechanisms such that uniform behavior is observed?

It seems to me that the L2 devices are welcome to perform
whatever filtering they like regardless of any documents
that might come from the IETF. Therefore, I'd like to see
more pros/cons on this.

Thanks - Fred
fred.l.templin@boeing.com

>-----Original Message-----
>From: Thomas Narten [mailto:narten@us.ibm.com]
>Sent: Wednesday, November 26, 2008 12:24 PM
>To: Fred Baker
>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