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

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 17 Aug 2016 14:35:42 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for your work on this draft.  There may be some overlap in points,
I tried to minimize them...
----
Section 3.1:

I don't see any actual requirements for mutual authentication in this
section, just requirements for identifiers.  Did I miss something?

Are all mutual auth schemes in scope?  Are there any considerations for
mutual authentication (passwords, keys, etc.)?
----
I share the same concern as others for secure transport, but since there
are already discusses on that, I have one comment to add to the existing
discusses below.

----------------------------------------------------------------------
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.
----
Section 3.2
I agree with Alissa's discuss point on the following sentence (that could
also be reworded a bit):
   A non-secure transport can be 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.
----
Section 3.4: In the following text:
   SEC-REQ-15: The integrity that the message data is not repeated means
   that I2RS client to I2RS agent transport SHOULD protect against
   replay attack

I'm not sure why this just doesn't say:
   SEC-REQ-15: I2RS client to I2RS agent transport SHOULD protect
against
   replay attack

The additional text doesn't add anything and sounds a bit confusing. 
----
Nit:

I'm not sure these definitions add any value as they seem to restate the
term defined:

   I2RS protocol data integrity

      The transfer of data via the I2RS protocol has the property of
      data integrity described in [RFC4949].

   I2RS component protocols

      Protocols which are combined to create the I2RS protocol.
-----

I also agree that the definitions from 4949 should be removed.

Thank you in advance.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 17 Aug 2016 18:10:37 -0400

In line, I hope answering the questions.
Yours,
Joel

> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/

The second bullet in section 3.1 (Mutual Authentication) is about 
mutually authenticating.  The verbiage was chosen by the more 
security-experienced writer, so the co-authors assumed it was 
sufficient.  If you can suggest better words, we are happy to change it.

> mutual authentication (passwords, keys, etc.)?

I2RS does not have any constraints that we know of on the mutual 
authentication scheme used.  The I2RS protocol may have some constraints 
or assumptions, but this document does not place any such.

> are already discusses on that, I have one comment to add to the existing

The ephemeral state document has wording that has been worked out 
carefully on how much we are mandating about the specificity of allowing 
non-secure transport.  Since this document points there, how specific do 
we need to be here?  (And do folks think that needs to be considered a 
normative reference?  We can do that if needed.)

> The additional text doesn't add anything and sounds a bit confusing.

As per Ben's comments, I think this will get cleaned up.  As you 
observe, it is overly verbose at the moment.

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Aug 2016 21:16:48 -0400

Kathleen: 

Thank you for your comments.  Please see the inline comments below.  I will be uploading a version -08.txt that will resolve some of these comments. 

Sue 

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Wednesday, August 17, 2016 5:36 PM
To: The IESG
Cc: [email-masked]; Jeffrey Haas; [email-masked]; [email-masked]; [email-masked]
Subject: Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Thanks for your work on this draft.  There may be some overlap in points, I tried to minimize them...
----
>Section 3.1:
>
>I don't see any actual requirements for mutual authentication in this section, just requirements for identifiers.  Did I miss something?  

No, there are no additional requirements.  We only have requirements for identifiers.   Do you have a suggestion for improved language. 

> Are all mutual auth schemes in scope?  Are there any considerations for mutual authentication (passwords, keys, etc.)?

All mutual identification schemes are in scope.  Is there a reason we should restrict the mutual authentication schemes to a subset. 

----
>I share the same concern as others for secure transport, but since there are already discusses on that, I have one comment to add to the existing discusses below.

You have a concern regarding the secure transport?  My understanding is that other people had a concern regarding the insecure transport.   I have provide an example of the BGP data feed utilized by http://www.routeviews.org/ project.  

> Section 3: 
> Can you clarify the second to last sentence?  Do you mean there are sections that indicate an insecure transport should be used?

>  insecure transport for portions of data models that clearly indicate the use of an
>  insecure transport.

Changed to :

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.

----
> Section 3.2
> I agree with Alissa's discuss point on the following sentence (that could also be reworded a bit):

I would appreciate a recommended set of text or additional explanation on what you would like to see in rewording. 

----

> SEC-REQ-15: I2RS client to I2RS agent transport SHOULD protect against
 > replay attack

Sue: Is this ok.  It will be changed 
 
----
Nit:

>    data integrity described in [RFC4949].

Deleted 

>    Protocols which are combined to create the I2RS protocol.

Please suggest alternative text for this section. 

-----

> I also agree that the definitions from 4949 should be removed.

These definition have been removed.  I will provide feedback if this removal cause problems in the creation of the protocol.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Aug 2016 09:32:03 +0200

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/>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Aug 2016 08:07:18 -0400

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-masked]] 
Sent: Thursday, August 18, 2016 3:32 AM
To: Susan Hares
Cc: 'Kathleen Moriarty'; 'The IESG'; [email-masked]; [email-masked];
[email-masked];
[email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
COMMENT)

> >  insecure transport for portions of data models that clearly 
> > indicate  insecure transport.
> 
> >  Perhaps:
> >  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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Aug 2016 14:14:05 +0200

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Aug 2016 09:00:14 -0400

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-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, August 18, 2016 8:14 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Kathleen Moriarty'; 'The IESG';
[email-masked]; [email-masked]
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:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
situation.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 18 Aug 2016 09:05:17 -0400

> concern before (and we simply seem to disagree).

I agree with Juergen on this point and the example provided seems to
go in line with his line of reason.  The decision could be made based
on the data by the operator and not the data model.  This is what
typically happens and is more flexible to cover confidentiality and
privacy decisions that do vary by situation.

I'll go back through the other responses to my questions now.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Aug 2016 15:05:55 +0200

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 18 Aug 2016 09:06:01 -0400

> deployment matches the requests.

This sounds like more of an experiment, doesn't it?

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Aug 2016 09:16:44 -0400

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-masked]] 
Sent: Thursday, August 18, 2016 9:06 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Kathleen Moriarty'; 'The IESG';

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:
> Cc: [email-masked]; [email-masked]; 'Kathleen Moriarty'; 'The 
> IESG'; [email-masked]; 
> > > ------------------------------------------------------------------
> > > --
> > > --
> > > COMMENT:
> > > ------------------------------------------------------------------
> > > --
> > > --
> > > 
> > > > Section 3: 
> > 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
> >

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 18 Aug 2016 09:18:18 -0400

Hi Sue,

Thanks for your quick response.  inline

>From your response & Joel's, I see bullet #2 is the only one that
calls out the need for mutual authentication and it just states that
with no additional details.  That is fine, but the subject for section
3.1 should be something more like authentication and identifiers to
represent the content better.

> All mutual identification schemes are in scope.  Is there a reason we should restrict the mutual authentication schemes to a subset.

You don't have to, but the header of the section makes me think this
is going to happen in the section.  Maybe setting a baseline would be
good if possible. Not using passwords - so a secure form of mutual
authentication would be good if the requirements are only high level.

> You have a concern regarding the secure transport?

KM: Yes, the wording that allows for insecure transport.  Same concern
expressed by other ADs.

My understanding is that other people had a concern regarding the
insecure transport.   I have provide an example of the BGP data feed
utilized by http://www.routeviews.org/ project.

KM: Aren't you concerned about the integrity of this data?

I don't agree with the data model setting the transport requirements.
If this is done, it should be an experiment IMO.

> I would appreciate a recommended set of text or additional explanation on what you would like to see in rewording.

I'll have to look through Alissa's discuss, but isn't integrity a
concern if confidentiality and privacy are not?  I'm sure once this
type of text is altered and used to make important decisions, this
will come back to bite us.

> Sue: Is this ok.  It will be changed

Thanks.

> Please suggest alternative text for this section.

I think it is self explanatory.  But if that's just me, leave the definition in.

> These definition have been removed.  I will provide feedback if this removal cause problems in the creation of the protocol.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Aug 2016 09:20:09 -0400

Kathleen: 

Hmm.  If this sounds like an experiment, then all new protocols are an experiment.   

This is a catch-22 - we are setting requirements for a re-use protocol that has not be designed yet.  We are working on prototypes, but these prototypes cannot match the final work until we agree upon a set of requirements for the protocol.   

Sue Hares 

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Thursday, August 18, 2016 9:06 AM
To: Susan Hares
Cc: Juergen Schoenwaelder; [email-masked]; [email-masked]; The IESG; Jeffrey Haas; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Thanks,
Kathleen

>> > -------------------------------------------------------------------
>> > -
>> > --
>> > COMMENT:
>> > -------------------------------------------------------------------
>> > -
>> > --
>> >
>> > > Section 3:

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Aug 2016 09:49:34 -0400

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Thursday, August 18, 2016 9:18 AM
To: Susan Hares
Cc: Jeffrey Haas; [email-masked]; The IESG; [email-masked];

Hi Sue,

On Wed, Aug 17, 2016 at 9:16 PM, Susan Hares <[email-masked]> wrote:
> Kathleen:
>
> Thank you for your comments.  Please see the inline comments below.  I
will be uploading a version -08.txt that will resolve some of these
comments.
> Cc: [email-masked]; Jeffrey 
> Haas; [email-masked]; [email-masked]; [email-masked]
> Subject: Kathleen Moriarty's Discuss on 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>
>> No, there are no additional requirements.  We only have requirements for
identifiers.   Do you have a suggestion for improved language.

