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

[[e-mail]]

Hi Roman, 

Thank you for the review. Much appreciated.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Roman Danyliw via Datatracker [mailto:[e-mail]]
> Envoyé : dimanche 19 septembre 2021 23:21
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Roman Danyliw's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with
> DISCUSS and COMMENT)
> 
> 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?

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


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

[[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.";
     }

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

[[Med]] Thanks. 

> 
> ** 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?

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

> 
> Section 7.5.  Typo. s/rendez-vous/rendezvous/
> 
> YANG.  A few places. s/adresss/addresses/
> 
> 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.