Multiple components in the architecture interact with both the User Equipment and each other. Since the User Equipment is the focus of these interactions, the components must be able to both identify the User Equipment from their interactions with it and agree on the identity of the User Equipment when interacting with each other.
The methods by which the components interact restrict the type of information that may be used as an identifying characteristic. This section discusses the identifying characteristics.
An identifier is a characteristic of the User Equipment used by the components of a Captive Portal to uniquely determine which specific User Equipment instance is interacting with them. An identifier can be a field contained in packets sent by the User Equipment to the external network. Or, an identifier can 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.
The set of possible identifiers is quite large. However, in order to be considered a good identifier, an identifier SHOULD
meet the following criteria. Note that the optimal identifier will likely change depending on the position of the components in the network as well as the information available to them. An identifier SHOULD
uniquely identify the User Equipment
be hard to spoof
be visible to the API Server
be visible to the Enforcement Device
An identifier might only apply to the current point of network attachment. If the device moves to a different network location, its identity could change.
The Captive Portal MUST
associate the User Equipment with an identifier that is unique among all of the User Equipment interacting with the Captive Portal at that time.
Over time, the User Equipment assigned to an identifier 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 instances. 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.
A good identifier does not lend itself to being easily spoofed. At no time should it be simple or straightforward for one User Equipment instance to pretend to be another User Equipment instance, regardless of whether both are active at the same time. This property is particularly important when the User Equipment identifier is referenced externally by devices such as billing systems or when the identity of the User Equipment could imply liability.
Since the API Server will need to perform operations that rely on the identity of the User Equipment, such as answering a query about whether the User Equipment is captive, the API Server needs to be able to relate a request to the User Equipment making the request.
The Enforcement Device will decide on a per-packet basis whether the packet should be forwarded to the external network. Since this decision depends on which User Equipment instance sent the packet, the Enforcement Device requires that it be able to map the packet to its concept of the User Equipment.
To evaluate whether a type of identifier is appropriate, one should consider every recommended property from the perspective of interactions among the components in the architecture. When comparing identifier types, choose the one that best satisfies all of the recommended properties. The architecture does not provide an exact measure of how well an identifier type satisfies a given property; care should be taken in performing the evaluation.
This section provides some example identifier types, along with some evaluation of whether they are suitable types. The list of identifier types is not exhaustive; other types may be used. An important point to note is that whether a given identifier type is suitable depends heavily on the capabilities of the components and where in the network the components exist.
The physical interface by which the User Equipment is attached to the network can be used to identify the User Equipment. This identifier type has the property of being extremely difficult to spoof: the User Equipment is unaware of the property; one User Equipment instance cannot manipulate its interactions to appear as though it is another.
Further, if only a single User Equipment instance is attached to a given physical interface, then the identifier will be unique. If multiple User Equipment instances are attached to the network on the same physical interface, then this type is not appropriate.
Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API Server and the Enforcement Device MUST
invalidate their state related to the User Equipment.
The Enforcement Device needs to be aware of the physical interface, which constrains the environment; it must either be part of the device providing physical access (e.g., implemented in firmware), or packets traversing the network must be extended to include information about the source physical interface (e.g., a tunnel).
The API Server faces a similar problem, implying that it should co-exist with the Enforcement Device or that the Enforcement Device should extend requests to it with the identifying information.
A natural identifier type to consider is the IP address of the User Equipment. At any given time, no device on the network can have the same IP address without causing the network to malfunction, so it is appropriate from the perspective of uniqueness.
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 routability, 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).
Since the IP address may traverse multiple segments of the network, more flexibility is afforded to the Enforcement Device and the API Server; they simply must exist on a segment of the network where the IP address is still unique. However, consider that a NAT may be deployed between the User Equipment and the Enforcement Device. In such cases, it is possible for the components to still uniquely identify the device if they are aware of the port mapping.
In some situations, the User Equipment may have multiple IP addresses (either IPv4, IPv6, or a dual-stack [RFC 4213
] combination) 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 instance, 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.
The MAC address of a device is often used as an identifier in existing implementations. This document does not discuss the use of MAC addresses within a captive portal system, but they can be used as an identifier type, subject to the criteria in Section 3.2
A Captive Portal API needs to present information to clients that is unique to that client. To do this, some systems use information from the context of a request, such as the source address, to identify the User Equipment.
Using information from context rather than information from the URI allows the same URI to be used for different clients. However, it also means that the resource is unable to provide relevant information if the User Equipment makes a request using a different network path. This might happen when User Equipment has multiple network interfaces. It might also happen if the address of the API provided by DNS depends on where the query originates (as in split DNS [RFC 8499
Accessing the API MAY
depend on contextual information. However, the URIs provided in the API SHOULD
be unique to the User Equipment and not dependent on contextual information to function correctly.
Though a URI might still correctly resolve when the User Equipment makes the request from a different network, it is possible that some functions could be limited to when the User Equipment makes requests using the Captive Portal. For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection.
URIs could include some means of identifying the User Equipment in the URIs. However, including unauthenticated User Equipment identifiers in the URI may expose the service to spoofing or replay attacks.