CAPPORT Architecture
draft-ietf-capport-architecture-06

The information below is for an old version of the document
Document Type Active Internet-Draft (capport WG)
Last updated 2020-03-31 (latest revision 2020-02-15)
Replaces draft-larose-capport-architecture
Stream IETF
Intended RFC status Informational
Formats pdf htmlized (tools) htmlized bibtex
Reviews
Stream WG state WG Document
Document shepherd Martin Thomson
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to Martin Thomson <mt@lowentropy.net>
Internet Engineering Task Force                                K. Larose
Internet-Draft                                                  Agilicus
Intended status: Informational                                 D. Dolson
Expires: 18 August 2020                                                 
                                                                  H. Liu
                                                        15 February 2020

                          CAPPORT Architecture
                   draft-ietf-capport-architecture-06

Abstract

   This document aims to document consensus on the CAPPORT architecture.
   DHCP or Router Advertisements, an optional signaling protocol, and an
   HTTP API are used to provide the solution.  The role of Provisioning
   Domains (PvDs) is described.

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 18 August 2020.

Copyright Notice

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

   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.

Larose, et al.           Expires 18 August 2020                 [Page 1]
Internet-Draft            CAPPORT Architecture             February 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Components  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  User Equipment  . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Provisioning Service  . . . . . . . . . . . . . . . . . .   6
       2.2.1.  DHCP or Router Advertisements . . . . . . . . . . . .   6
       2.2.2.  Provisioning Domains  . . . . . . . . . . . . . . . .   6
     2.3.  Captive Portal API Server . . . . . . . . . . . . . . . .   6
     2.4.  Captive Portal Enforcement  . . . . . . . . . . . . . . .   7
     2.5.  Captive Portal Signal . . . . . . . . . . . . . . . . . .   8
     2.6.  Component Diagram . . . . . . . . . . . . . . . . . . . .   9
   3.  User Equipment Identity . . . . . . . . . . . . . . . . . . .  10
     3.1.  Identifiers . . . . . . . . . . . . . . . . . . . . . . .  10
     3.2.  Recommended Properties  . . . . . . . . . . . . . . . . .  10
       3.2.1.  Uniquely Identify User Equipment  . . . . . . . . . .  11
       3.2.2.  Hard to Spoof . . . . . . . . . . . . . . . . . . . .  11
       3.2.3.  Visible to the API Server . . . . . . . . . . . . . .  11
       3.2.4.  Visible to the Enforcement Device . . . . . . . . . .  11
     3.3.  Evaluating an Identifier  . . . . . . . . . . . . . . . .  12
     3.4.  Examples of an Identifier . . . . . . . . . . . . . . . .  12
       3.4.1.  Physical Interface  . . . . . . . . . . . . . . . . .  12
       3.4.2.  IP Address  . . . . . . . . . . . . . . . . . . . . .  13
       3.4.3.  Context-free URL  . . . . . . . . . . . . . . . . . .  14
   4.  Solution Workflow . . . . . . . . . . . . . . . . . . . . . .  14
     4.1.  Initial Connection  . . . . . . . . . . . . . . . . . . .  14
     4.2.  Conditions About to Expire  . . . . . . . . . . . . . . .  15
     4.3.  Handling of Changes in Portal URI . . . . . . . . . . . .  15
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
     7.1.  Trusting the Network  . . . . . . . . . . . . . . . . . .  16
     7.2.  Authenticated APIs  . . . . . . . . . . . . . . . . . . .  16
     7.3.  Secure APIs . . . . . . . . . . . . . . . . . . . . . . .  17
     7.4.  Risks Associated with the Signaling Protocol  . . . . . .  17
     7.5.  User Options  . . . . . . . . . . . . . . . . . . . . . .  17
Show full document text