IPv6 Router Advertisement Guard
draft-ietf-v6ops-ra-guard-08

[Ballot comment]
I've cleared my DISCUSS based on the changes to section 4.1. I
think a couple of sentences in the definition of the LEARNING state
might benefit from clarification:

        A device or interface in the RA-Guard "Learning" state is
        actively acquiring information about the IPv6 routing devices
        connected.

Append "to its interfaces"?

        The learning process takes place over a pre-defined
        unique period in time, set by manual configuration or it can be
        event triggered.

It's not clear to me whether the event triggering causes the device
to enter or leave the LEARNING state.  That is, does the device
always stay in LEARNING state for a fixed period of time, or can
it stay in LEARNING state either for a fixed period of time or until
some event takes place?

        Once the L2-device has identified through "Learning" the valid
        IPv6 routers and hence also identified the valid RAs, [...]

Would this paragraph be clearer as:

When the L2-device reaches the end of the LEARNING state, it
        has a record of which interfaces are attached to links with
        valid IPv6 routers.  The L2-device transtions each interface
        from "LEARNING" into either BLOCKING state if there was no
        valid IPv6 router discovered at the interface, or transitions
        the interface into FORWARDING state if there was a valid IPv6
        router discovered.

Finally, although the state machine is described earlier in section
4.1 as "global, per-interface, or per-peer", this paragraph implies
that the BLOCKING/FORWARDING state is per-interface.

[Ballot comment]
I've cleared my DISCUSS based on the changes to section 4.1. I think a couple of sentences in the definition of the LEARNING state might benefit from clarification:

        A device or interface in the RA-Guard "Learning" state is
        actively acquiring information about the IPv6 routing devices
        connected.

Append "to its interfaces"?

        The learning process takes place over a pre-defined
        unique period in time, set by manual configuration or it can be
        event triggered.

It's not clear to me whether the event triggering causes the device
to enter or leave the LEARNING state.  That is, does the device
always stay in LEARNING state for a fixed period of time, or can
it stay in LEARNING state either for a fixed period of time or until
some event takes place?

        Once the L2-device has identified through "Learning" the valid
        IPv6 routers and hence also identified the valid RAs, [...]

Would this paragraph be clearer as:

When the L2-device reaches the end of the LEARNING state, it
        has a record of which interfaces are attached to links with
        valid IPv6 routers.  The L2-device transtions each interface
        from "LEARNING" into either BLOCKING state if there was no
        valid IPv6 router discovered at the interface, or transitions
        the interface into FORWARDING state if there was a valid IPv6
        router discovered.

Finally, although the state machine is described earlier in section
4.1 as "global, per-interface, or per-peer", this paragraph implies
that the BLOCKING/FORWARDING state is per-interface.

[Ballot comment]
I noticed one nit in the new Security Considerations text (Sction 7, first sentence of the second paragraph).  Here is
one possible fix:

OLD
          in Section 4.1 a simple mechanism to learn dynamical the valid IPv6
  routers connected to a L2-device is explained.
NEW
          In Section 4.1 a simple mechanism to dynamically learn the valid IPv6
  routers connected to a L2-device is explained.

[Ballot comment]
Review by Ari Keränen:

The "RA" abbreviation in the title should be expanded.

According to ID checklist, there should not be citations in the abstract:
http://www.ietf.org/id-info/checklist.html#anchor6

Overall, I find the abstract somewhat long and hard to read. Having less details and making editorial fixes would be a good idea (e.g., the phrase "End-nodes must be provisioned with certificate anchors." in the middle sounds strange, and probably is not even that relevant). Perhaps the whole first paragraph of the abstract could be removed.


2. Model and Applicability

Figure 1 does not have a caption. Also, the meaning of the diagonal lines and the horizontal line connecting the two diagonal lines was not clear.