>calls out the need for mutual authentication and it just states that with
no additional details.  That is fine, but the subject for section

Any suggestions on the header you would like to see? 

>>
>> All mutual identification schemes are in scope.  Is there a reason we
should restrict the mutual authentication schemes to a subset.

>You don't have to, but the header of the section makes me think this is
going to happen in the section.  Maybe setting a baseline would be good if
possible. Not using passwords - so > a secure form of mutual authentication
would be good if the requirements are only high level.

Can you please suggest text for a removal of using passwords? 

SH: My understanding is that other people had a concern regarding the
insecure transport.   I have provide an example of the BGP data feed
utilized by http://www.routeviews.org/ project.

SH:  Let me answer this from the operators feedback that causes this input. 
Some operators state, I will run everything over secure transport. 
Other operators state, I want to have light weight clients that will 
receive certain types of information via insecure transport. 
The light-weight client will have caveats (insecure transport, could be
spoofed), 
and then present the information. 

The argument within the WG was strong from operators for this second case,
and 
we made the decision to include the insecure data stream.   We can limit
this 
second case to unique data models (due to the mount addition to
netconf/netmod) 
which can be mounted.   We could expand this to specific events. 

>>> the use of an  insecure transport.
>>
>> Changed to :
>>
>> 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

>If this is done, it should be an experiment IMO.

What does experimental mean in a re-use protocol requirements?  
Does it mean that the NETCONF/RESTCONF does not have to it functional? 
Does it mean that we indicate this function is experimental and needs to be 
reviewed again?  If so, what are the criteria for the experiment to be
successful?

If experimental has the following constraint: 
1) NETCONF/RESTCONF must provide both standards and experimental features in
a design,  
2) I2RS protocol may use standard and experimental features to judge a
protocol fits I2RS protocol needs, 
3) I2RS will write-up a document indicating what tests will be used to deem
that the experimental features are ready for protocol standardization. 

> I'll have to look through Alissa's discuss, but isn't integrity a concern
if confidentiality and privacy are not?  I'm sure once this type of text is
altered and used to make important 
> decisions, this will come back to bite us.

Of course, integrity is desired. The non-secure transport is looking to
provide public information for a light-weight client.  Operators have
indicated a light-weight I2RS client will use this point.  The challenge
will be to have a light-weight integrity.    

> KM: Thanks.

Sue: Please verify you have what you want in the -08.txt 

> Please suggest alternative text for this section.

KM: I think it is self explanatory.  But if that's just me, leave the
definition in.
Sue:  Other people did not find it self-explanatory. 

> These definition have been removed.  I will provide feedback if this
removal cause problems in the creation of the protocol.

Sue: You are welcome. 

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Joel Halpern <[email-masked]>
Date: Thu, 18 Aug 2016 14:30:56 +0000

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.

Yours,
Joel

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Thursday, August 18, 2016 9:17 AM
To: 'Juergen Schoenwaelder' <[email-masked]>
Cc: [email-masked]; [email-masked]; 'Kathleen Moriarty' <[email-masked]>; 'The IESG' <[email-masked]>; [email-masked]; [email-masked]
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. 

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, August 18, 2016 9:06 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Kathleen Moriarty'; 'The IESG'; [email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Aug 2016 11:29:39 -0400

Joel and Kathleen: 

Just for the record, I disagree that putting in Yang 1.1 is awkward.  It is
only a key-word on an item that gives information to a implementation what
transports can be used to transport data.   If the telemetry information is
events (pub/sub), then this telemetry information could encode it to go on
secure stream or an insecure stream. 

If we are going to say that something is too difficult, I would like to
discuss this point.  Large routing systems are not what NETCONF/RESTCONF has
been designing for the last 5 years.    This telemetry information is target
at those systems.  The changes that I2RS is pushing is for routing systems.
One of the reasons that Juergen and I disagree on the difficulty of the work
is different of focus of IP systems (1-20 interfaces) and the large routing
systems.  I have given you BGP examples from Large routing systems.  I
believe this is necessary for large routing systems to give the BGP
telemetry information to aid provider networks.   I welcome comments from
Joel on the usefulness of the BGP Route View information. 

+1 on the disconnect between the WG and the IESG.  The I2RS architecture has
the concept of an unsecure channel. 

Sue 

-----Original Message-----
From: Joel Halpern [mailto:[email-masked]] 
Sent: Thursday, August 18, 2016 10:31 AM
To: Susan Hares; 'Juergen Schoenwaelder'
Cc: [email-masked]; [email-masked]; 'Kathleen Moriarty'; 'The IESG';
[email-masked]; [email-masked]
Subject: RE: [i2rs] Kathleen Moriarty's Discuss on
draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
COMMENT)

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.

Yours,
Joel

-----Original Message-----
From: Susan Hares [mailto:[email-masked]]
Sent: Thursday, August 18, 2016 9:17 AM
To: 'Juergen Schoenwaelder' <[email-masked]>
Cc: [email-masked]; [email-masked]; 'Kathleen Moriarty'
<[email-masked]>; 'The IESG' <[email-masked]>;
[email-masked]; [email-masked]
Subject: RE: [i2rs] Kathleen Moriarty's Discuss on
draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
COMMENT)

Juergen and Kathleen: 

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, August 18, 2016 9:06 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Kathleen Moriarty'; 'The IESG';

/js

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 18 Aug 2016 12:53:53 -0400

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-masked]> wrote:
> 

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Aug 2016 14:35:03 -0400

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-masked]] 
Sent: Thursday, August 18, 2016 12:54 PM
To: Joel Halpern
Cc: Susan Hares; Juergen Schoenwaelder; [email-masked]; [email-masked]; Kathleen Moriarty; IESG; [email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

>> 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.
>> 
>> 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.

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: 

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.

> [email-masked]; 
>> For me, the value is a common understanding of deployment 
>> distribution
> such

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Aug 2016 15:56:01 -0400

Alissa: 

A follow-up email on this topic.  Joel suggests that I missing your question. Are you asking  who is in a position to determine that certain data is reasonable to send unprotected?  
Are you asking if it is the operator, the data model designer, or our original WG designing the protocol? 

If this is the case, the final authority is the owner of the data - the operator.   The closer the operator works with vendors who supply code and standardize it, the better the vendors understand the need.  It is hoped that the vendors and the operators will help I2RS or other WG to define these data modules.  We hope the security people from these operators and security people from vendors and research will validate the security needs.   We believe we have a sense from the WG discussions on the categories I mentioned:  a) publically available data (route-views),  b) events specific to operators that are public, and c) interface/data that can be seen publically (IXP ports or MEF exchange ports) 

Personally, I also want to be very careful with any data that can be linked to a person.  To me, this must be done over a secure transport.  

Does this help?  Like Joel - I am proactively answering you, but confused on what you want me to change.  

Sue 

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]] 
Sent: Thursday, August 18, 2016 12:54 PM
To: Joel Halpern
Cc: Susan Hares; Juergen Schoenwaelder; [email-masked]; [email-masked]; Kathleen Moriarty; IESG; [email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Alissa

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Aug 2016 11:53:29 -0700

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 <[email-masked]> 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.
>
> Cc: Susan Hares; Juergen Schoenwaelder; [email-masked];
> [email-masked]; Kathleen Moriarty; IESG; [email-masked];
> 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).
>
> >> 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
> 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,
> > 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:
> >
> > 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:
> 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.
> > 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.
> >
> > 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.
> >
> > 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
> >
> >> as the route-views.   Since the operators argued strongly for this
> point,
> > I

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Aug 2016 15:44:34 -0400

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:

   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.”

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

From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, August 18, 2016 2:53 PM
To: Susan Hares
Cc: Alissa Cooper; Joel Halpern; [email-masked]; Juergen Schoenwaelder; [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Hi,

in an IETF module, the IETF needs to agree that there could never possibly be

 

Andy

Alissa:

Sue

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]]
Sent: Thursday, August 18, 2016 12:54 PM
To: Joel Halpern
Cc: Susan Hares; Juergen Schoenwaelder; [email-masked]; [email-masked]; Kathleen Moriarty; IESG; [email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Point 1:

Point 2:

Sue

===================

Section 3:

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Aug 2016 13:02:03 -0700

On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <[email-masked]> wrote:

> *“ 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:[email-masked]]
> *Sent:* Thursday, August 18, 2016 2:53 PM
> *To:* Susan Hares
> *Cc:* Alissa Cooper; Joel Halpern; [email-masked]; Juergen Schoenwaelder;
> [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas;
> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Aug 2016 10:57:56 +0200

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

---

From: [email-masked]
Date: Fri, 19 Aug 2016 06:46:39 -0400

Sent from my iPhone

> On Aug 19, 2016, at 4:57 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

What I proposed just adds a trigger so operators can make that decision and can automate it.  This isn't new for IETF protocols.  I'm proposing this since it seems it was a working group decision to allow for automation.  Is that not the case?

Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 06:49:56 -0400

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-masked]] 
Sent: Friday, August 19, 2016 4:58 AM
To: Susan Hares
Cc: 'Alissa Cooper'; 'Joel Halpern'; [email-masked]; [email-masked]; 'Kathleen Moriarty'; 'IESG'; [email-masked]; [email-masked]
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:
> >> 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.
> 
> > 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.
> >> think the best idea is to get it working in code and then see if 
> >> the deployment matches the requests.
> >> 
> >> Sue
> >> 
> >>> Cc: 'Kathleen Moriarty'; 'The IESG'; [email-masked]; 
> >>> [email-masked]; [email-masked]; 
> >>> 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
> >>>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Aug 2016 13:57:36 -0700

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 <[email-masked]> 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
>
>
>
> *Sent:* Thursday, August 18, 2016 4:02 PM
> *To:* Susan Hares

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Aug 2016 14:27:57 -0700

