Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT)
Susan Hares <susaha1@mail.regent.edu> Wed, 17 August 2016 23:45 UTC
Return-Path: <susaha1@mail.regent.edu>
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 5C49A12D81B for <i2rs@ietfa.amsl.com>; Wed, 17 Aug 2016 16:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-regent-edu.20150623.gappssmtp.com
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 i_ohplkx5q6q for <i2rs@ietfa.amsl.com>; Wed, 17 Aug 2016 16:45:48 -0700 (PDT)
Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 1E67112D58D for <i2rs@ietf.org>; Wed, 17 Aug 2016 16:45:45 -0700 (PDT)
Received: by mail-wm0-x244.google.com with SMTP id q128so1780810wma.1 for <i2rs@ietf.org>; Wed, 17 Aug 2016 16:45:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-regent-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=ngWYbaYXQ64L5Pq4Xt9y6DCIJaK8Knm6XMOVPLpwrY4=; b=KEt2HdofaZLDkTFLaNkwBG/p1KDtm+9qrmnFaZKWhCfvv87gnu2zX+IAj3cUqHUpZk V3ngN/qroIrSCrffCaBBSVLWINRt4exYKk0aCRctVe3luTetWSTjTlcANYH0wzOarrqa xz8QTei8LOpZhRUD2wNeyF1EJ5QLeHs9RPiUs+fNufEMKpKrQOHmSc3LO7HkBp/piS7y +HQMGtZ99JxVL8kx6a1+blD8KrSVLfaDmuBhwTvK2jygwIlPKnfB+hP534JKzxzcICNc tSctBxHXb/RIoKNBdhRKyppR0Q0m4PyE++9mZy57gPQLagAC7q8LlLzesm9phJhqtohr 1XXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ngWYbaYXQ64L5Pq4Xt9y6DCIJaK8Knm6XMOVPLpwrY4=; b=JMRSZuzlmsKj8FAzN93UNonrr0icFDyXxr5ap+C0WN+vWOw//NrBiOKe57Mq6KK0BT Tb9mT6QaYETiKnCqDUSsbZwYd8lHbnoZEoB/VbUcgzvOSqrPuqXTXB6dDwjlc0yJ3PKW zxy3UzCEEzc3iKXjasWTnu6cHQzfDlQWD36sdY8+c30PYHC7EJAbAIzkbPMETGIUwpxZ lP9xjEY8L+6a+LLIxVq7RhdWoUJZ5jbcMOUsthqR9zLgGRqm/+FJvfW/+wf9vNMcRETp T6Sb513QmfJ7XPmVUnZNZdY07AZ0j/4/WFqSy4q4u/KWevRJrW7q8n6jvilOtOatENc9 Koug==
X-Gm-Message-State: AEkoousE7sl3lnvv+nDTTzkCbatRBIu6PPi1iYCmnTZRMBA4IemSXCIi/kI9M3A7TIlO9ByGXGIUyOwpV1aKkpA5
X-Received: by 10.28.18.11 with SMTP id 11mr28471692wms.11.1471477543414; Wed, 17 Aug 2016 16:45:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.66.102 with HTTP; Wed, 17 Aug 2016 16:45:42 -0700 (PDT)
From: Susan Hares <susaha1@mail.regent.edu>
Date: Wed, 17 Aug 2016 19:45:42 -0400
Message-ID: <CAMzKBaKCWTn-dMfg5Gn9xqxaXmrgPrbhF9F3Y78WqSsmR87FDA@mail.gmail.com>
To: Alia Atlas <akatlas@gmail.com>, Alissa Cooper <alissa@cooperw.in>
Content-Type: multipart/alternative; boundary="001a11469722454591053a4d108e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/1MTTpKcOTDB-Y2aLjUKANCzhBiU>
X-Mailman-Approved-At: Wed, 17 Aug 2016 16:57:31 -0700
Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, iesg@ietf.org, jhass@pfrc.org, Susan Hares <shares@ndzh.com>, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (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: Wed, 17 Aug 2016 23:45:50 -0000
Alissa: In storms in the mid-west have knock out power and connectivity to my mailer. It is up/down - so I am sending the response to you via my secondary mail address at my school. Please acknowledge when you receive this email, and send On the DISCUSS: Operators indicated that there are events which they will want to send publically. One example of such an event is the route establishment/loss (such as the routes available to http://www.routeviews.org/ or looking glass sites). This data is specific route information that is publically known. Right now this information requires a BGP connection, or data from a BGP connection. In the future, it would simply require an I2RS client to have a connection to an I2RS agent. Insecure I2RS Client=======I2RS Agent This data can also be distributed in tiers – where a massive amount of clients connect to an I2RS agent which draws its information in a proxy mode: Insecure Proxy-model secure I2RS client-1========= I2RS Agent /I2RS client ----------------------- I2RS Agent I2RS client-2===========| Alissa - does this provide you enough information to resolve your discuss? ===================== On your comments: *section 2.1:* The addition of privacy was suggested by our QA sec-dir reviewer who made the point that privacy was not always equivalent to confidentiality. The suggestion was to clearly specify our use of privacy. If you, Kathleen, and Stephen have a suggestion for alternate language or to drop the privacy language. RFC6793 - BGP Support for Four-Octet Autonomous System (AS) Number Space. Therefore, you must mean a different RFC. Please provide this example. *Section 2.2: * == Section 2.2 == "The I2RS protocol exists as a higher-level protocol which may combine other protocols (NETCONF, RESTCONF, IPFIX and others) within a specific I2RS client-agent relationship with a specific trust for ephemeral configurations, event, tracing, actions, and data flow interactions." Reading the provided definition of "trust," I'm not sure what "with a specific trust for" means in the sentence above. *Sue: *The ephemeral state requires that the I2RS Client-Agent operate with default level of security (default secure transport) that IPFIX does not require. The I2RS client-I2RS Agent must provide mutual authentication. We summarized this as "specific trust". Do you have an alternate text? 2) definition of secondary identity "The I2RS architecture document [I-D.ietf-i2rs-architecture] defines a secondary identity as the entity of some non-I2RS entity (e.g. application) which has requested a particular I2RS client perform an operation." Per my comment above, I would suggest just referencing the definition from the architecture document. The text above is circular ("the entity of some ... entity") and conflates an identity with an identifier. Sue: We had comments from NETCONF that suggested adding this definition to make the requirements more user friendly. If this is a blocking comment, we will remove it. Otherwise the text will be changed to: "The I2RS architecture document [RFC7921]. Please note that the secondary identity specifies a non-I2RS entity (e.g. application) that has requested a particular I2RS client perform an operation." I look forward to your feedback on this new text. == Section 3.1 == Agree with Mirja that this section is superfluous. Sue: While this is rational idea, it was not superfluous during the discussion with NETCONF. Without this section, I2RS and NETCONF ran into miscommunication. Therefore, since this section clarified things for the creation of the I2RS protocol as additions to NETCONF/RESTCONF - unless this becomes a blocking comment - it will stay. == Section 3.3 == 3.3 <https://tools.ietf.org/html/draft-ietf-i2rs-protocol-security-requirements-07#section-3.3>. Data Confidentiality Requirements SEC-REQ-13: In a critical infrastructure, certain data within routing elements is sensitive and read/write operations on such data SHOULD be controlled in order to protect its confidentiality. Sue: If you do not use SHOULD, the document contradicts itself regarding insecure transport protocol. If you suggestions that handle both, please suggest text. 3.5 Is the omission of normative language from Sec-REQ-20 purposeful? Sec-REQ-20: If an I2RS agents or an I2RS client is tightly correlated with a person, then the I2RS protocol and data models should provide additional security that protects the person's privacy. SHOULD is normative whether caps or lower case. Did you want this to go a SHOULD? I've capitalized it in version-08. If you want it to go to a MUST, please just let me know why. Thank you for your comments, Sue
- Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-… Susan Hares
- Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-… Susan Hares
- Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-… Kathleen Moriarty
- Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-… Kathleen Moriarty
- Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-… Susan Hares
- Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-… Susan Hares
- Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-… stephen.farrell
- Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-… Alia Atlas
- [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs… Alissa Cooper