< draft-ietf-pana-ipsec-06.txt		draft-ietf-pana-ipsec-07.txt >
	PANA Working Group		PANA Working Group
	Internet Draft M. Parthasarathy		Internet Draft M. Parthasarathy
	Document: draft-ietf-pana-ipsec-06.txt Nokia		Document: draft-ietf-pana-ipsec-07.txt Nokia
	Expires: November 2005 May 2005		Expires: January 2006 July 2005
	PANA Enabling IPsec based Access Control		PANA Enabling IPsec based Access Control
	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
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at		and may be updated, replaced, or obsoleted by other documents at any
	anytime. 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 November 2005.		This Internet-Draft will expire on January 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005). All Rights Reserved.		Copyright (C) The Internet Society (2005). All Rights Reserved.
	Abstract		Abstract
	PANA (Protocol for carrying Authentication for Network Access) is a		PANA (Protocol for carrying Authentication for Network Access) is a
	protocol for authenticating clients to the access network using IP		protocol for authenticating clients to the access network using IP
	based protocols. The PANA protocol authenticates the client and also		based protocols. The PANA protocol authenticates the client and also
	establishes a PANA security association between the PANA client and		establishes a PANA security association between the PANA client and
	PANA authentication agent at the end of a successful authentication.		PANA authentication agent at the end of a successful authentication.
	This document discusses the details for establishing an IPsec		This document discusses the details for establishing an IPsec
	security association using the PANA security association for enabling		security association using the PANA security association for enabling
	IPsec based access control.		IPsec based access control.
	Table of Contents		Table of Contents
	1.0 Introduction..................................................2		1.0 Introduction..................................................2
	2.0 Keywords......................................................4		2.0 Keywords......................................................4
	3.0 Pre-requisites for IPsec SA establisment......................4		3.0 Pre-requisites for IPsec SA establishment.....................4
	4.0 IP Address Configuration......................................4		4.0 IP Address Configuration......................................4
	5.0 IKE Pre-shared key derivation.................................5		5.0 IKE Pre-shared key derivation.................................5
	6.0 IKE and IPsec details.........................................6		6.0 IKE and IPsec details.........................................6
	7.0 Packet Formats................................................7		7.0 Packet Formats................................................7
	8.0 IPsec SPD entries.............................................8		8.0 IPsec SPD entries.............................................8
	9.0 Dual Stack Operation.........................................12		9.0 Dual Stack Operation.........................................11
			10.0 IANA Considerations.........................................12
	10.0 Security considerations.....................................12		10.0 Security considerations.....................................12
	11.0 Normative References........................................12		11.0 Normative References........................................12
	12.0 Informative References......................................13		12.0 Informative References......................................12
	13.0 Acknowledgments.............................................14		13.0 Acknowledgments.............................................14
	14.0 Revision log................................................14		14.0 Revision log................................................14
	15.0 Appendix A..................................................15		15.0 Appendix A..................................................15
	16.0 Author's Addresses..........................................16		16.0 Author's Addresses..........................................16
	Intellectual Property Statement..................................16		Intellectual Property Statement..................................16
	Disclaimer of Validity...........................................17		Disclaimer of Validity...........................................17
	Copyright Statement..............................................17		Copyright Statement..............................................17
	Acknowledgment...................................................17		Acknowledgment...................................................17
	1.0 Introduction		1.0 Introduction
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 42 ¶
	client (PaC) and PANA authentication agent (PAA) at the end of		client (PaC) and PANA authentication agent (PAA) at the end of
	successful authentication. The PAA indicates the results of the		successful authentication. The PAA indicates the results of the
	authentication using the PANA-Bind-Request message wherein it can		authentication using the PANA-Bind-Request message wherein it can
	indicate the access control method enforced by the access network.		indicate the access control method enforced by the access network.
	The PANA protocol [PANA-PROT] does not discuss any details of IPsec		The PANA protocol [PANA-PROT] does not discuss any details of IPsec
	[RFC2401] security association (SA) establishment, when IPsec is used		[RFC2401] security association (SA) establishment, when IPsec is used
	for access control. This document discusses the details of		for access control. This document discusses the details of
	establishing an IPsec security association between the PANA client		establishing an IPsec security association between the PANA client
	and the enforcement point. The IPsec SA is established using IKE		and the enforcement point. The IPsec SA is established using IKE
	[RFC2409], which in turn uses the pre-shared key derived from the EAP		[RFC2409], which in turn uses the pre-shared key derived from the EAP
	authentication (AAA-Key). The IPsec SA used to protect the packet		authentication. The IPsec SA used to protect the packet provides the
	provides the assurance that the packet comes from the client that		assurance that the packet comes from the client that authenticated to
	authenticated to the network. Thus, the IPsec SA can be used for		the network. Thus, the IPsec SA can be used for access control and
	access control and specifically used to prevent the service theft		specifically used to prevent the service theft mentioned in
	mentioned in [PANA-THREATS]. The term "access control" in this		[RFC4016]. The term "access control" in this document refers to the
	document refers to the per-packet authentication provided by IPsec.		per-packet authentication provided by IPsec. IPsec is used to protect
	IPsec is used to protect packets flowing between PaC and EP in both		packets flowing between PaC and EP in both directions.
	directions.
	Please refer to [PANAREQ] for terminology and definitions of terms		Please refer to [PANAREQ] for terminology and definitions of terms
	used in this document. The PANA framework document [PANA-FRAME]		used in this document. The PANA framework document [PANA-FRAME]
	describes the deployment scenarios for IPsec. The following picture		describes the deployment scenarios for IPsec. The following picture
	illustrates what is being protected with IPsec. The different		illustrates what is being protected with IPsec. The different
	scenarios of PANA usage are described in the [PANAREQ]. When IPsec is		scenarios of PANA usage are described in the [PANAREQ]. When IPsec is
	used, scenarios 3 and 5 are supported as shown below. As shown in		used, scenarios 3 and 5 are supported as shown below. As shown in
	Figure 1, the Enforcement Point (EP), Access Router (AR) and the PANA		Figure 1, the Enforcement Point (EP), Access Router (AR) and the PANA
	authentication agent are co-located which is described as scenario 3		authentication agent are co-located which is described as scenario 3
	in [PANAREQ].		in [PANAREQ].
	PaC ------------------+		PaC ------------+
	|		|
	+---EP/AR/PAA----Intranet/Internet		+---EP/AR/PAA----Intranet/Internet
	|		|
	PaC ------------------+		PaC ------------+
	<-----------IPsec-------->		<-------IPsec------>
	Figure 1: PAA/EP/AR are co-located		Figure 1: PAA/EP/AR are co-located
	As show in Figure 2, only the AR and EP are co-located. The PAA is a		As show in Figure 2, only the AR and EP are co-located. The PAA is a
	separate node though located on the same link as the AR and EP. All		separate node though located on the same link as the AR and EP. All
	of them are one IP hop away from the PaC. This is the same as		of them are one IP hop away from the PaC. This is the same as
	scenario 5 described in [PANAREQ].		scenario 5 described in [PANAREQ].
	PaC ------------------+		PaC -------------+
	|		|
	+---PAA		+---PAA
	|		|
	+---EP/AR-----Intranet/Internet		+---EP/AR-----Intranet/Internet
	|		|
	PaC ------------------+		PaC -------------+
	<-----------IPsec-------->		<------IPsec----->
	Figure 2: EP and AR are co-located		Figure 2: EP and AR are co-located
	The IPsec security association protects the traffic between the PaC		The IPsec security association protects the traffic between the PaC
	and EP. In IPsec terms, the EP is a security gateway (therefore a		and EP. In IPsec terms, the EP is a security gateway (therefore a
	router) and forwards packets coming from the PaC to other nodes.		router) and forwards packets coming from the PaC to other nodes.
	First, this document discusses some of the pre-requisites for IPsec		First, this document discusses some of the pre-requisites for IPsec
	SA establishment. Next, it gives details on what should be		SA establishment. Next, it gives details on what should be
	communicated between the PAA and EP. Then, it gives the details of		communicated between the PAA and EP. Then, it gives the details of
	IKE exchange with IPsec packet formats and SPD entries. Finally, it		IKE exchange with IPsec packet formats and SPD entries. Finally, it
	discusses the dual stack operation.		discusses the dual stack operation.
	2.0 Keywords		2.0 Keywords
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2118].		document are to be interpreted as described in [RFC2118].
	3.0 Pre-requisites for IPsec SA establisment		3.0 Pre-requisites for IPsec SA establishment
	This document assumes that the following have already happened before		This document assumes that the following have already happened before
	the IKE exchange starts.		the IKE exchange starts.
	1) The PaC) and PAA mutually authenticate each other using an EAP		1) The PaC) and PAA mutually authenticate each other using an EAP
	method that is able to derive a AAA-key [EAP-KEY].		method that is able to derive a AAA-key [EAP-KEY].
	2) The PaC learns the IP address of the Enforcement point (EP)		2) The PaC learns the IP address of the Enforcement point (EP)
	during the PANA exchange.		during the PANA exchange.
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 34 ¶
	key changes due to re-authentication as described below, the new		key changes due to re-authentication as described below, the new
	value is computed by the PAA and communicated to the EP with all the		value is computed by the PAA and communicated to the EP with all the
	other parameters.		other parameters.
	The IKE exchange between the PaC and PAA is equivalent to the 4-way		The IKE exchange between the PaC and PAA is equivalent to the 4-way
	handshake in [IEEE80211i] following the EAP exchange. The IKE		handshake in [IEEE80211i] following the EAP exchange. The IKE
	exchange establishes the IPsec SA similar to the pair-wise transient		exchange establishes the IPsec SA similar to the pair-wise transient
	key (PTK) established in [IEEE80211i]. The IKE exchange provides both		key (PTK) established in [IEEE80211i]. The IKE exchange provides both
	key confirmation and protected cipher-suite negotiation.		key confirmation and protected cipher-suite negotiation.
	The IKE pre-shared key is derived as follows.		The IKE pre-shared key is derived as follows (where "|" means
			concactenation).
	IKE Pre-shared Key = HMAC-SHA-1 (AAA-Key, "IKE-preshared key" |		IKE Pre-shared Key = HMAC-SHA-1 (PaC-EP-Master-Key,
			"IKE-preshared key" |
	Session ID | Key-ID | EP-address)		Session ID | Key-ID | EP-address)
	The values have the following meaning:		The values have the following meaning:
	AAA-Key: A key derived by the peer and EAP server and transported to		PaC-EP-Master-Key: A key derived from the AAA-key for each EP as
	the authenticator [EAP-KEY].		defined in [PANA-PROT].
	Session ID: The value as defined in the PANA protocol [PANA-PROT],		Session ID: The value as defined in the PANA protocol [PANA-PROT],
	identifies a particular session of a client.		identifies a particular session of a client.
	Key-ID: This identifies the AAA-Key within a given session [PANA-		Key-ID: This identifies the PaC-EP-Master-Key within a given session
	PROT]. During the lifetime of the PANA session, there could be		[PANA-PROT]. During the lifetime of the PANA session, there could be
	multiple runs of EAP re-authentications. As EAP re-authentication		multiple runs of EAP re-authentications. As EAP re-authentication
	changes the AAA-Key, Key-ID is used to identify the right AAA-Key.		changes the AAA-key which in turn affects Pac-EP-Master-Key, Key-ID
	This is contained in the Key-ID AVP [PANA-PROT].		is used to identify the right PaC-EP-Master-Key. This is contained in
			the Key-ID AVP [PANA-PROT].
	EP-address: This is the address of the enforcement point with which		EP-address: This is the address of the enforcement point with which
	the IKE exchange is being performed. When the PAA is controlling		the IKE exchange is being performed. When the PAA is controlling
	multiple EPs, this provides a different pre-shared key for each of		multiple EPs, this provides a different pre-shared key for each of
	the EPs.		the EPs.
	The character "|" denotes concatenation as defined in [RFC2409].
	During EAP re-authentication, the AAA-Key changes. Whenever the AAA-		During EAP re-authentication, the AAA-Key changes. Whenever the AAA-
	Key changes, a new value of Key-ID is established between the PaC and		Key changes, a new PaC-EP-Master-Key is derived and a new value for
	PAA/EP as defined in [PANA-PROT]. If there is already an IKE SA or		Key-ID is established between the PaC and PAA/EP as defined in [PANA-
	IPsec SA established, it MUST continue to be used till it expires. A		PROT]. The [EAP-KEY] document requires that all keys derived from
	change in the value of AAA-Key MUST NOT result in re-negotiating a		AAA-key be deleted when the AAA-key expires. Hence, a new IKE PSK
	new IKE SA or IPsec SA immediately. The IKE PSK continues to exist		should be derived upon AAA-key expiry. As it also affects the IKE
	even after the AAA-Key from which it is derived expires. When the		and IPsec SAs derived from it, new security associations for IKE and
	IPsec SA expires, a new IPsec SA is negotiated without negotiating a		IPsec are established with the new IKE PSK. In case where two runs of
	new IKE SA. When the IKE SA expires, a new IKE PSK is derived from		EAP authentication (NAP/ISP) are performed during a single PANA
	the latest AAA-key and used in negotiating the IKE SA and IPsec SA.		authentication phase, a new PaC-EP-Master-Key is derived from the
	In case where two runs of EAP authentication (NAP/ISP) are performed		AAA-key obtained from both authentications as specified in the [PANA-
	during a single PANA authentication phase, a AAA-Key is derived from		PROT].
	both authentications as specified in the [PANA-PROT].
	6.0 IKE and IPsec details		6.0 IKE and IPsec details
	IKE [RFC2409] MUST be used for establishing the IPsec SA. The details		IKE [RFC2409] MUST be used for establishing the IPsec SA. The details
	specified in this document works with IKEv2 [IKEV2] as well as IKE.		specified in this document works with IKEv2 [IKEV2] as well as IKE.
	Any difference between them would be explicitly noted. PANA		Any difference between them would be explicitly noted. PANA
	authenticates the client and network, and derives the keys to protect		authenticates the client and network, and derives the keys to protect
	the traffic. Hence, manual keying cannot be used. If IKE is used,		the traffic. Hence, manual keying cannot be used. If IKE is used,
	aggressive mode with pre-shared key MUST be supported. The PaC and EP		aggressive mode with pre-shared key MUST be supported. The PaC and EP
	SHOULD use the following value in the payload of the ID_KEY_ID to		SHOULD use the following value in the payload of the ID_KEY_ID to
	skipping to change at page 6, line 50 ¶		skipping to change at page 6, line 49 ¶
	portion of the Session-Id and Key-Id AVP respectively [PANA-PROT].		portion of the Session-Id and Key-Id AVP respectively [PANA-PROT].
	They are concatenated to form the content of ID_KEY_ID data. IP		They are concatenated to form the content of ID_KEY_ID data. IP
	addresses cannot be used as identifier as the same PaC or different		addresses cannot be used as identifier as the same PaC or different
	PaC may use the same IP address across a PANA session. For the same		PaC may use the same IP address across a PANA session. For the same
	reason, main mode of IKE cannot be used, as it requires addresses to		reason, main mode of IKE cannot be used, as it requires addresses to
	be used as identifiers.		be used as identifiers.
	If IKE is used, a quick mode exchange is performed to establish an		If IKE is used, a quick mode exchange is performed to establish an
	ESP tunnel mode IPsec SA for protecting the traffic between the PaC		ESP tunnel mode IPsec SA for protecting the traffic between the PaC
	and EP. In IKEv2, the initial exchange (IKE_SA_INIT and IKE_AUTH)		and EP. In IKEv2, the initial exchange (IKE_SA_INIT and IKE_AUTH)
	creates the IPsec SA also. The identities (traffic selectors in		creates the IPsec SA also. The identities (a.k.a. traffic selectors
	IKEv2) used during Phase 2 are explained in the next section. As		in IKEv2) used during Phase 2 are explained later along with the SPD
	mentioned in section 4.0, an address (POPA) may also have to be		entries. As mentioned in section 4.0, an address (POPA) may also have
	configured. The address configuration method to be used by the PaC is		to be configured. The address configuration method to be used by the
	indicated in the PANA-Bind-Request message at the end of the		PaC is indicated in the PANA-Bind-Request message at the end of the
	successful PANA authentication. The PaC chooses the appropriate		successful PANA authentication. The PaC chooses the appropriate
	method and replies back in PANA-Bind-Answer message.		method and replies back in PANA-Bind-Answer message.
	7.0 Packet Formats		7.0 Packet Formats
	Following acronyms are used throughout this document.		Following acronyms are used throughout this document.
	PAC-TIA denotes the IPsec-TIA used by the PaC. PAC-TIA may be set to		PAC-TIA denotes the IPsec-TIA used by the PaC. PAC-TIA may be set to
	a PRPA when the same PRPA is used as the IPsec-TIA and IPsec-TOA on		a PRPA when the same PRPA is used as the IPsec-TIA and IPsec-TOA on
	the PaC. Otherwise, PAC-TIA is set to the POPA.		the PaC. Otherwise, PAC-TIA is set to the POPA.
	skipping to change at page 8, line 14 ¶		skipping to change at page 8, line 14 ¶
	IPv6 header (source = EP-ADDR,		IPv6 header (source = EP-ADDR,
	destination = PAC-TOA)		destination = PAC-TOA)
	ESP header		ESP header
	IPv6 header (source = END-ADDR,		IPv6 header (source = END-ADDR,
	destination = PAC-TIA)		destination = PAC-TIA)
	8.0 IPsec SPD entries		8.0 IPsec SPD entries
	The SPD entries for IPv4 and IPv6 are specified separately as they		The SPD entries for IPv4 and IPv6 are specified separately as they
	are different. All the SPD entries described below are dynamically		are different. When the same address is used as IPsec-TIA and IPsec-
	created. When the same address is used as IPsec-TIA and IPsec-TOA,		TOA, the EP can add the entry to the SPD before the IKE exchange
	the EP can add the entry to the SPD before the IKE exchange starts,		starts, as it knows the address a priori. When IKEv2 [IKEV2] or
	as it knows the address a priori. When IKEv2 [IKEV2] or [RFC3456] is		[RFC3456] is used for address configuration, the SPD entry cannot be
	used for address configuration, the SPD entry cannot be created until		created until the IPsec SA is successfully negotiated as the address
	the IPsec SA is successfully negotiated as the address is not known a		is not known a priori. This is very similar to the road warrior case
	priori. This is very similar to the road warrior case described in		described in [IPSEC-BIS]. In this case, an SPD entry with a name
	[IPSEC-BIS]. In this case, an SPD entry with a name selector is used		selector is used and when the IPsec SA is successfully negotiated, a
	and when the IPsec SA is successfully negotiated, a new SPD entry is		new SPD entry is created with the appropriate addresses. The name
	created with the appropriate addresses. The name used here could be		would be the contents of ID_KEY_ID payload.
	the contents of ID_KEY_ID payload. The SPD entries shown below are
	the entries that are added after the successful IPsec SA negotiation.
	In environments where the PaC is a router, the IPsec-TIA can be a		In environments where the PaC is a router, the IPsec-TIA can be a
	range of addresses (prefix) instead of a single host address. The PaC		range of addresses (prefix) instead of a single host address. The PaC
	acts like a security gateway in this case establishing the IPsec SA		acts like a security gateway in this case establishing the IPsec SA
	with another security gateway (EP). This scenario is supported by		with another security gateway (EP). This scenario is supported by
	[RFC2401] and [IPSEC-BIS]. It is assumed that the PaC obtains the		[RFC2401] and [IPSEC-BIS]. It is assumed that the PaC obtains the
	prefix through other mechanisms not defined in this document. When		prefix through other mechanisms not defined in this document. When
	the IPsec SA is negotiated, the prefix is carried in the traffic		the IPsec SA is negotiated, the prefix is carried in the traffic
	selectors.		selectors.
	The SPD entries shown here affect the flow of data traffic, which		Each SPD entry specifies packet disposition as BYPASS, DISCARD or
	includes neighbor discovery messages for IPv6. The SPD entries in the		PROTECT. The entry that causes the traffic to be protected with IPsec
	PaC protect all the traffic with source address set to IPsec-TIA.		uses IPsec-TIA as the selector. This has the side effect of
	When IPsec-TIA and IPsec-TOA are the same (as discussed in section		protecting all the traffic, which could be a problem. Some of the
	4.0), the PANA traffic also gets protected with IPsec. The PANA		traffic that is not protected with IPsec is discussed below.
	traffic destined to the PAA from the PaC is forwarded to PAA after
	decrementing the TTL in the IP header. The PAA would drop the packet
	if the TTL is not 255. Hence, we need explicit entries to bypass
	IPsec protection for PANA traffic on PaC. This may not be needed
	always for traffic going from PAA to PaC. If PAA and EP are not co-
	located, PAA would send traffic directly to PaC without going through
	EP. Hence, EP does not need to have SPD entries to bypass IPsec in
	this case. If PAA and EP are co-located, the PANA packets will be
	protected with IPsec only if the IPsec-TIA and IPsec-TOA are same.
	Hence, we need explicit entries to bypass IPsec protection when PAA
	and EP are co-located.
	If source_port = PANA_PORT OR dest_port = PANA_PORT
	THEN BYPASS
	PANA_PORT is the IANA assigned (TBD) PANA protocol number [PANA-
	PROT]. There may be other protocols that expect the TTL to be 255
	whose SPD entries are not shown here. Also, when the PaC is using
	IPsec for remote access, there may be additional SPD entries and
	IPsec security associations, which are not discussed in this
	document.
	8.1 IPv4 SPD entries
	PaC's SPD OUT:
	IF source_port = PANA_PORT OR dest_port = PANA_PORT
	THEN BYPASS
	IF source = PAC-TIA & destination = any
	THEN USE ESP TUNNEL MODE SA:
	outer source = PAC-TOA
	outer destination = EP-ADDR
	PaC's SPD IN:
	IF source_port = PANA_PORT OR dest_port = PANA_PORT
	THEN BYPASS
	IF source = any & destination = PAC-TIA		. The neighbor discovery messages specified in [RFC2461] are
	THEN USE ESP TUNNEL MODE SA:		protected using [RFC3971]. The Multicast listener Discovery
	outer source = EP-ADDR		messages specified in [RFC2710] are also bypassed as IKE can
	outer destination = PAC-TOA		negotiate keys only for unicast traffic. The SPD contains entry
			based on ICMPv6 type (130 to 137) to bypass such traffic.
	EP's SPD OUT:		. When IPsec-TIA and IPsec-TOA are the same (as discussed in
			section 4.0), the PANA traffic also gets protected with IPsec.
			As the IPsec protection adds extra overhead without any benefit,
			we need explicit entries to bypass IPsec protection for PANA
			traffic on PaC. This may not be needed always for traffic going
			from PAA to PaC. If PAA and EP are not co-located, PAA would
			send traffic directly to PaC without going through EP. Hence, EP
			does not need to have SPD entries to bypass IPsec in this case.
	IF source_port = PANA_PORT OR dest_port = PANA_PORT		If PAA and EP are co-located, the PANA packets will be protected
	THEN BYPASS		with IPsec only if the IPsec-TIA and IPsec-TOA are same. Hence,
			we need explicit entries to bypass IPsec protection when PAA and
			EP are co-located. The SPD entry is specified using PANA_PORT.
			PANA_PORT is the IANA assigned (TBD) PANA protocol number [PANA-
			PROT].
	IF source = any & destination = PAC-TIA		There may be protocols that expect the TTL to be 255, which may not
	THEN USE ESP TUNEL MODE SA:		be preserved as a result of IP forwarding by the EP. If the protocol
	outer source = EP-ADDR		termination is in a different place than EP, then we may need
	outer destination = PAC-TOA		additional bypass entries for those protocols, which are not shown
			here. Also, when the PaC is using IPsec for remote access, there may
			be additional SPD entries and IPsec security associations, which are
			not discussed in this document.
	EP's SPD IN:		The format chosen to represent the SPD rules is similar to the one
			used in [IPSEC-BIS] document (See Appendix E). Following acronyms are
			used.
	IF source_port = PANA_PORT OR dest_port = PANA_PORT		Rule - SPD rule and this column has ordered rules.
	THEN BYPASS		LADDR - Local address
			RADDR - Remote address
			LPORT - Local Port
			RPORT - Remote Port
			ITYPE - Specifies ICMPv6 type
			Action - Specifies the IPsec actions (BYPASS, DROP, PROTECT)
	IF source = PAC-TIA & destination = any		8.1 IPv4 SPD entries
	THEN USE ESP TUNNEL MODE SA:
	outer source = PAC-TOA		PaC's SPD:
	outer destination = EP-ADDR
	During the IPsec SA setup, the PaC uses PAC-TIA as its phase 2		Rule LADDR RADDR LPORT RPORT Action
	identity (IDci) and EP uses ID_IPV4_ADDR_RANGE or ID_IPV4_ADDR_SUBNET		---- ----- ----- ----- ----- ------
	as its phase 2 identity. The starting address is zero IP address and		Rule 1 ANY PAA-ADDR ANY PANA_PORT BYPASS
	the end address is all ones for ID_IPV4_ADDR_RANGE. The starting
	address is zero IP address and the end address is all zeroes for
	ID_IPV4_ADDR_SUBNET.
	8.2 IPv6 SPD entries		Rule 2 PAC-TIA ANY ANY ANY PROTECT
			(ESP, tunnel)
	The IPv6 SPD entries are slightly different from IPv4 to prevent the		Rule 3 ANY ANY ANY ANY DISCARD
	neighbor and router discovery [RFC2461] packets from being protected
	with IPsec. The first three entries of the following SPD entries
	bypass IPsec protection for neighbor and router discovery packets.
	The latest version of the IPsec [IPSEC-BIS] document allows traffic
	selectors to be based on ICMPv6 type and code values. In that case,
	the first three entries can be based on ICMPv6 type and code values.
	Pac's SPD OUT:		The ESP tunnel's outer source address is PAC-TOA and outer
			destination address is EP-ADDR.
	IF source = ::/128 & destination = any		EP's SPD:
	THEN BYPASS
	IF source = fe80::/10 & destination = any		Rule LADDR RADDR LPORT RPORT Action
	THEN BYPASS		---- ----- ----- ----- ----- ------
			Rule 1 PAA-ADDR ANY PANA_PORT ANY BYPASS
	IF source = any & destination = fe80::/10		Rule 2 ANY PAC-TIA ANY ANY PROTECT
	THEN BYPASS		(ESP, tunnel)
	IF source_port = PANA_PORT OR dest_port = PANA_PORT		Rule 3 ANY ANY ANY ANY DISCARD
	THEN BYPASS
	IF source = PAC-TIA & destination = any		The ESP tunnel's outer source address is EP-ADDR and outer
	THEN USE ESP TUNNEL MODE SA:		destination address is PAC-TOA.
	outer source = PAC-TOA
	outer destination = EP-ADDR
	PaC's SPD IN:		The phase 2 identities (a.k.a. traffic selectors in IKEv2) differ
			depending on how the PaC acquires the PAC-TIA.
	IF source = ::/128 & destination = any		. If the client uses PAC-TOA as the PAC-TIA, then it uses PAC-TOA
	THEN BYPASS		as the client identity (IDci). The responder identity (IDcr)
			would contain the ID_IPV4_ADDR_RANGE with starting address as
			zero address (0.0.0.0) and end address as (255.255.255.255).
	IF source = fe80::/10 & destination = any		. If the client uses [RFC3456] for acquiring the PAC-TIA, it needs
	THEN BYPASS		to establish the DHCP SA first. This requires additional SPD
			entries. Once the PAC-TIA is acquired using DHCP, the DHCP SA is
			deleted and a new IPsec tunnel mode SA is established as
			specified in this document. When establishing such an SA, PAC-
			TIA will be used as the IDci. The responder identity (IDcr)would
			contain the ID_IPV4_ADDR_RANGE with starting address as zero
			address (0.0.0.0) and end address as (255.255.255.255).
	IF source = any & destination = fe80::/10		. If IKEv2 is used to obtain the PAC-TIA, the client uses the
	THEN BYPASS		configuration request (CFG_REQUEST) along with the traffic
	IF source_port = PANA_PORT OR dest_port = PANA_PORT		selectors as given in IKEv2. PaC uses IPV4_ADDR_RANGE with
	THEN BYPASS		starting address as zero address (0.0.0.0) and end address as
			(255.255.255.255) for both TSi and TSr. The EP assigns the
			address (PAC-TIA) and returns it in both the configuration
			payload (CFG_REPLY) and TSi. The TSr is left to contain the
			IPV4_ADDR_RANGE.
	IF source = any & destination = PAC-TIA		8.2 IPv6 SPD entries
	THEN USE ESP TUNNEL MODE SA:		Pac's SPD:
	outer source = EP-ADDR
	outer destination = PAC-TOA
	EP's SPD OUT:		Rule LADDR RADDR LPORT RPORT ITYPE Action
			---- ----- ----- ----- ----- ----- ------
			Rule 1 ANY ANY ANY ANY 130-137 BYPASS
	IF source = ::/128 & destination = any		Rule 2 ANY ANY PANA_PORT ANY ANY BYPASS
	THEN BYPASS
	IF source = fe80::/10 & destination = any		Rule 3 PAC-TIA ANY ANY ANY ANY PROTECT
	THEN BYPASS		(ESP, tunnel)
	IF source = any & destination = fe80::/10		Rule 4 ANY ANY ANY ANY ANY DISCARD
	THEN BYPASS
	IF source_port = PANA_PORT OR dest_port = PANA_PORT		The ESP tunnel's outer source address is PAC-TOA and outer
	THEN BYPASS		destination address is EP-ADDR.
	IF source = any & destination = PAC-TIA		EP's SPD:
	THEN USE ESP TUNNEL MODE SA:
	outer source = EP-ADDR
	outer destination = PAC-TOA
	EP's SPD IN:		Rule LADDR RADDR LPORT RPORT ITYPE Action
			---- ----- ----- ----- ----- ----- ------
			Rule 1 ANY ANY ANY ANY 130-137 BYPASS
	IF source = ::/128 & destination = any		Rule 2 ANY ANY ANY PANA_PORT ANY BYPASS
	THEN BYPASS
	IF source = fe80::/10 & destination = any		Rule 3 ANY PAC-TIA ANY ANY ANY PROTECT
	THEN BYPASS		(ESP, tunnel)
	IF source = any & destination = fe80::/10		Rule 4 ANY ANY ANY ANY ANY DISCARD
	THEN BYPASS
	IF source_port = PANA_PORT OR dest_port = PANA_PORT		The ESP tunnel's outer source address is EP-ADDR and outer
	THEN BYPASS		destination address is PAC-TOA.
	IF source = PAC-TIA & destination = any		IKEv2 [IKEV2] is used to configure the PAC-TIA address. The usage of
	THEN USE ESP TUNNEL MODE SA:		traffic selectors is very similar to the IPv4 usage as explained in
	outer source = PAC-TOA		the previous section. The client may use the interface identifier in
	outer destination = EP-ADDR		the lower bits of the TSi so that the responder can assign an IPv6
	During the IPsec SA setup, the PaC uses PAC-TIA as its phase 2		address honoring the interface identifier also.
	identity (IDci) and the EP uses ID_IPV6_ADDR_RANGE or
	ID_IPV6_ADDR_SUBNET as its phase 2 identity. The starting address is
	zero IP address and the end address is all ones for
	ID_IPV6_ADDR_RANGE. The starting address is zero IP address and the
	end address is all zeroes for ID_IPV6_ADDR_SUBNET.
	9.0 Dual Stack Operation		9.0 Dual Stack Operation
	IKEv2 [IKEV2] can enable configuration of IPsec-TIA for both IPv4 and		IKEv2 [IKEV2] can enable configuration of IPsec-TIA for both IPv4 and
	IPv6 TIAs by sending both IPv4 and IPv6 configuration attributes in		IPv6 TIAs by sending both IPv4 and IPv6 configuration attributes in
	the configuration request (CFG-REQUEST). This enables use of single		the configuration request (CFG_REQUEST). This enables use of single
	IPsec tunnel mode SA for sending both IPv4 and IPv6 traffic.		IPsec tunnel mode SA for sending both IPv4 and IPv6 traffic.
	Therefore, IKEv2 is recommended for handling dual-stack PaCs where		Therefore, IKEv2 is recommended for handling dual-stack PaCs where
	single execution of IKE is desired.		single execution of IKE is desired.
			10.0 IANA Considerations
			This document does not make no request to IANA.
	10.0 Security considerations		10.0 Security considerations
	This document discusses the use of IPsec for access control when PANA		This document discusses the use of IPsec for access control when PANA
	is used for authenticating the clients to the access network.		is used for authenticating the clients to the access network.
	The aggressive mode in IKE [RFC2409] is considered bad due to its DoS		The aggressive mode in IKE [RFC2409] is considered bad due to its DoS
	properties i.e., any attacker can bombard IKE aggressive mode packets		properties i.e., any attacker can bombard IKE aggressive mode packets
	making the EP perform heavy diffie-hellman calculations. As the		making the EP perform heavy diffie-hellman calculations. As the
	ID_KEY_ID can be verified by the EP before doing the diffie-hellman		ID_KEY_ID can be verified by the EP before doing the diffie-hellman
	calculation, it prevents random attacks. The attacker now needs to		calculation, it prevents random attacks. The attacker now needs to
	skipping to change at page 12, line 42 ¶		skipping to change at page 12, line 34 ¶
	If the EP does not verify whether the PaC is authorized to use an IP		If the EP does not verify whether the PaC is authorized to use an IP
	address, it is possible for the PaC to steal the traffic destined to		address, it is possible for the PaC to steal the traffic destined to
	some other PaC. When IKEv2 [IKEV2] and [RFC3456] are used for address		some other PaC. When IKEv2 [IKEV2] and [RFC3456] are used for address
	configuration, the address is assigned by the EP and hence this		configuration, the address is assigned by the EP and hence this
	attack is not present in such cases. When the same address is used as		attack is not present in such cases. When the same address is used as
	both IPsec-TIA and IPsec-TOA, the EP creates the SPD entry with the		both IPsec-TIA and IPsec-TOA, the EP creates the SPD entry with the
	appropriate address for the PaC and hence the address is verified		appropriate address for the PaC and hence the address is verified
	implicitly by the virtue of successful IPsec SA negotiation.		implicitly by the virtue of successful IPsec SA negotiation.
	When IPv6 is used, the SPD entries bypass all link-local traffic
	without applying IPsec. This should not be a limitation as the link-
	local address is used only by link-local services e.g. neighbor and
	router discovery, which could use [SEND] to protect their traffic.
	Moreover, this limitation may not be there in the future if IPsec
	extends the SPD selectors to specify ICMP types.
	11.0 Normative References		11.0 Normative References
	Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,		Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
	RFC 2026, October 1996.		RFC 2026, October 1996.
	[RFC2401] S. Kent et al., "Security Architecture for the Internet		[RFC2401] S. Kent et al., "Security Architecture for the Internet
	Protocol", RFC 2401, November 1998		Protocol", RFC 2401, November 1998
	[PANA-PROT] D. Fosberg et al., "Protocol for Carrying Authentication		[PANA-PROT] D. Fosberg et al., "Protocol for Carrying Authentication
	for Network Access", draft-ietf-pana-05.txt		for Network Access", draft-ietf-pana-06.txt
	[PANA-THREATS] M. Parthasarathy, "PANA Threat analysis and security		[RFC4016] M. Parthasarathy, "Protocol for carrying Authentication for
	requirements", draft-ietf-pana-threats-eval-04.txt		Network Access (PANA) Threat analysis and security requirements",
			RFC 4016, March 2005
	12.0 Informative References		12.0 Informative References
	[PANAREQ] A. Yegin et al., "Protocol for Carrying Authentication for		[PANAREQ] A. Yegin et al., "Protocol for Carrying Authentication for
	Network Access (PANA) Requirements and Terminology", draft-ietf-		Network Access (PANA) Requirements and Terminology", draft-ietf-
	pana-requirements-09.txt		pana-requirements-09.txt
	[PANA-FRAME] P. Jayaraman et al., "PANA Framework", draft-ietf-pana-		[PANA-FRAME] P. Jayaraman et al., "PANA Framework", draft-ietf-pana-
	framework-01.txt		framework-01.txt
	[RFC2119] S. Bradner, "Key words for use in RFCS to indicate		[RFC2119] S. Bradner, "Key words for use in RFCS to indicate
	requirement levels", RFC 2119, March 1997		requirement levels", RFC 2119, March 1997
	[RFC2409] D. Harkins et al., "Internet Key Exchange", RFC 2409,		[RFC2409] D. Harkins et al., "Internet Key Exchange", RFC 2409,
	November 1998		November 1998
	[IKEV2] C. Kauffman et al., "Internet Key Exchange(IKEv2) Protocol",		[IKEV2] C. Kauffman et al., "Internet Key Exchange(IKEv2) Protocol",
	draft-ietf-ipsec-ikev2-15.txt		draft-ietf-ipsec-ikev2-15.txt
	[IPSEC-BIS] S. Kent, "Security Architecture for the Internet		[IPSEC-BIS] S. Kent, "Security Architecture for the Internet
	Protocol", draft-ietf-ipsec-rfc2401bis-00.txt		Protocol", draft-ietf-ipsec-rfc2401bis-06.txt
	[RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,		[RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
	March 1997		March 1997
	[RFC3456] B. Patel et al., "Dynamic Host Configuration Protocol		[RFC3456] B. Patel et al., "Dynamic Host Configuration Protocol
	(DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January		(DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January
	2003		2003
	[RFC3315] R. Droms et. al, "Dynamic Host Configuration Protocol for		[RFC3315] R. Droms et. al, "Dynamic Host Configuration Protocol for
	IPv6", RFC 3315, July 2003		IPv6", RFC 3315, July 2003
	[RFC2461] T. Narten et al., "Neighbor Discovery for IP version 6		[RFC2461] T. Narten et al., "Neighbor Discovery for IP version 6
	(IPv6) ", RFC 2461, December 1998		(IPv6) ", RFC 2461, December 1998
	[RFC2462] S. Thomson et. al, "IPv6 Stateless Address		[RFC2462] S. Thomson et. al, "IPv6 Stateless Address
	Autoconfiguration", RFC 2462, December 1998		Autoconfiguration", RFC 2462, December 1998
	[RFC3041] T. Narten et al., "Privacy Extensions for Stateless Address		[RFC3041] T. Narten et al., "Privacy Extensions for Stateless Address
	Autoconfiguration in IPv6", RFC 3041, January 2001		Autoconfiguration in IPv6", RFC 3041, January 2001
	[EAP-KEY] D. Simon et al., "EAP Key Management Framework", draft-		[EAP-KEY] B. Aboba et al., "EAP Key Management Framework", draft-
	ietf-eap-keying-02.txt		ietf-eap-keying-06.txt
	[SEND] J. Arkko et al., "Secure Neighbor Discovery", draft-ietf-send-		[RFC3971] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", RFC
	ndopt-06.txt		3971, March 2005
	[IPV4-LINK] B. Aboba et al., "Dynamic configuration of Link-local		[IPV4-LINK] B. Aboba et al., "Dynamic configuration of Link-local
	IPv4 addresses", draft-ietf-zeroconf-ipv4-linklocal-12.txt		IPv4 addresses", draft-ietf-zeroconf-ipv4-linklocal-12.txt
	[RFC1918] Y. Rekhter et al., "Address Allocation for Private		[RFC1918] Y. Rekhter et al., "Address Allocation for Private
	Internets", BCP 5, RFC 1918, February 1996		Internets", BCP 5, RFC 1918, February 1996
			[RFC2710] S.Deering et al., "Multicast Listener Discovery (MLD)for
			IPv6", RFC 2710, October 1999
	[IEEE80211i] IEEE Draft 802.11I/D5.0, "Draft Supplement to STANDARD		[IEEE80211i] IEEE Draft 802.11I/D5.0, "Draft Supplement to STANDARD
	FOR Telecommunications and Information Exchange between Systems û		FOR Telecommunications and Information Exchange between Systems
	LAN/MAN Specific Requirements - Part 11: Wireless Medium Access		LAN/MAN Specific Requirements - Part 11: Wireless Medium Access
	Control (MAC) and physical layer specifications: Specification for		Control (MAC) and physical layer specifications: Specification for
	Enhanced Security", August 2003.		Enhanced Security", August 2003.
	13.0 Acknowledgments		13.0 Acknowledgments
	The author would like to thank Francis Dupont, Pasi Eronen, Yoshihiro		The author would like to thank Francis Dupont, Pasi Eronen, Yoshihiro
	Ohba, Jari Arkko, Hannes Tschofenig, Alper Yegin, Erik Nordmark,		Ohba, Jari Arkko, Hannes Tschofenig, Alper Yegin, Erik Nordmark,
	Giaretta Gerardo, Rafa Marin Lopez, Tero Kivinen and other PANA WG		Giaretta Gerardo, Rafa Marin Lopez, Tero Kivinen and other PANA WG
	members for their valuable comments and discussions.		members for their valuable comments and discussions.
	14.0 Revision log		14.0 Revision log
			Changes between revision 06 and 07
			-Changed the format of the SPD to use a table
			-Changed the IPv6 SPD entries to use ICMPv6 types
	Changes between revision 05 and 06		Changes between revision 05 and 06
	-Clarified that PRPA can be a global address also in IPv6.		-Clarified that PRPA can be a global address also in IPv6.
	Changes between revision 04 and 05		Changes between revision 04 and 05
	-working group last call comments (mostly editorial)		-working group last call comments (mostly editorial)
	Changes between revision 03 and 04		Changes between revision 03 and 04
	skipping to change at page 16, line 21 ¶		skipping to change at page 16, line 18 ¶
	also. The implementations would associate the auto-configured		also. The implementations would associate the auto-configured
	addresses and the default router with the interface on which the		addresses and the default router with the interface on which the
	router advertisement was received. As we configure the SPD to		router advertisement was received. As we configure the SPD to
	bypass IPsec for router discovery and neighbor discovery		bypass IPsec for router discovery and neighbor discovery
	messages, the address would be associated with the physical		messages, the address would be associated with the physical
	interface and not with the IPsec interface. There is also an		interface and not with the IPsec interface. There is also an
	additional issue, as the address configured by the PaC is not		additional issue, as the address configured by the PaC is not
	known to the EP. It needs to trust whatever PaC provides in its		known to the EP. It needs to trust whatever PaC provides in its
	traffic selector during the IPsec SA negotiation. This leads to		traffic selector during the IPsec SA negotiation. This leads to
	a DoS attack where the PaC can steal some other PaC's address,		a DoS attack where the PaC can steal some other PaC's address,
	which cannot be prevented unless [SEND] is deployed.		which cannot be prevented unless [RFC3971] is deployed.
	16.0 Author's Addresses		16.0 Author's Addresses
	Mohan Parthasarathy		Mohan Parthasarathy
	313 Fairchild Drive		313 Fairchild Drive
	Mountain View CA-94043		Mountain View CA-94043
	Email: mohanp@sbcglobal.net		Email: mohanp@sbcglobal.net
	Intellectual Property Statement		Intellectual Property Statement
End of changes. 69 change blocks.
	221 lines changed or deleted		201 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/