>    secure transport and optionally MAY be able to transfer data over a
I do not understand why approving the ok for non-secure transport for some
> modules means the following to you:
>
>
>

I see your point now.
This draft makes no mention of the YANG data model marking objects that can
be nonsecure.

SEC-REQ-08 is fine.
The other requirement (sorry I don't have the number) is the one that
should be removed.

Andy

---

From: joel jaeggli <[email-masked]>
Date: Thu, 18 Aug 2016 15:10:20 -0700

> Does this help?  Like Joel - I am proactively answering you, but confused on what you want me to change.  
Another joel here,

Conceptually an I2RS system resembles the distributed control and
forwarding architecture of a large routers. Likewise is possible to
conceive of router(s) where the I2RS architecture is the control plane.
If it appropriate to carry controller-plane programming or accounting
information around internally in such a system for reasons of
convenience or performance  then architects will probably do that. I
don't see as desirable, exposing my distributed control-plane to the
potential for information leakage or compromise when it's distributed
across the internet, At the same time if it's a big sheetmetal box with
12 linecards and internal network stashed away in a VRF, or a bunch of
software blobs running on the same machine, I might be inclined to treat
them differently.

Respecting SEC-REQ-09 I can imagine it being appropriate to do both at
the same time  with the same data to different clients

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 18 Aug 2016 20:47:02 -0400

I think there are some easy tweaks that could make everyone happy.  We
should be focusing on MTI, not MTU for requirements so that operators
can make decisions as needed.  I think we can all agree with that
statement.  We are worried about a few areas of text in the document,
namely where the data model can trigger the use of an insecure
transport.  The default is a secure transport for the protocol, so
that is MTI across the board.  One of the sections that causes concern
is the following:

Section 3: (I think the latest proposed text)

Which doesn't exactly meet the stated requirement in Section 3.2:

I think if we reword the text in section 3 as follows, the requirement
for support of a secure transport will be clear, a way to mark the
data model for the possible use of insecure transport is possible
(decision of the operator).

How about:
   I2RS allows the use of an insecure transport for portions of data
   models that clearly indicate data confidentiality and integrity
protection may not be necessary.
   Operators deploying I2RS must determine if they want to populate and
   deploy the portions of the data model with a configuration option
to use insecure transports.

I understand this changes your requirements a bit and your
implementation, but is this a way that we could allow some operators
to operate in a secure mode for this data if they choose and also
allow MTU to be less than the default?

If that's agreeable - with the other ADs too - then some more text in
section 3.2 needs to be tweaked in a similar way.

The text in section 3.2 is closer to what I am proposing, you have the sentence:

This talks about the data being marked in terms of a need for
confidentiality (should be integrity too as I could corrupt a clear
text stream in a way that is not detectable) instead of explicitly
stating that the transport should be insecure.  If the data model had
a attribute that had this marking (operator driven), I think that's an
improvement.

How about:

   A non-secure transport can be used for publishing telemetry data or
   other operational state that was specifically indicated as non-
   confidential and does not require integrity protection through an
   option provided in the data model.

I think this text allows for the WG goal of using a data model to
indicate the transport option, but for it to be an operator driven
decision in case some operators prefer to use transport encryption for
this section of the data model... or things change and they all decide
this is a good idea.

I'll get back to the other responses to my comments and discuss in a
separate message (possibly tomorrow).

If this alters discussions from other threads, please point me to the
thread and I'll catch up.

Thanks,
Kathleen

On Thu, Aug 18, 2016 at 4:05 PM, Susan Hares <[email-masked]> wrote:
> For the BGP route-views use case, this would make it clear that data had to
> be transformed to be insecure transmission.
>
>
>
> Sue
>
>
>
> Sent: Thursday, August 18, 2016 4:02 PM
>
>
> To: Susan Hares
> Cc: Alissa Cooper; Joel Halpern; [email-masked]; Juergen Schoenwaelder;
> “ the IETF needs to agree that there could never possibly be any deployment
> that would not want to allow exposure of the data.
>
> As I understand it, this requirement has another requirement associated with
> it
>
> 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
>
>
>
>
>
>
>
> Cc: Alissa Cooper; Joel Halpern; [email-masked]; Juergen Schoenwaelder;
> 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.
>
> Cc: Susan Hares; Juergen Schoenwaelder; [email-masked]; [email-masked];
> Kathleen Moriarty; IESG; [email-masked];
>>> rate telemetry data.  This may be BGP update information, it may be frequent
>>> single I2RS >communication between a client and agent is actually associated
>>> 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.
>>>
>>> sent unprotected >causes concern about insufficient protection.  If I recall
>>> 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
>> 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 disagree with Juergen on the difficulty in specifying the sections of the
> yang modules.  I have provided a suggested solution in:
> 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.
>> is public, and available via an unprotect means.  The fact the data model is

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 07:49:40 -0400

Kathleen: 

The intent of the text is the following: 

1) operators have a configuration knob that sets non-secure transport or secure transport for portions of data model marked as non-secure. 
     The operators always have the choice to use secure transport.  Some operators have indicated they will always use secure transport., 
 
2)  The data model are clearly marked with the sections of the data model that can be sent over non-secure transport.  
      The WG does not want configuration to be sent or some operational state to be sent over a non-secure transport. 

The WG is more restrictive than your comment.   I would prefer to keep this restriction.  

I realize that Juergen does not want to mark the data models.  He's repeated this viewpoint for 3 years. His viewpoint was declared in the "rough" in the I2RS Consensus.   The I2RS WG is setting requirements for the NETCONF/NETMOD WG.   

It is the IESG choice to say to the I2RS WG that their opinion is in the rough, and provide technical reasons why. 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 19, 2016 6:47 AM
To: Juergen Schoenwaelder
Cc: Susan Hares; Alissa Cooper; Joel Halpern; [email-masked]; [email-masked]; IESG; [email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Sent from my iPhone

Kathleen

---

From: Lou Berger <[email-masked]>
Date: Fri, 19 Aug 2016 07:33:36 -0400

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:

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

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 07:39:22 -0400

Kathleen: 

Thank you for your suggestions.  See below for the modification. 

Sue 

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Thursday, August 18, 2016 8:47 PM
To: Susan Hares
Cc: Andy Bierman; Alissa Cooper; Joel Halpern; [email-masked]; Juergen Schoenwaelder; [email-masked]; IESG; Jeffrey Haas; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

I think there are some easy tweaks that could make everyone happy.  We should be focusing on MTI, not MTU for requirements so that operators can make decisions as needed.  I think we can all agree with that statement.  We are worried about a few areas of text in the document, namely where the data model can trigger the use of an insecure transport.  The default is a secure transport for the protocol, so that is MTI across the board.  One of the sections that causes concern is the following:

[please define:  MTI/MTU] 

The latest text from -08.txt is: 

>The security for the I2RS protocol requires mutually authenticated I2RS 
>clients and I2RS agents. The I2RS client and I2RS agent using the I2RS 
>protocol MUST be able to exchange data over a secure transport.  
>Optionally, the I2RS Client and I2RS agent MAY operate on a non-secure 
>transport to transfer a specific set of non-confidential data
 
Alvaro made the point this text was redundant. I agreed and suggested it be removed -09.txt.
Does this satisfy you.  

===================

> I think if we reword the text in section 3 as follows, the requirement for support of a secure transport will be clear, a way to mark the data model for the possible use of insecure > transport is possible (decision of the operator).
> 
> How about:
>    models that clearly indicate data confidentiality and integrity protection may not be necessary.
>   deploy the portions of the data model with a configuration option to use insecure transports.
> 
> I understand this changes your requirements a bit and your implementation, but is this a way that we could allow some operators to operate in a secure mode for this data if they choose and also allow MTU to be less than the default?
> 

Sue: Would removal of this text work instead?  As Alvaro pointed out, it is redundant to SEC-REQ-08. 
I agreed to remove that text which results in: 

The Start of section 3 would be: 

   The security for the I2RS protocol requires mutually authenticated
   I2RS clients and I2RS agents communicating over a secure transport.  
   The I2RS protocol MUST be able to provide atomicity of an I2RS
   transaction, but it is not required to have multi-message atomicity
   and roll-back mechanism transactions.  Multiple messages transactions
   may be impacted by the interdependency of data.  This section
   discusses the details of these security requirements.
=====================================

>If that's agreeable - with the other ADs too - then some more text in section 3.2 needs to be tweaked in a similar way.
>
>This talks about the data being marked in terms of a need for confidentiality (should be integrity too as I could corrupt a clear text stream in a way that is not detectable) instead >of explicitly stating that the transport should be insecure.  If the data model had a attribute that had this marking (operator driven), I think that's an improvement.

>I think this text allows for the WG goal of using a data model to indicate the transport option, but for it to be an operator driven decision in case some operators prefer to use >transport encryption for this section of the data model... or things change and they all decide this is a good idea.

Technical point:  The phrase: 
  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.

This text always implied to the WG that the operator could always elect to send the non-secure marked portion of a data model over secure transport.  Therefore, I am happy you want to emphasize this technical issue in the text.  I think we are aligned on this higher issue.   However, this alternate text has a problem. 

 Textual comments: The reason we stated:  

  And 

Is to provide precise requirements for the NETCONF/NETMOD WG with whom the I2RS WG to whom the 
I2RS WG will send these initial comments.  Your text does not provide that precise instruction. 

How about this version for SEC-REQ-08:

    
   A non-secure transport may optionally 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.  
   Since the non-secure transport is optional, an operator may set an option 
   to send the data marked "non-secure" in the Yang syntax 
   over a secure transport.    

   The following are further restrictions on this optionally non-secure transport: 

   1) The configuration of ephemeral data in the I2RS Agent by the I2RS
   client SHOULD be done over a secure transport.
 
   2)  It is anticipated  that the passing of most I2RS ephemeral state operational status
   SHOULD be done over a secure transport.  

   3) As [I-D.ietf-i2rs-ephemeral-state] notes 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.   
