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