Rogue IPv6 Router Advertisement Problem Statement
RFC 6104

[Ballot discuss]
The security considerations section states:

7.  Security Considerations

  This document is Informational.  It does not describe solutions for
  malicious attacks on a network for which malicious RAs may be part of
  a broader attack, e.g. including malicious NA messages.

While it may be reasonable to place malicious RAs out of scope for the corresponding protocol
work, I do not believe we should exclude it from the security considerations!  I understand
that the wg decided not to attempt to resolve this problem, but a description of the malicious
RA problem, and the extent that it overlaps with the administrator and user configuration
issues that are addressed would be helpful.

This seems reasonable, since a robust defense against administrator and user configuration
issues should mitigate some rogue RAs generated via malicious configuration.  Understanding
which malicious rogue RAs are not addressed might be helpful in deciding whether to deploy
this technology.

[Ballot comment]
I support the duscuss by Tim (as does Ari's review below).

Review by Ari Keränen:

1. Introduction

  In
  addition a network experiencing malicious attack of this kind is
  likely to also experience malicious NA and related messages also.

Expand "NA".


2.3. Malicious misconfiguration

  In writing this text we came to the conclusion that the
  issue of malicious attack, due to the other complementary attacks
  that are likely to be launched using rogue NA and similar messages,
  are best considered elsewhere.

If there is such a document, reference could be useful.


3.2. Introduce RA snooping

  This type of solution
  has appeal because it is a familiar model for enterprise network
  managers, but it can also be used to complement SeND, by a switch
  acting as a SeND proxy for hosts.

Expand "SeND" and add reference to the RFC or Section 3.4.


4. Scenarios and mitigations

  In this section we summarise the scenarios and practical mitigations
  described above in a matrix format.  We consider, for the case of a
  rogue multicast RA, which of the mitigation methods helps protect
  against each cause.

I would suggest using "against administrator and user errors" instead of "against each cause", since you have only two causes (it took a couple of cycles to figure out what "each cause" meant here).


5.1. Unicast RAs

  The above discussion was initially held on the assumption that rogue
  multicast RAs were the cause of problems on a shared network subnet.
  However, the specifications for Router Advertisements allow them to
  be sent unicast to a host, as per Section 6.2.6 of RFC4861.  If a
  host sending rogues RAs sends them unicast to the soliciting host,
  that RA may not be seen by other hosts on the shared medium, e.g. by
  a monitoring daemon.  In most cases though, an accidental rogue RA is
  likely to be multicast.

Wouldn't it then make sense to recommend for such daemons to capture RAs in a promiscuous mode?


5.5. Recovering from bad configuration state

  A host that is aware of
  protocols such as shim6 may believe it is genuinely multihomed.

Missing shim6 reference.


7. Security Considerations

  This document is Informational.  It does not describe solutions for
  malicious attacks on a network for which malicious RAs may be part of
  a broader attack, e.g. including malicious NA messages.

The security effects of non-malicious RAs could be discussed.

[Ballot comment]
Review by Ari Keränen:

1. Introduction

  In
  addition a network experiencing malicious attack of this kind is
  likely to also experience malicious NA and related messages also.

Expand "NA".


2.3. Malicious misconfiguration

  In writing this text we came to the conclusion that the
  issue of malicious attack, due to the other complementary attacks
  that are likely to be launched using rogue NA and similar messages,
  are best considered elsewhere.

If there is such a document, reference could be useful.


3.2. Introduce RA snooping

  This type of solution
  has appeal because it is a familiar model for enterprise network
  managers, but it can also be used to complement SeND, by a switch
  acting as a SeND proxy for hosts.

Expand "SeND" and add reference to the RFC or Section 3.4.


4. Scenarios and mitigations

  In this section we summarise the scenarios and practical mitigations
  described above in a matrix format.  We consider, for the case of a
  rogue multicast RA, which of the mitigation methods helps protect
  against each cause.

I would suggest using "against administrator and user errors" instead of "against each cause", since you have only two causes (it took a couple of cycles to figure out what "each cause" meant here).


5.1. Unicast RAs

  The above discussion was initially held on the assumption that rogue
  multicast RAs were the cause of problems on a shared network subnet.
  However, the specifications for Router Advertisements allow them to
  be sent unicast to a host, as per Section 6.2.6 of RFC4861.  If a
  host sending rogues RAs sends them unicast to the soliciting host,
  that RA may not be seen by other hosts on the shared medium, e.g. by
  a monitoring daemon.  In most cases though, an accidental rogue RA is
  likely to be multicast.

Wouldn't it then make sense to recommend for such daemons to capture RAs in a promiscuous mode?


5.5. Recovering from bad configuration state

  A host that is aware of
  protocols such as shim6 may believe it is genuinely multihomed.

Missing shim6 reference.


7. Security Considerations

  This document is Informational.  It does not describe solutions for
  malicious attacks on a network for which malicious RAs may be part of
  a broader attack, e.g. including malicious NA messages.

The security effects of non-malicious RAs could be discussed.

[Ballot discuss]
This is a discuss-discuss, as it conflicts in part with wg consensus.  The security considerations
section states:

7.  Security Considerations

  This document is Informational.  It does not describe solutions for
  malicious attacks on a network for which malicious RAs may be part of
  a broader attack, e.g. including malicious NA messages.

While it may be reasonable to place malicious RAs out of scope for the corresponding protocol
work, I do not believe we should exclude it from the security considerations!  I understand
that the wg decided not to attempt to resolve this problem, but a description of the malicious
RA problem, and the extent that it overlaps with the administrator and user configuration
issues that are addressed would be helpful.

This seems reasonable, since a robust defense against administrator and user configuration
issues should mitigate some rogue RAs generated via malicious configuration.  Understanding
which malicious rogue RAs are not addressed might be helpful in deciding whether to deploy
this technology.

[Ballot comment]
It's not clear what he following means:

"But for accidental problems like Windows ICS and 6to4, it could be useful."

In particular references are needed.

===========
In Section 5.1

If a host sending rogues RAs
                      ^
Spurious "s"

===========

"In the case of Windows ICS"

Needs a reference (and an expansion of "ICS"

===========

Section 8

"Where managed switches are no available"

S/no/not/

Then next line I think s/moreso/more so/

[Ballot comment]
I found this document to be quite clear and informative. I have a few comments that could improve readability:

1. Many acronyms lack expansion at first occurance. For example because NA is not expanded the last paragraph in section 1 is hard to understand. Also lacking - VLAN, DHCPO, SeND, ICS.

2. It would be good to provide references to the tools descreibed in Section 3.8

3. Section 3.10 - not clear what exactly is meant by 'different layer 2 medium' - if this means 'physically separate layer 2 network' than the later terminology is better.

> (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 for publication.

> (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?

It has had review and discussion. I think it is adequate to the problem set.

> (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?

It is a problem statement; the solution probably calls for that, but not the problem statement.

> (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 know of no issues in this area.

> (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 tends to be a quiet bunch. We had a number of small conversations on the topic, more in person than on the list. The discussions in IETF meetings have generally supported the document.

> (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 language. The idnits check fails, saying that "The document has a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. Does it really need the disclaimer?". However, it derives from draft-chown-v6ops-rogue-ra-00.txt, and the authors made a disclaimer regarding text in that document.

> (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 made are all informative. One could argue that the "informative" references to standards, including RFCs 2684, 3056, 3315, 3736, 3971, 4191, 4861, and 4862, should be normative, but I have not pushed that point.

> (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?

Section 8 states that "There are no extra IANA consideration for this document."

> (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 the 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

When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the Router Advertisement (RA) message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this draft we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed.

> Working Group Summary

Working group commentary was quiet but supportive.

> Document Quality

The commentary on the document has stated that it is clear and to the point.