-------
Does this refinement of the text make it clear the operator can always turn 
on the secure transport? 

> I'll get back to the other responses to my comments and discuss in a separate message (possibly tomorrow).
>
> If this alters discussions from other threads, please point me to the thread and I'll catch up.

I've pointed you at Alvaro message. 

------------------
Thanks,
Kathleen

Thank you Kathleen.   This  helped!

On Thu, Aug 18, 2016 at 4:05 PM, Susan Hares <[email-masked]> wrote:
> For the BGP route-views use case, this would make it clear that data 
> had to be transformed to be insecure transmission.
>
>
>
> Sue
>
>
>
> “ the IETF needs to agree that there could never possibly be any 
> deployment that would not want to allow exposure of the data.
>
> As I understand it, this requirement has another requirement 
> associated with it
>
> but not if that opens up correlation attacks.  (e.g., I can send data 
> to some
>
> 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
> requirement provides a full scope of the work, but implementers will 
> require network operators to configure these features on.
>
>
>
> Sue
>
>
>
> Andy
>
>
>
>
>
>
>
> (1995-2010) developing a routing/switching platform (denoted as GateD) which was sold to
> 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
> 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.
>
> 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-masked]>
>>> wrote:
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> allow for unprotected channels, I guess we have disconnect between 
>>> the IESG and the WG.
>>>
>>> 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.
>>>
>>> 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.
>
>> 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.
>> 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.
>> 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:
>>
>> 2. For line card activity data where there is no likely upgrade path 
>> to support secure transports in the foreseeable future.
>>
>> 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:
> Given the mount schema functionality, we can mount ephemeral state 
> module which augment non-ephemeral state modules which are "in-secure only".
>
> Point 2:
> purpose are you looking for this enumeration to server.  Are you 
> looking for the enumeration in SEC-REQ-08?
>
>> 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
>> 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.
>>
>> YANG doctors going to review this? How are security directorate 
>> people going to judge this? But as promised, I leave (still puzzled) now.
>>
>> /js
>>

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 08:07:12 -0400

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-masked]] 
Sent: Friday, August 19, 2016 7:34 AM
To: Susan Hares; 'Juergen Schoenwaelder'
Cc: [email-masked]; 'Alissa Cooper'; [email-masked]; 'Kathleen Moriarty'; 'IESG'; [email-masked]; 'Joel Halpern'; [email-masked]
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.

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:
> Cc: 'Alissa Cooper'; 'Joel Halpern'; [email-masked]; 
> [email-masked]; 'Kathleen Moriarty'; 'IESG'; [email-masked];

---

From: Lou Berger <[email-masked]>
Date: Fri, 19 Aug 2016 08:20:16 -0400

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

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 08:45:25 -0400

Lou: 

Ok, Thank you for noting these three points.  For the IESG, the proposed text to Kathleen still works.  If Kathleen ACKS my message and text, then I will upload this text in version 9.   I also hear the silence regarding NETMOD WG considering these proposals. 

Sue   

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, August 19, 2016 8:20 AM
To: Susan Hares; 'Juergen Schoenwaelder'
Cc: [email-masked]; 'Alissa Cooper'; [email-masked]; 'Kathleen Moriarty'; 'IESG'; [email-masked]; 'Joel Halpern'; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Sue,

 

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.

Lou
On 8/19/2016 8:07 AM, Susan Hares wrote:
> Cc: [email-masked]; 'Alissa Cooper'; [email-masked]; 'Kathleen 
> Moriarty'; 'IESG'; [email-masked]; 'Joel Halpern'; 
>>>>> 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
>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> -
>>>>>>> -
>>>>>>> --
>>>>>>> --
>>>>>>> COMMENT:
>>>>>>> ----------------------------------------------------------------
>>>>>>> -
>>>>>>> -
>>>>>>> --
>>>>>>> --
>>>>>>>
>>>>>>>> Section 3:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 19 Aug 2016 08:08:09 -0500

Dear All,

> that arbitrary index 455992 is really John Doe or really suite #14, etc.

Since Kathleen asked what other ADs were thinking ...

I'm current on this thread, as of the time I'm sending my note, but
replying to Andy's note because it's poking where I am poking.

So, if (say) an octet counter is considered safe to send in the clear, and
a Yang model that reflects that is approved and widely deployed, and then
someone realizes that it's not safe to send in the clear, is that a big
deal to fix, and get the updated Yang model widely deployed?

My opinion on this point has a lot to do with how hard it is to recover if
a Yang model gets this wrong ...

My apologies for not understanding enough about Yang and I2RS to be able to
answer my own question, of course.

Thanks,

Spencer

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 09:19:57 -0400

Spencer: 

You as asking if:

1)      Can Yang Models be revised?  - there is a revision tag on the Yang model. 

2)      How long it takes to deploy revised models in the Internet, and old-models to be timed out?  This is an operational question on yang models that no one has experience to determine.   Andy suggest that the deployment time is 20 years (the Age of the Commercial internet – 1996 -2016) rather than the age of the Internet (1987-2016).  

However, the real question you should have asked is: Can operators deploy models which are marked as “non-secure transport” with a  secure transport?  

The answer is yes.  In fact, several operators in I2RS stated that all I2RS protocol communication needed to be secure.    Therefore, if the people found out that a model was problematic to be insecure – operators and vendors would simply turn the deployment knob switch that says – deploy this always with a secure transport rather than optionally allow an insecure transport.    

Now, the real problem is if the IESG has been cycling on this concept – the text needs to change.   I’m going to go ahead and release a version-09.txt that tries to make this very clear.   Please comment on that text to help make this clear. 

Sue 

