Re: [secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements-06

"Susan Hares" <> Thu, 18 August 2016 02:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C91A412D5EC; Wed, 17 Aug 2016 19:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.739
X-Spam-Level: *
X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ve-TX5NxkgzV; Wed, 17 Aug 2016 19:13:09 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1FEF12D5BC; Wed, 17 Aug 2016 19:13:08 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=;
From: Susan Hares <>
To: 'Radia Perlman' <>,, 'The IESG' <>,
References: <>
In-Reply-To: <>
Date: Wed, 17 Aug 2016 22:11:52 -0400
Message-ID: <015701d1f8f5$eae5a6d0$c0b0f470$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0158_01D1F8D4.63D58D70"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHCtNdp+3zCUnemYE+gWRpQ0UPOFqBqmqQQ
Content-Language: en-us
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements-06
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Aug 2016 02:13:11 -0000



Thank you for these excellent editorial comments.   A version -08 addresses your comments. 


From: Radia Perlman [] 
Sent: Saturday, August 13, 2016 8:08 PM
To:; The IESG;
Subject: Secdir review of draft-ietf-i2rs-protocol-security-requirements-06


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.


The document is about the security requirements between a management station (what I assume a "I2RS client" is) and the agent on a "routing system". These include mutual authentication, transport security, atomicity.


The document is well-written and ready, with nits.

>I haven't been following this WG, so apologies for perhaps not getting the terminology, though it might be better if every document were self contained, in >defining terms, or pointing to a different document where all the terms are defined.

1)      The meaning of the  term in the spec  "routing system" is not obvious to me. I'm assuming it means not only routers but anything that looks at layer 3 such as load splitters and hypervisors, is that correct? Maybe the term is defined in a different document? If not, a clarifying sentence would be appreciated by readers.\

Sue’s Response: Added the following definition: 

/I2RS routing system:  Layer three (L3) routing systems which include physical routers,  virtual routers (in hypervisors or load splitters), and other devices handling L3 routing./

2)  In section "I2RS multi-message atomicity"
"this is not supported in order to simply the first version of I2RS" 
should be "simplify"
   Added in version 7 
3)  "If insecure transport is used, then confidentiality and integrity cannot be achieved"
That statement, as a sweeping statement, isn't true, since, for instance, Ethernet does not provide any confidentiality and integrity, but protocols can achieve confidentiality and integrity by doing it themselves.  So perhaps the statement should be softened to say something like "I2RS does not itself provide confidentiality and integrity, so it depends on running over a secure Transport that provides these features".
Sue’s Comment: Agreed.  Here’s my new text. 
New text/
Since, I2RS does not itself provide confidentiality and integrity, 
so it depends on running over a secure Transport that provides these features. 
I2RS allows the use of an insecure transport for portions of data models that clearly indicate
insecure transport. Operators deploying I2RS must determine if they want to populate and 
deploy the portions of the data model which use insecure transports.
4)  "All I2RS clients and I2RS agents MUST have an identity, and at least one unique identifier that uniquely identifies each party in the I2RS protocol context."
This might be overly restrictive.  You might want several I2RS clients acting as instances of a single identity, in which case, they might all share the same identity.  
 Sue’s Response:  We consider that a single identity = a single client.    If the client has multiple instances and multiple transports, it is still consider the same identity. 
" SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF
      or private) will distribute or load identifiers so that the I2RS
      client/agent has these identifiers prior to the I2RS protocol
      establishing a connection between I2RS client and I2RS agent."
Instead of "distribute or load", perhaps "configure" would be clearer?  At any rate, I don't know the difference between "distribute" and "load".
Configure is not the right word.  One example for loading the identities is AAA. 
How about the following:
/The I2RS protocol SHOULD assume some mechanism(s) (IETF or private) will
 distribute the identifiers and load these into the I2RS client and agent  
 so that the I2RS client/agent has these
 identifiers prior to the I2RS protocol establishing a connection 
 between I2RS client and I2RS agent. (One mechanism such mechanism is AAA protocols.)



Thank you for your review.