Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-11: (with DISCUSS and COMMENT)
"Susan Hares" <shares@ndzh.com> Mon, 26 September 2016 22:24 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D75B12B028; Mon, 26 Sep 2016 15:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 Mp7TtlHGl51Q; Mon, 26 Sep 2016 15:24:27 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 8FE9A12B01C; Mon, 26 Sep 2016 15:24:19 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.51;
From: Susan Hares <shares@ndzh.com>
To: 'Alissa Cooper' <alissa@cooperw.in>, 'The IESG' <iesg@ietf.org>
References: <147491684980.4980.3899605336197818600.idtracker@ietfa.amsl.com>
In-Reply-To: <147491684980.4980.3899605336197818600.idtracker@ietfa.amsl.com>
Date: Mon, 26 Sep 2016 18:21:15 -0400
Message-ID: <140001d21844$530ba300$f922e900$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_1401_01D21822.CBFA7830"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIlYbPQnl/E5iNi+W2icSZx5lluHJ/luMuQ
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/kbaMo60u_u0h7VFzugkPwTEW4r4>
Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-11: (with DISCUSS and COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 22:24:33 -0000
Alissa: Thank you for taking time to make further comments. You caught 6 things I'd missed. I've submitted a version 12 to resolve all these issues. I've attached pdf with the differences. Please let me know if you find anything else. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: Monday, September 26, 2016 3:07 PM To: The IESG Cc: jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-11: (with DISCUSS and COMMENT) Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-11: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requireme nts/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for resolving my previous DISCUSS point. I have just one further point that hopefully will be easy to fix: Section 3.2 trails off in mid-sentence. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- #1 >= Section 1 = > >The abstract talks about multi-headed writes but Section 1 talks about multi-headed reads -- I'm assuming these are supposed to be aligned. [Sue]: Good catch. It is multi-headed writes in both cases. #2 Section 3.1 = > >"I2RS also requires a secure transport protocol and key distribution > protocols." > >This is the first sentence of the section -- what does the "also" refer to? [Sue]: Good catch. I've removed the also. #3) "The following protocols will need to be extended to provide confidentiality, data integrity, peer authentication, and key distribution protocols: SSH, SCTP, or the ForCES TML layer over SCTP." >I'm a little confused by the implications of "will need to be extended." >Is this document proposing that they be extended? Or is the idea that if any of these protocols is chosen as a transport for I2RS, they would need to >be extended to meet the I2RS security requirements? Also, note the existence of draft-ietf-tsvwg-sctp-dtls-encaps-09. Answer: Good catch. I left out a protocol name. The two protocols are IPFIX and ForCES TML Layer. Both will need extensions to run over a secure transport (TLS or DTLS). Here's the new text: The following protocols will need to be extended to provide confidentiality, data integrity, peer authentication, and key distribution protocols: IPFIX (over SCTP, TCP or UDP) and ForCES TML layer (over SCTP). These protocols will need extensions to run over a secure transport (TLS or DTLS) (see section 3.3 for details). #4 = Section 3.2 = >"The last new security feature is the ability to allow non- > confidential data to be transfered over a non-secure transport." > >How is this a security feature? (smile) New: The last new feature related to I2RS security is the ability to allow non-confidential data to be transferred over a non-secure transport. #5 >= Section 3.3 = > >I'm not sure what "options described above" is referring to. Thank you for letting me know. I've included the details on the extensions for DTLS in the text. [replay protection and anti-DoS stateless cookie mechanism]. #6 = Section 4 = >"Data passed over the insecure > transport channel MUST not contain any data which identifies a person > or any "write" transactions." > >Assuming this should say "MUST NOT". Thank you for catching this point. _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
- [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs… Alissa Cooper
- Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-… Susan Hares