SEND is not spelled consistently (sometimes it's "SeND").

  If this node-in-the-middle is a L2 device, it will
  not change the content of the validated RA, and avoid any of the nd-
  proxy pitfalls.

Capitalize "nd" in the "nd-proxy".


4.1. State Machine

It's hard to see when and why would one move to the BLOCKING state in the state machine. Overall, it would be helpful to have some explanation on the transitions instead of just saying that they are "triggered by manual configuration or by meeting a pre-defined criteria".


4.2. SeND-based RA-Guard

Expand abbreviations and add references where needed (e.g., CGA, RSA, CPS, CRL, NTP).

  Bootstrapping issue in this
  case can be resolved by using the configuration method to specify a
  trusted port to a first router, and send-based-ra-guard method on all
  other ports.

"send-based-ra-guard" should be spelled as in the title?


7. Security Considerations

  Once RA-Guard has setup the proper criteria, for example, it
  identified that a port is allowed to receive RAs, or it identified
  legitimate sources of RA, or certificate base, then there is no
  possible instances of accidentlly filtered legitimate RA's assuming
  the RA-Guard filter enforcement follows strictly the RA-Guard
  criteria's.

Typos: accidentlly, RA's, criteria's

Why isn't spoofing of source address and port discussed? After all, in sections 2 and 3 it is mentioned that L2 and L3 addresses can be used for filtering.

Also, it seems that it would be fairly easy to attack against the stateful RA-Guard described in the Section 4.1 by sending valid RAs during the learning period and then switch to rogue RAs.

[Ballot discuss]
I like the stateless solution, and it should really come as standard on every switch and router.

I think the stateful 4.2 solution is reasonable, but I have doubts about
the 4.1 solution. A simplistic implementation of the Section 4.1 solution
could block a legitimate router that boots later than the switch, for
instance. The document says very little about how to run this solution
in a way that ensures no problems will occur.

Do we really need a medium level, somewhat complex and possibly error
prone solution in addition to the low level simple thing and the fully
fledged (4.2 + SEND) solutions?

[Ballot comment]
Review by Ari Keränen:

The "RA" abbreviation in the title should be expanded.

According to ID checklist, there should not be citations in the abstract:
http://www.ietf.org/id-info/checklist.html#anchor6

Overall, I find the abstract somewhat long and hard to read. Having less details and making editorial fixes would be a good idea (e.g., the phrase "End-nodes must be provisioned with certificate anchors." in the middle sounds strange, and probably is not even that relevant). Perhaps the whole first paragraph of the abstract could be removed.


2. Model and Applicability

Figure 1 does not have a caption. Also, the meaning of the diagonal lines and the horizontal line connecting the two diagonal lines was not clear.

SEND is not spelled consistently (sometimes it's "SeND").

  If this node-in-the-middle is a L2 device, it will
  not change the content of the validated RA, and avoid any of the nd-
  proxy pitfalls.

Capitalize "nd" in the "nd-proxy".


4.1. State Machine

It's hard to see when and why would one move to the BLOCKING state in the state machine. Overall, it would be helpful to have some explanation on the transitions instead of just saying that they are "triggered by manual configuration or by meeting a pre-defined criteria".


4.2. SeND-based RA-Guard

Expand abbreviations and add references where needed (e.g., CGA, RSA, CPS, CRL, NTP).

  Bootstrapping issue in this
  case can be resolved by using the configuration method to specify a
  trusted port to a first router, and send-based-ra-guard method on all
  other ports.

"send-based-ra-guard" should be spelled as in the title?


7. Security Considerations

  Once RA-Guard has setup the proper criteria, for example, it
  identified that a port is allowed to receive RAs, or it identified
  legitimate sources of RA, or certificate base, then there is no
  possible instances of accidentlly filtered legitimate RA's assuming
  the RA-Guard filter enforcement follows strictly the RA-Guard
  criteria's.

Typos: accidentlly, RA's, criteria's

Why isn't spoofing of source address and port discussed? After all, in sections 2 and 3 it is mentioned that L2 and L3 addresses can be used for filtering.

Also, it seems that it would be fairly easy to attack against the stateful RA-Guard described in the Section 4.1 by sending valid RAs during the learning period and then switch to rogue RAs.

[Ballot discuss]
Have I misunderstood something? This looks like a layer violation. If I understand correctly, a layer 2 device is asked to examine the content of the data it is forwarding in order to provide a filter to remove unwanted RAs. Why is this conseidered acceptable?

[Ballot comment]
Style comment - move citation for SeND reference from Abstract to Introduction; give expansion of SeND abbreviation on first reference in both Abstract and body of document. As an aside, I see that "SeND" is actually abbreviated "SEND" in the title of RFC 3971 (according to the reference).

Figure 1 isn't actually labeled "Figure 1"; I don't understand the angled lines between the links connecting the hosts and router to the L2 device.

Just to make sure I have the correct understanding, "stateless" RA-guard could also be described as "statically-configured", in which the rules for accepting or dropping RAs are pre-defined.  If I have that right, and it wasn't quite clear to me when I read the description, it might help the reader to add an example of the static rules used in stateless RA-guard.

[Ballot discuss]
Following up and supporting Tim's DISCUSS, I found the text in section 4.1 insufficient to understand how the state machine RA-Guard works.  Does this text:

        The information gathered is compared
        against pre-defined criteria which qualify the validity of the
        RAs.

imply deeper analysis than the rules in stateless RA-Guard?

[Ballot comment]
Style comment - move citation for SeND reference from Abstract to Introduction; give expansion of SeND abbreviation on first reference in both Abstract and body of document. As an aside, I see that "SeND" is actually abbreviated "SEND" in the title of RFC 3971 (according to the reference).

Figure 1 isn't actually labeled "Figure 1"; I don't understand the angled lines between the links connecting the hosts and router to the L2 device.

Just to make sure I have the correct understanding, "stateless" RA-guard could also be described as "statically-configured", in which the rules for accepting or dropping RAs are pre-defined.  If I have that right, and it wasn't quite clear to me when I read the description, it might help the reader to add an example of the static rules used in stateless RA-guard.

[Ballot discuss]
(1) Has the SAVI wg looked at the SEND-based solution?  It seems reasonably straightforward,
but does overlap.

(2) This may be clear to a reader with expertise in the field, but I found the state machine in
section 4.1 rather confusing.

(a) Transitions between States 2, 3, and 4 are not clear. what are the conditions where
RA Guard should transition from 2 to state 3 or 4?  What about transitions out of state 3 or 4?

(b) Further, State 2 (LEARNING) ends with the following text:

        In this state, the RA-Guard enabled device or interface is
        either blocking all RAs until their validity is verified or,
        alternatively it can temporarily forward the RAs until the
        decision is being made.

Given that State 2 can block or forward RAS, how does LEARNING differ from the
BLOCKING and FORWARDING states?

[Ballot comment]
Just some minor issues with definition of abbreviations:

"When operating IPv6 in a shared L2 network segment without complete
SeND support by all devices"

Need a REF to SeND - it is in the Abstract but not in the main body of the doc.

=======

"RA-Guard can be seen as a superset of SEND"
s/SEND/SeND/  ?

=======

In section 4.2

CGA, CPS, CPANTP and CRL all used without expansion or definition

=======

[Ballot discuss]
I have a fundamental qestion concerning the solution proposed by this document. If the RA-Guard mechanism is effective only when all messages between IPv6 devices in the target environment traverse controlled L2 networking devices, would not a L2 solution built upon port-access control IEEE 802.1X and MAC Security IEEE 802.1AE be sufficient and the default choice for a network operator?

> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

Fred Baker. Yes, I believe that it is ready to move forward.

> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?

Yes. Working group discussion has not been active, but has supported the document.

> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization or XML?

I think it would be appropriate to get security and operational review.

> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he
> or she is uncomfortable with certain parts of the document, or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has indicated
> that it still wishes to advance the document, detail those
> concerns here. Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.

I think the solution is simple and solid.

> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

IPv6 Operations is a quiet bunch. The discussion, mostly in IETF meetings, has been to the point and supportive.

> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

No

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See the
> Internet-Drafts Checklist
>
> and
> http://tools.ietf.org/tools/idnits/
> ). Boilerplate checks are
> not enough; this check needs to be thorough. Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?

The document contains no formal grammar. The idnits check reports one unused reference, to RFC 4861 "Neighbor Discovery for IP version 6". One could describe the entire document as a reference to that specification...

> (1.h) Has the document split its references into normative and
> informative? Are there normative references to documents that
> are not ready for advancement or are otherwise in an unclear
> state? If such normative references exist, what is the
> strategy for their completion? Are there normative references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].

