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/ |