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
