Subject: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Sun, 19 Sep 2021 14:21:11 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-opsawg-l3sm-l3nm-11: 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 DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/

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

** RFC8177 already defines a container to represent an individual key --
key-string – as both a string and hex format. Additionally, this representation
has built in ACLs to protect it.  This model appears to maximize flexibility by
supporting both key-chains and an explicit key for protocols like BGP, RIP and
ISIS.  Is there a reason why this model does not (or perhaps cannot) reuse the
key-string representation from RFC8177 (the same way key-chain is)? And/or to
not provide the flexibility for a hex encoded key?

** Section 9.  The text notes that ‘vpn-service’ is sensitive to write
operations.  Wouldn’t ‘vpn-profiles’ be equally sensitive to alterations with
similar consequences?  For example, altering an encryption-profile-identifier
could change the algorithm chosen or the key.

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

Thank you to Rifaat Shekh-Yusef for the SECDIR review.

To the authors: the explanatory text in Sections 4 and 7 made this large YANG
model very accessible.  It's sometimes hard to find the right balance between
the text narrative and letting the model speak for itself, but this document
negotiated it well.

** Section 7.6.5.  Could we ever end up in a situation where
security/enabled=True but the key-chain-ref pointed a key-chain who’s
crypto-algorithm was cleartext?

** Section 9.  In addition to sensitivity of customer-name and ip-connection to
read operation, wouldn’t the corresponding topology information revealed by
pretty much everything in vpn-service also be of concern?

** Section 9.  The text enumerating sensitive read operations provides no
caution about protecting the various key material.  RFC8177 is cited later, but
as noted in the DISCUSS, the suggested key wrap primitive is not usable with
instances of “key” as the hex-key-string feature is not supported.

** Typos:

Section 7.5.  Typo. s/rendez-vous/rendezvous/

YANG.  A few places. s/adresss/addresses/

YANG.  Typo. s/oubtound/outbound/

---

From: <[email-masked]>
Date: Wed, 22 Sep 2021 12:11:59 +0000

Hi Roman, 

Thank you for the review. Much appreciated.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Roman Danyliw via Datatracker [mailto:[email-masked]]
> Envoyé : dimanche 19 septembre 2021 23:21
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Roman Danyliw's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with
> DISCUSS and COMMENT)
> 
> key-string – as both a string and hex format. Additionally, this
> representation has built in ACLs to protect it.  This model appears to
> maximize flexibility by supporting both key-chains and an explicit key
> for protocols like BGP, RIP and ISIS.  Is there a reason why this model
> does not (or perhaps cannot) reuse the key-string representation from
> RFC8177 (the same way key-chain is)? And/or to not provide the
> flexibility for a hex encoded key?

[[Med]] We are echoing what is supported by the device models where the explicit key is supported. For example, 

* RFC8695 for RIP supports the following:

       |     +--rw authentication
       |     |  +--rw (auth-type-selection)?
       |     |     +--:(auth-key-chain)
       |     |     |  +--rw key-chain? key-chain:key-chain-ref
       |     |     +--:(auth-key)
       |     |        +--rw key?                string
       |     |        +--rw crypto-algorithm?   identityref

* draft-ietf-isis-yang-isis-cfg for IS-IS supports the following:

          |  +--rw (authentication-type)?
          |  |  +--:(key-chain) {key-chain}?
          |  |  |  +--rw key-chain?            key-chain:key-chain-ref
          |  |  +--:(password)
          |  |     +--rw key?                string
          |  |     +--rw crypto-algorithm?   identityref

> operations.  Wouldn’t ‘vpn-profiles’ be equally sensitive to alterations
> with similar consequences?  For example, altering an encryption-profile-
> identifier could change the algorithm chosen or the key.

[[Med]] We didn't because the profiles are defined with the following (see the common I-D):

"nacm:default-deny-write;"

And that we are saying the following under security considerations:

   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset of all available NETCONF or
   RESTCONF protocol operations and content.

FWIW, RFC8341 defines the default-deny-write as follows: 

     extension default-deny-write {
       description
         "Used to indicate that the data model node
          represents a sensitive security system parameter.

          If present, the NETCONF server will only allow the designated
          'recovery session' to have write access to the node.  An
          explicit access control rule is required for all other users.

          If the NACM module is used, then it must be enabled (i.e.,
          /nacm/enable-nacm object equals 'true'), or this extension
          is ignored.

          The 'default-deny-write' extension MAY appear within a data
          definition statement.  It is ignored otherwise.";
     }

