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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 01 Feb 2015 11:44:20 -0800

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?

---

From: Jari Arkko <[email-masked]>
Date: Mon, 2 Feb 2015 17:33:18 +0200

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

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

> best you offer is a single, network-wide password to cover all 

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.

> recommend limits on the applicability of this spec.

Given the above, what words would you suggest?

> you would find a way to mitigate it.

Seems reasonable.

> implementation of this spec will do something different from 2328?

My understanding is that it is really is a difference.

>   base OSPFv3 protocol specification [OSPFV3].

Good. Thanks.

> s/described:/described in this document:/

Yes.

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

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

Yes, much better.

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

Yes.

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

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

s/vanilla//

> auto-config router do once this has been detected?

Not be auto configured on that interface?

> router that is temporarily down or disconnected.

Seems reasonable. Thanks.

> will be handled as a self-originated LSA and include a forward-pointer

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

> Why 32 bits when everything previous was in octets?

I think we are following previous practice...

>   configuration information.

ok

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

>   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

Your ID may change. That could be fine.

> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 2 Feb 2015 20:30:41 -0000

Hi Jari,

Thanks for engaging!

I've cut down to the open issues. Recall that Comments are just for you and your
AD to think about.

Adrian

> not sure it is needed. Acee?

I'd be OK with that.
If you all *do* think that it was intended that this be considered part of the
core function of OSPFv3, then clearly it is an update and some statements will
be needed.

>    *minimally offer an option* to explicitly configure a single password

Perhaps this is an American thing?
Are you saying that the text means that the implementations should include at
least an option to configure a single password, but may include more security?
I read it to mean that the implementations should include the minimal option of
a single password (implying this or nothing).

Perhaps a few more words would help clarify.

However...

>    an automatically configured, securely routed network.

I saw this and thought it was a classic dodge. "Yeah the security sucks, but a
future extension might make it OK." From the perspective of this specification,
that means that there isn't a mechanism for automatic security pairing so we
must fall back on the other mechanisms when assessing the utility of the spec.

> as a whole is no longer worthwhile.

Well, I read "The configuration and operational description of such deployments
is beyond the scope of this document" to say that there is no description of how
to use the mechanisms in this document combined with any better security than
domain-wide password.

And your note here seems to confirm the view that you might be in the position
of either using autoconfig or using decent security, but not both.

And that led to my Discuss point that this appears to make the solution
inadvisable for SPs and larger enterprises. In other words it is predominately a
homenet or small enterprise solution. That needs to be called out.

Perhaps you don't need to go as far as making a statement about the target
network, if you make a clearer statement about the level of security you can get
with this solution. (see below)

(BTW, lots of people would *really* like a carrier-class autoconfig solution.)

> Given the above, what words would you suggest?

How about (in the Introduction)

The solution described in this document is not consistent with advanced routing
protocol security. Such per-peer security mechanisms require the manual
configuration of security associations, and that configuration is in contrast to
the objectives of this document to reduce per-router configuration. Although
some security can be achieved by using common security credentials across a
whole auto-configuration domain, that might not provide sufficient security for
some deployment scenarios. Operators should carefully consider ther security
requirements of their network before deploying the solution described in this
document.

> My understanding is that it is really is a difference.

OK. Just wordsmith. It's only a Comment.

> NOT want to run OSPFv3 on that case.

OK. Suggest you re-read the paragraph. The wording of the example implies that
opposite of the example will be true, but that is not the message you seem to
want to deliver. It's only a Comment.

> Not be auto configured on that interface?

So you could say this?
If a router attempting to perform auto-configuration as described in this
document does not receive an OSPFv3 Router Auto-Configuration LSA from a peer,
it MUST not attempt to bring the adjacency up, and MUST NOT advertise any links
to that peer until manual configuration of the adjacency has been activated.
It's only a Comment.

Adrian

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 3 Feb 2015 14:06:19 +0000

Hi Adrian, 

>core function of OSPFv3, then clearly it is an update and some statements

The base protocol does change when OSPFv3 auto-configuration is in effect.
We are relaxing the hello interval/dead time constraints and adding some
hysteresis to RFC 2328. We could have been more pedantic about the hello
interval/dead time but it wouldn¹t have added any value as the end result
of the adjacency not forming would be the same.

Now - one thing we seem to struggle with is whether the base protocol RFC
should be listed as ³updated" when the base mechanisms are extended or
only when the base protocol mechanisms are changed.

>Perhaps this is an American thing?

Yeah - It should be self evident that home users are endowed by their
Creator with the unalienable right to a self-configuring OSPFv3 router
offering security with minimal configuration.

>a single password (implying this or nothing).

Yes - but if you read the manageability section of the draft it recommends
offering complete configuration as well.

   It is RECOMMENDED that OSPFv3 routers supporting this specification
   also allow explicit configuration of OSPFv3 parameters as specified
   in Appendix C of [OSPFV3].  The would allow explicit override of
   autoconfigured parameters in situations where it is required (e.g.,
   if the deployment requires multiple OSPFv3 areas).  This is in
   addition to the authentication key configuration recommended in
   Section 4 which supports OSPFv3 authentication with the absolute
   minimum manual configuration.

>must fall back on the other mechanisms when assessing the utility of the

I wouldn¹t say that RFC 7166 authentication sucks. What this is conveying
is that future mechanisms for automatic security pairing are not precluded
and we're not trying to solve this problem with an OSPFv3 specific
solution. 

>of either using autoconfig or using decent security, but not both.

I think your definition of ³decent² is somewhat objective but, otherwise,
your understanding is correct. What I will add is,

 ³For example, IPsec, per-interface keys, or other security mechanisms
could be explicitly configured as described in section 8."

>(BTW, lots of people would *really* like a carrier-class autoconfig

OSPFv3 is the wrong place to solve the security aspects of a carrier-class
auto-config solution. There are many ways to attack this and the first
thing to agree on is the operational model.

>How about this for the ³Introduction²?

Since the goals of auto-configuration and security can be conflicting,
operators and network administrators should carefully consider their
security requirements before deploying the solution described in this
document. Refer to section 8 for more information.

>want to deliver. It's only a Comment.

I¹ll remove the part about BGP peering as this was meant to exclude iBGP
where you¹d want an IGP adjacency. However, in this context, it
complicates the example.

>to that peer until manual configuration of the adjacency has been

I don¹t see how this isn¹t clear to anyone familiar with OSPFv3 - to form
an adjacency both routers need to either have the same hello/dead
intervals or both support auto-configuration.

Thanks,
Acee 

>It's only a Comment.
>
>Adrian
>
>_______________________________________________
>OSPF mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ospf