Subject: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 05 Jan 2017 04:52:19 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-i2rs-yang-network-topo-10: No Objection

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-yang-network-topo/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Kathleen's discuss points and have one
more aspect to offer that I hope you include in that
discussion:

This model I think will lead designers to only think
about the nodes that are supposed to have access to
traffic.  (See also below about broadcast media.) The
model will generally not capture the reality that some
other nodes can also actually see or influence traffic
and I think that will lead to vulnerabilities not
being recognised. I don't have a good suggestion for
how to fix that problem but I do think you ought
mention it as a security consideration, e.g. something
like: "For models such as these - the real world
network may allow additional communications or links
that are not represented in the model and such links
may enable vulnerabilities that are liable to be
missed when considering only the model. These models
don't really capture the security or privacy aspects
of the network." 

- 4.2 and generally: It is not clear to me how to
represent broadcast media (e.g. radio) nor how IP
multicast would be reflected in this model. I assume
those can be done but as a bit of a hack.  

- nit: 6 authors and 4 contributors. I wish people
(esp chairs) would just enforce the 5 author guideline
and say why that's inappropriate in the few instances
in which that is the case.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Jan 2017 08:04:52 -0500

Stephen: 

Thank you for letting the authors know about your security concerns.  I think we have some discussion that needs to take place with the authors, Alia, and Benoit on whether the yang security guidelines are sufficient or if these need to be expanded based on the I2RS protocol security requirements.  

I appreciate Kathleen, you, Ben, and Benoit mentioning the privacy and security issues.  It will help us make sure the next I2RS documents submitted to the IESG have the appropriate security considerations and threat analysis. 

On the 6 authors, we really did investigate each authors active contribution.  

Sue Hares
Document shepherd. 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, January 5, 2017 7:52 AM
To: The IESG
Cc: [email-masked]; Susan Hares; [email-masked]; [email-masked]; [email-masked]
Subject: Stephen Farrell's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with 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.)

I agree with Kathleen's discuss points and have one more aspect to offer that I hope you include in that
discussion:

This model I think will lead designers to only think about the nodes that are supposed to have access to traffic.  (See also below about broadcast media.) The model will generally not capture the reality that some other nodes can also actually see or influence traffic and I think that will lead to vulnerabilities not being recognised. I don't have a good suggestion for how to fix that problem but I do think you ought mention it as a security consideration, e.g. something
like: "For models such as these - the real world network may allow additional communications or links that are not represented in the model and such links may enable vulnerabilities that are liable to be missed when considering only the model. These models don't really capture the security or privacy aspects of the network." 

- 4.2 and generally: It is not clear to me how to represent broadcast media (e.g. radio) nor how IP multicast would be reflected in this model. I assume those can be done but as a bit of a hack.  

- nit: 6 authors and 4 contributors. I wish people (esp chairs) would just enforce the 5 author guideline and say why that's inappropriate in the few instances in which that is the case.

---

From: Giles Heron <[email-masked]>
Date: Thu, 5 Jan 2017 13:50:41 +0000

Re broadcast media those are typically represented (in time-honoured fashion) as pseudonodes.   So while it’s a hack it’s a well-understood one.

For IP multicast you could model the tree for any given multicast group I suppose?

the security note comment makes sense at least to me as a non-author (but regular user) of the topology model.   In general the model only models what you have access to - you can’t guarantee it’s a full picture of the network (e.g. if you get L3 topology from BGP-LS then you’ll only see OSPF or ISIS nodes).

Giles

> On 5 Jan 2017, at 13:04, Susan Hares <[email-masked]> wrote:
> 
> Stephen: 
> 
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Benoit Claise <[email-masked]>
Date: Thu, 5 Jan 2017 14:55:05 +0100

Dear all,
> Thank you for letting the authors know about your security concerns.  I think we have some discussion that needs to take place with the authors, Alia, and Benoit on whether the yang security guidel…
This document contains a YANG model, a generic YANG model that could be 
accessed by NETCONF, RESTCONF, or the future I2RS protocol.
This document doesn't say (and that would be a mistake IMO if it would) 
that this YANG model can only be accessed by the I2RS protocol.
Hence I'm advocating that the security considerations diligently follow 
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that 
they don't go in the I2RS protocol specific details.

Regards, Benoit
> .

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Jan 2017 13:57:36 +0000

On 05/01/17 13:55, Benoit Claise wrote:
> Dear all,
>> Stephen:
>>
>> Thank you for letting the authors know about your security concerns. 
>> I think we have some discussion that needs to take place with the
>> authors, Alia, and Benoit on whether the yang security guidelines are
>> sufficient or if these need to be expanded based on the I2RS protocol
>> security requirements.

Just to note that my comment is about the generic
model and nothing to do with i2rs nor any other
protocol specific stuff.

I'll leave Sue and Benoit to discuss i2rs:-)

Cheers,
S.

> 
> Regards, Benoit
>>
>> I appreciate Kathleen, you, Ben, and Benoit mentioning the privacy and
>> security issues.  It will help us make sure the next I2RS documents
>> submitted to the IESG have the appropriate security considerations and
>> threat analysis.
>>
>> Cc: [email-masked]; Susan Hares;
>> [email-masked]; [email-masked]; [email-masked]
>> Subject: Stephen Farrell's No Objection on
>> draft-ietf-i2rs-yang-network-topo-10: (with COMMENT)
>>
>> email addresses included in the To and CC lines. (Feel free to cut
>> this introductory paragraph, however.)
>>
>>
>> This model I think will lead designers to only think about the nodes
>> that are supposed to have access to traffic.  (See also below about
>> broadcast media.) The model will generally not capture the reality
>> that some other nodes can also actually see or influence traffic and I
>> think that will lead to vulnerabilities not being recognised. I don't
>> have a good suggestion for how to fix that problem but I do think you
>> ought mention it as a security consideration, e.g. something
>> like: "For models such as these - the real world network may allow
>> additional communications or links that are not represented in the
>> model and such links may enable vulnerabilities that are liable to be
>> missed when considering only the model. These models don't really
>> capture the security or privacy aspects of the network."
>>
>> - 4.2 and generally: It is not clear to me how to represent broadcast
>> media (e.g. radio) nor how IP multicast would be reflected in this
>> model. I assume those can be done but as a bit of a hack.
>>
>> - nit: 6 authors and 4 contributors. I wish people (esp chairs) would
>> just enforce the 5 author guideline and say why that's inappropriate
>> in the few instances in which that is the case.
>>
>>
>>
>> .
>>
>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 5 Jan 2017 09:52:46 -0500

I agree. The statement you refer to is sufficient. 
We really need to get away from having to be more specific
than that in Yang models.

	—Tom

> On Jan 5, 2017:8:55 AM, at 8:55 AM, Benoit Claise <[email-masked]> wrote:
> 
> Dear all,
>> Stephen:
>> 
> This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol.
> This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol.
> Hence I'm advocating that the security considerations diligently follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details.
> 
> Regards, Benoit
>>