A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services
draft-ietf-tsvwg-le-phb-10

[Ballot comment]
Thanks for addressing the TSV-ART comments (and thanks Olivier for the review)!

Two mostly editorial comments from my side:

1) In sec 3: "nor should packets be "downgraded" to the LE PHB  instead of being dropped"
I would suggest to use proper normative language here, e.g. "and packets SHOULD NOT be "downgraded" to the LE PHB instead of being dropped".

2) I would recommend to add a reference to rfc8087 at the end of section 4.

[Ballot comment]
I was not sure how this behavior in Section 8 is expected to be deployed and used.

"  A DS domain that still uses DSCP CS1 for marking LE traffic
  (including Low Priority-Data as defined in [RFC4594] or the old
  definition in [RFC3662]) SHOULD remark traffic to the LE DSCP
  '000001' at the egress to the next DS domain."

Is the expectation that even on a domain that has not been updated to use the new DSCP there will be some node at the edge that will have been updated? If so, it might be good to explicitly note this. If not, I cannot see how a legacy node will follow this recommendation.

[Ballot comment]
--- Original DISCUSS position for hysterical raisins ---
I believe that this should be trivial DISCUSS to address, but I thought it important enough to warrant it. I'm OK with basically whatever you answer, I just wanted to make sure this had been seen and considered.

"An LE PHB SHOULD NOT be used for a customer’s "normal Internet"
  traffic nor should packets be "downgraded" to the LE PHB instead of
  being dropped, particularly when the packets are unauthorized
  traffic.  "

Great, sounds good to me -- but in the USA at least, there is are many cell phone plans which are "unlimited", but after some amount of traffic (e.g 22GB) your connection gets throttled to a lower data rate. Is this traffic still 'a customer's "normal Internet" traffic"? Is it appropriate (whatever that means) to downgrade this traffic to the LE PHB?
I understand not wanting to touch this issue with  a 10 foot pole (and I don't know what the right answer is!), but you *did* open this can of worms by talking about what classification user traffic should have.

Note: I'm happy to clear my DISCUSS no matter what the answer is, I just want to make sure it has been considered / discussed.

---------

Major:
"Some network providers keep link utilization below 50% to ensure that all traffic is forwarded without loss after rerouting caused by a link failure (cf.Section 6 of [RFC3439]).  LE marked traffic can utilize the normally unused capacity and will be preempted automatically in case of link failure when 100% of the link capacity is required for all other traffic. "
Yup - very true. But I think it needs to be mentioned that the provider will need to upgrade their monitoring / management system so that they can see the traffic lass. If they monitoring circuit utilization using e.g interface counters (and not by traffic class), a link may have 1% "real" traffic and 90% LE traffic, and it will look like it it 91% "full". I don't have any suggested text to address this (and this is just a comment, so "well, duh, they should know that anyway!" is a fine answer.)


Nits:
"A main problem is that multicast" -- I'm not sure you can say "A main" - main implies singular.; I'd suggest "The main" or "A major".

"However,using the Lower Effort PHB for multicast requires to pay special" -- "requires paying"...

[Ballot comment]
I think Warren hit on my concern. There seems to be mixed concepts regarding
how the markings are done. E.g.:
"However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to LE on a regular basis without consent or knowledge of the user."

Maybe for some users, an operator informs the "user" how their traffic is
marked, but I think it is more of a service contract, doesn't spell out this
detail. Especially if multi-domain. And traffic can be re-marked
(RFC7657/section 3.2). This is really per operator implementation.

Suggest remove this sentence, especially RC2119 language. Agree
also with Warren's examples to fix.

[Ballot comment]
I think Warren hit on my concern. There seems to be mixed concepts regarding
how the markings are done. E.g.:
"However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to LE on a regular basis without consent or knowledge of the user."

Maybe for some users, an operator informs the "user" how their traffic is
marked, but I think it is more of a service contract, doesn't spell out this
detail. Especially if multi-domain. And traffic can be re-marked
(RFC7657/section 3.2).

Suggest remove this sentence, especially RC2119 language. Agree
also with Warren's examples to fix.

[Ballot comment]
= Section 3 =

"An LE PHB SHOULD NOT be used for a customer's "normal Internet"
  traffic nor should packets be "downgraded" to the LE PHB instead of
  being dropped, particularly when the packets are unauthorized
  traffic."

I would recommend against mixing normative and non-normative keywords for a sequence of behaviors listed in the same sentence. I can't determine why one of these is normative and the other not.

"There is no intrinsic reason to limit the applicability of the LE PHB
  to any particular application or type of traffic."

I get the idea of not wanting to imply any kind of limitation, but wouldn't use cases of applying this to real-time traffic be pretty rare? That seems like a caveat worth explaining.

= Section 15 =

RFC 8174 should be a normative reference.

[Ballot comment]
Thank you for a well written document.

I only have one nit about the document title:

  A Lower Effort Per-Hop Behavior (LE PHB)

Please use a better title that makes it clearer to readers what are you talking about. Looking at RFC 3662 I see:

  A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services

I think the part "for Differentiated Services" would be very helpful.

[Ballot discuss]
Thanks for this effort. The draft appears to be in good shape overall; I just have one process point I would like to DISCUSS before approval:

Section 12 appears to be an update to draft-ietf-tsvwg-rtcweb-qos, which is currently in the RFC Editor queue in the MISSREF state. It's not clear to me what the intent of this section is, but if the idea is to formally update a _draft_, then please do not do that. The right way to proceed would be to pull draft-ietf-tsvwg-rtcweb-qos from the RFC editor queue and make the changes there.

The UPDATES relationship is intended for updating RFCs, which are otherwise immutable. Drafts, even post-IESG approval and in the RFC editor queue can still be changed. Making readers figure out the update between two different RFCs when there is an option to just fix the draft would be a disservice to readers.

[Ballot discuss]
I believe that this should be trivial DISCUSS to address, but I thought it important enough to warrant it. I'm OK with basically whatever you answer, I just wanted to make sure this had been seen and considered.

"An LE PHB SHOULD NOT be used for a customer’s "normal Internet"
  traffic nor should packets be "downgraded" to the LE PHB instead of
  being dropped, particularly when the packets are unauthorized
  traffic.  "

Great, sounds good to me -- but in the USA at least, there is are many cell phone plans which are "unlimited", but after some amount of traffic (e.g 22GB) your connection gets throttled to a lower data rate. Is this traffic still 'a customer's "normal Internet" traffic"? Is it appropriate (whatever that means) to downgrade this traffic to the LE PHB?
I understand not wanting to touch this issue with  a 10 foot pole (and I don't know what the right answer is!), but you *did* open this can of worms by talking about what classification user traffic should have.

Note: I'm happy to clear my DISCUSS no matter what the answer is, I just want to make sure it has been considered / discussed.

[Ballot comment]
Major:
"Some network providers keep link utilization below 50% to ensure that all traffic is forwarded without loss after rerouting caused by a link failure (cf.Section 6 of [RFC3439]).  LE marked traffic can utilize the normally unused capacity and will be preempted automatically in case of link failure when 100% of the link capacity is required for all other traffic. "
Yup - very true. But I think it needs to be mentioned that the provider will need to upgrade their monitoring / management system so that they can see the traffic lass. If they monitoring circuit utilization using e.g interface counters (and not by traffic class), a link may have 1% "real" traffic and 90% LE traffic, and it will look like it it 91% "full". I don't have any suggested text to address this (and this is just a comment, so "well, duh, they should know that anyway!" is a fine answer.)


Nits:
"A main problem is that multicast" -- I'm not sure you can say "A main" - main implies singular.; I'd suggest "The main" or "A major".

"However,using the Lower Effort PHB for multicast requires to pay special" -- "requires paying"...

[Ballot comment]
Two mostly editorial comments:

1) In sec 3: "nor should packets be "downgraded" to the LE PHB  instead of being dropped"
I would suggest to use proper normative language here, e.g. "and packets SHOULD NOT be "downgraded" to the LE PHB instead of being dropped".

2) I would recommend to add a reference to rfc8087 at the end of section 4.

