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

[Jari Arkko <[e-mail]>]

Thanks for your in-depth review and comments, Adrian.

> 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 am fine with dropping the update. I think the original reason for updating
was to be considered as a part of basic functionality. In retrospect, I am
not sure it is needed. Acee?

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

The document says in Section 4 (my emphasis):

   it is RECOMMENDED that OSPFv3 routers supporting this specification
   *minimally offer an option* to explicitly configure a single password

and Section 8:

   However, auto-configuration can also be combined with
   password configuration (see Section 4) or future extensions for
   automatic pairing between devices.  These mechanisms can help provide
   an automatically configured, securely routed network.

   In deployments where stronger authentification or encryption is
   required, OSPFv3 IPsec [OSPFV3-IPSEC] or stronger OSPFv3
   Authentication trailer [OSPFV3-AUTH-TRAILER] algorithms *MAY be used
   at the expense of additional configuration*.  The configuration and
   operational description of such deployments is beyond the scope of
   this document.

I think the intent is that existing functionality is not removed. There is
a recommendation for a single-password simple version, but that
does not mean it is the only option. Of course, the additional security
configuration effort may make the situation such that auto configuration
as a whole is no longer worthwhile.

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

Given the above, what words would you suggest?

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

Seems reasonable.

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

My understanding is that it is really is a difference.

> 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].

Good. Thanks.

>   The following aspects of OSPFv3 auto-configuration are described:
> 
> s/described:/described in this document:/

Yes.

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

Not from my point of view, but I suppose the RFC Editor can also order
the sections in their preferred way.

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

Yes, much better.

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

Yes.

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

I think the rest of the paragraph are saying exactly the opposite, i.e., 
NOT want to run OSPFv3 on that case.

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

s/vanilla//

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

Not be auto configured on that interface?

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

Seems reasonable. Thanks.

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

Yes, although i’m not sure new text is needed, as I thought this was 
clear already earlier.

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


I think we are following previous practice...

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

ok

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

Same as with any other issue where you are presented an invalidly formatted
data. Acee, is there a good reference to existing RFCs for that behaviour?

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

This is better. Thanks.

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

Your ID may change. That could be fine.

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

Past experience with IANA rules indicates that it is good to provide a
rule while allowing for special treatment in case that something special
happens. I do not at least expect any special issues to be likely, but
I think it is better practice to define the IANA rules in this fashion,
because it leaves a usually :-) sane board be able to deal with
exceptions if they ever arise without having to re-issue any RFCs.

Example: experimental IRTF RFCs might in some cases be fine
for some allocations.

Jari