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

"Alvaro Retana (aretana)" <> Thu, 18 August 2016 02:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EBAD12D843; Wed, 17 Aug 2016 19:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h1cpLApc-RZI; Wed, 17 Aug 2016 19:53:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A515312B063; Wed, 17 Aug 2016 19:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3215; q=dns/txt; s=iport; t=1471488810; x=1472698410; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iqvqJGCahmOnbFgM7uNc9pRBzkb6XEYfAXOhmk0T+Zk=; b=L3EiKAV36Vtrme6GpYoe5cS2paoXG/vKw8bCjrsO9n1B85xOvkBXMAlD fQf5EZNk75r2PHjl0TLtWdZSIMrJ3FwNfIMp73ti3om4Q2uGZYC/pmXoF ZLXqBVWGwd+4RzO9FRHpndsd3E3+i2NWS1Vs0SB2mwoYL70na1NxprE8s w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAgADHrVX/4QNJK1eg0SBUge1RYIPg?= =?us-ascii?q?X2CZoM3AoFmOBQCAQEBAQEBAV4nhF8BBXkQAgEIDgQpCzIXDgIEAQkEBYgxviI?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiqETYQdhX4BBJN9hUcBjx2PSZAyAR42g?= =?us-ascii?q?kWBNW6FaUV/AQEB?=
X-IronPort-AV: E=Sophos;i="5.28,537,1464652800"; d="scan'208";a="141076943"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Aug 2016 02:53:29 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u7I2rTpJ006487 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Aug 2016 02:53:29 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 17 Aug 2016 21:53:29 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 17 Aug 2016 21:53:28 -0500
From: "Alvaro Retana (aretana)" <>
To: Susan Hares <>, "'The IESG'" <>
Thread-Topic: Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT)
Thread-Index: AQHR+Plx0ThSsjCXkUiHItVMbeJWy6BOBWuA
Date: Thu, 18 Aug 2016 02:53:28 +0000
Message-ID: <>
References: <> <000001d1f8f9$490933a0$db1b9ae0$>
In-Reply-To: <000001d1f8f9$490933a0$db1b9ae0$>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:53:32 -0000

On 8/17/16, 9:36 PM, "iesg on behalf of Susan Hares"
< on behalf of> wrote:



>>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
>data over a secure transport, but some functions may operate on a
>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.

-08 still has these two pieces of text:

"SEC-REQ-08: 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


>From Section 3: "...MUST be able to exchange data over a secure transport,
but some functions may operate on a non-secure transport."

Again, the difference is that the latter text mentions "some functions"
(which seems in line with the changes you made in this version to
highlight that not everything could be run over an insecure transport),
while SEC-REQ-08 basically says that the i2rs protocol MAY be run over
non-secure transport -- but it doesn't limit the i2rs protocol to some
functions or some type or information.

>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".

See above.

>>  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.

Now the single requirement just sounds redundant...