[Ballot comment]
This document is generally in fine shape, and has some good discussion
in it.  I basically just have some editorial suggestions.

As one general note, the text sometimes seems to present a mixed story,
for example in the case of "downgrading" traffic from other PHBs.  We're
told to in general not do this instead of dropping traffic, but on the
other hand an example use of the LE PHB is for downgrading traffic from
some other PHB (but only when it does not violate the operational
objectives of that other PHB).  Greater clarity on who is authorized to
decide to downgrade, and in what cases it makes sense, could be useful.
In a similar vein, the text sometimes suggests a dichotomy between use
of the LE PHB for "preemptable" traffic vs. as a "scavenger" service
class, and at other times suggests that these usages are identical.  But
those are, of course, editorial matters.

Abstract

                                        The primary objective of this LE
  PHB is to protect best-effort (BE) traffic (packets forwarded with
  the default PHB) from LE traffic in congestion situations, i.e., when
  resources become scarce, best-effort traffic has precedence over LE
  traffic and may preempt it.  Alternatively, packets forwarded by the
  LE PHB can be associated with a scavenger service class, i.e., they
  scavenge otherwise unused resources only.  [...]

It seems like "preemptable" and "scavenger" are being deliberately
conflated, but are not necessarily the same.

Section 3

  (e.g., if a transport connection fails due to timing out, the
  application may try several times to re-establish the transport
  connection in order to resume the application session before finally

There was some directorate review traffic suggesting that further
qualifications about the retries; I do see such qualifying statemnets in
the next paragraph, so maybe there is no big need to do so here as well..

  Use of the LE PHB might assist a network operator in moving certain
  kinds of traffic or users to off-peak times.  Alternatively, or in
  addition, packets can be designated for the LE PHB when the goal is
  to protect all other packet traffic from competition with the LE

Is it "alternatively" or "in addition" -- can it really be both at the
same time?  (I suppose the intent is that different operators could
apply different policies?)

Section 9

Is there a section reference in RFC 3754 to point us to?

(Also, the RFC Editor will probably put a comma after "Basically".)

  Several forwarding error correction coding schemes such as fountain
  codes (e.g., [RFC5053]) allow reliable data delivery even in

I'm used to seeing "forward error correction"; is "forwarding error
correction" also an acceptabale usage?

  While the resource contention problem caused by multicast packet
  replication is also true for other Diffserv PHBs, LE forwarding is
  special, because often it is assumed that LE packets get only

nit: s/get only/only get/

  forwarded in case of available resources at the output ports.  The
  previously mentioned redundancy data traffic could nicely use the
  varying available residual bandwidth being utilized the by LE PHB,
  but only if the previously specific requirements in the internal
  implementation of the network devices are considered.

I'm not sure how to interpret "previously specific requirements", here.
Was it intended to be "previously specified requirements"?

Section 12

As per the GenART review, updating the draft in missref is a bit weird,
but we can probably leave it to the responsible AD and RFC Editor to
decide whether to retain the "Updates" relationship or directly effect
the needed changes.

(Via Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

  18.1.5, and 22.7.  As a convenience to the reader, we mention here
  that the client includes requested option codes in the Option Request
  Option.

  On receipt of a DHCPv6 Reply message which contains the
  OPTION_V6_ZEROTOUCH_REDIRECT, the client processes the response
  according to Section 5.5, with the understanding that the "address"
  and "port" values are encoded in the URIs.

  Any invalid URI entries received in the uri-data field are ignored by
  the client.  If OPTION_V6_ZEROTOUCH_REDIRECT does not contain at
  least one valid URI entry in the uri-data field, then the client MUST
  discard the option.

  DHCPv6 Server Behavior

  Sections 17.2.2 and 18.2 of [RFC3315] govern server operation
  in regard to option assignment.  As a convenience to the reader,
  we mention here that the server will send a particular option code
  only if configured with specific values for that option code and if
  the client requested it.

  Option OPTION_V6_ZEROTOUCH_REDIRECT is a singleton.  Servers MUST NOT
  send more than one instance of the OPTION_V6_ZEROTOUCH_REDIRECT
  option.

8.3.  Common Field Encoding

  Both of the DHCPv4 and DHCPv6 options defined in this section encode
  a list of bootstrap server URIs.  The "URI" structure is an option
  that can contain multiple URIs (see [RFC7227], Section 5.7).

    bootstrap-server-list:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
    |      uri-length              |          URI                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

    o uri-length: variable, in octets.

    o URI: URI of zerotouch bootstrap server, using the HTTPS URI
      scheme defined in Section 2.7.2 of RFC7230.  URI MUST be in
      form "https://<ip-address-or-hostname>[:<port>]".

Watsen, et al.            Expires March 9, 2019                [Page 53]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

9.  Security Considerations

9.1.  Clock Sensitivity

  The solution in this document relies on TLS certificates, owner
  certificates, and ownership vouchers, all of which require an
  accurate clock in order to be processed correctly (e.g., to test
  validity dates and revocation status).  Implementations SHOULD ensure
  devices have an accurate clock when shipped from manufacturing
  facilities, and take steps to prevent clock tampering.

  If it is not possible to ensure clock accuracy, it is RECOMMENDED
  that implementations disable the aspects of the solution having clock
  sensitivity.  In particular, such implementations should assume that
  TLS certificates, ownership vouchers, and owner certificates never
  expire and are not revokable.  From an ownership voucher perspective,
  manufacturers SHOULD issue a single ownership voucher for the
  lifetime of such devices.

  Implementations SHOULD NOT rely on NTP for time, as NTP is not a
  secure protocol.

9.2.  Use of IDevID Certificates

  IDevID certificates, as defined in [Std-802.1AR-2009], are
  RECOMMENDED, both for the TLS-level client certificate used by
  devices when connecting to a bootstrap server, as well as for the
  device identity certificate used by owners when encrypting the zero
  touch artifacts.

9.3.  Immutable Storage for Trust Anchors

  Devices MUST ensure that all their trust anchor certificates,
  including those for connecting to bootstrap servers and verifying
  ownership vouchers, are protected from external modification.

  It may be necessary to update these certificates over time (e.g., the
  manufacturer wants to delegate trust to a new CA).  It is therefore
  expected that devices MAY update these trust anchors when needed
  through a verifiable process, such as a software upgrade using signed
  software images.

9.4.  Secure Storage for Long-lived Private Keys

  Manufacturer-generated device identifiers may have very long
  lifetimes.  For instance, [Std-802.1AR-2009] recommends using the
  "notAfter" value 99991231235959Z in IDevID certificates.  Given the
  long-lived nature of these private keys, it is paramount that they

Watsen, et al.            Expires March 9, 2019                [Page 54]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

  are stored so as to resist discovery, such as in a secure
  cryptographic processor (e.g., a TPM).

9.5.  Blindly Authenticating a Bootstrap Server

  This document allows a device to blindly authenticate a bootstrap
  server's TLS certificate.  It does so to allow for cases where the
  redirect information may be obtained in an unsecured manner, which is
  desirable to support in some cases.

  To compensate for this, this document requires that devices, when
  connected to an untrusted bootstrap server, assert that data
  downloaded from the server is signed.

9.6.  Disclosing Information to Untrusted Servers

  This document allows devices to establish connections to untrusted
  bootstrap servers.  However, since the bootstrap server is untrusted,
  it may be under the control of an adversary, and therefore devices
  SHOULD be cautious about the data they send to the bootstrap server
  in such cases.

  Devices send different data to bootstrap servers at each of the
  protocol layers TCP, TLS, HTTP, and RESTCONF.

  At the TCP protocol layer, devices may relay their IP address,
  subject to network translations.  Disclosure of this information is
  not considered a security risk.

  At the TLS protocol layer, devices may use a client certificate to
  identify and authenticate themselves to untrusted bootstrap servers.
  At a minimum, the client certificate must disclose the device's
  serial number, and may disclose additional information such as the
  device's manufacturer, hardware model, public key, etc.  Knowledge of
  this information may provide an adversary with details needed to
  launch an attack.  It is RECOMMENDED that secrecy of the network
  constituency is not relied on for security.

  At the HTTP protocol layer, devices may use an HTTP authentication
  scheme to identify and authenticate themselves to untrusted bootstrap
  servers.  At a minimum, the authentication scheme must disclose the
  device's serial number and, concerningly, may, depending on the
  authentication mechanism used, reveal a secret that is only supposed
  to be known to the device (e.g., a password).  Devices SHOULD NOT use
  an HTTP authentication scheme (e.g., HTTP Basic) with an untrusted
  bootstrap server that reveals a secret that is only supposed to be
  known to the device.

Watsen, et al.            Expires March 9, 2019                [Page 55]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

  At the RESTCONF protocol layer, devices use the "get-bootstrapping-
  data" RPC, but not the "report-progress" RPC, when connected to an
  untrusted bootstrap server.  The "get-bootstrapping-data" RPC allows
  additional input parameters to be passed to the bootstrap server
  (e.g., "os-name", "os-version", "hw-model").  It is RECOMMENDED that
  devices only pass the "untrusted-connection" input parameter to an
  untrusted bootstrap server.  While it is okay for a bootstrap server
  to immediately return signed onboarding information, it is
  RECOMMENDED that bootstrap servers instead promote the untrusted
  connection to a trusted connection, as described in Appendix B, thus
  enabling the device to use the "report-progress" RPC while processing
  the onboarding information.

9.7.  Sequencing Sources of Bootstrapping Data

  For devices supporting more than one source for bootstrapping data,
  no particular sequencing order has to be observed for security
  reasons, as the solution for each source is considered equally
  secure.  However, from a privacy perspective, it is RECOMMENDED that
  devices access local sources before accessing remote sources.

9.8.  Safety of Private Keys used for Trust

  The solution presented in this document enables bootstrapping data to
  be trusted in two ways, either through transport level security or
  through the signing of artifacts.

  When transport level security (i.e., a trusted bootstrap server) is
  used, the private key for the end-entity certificate must be online
  in order to establish the TLS connection.

  When artifacts are signed, the signing key is required to be online
  only when the bootstrap server is returning a dynamically generated
  signed-data response.  For instance, a bootstrap server, upon
  receiving the "untrusted-connection" input parameter to the "get-
  bootstrapping-data" RPC, may dynamically generate a response that is
  signed.

  Bootstrap server administrators are RECOMMENDED to follow best
  practice to protect the private key used for any online operation.
  Use of an hardware security module (HSM) is RECOMMENDED.  If an HSM
  is not used, frequent private key refreshes are RECOMMENDED.

  For best security, it is RECOMMENDED that owners only provide
  bootstrapping data that has been signed, using a private key that is
  not accessible to a network of questionable integrity, and encrypted,
  using the device's public key from its secure device identity
  certificate.

Watsen, et al.            Expires March 9, 2019                [Page 56]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

9.9.  Infinite Redirection Loops and Sequences

  The recursive algorithm described in this document enables redirect
  information to lead to more redirect information, which may cause a
  device to redirect forever.

  Whilst a trusted bootstrap server may be misconfigured to cause a
  device to return to it again ad infitum, the greater concern is that
  any untrusted source of bootstrapping data could be used by an
  adversary to purposely cause this.

  Infinite redirections are most easily constructed via loops, where
  some bootstrap server redirects back to a previously visited
  bootstrap server.  Infinite redirections can also be created without
  a loop by an adversary dynamically instantiated bootstrap servers on
  the fly.

  Implementations SHOULD limit the maximum number of recursive
  redirects allowed; no more than a half dozen seems reasonable.

9.10.  Increased Reliance on Manufacturers

  The zero touch bootstrapping protocol presented in this document
  shifts some control of initial configuration away from the rightful
  owner of the device and towards the manufacturer and its delegates.

  The manufacturer maintains the list of well-known bootstrap servers
  its devices will trust.  By design, if no bootstrapping data is found
  via other methods first, the device will try to reach out to the
  well-known bootstrap servers.  There is no mechanism to prevent this
  from occurring other than by using an external firewall to block such
  connections.  Concerns related to trusted bootstrap servers are
  discussed in Section 9.11.

  Similarly, the manufacturer maintains the list of voucher signing
  authorities its devices will trust.  The voucher signing authorities
  issue the vouchers that enable a device to trust an owner's domain
  certificate.  It is vital that manufacturers ensure the integrity of
  these voucher signing authorities, so as to avoid incorrect
  assignments.

  Operators should be aware that this system assumes that they trust
  all the pre-configured bootstrap servers and voucher signing
  authorities designated by the manufacturers.

Watsen, et al.            Expires March 9, 2019                [Page 57]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

9.11.  Concerns with Trusted Bootstrap Servers

  Trusted bootstrap servers, whether well-known or discovered, have the
  potential to cause problems, such as the following.

  o  A trusted bootstrap server that has been compromised may be
      modified to return unsigned data of any sort.  For instance, a
      bootstrap server that is only suppose to return redirect
      information might be modified to return onboarding information.
      Similarly, a bootstrap server that is only supposed to return
      signed data, may be modified to return unsigned data.  In both
      cases, the device will accept the response, unaware that it wasn't
      supposed to be any different.  It is RECOMMENDED that maintainers
      of trusted bootstrap servers ensure that their systems are not
      easily compromised and, in case of compromise, have mechanisms in
      place to detect and remediate the compromise as expediently as
      possible.

  o  A trusted bootstrap server hosting either unsigned or signed but
      not encrypted data may disclose information to unwanted parties
      (e.g., an administrator of the bootstrap server).  This is a
      privacy issue only, but could reveal information that might be
      used in a subsequent attack.  Disclosure of redirect information
      has limited exposure (it is just a list of bootstrap servers),
      whereas disclosure of onboarding information could be highly
      revealing (e.g., network topology, firewall policies, etc.).  It
      is RECOMMENDED that operators encrypt the bootstrapping data when
      its contents are considered sensitive, even to the administrators
      of a bootstrap server.

9.12.  Validity Period for Zero Touch Information

  Zero touch information does not specify a validity period.  For
  instance, neither redirect information nor onboarding information
  enable "not-before" or "not-after" values to be specified, and
  neither artifact alone can be revoked.

  For unsigned data provided by an untrusted source of bootstrapping
  data, it is not meaningful to discuss its validity period when the
  information itself has no authenticity and may have come from
  anywhere.

  For unsigned data provided by a trusted source of bootstrapping data
  (i.e., a bootstrap server), the availability of the data is the only
  measure of it being current.  Since the untrusted data comes from a
  trusted source, its current availability is meaningful and, since
  bootstrap servers use TLS, the contents of the exchange cannot be
  modified or replayed.

Watsen, et al.            Expires March 9, 2019                [Page 58]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

  For signed data, whether provided by an untrusted or trusted source
  of bootstrapping data, the validity is constrained by the validity of
  the both the ownership voucher and owner certificate used to
  authenticate it.

  The ownership voucher's validity is primarily constrained by the
  ownership voucher's "created-on" and "expires-on" nodes.  While
  [RFC8366] recommends short-lived vouchers (see Section 6.1), the
  "expires-on" node may be set to any point in the future, or omitted
  altogether to indicate that the voucher never expires.  The ownership
  voucher's validity is secondarily constrained by the manufacturer's
  PKI used to sign the voucher; whilst an ownership voucher cannot be
  revoked directly, the PKI used to sign it may be.

  The owner certificate's validity is primarily constrained by the
  X.509's validity field, the "notBefore" and "notAfter" values, as
  specified by the certificate authority that signed it.  The owner
  certificate's validity is secondarily constrained by the validity of
  the PKI used to sign the voucher.  Owner certificates may be revoked
  directly.

  For owners that wish to have maximum flexibility in their ability to
  specify and constrain the validity of signed data, it is RECOMMENDED
  that a unique owner certificate is created for each signed artifact.
  Not only does this enable a validity period to be specified, for each
  artifact, but it also enables to the validity of each artifact to be
  revoke.

9.13.  The "ietf-zerotouch-information" YANG Module

  The ietf-zerotouch-information module defined in this document
  defines a data structure that is always wrapped by a CMS structure.
  When accessed by a secure mechanism (e.g., protected by TLS), then
  the CMS structure may be unsigned.  However, when accessed by an
  insecure mechanism (e.g., removable storage device), then the CMS
  structure must be signed, in order for the device to trust it.

  Implementations should be aware that signed bootstrapping data only
  protects the data from modification, the contents are still visible
  to others.  This doesn't affect security so much as privacy.  That
  the contents may be read by unintended parties when accessed by
  insecure mechanisms is considered next.

  The ietf-zerotouch-information module defines a top-level "choice"
  statement that declares the contents are either "redirect-
  information" or "onboarding-information".  Each of these two cases
  are now considered.

Watsen, et al.            Expires March 9, 2019                [Page 59]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

  When the content of the CMS structure is redirect-information, an
  observer can learn about the bootstrap servers the device is being
  directed to, their IP addresses or hostnames, ports, and trust anchor
  certificates.  Knowledge of this information could provide an
  observer some insight into a network's inner structure.

  When the content of the CMS structure is onboarding-information, an
  observer could learn considerable information about how the device is
  to be provisioned.  This information includes the operating system
  version, initial configuration, and script contents.  This
  information should be considered sensitive and precautions should be
  taken to protect it (e.g., encrypt artifact with device public key).

9.14.  The "ietf-zerotouch-bootstrap-server" YANG Module

  The ietf-zerotouch-bootstrap-server module defined in this document
  specifies an API for a RESTCONF [RFC8040].  The lowest RESTCONF layer
  is HTTPS, and the mandatory-to-implement secure transport is TLS
  [RFC8446].

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

  This module presents no data nodes (only RPCs).  There is no need to
  discuss the sensitivity of data nodes.

  This module defines two RPC operations that may be considered
  sensitive in some network environments.  These are the operations and
  their sensitivity/vulnerability:

  get-bootstrapping-data:  This RPC is used by devices to obtain their
      bootstrapping data.  By design, each device, as identified by its
      authentication credentials (e.g. client certificate), can only
      obtain its own data.  NACM is not needed to further constrain
      access to this RPC.

  report-progress:  This RPC is used by devices to report their
      bootstrapping progress.  By design, each device, as identified by
      its authentication credentials (e.g. client certificate), can
      only report data for itself.  NACM is not needed to further
      constrain access to this RPC.

10.  IANA Considerations

Watsen, et al.            Expires March 9, 2019                [Page 60]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

10.1.  The IETF XML Registry

  This document registers two URIs in the IETF XML registry [RFC3688].
  Following the format in [RFC3688], the following registrations are
  requested:

  URI: urn:ietf:params:xml:ns:yang:ietf-zerotouch-information
  Registrant Contact: The NETCONF WG of the IETF.
  XML: N/A, the requested URI is an XML namespace.

  URI: urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server
  Registrant Contact: The NETCONF WG of the IETF.
  XML: N/A, the requested URI is an XML namespace.

10.2.  The YANG Module Names Registry

  This document registers two YANG modules in the YANG Module Names
  registry [RFC6020].  Following the format defined in [RFC6020], the
  the following registrations are requested:

  name:      ietf-zerotouch-information
  namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-information
  prefix:    zti
  reference: RFC XXXX

  name:      ietf-zerotouch-bootstrap-server
  namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-\
              server  (note: '\' used for formatting reasons only)
  prefix:    ztbs
  reference: RFC XXXX

10.3.  The SMI Security for S/MIME CMS Content Type Registry

  IANA is kindly requested to two entries in the "SMI Security for
  S/MIME CMS Content Type" registry (1.2.840.113549.1.9.16.1), with
  values as follows:

  Decimal  Description                            References
  -------  --------------------------------------  ----------
  TBD1      id-ct-zerotouchInformationXML          [RFCXXXX]
  TBD2      id-ct-zerotouchInformationJSON        [RFCXXXX]

  id-ct-zerotouchInformationXML indicates that the "zerotouch-
  information" is encoded using XML.  id-ct-zerotouchInformationJSON
  indicates that the "zerotouch-information" is encoded using JSON.

Watsen, et al.            Expires March 9, 2019                [Page 61]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

10.4.  The BOOTP Manufacturer Extensions and DHCP Options Registry

  IANA is kindly requested to make permanent the following early code
  point allocation in the "BOOTP Manufacturer Extensions and DHCP
  Options" registry maintained at http://www.iana.org/assignments/
  bootp-dhcp-parameters:

  Tag: 143
  Name: OPTION_V4_ZEROTOUCH_REDIRECT
  Data Length: N
  Meaning: This option provides a list of URIs
            for zerotouch bootstrap servers
  Reference: [RFCXXXX]

  And the following early code point allocation in the "Dynamic Host
  Configuration Protocol for IPv6 (DHCPv6)" registry maintained at
  http://www.iana.org/assignments/dhcpv6-parameters:

  Value: 136
  Description: OPTION_V6_ZEROTOUCH_REDIRECT
  Reference: [RFCXXXX]

11.  References

11.1.  Normative References

  [I-D.ietf-netmod-yang-data-ext]
              Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data
              Extensions", draft-ietf-netmod-yang-data-ext-01 (work in
              progress), March 2018.

  [ITU.X690.2015]
              International Telecommunication Union, "Information
              Technology - ASN.1 encoding rules: Specification of Basic
              Encoding Rules (BER), Canonical Encoding Rules (CER) and
              Distinguished Encoding Rules (DER)", ITU-T Recommendation
              X.690, ISO/IEC 8825-1, August 2015,
              <https://www.itu.int/rec/T-REC-X.690/>.

  [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Watsen, et al.            Expires March 9, 2019                [Page 62]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

  [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <https://www.rfc-editor.org/info/rfc3315>.

  [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
              DOI 10.17487/RFC3396, November 2002,
              <https://www.rfc-editor.org/info/rfc3396>.

  [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
              January 2006, <https://www.rfc-editor.org/info/rfc4253>.

  [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

  [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/info/rfc5652>.

  [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

  [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <https://www.rfc-editor.org/info/rfc6125>.

  [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.

  [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

  [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

Watsen, et al.            Expires March 9, 2019                [Page 63]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

  [RFC7227]  Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
              S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
              BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
              <https://www.rfc-editor.org/info/rfc7227>.

  [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

  [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

  [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
              "A Voucher Artifact for Bootstrapping Protocols",
              RFC 8366, DOI 10.17487/RFC8366, May 2018,
              <https://www.rfc-editor.org/info/rfc8366>.

  [Std-802.1AR-2009]
              IEEE SA-Standards Board, "IEEE Standard for Local and
              metropolitan area networks - Secure Device Identity",
              December 2009, <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.

11.2.  Informative References

  [I-D.ietf-netconf-crypto-types]
              Watsen, K., "Common YANG Data Types for Cryptography",
              draft-ietf-netconf-crypto-types-00 (work in progress),
              June 2018.

  [I-D.ietf-netconf-trust-anchors]
              Watsen, K., "YANG Data Model for Global Trust Anchors",
              draft-ietf-netconf-trust-anchors-00 (work in progress),
              June 2018.

  [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

  [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

Watsen, et al.            Expires March 9, 2019                [Page 64]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

  [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

  [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <https://www.rfc-editor.org/info/rfc6698>.

  [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              RFC 6960, DOI 10.17487/RFC6960, June 2013,
              <https://www.rfc-editor.org/info/rfc6960>.

  [RFC8071]  Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
              RFC 8071, DOI 10.17487/RFC8071, February 2017,
              <https://www.rfc-editor.org/info/rfc8071>.

  [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

  [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

  [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Watsen, et al.            Expires March 9, 2019                [Page 65]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

Appendix A.  The Zero Touch Device Data Model

  This section defines a non-normative data model that enables the
  configuration of zerotouch bootstrapping and discovery of what
  parameters are used by a device's bootstrapping logic.

A.1.  Data Model Overview

  The following tree diagram provides an overview for the zerotouch
  device data model.

  module: example-zerotouch-device
    +--rw zerotouch
        +--rw enabled?                                boolean
        +--ro idevid-certificate?
        |      ct:end-entity-cert-cms {bootstrap-servers}?
        +--ro bootstrap-servers {bootstrap-servers}?
        |  +--ro bootstrap-server* [address]
        |    +--ro address    inet:host
        |    +--ro port?      inet:port-number
        +--ro bootstrap-server-pinned-certificates?
        |      ta:pinned-certificates-ref {bootstrap-servers}?
        +--ro voucher-pinned-certificates?
                ta:pinned-certificates-ref {signed-data}?

  In the above diagram, notice that there is only one configurable node
  "enabled".  The expectation is that this node would be set to "true"
  in device's factory default configuration and that it would either be
  set to "false" or deleted when the zerotouch bootstrapping is longer
  needed.

A.2.  Example Usage

  Following is an instance example for this data model.

Watsen, et al.            Expires March 9, 2019                [Page 66]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

  [Note: '\' line wrapping for formatting only]

  <zerotouch
    xmlns="https://example.com/zerotouch-device">
    <enabled>true</enabled>
    <idevid-certificate>base64encodedvalue==</idevid-certificate>
    <bootstrap-servers>
      <bootstrap-server>
        <address>phs1.example.com</address>
        <port>8443</port>
      </bootstrap-server>
      <bootstrap-server>
        <address>phs2.example.com</address>
        <port>8443</port>
      </bootstrap-server>
      <bootstrap-server>
        <address>phs3.example.com</address>
        <port>8443</port>
      </bootstrap-server>
    </bootstrap-servers>
    <bootstrap-server-pinned-certificates>manufacturers-root-ca-certs<\
  /bootstrap-server-pinned-certificates>
    <voucher-pinned-certificates>manufacturers-root-ca-certs</voucher-\
  pinned-certificates>
  </zerotouch>

A.3.  YANG Module

  The device model is defined by the YANG module defined in this
  section.

  This module uses data types defined in [RFC6991],
  [I-D.ietf-netconf-crypto-types], and
  [I-D.ietf-netconf-trust-anchors].

  module example-zerotouch-device {
    yang-version 1.1;
    namespace "https://example.com/zerotouch-device";
    prefix ztd;

    import ietf-inet-types {
      prefix inet;
      reference "RFC 6991: Common YANG Data Types";
    }

    import ietf-crypto-types {
      prefix ct;
      revision-date 2018-06-04;

Watsen, et al.            Expires March 9, 2019                [Page 67]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

      description
        "This revision is defined in the -00 version of
        draft-ietf-netconf-crypto-types";
      reference
        "draft-ietf-netconf-crypto-types:
          Common YANG Data Types for Cryptography";
    }

    import ietf-trust-anchors {
      prefix ta;
      revision-date 2018-06-04;
      description
        "This revision is defined in -00 version of
        draft-ietf-netconf-trust-anchors.";
      reference
        "draft-ietf-netconf-trust-anchors:
          YANG Data Model for Global Trust Anchors";
    }

    organization
      "Example Corporation";

    contact
      "Author: Bootstrap Admin <mailto:admin@example.com>";

    description
      "This module defines a data model to enable zerotouch
        bootstrapping and discover what parameters are used.
        This module assumes the use of an IDevID certificate,
        as opposed to any other client certificate, or the
        use of an HTTP-based client authentication scheme.";

    revision 2018-09-05 {
      description
        "Initial version";
      reference
        "RFC XXXX: Zero Touch Provisioning for Networking Devices";
    }

    // features

    feature bootstrap-servers {
      description
        "The device supports bootstrapping off bootstrap servers.";
    }

    feature signed-data {
      description

Watsen, et al.            Expires March 9, 2019                [Page 68]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

        "The device supports bootstrapping off signed data.";
    }

    // protocol accessible nodes

    container zerotouch {
      description
        "Top-level container for zerotouch data model.";
      leaf enabled {
        type boolean;
        default false;
        description
          "The 'enabled' leaf controls if zerotouch bootstrapping is
            enabled or disabled.  The default is 'false' so that, when
            not enabled, which is most of the time, no configuration
            is needed.";
      }
      leaf idevid-certificate {
        if-feature bootstrap-servers;
        type ct:end-entity-cert-cms;
        config false;
        description
          "This CMS structure contains the IEEE 802.1AR-2009
            IDevID certificate itself, and all intermediate
            certificates leading up to, and optionally including,
            the manufacturer's well-known trust anchor certificate
            for IDevID certificates.  The well-known trust anchor
            does not have to be a self-signed certificate.";
        reference
          "IEEE 802.1AR-2009:
              IEEE Standard for Local and metropolitan area
              networks - Secure Device Identity.";
      }
      container bootstrap-servers {
        if-feature bootstrap-servers;
        config false;
        description
          "List of bootstrap servers this device will attempt
            to reach out to when bootstrapping.";
        list bootstrap-server {
          key "address";
          description
            "A bootstrap server entry.";
          leaf address {
            type inet:host;
            mandatory true;
            description
              "The IP address or hostname of the bootstrap server the

Watsen, et al.            Expires March 9, 2019                [Page 69]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

                device should redirect to.";
          }
          leaf port {
            type inet:port-number;
            default "443";
            description
              "The port number the bootstrap server listens on.  If no
                port is specified, the IANA-assigned port for 'https'
                (443) is used.";
          }
        }
      }
      leaf bootstrap-server-pinned-certificates {
        if-feature bootstrap-servers;
        type ta:pinned-certificates-ref;
        config false;
        description
          "A reference to a list of pinned certificate authority (CA)
            certificates that the device uses to validate bootstrap
            servers with.";
      }
      leaf voucher-pinned-certificates {
        if-feature signed-data;
        type ta:pinned-certificates-ref;
        config false;
        description
          "A reference to a list of pinned certificate authority (CA)
            certificates that the device uses to validate ownership
            vouchers with.";
      }
    }
  }

Appendix B.  Promoting a Connection from Untrusted to Trusted

  The following diagram illustrates a sequence of bootstrapping
  activities that promote an untrusted connection to a bootstrap server
  to a trusted connection to the same bootstrap server.  This enables a
  device to limit the amount of information it might disclose to an
  adversary hosting an untrusted bootstrap server.

Watsen, et al.            Expires March 9, 2019                [Page 70]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

                                                        +----------+
                                                        |Deployment|
                                                        | Specific |
  +------+                                              |Bootstrap |
  |Device|                                              |  Server  |
  +------+                                              +----------+
      |                                                        |
      | 1. "HTTPS" Request ("untrusted-connection", nonce)    |
      |------------------------------------------------------->|
      | 2. "HTTPS" Response (signed redirect information)      |
      |<-------------------------------------------------------|
      |                                                        |
      |                                                        |
      | 3. HTTPS Request (os-name=xyz, os-version=123, etc.)  |
      |------------------------------------------------------->|
      | 4. HTTPS Response (unsigned onboarding information    |
      |<-------------------------------------------------------|
      |                                                        |

  The interactions in the above diagram are described below.

  1.  The device initiates an untrusted connection to a bootstrap
      server, as is indicated by putting "HTTPS" in double quotes
      above.  It is still an HTTPS connection, but the device is unable
      to authenticate the bootstrap server's TLS certificate.  Because
      the device is unable to trust the bootstrap server, it sends the
      "untrusted-connection" input parameter, and optionally also the
      "nonce" input parameter, in the "get-bootstrapping-data" RPC.
      The "untrusted-connection" parameter informs the bootstrap server
      that the device does not trust it and may be holding back some
      additional input parameters from the server (e.g., other input
      parameters, progress reports, etc.).  The "nonce" input parameter
      enables the bootstrap server to dynamically obtain an ownership
      voucher from a MASA, which may be important for devices that do
      not have a reliable clock.

  2.  The bootstrap server, seeing the "untrusted-connection" input
      parameter, knows that it can either send unsigned redirect
      information or signed data of any type.  But, in this case, the
      bootstrap server has the ability to sign data and chooses to
      respond with signed redirect information, not signed onboarding
      information as might be expected, securely redirecting the device
      back to it again.  Not displayed but, if the "nonce" input
      parameter was passed, the bootstrap server could dynamically
      connect to a download a voucher from the MASA having the nonce
      value in it.  Details regarding a protocol enabling this
      integration is outside the scope of this document.

Watsen, et al.            Expires March 9, 2019                [Page 71]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

  3.  Upon validating the signed redirect information, the device
      establishes a secure connection to the bootstrap server.
      Unbeknownst to the device, it is the same bootstrap server it was
      connected to previously but, because the device is able to
      authenticate the bootstrap server this time, it sends its normal
      "get-bootstrapping-data" request (i.e., with additional input
      parameters) as well as its progress reports (not depicted).

  4.  This time, because the "untrusted-connection" parameter was not
      passed, having access to all of the device's input parameters,
      the bootstrap server returns, in this example, unsigned
      onboarding information to the device.

Appendix C.  Workflow Overview

  The zero touch solution presented in this document is conceptualized
  to be composed of the non-normative workflows described in this
  section.  Implementation details are expected to vary.  Each diagram
  is followed by a detailed description of the steps presented in the
  diagram, with further explanation on how implementations may vary.

C.1.  Enrollment and Ordering Devices

  The following diagram illustrates key interactions that may occur
  from when a prospective owner enrolls in a manufacturer's zero touch
  program to when the manufacturer ships devices for an order placed by
  the prospective owner.

Watsen, et al.            Expires March 9, 2019                [Page 72]
Internet-Draft    Secure Zero Touch Provisioning (SZTP)  September 2018

                                  +-----------+
  +------------+                |Prospective|                    +---+
  |Manufacturer|                |  Owner  |                    |NMS|
  +------------+                +-----------+                    +---+
        |                              |                            |
        |                              |                            |
        |  1. initiate enrollment      |                            |
        #<-----------------------------|                            |
        #                              |                            |
        #                              |                            |
        #    IDevID trust anchor      |                            |
        #----------------------------->#  set IDevID trust anchor  |
        #                              #--------------------------->|
        #                              |                            |
        #    bootstrap server        |                            |
        #    account credentials      |                            |
        #----------------------------->#  set credentials          |
        |                              #--------------------------->|
        |                              |                            |
        |                              |                            |
        |  2. set owner certificate trust anchor                    |
        |<----------------------------------------------------------|
        |                              |                            |
        |                              |                            |
        |  3. place device order      |                            |
        |<-----------------------------#  model devices            |
        |                              #--------------------------->|
        |                              |                            |
        |  4. ship devices and send    |                            |
        |    device identifiers and  |                            |
        |    ownership vouchers      |                            |
        |----------------------------->#  set device identifiers    |
        |                              #  and ownership vouchers    |
        |                              #--------------------------->|
        |                              |                            |

  Each numbered item below corresponds to a numbered item in the
  diagram above.

  1.  A prospective owner of a manufacturer&drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tsvwg-le-phb-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Differentiated Services Field Codepoints (DSCP) registry located at:

https://www.iana.org/assignments/dscp-registry/

a single, new registration from Pool 3, as follows:

Name: LE
Value (Binary): 000001
Value (Decimal): 1
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-02-12):

From: The IESG
To: IETF-Announce
CC: tsvwg@ietf.org, draft-ietf-tsvwg-le-phb@ietf.org, david.black@dell.com, tsvwg-chairs@ietf.org, David Black , spencerdawkins.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Lower Effort Per-Hop Behavior (LE PHB)) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'A Lower Effort Per-Hop
Behavior (LE PHB)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-02-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies properties and characteristics of a Lower
  Effort (LE) per-hop behavior (PHB).  The primary objective of this LE
  PHB is to protect best-effort (BE) traffic (packets forwarded with
  the default PHB) from LE traffic in congestion situations, i.e., when
  resources become scarce, best-effort traffic has precedence over LE
  traffic and may preempt it.  Alternatively, packets forwarded by the
  LE PHB can be associated with a scavenger service class, i.e., they
  scavenge otherwise unused resources only.  There are numerous uses
  for this PHB, e.g., for background traffic of low precedence, such as
  bulk data transfers with low priority in time, non time-critical
  backups, larger software updates, web search engines while gathering
  information from web servers and so on.  This document recommends a
  standard DSCP value for the LE PHB.  This specification obsoletes RFC
  3662 and updates the DSCP recommended in RFC 4594 and RFC 8325 to use
  the DSCP assigned in this specification.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc2475: An Architecture for Differentiated Services (Informational - IETF stream)

Document shepherd write-up:

                A Lower Effort Per-Hop Behavior (LE PHB)
                      draft-ietf-tsvwg-le-phb-06
1. Summary

Document Shepherd: David Black
Responsible AD: Spencer Dawkins

  This document specifies properties and characteristics of a Lower
  Effort (LE) per-hop behavior (PHB).  The primary objective of this LE
  PHB is to protect best-effort (BE) traffic (packets forwarded with
  the default PHB) from LE traffic in congestion situations, i.e., when
  resources become scarce, best-effort traffic has precedence over LE
  traffic and may preempt it.  Alternatively, packets forwarded by the
  LE PHB can be associated with a scavenger service class, i.e., they
  scavenge otherwise unused resources only.  There are numerous uses
  for this PHB, e.g., for background traffic of low precedence, such as
  bulk data transfers with low priority in time, non time-critical
  backups, larger software updates, web search engines while gathering
  information from web servers and so on.  This document recommends a
  standard DSCP value for the LE PHB.  This specification obsoletes RFC
  3662 and updates the DSCP recommended in RFC 4594 and RFC 8325 to use
  the DSCP assigned in this specification.

When Diffserv was originally designed, interest in less-than-best effort
(aka scavenger) forwarding behavior eventually resulted in publication of
RFC 3662 which specified the Diffserv Lower Effort (LE) PHB/PDB.

In 20/20 hindsight, RFC 3662 had a number of drawbacks, as it was not
a full PHB specification and in particular did not recommend a default
DSCP (Diffserv Codepoint) for Lower Effort traffic.  The default DSCP
recommendation eventually occurred in practice as a side effect of
publishing RFC 4594 on Diffserv Service Classes.  The recommended
DSCP, CS1, has turned out to be problematic in practice - e.g., see the
discussion of CS1 in RFC 7657 on Diffserv interaction with real time
communication.

This draft cleans up the LE PHB situation by providing a full PHB
specification of the Lower Effort PHB that obsoletes RFC 3662 and
recommends a newly chosen default DSCP, 000001, which is expected to
avoid the problems encountered with CS1 and provide a solid Diffserv
specification for lower effort/less-than-best-effort/scavenger traffic.
Proposed Standard is appropriate for this document in support of
consistent deployment of the updated LE PHB as part of Diffserv.

2. Review and Consensus

The Transport Area WG (tsvwg) is a collection of people with varied
interests that don't individually justify their own working groups.

Specifying the Lower Effort PHB was relatively straightforward in
the WG.  In contrast, determining which DSCP to recommend as the
default for that PHB was not.  The underlying problem is that a
non-negligible amount of deployed Internet equipment "bleaches"
the three most significant bits of the DSCP field in IP headers to
zero, even though that violates Diffserv requirements.  This made
it problematic to use the initially suggested 000010 value, as that
value can and does result from this three-bit bleaching of DSCP
values for higher priority traffic that should not be forwarded
as lower effort (LE) traffic.

After much discussion and evaluation of measurement results on Internet
traffic in both TSVWG and MAPRG, the TSVWG working group chose 000001
value as the recommended default DSCP.  This decision necessitated
publication of RFC 8436 to change the IANA procedures for managing the
DSCP registry so that this DSCP value 000001 could be assigned as the
default DSCP for the LE PHB in this document.

This draft is supported by the portion of the tsvwg working group that
is familiar with and interested in Diffserv.  The draft has received
significant review and critique from a number of Diffserv experts,
including the draft shepherd and Brian Carpenter who was one of the
original chairs of the Diffserv WG.  There is clear consensus in the
TSVWG WG on the need to update the LE PHB specification to replace
and obsolete RFC 3662.

3. Intellectual Property

The draft author has stated his direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

The shepherd has checked the IANA Considerations.

idnits generated a number of comments that don't reflect actual problems,
plus three warnings about missing references and a Downref complaint.

The three warnings about missing references are all in quoted text
(existing or updated) for other documents - in each case the document
involved contains the necessary reference, so the warnings can be ignored.

This document contains a Downref to RFC 2475 on Diffserv Architecture.
In the shepherd's considered opinion, this Downref is justified because
an understanding of RFC 2475 is necessary to understand this document,
and RFC 2475's security considerations are explicitly referenced by
this document's security considerations.  That Downref will need to
be noted in the IETF Last Call announcement.