From: Spencer Dawkins at IETF [mailto:[email-masked]] 
Sent: Friday, August 19, 2016 9:08 AM
To: Andy Bierman
Cc: Susan Hares; [email-masked]; Alissa Cooper; Juergen Schoenwaelder; [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Dear All,

 

Andy:

 

As I understand it, this requirement has another requirement associated with it

but not if that opens up correlation attacks.  (e.g., I can send data to some

I'm current on this thread, as of the time I'm sending my note, but replying to Andy's note because it's poking where I am poking.

So, if (say) an octet counter is considered safe to send in the clear, and a Yang model that reflects that is approved and widely deployed, and then someone realizes that it's not safe to send in the clear, is that a big deal to fix, and get the updated Yang model widely deployed? 

My opinion on this point has a lot to do with how hard it is to recover if a Yang model gets this wrong ...

My apologies for not understanding enough about Yang and I2RS to be able to answer my own question, of course.

Thanks,

Spencer

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 09:30:05 -0400

Spencer: 

Let me clarify one thing.   The deployment of new Yang modules can be sent with any software update cycle.  A software update cycle takes hours in some environments and months in others.  The question is what is the longest a yang module can stay the network.  Andy suggests 20+ years (probably based on SNMP deployments).  

I have posted version -09.txt.   

Sue 

From: Susan Hares [mailto:[email-masked]] 
Sent: Friday, August 19, 2016 9:20 AM
To: 'Spencer Dawkins at IETF'; 'Andy Bierman'
Cc: [email-masked]; 'Alissa Cooper'; 'Juergen Schoenwaelder'; [email-masked]; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel Halpern'; [email-masked]
Subject: RE: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Spencer: 

You as asking if:

Now, the real problem is if the IESG has been cycling on this concept – the text needs to change.   I’ve release a version-09.txt that tries to make this very clear.   Please comment on that text to help make this clear. 

Sue 

Dear All,

 

Andy:

 

Thanks,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 19 Aug 2016 09:13:18 -0500

Hi, Susan,

On Fri, Aug 19, 2016 at 8:19 AM, Susan Hares <[email-masked]> wrote:

> 2)      How long it takes to deploy revised models in the Internet, and
> old-models to be timed out?  This is an operational question on yang models
> that no one has experience to determine.   Andy suggest that the deployment
> time is 20 years (the Age of the Commercial internet – 1996 -2016) rather
> than the age of the Internet (1987-2016).
>
>
>
> However, the real question you should have asked is: Can operators deploy
> models which are marked as “non-secure transport” with a  secure transport?
>

I understood that part. My question was how long it would likely take them
to switch to a secure transport if they had deployed a model with an
insecure transport and figured out that was problematic.

Thanks for the explanation. It was helpful.

Spencer

> The answer is yes.  In fact, several operators in I2RS stated that all
> I2RS protocol communication needed to be secure.    Therefore, if the
> people found out that a model was problematic to be insecure – operators
> and vendors would simply turn the deployment knob switch that says – deploy
> this always with a secure transport rather than optionally allow an
> insecure transport.
>
>
>
> Now, the real problem is if the IESG has been cycling on this concept –
> the text needs to change.   I’m going to go ahead and release a
> version-09.txt that tries to make this very clear.   Please comment on that
> text to help make this clear.
>
>
>
> Sue
>
>
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:[email-masked]]
> *Sent:* Friday, August 19, 2016 9:08 AM
> *To:* Andy Bierman
> *Cc:* Susan Hares; [email-masked]; Alissa Cooper; Juergen Schoenwaelder;
> [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel
> Halpern; [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Aug 2016 07:23:47 -0700

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-masked]> wrote:

> > 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:
> >
> > 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
> >
> >
> 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
> >
> >> 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:
> >>
> >> 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
> >>
> 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
> >>
> work, I am working on a publically available work in Quagga based on the
> confD product suggested by Cisco.
> >>>
> high rate telemetry data.  This may be BGP update information, it may be
> 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.
> 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.
> the cases that motivate the inclusion of protocol support for insecure
> transport:
> >>>>
> >>>> 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
> model is public, and available via an unprotect means.  The fact the data
> model is all public should simplify the review.
> >>>>
> second case.  The I2RS RIB has an event based on policy that indicates a
> 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
> >>>>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 10:59:23 -0400

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-masked]] 
Sent: Friday, August 19, 2016 10:24 AM
To: Lou Berger
Cc: Susan Hares; Juergen Schoenwaelder; [email-masked]; Alissa Cooper; [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Hi,

I agree with Juergen.

all this time.

Andy

Sue,

Lou

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 11:02:10 -0400

Spencer: 

Thank you for asking.  The time it would take is the time to move the configuration knob to “always transport-secure” for this model. 

Sue 

From: Spencer Dawkins at IETF [mailto:[email-masked]] 
Sent: Friday, August 19, 2016 10:13 AM
To: Susan Hares
Cc: Andy Bierman; [email-masked]; Alissa Cooper; Juergen Schoenwaelder; [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Hi, Susan,

Spencer: 

You as asking if:

I understood that part. My question was how long it would likely take them to switch to a secure transport if they had deployed a model with an insecure transport and figured out that was problematic.

Spencer

Sue 

Dear All,

 

Andy:

 

Thanks,

Spencer

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 19 Aug 2016 11:26:43 -0400

On Fri, Aug 19, 2016 at 11:02 AM, Susan Hares <[email-masked]> wrote:
> Spencer:
>
>
>
> Thank you for asking.  The time it would take is the time to move the
> configuration knob to “always transport-secure” for this model.

Why does the knob in the data model have to be set only one way?
Couldn't an attribute be used that you could change the setting for
that attribute rather than update the entire YANG module or is that
not possible in YANG?  Couldn't this be a setting?

Thanks,
Kathleen

> Cc: Andy Bierman; [email-masked]; Alissa Cooper; Juergen Schoenwaelder;
> [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern;
> The answer is yes.  In fact, several operators in I2RS stated that all I2RS
> protocol communication needed to be secure.    Therefore, if the people
> found out that a model was problematic to be insecure – operators and
> vendors would simply turn the deployment knob switch that says – deploy this
> always with a secure transport rather than optionally allow an insecure
> transport.
>
>
>
> Now, the real problem is if the IESG has been cycling on this concept – the
> text needs to change.   I’m going to go ahead and release a version-09.txt
> that tries to make this very clear.   Please comment on that text to help
> make this clear.
>
>
>
> Sue
>
>
>
>
>
> Cc: Susan Hares; [email-masked]; Alissa Cooper; Juergen Schoenwaelder;
> [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern;
> I'm current on this thread, as of the time I'm sending my note, but replying
> to Andy's note because it's poking where I am poking.
>
>
>
> So, if (say) an octet counter is considered safe to send in the clear, and a
> Yang model that reflects that is approved and widely deployed, and then
> someone realizes that it's not safe to send in the clear, is that a big deal
> to fix, and get the updated Yang model widely deployed?
>
>
>

-- 

Best regards,
Kathleen

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Aug 2016 08:43:22 -0700

Hi,

That is simple.
There needs to be consensus on the syntax and semantics of each
statement in the YANG module.

Since security is MTI and MTU for NETCONF and RESTCONF, there
is no point debating which objects are OK without security.

Andy

On Fri, Aug 19, 2016 at 7:59 AM, Susan Hares <[email-masked]> wrote:

> 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
>
>
>
> *Sent:* Friday, August 19, 2016 10:24 AM
> *To:* Lou Berger
> *Cc:* Susan Hares; Juergen Schoenwaelder; [email-masked]; Alissa Cooper;

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 11:42:21 -0400

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/

   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-masked]] On Behalf Of Susan Hares
Sent: Friday, August 19, 2016 10:59 AM
To: 'Andy Bierman'; 'Lou Berger'
Cc: [email-masked]; 'Alissa Cooper'; 'Juergen Schoenwaelder'; [email-masked]; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel Halpern'; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Andy: 

Sue 

Hi,

I agree with Juergen.

all this time.

Andy

Sue,

Lou

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 12:01:02 -0400

Kathleen: 

First of all, I agree software knobs can always be set to multiple settings in vendor settings.  These settings may expand beyond standard models, and operators may set these knobs as they wish.   

As a security person, do you really want a standardized knob that says "run this model over non-secure transport"?  I do not want non-secure transport used for configuration and most operational status.  Corrupted data in the MGT plane can corrupt data traffic in the network.   The bar for non-secure transport has to be very high with lots of warnings.  Therefore an operator having a switch to change attribute (such as a configuration attribute) from a secure transport to a non-secure transport - should be discouraged.

Yang 1.1 has three places to indicate: 
 1) Attribute - on the yang syntax on an attribute (leaf node or leaf list),  or portion of a schema, 
 2) model - meta-data on yang modules contained in library. 
 3) mount points - where multiple modules are mounted.  

[Andy or Juergen may provide more details on meta-data on yang module libraries.  Lada or Lou can provide more details on mount points. ]

Early in our discussion, NETCONF/NETMOD asked us to be specific in our requirements.   In the final discussion, we put Yang syntax so the level could be attribute to provide the level of check you indicated.   It could go to any of these places if it works,. 

Does this discussion help?

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Friday, August 19, 2016 11:27 AM
To: Susan Hares
Cc: [email-masked]; Alissa Cooper; Juergen Schoenwaelder; [email-masked]; Andy Bierman; Spencer Dawkins at IETF; Jeffrey Haas; Joel Halpern; [email-masked]; IESG
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Why does the knob in the data model have to be set only one way?
Couldn't an attribute be used that you could change the setting for that attribute rather than update the entire YANG module or is that not possible in YANG?  Couldn't this be a setting?

Thanks,
Kathleen

> time is 20 years (the Age of the Commercial internet – 1996 -2016) 
> rather than the age of the Internet (1987-2016).
>
>
>
> However, the real question you should have asked is: Can operators 
> deploy models which are marked as “non-secure transport” with a  secure transport?
>
>
>
> I understood that part. My question was how long it would likely take 
> them to switch to a secure transport if they had deployed a model with 
> an insecure transport and figured out that was problematic.
>
>
>
> vendors would simply turn the deployment knob switch that says – 
> deploy this always with a secure transport rather than optionally 
> allow an insecure transport.
>
>
>
> So, if (say) an octet counter is considered safe to send in the clear, 
> and a Yang model that reflects that is approved and widely deployed, 
> and then someone realizes that it's not safe to send in the clear, is 
> that a big deal to fix, and get the updated Yang model widely deployed?
>
>
>
> My opinion on this point has a lot to do with how hard it is to 
> recover if a Yang model gets this wrong ...
>
>
>
> My apologies for not understanding enough about Yang and I2RS to be 
> able to answer my own question, of course.
>
>
>
> Thanks,
>
>
>
> Spencer
>
>

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 12:03:33 -0400

