One document matched: draft-wu-hokey-ldn-discovery-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 03:08:38 |