Network Tokens
draft-yiakoumis-network-tokens-01

Document Type Active Internet-Draft (individual)
Authors Yiannis Yiakoumis  , Nick McKeown  , Frode Sorensen 
Last updated 2020-06-18
Stream (None)
Intended RFC status (None)
Formats plain text pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
TBD                                                         Y. Yiakoumis
Internet-Draft                                      Selfie Networks, Inc
Intended status: Standards Track                              N. McKeown
Expires: December 17, 2020                           Stanford University
                                                             F. Sorensen
                                      Norwegian Communications Authority
                                                           June 15, 2020

                             Network Tokens
                   draft-yiakoumis-network-tokens-01

Abstract

   Network tokens is a method for endpoints to explicitly and securely
   coordinate with networks about how their traffic is treated.  They
   are inserted by endpoints in existing protocols, interpreted by
   trusted networks, and may be signed or encrypted to meet security and
   privacy requirements.  Network tokens provide a means for network
   operators to expose datapath services (such as a zero-rating service,
   a user-driven QoS service, or a firewall whitelist), and for end
   users and application providers to access such services.  Network
   tokens are inspired and derived by existing security tokens (like JWT
   and CWT), and borrow several of their core ideas along with security
   and privacy properties.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 17, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Yiakoumis, et al.       Expires December 17, 2020               [Page 1]
Internet-Draft                networktokens                    June 2020

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Network Token Overview  . . . . . . . . . . . . . . . . .   3
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Use cases Overview  . . . . . . . . . . . . . . . . . . .   5
       2.1.1.  Zero Rating . . . . . . . . . . . . . . . . . . . . .   5
       2.1.2.  Firewall Whitelist  . . . . . . . . . . . . . . . . .   6
       2.1.3.  QoS . . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.2.  Existing mechanisms . . . . . . . . . . . . . . . . . . .   8
       2.2.1.  DiffServ  . . . . . . . . . . . . . . . . . . . . . .   8
       2.2.2.  Deep Packet Inspection  . . . . . . . . . . . . . . .   8
     2.3.  Requirements and Challenges . . . . . . . . . . . . . . .   9
       2.3.1.  Integration overhead  . . . . . . . . . . . . . . . .   9
       2.3.2.  Detection Accuracy  . . . . . . . . . . . . . . . . .  10
       2.3.3.  Fraud Prevention  . . . . . . . . . . . . . . . . . .  11
       2.3.4.  Implementing user-centric control . . . . . . . . . .  11
       2.3.5.  Privacy . . . . . . . . . . . . . . . . . . . . . . .  12
   3.  Representation  . . . . . . . . . . . . . . . . . . . . . . .  12
   4.  Contents  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.1.  Network Token Common fields . . . . . . . . . . . . . . .  13
       4.1.1.  'iss' (Issuer) field  . . . . . . . . . . . . . . . .  13
       4.1.2.  "sub" (Subject) field . . . . . . . . . . . . . . . .  13
       4.1.3.  "exp" (Expiration Time) field . . . . . . . . . . . .  13
       4.1.4.  "iat" (Issued At) field . . . . . . . . . . . . . . .  14
       4.1.5.  "nti" field (Network Token ID) field  . . . . . . . .  14
       4.1.6.  "bip" field (Bound IP) field  . . . . . . . . . . . .  14
   5.  Network Token Format  . . . . . . . . . . . . . . . . . . . .  14
   6.  Example Network Tokens  . . . . . . . . . . . . . . . . . . .  15
     6.1.  Application Token . . . . . . . . . . . . . . . . . . . .  15
     6.2.  User-centric Token  . . . . . . . . . . . . . . . . . . .  16
   7.  Network Tokens and Encapsulating protocols  . . . . . . . . .  17
     7.1.  Network Tokens as a TLS Extension . . . . . . . . . . . .  18
     7.2.  Network Tokens as a STUN Attribute  . . . . . . . . . . .  20
     7.3.  Network Tokens as an IPv6 Hop-by-Hop Extension Header . .  21
   8.  Implementation Considerations . . . . . . . . . . . . . . . .  22
     8.1.  Contents  . . . . . . . . . . . . . . . . . . . . . . . .  23
     8.2.  Encapsulating protocol  . . . . . . . . . . . . . . . . .  23

