rfc8952v2.txt   rfc8952.txt 
skipping to change at line 243 skipping to change at line 243
Captive Portal Signal Captive Portal Signal
A notification from the network used to signal to the User A notification from the network used to signal to the User
Equipment that the state of its captivity could have changed. Equipment that the state of its captivity could have changed.
Captive Portal Signaling Protocol Captive Portal Signaling Protocol
The protocol for communicating Captive Portal Signals. Also known The protocol for communicating Captive Portal Signals. Also known
as "Signaling Protocol". as "Signaling Protocol".
Captive Portal Session Captive Portal Session
Also referred to simply as the "Session", a Captive Portal Session Also referred to simply as the "Session", a Captive Portal Session
is the association for a particular User Equipment that starts is the association for a particular User Equipment instance that
when it interacts with the Captive Portal and gains open access to starts when it interacts with the Captive Portal and gains open
the network and ends when the User Equipment moves back into the access to the network and ends when the User Equipment moves back
original captive state. The Captive Network maintains the state into the original captive state. The Captive Network maintains
of each active Session and can limit Sessions based on a length of the state of each active Session and can limit Sessions based on a
time or a number of bytes used. The Session is associated with a length of time or a number of bytes used. The Session is
particular instance of User Equipment using the User Equipment's associated with a particular User Equipment instance using the
identifier (see Section 3). User Equipment's identifier (see Section 3).
2. Components 2. Components
2.1. User Equipment 2.1. User Equipment
The User Equipment is the device that a user desires to be attached The User Equipment is the device that a user desires to be attached
to a network with full access to all hosts on the network (e.g., to to a network with full access to all hosts on the network (e.g., to
have Internet access). The User Equipment communication is typically have Internet access). The User Equipment communication is typically
restricted by the Enforcement Device, described in Section 2.4, until restricted by the Enforcement Device, described in Section 2.4, until
site-specific requirements have been met. site-specific requirements have been met.
skipping to change at line 524 skipping to change at line 524
identity of the User Equipment when interacting with each other. identity of the User Equipment when interacting with each other.
The methods by which the components interact restrict the type of The methods by which the components interact restrict the type of
information that may be used as an identifying characteristic. This information that may be used as an identifying characteristic. This
section discusses the identifying characteristics. section discusses the identifying characteristics.
3.1. Identifiers 3.1. Identifiers
An identifier is a characteristic of the User Equipment used by the An identifier is a characteristic of the User Equipment used by the
components of a Captive Portal to uniquely determine which specific components of a Captive Portal to uniquely determine which specific
User Equipment is interacting with them. An identifier can be a User Equipment instance is interacting with them. An identifier can
field contained in packets sent by the User Equipment to the external be a field contained in packets sent by the User Equipment to the
network. Or, an identifier can be an ephemeral property not external network. Or, an identifier can be an ephemeral property not
contained in packets destined for the external network, but instead contained in packets destined for the external network, but instead
correlated with such information through knowledge available to the correlated with such information through knowledge available to the
different components. different components.
3.2. Recommended Properties 3.2. Recommended Properties
The set of possible identifiers is quite large. However, in order to The set of possible identifiers is quite large. However, in order to
be considered a good identifier, an identifier SHOULD meet the be considered a good identifier, an identifier SHOULD meet the
following criteria. Note that the optimal identifier will likely following criteria. Note that the optimal identifier will likely
change depending on the position of the components in the network as change depending on the position of the components in the network as
skipping to change at line 563 skipping to change at line 563
The Captive Portal MUST associate the User Equipment with an The Captive Portal MUST associate the User Equipment with an
identifier that is unique among all of the User Equipment interacting identifier that is unique among all of the User Equipment interacting
with the Captive Portal at that time. with the Captive Portal at that time.
Over time, the User Equipment assigned to an identifier value MAY Over time, the User Equipment assigned to an identifier value MAY
change. Allowing the identified device to change over time ensures change. Allowing the identified device to change over time ensures
that the space of possible identifying values need not be overly that the space of possible identifying values need not be overly
large. large.
Independent Captive Portals MAY use the same identifying value to Independent Captive Portals MAY use the same identifying value to
identify different instances of User Equipment. Allowing independent identify different User Equipment instances. Allowing independent
captive portals to reuse identifying values allows the identifier to captive portals to reuse identifying values allows the identifier to
be a property of the local network, expanding the space of possible be a property of the local network, expanding the space of possible
identifiers. identifiers.
3.2.2. Hard to Spoof 3.2.2. Hard to Spoof
A good identifier does not lend itself to being easily spoofed. At A good identifier does not lend itself to being easily spoofed. At
no time should it be simple or straightforward for one User Equipment no time should it be simple or straightforward for one User Equipment
to pretend to be another User Equipment, regardless of whether both instance to pretend to be another User Equipment instance, regardless
are active at the same time. This property is particularly important of whether both are active at the same time. This property is
when the User Equipment identifier is referenced externally by particularly important when the User Equipment identifier is
devices such as billing systems or when the identity of the User referenced externally by devices such as billing systems or when the
Equipment could imply liability. identity of the User Equipment could imply liability.
3.2.3. Visible to the API Server 3.2.3. Visible to the API Server
Since the API Server will need to perform operations that rely on the Since the API Server will need to perform operations that rely on the
identity of the User Equipment, such as answering a query about identity of the User Equipment, such as answering a query about
whether the User Equipment is captive, the API Server needs to be whether the User Equipment is captive, the API Server needs to be
able to relate a request to the User Equipment making the request. able to relate a request to the User Equipment making the request.
3.2.4. Visible to the Enforcement Device 3.2.4. Visible to the Enforcement Device
The Enforcement Device will decide on a per-packet basis whether the The Enforcement Device will decide on a per-packet basis whether the
packet should be forwarded to the external network. Since this packet should be forwarded to the external network. Since this
decision depends on which instance of User Equipment sent the packet, decision depends on which User Equipment instance sent the packet,
the Enforcement Device requires that it be able to map the packet to the Enforcement Device requires that it be able to map the packet to
its concept of the User Equipment. its concept of the User Equipment.
3.3. Evaluating Types of Identifiers 3.3. Evaluating Types of Identifiers
To evaluate whether a type of identifier is appropriate, one should To evaluate whether a type of identifier is appropriate, one should
consider every recommended property from the perspective of consider every recommended property from the perspective of
interactions among the components in the architecture. When interactions among the components in the architecture. When
comparing identifier types, choose the one that best satisfies all of comparing identifier types, choose the one that best satisfies all of
the recommended properties. The architecture does not provide an the recommended properties. The architecture does not provide an
skipping to change at line 617 skipping to change at line 617
identifier types is not exhaustive; other types may be used. An identifier types is not exhaustive; other types may be used. An
important point to note is that whether a given identifier type is important point to note is that whether a given identifier type is
suitable depends heavily on the capabilities of the components and suitable depends heavily on the capabilities of the components and
where in the network the components exist. where in the network the components exist.
3.4.1. Physical Interface 3.4.1. Physical Interface
The physical interface by which the User Equipment is attached to the The physical interface by which the User Equipment is attached to the
network can be used to identify the User Equipment. This identifier network can be used to identify the User Equipment. This identifier
type has the property of being extremely difficult to spoof: the User type has the property of being extremely difficult to spoof: the User
Equipment is unaware of the property; one User Equipment cannot Equipment is unaware of the property; one User Equipment instance
manipulate its interactions to appear as though it is another. cannot manipulate its interactions to appear as though it is another.
Further, if only a single instance of User Equipment is attached to a Further, if only a single User Equipment instance is attached to a
given physical interface, then the identifier will be unique. If given physical interface, then the identifier will be unique. If
multiple instances of User Equipment is attached to the network on multiple User Equipment instances are attached to the network on the
the same physical interface, then this type is not appropriate. same physical interface, then this type is not appropriate.
Another consideration related to uniqueness of the User Equipment is Another consideration related to uniqueness of the User Equipment is
that if the attached User Equipment changes, both the API Server and that if the attached User Equipment changes, both the API Server and
the Enforcement Device MUST invalidate their state related to the the Enforcement Device MUST invalidate their state related to the
User Equipment. User Equipment.
The Enforcement Device needs to be aware of the physical interface, The Enforcement Device needs to be aware of the physical interface,
which constrains the environment; it must either be part of the which constrains the environment; it must either be part of the
device providing physical access (e.g., implemented in firmware), or device providing physical access (e.g., implemented in firmware), or
packets traversing the network must be extended to include packets traversing the network must be extended to include
skipping to change at line 673 skipping to change at line 673
deployed between the User Equipment and the Enforcement Device. In deployed between the User Equipment and the Enforcement Device. In
such cases, it is possible for the components to still uniquely such cases, it is possible for the components to still uniquely
identify the device if they are aware of the port mapping. identify the device if they are aware of the port mapping.
In some situations, the User Equipment may have multiple IP addresses In some situations, the User Equipment may have multiple IP addresses
(either IPv4, IPv6, or a dual-stack [RFC4213] combination) while (either IPv4, IPv6, or a dual-stack [RFC4213] combination) while
still satisfying all of the recommended properties. This raises some still satisfying all of the recommended properties. This raises some
challenges to the components of the network. For example, if the challenges to the components of the network. For example, if the
User Equipment tries to access the network with multiple IP User Equipment tries to access the network with multiple IP
addresses, should the Enforcement Device and API Server treat each IP addresses, should the Enforcement Device and API Server treat each IP
address as a unique User Equipment, or should it tie the multiple address as a unique User Equipment instance, or should it tie the
addresses together into one view of the subscriber? An multiple addresses together into one view of the subscriber? An
implementation MAY do either. Attention should be paid to IPv6 and implementation MAY do either. Attention should be paid to IPv6 and
the fact that it is expected for a device to have multiple IPv6 the fact that it is expected for a device to have multiple IPv6
addresses on a single link. In such cases, identification could be addresses on a single link. In such cases, identification could be
performed by subnet, such as the /64 to which the IP belongs. performed by subnet, such as the /64 to which the IP belongs.
3.4.3. Media Access Control (MAC) Address 3.4.3. Media Access Control (MAC) Address
The MAC address of a device is often used as an identifier in The MAC address of a device is often used as an identifier in
existing implementations. This document does not discuss the use of existing implementations. This document does not discuss the use of
MAC addresses within a captive portal system, but they can be used as MAC addresses within a captive portal system, but they can be used as
skipping to change at line 854 skipping to change at line 854
6.3. Secure APIs 6.3. Secure APIs
The solution described here requires that the API be secured using The solution described here requires that the API be secured using
TLS. This is required to allow the User Equipment and API Server to TLS. This is required to allow the User Equipment and API Server to
exchange secrets that can be used to validate future interactions. exchange secrets that can be used to validate future interactions.
The API MUST ensure the integrity of this information, as well as its The API MUST ensure the integrity of this information, as well as its
confidentiality. confidentiality.
An attacker with access to this information might be able to An attacker with access to this information might be able to
masquerade as a specific User Equipment when interacting with the masquerade as a specific User Equipment instance when interacting
API, which could then allow them to masquerade as that User Equipment with the API, which could then allow them to masquerade as that User
when interacting with the User Portal. This could give them the Equipment instance when interacting with the User Portal. This could
ability to determine whether the User Equipment has accessed the give them the ability to determine whether the User Equipment has
portal, deny the User Equipment service by ending their Session using accessed the portal, deny the User Equipment service by ending their
mechanisms provided by the User Portal, or consume that User Session using mechanisms provided by the User Portal, or consume that
Equipment's quota. An attacker with the ability to modify the User Equipment's quota. An attacker with the ability to modify the
information could deny service to the User Equipment or cause them to information could deny service to the User Equipment or cause them to
appear as a different User Equipment. appear as different User Equipment instances.
6.4. Risks Associated with the Signaling Protocol 6.4. Risks Associated with the Signaling Protocol
If a Signaling Protocol is implemented, it may be possible for any If a Signaling Protocol is implemented, it may be possible for any
user on the Internet to send signals in an attempt to cause the user on the Internet to send signals in an attempt to cause the
receiving equipment to communicate with the Captive Portal API. This receiving equipment to communicate with the Captive Portal API. This
has been considered, and implementations may address it in the has been considered, and implementations may address it in the
following ways: following ways:
* The signal only signals to the User Equipment to query the API. * The signal only signals to the User Equipment to query the API.
 End of changes. 11 change blocks. 
33 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/