Subject: [i2rs] Comments on draft-i2rs-architecture [Security Considerations]

From: Daniel Migault <[email-masked]>
Date: Thu, 23 Apr 2015 10:31:32 -0400

Hi,

Please find my comments of the draft-i2rs-architecture's security
considerations:

Comment 1:

   "Two of existing protocol which the I2RS WG
   has selected to attempt to re-use are NETCONF [RFC6241] and RESTCONF
   [I-D.ietf-netconf-restconf].  The I2RS protocol design process is to
   specify additional requirements which will include security for an
   existing protocol in order to support the I2RS architecture."

We should make clear why NETCONF or RESTCONF have been selected in this
section. More specifically, if NETCONF or RESTCONF has some interesting
security properties, they should be exposed here. In addition, the scope of
the security consideration section should be protocol independent.

Comment 2

   "Due to the re-use strategy of the I2RS architecture, this security

   section describes the assumed security environment for I2RS with
   additional detail on:"

I believe security should be introduced within the i2rs scope. I would
propose the following text:

“At first I2RS should consider its interactions with existing interfaces
that manipulate the routing system resources, like the management plane or
the routing control plane for example. The scope of identifying these
interactions is to limit how I2RS impacts these already existing interfaces
as well as how these existing interfaces impact I2RS.

Within the I2RS architecture, there is a strong need that the routing
system resource remain protected. This means that strong Authentication
Authorization and Access control policies should be enforced between the
different entities involved in the I2RS architecture. This includes
considerations on Identity, Authentication, Authorization. Then in order to
be enforced, these policies should rely on a robust and highly available
I2RS architecture.

This describes I2RS security with additional details on:"

Comment 3

  " To support numerous and speedy interactions between the I2RS
   Agent and I2RS Client, it is assumed that the I2RS Agent can also
   cache that particular I2RS Clients are trusted and their associated
   [page break]

   authorized scope.  This implies that the permission information may
   be old either in a pull model until the I2RS Agent re-requests it, or
   in a push model until the authentication and authorization channel
   can notify the I2RS Agent of changes."

This does not seems to me a security issue, but instead a performance
aspect.  One option is to remove these lines. If performance still got its
place here, I would propose the following text:

"In order to provide the AAA enforcement policies a similar scalability as
the scalability provided by the I2RS Client broker architecture, some means
should be provided in order to distribute the authorization policies among
the I2RS Clients. More specifically, an I2RS Client should be able to
retrieve the I2RS Agent AAA policies that apply to itself. When an
application sends a resource access to the I2RS Client that would be
rejected by the I2RS Agent, this request could be rejected by the I2RS
Client instead. This avoids loading unnecessarily the network and the I2RS
Agent.  On the other hand, as AAA of the I2RS Agent are subject to changes,
the I2RS Client should be informed when these changes occurs."

Comment 4

"An I2RS Client is not automatically trustworthy"

I would propose the following rewordings, which seems at least for me
clearer:
“I2RS Agent do not inherently trust I2RS Client.”

Comment 5

   " If the I2RS Client is
   acting as a broker for multiple applications, managing the security,
   authentication and authorization for that communication is out of
   scope;"

I would propose the following words:

"If the I2RS Client is acting as a broker for multiple applications,
managing the security, authentication and authorization for that
application is out of scope of I2RS;"

Comment 6

"Different levels of integrity, confidentiality, and replay protection
   are relevant for different aspects of I2RS. "

I would probably add this where  “Mutual authentication” is discussed. In
addition those two paragraphs could be placed in section 4.1.

I found confusing to speak about different levels as we do not consider
weak, strong or no authentication/encryption.  Thus I would rather propose
to say  “Authentication or Encryption are not mandatory” instead of talking
about levels.

The proposed text would be:

"Different security mechanisms for integrity, confidentiality, and replay
protection
   are relevant for different aspects of I2RS. “Authentication or
Encryption are not always mandatory"

Comment 7

   "For example, a I2RS client may request notifications
   of certain events and the agent will open a communication channel to
   report such events."

I understand that it is possible for example for an I2RS Client to open a
communication so event are reported to a third party, for example a shared
repository. This prevents that the same flow is being sent to multiple I2RS
Clients requesting for it.

In this case, I do not think that authentication is sufficient. Instead the
destination of the flow must agree to receive the flow. Suppose multiple
authenticated I2RS Client opens a channel on shared_repo_x. As shared_rep_x
has not been part of the negotiation, it may become overloaded.

Comment 8 section 4.1

   "While
   those applications' identities are not needed for authentication or
   authorization, "

I would propose the following text:
"The secondary identities are not used for authentication or authorization
purpose by the I2RS Agent. In fact the I2RS Agent only authenticate the
I2RS Client. On the other hand, for  tracking attribution of operations to
support functionality such as troubleshooting and logging of network
changes, the I2RS Client may provide the secondary identities to the I2RS
Agent. "

Comment 9 section 4.3

  "I2RS must support client redundancy.  At the simplest, this can be
   handled by having a primary and a backup network application that
   both use the same client identity and can successfully authenticate
   as such."

I suggest that “network application” be replaced by “I2RS Client”.

Additional Comments

A)
Section 1.1

It is not very clear to me what is an ephemeral state:

"Such an interface also facilitates the injection of ephemeral state into
the routing system." The explanation of ephemeral state comes in section
6.2.1. Unless, this is well known vocabulary, I would clarify this at the
first time it appears, and so directly in this section 1.1.

B)
Section 3

I suppose "... and because the performance and scaling requires varies
based on the particular use-cases." should be replaced by "... and because
the performance and scaling requirements varie based on the particular
use-cases."

C)
Section 4.1
I suppose "even information" should be replaced by “event information”

D)
Section 4.2
I suppose "can be specify" should be replaced by "can be specified"
I suppose "is linked a" should be replaced by "is linked to"
I suppose 'that contained' should be replaced by "that is contained"
I suppose "This scope policy is can be" should be replaced by "This scope
policy can be"

E)
Section 6.2.1
In the section NOTIFICATION_I2RS_AGENT_STARTING: It look sto me the
following sentence is wrong : "... The agent-boot-count allows an I2RS
Client to determine if the I2RS Agent has restarted". Instead, it should be
replaced by "... The agent-boot-count allows an I2RS Client to determine if
the I2RS Agent has restarted since the routing element has restarted"

-- 
Daniel Migault
Ericsson