Andy/Kathleen: 

What do MTI and MTU standard for?  

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, August 19, 2016 11:43 AM
To: Susan Hares
Cc: [email-masked]; Alissa Cooper; Juergen Schoenwaelder; [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern; Lou Berger; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Hi,

That is simple.

Andy

Andy: 

Sue 

Hi,

I agree with Juergen.

all this time.

Andy

Sue,

Lou

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 19 Aug 2016 12:09:33 -0400

Hi Sue,

On Fri, Aug 19, 2016 at 12:01 PM, Susan Hares <[email-masked]> wrote:
> As a security person, do you really want a standardized knob that says "run this model over non-secure transport"?

KM: What I had asked earlier was if you could set a flag to say the
data wasn't confidential and didn't require integrity protection.  The
operator could decide how they want to treat the data in that
circumstance and you might only put this flag in the data model in
places that you think the trigger is needed.

Kathleen

 I do not want non-secure transport used for configuration and most
operational status.  Corrupted data in the MGT plane can corrupt data
traffic in the network.   The bar for non-secure transport has to be
very high with lots of warnings.  Therefore an operator having a
switch to change attribute (such as a configuration attribute) from a
secure transport to a non-secure transport - should be discouraged.

-- 

Best regards,
Kathleen

---

From: joel jaeggli <[email-masked]>
Date: Fri, 19 Aug 2016 09:12:26 -0700

> What do MTI and MTU standard for? 

Mandatory to implement / use

>  
> 
> Sue
> 
>  
> 
> *From:*i2rs [mailto:[email-masked]] *On Behalf Of *Andy Bierman
> *Sent:* Friday, August 19, 2016 11:43 AM
> *To:* Susan Hares
> *Cc:* [email-masked]; Alissa Cooper; Juergen Schoenwaelder;
> Halpern; Lou Berger; [email-masked]
> On Fri, Aug 19, 2016 at 7:59 AM, Susan Hares <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Andy:
> 
>  
> 
> *From:*Andy Bierman [mailto:[email-masked] <mailto:[email-masked]>]
> *Cc:* Susan Hares; Juergen Schoenwaelder; [email-masked]
> <mailto:[email-masked]>; Alissa Cooper; [email-masked]
> <mailto:[email-masked]>; Kathleen Moriarty; IESG; Jeffrey Haas;
> Joel Halpern; [email-masked]
> <mailto:[email-masked]>
> On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> Sue,
> 
> 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:
>>
> 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
>>
>>
>> From: Lou Berger [mailto:[email-masked] <mailto:[email-masked]>]
>> Cc: [email-masked] <mailto:[email-masked]>; 'Alissa Cooper';
> [email-masked] <mailto:[email-masked]>; 'Kathleen Moriarty';
> 'IESG'; [email-masked] <mailto:[email-masked]>; 'Joel Halpern';
> <mailto:[email-masked]>
>> I have to say that from a model complexity (definition, process,
> review, implementation - take your pick) , language and NETMOD co-chair
> 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.
>>>
> 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:
>>>
> requirement phase, the operators may begin to specify new models that
> have this feature.
>>>
>>> Sue
>>>
>>> [mailto:[email-masked]
> <mailto:[email-masked]>]
>>> Cc: 'Alissa Cooper'; 'Joel Halpern'; [email-masked]
> <mailto:[email-masked]>;
>>> [email-masked] <mailto:[email-masked]>; 'Kathleen
> Moriarty'; 'IESG'; [email-masked] <mailto:[email-masked]>;
> <mailto:[email-masked]>
> 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
>>>
> 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.
>>>>
>>>> From: Alissa Cooper [mailto:[email-masked]
> <mailto:[email-masked]>]
>>>> Cc: Susan Hares; Juergen Schoenwaelder; [email-masked]
> <mailto:[email-masked]>;
>>>> [email-masked] <mailto:[email-masked]>; Kathleen
> Moriarty; IESG; [email-masked] <mailto:[email-masked]>;
> <mailto:[email-masked]>
> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>
> 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.
>>>>>>
> 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
> 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.
>>>>>>
>>>>>> 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.
> 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
>>>>> 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.
>>>>> 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
> 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?
>>>>
> below.  Given your comments, I believe I should change the last line to
> a MUST.
>>>>> From: Susan Hares [mailto:[email-masked] <mailto:[email-masked]>]
>>>>> To: 'Juergen Schoenwaelder' <[email-masked]
> <mailto:[email-masked]>>
>>>>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; 'Kathleen Moriarty'
>>>>> <[email-masked]
> <mailto:[email-masked]>>; 'The IESG' <[email-masked]
> <mailto:[email-masked]>>;
>>>>> [email-masked] <mailto:[email-masked]>;
> <mailto:[email-masked]>
> 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.
> 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
>>>>> [mailto:[email-masked]
> <mailto:[email-masked]>]
>>>>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; 'Kathleen Moriarty'; 'The
>>>>> IESG'; [email-masked] <mailto:[email-masked]>;
> <mailto:[email-masked]>
> doctors going to review this? How are security directorate people going
> to judge this? But as promised, I leave (still puzzled) now.
>>>>>
>>>>> /js
>>>>>
>>>>>> From: i2rs [mailto:[email-masked]
> <mailto:[email-masked]>] On Behalf Of Juergen
>>>>>> Schoenwaelder
>>>>>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; 'Kathleen Moriarty'; 'The
>>>>>> IESG'; [email-masked] <mailto:[email-masked]>;
> <mailto:[email-masked]>
>>>>>>> [mailto:[email-masked]
> <mailto:[email-masked]>]
>>>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; [email-masked]
> <mailto:[email-masked]>;
>>>>>>> [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>;
> <mailto:[email-masked]>
>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 12:12:10 -0400

Kathleen:

Responding to: 

KM: What I had asked earlier was if you could set a flag to say the data wasn't confidential and didn't require integrity protection.  The operator could decide how they want to treat the data in that circumstance and you might only put this flag in the data model in places that you think the trigger is needed.

Sue: 
There is no mechanism to do this in Yang right now.  There is a proposal on how such a flag to be placed in the data model in places that need this trigger in draft-hares-i2rs-protocol-strawman.

Sue 

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Friday, August 19, 2016 12:10 PM
To: Susan Hares
Cc: [email-masked]; Alissa Cooper; Juergen Schoenwaelder; [email-masked]; Andy Bierman; Spencer Dawkins at IETF; Jeffrey Haas; Joel Halpern; [email-masked]; IESG
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Hi Sue,

> As a security person, do you really want a standardized knob that says "run this model over non-secure transport"?

KM: What I had asked earlier was if you could set a flag to say the data wasn't confidential and didn't require integrity protection.  The operator could decide how they want to treat the data in that circumstance and you might only put this flag in the data model in places that you think the trigger is needed.

Kathleen

 I do not want non-secure transport used for configuration and most operational status.  Corrupted data in the MGT plane can corrupt data
traffic in the network.   The bar for non-secure transport has to be
very high with lots of warnings.  Therefore an operator having a switch to change attribute (such as a configuration attribute) from a secure transport to a non-secure transport - should be discouraged.
> [Andy or Juergen may provide more details on meta-data on yang module 
> libraries.  Lada or Lou can provide more details on mount points. ]
>
> Cc: [email-masked]; Alissa Cooper; Juergen Schoenwaelder; 
> [email-masked]; Andy Bierman; Spencer Dawkins at IETF; Jeffrey 
> Haas; Joel Halpern; 
> [email-masked]; IESG
>> Cc: Andy Bierman; [email-masked]; Alissa Cooper; Juergen 
>> Schoenwaelder; [email-masked]; Kathleen Moriarty; IESG; Jeffrey 
>> Haas; Joel Halpern; 
>> them to switch to a secure transport if they had deployed a model 
>> with an insecure transport and figured out that was problematic.
>>
>>
>>
>> So, if (say) an octet counter is considered safe to send in the 
>> clear, and a Yang model that reflects that is approved and widely 
>> deployed, and then someone realizes that it's not safe to send in the 
>> clear, is that a big deal to fix, and get the updated Yang model widely deployed?
>>
>>
>>

-- 

Best regards,
Kathleen

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Aug 2016 09:32:16 -0700

On Fri, Aug 19, 2016 at 8:42 AM, Susan Hares <[email-masked]> wrote:

> 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].
>
>
>

I hope you are right that it will almost always be easy for a WG
to decide this issue for each leaf.

We already have "security tagging" in NACM, and this has not caused delays.
This is the opposite decision -- Is this data so sensitive that the NACM
default
access control needs to block writes (nacm:default-deny-write) or block all
access
(nacm:default-deny-all)?

These extensions are used in ietf-system.yang, not just in the NACM RFC.
They can be used anywhere and a NACM implementation MUST enforce
the extension semantics.

If YANG Push had similar requirements (i.e, MUST NOT send data in the clear
that is not tagged with the appropriate extension) and the review criteria
is clear,
then this approach should be OK.

Andy

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.
>
> other
> *From:* i2rs [mailto:[email-masked]] *On Behalf Of *Susan Hares
> *Sent:* Friday, August 19, 2016 10:59 AM
> *To:* 'Andy Bierman'; 'Lou Berger'
> *Cc:* [email-masked]; 'Alissa Cooper'; 'Juergen Schoenwaelder';
> [email-masked]; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel
> Halpern'; [email-masked]
> *From:* Andy Bierman [mailto:[email-masked] <[email-masked]>]

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 12:55:53 -0400

Andy: 

The easy of reviewing per leaf – is why I suggested the per leaf.  

I also agree it is important to mention this non-secure/secure requirement to the PUSH work team we are both on. 

Should I change: 

Old: /

New: 

/   A non-secure transport can be used for publishing telemetry data or

   confidential in the data model. /

Sue 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, August 19, 2016 12:32 PM
To: Susan Hares
Cc: Lou Berger; [email-masked]; Alissa Cooper; Juergen Schoenwaelder; [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Andy: 

 

This is the opposite decision -- Is this data so sensitive that the NACM default

access control needs to block writes (nacm:default-deny-write) or block all access

(nacm:default-deny-all)?

the extension semantics.

that is not tagged with the appropriate extension) and the review criteria is clear,

 

Andy

Old/

New:/

    /

Sue 

Andy: 

Sue 

Hi,

I agree with Juergen.

all this time.

Andy

Sue,

Lou

---

From: William Atwood <[email-masked]>
Date: Fri, 19 Aug 2016 16:14:29 -0400

See suggestion below:-

> /   A non-secure transport can be used for publishing telemetry data or
                             may
>    other operational state that was specifically indicated to non-
                                                                be non-
>    confidential in the data model. /
can = it is possible to do it
may = you have permission to do it

I offer two choices for the second correction:
s/to/to be/  (as indicated)
s/to/as/     (which is perhaps better than my first suggestion)

  Bill

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Alia Atlas <[email-masked]>
Date: Fri, 19 Aug 2016 16:29:23 -0400

First, to be very clear.  This document has WG consensus - confirmed over
multiple WGLCs - in the I2RS WG.
This thread is to resolve the concerns expressed by the ADs about specific
aspects of this document.

Second, by having a requirement for indicating in the model - whether for
the whole model or per leaf - that
the data may be sent over an insecure transport, this encourages limiting
the standard use of an insecure
transport to exactly those models or data that requires it for a given
use-case.

I do see this as limited to certain types of use-cases and the ability to
mount a model differently allows the
flexibility of describing a particular model as acceptable for insecure
transport rather than requiring a leaf-by-leaf
indication.

The use of insecure transport is to accommodate use-cases that were not in
the scope initially considered
for NetConf/RestConf.

Regards,
Alia

On Fri, Aug 19, 2016 at 12:32 PM, Andy Bierman <[email-masked]> wrote:

> 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.
>>
>> 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
>> >>>>>> glass functions.    For the web-server route,  an event be sent
>> when
>> >>>> that
>> >>>>>> one route is added.
>> >>>>>>
>> >>>>>> Sue
>> >>>>>>
>> >>>>>>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Aug 2016 17:16:47 -0400

Bill:

Thank you for your comment.  Just to be clear, your revised comment is: 

New

/A non-secure transport may be used for publishing telemetry data or 
other operational state that was specifically indicated as non-confidential
in the data model. 
/

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of William Atwood
Sent: Friday, August 19, 2016 4:14 PM
To: Susan Hares; 'Andy Bierman'
Cc: [email-masked]; 'Alissa Cooper'; 'Juergen Schoenwaelder';
Halpern'; 'Lou Berger';

See suggestion below:-

                             may
                                                                be non-

  Bill

--

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Aug 2016 12:07:38 +0200

>    confidential in the data model. /

Tagging something in the data model as 'non-confidential' remains a
flawed idea. What can be considered 'non-confidential' depends on the
deployment scenario. It is even worse to standardize some piece of
information as 'non-confidential'. How can the IETF claim that
something is always 'non-confidential'? (And note, a non-secure
transport is not just about confidentiality, it also implies that
boxes on the path can arbitrarily change the information.)

In case this is not clear: What we have done for ~30 years is to have
the decision which information goes into an insecure transport be
taken by an access control model. This makes the decision runtime
configurable and thus things can be deployment specific. This has
worked for 30 years and I have no problem with this. What I am
struggling with is the idea to standardize parts of YANG data models
as 'non-confidential'.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 22 Aug 2016 08:46:13 -0400

Juergen: 

Thank you for your input. 

I can find nothing new in your input that was not covered in the I2RS WG discussions. As far as I can tell you are re-iterating a discussion that occurred in the WG, and was closed.   I have given example (BGP route-view,  web-service up) as events which currently in the public and have been requested by some operators.  Please note that the operator should have a knob that says "always" secure-transport.   

Sue  

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, August 22, 2016 6:08 AM
To: Susan Hares
Cc: 'Andy Bierman'; 'Lou Berger'; [email-masked]; 'Alissa Cooper'; [email-masked]; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel Halpern'; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

>    confidential in the data model. /

Tagging something in the data model as 'non-confidential' remains a flawed idea. What can be considered 'non-confidential' depends on the deployment scenario. It is even worse to standardize some piece of information as 'non-confidential'. How can the IETF claim that something is always 'non-confidential'? (And note, a non-secure transport is not just about confidentiality, it also implies that boxes on the path can arbitrarily change the information.)

In case this is not clear: What we have done for ~30 years is to have the decision which information goes into an insecure transport be taken by an access control model. This makes the decision runtime configurable and thus things can be deployment specific. This has worked for 30 years and I have no problem with this. What I am struggling with is the idea to standardize parts of YANG data models as 'non-confidential'.

/js

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 22 Aug 2016 11:19:12 -0400

Hello,

My plan is to re-read the posted draft, but if you plan to include
Stephen's updates as well, I can wait to review that.  I'll have to
read the text to see where we are at as there have been a lot of
messages on this thread and updates from other related AD
comments/disucusses.  I'm still concerned about a few things, but will
see if that matters in the text.

I believe I responded on the heading for the mutual authentication
suggesting that it should really be identifiers and authentication
instead of mutual authentication.  I don't expect to see explicit
guidelines on mutual auth, but with that as the header, I would have.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 22 Aug 2016 11:35:15 -0400

Kathleen:

I will include some of Stephen's updates.   The document update will probably late today or early tomorrow.  

Sue 

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Monday, August 22, 2016 11:19 AM
To: Susan Hares
Cc: Juergen Schoenwaelder; Andy Bierman; Lou Berger; [email-masked]; Alissa Cooper; [email-masked]; IESG; Jeffrey Haas; Joel Halpern; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Hello,

My plan is to re-read the posted draft, but if you plan to include Stephen's updates as well, I can wait to review that.  I'll have to read the text to see where we are at as there have been a lot of messages on this thread and updates from other related AD comments/disucusses.  I'm still concerned about a few things, but will see if that matters in the text.

I believe I responded on the heading for the mutual authentication suggesting that it should really be identifiers and authentication instead of mutual authentication.  I don't expect to see explicit guidelines on mutual auth, but with that as the header, I would have.

Thanks,
Kathleen

On Mon, Aug 22, 2016 at 8:46 AM, Susan Hares <[email-masked]> wrote:
> Cc: 'Andy Bierman'; 'Lou Berger'; [email-masked]; 'Alissa Cooper'; 
> [email-masked]; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 
> 'Joel Halpern'; 

-- 

Best regards,
Kathleen

---

From: [email-masked]
Date: Mon, 22 Aug 2016 12:30:25 -0400

Thank you, Sue.  I'll wait until then to review again.

Best regards,
Kathleen 

Sent from my iPhone

> On Aug 22, 2016, at 11:35 AM, Susan Hares <[email-masked]> wrote:
> 
> Kathleen:
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Aug 2016 10:06:43 -0700

On Mon, Aug 22, 2016 at 3:07 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > I also agree it is important to mention this non-secure/secure
> requirement to the PUSH work team we are both on.
> >
> >
> >
> > Should I change:
> >
> > Old: /
> >
This additional note is quite interesting.
It is 1 thing to decide if the data is public info or not.
(Assume security guidelines could be provided that clearly define that.)

It is quite another to say "it's OK if the monitoring data gets modified in
flight".
I can't imagine any use-cases for that.

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Aug 2016 15:45:49 -0400

I'm lagging in my email, as usual.  However, this one caught my eye:

> requests so they become a bottleneck in YANG RFC publication process?

I wanted to point out some of the per-object security evaluation that is
already imposed on MIB modules.  Consider the following text from RFC 4273:

:    There are a number of managed objects in this MIB that contain
:    sensitive information regarding the operation of a network.  For
:    example, a BGP peer's local and remote addresses might be sensitive
:    for ISPs who want to keep interface addresses on routers confidential
:    in order to prevent router addresses used for a denial of service
:    attack or spoofing.
: 
:    Therefore, it is important in most environments to control read
:    access to these objects and possibly to even encrypt the values of
:    these object when sending them over the network via SNMP.

In some respect, the discussion with regard to I2RS annotation of yang nodes
with security considerations have precedence.  It could be done in the
containing documents' security considerations section.  It could be part of
the description clause for the node.  

Having some notion of the consideration available as a machine-parseable
markup thus doesn't seem completely unreasonable.

The essence of your point, Andy, and I believe Juergen's is given a presmise
of "secure by default", is it okay to mark things as "the author of this
module believes this to be okay to be insecure by default"?

Possibly not.  As you both mention, it will depend on the circumstances of a
given operator's deployment.  

The underlying I2RS question is how to mark nodes in such a way that the
insecure transport protocols may be permitted to publish them without
requiring every single node to be audited if you have relatively weak
deployment considerations?  If the answer is "read the security
considerations and write a filter", it's not the answer i2rs is looking for.

-- Jeff

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 22 Aug 2016 15:51:09 -0400

> considerations and write a filter", it's not the answer i2rs is looking for.

I think it's just that it is easier to mark the items that require
confidentiality and integrity protection, when that is clear, rather
than trying to figure out that something is absolutely not in need of
any confidentiality and integrity protections.  In this case, you are
not saying that items don't need security, you are just not taking an
official stance and it's up to the user to turn on or off the default
knob for session transport security.

-- 

Best regards,
Kathleen

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Aug 2016 15:58:22 -0400

On Mon, Aug 22, 2016 at 03:51:09PM -0400, Kathleen Moriarty wrote:
> any confidentiality and integrity protections.

I think I2RS has done generally better than that.  When not so marked, the
intent is secure.

>From a syntactic standpoint, it's much nicer to add keywords for the
exceptions rather than the default. :-)

