Dynamic Host Configuration S. Muthusamy Internet-Draft Y. Lee Intended status: Standards Track R. Kothari Expires: 9 May 2024 Comcast 6 November 2023 Mobile Subscription Info in DHCP and Router Advertisement draft-muthusamy-dhc-mobile-sub-info-01 Abstract In some environments where a mobile client joins a network via simple DHCP process and/or IPv6 Router Advertisement, the serving network may want to know the mobile client's mobile subscription information. This is particularly useful when a mobile client switches to a private Wi-Fi network such as home network which uses simple SSID/ Pre-Shared-Key combination. The network can use the mobile subscription information to identify the client's serving mobile network and provide service continuity. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 May 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Requirements Language 2. The Mobile-Subscription Information Option 2.1. Client Behavior 2.2. Server Behavior 2.3. The Mobile-Sub-Info IPv4 DHCP Option 2.4. The Mobile-Sub-Info IPv6 DHCP Option 2.5. The Mobile-Sub-Info IPv6 RA Option 2.6. Precedence of API URIs 2.7. IANA Considerations 2.8. Security Considerations 3. Normative References 4. Informative References Authors' Addresses 1. Introduction When a mobile client roams in the range of a known Wi-Fi network, it is common for the mobile client to switch from the mobile network to the Wi-Fi network. The Wi-Fi network may be setup to use simple SSID/Pre-Shared-Key combination (e.g., home private network) and does not require EAP-AKA authentication [RFC4187] for the client to join the network. As such the network will not be able to identify the client's mobile subscription. In an environment where the mobile network and the Wi-Fi network are of the same service provider, the service provider may want to retrieve the mobile subscription information from the client and offer service continuity (e.g., Parental Control) while the client is on the private Wi-Fi network. In this draft, we define a DHCPv4 [RFC2131] and DHCPv6 [RFC8415] option (Mobile-Sub-Info) and an IPv6 Router Advertisement (RA) [RFC4861] that inform mobile clients to exchange Mobile Subscription Information with the network. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. The Mobile-Subscription Information Option The Mobile Subscription Information DHCP/RA Option (Mobile-Sub-Info) signals the client that the network wants to obtain the Mobile subscription Information from the client. The option contains a URL the client may use it to securely exchange mobile subscription information with the network. The mechanism is similar to Captive- Portal Identification in DHCP and Router Advertisements (RAs) defined in [RFC8910]. The Mobile-Sub-Info Option contains a URL that provides a web address to the client to initiate a secure connection to trigger the EAP-AKA process [RFC4187] with the network. The process is outside of the DHCP and RA protocol process that gives flexibility to the client and network to use standard web technology to securely exchange messages. As such, it relaxes the 255-byte length restriction imposed by DHCPv4 option. Upon successful information exchange, the network MAY continue to provide similar mobile network services (e.g., Parental Control) after the client switching from the mobile network to the Wi-Fi network using SSID/PSK combination. 2.1. Client Behavior Clients that support Mobile-Sub-Info DHCP option SHOULD include the option in the Parameter Request List in DHCPREQUEST message. DHCP server MAY send the Mobile-Sub-Info option without explicit request. Client receives the URL in the option MAY initiate a request to the network to exchange Mobile Subscription Information. Client MAY safely ignore the option either it doesn't support it or its local policy chooses not to respond to the request. 2.2. Server Behavior To support different types of clients (e.g., IPv4-only, IPv6-only with DHCPv6 and IPv6-only with RA), the network must provide different methods to inform the client of supporting the Mobile-Sub- Info option. The network SHOULD provision identical Mobile- Subscription-URI in each method to avoid ambiguity. As of the maximum length of the URI that can be carried in DHCPv4 is 255 bytes, URIs SHOULD not be longer than 255 bytes. If the network supports only DHCPv6, the restriction can be relaxed. The URL MUST not contain any explicit IP address information. 2.3. The Mobile-Sub-Info IPv4 DHCP Option The format of the Mobile-Sub-Info DHCP option is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Len | URI (variable length) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . ...URI continued... . | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Mobile-Sub-Info DHCPv4 Option Format Code: The Mobile Subscription Inormation DHCPv4 Option (TBD) (one octet). Len: The length (one octet), in octets, of the URI. URI: The URI for the mobile subscription API endpoint to which the user should connect. 2.4. The Mobile-Sub-Info IPv6 DHCP Option The format of the Mobile-Sub-Info DHCP option is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . URI (variable length) . | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Mobile-Sub-Info DHCPv6 Option Format option-code: The Mobile Subscription DHCPv6 Option (TBD) (two octet). option-len: The unsigned 16-bit length, in octets, of the URI. URI: The URI for the mobile subscription API endpoint to which the user should connect (encoded following the rules in ). 2.5. The Mobile-Sub-Info IPv6 RA Option The format of the Mobile-Sub-Info RA option is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | URI . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Mobile Subscription RA Option Format Type: TBD Length: 8-bit unsigned integer. The length of the option (including the Type and Length fields) in units of 8 bytes. URI: The URI for the mobile subscription API endpoint to which the user should connect. This MUST be padded with NUL (0x00) to make the total option length (including the Type and Length fields) a multiple of 8 bytes. Note that the URI parameter is not guaranteed to be null terminated. As the maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, URIs longer than this SHOULD NOT be provisioned via IPv6 RA options. 2.6. Precedence of API URIs When client receives the Mobile-Subscription option and supports this option, it SHOULD retrieve the URL from the option and initiate a GET request [RFC2616] with the URL over HTTPS [RFC2818] . When the network receives the request, it SHOULD start the EAP-AKA process over HTTPS [RFC4187] by sending EAP-Request/AKA-Identity to exchange mobile subscription information with the client. Note that this precedence is independent to the DHCP and RA protocol. Should a client choose not to use this option or the EAP-AKA process fails, it does not impact the DHCP and RA process. In this draft, we present EAP-AKA as the mobile information exchange method. However, other methods could also be considered. This is out-of-scope of this draft. 2.7. IANA Considerations Option TBA 2.8. Security Considerations The Option contains a URL that is transmitted in unencrypted plain text. An attacker on the same LAN segment may setup a rogue DHCP server or send out rogue RA to mis-guide the victim to connect to an attacker's server. The EAP-AKA transaction is protected by the EAP- AKA security framework. That being said, the client MUST initiate the request over HTTPS [RFC2818] and disgard any non HTTPS protocol (i.e., HTTP) proposed in the option. 3. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, January 2006, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . 4. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8910] Kumari, W. and E. Kline, "Captive-Portal Identification in DHCP and Router Advertisements (RAs)", RFC 8910, DOI 10.17487/RFC8910, September 2020, . Authors' Addresses Saravanan Muthusamy Comcast 1800 Arch Street Philadelphia, PA 19103 United States of America Email: Saravanan_Muthusamy@comcast.com Yiu L. Lee Comcast 1800 Arch Street Philadelphia, PA 19103 United States of America Email: yiu_lee@comcast.com Ruchi Kothari Comcast 1800 Arch Street Philadelphia, PA 19103 United States of America Email: Ruchi_Kothari@comcast.com