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

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Dec 2008 12:55:12 -0800

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
[email-masked]

>-----Original Message-----
>From: Thomas Narten [mailto:[email-masked]]
>Sent: Wednesday, November 26, 2008 12:24 PM
>To: Fred Baker
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: WGLC for draft-ietf-v6ops-ra-guard-01.txt (was: Re: Rogue RA
WGLC)
>
>Fred Baker <[email-masked]> 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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 11 Dec 2008 13:42:51 -0800

At Tue, 18 Nov 2008 13:22:02 -0600,
Fred Baker <[email-masked]> wrote:

> 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. Please  
> read these drafts now. If you find nits (spelling errors, minor  
> suggested wording changes, etc), comment to the authors; if you find  
> greater issues, such as disagreeing with a statement or finding  
> additional issues that need to be addressed, please post your comments  
> to the list.

I've read draft-chown-v6ops-rogue-ra-02.txt.  While I think this can
be a useful document, I have a concern about its scope.

This document looks to me too generalized by attempting all kinds of
"rogue" behavior, and could lead to a misleading conclusion.
Specifically, it seems to me that by discussing 'malicious
misconfiguration' this document makes the whole discussion complicated
and distracting.

I thought the original motivation of this document was 'user
misconfiguration' that we've seen various places in actual deployment
of IPv6.  I agree discussion in this scope makes sense and is useful.

But, have we really experienced 'malicious misconfiguration' of RA and
recognized it as a problem to be solved as a pragmatic sense?  Of
course, this could be a real problem as discussed in RFC3756, and I
don't deny the value of discussing it per se.  But since this is
essentially a security issue (while limited within a single link),
discussion on the solution will be much more complicated.  For
example, it's not sufficient in this sense to just avoid a rogue
default router by some measure, because if it's a malicious attempt we
should also worry about other attacks such as stealing the L2 address
of a valid router using rogue NAs.

I understand this document notes limitations of possible solutions,
and I'm not arguing every document that discusses a rogue behavior
must provide a complete solution.  But, in this specific case, it
overly dismisses solutions for non-malicious behavior (for which
we'd really want a workable solution) by introducing the consideration
on malicious (security) viewpoints.  As an example, it states in
Section 3.5 ("Use the Router Preference Option") as follows:

   This of course would only work in some scenarios - an attacker would
   certainly seek to use High priority anyway - and would also rely on
   clients having implementations of the protocol.

If our focus were limited to erroneous (i.e. not 'malicious') rogue
behavior, the discussion could be simpler and would in fact help many
people realistically.  But by mentioning "attacks", this document
makes solutions sound much less promising.

(again) to be clear, I'm not saying we should ignore security
implications.  But IMO the current content of this document tries to
be too generic (by including security topics) and makes useless
conclusions, while there can be realistic and useful solutions with
limitations wrt security that can be acceptable for certain users.

So, if it's okay to make this level of comment, I'd like to propose
either
a) remove the 'malicious misconfiguration' considerations (but
   explicitly note they are out of scope somewhere, possibly in the
   security consideration section), or
b) discuss cases limited to non-malicious misconfigurations
   separately.

I have a few other minor comments that follow:

- Section 3.11
  "Catch-22" sounds like a jargon to me.  Can't this be a more
  conservative word such as "dilemma"?

- Table in Section 4
  I don't understand the "If Auth" entry for the "Admin Error"x"DHCPv6
  gateway option" cell.  What does "auth" mean here, and what kind of
  "admin error" does it avoid?  Doesn't authentication help when a
  valid administrator misconfigures the DHCPv6 server with valid
  DHCPv6 authentication?

- Section 5.5
  
   e.g. considering the '2 hour rule' of
   Section 5.5.3 of RFC4862 (though this applies to the prefix lifetime
   not the router lifetime).

  This is not 100% correct.  The 2hour rule applies to the valid
  lifetime of addresses.  Using the term "prefix lifetime" could be
  misleading because it may be interpreted as the lifetime of on-link
  prefixes.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 11 Dec 2008 17:03:29 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of JINMEI Tatuya / ????
Sent: Thursday, December 11, 2008 4:43 PM
To: Fred Baker (fred)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Rogue RA WGLC

 > misleading because it may be interpreted as the lifetime of on-link

I agree with Jinmei. The document should be careful with terminology
here. Snipped from section 6.3.4 of RFC 4861 is the clear text snipped
below that says on-link prefix lifetime as specified in RFC4862 (like
the 2 hour time extension etc.) is not valid in the ND protocol for
on-link prefix lifetimes.

[Stateless address autoconfiguration [ADDRCONF] may in some
   circumstances use a larger Valid Lifetime of a prefix or ignore it
   completely in order to prevent a particular denial-of-service attack.
   However, since the effect of the same denial of service targeted at
   the on-link prefix list is not catastrophic (hosts would send packets
   to a default router and receive a redirect rather than sending
   packets directly to a neighbor), the Neighbor Discovery protocol does
   not impose such a check on the prefix lifetime values.]

Hemant