> In this case, you are

Mostly I'm saying that once you have annotated some data node as being "okay
to be insecure", the user can have tools to programmatically act upon that
based on information in the model.  Lacking that, we're back in SNMP land
wherein people have to put in per-object filters to implement this.

Note this is "can act".  It'd be fine to have your policy be "even if marked
insecure, leave secure".  It's even fine, IMO (but not as an author of this
document), for such "leave secure unless otherwise configured" to be the
mandatory to implement default.

I'm somewhat curious if you've done such configuration in SNMP.  It's a
PITA. :-)

-- Jeff

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 22 Aug 2016 16:08:13 -0400

> wherein people have to put in per-object filters to implement this.

One other important consideration from this discussion is the terms
used.  I have been careful to say needing confidentiality and
integrity protections, which is different from saying it needs to be
secure (or it doesn't need confidentiality and integrity protection).

> I'm somewhat curious if you've done such configuration in SNMP.  It's a

Not that it matters, but yes, one my masters degree projects involved
automating a bunch of functions in a service provider NOC with SNMP
and I wrote a MIB for one of my drafts that was later changed to XML.

Kathleen

-- 

Best regards,
Kathleen

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 23 Aug 2016 12:31:39 -0400

Andy: 

Rather than state “data model as 'non-confidential' remains a flawed” in the abstract, can we simply discuss the specifics I listed? 

1)      BGP information publically sent as part of route-views

