Last Call Review of draft-ietf-l3sm-l3vpn-service-model-16
review-ietf-l3sm-l3vpn-service-model-16-secdir-lc-orman-2016-10-14-00

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

    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?

       }
       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.  Should the provider arbitrarily change
the definition, the customer's configuration parameters might be
dangerously misinterpreted.  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?
           }
          }
          case pki {

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

Is "type of keys" supposed to imply the algorithm for key derivation?

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

I assume the profiles are the opaque "external identifiers"?
"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?

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.