Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91A412D5EC; Wed, 17 Aug 2016 19:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve-TX5NxkgzV; Wed, 17 Aug 2016 19:13:09 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (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=174.124.169.225; 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$@ndzh.com> 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 X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements-06 X-BeenThere: secdir@ietf.org 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 This is a multipart message in MIME format. ------=_NextPart_000_0158_01D1F8D4.63D58D70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Radia: =20 Thank you for these excellent editorial comments. A version -08 = addresses your comments.=20 =20 From: Radia Perlman [mailto:radiaperlman@gmail.com]=20 Sent: Saturday, August 13, 2016 8:08 PM To: secdir@ietf.org; The IESG; = draft-ietf-i2rs-protocol-security-requirements.all@tools.ietf.org Subject: Secdir review of = draft-ietf-i2rs-protocol-security-requirements-06 =20 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. =20 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. =20 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=E2=80=99s Response: Added the following definition:=20 /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"=20 should be "simplify" =20 Added in version 7=20 =20 =20 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". =20 Sue=E2=80=99s Comment: Agreed. Here=E2=80=99s my new text.=20 =20 New text/ Since, I2RS does not itself provide confidentiality and integrity,=20 so it depends on running over a secure Transport that provides these = features.=20 =20 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=20 deploy the portions of the data model which use insecure transports. / =20 =20 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." =20 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. =20 =20 Sue=E2=80=99s Response: We consider that a single identity =3D a = single client. If the client has multiple instances and multiple = transports, it is still consider the same identity.=20 =20 =20 " 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." =20 Instead of "distribute or load", perhaps "configure" would be clearer? = At any rate, I don't know the difference between "distribute" and = "load". =20 Response: =20 Configure is not the right word. One example for loading the identities = is AAA.=20 =20 How about the following: =20 New:=20 /The I2RS protocol SHOULD assume some mechanism(s) (IETF or private) = will distribute the identifiers and load these into the I2RS client and = agent =20 so that the I2RS client/agent has these identifiers prior to the I2RS protocol establishing a connection=20 between I2RS client and I2RS agent. (One mechanism such mechanism is = AAA protocols.) / =20 Radia =20 =20 Thank you for your review.=20 =20 Sue=20 ------=_NextPart_000_0158_01D1F8D4.63D58D70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Radia:

 

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

 

From:= = Radia Perlman [mailto:radiaperlman@gmail.com]=
Sent: Saturday, August 13, 2016 8:08 PM
To: secdir@ietf.org; The IESG; draft-ietf-i2rs-protocol-security-requirements.all@tools.ietf.or= g
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.\

S= ue=E2=80=99s 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=E2=80=99s Comment: Agreed.  =
Here=E2=80=99s 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.  
 <=
/span>
 Sue=E2=80=99s =
Response:  We consider that a single identity =3D 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".
 
Response:  
Configure is not the right word.  One example =
for loading the identities is AAA. 
 
How about the =
following:
 
New: 
/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.)
/
 
Radia

 

 

Thank you = for your review.

 

Sue =

------=_NextPart_000_0158_01D1F8D4.63D58D70--