Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT)

[Susan Hares <[e-mail]>]

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