> To the authors: the explanatory text in Sections 4 and 7 made this large
> YANG model very accessible.  It's sometimes hard to find the right
> balance between the text narrative and letting the model speak for
> itself, but this document negotiated it well.

[[Med]] Thanks. 

> crypto-algorithm was cleartext?

[[Med]] Not sure to get the question. Are you referring to customer-key-chain under security?

                         |  +--rw encryption-profile
                         |     +--rw (profile)?
                         |        +--:(provider-profile)
                         |        |  +--rw profile-name?         leafref
                         |        +--:(customer-profile)
                         |           +--rw customer-key-chain?
                         |                   kc:key-chain-ref

> 
> ** Section 9.  In addition to sensitivity of customer-name and ip-
> connection to read operation, wouldn’t the corresponding topology
> information revealed by pretty much everything in vpn-service also be of
> concern?
> 

[[Med]] The ip-connection is more a concern as it include details about the CE, not the node topology (PEs) as these are shared between many customers.

> ** Section 9.  The text enumerating sensitive read operations provides
> no caution about protecting the various key material.  RFC8177 is cited
> later, but as noted in the DISCUSS, the suggested key wrap primitive is
> not usable with instances of “key” as the hex-key-string feature is not
> supported.

[[Med]] Do you have in mind a specific text we can add? Thanks. 

> ** Typos:

[[Med]] Fixed all those. Thanks.

> YANG.  Typo. s/oubtound/outbound/

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Mon, 27 Sep 2021 09:29:24 +0000

Hi Roman, 

A new version that echo the replies already provided in this this thread is available:

URL:            https://www.ietf.org/archive/id/draft-ietf-opsawg-l3sm-l3nm-12.txt 
Status:         https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/ 
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm 
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-l3sm-l3nm-12

Some more context is provided inline for some changes made in this version to better address your comments. 

Please let me know if you still have any comment. Thanks. 

Cheers,
Med

> De : OPSAWG [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : mercredi 22 septembre 2021 14:12
> À : Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked]; opsawg-
> [email-masked]
> Objet : Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-l3sm-
> l3nm-11: (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> > De : Roman Danyliw via Datatracker [mailto:[email-masked]] Envoyé :
> > dimanche 19 septembre 2021 23:21 À : The IESG <[email-masked]> Cc :
> > [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked] Objet :
> > Roman Danyliw's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with
> > DISCUSS and COMMENT)
> >
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > ** RFC8177 already defines a container to represent an individual key
> > -- key-string – as both a string and hex format. Additionally, this
> > for protocols like BGP, RIP and ISIS.  Is there a reason why this
> > model does not (or perhaps cannot) reuse the key-string representation
> > from

[[Med]] Made this change to echo this: 

OLD: 
   Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely
   upon [RFC8177] for authentication purposes.  Therefore, this module
   inherits the security considerations discussed in Section 5 of
   [RFC8177].  

NEW:
   Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely
   upon [RFC8177] for authentication purposes.  Therefore, this module
   inherits the security considerations discussed in Section 5 of
   [RFC8177].  Also, these data nodes support supplying explicit keys as
   strings in ASCII format.  The use of keys in hexadecimal string
   format would afford greater key entropy with the same number of key-
   string octets.  However, such format is not included in this version
   of the L3NM because it is not supported by the underlying device
   modules (e.g., [RFC8695]).

> > operations.  Wouldn’t ‘vpn-profiles’ be equally sensitive to
> > alterations with similar consequences?  For example, altering an
> > encryption-profile- identifier could change the algorithm chosen or
> the key.
> 

[[Med]] After thinking about this, I added this text as the tagging in the common-vpn module may not be trivial:

NEW:
   o  'vpn-profiles': This container includes a set of sensitive data
      that influence how the L3VPN service is delivered.  For example,
      an attacker who has access to these data nodes may be able to
      manipulate routing policies, QoS policies, or encryption
      properties.  These data nodes are defined with "nacm:default-deny-
      write" tagging [I-D.ietf-opsawg-vpn-common].

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 29 Sep 2021 20:16:00 +0000

Hi Med!