Yiakoumis, et al.       Expires December 17, 2020               [Page 2]
Internet-Draft                networktokens                    June 2020

     8.3.  Network Token granularity . . . . . . . . . . . . . . . .  24
       8.3.1.  Per-packet granularity  . . . . . . . . . . . . . . .  24
       8.3.2.  Per-flow granularity  . . . . . . . . . . . . . . . .  24
     8.4.  Token to DiffServ mapping and reflection  . . . . . . . .  25
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
   10. IANA Considerations { #iana } . . . . . . . . . . . . . . . .  26
     10.1.  Token Descriptor ID Registry . . . . . . . . . . . . . .  26
       10.1.1.  Initial Registry Contents  . . . . . . . . . . . . .  26
     10.2.  IPv6 Hop-By-Hop options registration . . . . . . . . . .  26
     10.3.  TLS ExtensionType Registry . . . . . . . . . . . . . . .  27
     10.4.  STUN Attributes Registry . . . . . . . . . . . . . . . .  27
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  27
     11.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

1.  Introduction

   This specification motivates and describes network tokens, a method
   for endpoints to explicitly coordinate with networks about how their
   traffic is treated.  They provide a means for networks to expose
   datapath services, and for end users to access such services by
   appropriately tagging their traffic.  Network tokens are intended for
   scenarios where there is explicit coordination and trust between
   endpoints and the network, like a zero-rating service, a user-driven
   QoS service, or a firewall whitelist.

1.1.  Network Token Overview

   A network token is a small piece of data that end users attach to
   their packets.  As packets flow through the network, intermediate
   nodes MAY detect tokens, interpret them, and apply the desired
   service to the packets that carry them (and possibly to all other
   packets from the same flow).

   Tokens MAY be digitally signed, integrity protected and/or encrypted
   to account for privacy and security, and can be provisioned to
   prevent replay and spoofing attacks.

   Tokens carry simple claims that can drive network policy.

   For example, a token might just state the name of the application
   that a packet originates from, which can then be used by firewalls
   and/or zero-rating whitelists.  Such a token (an "application
   token"), would be signed with the private key of the application
   provider, and could be interpreted and verified by any one with the
   application provider's public key.  It may also be bound to the IP

Yiakoumis, et al.       Expires December 17, 2020               [Page 3]
Internet-Draft                networktokens                    June 2020

   address of the application provider's server that generates the
   traffic so it cannot be used in a different context.

   Similarly, a token might state the request of an end-user to access a
   network service, such as a low-latency and reliable QoS SLA, in a
   user-centric, application agnostic, and privacy preserving means.
   Such a token (a "user-centric token"), will hold a unique user
   identifier (like an MSISDN), the keyword "lowlatency", an expiration
   date, a nonce for revocability, and will be encrypted with a network
   operator's secret key.  The contents of the token will be opaque and
   uninterpretable by everyone other than the operator (including the
   user).

   Tokens are policy-agnostic, i.e., they just provide a unified
   mechanism to communicate and interpret certain claims in the
   datapath.  Network services built using tokens can dictate the
   desired policy through token (or token metadata) distribution, and
   the cryptographic functions applied to them.

   Network tokens do not dictate a dedicated header or protocol to be
   inserted.  Instead, they are incorporated as options and extensions
   into a variety of existing protocols.  For example, they can be
   carried as TLS Client and Server Hello extensions during a TLS
   handshake, as IPv6 Hop by Hop Options, or as attributes during a
   STUN-enabled flow setup.  Network tokens are largely opaque to the
   protocols that carry them.

   Network tokens are inspired and derived by existing security tokens,
   like JSON Web Token (JWT) [RFC7519] and CBOR Web Token (CWT)
   [RFC8392], and borrow a lot of their properties in terms of security
   and privacy.  In fact, network tokens MAY be represented as JWT and
   CWT objects, and respectively use JOSE and COSE technologies for
   signing and encryption.

2.  Motivation

   Network traffic differentiation is widely deployed in enterprise,
   residential, and cellular networks.  Typical use cases are firewall
   whitelists, zero-rating programs, and custom QoS SLAs where certain
   traffic is granted special treatment.

   A common concern for all such services is how to identify traffic of
   interest in order to map it to (and enforce) the desired network
   policy.  The mechanism that does this essentially becomes the
   interface between network operators, application providers and end-
   users, and has direct implications to network management and
   security, user privacy, business practices, and compliance with net
   neutrality regulation.

Yiakoumis, et al.       Expires December 17, 2020               [Page 4]
Internet-Draft                networktokens                    June 2020

   Identifying traffic of interest is not straight forward, as it often
   depends on context not present in the related packets themselves.
   For example, the decision to allow a packet through a firewall or
   zero-rating whitelist is based on the application that generated the
   packet, while routing a flow through a low-latency path depends on
   the desire of a user to prioritize this flow and potentially pay for
   it.  Requirements around accountability and verification, fraud
   prevention, privacy preservation, and compliance with net neutrality
   regulation just make the task harder.

   This section discusses usecases, existing mechanisms that map traffic
   to network differentiation services, and then details some of the
   challenges through the perspective of different stakeholders, and how
   network tokens can help to address them.

2.1.  Use cases Overview

2.1.1.  Zero Rating

   Zero rating (and similarly sponsored data and other application-
   specific data plans) is the practice of differentiating charging of
   internet access based on the application that generated data.  For
   example, a mobile operator might allow its users to stream music
   without paying for data as part of a promotional offer, or purchase a
   discounted data plan that can be used only for certain applications.
   It is deployed in several cellular networks along with data usage
   caps.

   Zero-rating services require close collaboration between application
   providers and mobile operators.  The typical workflow involves the
   application provider sharing an application signature with the
   operator (i.e., a list of domains and IP addresses used to serve
   traffic), operators configuring their networks to detect traffic with
   these characteristics, and then map it to predefined charging groups.
   The process repeats whenever there are updates in application
   signatures.

   A critical metric for zero-rating integrations is accuracy, i.e.,
   what percentage of the traffic from a specific application is
   detected (and properly charged) by the network.  Undetected traffic
   that should otherwise be zero-rated, leads to unexpected charges or
   packet drops for users.  Zero-rating traffic that shouldn't be zero-
   rated, leads to loss of revenue for operators.  As such, network
   operators evaluate detection accuracy for each application against a
   threshold, and appropriately decide whether to add an application or
   not.  There are typically four sources of inaccuracy:

Yiakoumis, et al.       Expires December 17, 2020               [Page 5]
Internet-Draft                networktokens                    June 2020

   o  Third-party traffic: Most modern applications include third-party
      traffic which cannot be counted as part of the application
      signature (e.g., analytics, ads, social network plugins, etc).

   o  Out-of-sync application signature: Application signatures often
      change (when servers and/or domains are added or deleted).  When
      these changes are not incorporated in the network configuration,
      inaccuracies occur.

   o  Fraudulent behavior: Malicious users may attempt to masquerade
      their traffic to appear as eligible zero-rating traffic when it is
      not.  For example, one can setup a rogue proxy server, spoof a
      zero-rated domain through the SNI field, and route all traffic
      through this proxy.  This has lead some operators to only perform
      zero-rating based on IP addresses.

   o  Unsupported detection methods: this is common when application
      providers use peer-to-peer connectivity, or when their traffic
      comes from CDN servers with shared IP addresses and the operator
      does not support domain-based signatures.

   Another important metric for zero-rating is to keep onboarding and
   operational overhead low, as operators typically zero-rate multiple
   applications.  For example, a common practice, driven by regulatory
   and/or commercial requirements is to apply the same treatment to a
   group of applications from specific categories (e.g., music, video,
   social networks, gaming).  From a regulatory perspective, the goal is
   to provide a level playing field for competing application providers
   according to net neutrality principles.  From a commercial
   perspective, grouping multiple applications together can improve
   perceived value for users.

   Zero-rating is typically either application-specific, or specific to
   a category of applications, and implies a trust relationship between
   an application provider and the network.

2.1.2.  Firewall Whitelist

   A firewall whitelist shares many characteristics with zero-rating as
   far as it concerns this document.  It is typically application-
   specific, and implies a trust relationship between an application
   provider and the network operator.

   A critical metric for firewall whitelists is performance, as
   firewalls may become bottlenecks in otherwise well-provisioned
   networks.  Another metric is accuracy, as letting insecure traffic
   through a firewall can become a security risk.

Yiakoumis, et al.       Expires December 17, 2020               [Page 6]
Internet-Draft                networktokens                    June 2020

   Firewall whitelists are typically used in enterprise networks to
   allow traffic from certain applications through the network, or
   bypass an expensive classification path.

2.1.3.  QoS

   QoS services have been historically deployed in a variety of
   networks, and emerging use cases like SD-WAN and 5G slicing renewed
   interest to how they are implemented.

   This document is related only to QoS policies where a subset of the
   traffic to/from an endpoint receives special treatment.  For example,
   a scenario where a user's traffic is throttled at 10Mbps during peak
   evening hours is out-of-scope for this document.  A scenario where a
   user accesses a 10Mbps connection for a flat fee, an hourly 100Mbps
   connection for an hourly fee, and she can dynamically decide which
   packet to send to which QoS SLA is in scope for this document.

   QoS policies might be either application specific, or user-centric.
   Application-specific applications are similar to zero-rating and
   firewall whitelists services, and imply trust between an application
   provider and the network operator.

   In contrast, user-driven QoS policies imply trust between the user
   and the network operator, while the role of the application
   developer, if any, is to facilitate their interaction.  In other
   words, the network operator is not concerned with whether the traffic
   from an application is eligible for certain treatment.  It just needs
   to verify that the end-user requires a flow to receive a special
   treatment.  A user might be an individual, an enterprise, or an
   organization that wants to use a third-party application over a QoS
   SLA provided by a network operator.

   For example, a user-driven approach for mobile networks is
   recommended by regulators in multiple countries as a way to offer QoS
   differentiation in a way compliant with net neutrality regulation.
   Additionally, services might have to be application-agnostic (i.e.,
   the user should be able to use it for any application they want) and
   privacy preserving (i.e., the network operator doesn't need to know
   the application associated with this traffic to offer the service).

   Similar requirements arise in enterprise networks, where companies
   purchase multiple SLAs from their connectivity provider and want to
   decide how they differentiate traffic from different applications
   through respective paths.

   QoS services are often charged based on usage, and therefore
   accountability and verification are important aspects of it.

Yiakoumis, et al.       Expires December 17, 2020               [Page 7]
Internet-Draft                networktokens                    June 2020

2.2.  Existing mechanisms

   The two primary methods that map traffic to network differentiation
   services today are DiffServ and Deep Packet Inspection.

2.2.1.  DiffServ

   DiffServ [RFC2475] uses DSCP bits in the IP header to map traffic
   into specific classes and drive per-hop-behavior in the network for
   traffic differentiation.  DiffServ operates within a single
   administrative domain, and assumes that traffic is properly marked
   and classified in the network boundaries.  In many practical
   deployments, the endpoints under consideration are not under the
   network's administrative domain and this causes issues.

   Intermediate nodes in the path may alter or reset the DSCP bits
   (e.g., to use them for their own purposes), therefore nullyfying any
   endpoint marking.  Second, and maybe most important, DiffServ has no
   authentication and revocation primitives: any application can set the
   DSCP bits and request service without the user's consent.  Any
   developer can ask for special network treatment even if it conflicts
   with a user's desire, or--even worse--if it results in network
   charges for users, and users or operators do not have the means to
   easily revoke such access.

   Network tokens can solve such problems as they operate across network
   boundaries, and support revocation and authentication.  In that
   sense, tokens are complementary to DiffServ, not a replacement.  They
   can be used to communicate a claim in a secure way, across network
   boundaries.  Once a token is interpreted, DiffServ can be used within
   an administrative domain to drive enforcement on a per-hop basis.

2.2.2.  Deep Packet Inspection

   Deep Packet Inspection uses predefined application signatures to
   detect traffic of interest, and then enforces the desired policy.
   Application signatures are a combination of IP addresses, domain
   names, SSL certificates, and other fields, that infer the application
   that generated traffic by implicitly observing traffic between
   endpoints.  They are widely deployed by network operators today as an
   enabler for traffic differentiation services.

   The advantage of DPI is that it requires no changes from endpoints.
   But as new usecases come up, applications grow in complexity, and
   privacy or net neutrality requirements strengthen, its shortcomings
   become more dominant.

Yiakoumis, et al.       Expires December 17, 2020               [Page 8]
Internet-Draft                networktokens                    June 2020

   o  Modern applications use a variety of protocols and architectures,
      integrate third-party services, establish connectivity through
      thousands of nodes, and constantly change.  Maintaining
      application signatures is manual, expensive, and often inaccurate.
      They require frequent updates, involve manual interactions between
      parties, and cannot cover third-party traffic scenarios.

   o  Application signatures are vulnerable to fraud, as bad actors can
      spoof certain fields (like Server Name Identification) and pretend
      they are eligible for preferential treatment.

   o  Deep Packet Inspection policies are strictly linked with an
      application.  This raises privacy concerns, as networks need to
      know the application that traffic originates from in order to
      enforce a policy.

   o  New privacy-enabling protocols (like DNS over HTTPS and Encrypted
      SNI) encrypt the last bits of cleartext information sent over the
      internet, further limiting DPI-based application detection.

2.3.  Requirements and Challenges

2.3.1.  Integration overhead

   Network services often require coordination between a network
   operator and an application provider.  For example, firewall
   whitelists and zero-rating programs require the coordination between
   networks and the applications to be whitelisted (or zero-rated).  It
   is typical for such programs to include a large and growing number of
   applications, and the integration process and mapping interface
   matters a lot, as it dictates the required effort for both network
   operators and application providers.

   Network operators want to streamline the onboarding process for new
   applications in their programs, and also minimize the overhead to
   keep these integrations functional and accurate.  They also want to
   make it easy for third parties to integrate and use their services.
   Network tokens enable operators to onboard new applications just by
   granting them a new token, without additional per-application
   overhead to create, evaluate, and maintain app signatures.  A token-
   based approach also decouples integration from the architecture of an
   application provider, meaning that there is no need for updates and
   maintenance every time an application partner changes its
   infrastructure.

   Decoupling integration from an application's infrastructure is
   important for the application provider's side as well.  They don't
   have to pace deployment of new servers to give partnering networks

Yiakoumis, et al.       Expires December 17, 2020               [Page 9]
Internet-Draft                networktokens                    June 2020

   advance warning to update their DPI, and they can still leverage a
   network's services even when they don't own a server or when the
   traffic is originating from a third-party service.  Another benefit
   for application providers is control.  Tokens give application
   providers the capability to decide when and how to use related
   services, so they can offer it only to a subset of their users, for a
   limited period, or run A/B experiments without any infrastructure
   overhead and without further coordination with the network.

   Regulators MAY require that zero-rating programs are available to a
   large number of application providers.  For example many zero-rating
   programs are required to onboard all applications in a category.
   Network tokens offer a straight-forward and low overhead onboarding
   process, and make it easier to keep implementations compliant.
   Regulators may also have to monitor commercial practices for
   compliance, and therefore auditability becomes important.  With
   network tokens, audits need to only check token distribution, which
   can be as simple as a database with when an application asked for a
   token, and when this was granted.

2.3.2.  Detection Accuracy

   Detection accuracy captures what percentage of traffic that falls
   under a policy gets eventually detected and treated accordingly by
   the network.  It is one of the main criteria used during a zero-
   rating integration, and where most problems appear.  One reason is
   that many applications involve traffic from third party servers that
   cannot be properly accounted for (like ads, social media add-ons, or
   traffic from public CDNs).  Another source of detection inaccuracy
   comes from application backend changes that are not properly
   communicated to or acted upon by the network operator.

   Many integrations do not happen just because of inaccuracy reasons,
   causing issues for both application providers and operators.  In
   other cases, application providers might have to change the
   functionality for such integrations to happen (e.g., disable ads)
   which can have a significant impact on their business and/or user
   experience.

   Once an integration is established, failing to detect traffic may
   lead to unintended charges for users and dissatisfaction.  Operators
   have to retroactively perform troubleshooting, deal with customer
   support, and issue refunds.

   Inaccuracies also pose a trade-off for regulators: if detection
   inaccuracies are accepted, plan transparency issues arise (e.g.,
   users might get charged for use of an application that is promoted as
   free).  In contrast, when inaccuracies are not allowed, some eligible

Yiakoumis, et al.       Expires December 17, 2020              [Page 10]
Internet-Draft                networktokens                    June 2020

   applications cannot participate without modifications to their
   implementation, thus raising issues about the openness of such
   programs or entry barriers to market.

   Network tokens are decoupled from an application's backend and can
   also be applied to third-party traffic, giving application developers
   the capability to improve accuracy without affecting the
   functionality of their apps.

2.3.3.  Fraud Prevention

   Malicious users may exploit limitations in traffic detection and get
   special treatment from the network.  This often happens in zero-
   rating services, where malicious users setup a proxy server, connect
   to it using the properties (e.g., SNI) of an otherwise zero-rated
   application, and essentially zero-rate all their traffic.

   When fraud happens it leads to lost revenue for network operators.
   To prevent fraud, some operators require that application signatures
   use only IP addresses, which are harder for bad actors to spoof.
   This in turn makes integration harder.  Many application providers
   use CDNs that share IP addresses across multiple applications, and
   they become ineligible to participate.  Others that do have their own
   IP addresses can still integrate, but at the cost of more frequent
   updates whenever as new servers (and IP addresses) are added.

   Network tokens deal with fraud through signed and/or encrypted tokens
   that can be integrity protected and resistant to replay and spoofing
   attacks.

2.3.4.  Implementing user-centric control

   One particular instance of traffic differentiation services (and
   particular QoS services) is user-centric control.  User-driven
   control can better serve the needs of end-users, and might
   additionally be driven by business and regulatory reasons.

   Network tokens provide the means to put users in charge of QoS
   treatment.  User-specific tokens can be applied to traffic directly,
   or given to applications after user consent, and be revoked at any
   time, similar with OATH2 authentication workflows.  They can be used
   in an application agnostic manner, and don't require network
   operators to limit their offerings to specific applications.

   Moreover, tokens require explicit action, are verifiable, and prevent
   abuse from third parties, which are necessary properties to build
   network services that involve charging and accounting.

Yiakoumis, et al.       Expires December 17, 2020              [Page 11]
Internet-Draft                networktokens                    June 2020

2.3.5.  Privacy

   Privacy is often at odds with traffic differentiation services,
   especially when networks have to inspect a user's traffic to enforce
   a service, and/or this happens without a user's consent.  Regulation
   around privacy, increased user awareness, as well as emerging
   protocols like Encrypted SNI and DNS over HTTPS require new ways to
   combine privacy awareness with traffic differentiation services.
   Tokens can address such concerns in a number of ways.

   Coupled with user-centric control, network operators can expose
   datapath services in an application agnostic manner and respect user
   privacy.  They do not have to detect use of specific applications at
   all, all necessary information is included within a token, and users
   explicitly share relevant information with the network upon consent.

   Network tokens can also promote privacy for application-based network
   services.  Today, if one network can detect an application (e.g.,
   through the use of SNI), every other network can as well.  Using
   network tokens, the application provider (or user) can share this
   context only with trusted networks, keeping traffic largely opaque
   for other networks.

   As protocols like ESNI and DoH emerge, network tokens enable
   application providers to adopt them, and at the same time integrate
   with trusted networks.  Respectively, they can enable network
   operators to expose traffic differentiation services, even when
   traffic is largely opaque to them.

3.  Representation

   Network tokens can be represented in different formats.  For example,
   a network operator might structure a token as a pre-defined byte
   sequence or a list of TLV-encoded fields.  Alternatively, tokens can
   use existing JOSE and COSE technologies for representation, as they
   already provide a framework to securely communicate information
   between different entities.  The actual representation and contents
   of a token should take into consideration the capabilities of the
   network to process them (i.e, what cryptographic functionality can
   the network support), the token's length in terms of header space,
   and requirements for integrity protection, privacy preservation, and
   attack scenarios.

   Examples in this document will use JWT to represent tokens, as they
   are well understood by the community and easily read by humans.
   Translation to a different representation format should be straight
   forward.

Yiakoumis, et al.       Expires December 17, 2020              [Page 12]
Internet-Draft                networktokens                    June 2020

4.  Contents

   The contents of a network token communicate the desired information
   between an endpoint and the network (e.g., the name of an
   application, or a user's request to access a low-latency services.
   Along with these claims, tokens carry necessary metadata to i)
   digitally sign and/or encrypt a token to meet privacy and security
   requirements, and ii) prevent unauthorized parties from replaying or
   using these tokens to inadvertently access network services (e.g.,
   through the use of timestamps, expiration time, nonces).

4.1.  Network Token Common fields

   Network tokens can have arbitrary fields (or claims).  The fields
   defined below, while not mandatory, provide a starting point for a
   set of useful, interoperable fields.  Network services using network
   tokens should define which specific fields they use and whether they
   are required or optional.  Several of the fields listed below are
   already registered as part of JWT and CWT specifications, while
   others are specific for network tokens.

4.1.1.  'iss' (Issuer) field

   The "iss" (issuer) field identifies the principal that issued the
   token.  For example, the issuer might be the name of the network
   operator that offers the service of interest.

4.1.2.  "sub" (Subject) field

   The "sub" (subject) field identifies the principal that is the
   subject of the token.  This could be a subscriber id, or the name of
   an application.

4.1.3.  "exp" (Expiration Time) field

   The "exp" (expiration time) field identifies the expiration time on
   or after which the token MUST NOT be accepted for processing.  The
   processing of the "exp" field requires that the current date/time
   MUST be before the expiration date/time listed in the "exp" claim.
   Implementers MAY provide for some small leeway, usually no more than
   a few minutes, to account for clock skew.  The "exp" field can be
   used to reduce the probability of replay attacks, restrict service
   access to a certain period, or to force users to refresh
   authentication credentials.

Yiakoumis, et al.       Expires December 17, 2020              [Page 13]
Internet-Draft                networktokens                    June 2020

4.1.4.  "iat" (Issued At) field

   The "iat" (issued at) field identifies the time at which the token
   was issued or generated.  This field can be used to determine the age
   of the token, and can be used along or instead of the "exp" field.

4.1.5.  "nti" field (Network Token ID) field

   The "nti" field provides a nonce-like value for the token.  The
   identifier value MUST be assigned in a manner that ensures that there
   is a negligible probability that the same value will be accidentally
   assigned to a different data object; if the application uses multiple
   issuers, collisions MUST be prevented among values produced by
   different issuers as well.  The "nti" field can be used to revoke a
   token, or prevent it from being replayed.

4.1.6.  "bip" field (Bound IP) field

   The "bip" (Bound IP) field bounds the use of the token to a specific
   IP address.  This can prevent third parties from reusing the token in
   a different context.

5.  Network Token Format

   A token consists of the following fields (Figure X):

   o  Reflect Type (4-bits): Indicates reflection properties for the
      token.

      *  0x0: Token is inserted by the origin of this flow.  No
         reflection needed.

      *  0x1: Token is inserted by the origin of this flow.  Reflect at
         receiver.

      *  0x2: Reflected token.

      *  0x3-0xf: Reserved

   o  Token Descriptor ID (28-bits): An ID that helps the network decide
      whether and how to interpret tokens.  Descriptor IDs are
      registered in the "Token Descriptor ID" registry (MSB = 0) or
      private (MSB equals 1).  For private descriptor IDs, the definer
      of the value needs to take reasonable precautions to make sure
      they are in control of the part of the namespace they use (e.g.,
      by using a OUI prefix).  A token descriptor might just indicate
      that the token payload is a JWT, or point to a structure that
      holds keys and other information to interpret a token.

Yiakoumis, et al.       Expires December 17, 2020              [Page 14]
Internet-Draft                networktokens                    June 2020

   o  Token Payload: Depending on the application, the token payload
      might be a self-contained JWT or CWT (as plaintext, signed, or
      encrypted), a set of TLV-encoded values, or has its own custom
      format.

   The length of the token is arbitrary, but must follow the limitations
   imposed by the protocol it is encapsulated.  For example, if the
   token is carried as an IPv6 hop-by-hop option, the total length of
   the token cannot exceed 2048 bytes.

                         0         1         2        3
                         0123456789012345678901245678901
                        +-------------------------------+
                        | rfl |  token descriptor id    |
                        +-------------------------------+
                        |                               |
                        |                               |
                        |         token payload         |
                        |                               |
                        |                               |
                        +-------------------------------+

6.  Example Network Tokens

   This section discusses example network tokens and how they can serve
   specific use cases.

6.1.  Application Token

   An application token can be used to whitelist traffic from trusted
   applications for a zero-rating or firewall whitelist scenario (as
   discussed in Section {#usecases}.

   The following example verifies that a network flow is coming from
   "The Godfather App".

   The token payload is encoded as a JWT, and encapsulated as a TLS
   Extension attached in a Server Hello Message.

   The Reflect Type is 0x00 (i.e., peers should not reflect it), with
   the expectation that network flows can setup appropriate state for
   the reverse flow as well.  The Token Descriptor ID is 0x03, which
   might represent a registered value for application tokens.

   The JWT encodes the following object.

   The header of the JWT has the following fields:

Yiakoumis, et al.       Expires December 17, 2020              [Page 15]
Internet-Draft                networktokens                    June 2020

   {"alg":"ES256", "kid":"N6fr1MDrEuu1eXRkFbcpX4WY62SKN7TKrhYf9PfJEd8"}

   The token is signed using the Elliptic Curve Digital Signature
   Algorithm, and the public key can be looked-up in a pre-defined
   database using the "kid" thumbprint.

   The JWT payload has the following fields:

{"sub":"The Godfather App", "iat":1588116732, "exp":1588117732,"bip":"140.54.35.194"}

   The token is created by the application provider.  It states that
   this flow originates from "The Godfather App", along with the time
   that it was created and when it expires.  The token is signed with
   the app provider's public key, and any network can verify this
   through the attached signature.  The token is also bound to a
   specific IP address, and therefore cannot be reused in a different
   context.  For example, the application provider could configure all
   exit gateways to attach a token for all outgoing flows.

6.2.  User-centric Token

   A user-centric token may be used to access a custom QoS SLA (e.g.,
   low latency) from a mobile operator.  This is an application-agnostic
   and privacy-preserving token, i.e., users can use it for any traffic
   they want and the network operator doesn't need to know what
   application is associated with ths token.

   The token payload is encoded as a JWT, and can be inserted to STUN
   (as STUN attributes) or IPv6 packets (as IPv6 Hop-by-Hop extension
   header).

   The Reflect Type is 0x1, i.e., peers should reflect the token to
   setup state for the reverse flow.  The Token Descriptor ID is 0x01,
   stating that the token payload is encoded as a JWT object.

   The header of the JWT has the following fields:

   {'alg':'dir','enc':"A256CBC-HS512", 'app_id':14098715987234}

   The token is generated by the operator, and signed with the AES-256
   algorith, using an operator's symmetric key.  The app_id points to an
   operator-specific identifier associated with its own services.

   The payload of the token has the following fields, requesting for
   low-latency treatment, and bounding the start and end time of the
   token.  It also has a unique identifier to allow revocation.

Yiakoumis, et al.       Expires December 17, 2020              [Page 16]
Internet-Draft                networktokens                    June 2020

{'srv':'lowlatency', 'msisdn':'+4151111111111', 'nti': 5871234, iat':1588116732, 'exp':1588203132}

   Each token is valid for 24 hours.  As the encryption key is bound to
   a specific user, it cannot be used by another context.  The token is
   opaque to everyone other than the operator (including the user).  The
   Operating System (or an agent) in the user's device can request a
   token, and grant it to specific applications based on a user's
   request.  Users can revoke access by telling an operator to blacklist
   the nti associated with this token.

   Besides accessing a low-latency service, this token serves two
   requirements: * it is application agnostic and can be used for any
   application a user wants * it preserves privacy.  There is no
   indication about specific applications, and no identifier that can be
   linked to a user.

7.  Network Tokens and Encapsulating protocols

   Network tokens are inserted in existing protocols by leveraging
   extension capabilities and do not require a dedicated header.  The
   contents of the token are largely opaque to the protocol that carries
   them (i.e., they cannot read or verify a token).

   To support tokens, a protocol needs to allow its users to specify the
   token to be used (e.g., while opening a socket or configuring a
   connection), and appropriately reflect a token according to the value
   of a token's Reflect Type.

   While tokens are designed to be self-contained, the protocols that
   carry them inevitably affect its use.  In particular:

   o  the maximum size of tokens is dictated by the provision of the
      protocol extension that carries them.

   o  Protocols that use a checksum over transmitted data (like TLS or
      optionally STUN) ensure that a token cannot be tampered or removed
      by intermediary nodes without the endpoints noticing it

   o  Implementations should also consider whether the protocol
      guarantees that a token is contained in a single packet or might
      be carried over multiple packets.

   This section discusses the use of tokens in three widely used
   protocols, and section {#iana} describes recommended IANA changes for
   each protocol.

Yiakoumis, et al.       Expires December 17, 2020              [Page 17]
Internet-Draft                networktokens                    June 2020

   For the examples below we will use the following 227-byte long
   network token, which encodes (in hex notation) the low-latency token
   described in Section {#lowlatencytoken}.

10000001 # Network token is represented as JWT, reflect at node
65794a68624763694f694a6b615849694c434a6c626d4d694f694a424d6a553251304a444c556
8544e544579496e302e2e565f4278546d4e692d6b6337735a376b504e514851412e5a42764269
6d6d46705579555165e544579634b36244566a31378546d4e692d6b6337735a376b50476676c4
7597579666f734b43565234744576306a4d31735f4352484c50706a6335536d37703336487576
677541467c7979396f3a526e7976532484cd37703336487553559797170e514851412e5a42764
2696d6d4670557955516576676c47597579666f734b43565234744576306a4d31716535597971
702d5946796838566a396f72337a7351624e6d4e6475796974727658436854766c66633055704
4545597d429869d34e5486a63963305f6a5267424f39745a6e4535438566a396fe64757969747
27658766c6655704417e252636f267349565f36d585a6e4547568f7672637835f4352484c5417
72e32556e32636a6f6a5267424f396349565f7869536d586357745a6e4535495475684973456a
4f76726378472e3f9 # Network token payload (as JWE)

7.1.  Network Tokens as a TLS Extension

   Network tokens can be encoded as TLS extensions during the handshake
   phase in ClientHello, ServerHello, and HelloRetryRequest messages, as
   these are defined in [RFC8446].  As the handshake happens before
   encryption is established between the two communicating endpoints,
   the token will be sent unchanged and can be interpreted by any
   trusted networks.

   Network tokens used as TLS extension are flow-specific, i.e., the
   network should apply the policy linked to this token to all packets
   that belong to this flow.

   The token comprises the extension data.  Section {#iana} requests the
   value 57 as a Network Token extension type.  For TLS backward
   compatibility, the first 16-bit after the extension type should
   encode the length of the extension data.  The following bytestream
   defines the extension, including type and lengh data:

Yiakoumis, et al.       Expires December 17, 2020              [Page 18]
Internet-Draft                networktokens                    June 2020

3900e3  # Network Token Extension with 227 bytes length
1000001 # Network token is represented as JWT, reflect at node
65794a68624763694f694a6b615849694c434a6c626d4d694f694a424d6a553251304a444c556
8544e544579496e302e2e565f4278546d4e692d6b6337735a376b504e514851412e5a42764269
6d6d46705579555165e544579634b36244566a31378546d4e692d6b6337735a376b50476676c4
7597579666f734b43565234744576306a4d31735f4352484c50706a6335536d37703336487576
677541467c7979396f3a526e7976532484cd37703336487553559797170e514851412e5a42764
2696d6d4670557955516576676c47597579666f734b43565234744576306a4d31716535597971
702d5946796838566a396f72337a7351624e6d4e6475796974727658436854766c66633055704
4545597d429869d34e5486a63963305f6a5267424f39745a6e4535438566a396fe64757969747
27658766c6655704417e252636f267349565f36d585a6e4547568f7672637835f4352484c5417
72e32556e32636a6f6a5267424f396349565f7869536d586357745a6e4535495475684973456a
4f76726378472e3f9 # Network token payload (as JWE)

   If the reflect type is set to 0, the peer takes no additional step.
   If reflect type is 0x1, the peer should attach a Network Token
   request at the ServerHello message, set the type to 0x2, and copy the
   rest of the token in it.  The extension data for the ServerHello
   message that reflects the token mentioned above is listed below.

3900e3  # Network Token Extension with 227 bytes length
2000001 # Network token is represented as JWT, reflected token
65794a68624763694f694a6b615849694c434a6c626d4d694f694a424d6a553251304a444c556
8544e544579496e302e2e565f4278546d4e692d6b6337735a376b504e514851412e5a42764269
6d6d46705579555165e544579634b36244566a31378546d4e692d6b6337735a376b50476676c4
7597579666f734b43565234744576306a4d31735f4352484c50706a6335536d37703336487576
677541467c7979396f3a526e7976532484cd37703336487553559797170e514851412e5a42764
2696d6d4670557955516576676c47597579666f734b43565234744576306a4d31716535597971
702d5946796838566a396f72337a7351624e6d4e6475796974727658436854766c66633055704
4545597d429869d34e5486a63963305f6a5267424f39745a6e4535438566a396fe64757969747
27658766c6655704417e252636f267349565f36d585a6e4547568f7672637835f4352484c5417
72e32556e32636a6f6a5267424f396349565f7869536d586357745a6e4535495475684973456a
4f76726378472e3f9 # Network token payload (as JWE)

   TLS does not allow for extensions to be originated by the server if
   they are not defined in the ClientHello message.  To account for
   cases where tokens need to be inserted by the server, the client
   might send an empty Network Token extension which allows the server
   to respond to with the appropriate token.  Alternatively, the server
   can use a HelloRequestRetry message to ask the peer to re-send a
   ClientHello message with the NetworkToken extension included.  The
   HelloRequestRetry should include the token.  Depending on the reflect
   type the client peer might include an empty or populated Network
   Token extension on the subsequent ClientHello message.

   The use of Network Token between ClientHello, ServerHello, and
   HelloRequestRetry messages resembles the mechanics of the cookie TLS
   extension.

Yiakoumis, et al.       Expires December 17, 2020              [Page 19]
Internet-Draft                networktokens                    June 2020

   The TLS handshake is protected for message integrity, and as such
   guarantees that network tokens cannot be dropped by intermediary
   nodes.

7.2.  Network Tokens as a STUN Attribute

   Network tokens can be inserted as attributes in STUN Binding Request
   and Binding Response messages, during the handshake that preceeds
   WebRTC realtime communication flows [RFC5389].

   Network tokens used as STUN attributes are flow-specific, i.e., the
   network should apply the policy linked to this token to all packets
   that belong to this flow.

   The token comprises the attribute data.  Section {#iana} requests the
   value 0x8030 as a Network Token STUN attribute.  The following
   bytestream shows the attribute for the low-latency token described
   earlier, including attribute type and length.

   (TODO: We need to deal with padding here as STUN requires 32-bit
   boundaries.)

803000e3  # Network Token Attribute with 227 bytes length
1000001 # Network token is represented as JWT, reflect at node
65794a68624763694f694a6b615849694c434a6c626d4d694f694a424d6a553251304a444c556
8544e544579496e302e2e565f4278546d4e692d6b6337735a376b504e514851412e5a42764269
6d6d46705579555165e544579634b36244566a31378546d4e692d6b6337735a376b50476676c4
7597579666f734b43565234744576306a4d31735f4352484c50706a6335536d37703336487576
677541467c7979396f3a526e7976532484cd37703336487553559797170e514851412e5a42764
2696d6d4670557955516576676c47597579666f734b43565234744576306a4d31716535597971
702d5946796838566a396f72337a7351624e6d4e6475796974727658436854766c66633055704
4545597d429869d34e5486a63963305f6a5267424f39745a6e4535438566a396fe64757969747
27658766c6655704417e252636f267349565f36d585a6e4547568f7672637835f4352484c5417
72e32556e32636a6f6a5267424f396349565f7869536d586357745a6e4535495475684973456a
4f76726378472e3f9 # Network token payload (as JWE)

   If the reflect type is set to 0, the peer takes no additional step.
   If reflect type is 0x1, the peer should attach a Network Token
   request at the Binding Response message, set the type to 0x2, and
   copy the rest of the token in it.  The attribute data for the Binding
   Response message that reflects the token mentioned above is listed
   below.

Yiakoumis, et al.       Expires December 17, 2020              [Page 20]
Internet-Draft                networktokens                    June 2020

803000e3  # Network Token Extension with 227 bytes length
2000001 # Network token is represented as JWT, reflected token
65794a68624763694f694a6b615849694c434a6c626d4d694f694a424d6a553251304a444c556
8544e544579496e302e2e565f4278546d4e692d6b6337735a376b504e514851412e5a42764269
6d6d46705579555165e544579634b36244566a31378546d4e692d6b6337735a376b50476676c4
7597579666f734b43565234744576306a4d31735f4352484c50706a6335536d37703336487576
677541467c7979396f3a526e7976532484cd37703336487553559797170e514851412e5a42764
2696d6d4670557955516576676c47597579666f734b43565234744576306a4d31716535597971
702d5946796838566a396f72337a7351624e6d4e6475796974727658436854766c66633055704
4545597d429869d34e5486a63963305f6a5267424f39745a6e4535438566a396fe64757969747
27658766c6655704417e252636f267349565f36d585a6e4547568f7672637835f4352484c5417
72e32556e32636a6f6a5267424f396349565f7869536d586357745a6e4535495475684973456a
4f76726378472e3f9 # Network token payload (as JWE)

   STUN messages can be protected for message integrity, and as such
   they can guarantee that network tokens cannot be dropped by
   intermediary nodes.

7.3.  Network Tokens as an IPv6 Hop-by-Hop Extension Header

   Network tokens can be inserted as an IPv6 Hop-by-Hop Extension
   header, as defined in Section 4 of [RFC8200].

   Network tokens used as IPv6 extension headers can be either flow or
   packet specific.  The expectation must be defined by the network
   service itself, and the endpoints can decide to which packets to
   insert a token.  For example, they can insert a token at every packet
   of a specific flow, every few seconds, or only at the first packet of
   a flow.  The network should accordingly implement the policy.

   When tokens are attached to all packets of a flow, it is important to
   keep the length of the token small, to avoid overhead.  It is
   therefore recommended that in such cases implementations consider
   representation formats that can minimize the overall length of a
   token.  Size-efficient representation formats are out-of-scope for
   this document.

   The token comprises the IPv6 extension header data.  Section {#iana}
   requests the value 0x1F as a Network Token Extension Header.  The
   following bytestream shows the header for the low-latency token
   described earlier, including option type and length (in 8-octet
   units).

Yiakoumis, et al.       Expires December 17, 2020              [Page 21]
Internet-Draft                networktokens                    June 2020

1f1d  # Network Token Hop-by-Hop option with 29 8-octet length
1000001 # Network token is represented as JWT, reflect at node
65794a68624763694f694a6b615849694c434a6c626d4d694f694a424d6a553251304a444c556
8544e544579496e302e2e565f4278546d4e692d6b6337735a376b504e514851412e5a42764269
6d6d46705579555165e544579634b36244566a31378546d4e692d6b6337735a376b50476676c4
7597579666f734b43565234744576306a4d31735f4352484c50706a6335536d37703336487576
677541467c7979396f3a526e7976532484cd37703336487553559797170e514851412e5a42764
2696d6d4670557955516576676c47597579666f734b43565234744576306a4d31716535597971
702d5946796838566a396f72337a7351624e6d4e6475796974727658436854766c66633055704
4545597d429869d34e5486a63963305f6a5267424f39745a6e4535438566a396fe64757969747
27658766c6655704417e252636f267349565f36d585a6e4547568f7672637835f4352484c5417
72e32556e32636a6f6a5267424f396349565f7869536d586357745a6e4535495475684973456a
4f76726378472e3f9 # Network token payload (as JWE)

   If the reflect type is set to 0, the peer takes no additional step.
   If reflect type is 0x1, the peer should attach the Network Token Hop-
   by-hop option for messages in the reverse direction for this flow,
   set the type to 0x2, and copy the rest of the token in it.  The data
   for the Hop-By-Hop option that reflects the token mentioned above is
   listed below.

1f1d  # Network Token Hop-by-Hop option with 29-octet bytes length
2000001 # Network token is represented as JWT, reflected token
65794a68624763694f694a6b615849694c434a6c626d4d694f694a424d6a553251304a444c556
8544e544579496e302e2e565f4278546d4e692d6b6337735a376b504e514851412e5a42764269
6d6d46705579555165e544579634b36244566a31378546d4e692d6b6337735a376b50476676c4
7597579666f734b43565234744576306a4d31735f4352484c50706a6335536d37703336487576
677541467c7979396f3a526e7976532484cd37703336487553559797170e514851412e5a42764
2696d6d4670557955516576676c47597579666f734b43565234744576306a4d31716535597971
702d5946796838566a396f72337a7351624e6d4e6475796974727658436854766c66633055704
4545597d429869d34e5486a63963305f6a5267424f39745a6e4535438566a396fe64757969747
27658766c6655704417e252636f267349565f36d585a6e4547568f7672637835f4352484c5417
72e32556e32636a6f6a5267424f396349565f7869536d586357745a6e4535495475684973456a
4f76726378472e3f9 # Network token payload (as JWE)

   TODO (YY): There is no clear way currently for peers to understand
   how to reflect tokens (per-packet, per-flow, and when).  If this is
   understood by the context of the token the peer will need to be aware
   of the token, which is undesired.  The token should have all
   information regarding reflection.  We have to see whether the current
   two-bits can clarify this, or whether we need to make reflection part
   of the protocol-specific part and not the token itself.

8.  Implementation Considerations

   Network token applications (and their implementations) must decide
   the contents of the token, what protocol to insert them to, whether
   tokens are per-packet or per-flow, and whether they need to be

Yiakoumis, et al.       Expires December 17, 2020              [Page 22]
Internet-Draft                networktokens                    June 2020

   reflected by peers on the reverse flow.  This section discusses
   common consideration.

8.1.  Contents

   When deciding the contents of a token, applications should take
   effort to include only the necessary information and keep the size of
   the token small.  They should also take into consideration the trust
   relationships between different stakeholders (i.e., the network
   operator, the application provider, the operating system, the end
   user) and pick the right encryption and signing properties.  Another
   element to consider is potential abuse scenarios and how to prevent
   token replays and protect from malicious users, given assumptions
   around the network architecture.  For example, to prevent use of a
   user-specific token by a another user, a token might be bound to a
   user identifier that the network can separately verify while
   processing packets and tokens (e.g., a well-defined IP address or an
   MSISDN in case of a cellular network).

8.2.  Encapsulating protocol

   This specification describes three protocols where tokens might be
   inserted, and it is expected that this list will grow.

   IPv6 tokens sit at the narrow waist, can be applied to any traffic,
   and support both per-packet and per-flow granularity.  IPv6 tokens
   require OS support for any practical usecase.  The downside of IPv6
   tokens is that IPv6 adoption is still limited, and many networks drop
   packets with IPv6 extension headers with rates described in
   [RFC7872].  However, this is expected to improve over time.

   TLS tokens are limited to TLS/DTLS sessions, and can only be used at
   a flow granularity.  Implementation does not depend on the OS, but
   rather at the cryptographic library used (e.g., BoringSSL or
   OpenSSL).  As TLS handshake is integrity-protected, intermediate
   nodes cannot drop or alter a token.

   STUN tokens are targeted to real-time communications, and can only be
   used at a flow granularity.  Implementation does not depend on the
   OS, but rather at the library that initiates the related flows (e.g.,
   WebRTC).  As STUN messages are integrity-protected, intermediate
   nodes cannot drop or alter a token.

   The primary reason for making network tokens protocol agnostic is to
   ease adoption and enable interested parties (Operating System,
   application providers, users, network vendors and operators) to use
   them in a way that better fits the intended usecase.  The protocol to
   use will largely depend on the parties involved in a usecase, the

Yiakoumis, et al.       Expires December 17, 2020              [Page 23]
Internet-Draft                networktokens                    June 2020

   availability of tokens in different protocols, and the capability of
   endpoints and the network to insert and interpret tokens.

   When possible, networks should make efforts to accept tokens in
   different protocols to allow further adoption from endpoints.  As
   processing of tokens remains the same independent of the protocol
   that carries them, the main overhead from detecting tokens in
   multiple protocols will come from parsing and detecting tokens in
   different parts of the header.

8.3.  Network Token granularity

   The granularity of a token is either per-packet or per-flow and is
   closely related with the protocol where tokens are inserted.  The
   trade-offs for each option are discussed below.

8.3.1.  Per-packet granularity

   Per-packet granularity allows stateless processing from network nodes
   and the capability to pinpoint the exact packets for traffic
   differentiation (e.g., for flows that combine multple types of
   traffic).  Moreover, it preserves policy if the flow of interest gets
   rerouted.

   On the other hand, per-packet granularity limits potential
   encapsulating protocols.  From the protocols described in this
   specification only IPv6 allows per-packet granularity.

   Per-packet granularity implies that all packet processing will
   involve cryptographic functions which might be expensive (or
   unavailable).  Finally, the size of the token should be small as it
   will add overhead to all packets.

8.3.2.  Per-flow granularity

   Tokens with per-flow granularity can be inserted in multiple
   protocols.  As the token is sent only once per flow, its size is less
   important compared to per-packet tokens.  Limiting crypto to one
   packet per flow reduces the packet processing overhead, and allows
   implementations that combine a fast path (with no crypto support)
   with a slow, crypto-enabled path.

   The main disadvantage of per-flow granularity is that it requires
   per-flow state.  As policy enforcement depends on this state, per-
   flow granularity also requires that all packets of this flow will get
   routed through the node that interprets tokens.

Yiakoumis, et al.       Expires December 17, 2020              [Page 24]
Internet-Draft                networktokens                    June 2020

8.4.  Token to DiffServ mapping and reflection

   Tokens might be interpreted one or more times within a network.

   In many cases, a single interpretation will be enough.  One example
   is network policies that are enforced at a single point and involve
   per-flow state (like zero-rating).  In such scenarios, token
   interpretation and policy enforcement can take place all in once.
   Alternatively, when policy enforcement involves multiple nodes (e.g.,
   a low-latency service that spans the wired and radio network),
   network owners can use existing mechanisms (like DiffServ, QCI tags,
   or reflective QoS) to enforce the policy across multiple nodes within
   the same network domain.

   In cases where a reverse flow might get routed through a different
   path, token reflection should be used.

9.  Security Considerations

   As any cryptographic application, it is important for users of
   network token applications to protect asymmetric private and
   symmetric secret keys, and employ countermeasures to various attacks.

   The security of network tokens relies upon on the protections offered
   by the underlying signing and encryption technologies.  It is
   therefore recommended that implementations of network tokens use
   existing and well-understood cryptographic frameworks (like JOSE and
   COSE) to protect tokens, or careful consider security implications if
   they provide their own format.

   While tokens are integrity protected, an intermediary node can in
   theory replace or remove a token.  Protection against this can be
   provided by additional integrity protection from the encapsulating
   protocol itself, as is the case with TLS handshakes and STUN.

   Network tokens may require processing in software, as current
   hardware platforms do not support cryptographic capabilities.  This
   might impose a security risk and exposure to an attack, as traffic
   could be diverted towards the slow path, and in return degrade the
   overall performance of a node.  It is recommended that
   implementations adequately account for such scenarios, either by
   setting a rate-limit to packets that go through a slow path or
   ensuring that the overall functionality is not affected.

Yiakoumis, et al.       Expires December 17, 2020              [Page 25]
Internet-Draft                networktokens                    June 2020

10.  IANA Considerations { #iana }

10.1.  Token Descriptor ID Registry

   This section establishes the IANA "Network Token Descriptor ID"
   registry for token descriptors.  The registry records the descriptor
   ID and a reference to the specification that defines it.

   Values are registered on a Specification Required [RFC5226] basis
   after a three-week review period, on the advice of one or more
   Designated Experts.  However, to allow for the allocation of values
   prior to publication, the Designated Experts may approve registration
   once they are satisfied that such a specification will be published.

   Within the review period, the Designated Experts will either approve
   or deny the registration request, communicating this decision to the
   review list and IANA.  Denials should include an explanation and, if
   applicable, suggestions as to how to make the request successful.

   Criteria that should be applied by the Designated Experts includes
   determining whether the proposed registration duplicates existing
   functionality, whether it is likely to be of general applicability or
   whether it is useful only for a single application, and whether the
   registration description is clear.

10.1.1.  Initial Registry Contents

   o  Token Descriptor ID: 0x1

   o  Description: Token is represented as a JSON Web Token

   o  Specificaton Document(s): This document.

   o  Token Descriptor ID: 0x2

   o  Description: Token is represented as a Concise Binary
      Representation Object

   o  Specification Document(s): This document

10.2.  IPv6 Hop-By-Hop options registration

   This section registers the value 0x0F as a IPv6 Hop-By-Hop and
   Destination Option for network tokens.

   o  Hex Value: 0x1F

   o  Binary Value: 0x00011111

Yiakoumis, et al.       Expires December 17, 2020              [Page 26]
Internet-Draft                networktokens                    June 2020

   o  Description: Network Token

   o  Reference: This document

10.3.  TLS ExtensionType Registry

   This section registers the value 57 as a TLS Extension Type for
   network tokens.

   o  Value: 57

   o  Description: Network Token

   o  Reference: This document

10.4.  STUN Attributes Registry

   This section registers the value 0x8030 as a STUN attribute for
   network tokens.

   o  Value: 0x8030

   o  Description: Network Token

   o  Reference: This document

11.  References

11.1.  Normative References

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              DOI 10.17487/RFC5389, October 2008,
              <https://www.rfc-editor.org/info/rfc5389>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/info/rfc7516>.

Yiakoumis, et al.       Expires December 17, 2020              [Page 27]
Internet-Draft                networktokens                    June 2020

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC7872]  Gont, F., Linkova, J., Chown, T., and W. Liu,
              "Observations on the Dropping of Packets with IPv6
              Extension Headers in the Real World", RFC 7872,
              DOI 10.17487/RFC7872, June 2016,
              <https://www.rfc-editor.org/info/rfc7872>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
              May 2018, <https://www.rfc-editor.org/info/rfc8392>.

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

11.2.  Informative References

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

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
              <https://www.rfc-editor.org/info/rfc2475>.

Authors' Addresses

   Yiannis Yiakoumis
   Selfie Networks, Inc

   Email: yiannis@selfienetworks.com

   Nick McKeown
   Stanford University

   Email: nickm@stanford.edu

Yiakoumis, et al.       Expires December 17, 2020              [Page 28]
Internet-Draft                networktokens                    June 2020

   Frode Sorensen
   Norwegian Communications Authority

   Email: frode.sorensen@nkom.no

Yiakoumis, et al.       Expires December 17, 2020              [Page 29]