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

["Acee Lindem (acee)" <[e-mail]>]

Hi Adrian, 

On 2/2/15, 3:30 PM, "Adrian Farrel" <[e-mail]> wrote:

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

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.

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

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

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.


>
>Perhaps a few more words would help clarify.
>
>However...
>
>> 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.
>
>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.

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. 



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

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

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

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.

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


>
>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.
>
>> > 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.
>
>OK. Just wordsmith. It's only a Comment.
>
>> > 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.
>
>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.

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.

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

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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf