< draft-morand-pana-panaoverdsl-01.txt		draft-morand-pana-panaoverdsl-02.txt >
	PANA Working Group L. Morand		PANA Working Group L. Morand
	Internet-Draft France Telecom R&D		Internet-Draft France Telecom R&D
	Intended status: Informational A. Yegin		Intended status: Informational A. Yegin
	Expires: August 28, 2008 Samsung		Expires: November 17, 2008 Samsung
	Y. Ohba		Y. Ohba
	Toshiba America Research, Inc.		Toshiba America Research, Inc.
	J. Kaippallimalil		J. Kaippallimalil
	Huawei Technologies		Huawei Technologies
	February 25, 2008		May 16, 2008
	Application of PANA framework to DSL networks		Application of PANA framework to DSL networks
	draft-morand-pana-panaoverdsl-01		draft-morand-pana-panaoverdsl-02
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 28, 2008.		This Internet-Draft will expire on November 17, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document provides guidelines for PANA deployment over DSL access		This document provides guidelines for PANA deployment over DSL access
	networks. The document specifically describes the introduction of		networks. The document specifically describes the introduction of
	PANA in DSL networks migrating from a traditional PPP access model to		PANA in DSL networks migrating from a traditional PPP access model to
	a pure IP-based access environment.		a pure IP-based access environment.
	Table of Contents		Table of Contents
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 23 ¶
	5.2. Advisability of Introducing PANA in DSL Environment . . . 6		5.2. Advisability of Introducing PANA in DSL Environment . . . 6
	6. Applicability of PANA to IP Session based DSL Environment . . 7		6. Applicability of PANA to IP Session based DSL Environment . . 7
	6.1. Functional Architecture . . . . . . . . . . . . . . . . . 7		6.1. Functional Architecture . . . . . . . . . . . . . . . . . 7
	6.1.1. Location of PAA and EP . . . . . . . . . . . . . . . . 7		6.1.1. Location of PAA and EP . . . . . . . . . . . . . . . . 7
	6.1.2. Location of the PaC . . . . . . . . . . . . . . . . . 7		6.1.2. Location of the PaC . . . . . . . . . . . . . . . . . 7
	6.2. IP Address Configuration . . . . . . . . . . . . . . . . . 9		6.2. IP Address Configuration . . . . . . . . . . . . . . . . . 9
	6.3. Authorized Device ID . . . . . . . . . . . . . . . . . . . 10		6.3. Authorized Device ID . . . . . . . . . . . . . . . . . . . 10
	6.4. Cryptographic Protection . . . . . . . . . . . . . . . . . 10		6.4. Cryptographic Protection . . . . . . . . . . . . . . . . . 10
	6.5. Message Flows . . . . . . . . . . . . . . . . . . . . . . 10		6.5. Message Flows . . . . . . . . . . . . . . . . . . . . . . 10
	6.5.1. Generic Message Flows . . . . . . . . . . . . . . . . 10		6.5.1. Generic Message Flows . . . . . . . . . . . . . . . . 10
	6.5.2. Specific Example . . . . . . . . . . . . . . . . . . . 12		6.5.2. Specific Example I . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6.5.3. Specific Example II . . . . . . . . . . . . . . . . . 14
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 15		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . . 15		10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16		10.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Intellectual Property and Copyright Statements . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
			Intellectual Property and Copyright Statements . . . . . . . . . . 20
	1. Introduction		1. Introduction
	PANA (Protocol for carrying Authentication for Network Access) design		PANA (Protocol for carrying Authentication for Network Access) design
	provides support for various types of deployments. DSL networks were		provides support for various types of deployments. DSL networks were
	identified as a typical example of such a deployment. This document		identified as a typical example of such a deployment. This document
	provides guidelines for PANA deployment over DSL access networks.		provides guidelines for PANA deployment over DSL access networks.
	The document specifically describes the introduction of PANA in DSL		The document specifically describes the introduction of PANA in DSL
	networks migrating from a traditional PPP access model to a pure IP-		networks migrating from a traditional PPP access model to a pure IP-
	based access environment. In such environment, additional		based access environment. In such environment, additional
	skipping to change at page 9, line 41 ¶		skipping to change at page 9, line 41 ¶
	2. The PaC MAY dynamically configure the PRPA using DHCPv4 [RFC2131]		2. The PaC MAY dynamically configure the PRPA using DHCPv4 [RFC2131]
	or DHCPv6 [RFC3315].		or DHCPv6 [RFC3315].
	3. In IPv6, the PaC MAY configure non-link-local address(es) using		3. In IPv6, the PaC MAY configure non-link-local address(es) using
	IPv6 stateless auto-configuration [RFC2461] if router		IPv6 stateless auto-configuration [RFC2461] if router
	advertisements with prefixes are made available.		advertisements with prefixes are made available.
	4. PaC MAY also use an IPv4 link-local address [RFC3927] and/or an		4. PaC MAY also use an IPv4 link-local address [RFC3927] and/or an
	IPv6 link-local address [RFC2461].		IPv6 link-local address [RFC2461].
			5. PaC MAY use unspecified IPv4 address (0.0.0.0).
	After a successful authentication, the PaC MAY have to configure a		After a successful authentication, the PaC MAY have to configure a
	new IP address for communication with other nodes if the PRPA is a		new IP address for communication with other nodes if the PRPA is an
	local-use (e.g., a link-local or private address) or a temporarily		unspecified IPv4 address, a local-use IP address (e.g., a link-local
	allocated IP address. This IP address is called a post-PANA address		or private address) or a temporarily allocated IP address. This IP
	(POPA). An operator might choose allocating a POPA only after		address is called a post-PANA address (POPA). An operator might
	successful PANA authorization either to prevent waste of premium		choose allocating a POPA only after successful PANA authorization
	(e.g., globally routable) IP resources until the PaC is authorized		either to prevent waste of premium (e.g., globally routable) IP
	(especially in the IPv4 case), or to enable PaC identity based		resources until the PaC is authorized (especially in the IPv4 case),
	address assignment. POPA can be configured using DHCP [RFC2131]		or to enable PaC identity based address assignment. POPA can be
	[RFC3315] or using IPv6 stateless auto-configuration [RFC2461].		configured using DHCP [RFC2131] [RFC3315] or using IPv6 stateless
			auto-configuration [RFC2461].
	6.3. Authorized Device ID		6.3. Authorized Device ID
	The MAC address of the PaC can be used as a session attribute of the		The MAC address of the PaC can be used as a session attribute of the
	subscriber and used by EP for packet filtering once the PANA		subscriber and used by EP for packet filtering once the PANA
	authentication successfully completed. The MAC address can also be		authentication successfully completed. The MAC address can also be
	used by the network to assign a subscriber-dependent IP address using		used by the network to assign a subscriber-dependent IP address using
	DHCP. Therefore, the association between the subscriber ID that was		DHCP. Therefore, the association between the subscriber ID that was
	used with the PANA authentication and the session attributes (MAC and		used with the PANA authentication and the session attributes (MAC and
	IP addressess) can be formed.		IP addressess) can be formed.
	skipping to change at page 11, line 36 ¶		skipping to change at page 11, line 36 ¶
	| | | |		| | | |
	Figure 5. Generic PANA over DSL call flow		Figure 5. Generic PANA over DSL call flow
	Depending on the deployment, either the DSL Modem acts as a RG and		Depending on the deployment, either the DSL Modem acts as a RG and
	therefore only that node is authenticated; or the DSL Modem acts as a		therefore only that node is authenticated; or the DSL Modem acts as a
	bridge and hosts connected to that bridge gets individually		bridge and hosts connected to that bridge gets individually
	authenticated.		authenticated.
	Step 1: The DSL Modem/RG or host, acting as PaC, configures a pre-		Step 1: The DSL Modem/RG or host, acting as PaC, configures a pre-
	PANA IP address (PRPA).		PANA IP address (PRPA).This step is skipped if the PaC is using an
			unspecified IPv4 address.
	Step 2: PaC discovers the IP address of the PAA. PaC may use DHCP		Step 2: PaC discovers the IP address of the PAA. PaC may use DHCP
	[I-D.ietf-dhc-paa-option] or the discovery mechanism provided by		[I-D.ietf-dhc-paa-option] or the discovery mechanism provided by
	PANA [I-D.fajardo-pana-paa-discovery].		PANA [I-D.fajardo-pana-paa-discovery].
	Step 3: PaC and PAA performs authentication using EAP and AAA		Step 3: PaC and PAA performs authentication using EAP and AAA
	protocols (RADIUS, Diameter, etc.)		protocols (RADIUS, Diameter, etc.)
	Step 4: In case the PRPA was a temporary address or limited-use		Step 4: In case the PRPA was an unspecified IPv4 address,
	address, the PaC configures a post-PANA IP address (POPA). This		temporary IP address or limited-use IP address, the PaC configures
	is the service IP address.		a post-PANA IP address (POPA). This is the service IP address.
	Step 5: PAA instructs the EP to allow authorized IP traffic of		Step 5: PAA instructs the EP to allow authorized IP traffic of
	PaC. This step may be implicitly part of step 4 (e.g. DHCPACK		PaC. This step may be implicitly part of step 4 (e.g. DHCPACK
	with IP address configuration) or performed using a specific API.		with IP address configuration) or performed using a specific API.
	Step 6: PaC can transmit and receive IP data packets.		Step 6: PaC can transmit and receive IP data packets.
	Note that the step 4 is optional. Depending on the network		Note that the step 4 is optional. Depending on the network
	configuration and the IP address resource management, it may not be		configuration and the IP address resource management, it may not be
	needed for the PaC to configure a new IP address after the PANA		needed for the PaC to configure a new IP address after the PANA
	authentication.		authentication.
	6.5.2. Specific Example		6.5.2. Specific Example I
	These are the message flows for a specific example where:		These are the message flows for a specific example where:
	- DSL modem/RG is authenticated,		- DSL modem/RG is authenticated,
	- PRPA is a link-local IPv4 address,		- PRPA is a link-local IPv4 address,
	- PAA discovery is based on DHCP,		- PAA discovery is based on DHCP,
	- Authentication method used is EAP-MD5,		- Authentication method used is EAP-MD5,
	skipping to change at page 14, line 39 ¶		skipping to change at page 14, line 39 ¶
	Note that, during steps 1-14, the DSLAM (acting as EP) allows only		Note that, during steps 1-14, the DSLAM (acting as EP) allows only
	DHCP and PANA messages,and depending on deployment, address		DHCP and PANA messages,and depending on deployment, address
	resolution messages such as ARP and IPv6 Neighbor Discovery messges.		resolution messages such as ARP and IPv6 Neighbor Discovery messges.
	A variation of this call flow can be generated using PANA-based PAA		A variation of this call flow can be generated using PANA-based PAA
	discovery [I-D.fajardo-pana-paa-discovery] instead of DHCP for the		discovery [I-D.fajardo-pana-paa-discovery] instead of DHCP for the
	Steps 2 and 3. If Option 82 value is needed by the BRAS, it can be		Steps 2 and 3. If Option 82 value is needed by the BRAS, it can be
	inserted into the PANA messages as they go through the DSLAM.		inserted into the PANA messages as they go through the DSLAM.
			6.5.3. Specific Example II
			This is a similar example to the previous one with the exception
			that:
			- PRPA is the unspecified IPv4 address,
			- PAA discovery is based on PAA responding to broadcast PCI.
			DSL Modem/RG DSLAM BRAS AAA server
			(PaC) (EP) (PAA)
			| | | |
			| | | |
			| | | |
			|--1. PANA Client initiation-------->| |
			| | | |
			|<-2. PANA Auth Req (EAP-MD5 chal)---| |
			| | | |
			|--3. PANA Auth Ans (EAP-MD5 resp)-->| |
			| | | |
			| | |-4. RADIUS Access ->|
			| | | Request (EAP) |
			| | | |
			| | |<-5. RADIUS Access--|
			| | | (EAP Success) |
			|<-6. PANA Auth Req (EAP Success)----| |
			| | | |
			|--7. PANA Auth Ans (Ack)----------->| |
			| | | |
			|--8. DHCP Discover----------------->| |
			| | | |
			|<-9. DHCP Offer---------------------| |
			| | | |
			|--10. DHCP Request----------------->| |
			| | | |
			|<-11. DHCP Ack----*-----------------| |
			| | | |
			|<-12. IP session data traffic----------------> |
			| | | |
			Figure 7. Specific example message flow.
			Step 1: The DSL Modem/RG initiates PANA by sending a broadcasted
			PCI.
			The source IPv4 address of the PCI is set to 0.0.0.0. The
			destination IPv4 address is set to 255.255.255.255.
			Step 2: PAA responds with a PAR message which has its source IPv4
			address set to the PAA's IP address, and the destination IPv4
			address is set to 55.255.255.255. If the PAA is capable of
			retrieving the PaC's MAC address from incoming PCI, then the PAR
			is L2-unicasted using that MAC address. Otherwise, the PAR
			message will be L2-broadcasted.
			PaC discovers the PAA's IPv4 address when it receives the PAR
			message.
			Step 3: PaC sends the PAN message to the PAA's newly discovered
			IPv4 address.
			Steps 4-7: PANA and RADIUS carrying out EAP-MD5 authentication.
			Note that it is possible to translate EAP-MD5/PANA to CHAP/RADIUS
			and eliminate the need to support EAP/RADIUS. But the details of
			such translation is outside the scope of this I-D.
			Steps 8-11: Now that the DSL Modem/RG is authenticated, it
			proceeds to configuring service IP address using DHCPv4. As soon
			as the new IPv4 address is confirmed by the DHCP ACK, the DSL
			Modem/RG can stop using the unspecified address. In Step 11, the
			DHCP ACK message carrying the IPv4 address triggers the DSLAM to
			update its filters with the authorized IP/MAC address of the DSL
			Modem/RG.
			Step 12: The DSL Modem/RG can transmit and receive IP data packets
			using the service IP address.
			In case the deployment requires the Option 82 as a by-product of
			DHCP-based PAA discovery, then Steps 2-3 from previous call flow can
			be added to this one as well.
			A PAA implementation may not be capable of retrieving the PaC's MAC
			address from L2 header of the incoming PANA messages, or be able to
			send a L2-unicast even if it could retrieve the address. In such a
			case, the PAA sends PANA messages as L2-broadcast. In order to
			prevent other PaCs from processing the messages destined for a
			specific PaC, each PaC is required to supply its own MAC address as a
			payload AVP to PCI and expect it to be echoed back by the PAA in the
			initial PAR (TBD: Define an AVP for that). PaCs shall drop PARs with
			mismatching MAC payloads. If the PAA is capable of L2-unicasting
			PANA messages by using the MAC address learned from the PCI payload,
			it can do so.
			Note that any message beyond Step 2 would include the PAA-assigned
			and PaC-acknowledged PANA Session Id, hence use of MAC address
			payload is not needed for those messages.
	7. Security Considerations		7. Security Considerations
	The DSL infrastructure that connects the CPE to the DSLAM/BRAS is		The DSL infrastructure that connects the CPE to the DSLAM/BRAS is
	assumed to run over a physically-secured non-shared media. For that		assumed to run over a physically-secured non-shared media. For that
	reason, neither the use of a key-generating EAP method nor a secure		reason, neither the use of a key-generating EAP method nor a secure
	L2/L3 channel bootstrapped by PANA is required. The current DSL		L2/L3 channel bootstrapped by PANA is required. The current DSL
	deployments are satisfied by using non-key-generating client-only		deployments are satisfied by using non-key-generating client-only
	authentication methods (e.g., CHAP and its EAP equivalent EAP-MD5).		authentication methods (e.g., CHAP and its EAP equivalent EAP-MD5).
	The same model can be maintained even with the PANA-based		The same model can be maintained even with the PANA-based
	deployments. If next generation deployments prefer key-generating		deployments. If next generation deployments prefer key-generating
	skipping to change at page 18, line 44 ¶		skipping to change at line 859 ¶
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 12 change blocks.
	31 lines changed or deleted		130 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/