Draft: draft-ietf-capport-architecture

Commentary: We decided to reduce the scope of the signalling protocol during ietf 102 in Montreal ( Issue ) .This attempts to do so . Reduced signalling interactions from SHOULDs to a MAYs Removed references to trusting / validating / authenticating / etc the Signal reduced API extensibility text so that it no longer includes various unnecessary things , including signal validation tokens Removed section on the " upgrade " path of sending signal in conjunction with redirecting changed a bit of language around to make it clear that the signal is truly optional Fixed a few nits Changed the " Conditions About to Expire " example to discuss the UE querying the API , rather than relying on a pre - emptive signals . 
 We concluded in Montreal to look at removing details of the signaling protocol that we have n't decided on yet . For instance , we do n't need to describe whether the signal is authenticated . 
 Discussed and generally agreed at IETF 103 . We should do this . 
 Looks good in general . Just some nits to have clarity in the text .
Solutions MAY allow a device to be alerted that it is in a captive
network when attempting to use any application on the network.
The architecture SHOULD improve security by providing mechanisms
for trust, allowing alerts from trusted network operators to be
distinguished from attacks from untrusted agents.
End-user devices are notified of captivity with Captive Portal
Signals in response to traffic.  This notification should work
with any Internet protocol, not just clear-text HTTP.  This
notification does not carry the portal URI; rather it provides a
notification to the User Equipment that it is in a captive state.
This document will specify requirements for the signaling protocol
which will generate Captive Portal Signals.
Receipt of a Captive Portal Signal informs an end-user device that
it is captive.  In response, the device SHOULD query the
provisioned API to obtain information about the network state.
The device MAY take immediate action to satisfy the portal
(according to its configuration/policy).
End-user devices can be notified of captivity with Captive Portal
Signals in response to traffic.  This notification should work
with any Internet protocol, not just clear-text HTTP.  This
notification does not carry the portal URI; rather it provides a
notification to the User Equipment that it is in a captive state.
This document will specify requirements for a signaling protocol
which could generate Captive Portal Signals.
Receipt of a Captive Portal Signal informs an end-user device that
it could be captive.  In response, the device MAY query the
provisioned API to obtain information about the network state.
The device MAY take immediate action to satisfy the portal
(according to its configuration/policy).
Captive Portal Enforcement: The network equipment which enforces the
traffic restriction and notifies the User Equipment it is in a
captive state.
Captive Portal Enforcement: The network equipment which enforces the
traffic restriction.
Captive Portal Signaling Protocol: Also known as Signaling Protocol.
A protocol used by the Enforcement device to signal the User
Equipment information about the state of its captivity.
Captive Portal Signal: A notification from the network used to inform
the User Equipment that the state of its captivity could have
changed.
Captive Portal Signaling Protocol: Also known as Signaling Protocol.
The protocol for communicating Captive Portal Signals.
SHOULD be able to receive and validate the Captive Portal Signal,
and to access the Captive Portal API in response.
The API MUST be extensible to support future use-cases by allowing
extensible information elements.  Suggestions include quota
information, expiry time, method of providing credentials, security
token for validating Captive Portal Signals.
The API MUST be extensible to support future use-cases by allowing
extensible information elements.
User Equipment may send traffic outside the captive network prior to
the Enforcement device granting it access.  The Enforcement Device
rightly blocks or resets these requests.  However, lacking a signal
from the Enforcement Device, the User Equipment can only guess at
whether it is captive.  Consequently, allowing the Enforcement Device
to signal to the User Equipment that there is a problem with its
connectivity may improve the user's experience.
User Equipment may send traffic outside the captive network prior to
the Enforcement device granting it access.  The Enforcement Device
rightly blocks or resets these requests.  However, lacking a signal
from the Enforcement Device or interaction with the API server, the
User Equipment can only guess at whether it is captive.
Consequently, allowing the Enforcement Device to signal to the User
Equipment that there is a problem with its connectivity may improve
the user's experience.
The protocol SHOULD have a method of identifying the source of
signals.
The signal SHOULD NOT include any information other than a prompt
to contact the API, and any information necessary for validation.
There is no requirement that the protocol be reliable.  Thus, The
protocol SHOULD continue to send signals as long as the state
which triggered the first signal holds, subject to reasonable rate
limiting.  This is necessary to handle network loss or rate limits
between the Enforcement Device and the User Equipment.
The Captive Portal Enforcement function SHOULD send Captive Portal
Signals when disallowed User Equipment attempts to send to the
network.  These signals MUST be rate-limited to a configurable rate.
The signal SHOULD NOT include any information other than an
indication that traffic is restricted, which can be used as a
prompt to contact the API.
The Captive Portal Enforcement function MAY send Captive Portal
Signals when disallowed User Equipment attempts to send to the
network.  These signals MUST be rate-limited to a configurable rate.
The Captive Portal Enforcement device either allows the User
Equipment's packets to the external network, or responds with a
Captive Portal Signal.
The Captive Portal Enforcement device either allows the User
Equipment's packets to the external network, or if a signal has
been implemented, responds with a Captive Portal Signal.
This section describes a possible work-flow when conditions expire
and the user visits the portal again (e.g., low quota, or time
expiry).
Precondition: the Captive Portal Enforcement has been configured
to detect an expiry condition, which has now occurred.
The User Equipment sends a packet to the outside network.
The Captive Portal Enforcement detects that the packet is from an
expired User Equipment.
The Captive Portal Enforcement sends a Captive Portal Signal to
the User Equipment indicating that it needs to refresh its access.
The User Equipment verifies the signal is plausible.
The User Equipment queries the Captive Portal API to refresh
parameters and status of the Captive Network.
If necessary, the User once again navigates the web portal to gain
access to the external network.
The Captive Portal API Server gives more quota (time, bytes, etc.)
to the User Equipment by indicating to the Captive Portal
Enforcement the new, extended quota.
The User Equipment accesses the external network.
This section describes a possible work-flow when access is about to
expire.