Andy:
I have been thinking about your question for 30 minutes. Let me put down a
few of my personal opinions:
1) Most (99%) of the ephemeral data models will not allow non-secure
transport.
2) If any ephemeral data models have an insecure section, the review and
consensus for a standards model should take longer.
I hope we can streamline the normal Yang model review. [It would be nice to
streamline features additions for NETCONF/RESTCONF as well].
3) I prefer to have the non-secure sections of a data model moved to a
separate date model, and the data model marked as insecure.
[I do not know if we could use the library function to mark the data model in
meta-language.]
However, until we complete the mount schema work – I do not know if this is
workable.
Would it help if I changed version -08 to
Old/
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. /
New:/
A non-secure transport can be used for publishing telemetry data or other
Operational state that was specifically indicated to be non-confidential
in the data model.
/
Sue
From: i2rs [mailto:[email protected]] On Behalf Of Susan Hares
Sent: Friday, August 19, 2016 10:59 AM
To: 'Andy Bierman'; 'Lou Berger'
Cc: [email protected]; 'Alissa Cooper'; 'Juergen Schoenwaelder';
[email protected]; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel
Halpern'; [email protected]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)
Andy:
Thank you for your comments. Perhaps you can provide for the IESG the list of
things that are needed to move a Yang module forward in the IETF.
Sue
From: Andy Bierman [mailto:[email protected]]
Sent: Friday, August 19, 2016 10:24 AM
To: Lou Berger
Cc: Susan Hares; Juergen Schoenwaelder; [email protected]; Alissa Cooper;
[email protected]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern;
[email protected]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)
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 <[email protected]> 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:[email protected]]
> Sent: Friday, August 19, 2016 7:34 AM
> To: Susan Hares; 'Juergen Schoenwaelder'
> Cc: [email protected]; 'Alissa Cooper'; [email protected]; 'Kathleen
> Moriarty'; 'IESG'; [email protected]; 'Joel Halpern';
> [email protected]
> 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:[email protected]]
>> Sent: Friday, August 19, 2016 4:58 AM
>> To: Susan Hares
>> Cc: 'Alissa Cooper'; 'Joel Halpern'; [email protected];
>> [email protected]; 'Kathleen Moriarty'; 'IESG'; [email protected];
>> [email protected]
>> 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:[email protected]]
>>> Sent: Thursday, August 18, 2016 12:54 PM
>>> To: Joel Halpern
>>> Cc: Susan Hares; Juergen Schoenwaelder; [email protected];
>>> [email protected]; Kathleen Moriarty; IESG; [email protected];
>>> [email protected]
>>> 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 <[email protected]>
>>>>> 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:[email protected]]
>>>> Sent: Thursday, August 18, 2016 9:17 AM
>>>> To: 'Juergen Schoenwaelder' <[email protected]>
>>>> Cc: [email protected]; [email protected]; 'Kathleen Moriarty'
>>>> <[email protected]>; 'The IESG' <[email protected]>;
>>>> [email protected];
>>>> [email protected]
>>>> 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:[email protected]]
>>>> Sent: Thursday, August 18, 2016 9:06 AM
>>>> To: Susan Hares
>>>> Cc: [email protected]; [email protected]; 'Kathleen Moriarty'; 'The
>>>> IESG'; [email protected];
>>>> [email protected]
>>>> 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:[email protected]] On Behalf Of Juergen
>>>>> Schoenwaelder
>>>>> Sent: Thursday, August 18, 2016 8:14 AM
>>>>> To: Susan Hares
>>>>> Cc: [email protected]; [email protected]; 'Kathleen Moriarty'; 'The
>>>>> IESG'; [email protected];
>>>>> [email protected]
>>>>> 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:[email protected]]
>>>>>> Sent: Thursday, August 18, 2016 3:32 AM
>>>>>> To: Susan Hares
>>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; [email protected];
>>>>>> [email protected]; [email protected];
>>>>>> [email protected]
>>>>>> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>>>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>>>>>>
>>>>>> _______________________________________________
>>>>>> i2rs mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>>> --
>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH
>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>>>>>
>>>>> _______________________________________________
>>>>> i2rs mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>>>
>>>> --
>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>>>>
>
>
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
