Subject: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-yang-network-topo-10: (with DISCUSS)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 04 Jan 2017 13:33:45 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-i2rs-yang-network-topo-10: 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-yang-network-topo/

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

Thanks for your work on this draft.

I have a couple of things I'd like to discuss that may require some
additional text, but should be easy to resolve.

1. Privacy considerations - I don't see any listed and the YANG module
include a few identifiers as well as ways to group devices.  I think
privacy considerations need to be added for use of this module.

2. Security - the network topology and inventory created by this module
reveals information about systems and services.  This could be very
helpful information to an attacker and should also be called out as a
security consideration. The access and transport of this information is
covered though in the considerations, just listing this threat would be
helpful.

Thank you.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 4 Jan 2017 18:52:13 -0500

Kathleen:

I'm confused by your request. I thought draft-ietf-i2rs-protocol-security-requirements-17.txt was written to answer this questions for all I2RS modules.  We knew this new style of interface with Yang modules had these privacy and security constraints.  This data module SHOULD only run under the protocol security constraints listed in the draft-ietf-i2rs-protocol-security-requirements-17.txt module.  This document left out of this yang module because I thought we covered in the global document.   Each of the I2RS global modules provides information will have these concerns.  Let me review these concerns: 

·         Topology modules - you correctly note that the draft -i2rs-yang-network-topology model has privacy concerns regarding the identifiers and grouping of devices.  You also correctly note that network topology and network inventory can be used to attack the modules. 

·         RIB modules - You should understand the I2RS RIB has grouping and names that could be used to identify groups of routes.  In addition, RIB information quickly inserted/pulled from nodes is an attack vector. 

·         FB RIB module - The filter based RIBS indicates the filters that control forwarding of data on selected interfaces.  It uses group names to group these filters for companies or to group filters by function.   You can expand the topology concerns to the filters as well. 

·         The I2NSF data modules build upon these concepts.   

Do you wish threat sections in each module?  Could you provide a template for these threat comments.  If you wish to limit group identifiers in all of these modules, it would be good to provide write-up on what is good/bad group identifiers so the authors provide the 

In future SEC-DIR reviews, it would be good for your reviewers to specifically examine the document to see if these issues have been addressed. 

Sue Hares (shepherd) 

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

1. Privacy considerations - I don't see any listed and the YANG module include a few identifiers as well as ways to group devices.  I think privacy considerations need to be added for use of this module.

2. Security - the network topology and inventory created by this module reveals information about systems and services.  This could be very helpful information to an attacker and should also be called out as a security consideration. The access and transport of this information is covered though in the considerations, just listing this threat would be helpful.

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Wednesday, January 4, 2017 4:34 PM
To: The IESG
Cc: [email-masked]; Susan Hares; [email-masked]; [email-masked]; [email-masked]
Subject: Kathleen Moriarty's Discuss on draft-ietf-i2rs-yang-network-topo-10: (with 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> https://www.ietf.org/iesg/statement/discuss-criteria.html

 

 <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/

DISCUSS:

I have a couple of things I'd like to discuss that may require some additional text, but should be easy to resolve.

1. Privacy considerations - I don't see any listed and the YANG module include a few identifiers as well as ways to group devices.  I think privacy considerations need to be added for use of this module.

2. Security - the network topology and inventory created by this module reveals information about systems and services.  This could be very helpful information to an attacker and should also be called out as a security consideration. The access and transport of this information is covered though in the considerations, just listing this threat would be helpful.

Thank you.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Jan 2017 21:03:41 -0500

Hi Sue,

Thanks for your quick and detailed response.  inline

On Wed, Jan 4, 2017 at 6:52 PM, Susan Hares <[email-masked]> wrote:

> Kathleen:
>
>
>
> I'm confused by your request. I thought draft-ietf-i2rs-protocol-security-requirements-17.txt
> was written to answer this questions for all I2RS modules.  We knew this
> new style of interface with Yang modules had these privacy and security
> constraints.  This data module SHOULD only run under the protocol security
> constraints listed in the draft-ietf-i2rs-protocol-security-requirements-17.txt
> module.  This document left out of this yang module because I thought we
> covered in the global document.   Each of the I2RS global modules provides
> information will have these concerns.
>

I just looked again and there is no reference to the requirements document
in the security considerations section that says, look here for the
additional security and privacy considerations.  That's why it didn't occur
to me when reading the draft.

>   Let me review these concerns:
>
>
>
> ·         Topology modules - you correctly note that the draft
> -i2rs-yang-network-topology model has privacy concerns regarding the
> identifiers and grouping of devices.  You also correctly note that network
> topology and network inventory can be used to attack the modules.
>
> You may want to call out the specific identifiers (in a list) in the
security considerations section when you reference the security
requirements draft.  It's helpful to have specifics about a draft called
out that go beyond the general requirements document.

