Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
draft-ietf-v6ops-ra-guard-implementation-07

Note: This ballot was opened for revision 04 and is now closed.

(Ron Bonica) Yes

(Stewart Bryant) (was Discuss) No Objection

Comment (2012-11-14 for -05)
No email
send info
Clearing on the basis of the editor's note addressing  ":Appendix B.  "Advice and guidance to vendors" is inappropriate for an IETF stream document and needs to be removed prior to publication."

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2012-11-14)
No email
send info
Minor point. Take it or leave it.
In section 2

   Section 2.2 describes an attack method based
   on the use of IPv6 fragmentation, possibly in conjunction with the
   use of IPv6 Extension Headers.  This later vector has been found to
   be effective with all existing implementations of the RA-Guard
   mechanism.

Question: do you want to insert "stateless" in the last sentence?
RFC 6105 makes the distinction between stateless and statefull

(Ralph Droms) (was Discuss) No Objection

Comment (2012-11-14)
No email
send info
In my opinion, this document provides useful descriptions of attacks
on IPv6 RA-Guard and techniques for mitigating those attacks.

Revision -07, to be published as Informational without RFC 2119
language (except for text derived from other RFCs), is appropriately
written to provide guidance to implementors to mitigate the attacks
described in the document.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-11-12 for -05)
No email
send info
- section 3, rule 3, last para: how can you have a MUST for
implementations that "MUST NOT claim compliance with this
specification"? Seems illogical. I'd say s/MUST/ought/ if
you want to be consistent, but its pretty harmless as-is.

- Appendix B: this advertisement seems unwarranted.

- The secdir review [1] had some suggestions for rewording
some of the security considerations that are worth a look.

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03402.html

(Brian Haberman) (was Discuss) No Objection

Comment (2012-11-14)
No email
send info
1. I find it quite amusing that this specification is supposedly targeted at "layer-2 devices", but requires these devices to be fully layer-3 aware.

(Russ Housley) (was Discuss) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2012-11-10 for -05)
No email
send info
I have a few non-blocking comments, which you can chat with me about if you like.

-- General --
You use "discard" and "drop" packets, apparently interchangeably.  I suggest that you pick one and use it consistently.

Is there significance to the extra indentation of some paragraphs?  If so, can you explain this in the Introduction, perhaps with a sentence at the end, after the 2119 boilerplate.

-- Section 3 --
          An implementation that has such
          an implementation-specific limit MUST NOT claim compliance
          with this specification, and MUST pass the packet when such
          implementation-specific limit is reached.

I have a problem with that first MUST NOT, but it's a small thing.  I don't think 2119 key words are appropriate for compliance information.  I'd greatly prefer, "An implementation that has such an implementation-specific limit is not in compliance with this specification, and MUST pass the packet [...]."

-- Section 8.2 --
   [CPNI-IPv6]
              Gont, F., "Security Assessment of the Internet Protocol
              version 6 (IPv6)",  UK Centre for the Protection of
              National Infrastructure, (available on request).

I'm pretty sure the RFC Editor isn't going to like this.  Can you post this in the WG wiki?

(Pete Resnick) (was Discuss) No Objection

Comment (2012-11-14)
No email
send info
I will let others continue the discussion as they see fit, but I'm not going to hold this up. That said, making all of the "MUST"s into "must"s doesn't really change the fact that this thing looks like it is giving protocol instructions to routers. Remember, 2119 doesn't require that the words be uppercased; 2119 is simply saying that words like "must" are used when there are interoperability requirements for a protocol. So the "must not claim compliance" bit is still wrong and should be removed. But again, I'm not willing to hold up an Informational document over that.

(Robert Sparks) No Objection

Comment (2012-11-13 for -05)
No email
send info
I support the discuss positions already entered on this version of the document, particularly Ralph's and Stewart's.

(Martin Stiemerling) No Objection

Comment (2012-11-13 for -05)
No email
send info
Appendix B must be removed, as this is purely advertisement and it does not belong in any IETF draft/RFC.

(Sean Turner) (was Discuss) No Objection

Comment (2012-11-14)
No email
send info
I support Ralph's and Russ' discuss.