Discovering the Local Location Information Server (LIS)
Extracted elements (25)
DHCP is chosen for configuring the LIS address because it provides largely static configuration information that does not change during network attachment, and the LIS address (unlike physical location) does not change while attached.
The domain name input to U-NAPTR (not the output URI's domain) is used for LIS authentication. This design means DNS query results need no integrity protection, simplifying the security model at the cost of requiring matching domain names in the DHCP option and resulting URI.
DHCPv4 option 15 (RFC 2132) is used as a fallback domain name source when the access network domain name DHCP option is unavailable, but it may not be suitable for deployments where a global enterprise uses the same option 15 value across multiple sites.
Residential gateways may interfere with LIS discovery if they do not pass the access network domain name option to served Devices. Gateways can assist by relaying the option, performing their own LIS discovery, or acting as a LIS directly.
A Device MUST NOT attempt LIS discovery over a VPN network interface until it has attempted and failed to perform discovery on all other non-VPN interfaces.
A Device MUST support discovery using the access network domain name DHCP option as input to U-NAPTR resolution. If this option is not available, DHCPv4 option 15 is used.
A Device that discovers a LIS URI MUST attempt to verify that the LIS is able to provide location information. For HELD, this is done by making a location request; any HTTP 200 response containing a HELD response (except 'notLocatable') signifies success.
Alternative domain names MUST NOT be used unless the access network domain name option is unsuccessful or where external information indicates that a particular domain name is to be used.
An HTTPS LIS URI that is a product of U-NAPTR MUST be authenticated using the domain name method described in Section 3.1 of RFC 2818, using the domain name extracted from the URI.
If the LIS responds with the 'notLocatable' error code, the Device MUST continue or restart the discovery process and SHOULD NOT make further requests to that LIS until its network attachment changes.
Network administrators SHOULD ensure that the domain name in the DHCP option is the same as the one contained in the resulting LIS URI, to support endpoints that enforce this restriction.
The DHCPv4 and DHCPv6 access network domain name options each MUST contain precisely one root label (i.e., a single domain name).
The discovered LIS URI MUST be dereferenced using the HELD process. Devices MUST NOT embed these URIs in fields in other protocols designed to carry the location of the Device.
The high-order two bits of every length octet in the domain name encoding MUST be zero, and each label is limited to 63 octets or less; total domain name length is restricted to 255 octets or less.
The DHCPv4 Access Network Domain Name option (OPTION_V4_ACCESS_DOMAIN, code 213) carries the domain name of the access network encoded per RFC 1035 Section 3.1, used as input to U-NAPTR for LIS discovery.
The DHCPv6 Access Network Domain Name option (OPTION_V6_ACCESS_DOMAIN, code 57) carries the domain name of the access network encoded per RFC 1035 Section 3.1, similarly formatted to the DHCPv4 option.
U-NAPTR (RFC 4848) resolution takes a domain name as input and produces an HTTP or HTTPS URI identifying the LIS. It uses Application Service tag 'LIS' and Application Protocol tag 'HELD' to select relevant NAPTR records.
A new S-NAPTR/U-NAPTR Application Protocol tag 'HELD' was registered with IANA, identifying the HELD protocol (RFC 5985) for use with the 'LIS' Application Service tag.
A new S-NAPTR/U-NAPTR Application Service tag 'LIS' was registered with IANA, identifying a service that provides a Device with its location information, as mandated by RFC 3958.
IANA assigned DHCPv4 option code 213 (OPTION_V4_ACCESS_DOMAIN) for the access network domain name option and DHCPv6 option code 57 (OPTION_V6_ACCESS_DOMAIN) for the corresponding IPv6 option.
A LIS identified by an HTTP URI cannot be authenticated and does not meet HELD requirements for confidentiality and integrity, leaving Devices vulnerable to multiple attacks. Lower-layer protections such as Layer 2 traffic separation may provide some guarantees.
Authentication of a LIS relies on the integrity of the domain name acquired from DHCP. Preventing DHCP message modification or spoofing is necessary; physical/link-layer security and DHCP authentication (RFC 3118) can help.
The domain name used to authenticate the LIS is the input to U-NAPTR, not the output; therefore DNS query results do not need integrity protection. A client MAY reject URIs whose domain name differs from the U-NAPTR input to avoid authentication mismatches.
The primary attack against LIS discovery is impersonation of a LIS. Three attack stages are identified: (1) falsifying the domain name input to U-NAPTR, (2) altering DNS records used in U-NAPTR resolution, and (3) impersonating the LIS itself.
The domain name field in both DHCP options is encoded per RFC 1035: each label is a one-octet length followed by that many octets, terminated by a zero-length octet. The option's Length field gives the total encoding length.