OSPFv3 Autoconfiguration
draft-ietf-ospf-ospfv3-autoconfig-15

[Ballot discuss]
I've trimmed by Discuss to remove the pieces you have handled. Many
thanks for that.

====

> Does this document really update 5340?
> There is no mention of what this update is or why it is considered a
> part of the standard implementation of OSPFv3 to include the features
> described in this document.
>
> I suggest either dropping the update or clarifying how it works.
>
> (Note that idnits should have flagged this to you, but the shepherd
> write-up says that this document doesn't change the status of any
> existing RFCs.)

We discussed this a little, and I got the impression that the conclusion was that "update" really was intended.

In this case you need to (as also discussed):
- make this clear in the Abstract (as indicated by idnits)
- spend some time in the document (probably the Introduction) explaining how the update works (which is, I believe you are saying, that all new implementations of OSPFv3 are expected to include support for this feature).

I do see that you have added to the Introduction:

  This document describes
  extensions to OSPFv3 to enable it to operate in these environments.

But that is ambiguous. Are the "MUST"s in this document mandatory behaviour for an implementation of OSPFv3 or for an implementation of this document which is an option for OSPFv3 implementations? I don't think this is hard to write down, but I don't know what you are trying to achieve.

Notification list changed to ospf@ietf.org, ospf-chairs@ietf.org, draft-ietf-ospf-ospfv3-autoconfig.all@tools.ietf.org, "Ing-Wher Chen" <ing-wher.chen@ericsson.com> from ospf@ietf.org, ospf-chairs@ietf.org, draft-ietf-ospf-ospfv3-autoconfig.all@ietf.org, "Ing-Wher Chen" <ing-wher.chen@ericsson.com>

[Ballot discuss]
  4.  OSPFv3 interfaces MAY use an arbitrary HelloInterval and
      RouterDeadInterval as specified in Section 3. 

Hopefully, an easy DISCUSS.
From a management point of view, we must be able to determine if a router or interfaces within a router are OSPF-autoconfigured.
If I'm not mistaken, you miss, in the management considerations section, something like this: The OSPFv3 routers MUST flag the interfaces supporting this specification.

Background: I recall one particular tool in the past that would check the different router configs and flag the HelloInterval and RouterDeadInterval
mismatched values for adjacent routers. This would be equivalent to the following debug:
OSPF: Rcv hello from 192.168.0.2 area 0 from FastEthernet0/0 192.168.0.2
OSPF: Mismatched hello parameters from 192.168.0.2
OSPF: Dead R 40 C 60, Hello R 10 C 15  Mask R 255.255.255.252 C 255.255.255.252

In case of OSPF auto-config, this check doesn't make any sense.

[Ballot comment]
= Section 1 =
"OSPFv3 [OSPFV3] is a candidate for deployments in environments where
  auto-configuration is a requirement.  Its operation is largely
  unchanged from the base OSPFv3 protocol specification [OSPFV3]."

The use of "its" here doesn't make a lot of sense -- a plain reading of this is that OSPFv3 is unchanged from OSPFv3.

[Ballot comment]


Thanks for including section 4 - I was wondering if you
would before I read this:-)

- section 4: just saying "password" is likely to lead to
password == password or password == 123456. Why not advise
that a long higher entropy secret needs to be used?

- section 4: I hate to do this to you, but if by saying
"password" you also mean "entered by a human and likely a
human memorable secret" then aren't there i18n
considerations? Non-ascii characters in there are otherwise
likely to lead to a lack of interop. If you wanted my advice
as to how to avoid that, I'd go for RECOMMENDING that the
secret be entered as ascii-hex digits and that 32 such
digits be used if possible.

- section 8: What "stronger" auth trailer do you mean in the
last para? The weakness is that a password is used - the
rest (e.g. hmac-sha-256 vs. hmac-sha-1) is in the noise.
Maybe re-phrase.

[Ballot discuss]
I almost didn't place a Discuss on this document, but as my list of
larger comments grew to four, I decided that together they merit some
discussion and resolution.

====

Does this document really update 5340?
There is no mention of what this update is or why it is considered a
part of the standard implementation of OSPFv3 to include the features
described in this document.

