Re: [secdir] Security review of draft-ietf-l3sm-l3vpn-service-model-16 YANG Data Model for L3VPN service delivery

[<[e-mail]>]

Hi,

Please find some comments inline

Thanks

-----Original Message-----
From: Hilarie Orman [mailto:[e-mail]] 
Sent: Monday, October 10, 2016 21:05
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Security review of draft-ietf-l3sm-l3vpn-service-model-16 YANG Data Model for L3VPN service delivery

[Including subject line on resend]

Security review of YANG Data Model for L3VPN service delivery
draft-ietf-l3sm-l3vpn-service-model-16

Do not be alarmed.  I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The document uses the YANG data model to describe an abstracted view of Layer 3 Provider Provisioned VPN services.

The model has specific support for describing authentication and encryption requirements.  Perhaps I'm not imaginative enough to understand how they would be used, but my impression is that the models are incomplete.

    grouping site-security-authentication {
     container authentication {
      description
       "Authentication parameters";
     }
     description
      "This grouping defines authentication
      parameters
      for a site";
    }




In the data model shown above for "authentication", I'm not sure who the parties in the authentication are and where enforcement takes place.  This may be evident to those who are more familiar with VPN provisioning.  If so, some additional description would be helpful.

[SLI] We are not defining any authentication mechanism in the model. The container is just there to allow easy augmentation. This is stated in section 5.9.1.



    grouping site-security-encryption {
     container encryption {
      if-feature encryption;
      leaf enabled {
       type boolean;
       description
        "If true, access encryption is required.";
      }
      leaf layer {
       type enumeration {
        enum layer2 {
         description
          "Encryption will occur at layer2.";
        }
        enum layer3 {
         description
          "IPSec is requested.";
        }

Is IPSec the only layer 3 encryption method that is supported?
[SLI] I think the description is bad, it can be any layer 3 encryption mechanism, IPSec is one.

       }
       description
        "Layer on which encryption is applied.";
      }
      container encryption-profile {
       choice profile {
        case provider-profile {
         leaf profile-name {
          type string;
          description
           "Name of the SP profile
           to be applied.";

The "SP profile" is something defined by the service provider.  All the parameters and their interpretations are defined in some out-of-band way by the service provider.  This seems to impose a great deal of difficulty for the customer. 
[SLI] Yes there is a need of out of band discussion. Operator is allowing customer to use a set of profiles. It's not really difficult as today, most of the SPs works this way with customers.

 Should the provider arbitrarily change the definition, the customer's configuration parameters might be dangerously misinterpreted.  
[SLI] We usually do not change the definition of the profile because it is linked to a particular service selled to a customer. We can change parameters that does not affect the service.

Or, a customer trying to move to a different service provider might see a similar profile and try to use the same parameters.  Subtle differences in interpretation could lead to a security vulnerability.

         }
        }
        case customer-profile {
         leaf algorithm {
          type string;
          description
           "Encryption algorithm to
           be used.";
         }
         choice key-type {
          case psk {
           leaf preshared-key {
            type string;
            description
             "Key coming from
             customer.";

How does the customer submit the key?  Should there be a key identifier?  Perhaps the customer and the provider have a public key communication channel and the customer encrypts the keys and sends them to the provider, identifying them through the key identifiers?
Is there a key update procedure?
[SLI] The only supported method here is to submit the key through the RESTCONF or NETCONF over a secured channel.

           }
          }
          case pki {

          }
          description
           "Type of keys to be used.";

Is "type of keys" supposed to imply the algorithm for key derivation?
[SLI] The model does not support PKI, container is there just for augmentation. This is not highlighted , I can add it.

         }
        }
        description
         "Choice of profile.";
       }
       description
        "Profile of encryption to be applied.";
      }

I assume the profiles are the opaque "external identifiers"?
[SLI] Right.

"5.14.  External ID references

   The service model sometimes refers to external information through
   identifiers.  As an example, to order a cloud-access to a particular
   Cloud Service Provider (CSP), the model uses an identifier to refer
   to the targeted CSP.  In case, a customer is using directly this
   service model as an API (through REST or NETCONF for example) to
   order a particular service, the service provider should provide a
   list of authorized identifiers.  In case of cloud-access, the service
   provider will provide the identifiers associated of each available
   CSP.  The same applies to other identifiers like std-qos-profile, oam
   profile-name, provider-profile for encryption ...

   How SP provides those identifiers meaning to the customer is out of
   scope of this document."


If the request is spoofed or misunderstood in some way, then the encryption may be downgraded.  How is the configuration protected?

[SLI] I'm not sure it does really deal with this service model itself, it's more a global issue that the SP need to address.

I think there should be a way to sign a model.  There is an implied contract between the customer and the network owner, and the authenticity of the request seems paramount.

An example of the very confusing typos that are sprinkled throughout the document:
  "I want my current site-network-access to be not be connected on the
   same PoP ..."

Another confusing statement:
"1.  Introduction

   This document defines a YANG data model for communication between
   customers and network operators, and to provide input to automated
   control and configuration applications.
"

The introduction does not conform to the rules of English grammar.
I'm not entirely sure what it means.  Perhaps

" This document defines a YANG data model.  The model defines elements
   that can be used in communication protocols between customers and
   network operators.  Those elements can be used also as input to
   automated control and configuration applications.  "  ??

The document is marred by running afoul of the two notoriously difficult aspects of English grammar: subject/verb agreement and articles.  The errors are too numerous to mention.  For the most part, the meaning of the afflicted sentences is clear, but not always.  The document should not be published until the errors are corrected.

_________________________________________________________________________________________________________________________

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.