Network Working Group Q.Wu Internet Draft Huawei Intended status: Standard Track July 6, 2009 Expires: January 2010 Local domain name discovery draft-wu-hokey-ldn-discovery-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 6, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract As described in [RFC5296], the local domain name can be learnt by the peer though the ERP exchange or via lower-layer announcement. However lower-layer announcement for local domain name is not specified. This Wu Expires January 6, 2010 [Page 1] Internet-Draft Local domain name discovery July 2009 document specifies one local domain name discovery mechanism based on DHCP extension. Table of Contents 1. Introduction.................................................2 2. Conventions used in this document............................2 3. Protocol description.........................................2 3.1. Local Domain Name allocation in the DHCP server.........3 3.2. Local domain name allocation in the AAA Server..........5 4. Message format and Option....................................7 5. Security Considerations......................................7 6. IANA Considerations..........................................7 7. References...................................................8 7.1. Normative References....................................8 7.2. Informative References..................................8 8. Acknowledgments..............................................8 1. Introduction [RFC 5296] defines the EAP Re-authentication Protocol to allow faster re-authentication of a previously authenticated peer. In this protocol, the DRSK is derived from the local domain name and used to re-authenticate the peer in the local domain when the peer is attached. As described in [RFC5296], the local domain name can be learnt by the peer though the ERP exchange or via lower-layer announcement. However lower-layer announcement for local domain name is not specified. This document specifies one local domain name discovery mechanism based on DHCP extension. 2. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3. Protocol description The peer is able to acquire the local domain name information via a DHCP mechanism. The message flows for local domain name allocation in the DHCP Server and the AAA server are illustrated below. Wu Expires January 6, 2010 [Page 2] Internet-Draft Local domain name discovery July 2009 3.1. Local Domain Name allocation in the DHCP server This section describes a scenario where the local domain name is allocated in the DHCP server. In order to provide the peer with information about the assigned local domain name, the DHCP Server conveys the assigned local domain name information to the peer via DHCP protocol. Wu Expires January 6, 2010 [Page 3] Internet-Draft Local domain name discovery July 2009 +----+ +------+ +-------+ +------+ | | | | | | | | | MN/| |NAS/ | | DHCP | | AAA | |Peer| |DHCP | | Server| |Server| | | |relay | | | | | +----+ +------+ +-------+ +------+ | | | | | 1 | 1 | | |<------------->|<---------------------->| | | | | | | | | | 2 | | | |-------------->| | | | | | | | | 3 | | | |------------>| | | | | | | | 4 | | | |<------------| | | | | | | 5 | | | |<--------------| | | | | | | Figure 1 the message sequence for local domain name allocation in the DHCP server. Figure 1 shows the message sequence for local domain name allocation in the DHCP server. (1) The peer executes the network access authentication procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the NAS. The NAS is in the visited network and it interacts with the AAA server, which is in the same visited network as NAS does or in the home network, to authenticate the peer. In the process of authorizing the peer, the AAA server verifies in the AAA profile that the peer is allowed to attach to the network. (2) The peer sends a DHCPv6 Information Request message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. In this message the Peer (DHCP client) SHALL include the Option Code for local domain name Option in the Option Request option. The peer SHALL also include the OPTION_CLIENTID to identify itself to the DHCP server. (3) The Relay Agent intercepts the Information Request from the peer and forwards it to the DHCP server. Wu Expires January 6, 2010 [Page 4] Internet-Draft Local domain name discovery July 2009 (4) The DHCP server identifies the client by looking at the DUID for the client in the OPTION_CLIENTID and checks whether the peer is requesting local domain name information by looking at the option request Option (id-type 1)from the peer. If the option code for local domain name option is included in the option request option, the DHCP server assigns the local domain name to the peer and includes it in the local domain name Option in the Reply Message. (5) The Relay Agent relays the Reply Message from the DHCP server to the peer. At this point, the peer has the local domain name information that it requested. 3.2. Local domain name allocation in the AAA Server This section describes a scenario where the local domain name is allocated in the AAA server. In order to provide the peer with information about the assigned local domain, the AAA server conveys the assigned local domain name information to the NAS via AAA protocol. Wu Expires January 6, 2010 [Page 5] Internet-Draft Local domain name discovery July 2009 +----+ +------+ +-------+ +-----+ | | | | | | | | | MN/| |NAS/ | | DHCP | |AAA | |Peer| |DHCP | | Server| | | | | |relay | | | | | +----+ +------+ +-------+ +-----+ | | | | | 1 | 1 | | |<------------->|<---------------------->| | +-----+-------+ | | | |Extract Local| | | | |Domain Name | | | | +-----+-------+ | | | 2 | | | |-------------->| 3 | | | |------------>| | | | | | | | 4 | | | |<------------| | | | | | | 5 | | | |<--------------| | | | | | | Figure 2 The message sequence for local domain name allocation in the AAA server. Figure 2 shows the message sequence for local domain name allocation in the AAA server. (1) The peer executes the network access authentication procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the NAS. The NAS is in the visited network and it interacts with the AAA server, which is in the same visited network as NAS or in the home network, to authenticate the peer. In the process of authorizing the peer the AAA server verifies in the AAA profile that the peer is allowed to attach to the network. And then the AAA server assigns the local domain name and returns this information to the NAS. The NAS extracts the local domain name from AAA message and saves it for future use. (2) The peer sends a DHCPv6 Information Request message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. In this message the Peer (DHCP client) SHALL include the Option Code for local domain name Option in the Option Request option. The peer SHALL also include the OPTION_CLIENTID to identify itself to the DHCP server. Wu Expires January 6, 2010 [Page 6] Internet-Draft Local domain name discovery July 2009 (3) The Relay Agent intercepts the Information Request from the peer and forwards it to the DHCP server. The Relay Agent also includes the received local domain name information from the AAA server. (4) The DHCP server identifies the client by looking at the DUID for the client in the OPTION_CLIENTID and checks whether the peer is requesting local domain name information by looking at the Option Request Option (id-type 1). If the option code for local domain name option is included in the option request option and the DHCP server received local domain name from the Relay agent, then the DHCP server extracts the allocated local domain name information received from NAS and includes it in the local domain name Option in the Reply Message. (5) The Relay Agent relays the Reply Message from the DHCP server to the peer. At this point, the peer has the local domain name information that it requested. 4. Message format and Option The details are defined in the section 3 of [draft-wang-dhc-ldn- option-00]. 5. Security Considerations The transport of the assigned local domain name via the AAA infrastructure (i.e., from the AAA server to the AAA client) to the NAS is subject to the standard RADIUS and Diameter security considerations. The security mechanisms provided by [RFC2865] and [RFC3588] are applicable and provide adequate security for this purpose. The communication between the DHCP client and the DHCP server for the exchange of local domain name information is security sensitive and requires authentication, integrity and replay protection. Either lower-layer security (such as link layer security established as part of the network access authentication protocol run) or DHCP security [RFC3118] can be used. 6. IANA Considerations This document makes no requests for IANA action. Wu Expires January 6, 2010 [Page 7] Internet-Draft Local domain name discovery July 2009 7. References 7.1. Normative References [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC2865] Rigney,C.,Willens S." Remote Authentication Dial In User Service (RADIUS)",RFC2865,June 2000 [RFC3118] Droms, R. "Authentication for DHCP Messages", RFC3118,June 2001 7.2. Informative References [draft-wang-dhc-ldn-option-00] Yungui,W. and Qin,W." DHCP Option for Local Domain Name Discovery",draft-wang-dhc-ldn-option, (work in progress). 8. Acknowledgments The authors would like to thank all colleagues for his review and comments of this draft. Wu Expires January 6, 2010 [Page 8] Internet-Draft Local domain name discovery July 2009 Authors' Addresses Qin Wu Huawei Technologies Co.,Ltd Site B,Floor 12F,Huihong Mansion,No.91,Baixia Rd Nanjing,210001 P.R.China Email: sunseawq@huawei.com Wu Expires January 6, 2010 [Page 9]