Mobile Subscription Info in DHCP and Router Advertisement
draft-muthusamy-dhc-mobile-sub-info-01

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/info/rfc2131>.

   [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,
              <https://www.rfc-editor.org/info/rfc2616>.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <https://www.rfc-editor.org/info/rfc2818>.

   [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, <https://www.rfc-editor.org/info/rfc4187>.

   [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,
              <https://www.rfc-editor.org/info/rfc4861>.

   [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,
              <https://www.rfc-editor.org/info/rfc8415>.

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, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8910]  Kumari, W. and E. Kline, "Captive-Portal Identification in
              DHCP and Router Advertisements (RAs)", RFC 8910,
              DOI 10.17487/RFC8910, September 2020,
              <https://www.rfc-editor.org/info/rfc8910>.

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