Thanks for the revised draft.  Your explanations and those updates addressed all of my feedback but the one noted in line below.  I've updated my ballot to reflect that.

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of
> Sent: Wednesday, September 22, 2021 8:12 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; opsawg-
> [email-masked]; [email-masked]
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with
> DISCUSS and COMMENT)

[snip] 

> > no caution about protecting the various key material.  RFC8177 is
> > cited later, but as noted in the DISCUSS, the suggested key wrap
> > primitive is not usable with instances of “key” as the hex-key-string
> > feature is not supported.
> 

I was looking for something to align with the YANG security template.

OLD:
These are the subtrees and data
   nodes and their sensitivity/vulnerability:

   *  'customer-name' and 'ip-connection': An attacker can retrieve
      privacy-related information which can be used to track a customer.
      Disclosing such information may be considered as a violation of
      the customer-provider trust relationship.

NEW

These are the subtrees and data
   nodes and their sensitivity/vulnerability:

   *  'customer-name' and 'ip-connection': An attacker can retrieve
      privacy-related information which can be used to track a customer.
      Disclosing such information may be considered as a violation of
      the customer-provider trust relationship.

* 'keying-material': An attacker can retrieve the cryptographic keys protecting the underlying VPN service.  These keys could be used to disrupt or alter the configuration of the service.

Regards,
Roman

---

From: <[email-masked]>
Date: Thu, 30 Sep 2021 04:35:57 +0000

Hi Roman, 

Thank you. 

Please see one comment inline.

Cheers,
Med 

> De : Roman Danyliw <[email-masked]>
> Envoyé : mercredi 29 septembre 2021 22:16
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; The IESG
> <[email-masked]>
> Objet : RE: Roman Danyliw's Discuss on draft-ietf-opsawg-l3sm-l3nm-11:
> (with DISCUSS and COMMENT)
> 
> Hi Med!
> 
> Thanks for the revised draft.  Your explanations and those updates
> addressed all of my feedback but the one noted in line below.  I've
> updated my ballot to reflect that.
> 
> > Subject: RE: Roman Danyliw's Discuss on
> > draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS and COMMENT)
> 
> [snip]
> 
> > > ** Section 9.  The text enumerating sensitive read operations
> > > provides no caution about protecting the various key material.
> > > RFC8177 is cited later, but as noted in the DISCUSS, the suggested
> > > key wrap primitive is not usable with instances of “key” as the
> > > hex-key-string feature is not supported.
> >
> * 'keying-material': An attacker can retrieve the cryptographic keys
> protecting the underlying VPN service.  These keys could be used to
> disrupt or alter the configuration of the service.

[Med] As this is about considerations related to readable data nodes, I went with this wording:

NEW:
   o  'keying-material': An attacker can retrieve the cryptographic keys
      protecting the underlying VPN service (CE-PE routing, in
      particular).  These keys could be used to inject spoofed routing
      advertisements.

I also made this change to cover the writeable case: 

OLD:
   o  'vpn-services': An attacker who is able to access network nodes
      can undertake various attacks, such as deleting a running L3VPN
      service, interrupting all the traffic of a client.  In addition,
      an attacker may modify the attributes of a running service (e.g.,
      QoS, bandwidth, routing protocols),
NEW:
   o  'vpn-services': An attacker who is able to access network nodes
      can undertake various attacks, such as deleting a running L3VPN
      service, interrupting all the traffic of a client.  In addition,
      an attacker may modify the attributes of a running service (e.g.,
      QoS, bandwidth, routing protocols, keying material),
                                         ^^^^^^^^^^^^^^^^

These two changes will be in -16.

Thank you again for the review. Much appreciated.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 30 Sep 2021 12:18:15 +0000

Hi Med!

The changes described below is even clearer text than I proposed.  Thanks for merging it into -16.

Roman

> From: [email-masked] <[email-masked]>
> Sent: Thursday, September 30, 2021 12:36 AM
> > Envoyé : mercredi 29 septembre 2021 22:16 À : BOUCADAIR Mohamed
> > INNOV/NET <[email-masked]>; The IESG <[email-masked]>
> Cc
> > : [email-masked]; [email-masked]; opsawg-
> > [email-masked]; [email-masked] Objet : RE: Roman Danyliw's
> > Discuss on draft-ietf-opsawg-l3sm-l3nm-11:
> ___________________________________________________________________
> ______________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.