I suggest either dropping the update or clarifying how it works.

(Note that idnits should have flagged this to you, but the shepherd write-up
says that this document doesn't change the status of any existing RFCs.)

---
                                                                               
I think that the effect of sections 4 and 8 is that auto-config as
specified in this document is not suitable for deployment in service
provider networks. Did I miss something, or are you saying that the
best you offer is a single, network-wide password to cover all
adjacencies?

If this is fine for the home network environment, you should be able to
point at a homenet document that says so.

If you agree that this is not fine for a service provider (and probably
for most enterprises) you need to call this out more strongly and
recommend limits on the applicability of this spec.

---

Isn't the duplicate Router ID detection an attack vector?
If I can inject an LSA purporting to be from the same Router ID but with
a numerically larger router hardware fingerprint, I can cause some other
router in the network to reset all of its adjacencies.
In theory I can do this over and over, and I can do it automatically on
receipt of an OSPFv3 Router Auto-Configuration LSA.

I think you should at least call that out as a specific risk. Ideally,
you would find a way to mitigate it.

---

Section 7.4. is titled:
Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSAs'

Are you really changing 2328? Or are you trying to say that an
implementation of this spec will do something different from 2328?

[Ballot discuss]
I almost didn't place a Discuss on this document, but as my list of
larger comments grew to four, I decided that together they merit some
discussion and resolution.

====

Does this document really update 5340?
There is no mention of what this update is or why it is considered a
part of the standard implementation of OSPFv3 to include the features
described in this document.

I suggest either dropping the update or clarifying how it works.

---
                                                                               
I think that the effect of sections 4 and 8 is that auto-config as
specified in this document is not suitable for deployment in service
provider networks. Did I miss something, or are you saying that the
best you offer is a single, network-wide password to cover all
adjacencies?

If this is fine for the home network environment, you should be able to
point at a homenet document that says so.

If you agree that this is not fine for a service provider (and probably
for most enterprises) you need to call this out more strongly and
recommend limits on the applicability of this spec.

---

Isn't the duplicate Router ID detection an attack vector?
If I can inject an LSA purporting to be from the same Router ID but with
a numerically larger router hardware fingerprint, I can cause some other
router in the network to reset all of its adjacencies.
In theory I can do this over and over, and I can do it automatically on
receipt of an OSPFv3 Router Auto-Configuration LSA.

I think you should at least call that out as a specific risk. Ideally,
you would find a way to mitigate it.

---

Section 7.4. is titled:
Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSAs'

Are you really changing 2328? Or are you trying to say that an
implementation of this spec will do something different from 2328?

[Ballot comment]
The remaining points are normal review Comments that you can take or
leave as you wish:

---

Section 1 has
  OSPFv3 [OSPFV3] is a candidate for deployments in environments where
  auto-configuration is a requirement.  Its operation is largely
  unchanged from the base OSPFv3 protocol specification [OSPFV3].
If you parse this down, it says "OSPFv3 is largely unchanged from
OSPFv3" which may not be as helpful as you intended it to be!
Perhaps...
  OSPFv3 [OSPFV3] is a candidate for deployments in environments where
  auto-configuration is a requirement.  This document describes
  extensions to OSPFv3 to enable it to operate in these environments.
  In this mode of operation, the protocol is largely unchanged from the
  base OSPFv3 protocol specification [OSPFV3].

---

Section 1

  The following aspects of OSPFv3 auto-configuration are described:

s/described:/described in this document:/

---

Section 1.2
Is there a reason to diverge fromt he RFC Editor's Style Guide in
placing the Acknowledgements at the top of the document?

---

Section 2 has

  2.  OSPFv3 SHOULD be auto-configured for IPv6 on all interfaces
      intended as general IPv6-capable routers.  Optionally, an
      interface MAY be excluded if it is clear that running OSPFv3 on
      the interface is not required.  For example, if manual
      configuration or another condition indicates that an interface is
      connected to an Internet Service Provider (ISP) and there is no
      Border Gateway Protocol (BGP) [BGP] peering, there is typically
      no need to employ OSPFv3.

The first sentence is garbled since it says that an interface could be
intended as a router. Do you mean...

  OSPFv3 SHOULD be auto-configured on all IPv6-capable interfaces of a
  router.

"Optionally an interface MAY" is tautology. Suggest "An interface MAY".

I am wondering why the fact that you have a BGP peering on an interface
configured to connect to an ISP would mean that you would want to run
OSPFv3 on that interface. You are possibly saying that the interface, in
that case, may need to be auto-configured and present in the OSPFv3
advertisements. But this is not what you have said.

---

Section 2

Can you point me to the spec for "vanilla Wi-Fi"? :-)

