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

[Andy Bierman <[e-mail]>]

Hi,

I agree with Juergen.
There are already too many details that need consensus to move
a YANG module forward in the IETF.  It takes too long already.

We could have been tagging MIB objects all along, but we don't.
Imagine if there was a debate for every single OBJECT-TYPE macro
"is this leaf OK for noAuth/noPriv?"

Are there even clear SEC-DIR guidelines on how one would decide this
debate in a WG? Does SEC-DIR really want to be flooded with review
requests so they become a bottleneck in YANG RFC publication process?

Standardized insecure access is a big change from what we have done
for 30 years.  There could be a good reason why we left this out of scope
all this time.


Andy


On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger <[e-mail]> wrote:

>
> Sue,
>
> My message said three things:
>
> 1) Juergen's comment resonates with me.
>
> 2) I think the current text is acceptable.
>
> 3) I see changing the SHOULD to a MUST as problematic.
> I understood one of the other messages on this thread proposing this
> change which is what triggered my message.   If I misunderstood that
> message, feel free to interpret my message as supporting the current
> text in question.
>
> Note that I am only speaking for myself (including in my role as NETMOD
> co-chair) and not representing the consensus opinion of any WG.
>
> Lou
> On 8/19/2016 8:07 AM, Susan Hares wrote:
> > Lou:
> >
> > I am clear that Juergen does not want not want to place transport
> requirements within the data model for NETMOD.  His opinion was considered
> in the rough for the I2RS WG. If this requirement is a problem for
> NETCONF/NETMOD,  the text currently says:
> >
> > REQ-SEC-09 states:
> >
> >   The default mode of transport is secure so data models SHOULD clearly
> annotate what data nodes can be
> >    passed over an insecure connection.
> >
> > However, if this means the NETCONF/NETMOD WG will not even entertain
> proposal for marking the insecure functions in yang text -- then the two WG
> (I2RS/NETMOD) have a problem and should stop this standardization process
> going forward.
> >
> > Sue
> >
> >
> > -----Original Message-----
> > From: Lou Berger [mailto:[e-mail]]
> > Sent: Friday, August 19, 2016 7:34 AM
> > To: Susan Hares; 'Juergen Schoenwaelder'
> > Cc: [e-mail]; 'Alissa Cooper'; [e-mail]; 'Kathleen
> Moriarty'; 'IESG'; [e-mail]; 'Joel Halpern';
> [e-mail]
> > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
> >
> > Sue,
> >
> >     I don't see Juergen as arguing against model access via non-secure
> transport. I read his point as that the transport security requirements
> don't belong scattered within a data model.
> >
> > I have to say that from a model complexity (definition, process, review,
> implementation - take your pick) , language and NETMOD co-chair
> perspective, his comment resonates with me.
> >
> > I think this makes the key text:
> >
> >    The default mode of transport is
> >    secure so data models SHOULD clearly annotate what data nodes can be
> >    passed over an insecure connection.
> >
> >
> > As this isn't a MUST, I personally think we can live with the text and
> we can debate the issue further in the context of specific solutions.  I
> would strongly object to this being changed to a MUST, or if the document
> is changed to make transport (security) requirements identified within data
> models a requirement.
> >
> > Lou
> >
> > On 8/19/2016 6:49 AM, Susan Hares wrote:
> >> Juergen:
> >>
> >> You have laid out the two options:   a) link the data-model to the
> non-secure transport, and b) do not link the data to the non-secure
> transport.   I agree with you that past models did not link past SNMP MIB
> data model to the transport.  Existing NETCONF models do not link it to the
> transport.   As you have indicated, you disagreed in the I2RS WG and we
> found consensus was to include the non-secure transport.
> >>
> >> I2RS was created to build things as an interface to the routing
> environment.   The operators clearly informed the I2RS group of this need
> during the requirement setting phase prior to the time I was chair.  The
> reason I continue to press for this capability is their input, and the
> existing use cases I listed previously in this mail:
> >>
> >> a) public information - BGP route views,
> >> b) specific well know up events - such as public-web site up
> >> c) specific network service events - interface to particular public LAN
> up.
> >>
> >> As you know, we do not have any I2RS data models that specify this
> feature at this time.   I suspect after we get through this lengthy
> requirement phase, the operators may begin to specify new models that have
> this feature.
> >>
> >> Sue
> >>
> >> -----Original Message-----
> >> From: Juergen Schoenwaelder
> >> [mailto:[e-mail]]
> >> Sent: Friday, August 19, 2016 4:58 AM
> >> To: Susan Hares
> >> Cc: 'Alissa Cooper'; 'Joel Halpern'; [e-mail];
> >> [e-mail]; 'Kathleen Moriarty'; 'IESG'; [e-mail];
> >> [e-mail]
> >> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> >> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> >> COMMENT)
> >>
> >> I repeat my technical argument: While there may be deployments where
> non-secure transports may be reasonable to use, defining these situations
> statically as part of data model schemas does not follow established
> practices. The IETF has a long tradition of standardizing data models that
> can be used in a variety of operational contexts and I do not see reasons
> why we should move away from that basic approach.
> >>
> >> /js
> >>
> >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote:
> >>> Alissa:
> >>>
> >>> Just a little input you may not know.  My background is 15 years
> (1995-2010)  developing a routing/switching platform (denoted as GateD)
> which was sold to over 200 companies.   We developed XML and a binary XML
> based product that configured this product.  It could do 100K configuration
> lines and reboot in less than a second on most hardware.  We also provide
> status messages in secure streams and non-secure streams.    I sold early
> version of this code to companies that Alia has worked for  - so she has
> personal viewed the code.   At the height of our work, our development team
> ran to 50 people which I directed (First as VP of Engineering, and then as
> CTO). It is due to this level of experience that Alia selected me for the
> co-chair.   Russ White has understood Cisco's process, and has also
> directed software development teams for routing.
> >>>
> >>> In order to freshen my direct experience with I2RS on open source
> work, I am working on a publically available work in Quagga based on the
> confD product suggested by Cisco.
> >>>
> >>> In contrast, Juergen is a university professor who has worked on
> proto-types.   He is not working on an implementation.   I hope he will.
> >>>
> >>> I hope you will consider this background in my response to your
> comments below.
> >>>
> >>> Sue
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Alissa Cooper [mailto:[e-mail]]
> >>> Sent: Thursday, August 18, 2016 12:54 PM
> >>> To: Joel Halpern
> >>> Cc: Susan Hares; Juergen Schoenwaelder; [e-mail];
> >>> [e-mail]; Kathleen Moriarty; IESG; [e-mail];
> >>> [e-mail]
> >>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> >>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> >>> COMMENT)
> >>>
> >>> Jumping in here because this is relevant to my DISCUSS, hope nobody
> minds (but if you do, I can go back to the other thread).
> >>>
> >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern <
> [e-mail]> wrote:
> >>>>>
> >>>>> Let me try a different take approach to this particular question.
> >>>>>
> >>>>> Let me start by putting aside the question of where things are
> marked, and come back to that afterwards.
> >>>>>
> >>>>> There are a number of cases that I2RS has been asked to cover of
> high rate telemetry data.  This may be BGP update information, it may be
> frequent information about line card activity.  There are other cases, some
> of which have been documented.
> >>>>>
> >>>>> While not completely insensitive, the operators have made clear that
> they see protecting this data as unnecessary.  While I would hope over time
> to move to a domain where all of it is protect, that is not trivial.  As
> the I2RS Architecture points out, it is expected that what we describe as a
> single I2RS >communication between a client and agent is actually
> associated with multiple channels of communication.
> >>>>>
> >>>>> Now, if you want to say that the I2RS protocol requirements cannot
> allow for unprotected channels, I guess we have disconnect between the IESG
> and the WG.
> >>>>>
> >>>>> If we say that we can allow for unprotected channels, we then get to
> the question of which data can be sent over such channels.  While
> architecturally I agree with Juergen that the model is a bad place to
> specify it, the obverse is also true.  Not having some limits on what can
> be sent unprotected >causes concern about insufficient protection.  If I
> recall correctly, earlier security reviews called us to task for being too
> broad in what we allowed.
> >>>>>
> >>>>> So, if the IESG wants us to just allow it anywhere, because the
> >>>>> model is an awkward place to define the limitation, I can live with
> that.  What I can't live with is being told both that the model is a bad
> place to define it and that there must be restrictions on what is sent
> unprotected, without any proposal on how we are to move forward.
> >>>> Thank you Joel, this explanation helps me a lot. I think there is a
> disconnect about how the restrictions are expressed. From reading the email
> traffic about this document, it strikes me that trying to express the
> restrictions programmatically doesn’t make much sense in this case.
> >>>> I agree with Juergen that it will be challenging to make a judgment a
> priori in order to bake a restriction into a data model, because data that
> is considered sensitive enough to warrant a secure transport in one
> deployment may not be considered sensitive in another deployment.
> >>>> So for any data elements where there is any question at all about
> >>>> whether they might be sensitive (i.e., any data elements that are not
> already routinely made public), I would expect data model authors to end up
> indicating that they may be sent over either secure or insecure transport,
> which renders the indication not useful.
> >>>> Perhaps it would make more sense then to just enumerate in the text
> the cases that motivate the inclusion of protocol support for insecure
> transport:
> >>>>
> >>>> 1. For conveyance of information that is already routinely made
> public.
> >>>> 2. For line card activity data where there is no likely upgrade path
> to support secure transports in the foreseeable future.
> >>>>
> >>>> Then the normative requirements would be on clients and agents to use
> secure transports unless those clients and agents are deployed where either
> of the operational circumstances above necessitate otherwise.
> >>>> Alissa
> >>> Point 1:
> >>> I disagree with Juergen on the difficulty in specifying the sections
> of the yang modules.  I have provided a suggested solution in:
> >>> https://tools.ietf.org/html/draft-hares-i2rs-protocol-
> strawman-03#section-4.5.2.
> >>>
> >>> Given the mount schema functionality, we can mount ephemeral state
> module which augment non-ephemeral state modules which are "in-secure only".
> >>>
> >>> Point 2:
> >>> I am willing to put an enumeration of the use cases in the protocol
> requirement, but I would like to understand the purpose for the
> enumeration.   We are not doing a use case, but a requirements document.
> This information appears to be a "use case" rather than a technical
> description.   What purpose are you looking for this enumeration to
> server.  Are you looking for the enumeration in SEC-REQ-08?
> >>>
> >>> Point 3: Could you review -08.txt on this topic, especially the text
> below.  Given your comments, I believe I should change the last line to a
> MUST.
> >>> New/   The default mode of transport is
> >>>    secure so data models MUST clearly annotate what data nodes can be
> >>>    passed over an insecure connection.
> >>> /
> >>>
> >>> Sue
> >>>
> >>> ===================
> >>> As to the normative requirements (-08.txt) version:
> >>>
> >>> Section 3:
> >>>
> >>>    I2RS allows the use of an insecure transport for portions of data
> >>>    models that clearly indicate the use of an insecure transport.
> >>>    Operators deploying I2RS must determine if they want to populate and
> >>>    deploy the portions of the data model which use insecure transports.
> >>>
> >>> In Section 3.2 in version -08.txt
> >>>
> >>>    SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
> >>>    secure transport and optionally MAY be able to transfer data over a
> >>>    non-secure transport.  A secure transport MUST provide data
> >>>    confidentiality, data integrity, and replay prevention.
> >>>
> >>>    The default I2RS transport is a secure transport.
> >>>
> >>>    A non-secure transport can be used for publishing telemetry data or
> >>>    other operational state that was specifically indicated to non-
> >>>    confidential in the data model in the Yang syntax.
> >>>
> >>>    The configuration of ephemeral data in the I2RS Agent by the I2RS
> >>>    client SHOULD be done over a secure transport.  It is anticipated
> >>>    that the passing of most I2RS ephemeral state operational status
> >>>    SHOULD be done over a secure transport.  As
> >>>    [I-D.ietf-i2rs-ephemeral-state] notes,  a data model MUST indicate
> >>>    whether the transport exchanging the data between I2RS client and
> >>>    I2RS agent is secure or insecure.
> >>>
> >>>    The default mode of transport is
> >>>    secure so data models SHOULD clearly annotate what data nodes can be
> >>>    passed over an insecure connection.
> >>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>> -----Original Message-----
> >>>> From: Susan Hares [mailto:[e-mail]]
> >>>> Sent: Thursday, August 18, 2016 9:17 AM
> >>>> To: 'Juergen Schoenwaelder' <[e-mail]>
> >>>> Cc: [e-mail]; [e-mail]; 'Kathleen Moriarty'
> >>>> <[e-mail]>; 'The IESG' <[e-mail]>;
> >>>> [e-mail];
> >>>> [e-mail]
> >>>> Subject: RE: [i2rs] Kathleen Moriarty's Discuss on
> >>>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> >>>> COMMENT)
> >>>>
> >>>> Juergen and Kathleen:
> >>>>
> >>>> Let me proceed with two examples: BGP route views data model and the
> event for the web-service data.
> >>>>
> >>>> The content of these data models are designated as exposed to
> public.  The routing system only populates the proposed BGP route views
> data model with the data destined for the BGP looking glass.  The policy on
> the routing system indicates what information gets transferred.  The data
> model is completely available to the public.  The Yang Doctors are going to
> review this by seeing the whole model is public and available via
> non-secure means.
> >>>> The security people are going to review this seeing that the whole
> model is public, and available via an unprotect means.  The fact the data
> model is all public should simplify the review.
> >>>>
> >>>> An event from the I2RS RIB that a web-service route is up is the
> second case.  The I2RS RIB has an event based on policy that indicates a
> web-service route is up.  The yang-1.1 doctors must review the content of
> the event text to see it does not break privacy or provide too much
> >>>> information   The event mechanisms will need to work over secure
> transport
> >>>> and insecure transport.  Most of the data will go over the secure
> transport event stream. However, a small amount of information may go over
> the insecure transport stream.
> >>>>
> >>>> First, let me know if my use cases are understandable.  Second, let
> me know if you disagree with this use cases.
> >>>>
> >>>> Fyi -  IESG approved the architecture with the insecure stream.
> >>>>
> >>>> Sue
> >>>>
> >>>> -----Original Message-----
> >>>> From: Juergen Schoenwaelder
> >>>> [mailto:[e-mail]]
> >>>> Sent: Thursday, August 18, 2016 9:06 AM
> >>>> To: Susan Hares
> >>>> Cc: [e-mail]; [e-mail]; 'Kathleen Moriarty'; 'The
> >>>> IESG'; [e-mail];
> >>>> [e-mail]
> >>>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> >>>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> >>>> COMMENT)
> >>>>
> >>>> I just do not know on which basis a data model writer can decide
> whether a data object can be exposed in an unprotected way. How are YANG
> doctors going to review this? How are security directorate people going to
> judge this? But as promised, I leave (still puzzled) now.
> >>>>
> >>>> /js
> >>>>
> >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote:
> >>>>> Juergen:
> >>>>>
> >>>>> Yes, we seem to disagree on the value of making it hardwired in the
> model.
> >>>>> For me, the value is a common understanding of deployment
> >>>>> distribution
> >>>> such
> >>>>> as the route-views.   Since the operators argued strongly for this
> point,
> >>>> I
> >>>>> think the best idea is to get it working in code and then see if
> >>>>> the deployment matches the requests.
> >>>>>
> >>>>> Sue
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: i2rs [mailto:[e-mail]] On Behalf Of Juergen
> >>>>> Schoenwaelder
> >>>>> Sent: Thursday, August 18, 2016 8:14 AM
> >>>>> To: Susan Hares
> >>>>> Cc: [e-mail]; [e-mail]; 'Kathleen Moriarty'; 'The
> >>>>> IESG'; [e-mail];
> >>>>> [e-mail]
> >>>>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> >>>>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS
> >>>>> and
> >>>>> COMMENT)
> >>>>>
> >>>>> Sue,
> >>>>>
> >>>>> I still do not see why the 'mode of exposure' of data benefits from
> >>>>> being hard-wired in the data model. For me, it is a situational and
> >>>>> deployment specific question. But I shut up here since I aired this
> >>>>> concern before (and we simply seem to disagree).
> >>>>>
> >>>>> /js
> >>>>>
> >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote:
> >>>>>> Juergen:
> >>>>>>
> >>>>>> My example is the looking glass servers for the BGP route views
> >>>>>> project
> >>>>>> (http://www.routeviews.org/) or a route indicating the presence of
> a
> >>>>>> web-server that is public.   For the BGP I2RS route, a yang model
> could
> >>>>>> replace the looking glass function, and provide events for these
> looking
> >>>>>> glass functions.    For the web-server route,  an event be sent when
> >>>> that
> >>>>>> one route is added.
> >>>>>>
> >>>>>> Sue
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Juergen Schoenwaelder
> >>>>>> [mailto:[e-mail]]
> >>>>>> Sent: Thursday, August 18, 2016 3:32 AM
> >>>>>> To: Susan Hares
> >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; [e-mail];
> >>>>>> [e-mail]; [e-mail];
> >>>>>> [e-mail]
> >>>>>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> >>>>>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS
> >>>>>> and
> >>>>>> COMMENT)
> >>>>>>
> >>>>>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote:
> >>>>>>> -----------------------------------------------------------------
> >>>>>>> -
> >>>>>>> --
> >>>>>>> --
> >>>>>>> COMMENT:
> >>>>>>> -----------------------------------------------------------------
> >>>>>>> -
> >>>>>>> --
> >>>>>>> --
> >>>>>>>
> >>>>>>>> Section 3:
> >>>>>>>> Can you clarify the second to last sentence?  Do you mean there
> >>>>>>>> are
> >>>>>> sections that indicate an insecure transport should be used?
> >>>>>>>>  I2RS allows the use of an
> >>>>>>>> insecure transport for portions of data models that clearly
> >>>>>>>> indicate  insecure transport.
> >>>>>>>> Perhaps:
> >>>>>>>> I2RS allows the use of an
> >>>>>>>> insecure transport for portions of data models that clearly
> >>>>>>>> indicate the use of an  insecure transport.
> >>>>>> I still wonder how a data model writer can reasonably decide
> >>>>>> whether a piece of information can be shipped safely over an
> >>>>>> insecure transport since this decision often depends on the
> >>>>>> specifics of a deployment
> >>>>> situation.
> >>>>>> /js
> >>>>>>
> >>>>>> PS: I hope we do not end up with defining data multiple times (once
> >>>>>>    for insecure transport and once for secured transports).
> >>>>>>
> >>>>>> --
> >>>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>>>>> Phone: [phone]         Campus Ring 1 | 28759 Bremen |
> Germany
> >>>>>> Fax:   [phone]         <http://www.jacobs-university.de/>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> i2rs mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/i2rs
> >>>>> --
> >>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>>>> Phone: [phone]         Campus Ring 1 | 28759 Bremen |
> Germany
> >>>>> Fax:   [phone]         <http://www.jacobs-university.de/>
> >>>>>
> >>>>> _______________________________________________
> >>>>> i2rs mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/i2rs
> >>>>>
> >>>> --
> >>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >>>> Fax:   [phone]         <http://www.jacobs-university.de/>
> >>>>
> >
> >
> >
>
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>