The references are so divided.

> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC5226]. If the
> document describes an Expert Review process has Shepherd
> conferred with the Responsible Area Director so that the IESG
> can appoint the needed Expert during the IESG Evaluation?

There are no extra IANA consideration for this document, and section 6 says as much.

> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?

There is no formal grammar in this document.

> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up? Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:
>
> Technical Summary

It is particularly easy to experience "rogue" routers on an unsecured link [reference4]. Devices acting as a rougue router may send illegitimate RAs. Section 6 of SeND [RFC3971] provides a full solution to this problem, by enabling routers certification. This solution does, however, require all nodes on an L2 network segment to support SeND, as well as it carries some deployment challenges. End- nodes must be provisioned with certificate anchors. The solution works better when end-nodes have access to a Certificate Revocation List server, and to a Network Time Protocol server, both typically off-link, which brings some bootstrap issues.

When using IPv6 within a single L2 network segment it is possible and sometimes desirable to enable layer 2 devices to drop rogue RAs before they reach end-nodes. In order to distinguish valid from rogue RAs, the L2 devices can use a spectrum of criterias, from a static scheme that blocks RAs received on un-trusted ports, or from un-trusted sources, to a more dynamic scheme that uses SeND to challenge RA sources.

This document reviews various techniques applicable on the L2 devices to reduce the threat of rogue RAs.

> Working Group Summary

Working group discussion was generally supportive.

> Document Quality

The document is generally clear and concise.