---

Section 2 bullet 4

      Of course, an
      identical HelloInterval and RouterDeadInterval will still be
      required to form an adjacency with an OSPFv3 router not
      supporting auto-configuration [OSPFV3].

Of course, but how is this achieved? How does a router with auto-config
determine that its neighbor does not have auto-config and then discover
the correct intervals to use?

I think you can detect that your neighor is not doing auto-config by the
absence of the OSPFv3 Router Auto-Configuration LSA, but what should an
auto-config router do once this has been detected?

---
                                 
Maybe it is obvious, but in the process of selecting a new Router ID in
7.3, the router MUST NOT select a value that it knows (through LSAs
received before the duplicate was detected) is already in use in the
network.

It is even possible that the router SHOULD maintain some memory of
Router IDs seen in the network recently so as to not pick an ID of a
router that is temporarily down or disconnected.

---

7.2

  The Router-Hardware-Fingerprint TLV contains a variable
  length value that has a very high probability of uniquely identifying
  the advertising OSPFv3 router.

So, the first time you run live at a customer site, you know that the
fingerprints will match on two devices and that they will both select
the same Router ID.

I think this is actually all OK so long as you indicate that this case
will be handled as a self-originated LSA and include a forward-pointer
to section 7.4.

---

7.2.1

  The TLV
  is padded to 4-octet alignment; padding is not included in the length
  field (so a 3-octet value would have a length of 3, but the total
  size of the TLV would be 8 octets).  Nested TLVs are also 32-bit
  aligned.


Nice mixture of units :-)
Why 32 bits when everything previous was in octets?

---

7.2.1

  The new LSA is designated for information related to OSPFv3 Auto-
  configuration and, in the future, can be used other auto-
  configuration information.

You already said that.

---

7.2.2

  The Router-Hardware-Fingerprint TLV is the first TLV defined for the
  OSPFv3 Auto-Configuration (AC) LSA.  It will have type 1 and MUST be
  advertised in the LSID OSPFv3 AC LSA with an LSID of 0.

So, if absent... ?

---

7.2.2

  The contents of the hardware fingerprint MUST be some combination of
  MAC addresses, CPU ID, or serial number(s) that provides an extremely
  high probability of uniqueness.  It is RECOMMENDED that one or more
  available universal tokens (e.g., IEEE 802 48-bit MAC addresses or
  IEEE EUI-64 Identifiers [EUI64]) associated with the OSPFv3 router be
  included in the hardware fingerprint.  It MUST be based on hardware
  attributes that will not change across hard and soft restarts.

I think you mean...

  The contents of the hardware fingerprint MUST have an extremely high
  probability of uniqueness.  It SHOULD be constructed from the
  concatenation of a number of local values that themselves have a high
  likelihood of uniqueness, such as MAC addresses, CPU ID, or serial
  numbers.  It is RECOMMENDED that one or more available universal
  tokens (e.g., IEEE 802 48-bit MAC addresses or IEEE EUI-64
  Identifiers [EUI64]) associated with the OSPFv3 router be included in
  the hardware fingerprint.  It MUST be based on hardware attributes
  that will not change across hard and soft restarts.

Although I am a little puzzled as to what would happen if I changed my
MAC address.

---

Is there a reason to allow IESG Approval for your new registry? Is this
to make it look like all of the other OSPFv3 registries, or is it
because you anticipate specific problems?

[Ballot comment]
I'll note that the RFC Editor will move Section 1.2 to the end.  If there's a reason you don't want that, you should let them know.

