[OSPF] Adrian Farrel's Discuss on draft-ietf-ospf-ospfv3-autoconfig-13: (with DISCUSS and COMMENT)

["Adrian Farrel" <[e-mail]>]

Adrian Farrel has entered the following ballot position for
draft-ietf-ospf-ospfv3-autoconfig-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-autoconfig/



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


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