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

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

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.

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

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

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

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

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

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

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

Adrian