-- Section 10 --

  This specification also creates a registry for OSPFv3 Auto-
  Configuration (AC) LSA TLVs.  This registry should be placed in the
  existing OSPFv3 IANA registry, and new values can be allocated via
  IETF Consensus or IESG Approval.

The current term is "IETF Review" (not "IETF Consensus"), and you should have a normative reference to RFC 5226 here.  It would also be good to say when IESG Approval is an appropriate alternative to IETF Review.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ospf-ospfv3-autoconfig-10.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the OSPFv3 LSA Function Codes subregistry of the Open Shortest Path First v3 (OSPFv3) Parameters registry located at:

https://www.iana.org/assignments/ospfv3-parameters/

a new function code will be registered as follows:

LSA Function Code: [ TBD-at-registration ]
LS Type Description: OSPFv3 Auto-Configuration (AC) LSA
Reference: [ RFC-to-be ]

Second, a new registry, called the OSPFv3 Auto-Configuration (AC) LSA TLVs registry will be created in the existing Open Shortest Path First v3 (OSPFv3) Parameters registry located at:

https://www.iana.org/assignments/ospfv3-parameters/

The new registry will be maintained via IETF Consensus or IESG Approval as defined in RFC 5226.  There are initial entires in the new registry as follows:

+----------+------------------------------------+-------------------+
| Value    | Description                        | Reference        |
+----------+------------------------------------+-------------------+
|    0    | Reserved                          | [ RFC-to-be ]    |
|    1    | Router-Hardware-Fingerprint TLV    | [ RFC-to-be ]    |
|  2-65534 | Unassigned                        |                  |
|    65535 | Auto-configuration-Experiment-TLV  | [ RFC-to-be ]    |
+----------+------------------------------------+-------------------+

IANA understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (OSPFv3 Auto-Configuration) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'OSPFv3 Auto-Configuration'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-01-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  OSPFv3 is a candidate for deployments in environments where auto-
  configuration is a requirement.  One such environment is the IPv6
  home network where users expect to simply plug in a router and have
  it automatically use OSPFv3 for intra-domain routing.  This document
  describes the necessary mechanisms for OSPFv3 to be self-configuring.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-autoconfig/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-autoconfig/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) 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:

      This document specifies auto-configuration of OSPFv3 routers in
      certain environments that require auto-configuration, such as in a
      small IPv6 network like a home network.  To facilitate
      auto-configuration, this document specifies the default
      configuration, allows more flexibility in some verifications
      required by the OSPFv3 specification, and also describes a
      possible collision as well as the mechanism to resolve the
      collision.

Working Group Summary:

      The OSPFv3 router ID collision detection and resolution was a
      heated point of discussion a few months ago, but the issue has
      been resolved by IETF 89.  The technical aspect of the document,
      both within the document and mailing list discussions, have been
      stable for the last six months.

Document Quality:

      This document has been a WG document for a little under two years.
      It is stable, without changes to the technical solution for more
      than six months.  There are also two implementations based on this
      document already.  There is potentially a third implementation
      which implements parts of this draft.

Personnel:

      Helen Chen is the Document Shepherd.
      Alia Atlas is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

      This draft describes the mechanism for auto-configuration of
      OSPFv3 routers in a home network environment.  There is healthy
      participation, discussion, and review by both the OSPF WG and the
      homenet WG, including two complete implementations as well as a
      third implementation that partially implements this draft. 
      There are no outstanding issues with this draft.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has 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.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78 and BCP 79 have already been filed. If not, explain why?
 
      Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

      No.

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

      There is strong consensus from the WG, with a core group of WG
      participants agreeing with the solution and another group of more
      invested participants involved in long discussions that converged.

(10) 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
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Authors have resolved all nits.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) 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 plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).
 
      This document defines a new type of OSPFv3 LSA, which requires
      assignment of a number from the existing "OSPFv3 LSA Function
      Code" registry.  This document also defines a new registry for the
      TLVs of this new OSPFv3 LSA.  The IANA Considerations section
      correctly identifies the required registrations.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      A new registry for OSPFv3 Auto-Configuration (AC) LSA TLVs is
      required.  No Expert Review is necessary when allocating new
      values, as new values can be allocated via IETF Consensus or IESG
      Approval.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.