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

[Andy Bierman <[e-mail]>]

Hi,

I guess we disagree on how easy it will be for the IETF to
decide all instances of certain objects can be read using
nonsecure protocols.  This seems like a log of effort for
something the operator should be deciding anyway.


Andy




On Thu, Aug 18, 2016 at 1:05 PM, Susan Hares <[e-mail]> wrote:

> Andy:
>
>
>
> If we create a yang data model that is insecure, and mount on another data
> model – does it have the same issue as module augmentation?   Of course, we
> could create a mount point for all insecure data modules, and all data
> placed under that mount point – would be insecure.
>
>
>
> For the BGP route-views use case, this would make it clear that data had
> to be transformed to be insecure transmission.
>
>
>
> Sue
>
>
>
> *From:* Andy Bierman [mailto:[e-mail]]
> *Sent:* Thursday, August 18, 2016 4:02 PM
> *To:* Susan Hares
> *Cc:* Alissa Cooper; Joel Halpern; [e-mail]; Juergen Schoenwaelder;
> [e-mail]; Kathleen Moriarty; IESG; Jeffrey Haas;
> [e-mail]
> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <[e-mail]> wrote:
>
> Andy:
>
>
>
> Thank you – I thought it was on whether we could implement insecure
> transport in a Yang module.
>
>
>
> The requirement text you are working with is:
>
>
>
>    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.
>
>
>
> I do not understand why approving the ok for non-secure transport for some
> modules means the following to you:
>
>
>
> *“ the IETF needs to agree that there could never possibly be any
> deployment that would not want to allow exposure of the data.*
>
> *Not now. Not 20 years from now.”*
>
>
>
>
>
>
>
> As I understand it, this requirement has another requirement associated
> with it
>
> that says the data has to be identified as OK-for-nonsecure-transport.
>
>
>
> An extension in the data model says that all instances of the object in
>
> all possible deployments cannot be considered sensistive and therefore
>
> needs disclosure protection.
>
>
>
> It may seem like even a simple octet counter is safe to send in the clear,
>
> but not if that opens up correlation attacks.  (e.g., I can send data to
> some
>
> host.  I can see that index 455992 is incrementing the in-octets counters
>
> in a way that strongly correlates to my test traffic.  Therefore I can
> learn
>
> that arbitrary index 455992 is really John Doe or really suite #14, etc.
>
>
>
>
>
> I had thought that the security-directorate and other reviewers would look
> at each module that is insecure, and  consider whether it was reasonable
> for the use case at this time.   This is what I understood from Russ
> Housley’s first review of this technology.  Since like you, I believe the
> operator is going to  configure what modules are allowed on systems.   I
> agree that this requirement provides a full scope of the work, but
> implementers will require network operators to configure these features on.
>
>
>
> Sue
>
>
>
> Andy
>
>
>
>
>
>
>
> *From:* Andy Bierman [mailto:[e-mail]]
> *Sent:* Thursday, August 18, 2016 2:53 PM
> *To:* Susan Hares
> *Cc:* Alissa Cooper; Joel Halpern; [e-mail]; Juergen Schoenwaelder;
> [e-mail]; Kathleen Moriarty; IESG; Jeffrey Haas;
> [e-mail]
> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
>
>
> Hi,
>
>
>
> I did not think Juergen's comment was about running code.
>
>
>
> In order for a data node to get the "ok-for-nonsecure-transports" approval
>
> in an IETF module, the IETF needs to agree that there could never possibly
> be
>
> any deployment that would not want to allow exposure of the data.
>
> Not now. Not 20 years from now.
>
>
>
> I can see a vendor making that decision for their own proprietary modules,
>
> but it seems less likely for standard modules.
>
>
>
> Seems like the operator is going to have to configure what is allowed
>
> for nonsecure transport anyway, so just let them decide.
>
> I don't really object to the extension or the requirement.
>
> It doesn't help much but it doesn't hurt much either.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares <[e-mail]> 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
>
>
>
>
>