Skip to main content

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

Yes

(Ron Bonica)

No Objection

(Adrian Farrel)
(Gonzalo Camarillo)
(Russ Housley)
(Wesley Eddy)

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

Ron Bonica Former IESG member
Yes
Yes (for -04) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection () Unknown

                            
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2012-11-10 for -05) Unknown
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?
Benoît Claise Former IESG member
No Objection
No Objection (2012-11-14) Unknown
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
Brian Haberman Former IESG member
(was Discuss) No Objection
No Objection (2012-11-14) Unknown
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.
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (2012-11-13 for -05) Unknown
Appendix B must be removed, as this is purely advertisement and it does not belong in any IETF draft/RFC.
Pete Resnick Former IESG member
(was Discuss) No Objection
No Objection (2012-11-14) Unknown
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.
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2012-11-14) Unknown
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.
Robert Sparks Former IESG member
No Objection
No Objection (2012-11-13 for -05) Unknown
I support the discuss positions already entered on this version of the document, particularly Ralph's and Stewart's.
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2012-11-14) Unknown
I support Ralph's and Russ' discuss.
Stephen Farrell Former IESG member
No Objection
No Objection (2012-11-12 for -05) Unknown
- 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
Stewart Bryant Former IESG member
(was Discuss) No Objection
No Objection (2012-11-14 for -05) Unknown
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."
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown