Re: [secdir] Secdir review of draft-ietf-i2rs-architecture-13

["Susan Hares" <[e-mail]>]

Charlie: 

 

Thank you for the insightful comments.  Please see my response below.  I've
posted a version -14 with these changes.  I welcome any additional comments
you have. 

 

Sue 

 

From: Charlie Kaufman [mailto:[e-mail]] 
Sent: Saturday, March 26, 2016 8:32 PM
To: [e-mail]; 'The IESG'; [e-mail]
Subject: Secdir review of draft-ietf-i2rs-architecture-13

 

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

 

I reviewed the -07 version of this document in December 2014. As was true
then, this document says very little about security other than the kinds of
security mechanisms that are needed. In particular, it does not say what
security mechanisms will be used. The document appears to be part of a large
suite of documents covering various aspects of this I2RS thing. I would hope
the security relevant information appears somewhere else.

 

Sue's comments: 

The protocol security requirements are in
draft-ietf-i2rs-protocol-security-requirements, 

And the security environment is in
draft-ietf-i2rs-security-environment-reqs. 

 

 

I can't resist commenting on some of the things I found confusing. It is
likely a lot of my confusion is addressed in related documents. Assuming
that's true, it would be helpful if some - perhaps common - introduction to
the document suite specified an order in which the documents should be read
of avoid forward references.

 

The introduction section has been changed to include: 

Add /Security is a concern for any new interface to the routing system. 

  Section 4 provides an overview of the security considerations for 

  the I2RS architecture. The detailed requirements for I2RS 

  protocol security are contained in [draft-ietf-i2rs-protocol-security-
requirements], 

  and the detailed security requirements for environment in which the I2RS
protocol exists in are contained in
draft-ietf-i2rs-security-environment-reqs. 

 

 

The document calls itself An Architecture to the Interface to the Routing
System. It doesn't say whether this interface is an API or a protocol.
Probably both are involved. Section 4 paragraph 1 says "I2RS has been
designed to re-utilize existing protocols that carry network management
information. Two of the existing protocols which the which may be reused
(sic) are NETCONF and RESTCONF." This makes it sound like I2RS is an API.
But section 7.2 paragraph 1 says "All such communication channels will use
the same higher-layer I2RS protocol (which combines secure transport and
I2RS contextural information). This makes it sound like a protocol.

 

Section 4: paragraph 1 altered to the following: 

 

This I2RS architecture describes interfaces that clearly require

serious consideration of security. As an architecture, I2RS has

been designed to reuse existing protocols that carry network

management information. Two of the existing protocols which are 

being reused for I2RS protocol are NETCONF [RFC6241] and RESTCONF. 

 

 

Section 4.1 paragraph 2 talks about application identity, but it wasn't
clear (at least to me) whether it was referring to the application as code
and protocol (e.g., Wireshark) or as the owner of the instance of the
application to determine permissions.

 

 

Old/

I2RS clients mayb e operating on behalf of other applications. 

While those applications' identities are not needed for authentication or 

Authorization, each application should have a unique opaque identifier that
can be provided

By the I2RS client to the I2RS agent for the purpose of tracking attribution
of operations to support  functionality such as troubleshooting and logging
of network changes. 

 

New/ 

I2RS Clients may be operating on behalf of other applications.

While those applications' identities are not needed for authentication or
authorization, each application should have a unique opaque identifier that
can be provided by the I2RS client to the I2RS agent for purposes of
tracking attribution of operations to an application identifier (and from
that to the application).  This tracking of operations to an application
supports I2RS functionality for tracing actions (to aid troubleshooting in
routers) and logging of network changes 

/

 

 

Section 6.4.2 says "Directly writing to these protocol-specific RIBs or
databases is out of scope for I2RS" but says "joining/removing interfaces
from multicast trees" was a supported operation. Doesn't that involve
directly updating a protocol-specific database?

 

No:  The static joins/leaves can be done statically via general I2RS
multicast FIB/RIB interface.  

 

 

Section 7.6 says any given piece of information... (should only be)...
manipulated by a single I2RS Client. But section 4.3 says there should be
multiple clients running with the same client identity. This leaves
ambiguous how the clients are supposed to coordinate and whether (for
example) both will get copies of notifications the client identity has
signed up for.

 

Sue:  Yes, it is ambiguous in the architecture because different data models
will handle it differently.  For example, an I2RS model handling an
ephemeral RIB may be manipulated by multiple clients, but the unique unit is
the route.   The I2RS RIB model indicates how notifications will of route
changes will be sent.   The publication/subscription of notifications is
described in the pub/sub requirements. 

 

 

Nits (typos/language):

Section 4 para 1: "which the which may" -> "which may" Fixed
Section 4 para 1: "existing protocol in order" -> "existing protocols in
order" Fixed
Section 4 para 5: "I2RSS" -> "I2RS" Fixed
Section 6.3 para 1: First ref to "yang data model" should have reference.
Paragraph re-written
Section 7.4 para 1: "value ranges for portion of scope policy" -> ???

Replaced with:  The specifications for data scope policy (for read, write, 

or resources consumption) need to specify the data being controlled by the
policy, 

and acceptable ranges of values for the data


Section 7.5 para 3: "mechanism instantiated" -> "mechanisms instantiated"

Fixed