Sent as an  event stream from an I2RS client 

2)      Web server “up” messages sent as an event 

With the text similar to:   “go-to-me.com web server is up”  where “go-to-me” is a public name. 

Please consider in terms of an Event stream model we are working in the push.  Remember the configuration of the stream is via secure servers, and what we are talking about is listeners to the stream.  

Sue Hares         

From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, August 22, 2016 1:07 PM
To: Juergen Schoenwaelder; Susan Hares; Andy Bierman; Lou Berger; [email-masked]; Alissa Cooper; [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

On Mon, Aug 22, 2016 at 3:07 AM, Juergen Schoenwaelder <[email-masked]> wrote:

It is quite another to say "it's OK if the monitoring data gets modified in flight".

 

/js

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Aug 2016 10:08:37 -0700

On Tue, Aug 23, 2016 at 9:31 AM, Susan Hares <[email-masked]> wrote:

> Andy:
>
>
>
> Rather than state “data model as 'non-confidential' remains a flawed” in
> the abstract, can we simply discuss the specifics I listed?
>
>
>

That was Juergen's comment.

I think the tagging proposal is OK if the standard protocol that YANG Push
designates as non-secure (HTTP?) is not allowed to send any YANG data
that is not properly tagged.

(If the protocol is allowed to ignore this extension, then the extension is
pointless.)

> Please consider in terms of an Event stream model we are working in the
> push.  Remember the configuration of the stream is via secure servers, and
> what we are talking about is listeners to the stream.
>

The actual data sent to listeners can be altered in flight.
This may be a low risk.  This is part of the decision WGs will
have to make to support non-secure transport of data in the data models.

Andy

> *Sent:* Monday, August 22, 2016 1:07 PM
> *To:* Juergen Schoenwaelder; Susan Hares; Andy Bierman; Lou Berger;
> [email-masked]; Alissa Cooper; [email-masked]; Kathleen Moriarty;
> IESG; Jeffrey Haas; Joel Halpern; draft-ietf-i2rs-protocol-
> [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 23 Aug 2016 13:20:50 -0400

Andy: 

Thanks for your input.  I’m sorry I got your comment confused with Juergen’s comment.   I agree with your solution.  The Yang Push designating a non-secure (HTTP/RESTCONF) is not allowed to send anything that is not properly tagged.   This works for the BGP event stream and the web service  up stream. 

Sue 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Tuesday, August 23, 2016 1:09 PM
To: Susan Hares
Cc: Juergen Schoenwaelder; Lou Berger; [email-masked]; Alissa Cooper; [email-masked]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Andy: 

 

(If the protocol is allowed to ignore this extension, then the extension is pointless.)

 

 

Sue Hares         

Andy

 

 

/js

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 23 Aug 2016 15:27:01 -0400

Jeff: 

Thank you your comments.   I agree with your assessment of the WG's desires.
It provides a helpful context for the IESG members.   

As I mentioned in another email, one of the first mechanisms is to describe
what portions of an data model can be sent in the PUB/SUB Push via a
non-secure HTTP session or what require a secure HTTP session.   
 
Sue 
-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Monday, August 22, 2016 3:46 PM
To: Andy Bierman
Cc: [email-masked]; Alissa Cooper; Juergen Schoenwaelder;
[email-masked]; Kathleen Moriarty; IESG; Joel Halpern; Lou Berger;
Susan Hares; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
COMMENT)

On Fri, Aug 19, 2016 at 07:23:47AM -0700, Andy Bierman wrote:
> Imagine if there was a debate for every single OBJECT-TYPE macro "is 
> this leaf OK for noAuth/noPriv?"
> 

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Aug 2016 13:16:44 -0700

> given operator's deployment.

I believe the actual annotation needs to apply to a specific subtree.
There are corner-cases where the module-wide annotation does not work
(such as groupings used in a different module).

IMO the annotation needs to apply only to descendant-or-self nodes
in the same module namespace.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Aug 2016 17:24:37 +0200

I fail to understand why it makes a difference whether something is
accessed via pub/sub or in a more traditional way. We need to look at
this from an architectural point of view. And I am a big fan of the
separation of mechanism from policy [1].

The question what can be sent over an insecure transport is a policy
decision of a specific deployment and hard-coding such policies
statically in a data model scares me. SNMP got this piece right since
SNMP left it to the access control subsystem to take the decision and
thus policies could be flexible.

If there is a need to document common policies that certain
applications may find useful, then simply write them down as NACM
rules in XML. (The only little issue is that NACM today does not know
whether a request came via a non-secure transport since it assumes
there are only secure transports. But this seems to be fixable and
required to fix if NETCONF indeed introduces non-secure transports.)

/js

[1] https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Aug 2016 09:06:18 -0400

Juergen,

> separation of mechanism from policy [1].

The main i2rs use case is pub-sub.  I personally have no objection if the
use of such a mechanism is made general and is tied to the security
properties of the transport rather than the transport type.

> thus policies could be flexible.

In my opinion, SNMP is often improperly secured since the mechanisms
provided to lock down sensitive objects puts too much onus on the users
to "get it right".  This is made particularly difficult by the lack of
machine parseable hints in SMIv2 and requires the users to dig through
conformance statements, textual conventions and security considerations of
the underlying document which may not even be available in the extracted
MIBs.

I will concede that by starting with "we're secure by default", a number of
such headaches with regard to the security of objects is remediated.  What
is missing is the ability to make it easy to expose objects that have less
sensitivity.

> required to fix if NETCONF indeed introduces non-secure transports.)

Presume NACM gained visibility into the security profile of a transport.

What would such common policies look like?  Where do they get published?
Can we make them machine extractable so they can be loaded onto routers as a
default profile for a given presumed security level?

My suspicion is much of such a profile would simply reduce to "the following
nodes are permitted to be covered by the lower security profile".  Having
markup in the yang to permit extraction by NACM without explicit enumeration
in a per-module fashion helps quite a bit.

-- Jeff