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]