Draft: draft-ietf-capport-architecture

Commentary: This PR attempts to deal with issue by replacing references to ICMP with a generic signaling protocols , then specifying requirements for it . 
 I missed some stuff in here . My big long list of todos got messed up , so I thought I was done this bit . :/ Basically , some diagrams / etc still need work . I 'll take your feedback while finishing it up . 
 We need a firm decision about inclusion or not . If we include it , then we need a doc defining mechanisms . 
 If included , ICMP must only be used as a hint to query the API . The UE should rate - limit queries to the API . Example polocy : even if 1000 ICMP msgs / s , only query the API once every 5s . 
 We decided in IETF 101 to remove ICMP from being explicitly mentioned , and instead put requirements into the document for a signal . 
 Removed
This document aims to document consensus on the CAPPORT architecture.
DHCP or Router Advertisements, ICMP, and an HTTP API are used to
provide the solution.  The role of Provisioning Domains (PvDs) is
described.
In this document, "Captive Portal" is used to describe a network to
which a device may be voluntarily attached, such that network access
is limited until some requirements have been fulfilled.  Typically a
user is required to use a web browser to fulfil requirements imposed
by the network operator, such as reading advertisements, accepting an
acceptable-use policy, or providing some form of credentials.
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.
In this document, "Captive Portal" is used to describe a network to
which a device may be voluntarily attached, such that network access
is limited until some requirements have been fulfilled.  Typically a
user is required to use a web browser to fulfill requirements imposed
by the network operator, such as reading advertisements, accepting an
acceptable-use policy, or providing some form of credentials.
End-user devices are notified of captivity with ICMP/ICMP6
messages in response to traffic.  This notification can 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.
Receipt of the ICMP/ICMP6 messages 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 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).
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.
SHOULD be able to receive and validate the Captive Portal ICMP
message types, and to access the Captive Portal API in response.
SHOULD be able to receive and validate the Captive Portal Signal,
and to access the Captive Portal API in response.
The PvD server MUST support multiple (repeated) queries from each
User Equipment, always returning the current captive portal
information.  The User Equipment is expected to make this query upon
receiving (and validating) an ICMP Captive Portal message (see
section_icmp).
The PvD server MUST support multiple (repeated) queries from each
User Equipment, always returning the current captive portal
information.  The User Equipment is expected to make this query upon
receiving (and validating) a Captive Portal Signal (see
section_signal).
This architecture expects the User Equipment to query the API when
the User Equipment attaches to the network and multiple times
thereafter.  Therefore the API MUST support multiple repeated queries
from the same User Equipment, returning current state of captivity
for the equipment.
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 ICMP messages.
This architecture expects the User Equipment to query the API when
the User Equipment attaches to the network and multiple times
thereafter.  Therefore the API MUST support multiple repeated queries
from the same User Equipment, returning the current state of
captivity for the equipment.
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.
Blocks (discards) traffic and sends ICMP notifications for
disallowed User Equipment.
Blocks (discards) traffic for disallowed User Equipment.
May signal User Equipment using the Captive Portal Signaling
protocol if traffic is blocked.
ICMP messages have been selected for indicating to a sender that
packets could not be delivered for reason of a network policy (in
particular, captive portal).  ICMP is already used to indicate
reasons that packets could not be delivered (network unreachable,
port unreachable, packet too large, etc.).
A mechanism to trigger captive portal work-flows in the User
Equipment is proposed in I-D.wkumari-capport-icmp-unreach.
The Captive Portal Enforcement function is REQUIRED to send such ICMP
messages when disallowed User Equipment attempts to send to the
network.  These ICMP messages MUST be rate-limited to a configurable
rate.
The ICMP messages MUST NOT be sent to the Internet devices.  The
indications are only sent to the User Equipment.
The User Equipment operating system is NOT REQUIRED to deliver the
impact of the ICMP message to the application that triggered it.  The
User Equipment might be able to satisfy the Captive Portal
requirements quickly enough that existing transport connections are
not impacted.
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.
An Enforcement Device may also want to inform the User Equipment of a
pending expiry of its access to the external network, so providing
the Enforcement Device the ability to preemptively signal may be
desirable.
The notification SHOULD NOT be easy to spoof.  If an attacker can
send spoofed notifications to the User Equipment, they can cause
the User Equipment to unnecessarily access the API.  Rather than
relying solely on rate limits to prevent problems, a good protocol
will strive to limit the feasibility of such attacks.
It SHOULD be possible to send the notification before the captive
portal closes.  This will help ensure seamless connectivity for
the user, as the User Equipment will not need to wait for a
network failure to refresh its login.  On receipt of preemptive
notification, the User Equipment can prompt the user to refresh.
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 signals MUST NOT be sent to the Internet devices.  The
indications are only sent to the User Equipment.
The Captive Portal Enforcement device either allows the User
Equipment's packets to the external network, or responds with an
ICMP message.
The Captive Portal Enforcement device either allows the User
Equipment's packets to the external network, or responds with a
Captive Portal Signal.
An Identifier is a chatacteristic of the User Equipment used by the
components of a Captive Portal to uniquely determine which specific
User Equipment is interacting with them.  An Identifier MAY be a
field contained in packets sent by the User Equipment to the External
Network.  Or, an Identifier MAY be an ephemeral property not
contained in packets destined for the External Network, but instead
correlated with such information through knowledge available to the
different components.
An Identifier is a characteristic of the User Equipment used by the
components of a Captive Portal to uniquely determine which specific
User Equipment is interacting with them.  An Identifier MAY be a
field contained in packets sent by the User Equipment to the External
Network.  Or, an Identifier MAY be an ephemeral property not
contained in packets destined for the External Network, but instead
correlated with such information through knowledge available to the
different components.
Over time, the user equipment identified by the value MAY change.
Allowing the identified device to change over time ensures that the
space of possible identifying vallues need not be overly large.
Independent Captive Portals MAY use the same identifying value to
identify different User Equipment.  Allowing indendent captive
portals to reuse identifying values allows the identifier to be a
property of the local network, expanding the space of possible
identifiers.
Over time, the user equipment identified by the value MAY change.
Allowing the identified device to change over time ensures that the
space of possible identifying values need not be overly large.
Independent Captive Portals MAY use the same identifying value to
identify different User Equipment.  Allowing independent captive
portals to reuse identifying values allows the identifier to be a
property of the local network, expanding the space of possible
identifiers.
To evaluate whether an identifer is appropriate, one should consider
every recommended property from the perspective of interactions among
the components in the architecture.  When comparing identifiers,
choose the one which best satifies all of the recommended properties.
The architecture does not provide an exact measure of how well an
identifier satisfies a given property; care should be taken in
performing the evaluation.
To evaluate whether an identifier is appropriate, one should consider
every recommended property from the perspective of interactions among
the components in the architecture.  When comparing identifiers,
choose the one which best satisfies all of the recommended
properties.  The architecture does not provide an exact measure of
how well an identifier satisfies a given property; care should be
taken in performing the evaluation.
Further, if only a single User Equipment is attatched to a given
physical interface, then the identifier will be unique.  If multiple
User Equipment is attached to the network on the same physical
interface, then this property is not appropriate.
Further, if only a single User Equipment is attached to a given
physical interface, then the identifier will be unique.  If multiple
User Equipment is attached to the network on the same physical
interface, then this property is not appropriate.
However, it may be possible to spoof the IP address, particularly for
malicious reasons where proper functioning of the network is not
necessary for the malicious actor.  Consequently, any solution using
the IP address should proactively try to prevent spoofing of the IP
address.  Similarily, if the mapping of IP address to User Equipment
is changed, the components of the architecture must remove or update
their mapping to prevent spoofing.  Demonstrations of return
routeability, such as that required for TCP connection establishment,
might be sufficient defense against spoofing, though this might not
be sufficient in networks that use broadcast media (such as some
wireless networks).
However, it may be possible to spoof the IP address, particularly for
malicious reasons where proper functioning of the network is not
necessary for the malicious actor.  Consequently, any solution using
the IP address should proactively try to prevent spoofing of the IP
address.  Similarly, if the mapping of IP address to User Equipment
is changed, the components of the architecture must remove or update
their mapping to prevent spoofing.  Demonstrations of return
routeability, such as that required for TCP connection establishment,
might be sufficient defense against spoofing, though this might not
be sufficient in networks that use broadcast media (such as some
wireless networks).
In some situtations, the User Equipment may have multiple IP
addresses, while still satisfying all of the recommended properties.
This raises some challenges to the components of the network.  For
example, if the user equipment tries to access the network with
multiple IP addresses, should the enforcement device and API server
treat each IP address as a unique User Equipment, or should it tie
the multiple addresses together into one view of the subscriber?  An
implementation MAY do either.  Attention should be paid to IPv6 and
the fact that it is expected for a device to have multiple IPv6
addresses on a single link.  In such cases, idenfication could be
performed by subnet, such as the /64 to which the IP belongs.
In some situations, the User Equipment may have multiple IP
addresses, while still satisfying all of the recommended properties.
This raises some challenges to the components of the network.  For
example, if the user equipment tries to access the network with
multiple IP addresses, should the enforcement device and API server
treat each IP address as a unique User Equipment, or should it tie
the multiple addresses together into one view of the subscriber?  An
implementation MAY do either.  Attention should be paid to IPv6 and
the fact that it is expected for a device to have multiple IPv6
addresses on a single link.  In such cases, identification could be
performed by subnet, such as the /64 to which the IP belongs.
Pre-condition: the Captive Portal Enforcement has been configured
to detect an expiry condition, which has now occurred.
Precondition: the Captive Portal Enforcement has been configured
to detect an expiry condition, which has now occurred.
The Captive Portal Enforcement sends an ICMP message to the User
Equipment indicating that it needs to refresh its access.  I-
D.wkumari-capport-icmp-unreach.
The User Equipment verifies the ICMP message is plausible.
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 authors thank Lorenzo Colitti for providing the majority of the
content for the Captive Portal Signal requirements.
The authors thank various individuals for their feedback on the
mailing list and during the IETF98 hackathon: David Bird, Erik Kline,
Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van
Dam.
The ICMP packet does not carry the URL, making this method safer
than HTTP 3xx-redirect methods currently in use.  The User
Equipment does not have to use clear-text HTTP to solicit the URL
of the portal.
Because the ICMP messages will carry embedded packets sent by the
sender, the receiver of the ICMP message can validate that the
transport header is plausibly one it sent (i.e., the transport-
layer 5-tuple matches an open connection; there is no need to save
every packet it sent).  This validation requires an off-path
attacker to guess the 5-tuple in order to affect a flow.  It is
trivial for an on-path attacker to send a plausible ICMP packet.
(This is not a new ICMP attack.)  The impact of getting a valid
ICMP packet to the User Equipment is that it will visit the
CAPPORT API to check the status.  For this reason we recommend the
User Equipment rate-limit these requests to the API.
We considered that the ICMP packet could carry a short secret
token that would be known to the User Equipment and Captive Portal
Enforcement device but would not be available to an attacker, even
to an on-path attacker.  Although possible to guess by brute
force, the impact would be at worst a nuisance visit to the API.
We suggest that a 32-bit token would be sufficient to deter
nuisance attacks.
Even when redirected, the User Equipment securely authenticates
with API servers.
The signal only informs the User Equipment to query the API.  It
does not carry any information which may mislead or misdirect the
User Equipment.
Even when responding to the signal, the User Equipment securely
authenticates with API servers.
Accesses to the API server are rate limited, limiting the impact
of a repeated attack.