>
>
> ·         RIB modules - You should understand the I2RS RIB has grouping
> and names that could be used to identify groups of routes.  In addition,
> RIB information quickly inserted/pulled from nodes is an attack vector.
>
>
>
> ·         FB RIB module - The filter based RIBS indicates the filters
> that control forwarding of data on selected interfaces.  It uses group
> names to group these filters for companies or to group filters by
> function.   You can expand the topology concerns to the filters as well.
>

Please do call out these concerns explicitly.  It may help developers and
implementers.

> Do you wish threat sections in each module?  Could you provide a template
> for these threat comments.  If you wish to limit group identifiers in all
> of these modules, it would be good to provide write-up on what is good/bad
> group identifiers so the authors provide the
>

I called out identifiers specifically as this document had a few and that
is something to watch for per RFC6973.  Your other comments are helpful and
would aid a reader.

>
>
> In future SEC-DIR reviews, it would be good for your reviewers to
> specifically examine the document to see if these issues have been
> addressed.
>

Yes, if you'd like to add the concerns that have come up in the recent
document reviews to the discussion on the SAAG list for 3552, that would be
very helpful.  That document needs revision, but really needs input from
cross area contributors as they are the intended audience.  Please help us
get that draft to a state that it assists editors from other areas.

Thank you,
Kathleen

> reveals information about systems and services.  This could be very helpful
> information to an attacker and should also be called out as a security
> consideration. The access and transport of this information is covered
> though in the considerations, just listing this threat would be helpful.
>
>
>
>
>
> Cc: [email-masked]; Susan Hares;
> [email-masked]; [email-masked]; [email-masked]
> reveals information about systems and services.  This could be very helpful
> information to an attacker and should also be called out as a security
> consideration. The access and transport of this information is covered
> though in the considerations, just listing this threat would be helpful.
>
>
>
> Thank you.
>
>
>
>
>
>
>
>
>

-- 

Best regards,
Kathleen

---

From: Benoit Claise <[email-masked]>
Date: Thu, 5 Jan 2017 12:45:43 +0100

> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines template 
should be applied (I mentioned that in a previous review).
The first paragraph of the Security Considerations is right, but the 
rest of the section doesn't quite follow the template (which is 
something that the RFC editor will check).
For example, the following should be copied verbatim:

    There are a number of data nodes defined in this YANG module that
    are writable/creatable/deletable (i.e., config true, which is the
    default). These data nodes may be considered sensitive or vulnerable
    in some network environments. Write operations (e.g., edit-config)
    to these data nodes without proper protection can have a negative
    effect on network operations. These are the subtrees and data nodes
    and their sensitivity/vulnerability:

And <list subtrees and data nodes and state why they are sensitive> 
should be populated, based on the second paragraph of the current 
Security Considerations.

Regarding your point "the network topology and inventory created by this 
module reveals information about systems and services. This could be 
very helpful information to an attacker and should also be called out as 
a security consideration.", I believe that this is covered by the 
previous paragraph. as most nodes are config-true.

Regarding the "listing this threat would be helpful.", I'm not convinced 
that this is necessary to change the security guidelines YANG template.
As a comparison on how we've been documenting security considerations 
for MIB modules, see https://trac.ietf.org/trac/ops/wiki/mib-security

Regards, Benoit

> .

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 5 Jan 2017 09:16:51 -0500

Hi Benoit,

On Thu, Jan 5, 2017 at 6:45 AM, Benoit Claise <[email-masked]> wrote:

> The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/
>
>
>
> The first paragraph of the Security Considerations is right, but the rest
> of the section doesn't quite follow the template (which is something that
> the RFC editor will check).
> There are a number of data nodes defined in this YANG module that are
> writable/creatable/deletable (i.e., config true, which is the default).
> These data nodes may be considered sensitive or vulnerable in some network
> environments. Write operations (e.g., edit-config) to these data nodes
> without proper protection can have a negative effect on network operations.
> These are the subtrees and data nodes and their sensitivity/vulnerability:
>
> And <list subtrees and data nodes and state why they are sensitive> should
> be populated, based on the second paragraph of the current Security
> Considerations.
>
> module reveals information about systems and services. This could be very
> security consideration.", I believe that this is covered by the previous
> paragraph. as most nodes are config-true.
>

Sure, the template does help since stating they are sensitive is similar
enough to stating revealing information is possible.  We wouldn't care if
it wasn't sensitive or could help an attacker.

> that this is necessary to change the security guidelines YANG template.

Yes, please do use the template.  I think because aSue asked about a
specific template to I2RS, I was thrown a bit.  The YANG template would be
appropriate and they should also include links to any I2RS documents that
contain relevant security considerations.

Thank you,
Kathleen

> As a comparison on how we've been documenting security considerations for
> MIB modules, see https://trac.ietf.org/trac/ops/wiki/mib-security
>
> Regards, Benoit
>
>
> Thank you.
>
>
>
>
> .
>
>
>
>

-- 

Best regards,
Kathleen