One document matched: draft-ding-savi-pana-with-slacc-00.txt
Source Address Validation Y. Ding
Improvements WG R. Zheng
Internet-Draft Y. Li
Intended status: Standards Track Huawei Technologies
Expires: January 6, 2011 July 5, 2010
SAVI analysis for PANA with SLACC
draft-ding-savi-pana-with-slacc-00
Abstract
This document analysis the source address vilidation in PANA with
slacc,and specifies the procdure for binding assigned address to the
UE through PANA related mechanism.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://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 January 6, 2011.
Copyright Notice
Copyright (c) 2010 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
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Ding, et al. Expires January 6, 2011 [Page 1]
Internet-Draft SAVI for PANA July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative Reference . . . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Ding, et al. Expires January 6, 2011 [Page 2]
Internet-Draft SAVI for PANA July 2010
1. Introduction
In IP access netwok, IP edge device is communated with lots of
subscribers, which include home gateways and hosts. In order to keep
accurate information of these device, IP edge has to execute source
address validation to make the information related to the subscribers
processed correctly. In IPv6 access network, subscriber may use LLA
(Link Local Address) or ULA (Unique Local Address) to initiate the
subscriber authentication. The general approach to obtain a GUA
(Global Unique Address) address for a subscriber is to make the home
gateway get a delegated prefix and then home gateway advertises the
prefix to UEs in home network. Subscriber generates GUA via
stateless address configuration. Figure 1 shows a residential IPv6
broadband access network which uses DHCP PD[RFC3633] to get the
delegated prefix and SLACC to obtain the GUA address.
HGW gets a delegated prefix, say /56, for its home network use. When
UE1 tries to connect to the network, it first gets its own LLA/ULA
address and then uses that address as source IP address for the
following PANA authentication for subscriber verification. When the
authentication succeeds, it sends RS (router solicitation) to HGW and
HGW replies with RA (router advertisement) with a /64 prefix option
for SLACC configuration. UE1 uses the prefix to generate its GUA
address. And it uses GUA for the following data transportation.
When another UE2 tries to connect to the network, it repeats the step
2 to 7. However it should be noticed, /64 prefix that HGW sent to
UE2 visa RA may not be the same one as that sent to UE1. As IP edge
only knows /56 it delegated to HGW, there is no native way for IP
edge to know which address/prefix UE1 and UE2 used within the range
of the delegated /56 prefix. As IP session terminates on IP edge, IP
edge should have the detailed information stored for each session,
e.g. prefix, address, layer 2 information, etc. If IP edge wants to
treat the connections which terminate on UE1 and UE2 as different
sessions, it needs to know the specific information of each to set up
correct binding relationship. This contribution tries to analysis
the issue and provide some possible ways to let the subscriber's
address information get validated and let the IP edge know the SLACC
configuration in home network via PANA,.
Ding, et al. Expires January 6, 2011 [Page 3]
Internet-Draft SAVI for PANA July 2010
+------+
| UE1 |---------+
+------+ |
+-------+ +---+ +---------+
| HGW |-------|AN |------| IP Edge |
+-------+ +---+ +---------+
+------+ |
| UE2 |---------+
+------+
| | 1. DHCP PD |
| <--------------------------->
2.LLA/ULA | |
conf | |
| 3.PANA Authentication exchange |
<--------------><--------------------------->
| | |
4.Auth | |
Success | |
| | |
| 5. RS | |
|-------------->| |
| 6.RA w/ | |
| /64 prefix | |
|<--------------| |
| | |
7.Generate | |
GUA | |
| | |
Figure 1: IPv6 Broadband Access Network
2. Message Flow
The problem stated in Introduction section indeed is a special case
of IP address/prefix reconfiguration. Section 3 of [RFC5193] briefly
described the possible use cases of IP reconfiguration without giving
the detailed PANA flow. To implement IPv6 session information
binding in broadband access scenario, Figure 2 shows the message flow
to support subscriber authentication and SLACC configuration in home
network. IP edge device retrieves the relevant information from the
process and performs the necessary session bindings.
Ding, et al. Expires January 6, 2011 [Page 4]
Internet-Draft SAVI for PANA July 2010
+------+
| UE1 |-------------------+
+------+ |
+-------+ +---+ +---------+
| HGW |-------|AN |------| IP Edge |
+-------+ +---+ +---------+
+------+ |
| UE2 |-------------------+
+------+
| |1.DHCP PD(2002:db8:200:100::/56)|
| <-------------------------------->
2.LLA/ULA | |
conf | |
| 3.PCI (src=LLA/ULA) |
|-----------------------|-------------------------------->
| 4. PANA exchange |
<-----------------------|-------------------------------->
| | |
| 5.PAR/EAP success w/ 'I' & 'C' bit set |
<--------------------------------------------------------|
| | |
| 6. RS | |
|---------------------->| |
| 7.RA w/ | |
|<----------------------| |
| 2002:db8:200:122::/64 | |
| | |
8.Generate | |
GUA | |
2002:db8:200:122::fe99:3234 | |
| | |
| 9.PAN(src=GUA) w/ 'C' bit set |
|-----------------------+-------------------------------->
| | |
| | 10.Bind GUA,
| | prefix with
| | session
| | |
Figure 2: Message flow of IP/prefix reconfiguration in home network -
1
In step 5, PAR(PANA-Auth-request) with EAP sucess payload is sent to
UE. 'I' bit was set to indicate that UE is required to get a GUA and
use that GUA for the following message exchange. When receiving the
PAR with EAP success, UE starts the SLACC procedures to get the GUA
address for data communication. It send the RS(router solicitation)
to HGW in step 6. Then in step 7, HGW sends responded RA with
Ding, et al. Expires January 6, 2011 [Page 5]
Internet-Draft SAVI for PANA July 2010
advertised prefix to UE. The advertised prefix is within the rage of
the delegated /56 prefix in step 1 but is with 64-bit length. UE
uses the received /64 prefix to generate a GUA in step 8,which is to
be used in the data communication. In step 9 UE sends PAN(PANA-Auth-
Answer) with 'C' bit set to IP edge. GUA address generated in step 8
should be used as the source IP address. When IP edge receives PAN,
it retrieves the GUA and prefix information and binds them with the
session initiated by UE. PANA session ID can be used for the
matching of the LLA/ULA and GUA to set up the binding relationship.
With the approach shown in Figure 2, IP edge is able to get the
specific address/prefix information of connected UE with embedded
mechenism of PANA. It is a light-weighted solution for IPv6 session
information retrieval and binding in broadband access network.
There is also another approach to solve this problem in the following
figure, the address UE use in data communication may be allocated
after authentification process finished, Figure 3 shows the message
flow.
Ding, et al. Expires January 6, 2011 [Page 6]
Internet-Draft SAVI for PANA July 2010
+------+
| UE1 |-------------------+
+------+ |
+-------+ +---+ +---------+
| HGW |-------|AN |------| IP Edge |
+-------+ +---+ +---------+
+------+ |
| UE2 |-------------------+
+------+
| |1.DHCP PD(2002:db8:200:100::/56)|
| <-------------------------------->
2.LLA/ULA | |
conf | |
| 3. PANA exchange |
<-----------------------|-------------------------------->
| | |
| 4.GUA/prefix alloc | |
|(2002:db8:200:100::/64)| |
<-----------------------> |
| | |
| 5.PNR(src=GUA ) w/ 'P'bit set |
|-------------------------------------------------------->
| | |
| | 6.Bind GUA,
| | prefix with
| | session
| | |
Figure 3: Message flow of IP/prefix reconfiguration in home network -
2
UE use the LLA/ULA as source address to complete the authentification
exchange with IP dege in step 3. After this procedure, in step 4,
HGW allocate the GUA address to UE,or the prefix within the range of
the delegated /56 prefix in step 1 but is with 64-bit length. When
received the prefix with 64-bit length, UE use it to generate a GUA.
In step 5 UE sends PNR(PANA-Notification-Request) with 'P' bit set to
IP edge, 'P' bit was set to indicate doing the Ping operation between
PANA peers. GUA address generated in step 4 should be used as the
source IP address. When IP edge receives PNR, it retrieves the GUA
and prefix information and binds them with the session initiated by
UE. PANA session ID can be used for the matching of the LLA/ULA and
GUA to set up the binding relationship.
With this approach shown in Figure 3, IP edge is able to get the
specific address/prefix information of connected UE with mechenism of
PANA. It is another solution for IPv6 session information retrieval
and binding in broadband access network.
Ding, et al. Expires January 6, 2011 [Page 7]
Internet-Draft SAVI for PANA July 2010
3. Security Considerations
There is no extra security vulnarability introduced by this
contribution. AUTH AVP is used to integrity protect PANA messages
when last PAN is sent and source IP address has been switched from
LLA/ULA to GUA address.
4. IANA Considerations
There is no new IANA code required to be allocated.
5. References
5.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informative References
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and
A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA) Framework", RFC 5193, May 2008.
[TR-059] DSL Forum, "DSL Evolution - Architecture Requirements for
the Support of QoS-Enabled IP Services", TR 059,
September 2003.
[TR-101] DSL Forum, "Migration to Ethernet Based DSL Aggregation",
TR 101, April 2006.
Ding, et al. Expires January 6, 2011 [Page 8]
Internet-Draft SAVI for PANA July 2010
Authors' Addresses
Yilan Ding
Huawei Technologies
Huawei Nanjing R&D Center, 101 Software Avenue
Nanjing 210012
China
Phone: +86-25-56622346
Email: denver@huawei.com
Ruobin Zheng
Huawei Technologies
Huawei Industrial Base
Shenzhen 518129
China
Phone: +86-755-28973567
Email: robin@huawei.com
Yizhou Li
Huawei Technologies
Huawei Nanjing R&D Center, 101 Software Avenue
Nanjing 210012
China
Phone: +86-25-56622310
Email: liyizhou@huawei.com
Ding, et al. Expires January 6, 2011 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 10:52:45 |