Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT)

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D30512D587; Wed, 17 Aug 2016 19:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.738
X-Spam-Level: *
X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2ueSV7TDU8Aq; Wed, 17 Aug 2016 19:37:13 -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 43BAD12B041; Wed, 17 Aug 2016 19:37:13 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'Alvaro Retana'" <>, "'The IESG'" <>
References: <>
In-Reply-To: <>
Date: Wed, 17 Aug 2016 22:36:11 -0400
Message-ID: <000001d1f8f9$490933a0$db1b9ae0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJc/Nj7gQdXELJSuw4AgM5RmU8Yz5839V1g
Content-Language: en-us
Archived-At: <>
Cc: 'Jeffrey Haas' <>,,,
Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Aug 2016 02:37:15 -0000


I just uploaded version -08.txt.  Please review it to see if has changed your feelings on the secure transport.   See comments below. 

-----Original Message-----
From: Alvaro Retana [] 
Sent: Wednesday, August 17, 2016 9:53 PM
To: The IESG
Cc:; Jeffrey Haas;;
Subject: Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-07: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


>I have the same concerns as others around the secure transport, but I'm not putting in a DISCUSS because the concerns are already well represented.  Just one additional comment >on the topic:

Please see if I have answered these questions in version -08.txt and in the email. If not, please let me know. 

>I think there is a contradiction between SEC-REQ-09 ("The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a >non-secure transport") and this text from Section 3. (Security-Related Requirements): "…MUST be able to exchange data over a secure transport, but some functions may operate >on a non-secure transport."  The latter text talks bout "some functions" using a non-secure transport, while SEC-REQ-09 implies that everything may use it.

I do not see the contradiction in -08.txt.  

"The I2RS client and I2RS agent using the I2RS protocol MUST be able to exchange 
data over a secure transport, but some functions may operate on a non-secure

This says the I2RS client and I2RS agent must support using the I2RS protocol over a security transport, but I2RS client software and I2RS agent software may operate on non-secure transport.  

Other comments from Section 3.1. (Mutual authentication of an I2RS client and an I2RS Agent) 

>-- The text says that the "I2RS architecture [I-D.ietf-i2rs-architecture] sets the following requirements".  I'm not sure what you mean my "sets", as there are no requirements 
> labeled as such) in the architecture document.  If there are, then this section doesn't seem to be needed (as others have mentioned).  Maybe "these requirements are derived 
> from the architecture", or something similar may be more appropriate.

You are correct, the I2RS architecture does not label such requirements.  

We got into discussing a strawman protocol, and we found we needed to restate the I2RS architecture documents design in the specific requirements listed now in version 8 as:  SEC-REQ-01 to SEC-REQ-07.   In this case the restatement is useful (see Joel's comment).  Do you have a suggestion for another term than "sets".  

>-- What is a "valid identifier"?  A couple of requirements where a "valid identifier" "MUST" be confirmed are listed, but no indication as to what
>that may be in this document or the architecture one.   The definition of
> identifier doesn't help…

Actually, the security people indicated that a "valid identifier" was the appropriate term.  You have an identity which is expressed as an identifier. The identifier can (or cannot be) a valid identifier for the identity.   Identity consists of loss of features.  An identifier is the way to express the identity in a protocol. 

>  SEC-REQ-05 and SEC-REQ-06 sound the same to me.  What is the difference?  BTW, if there is a difference, instead of "IETF" I think that "standardized" may be better.

Merged these into one in version -08.txt .  Let me know what you think of the merge.