Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

"Joel M. Halpern" <> Wed, 17 August 2016 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5981B12D7D5; Wed, 17 Aug 2016 15:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.722
X-Spam-Status: No, score=-2.722 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 OHpCdUKzxs84; Wed, 17 Aug 2016 15:03:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5336212D7D6; Wed, 17 Aug 2016 15:03:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC3231C01C8; Wed, 17 Aug 2016 15:03:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1.tigertech; t=1471471389; bh=gD6fPU43wFhXHDDbBymHxZ5+bs8FbS9a4faklrC9Uhg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=AuKZwD/8aLA6rQfie0M+kzjvT3gGMl/VYDaSAAdzn8TBJGULhEHLKL4c7jyOf+3UN 4otEKEg69+yXj9aY5th+U8IYgvyUmq3V6CaCmxNSTZ0qe0ky8CNAJFSAsNp4JzuhtK pM2lmmalOdCUHzmLd5p2koLWFXdOLG2Z577y4sJM=
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1EE781C0340; Wed, 17 Aug 2016 15:03:09 -0700 (PDT)
To: Ben Campbell <>, The IESG <>
References: <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Wed, 17 Aug 2016 18:04:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [i2rs] Ben Campbell's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and 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: Wed, 17 Aug 2016 22:03:12 -0000

Making sure I understand what is being asked in each of these items, 
hence in-line.

On 8/17/16 5:11 PM, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-i2rs-protocol-security-requirements-07: Discuss
> 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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> In section 3.4, the text says that the requirements that the integrity
> protection mechanisms can actually provide integrity protection are
> SHOULD because some communication may occur over non-secure channels.
> That does not follow, since the rationale is about use, while the actual
> requirement is about capability.  As currently written, it leaves it
> possible for people to select a protocol that cannot provide integrity
> protection at all. I think the SHOULDs in 14 and 15 need to be MUSTS.

I think what you are asking is that we rephrase these requirements to 
indicate that implementations must include integrity protection 
capability which meets these requirements.  And that the current text 
explaining the SHOULD becomes text about when these mechanisms SHOULD be 

> In the third paragaph of 3.2, Isn't the point to say that ephemeral data
> MUST be sent over a secure transport unless the data model explicitly
> labels it as safe for insecure transports? As written, it seems to leave
> room to send data that is not labeled as safe to also be sent over
> insecure transports.

I am having trouble seeing the problem.  The text, as far as I can tell, 
says "SHOULD be protect", and then goes on to say "except when the model 
says it is okay to send unprotected".  That seems to say the right thing.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> -2.1: I am on the fence about other's comments about copying definitions
> here--but if you do copy them here, it seems strange to not mention
> "client" or "agent".

I can live with just listing the terms and references, without the text. 
  It makes reading a little more complex for new readers, but avoids any 
risk of error in copying.

> I agree with Alissa about equating privacy and confidentiality.

I was going to simply say "sure", but REQ-20 sems to need to still say 
"privacy".  Not sure what you (individually or collectively) would like 
us to do.
I do note that if the terminology has shifted from that documented in 
4949, it would be helpful to those of us who do not live with it daily 
to have some way to know such.

> -3.1,:
> I’m confused by the first paragraph. I don’t find strings of the form of
> SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right?

Section 3.1 is trying to recapitulate for context requirements that are 
stated in textual form in RFC 7921.  No, they are not lsited as 
SEQ_REQ-XX or even REQ-XX in RFC 7921.  Thus, in addition to context, 
listing them here allows us to give them numbers for consistency of 
discussion.  (Thus, this is a case where repetition adds value.)

> It’s not clear to me how 5 and 6 differ. Is it just a matter of the
> additional “before establishing a connection” part in 6?

As far as I know, it is indeed just a matter of the timing being added 
in 6.  If this is a problem, we can collapse them.

> -3.4: Isn't 15 simply a restatement of the third item under 14?

that looks like an error on our part.  Maybe I missed something, but I 
think we can drop that when we rewrite to address your major comment.

> 3.5: The  MAYs in 19 and 20 seem like statements of fact. (That is, do
> they simply recognize reality, or to they  grant permission?)

Re-reading these, the MAY in 19 is a description of allowed 
architecture, and seems to me to wall within the 2119 meaning.
The may in 20 is subtler.  I think it is recognizing reality, since that 
mechanism is not something we are going to be defining, as far as I 
know.  It can be argued that it is saying that these requirements allow 
such a range of mechanism.  But I agree that 2119 usage is a bit of a 
stretch there.

> _______________________________________________
> i2rs mailing list