draft-ietf-radext-ip-port-radius-ext-09.txt		draft-ietf-radext-ip-port-radius-ext-10.txt
	Network Working Group D. Cheng		Network Working Group D. Cheng
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track J. Korhonen		Intended status: Standards Track J. Korhonen
	Expires: September 18, 2016 Broadcom Corporation		Expires: January 29, 2017 Broadcom Corporation
	M. Boucadair		M. Boucadair
	Orange		Orange
	S. Sivakumar		S. Sivakumar
	Cisco Systems		Cisco Systems
	March 17, 2016		July 28, 2016
	RADIUS Extensions for IP Port Configuration and Reporting		RADIUS Extensions for IP Port Configuration and Reporting
	draft-ietf-radext-ip-port-radius-ext-09		draft-ietf-radext-ip-port-radius-ext-10
	Abstract		Abstract
	This document defines three new RADIUS attributes. For devices that		This document defines three new RADIUS attributes. For devices that
	implementing IP port ranges, these attributes are used to communicate		implement IP port ranges, these attributes are used to communicate
	with a RADIUS server in order to configure and report TCP/UDP ports		with a RADIUS server in order to configure and report TCP/UDP ports
	and ICMP identifiers, as well as mapping behavior for specific hosts.		and ICMP identifiers, as well as mapping behavior for specific hosts.
	This mechanism can be used in various deployment scenarios such as		This mechanism can be used in various deployment scenarios such as
	Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc.		Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc.
	Requirements Language		Requirements Language
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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 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."
	This Internet-Draft will expire on September 18, 2016.		This Internet-Draft will expire on January 29, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 51 ¶		skipping to change at page 2, line 51 ¶
	4. Applications, Use Cases and Examples . . . . . . . . . . . . 23		4. Applications, Use Cases and Examples . . . . . . . . . . . . 23
	4.1. Managing CGN Port Behavior using RADIUS . . . . . . . . . 23		4.1. Managing CGN Port Behavior using RADIUS . . . . . . . . . 23
	4.1.1. Configure IP Port Limit for a User . . . . . . . . . 24		4.1.1. Configure IP Port Limit for a User . . . . . . . . . 24
	4.1.2. Report IP Port Allocation/Deallocation . . . . . . . 26		4.1.2. Report IP Port Allocation/Deallocation . . . . . . . 26
	4.1.3. Configure Forwarding Port Mapping . . . . . . . . . . 27		4.1.3. Configure Forwarding Port Mapping . . . . . . . . . . 27
	4.1.4. An Example . . . . . . . . . . . . . . . . . . . . . 29		4.1.4. An Example . . . . . . . . . . . . . . . . . . . . . 29
	4.2. Report Assigned Port Set for a Visiting UE . . . . . . . 30		4.2. Report Assigned Port Set for a Visiting UE . . . . . . . 30
	5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 31		5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 31
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 32		6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	7.1. IANA Considerations on New IPFIX Information Elements . . 32		7.1. IANA Considerations on New IPFIX Information Elements . . 33
	7.2. IANA Considerations on New RADIUS Attributes . . . . . . 33		7.2. IANA Considerations on New RADIUS Attributes . . . . . . 33
	7.3. IANA Considerations on New RADIUS TLVs . . . . . . . . . 33		7.3. IANA Considerations on New RADIUS TLVs . . . . . . . . . 34
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	9.1. Normative References . . . . . . . . . . . . . . . . . . 34		9.1. Normative References . . . . . . . . . . . . . . . . . . 34
	9.2. Informative References . . . . . . . . . . . . . . . . . 34		9.2. Informative References . . . . . . . . . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	In a broadband network, customer information is usually stored on a		In a broadband network, customer information is usually stored on a
	RADIUS server [RFC2865]. At the time when a user initiates an IP		RADIUS server [RFC2865]. At the time when a user initiates an IP
	connection request, if this request is authorized, the RADIUS server		connection request, if this request is authorized, the RADIUS server
	will populate the user's configuration information to the Network		will populate the user's configuration information to the Network
	Access Server (NAS), which is often referred to as a Broadband		Access Server (NAS), which is often referred to as a Broadband
	Network Gateway (BNG) in broadband access networks. The Carrier-		Network Gateway (BNG) in broadband access networks. The Carrier-
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 19 ¶
	o Internal Port: is a UDP or TCP port, or an ICMP identifier, which		o Internal Port: is a UDP or TCP port, or an ICMP identifier, which
	is allocated by a host or application behind a device supporting		is allocated by a host or application behind a device supporting
	port ranges for an outbound IP packet in the internal realm.		port ranges for an outbound IP packet in the internal realm.
	o External Port: is a UDP or TCP port, or an ICMP identifier, which		o External Port: is a UDP or TCP port, or an ICMP identifier, which
	is allocated by a device supporting port ranges upon receiving an		is allocated by a device supporting port ranges upon receiving an
	outbound IP packet in the internal realm, and is used to replace		outbound IP packet in the internal realm, and is used to replace
	the internal port that is allocated by a user or application.		the internal port that is allocated by a user or application.
	o External realm: refers to the networking segment where external IP		o External realm: refers to the networking segment where external IP
	addresses are used in respective of the device supporting port		addresses are used as source addresses of outbound packets
	ranges.		forwarded by a device supporting port ranges.
	o Internal realm: refers to the networking segment that is behind a		o Internal realm: refers to the networking segment that is behind a
	device supporting port ranges and where internal IP addresses are		device supporting port ranges and where internal IP addresses are
	used.		used.
	o Mapping: associates with a device supporting port ranges for a		o Mapping: associates with a device supporting port ranges for a
	relationship between an internal IP address, internal port and the		relationship between an internal IP address, internal port and the
	protocol, and an external IP address, external port, and the		protocol, and an external IP address, external port, and the
	protocol.		protocol.
	skipping to change at page 26, line 12 ¶		skipping to change at page 26, line 12 ¶
	Figure 16: RADIUS Message Flow for changing a user's NAT44 port limit		Figure 16: RADIUS Message Flow for changing a user's NAT44 port limit
	4.1.2. Report IP Port Allocation/Deallocation		4.1.2. Report IP Port Allocation/Deallocation
	Upon obtaining the IP port limit for a user, the CGN device needs to		Upon obtaining the IP port limit for a user, the CGN device needs to
	allocate a TCP/UDP port or an ICMP identifiers for the user when		allocate a TCP/UDP port or an ICMP identifiers for the user when
	receiving a new IP flow sent from that user.		receiving a new IP flow sent from that user.
	As one practice, a CGN may allocate a bulk of TCP/UDP ports or ICMP		As one practice, a CGN may allocate a bulk of TCP/UDP ports or ICMP
	identifiers once at a time for a specific user, instead of one port/		identifiers one at a time for a specific user, instead of one port/
	identifier at a time, and within each port bulk, the ports/		identifier at a time, and within each port bulk, the ports/
	identifiers may be randomly distributed or in consecutive fashion.		identifiers may be randomly distributed or in consecutive fashion.
	When a CGN device allocates bulk of TCP/UDP ports and ICMP		When a CGN device allocates bulk of TCP/UDP ports and ICMP
	identifiers, the information can be easily conveyed to the RADIUS		identifiers, the information can be easily conveyed to the RADIUS
	server by a new RADIUS attribute called the IP-Port-Range (defined in		server by a new RADIUS attribute called the IP-Port-Range (defined in
	Section 3.1.2). The CGN device may allocate one or more TCP/UDP port		Section 3.1.2). The CGN device may allocate one or more TCP/UDP port
	ranges or ICMP identifier ranges, or generally called IP port ranges,		ranges or ICMP identifier ranges, or generally called IP port ranges,
	where each range contains a set of numbers representing TCP/UDP ports		where each range contains a set of numbers representing TCP/UDP ports
	or ICMP identifiers, and the total number of ports/identifiers must		or ICMP identifiers, and the total number of ports/identifiers must
	be less or equal to the associated IP port limit imposed for that		be less or equal to the associated IP port limit imposed for that
	skipping to change at page 32, line 22 ¶		skipping to change at page 32, line 22 ¶
	0+ 0+ 0 0 0+ TBA IP-Port-Forwarding-Map		0+ 0+ 0 0 0+ TBA IP-Port-Forwarding-Map
	The following table defines the meaning of the above table entries.		The following table defines the meaning of the above table entries.
	0 This attribute MUST NOT be present in packet.		0 This attribute MUST NOT be present in packet.
	0+ Zero or more instances of this attribute MAY be present in packet.		0+ Zero or more instances of this attribute MAY be present in packet.
	6. Security Considerations		6. Security Considerations
	This document does not introduce any security issue other than the		This document does not introduce any security issue other than the
	ones already identified in RADIUS [RFC2865].		ones already identified in RADIUS [RFC2865] and [RFC5176] for CoA
			messages. Known RADIUS vulnerabilities apply to this specification.
			For example, if RADIUS packets are sent in the clear, an attacker in
			the communication path between the RADIUS client and server may glean
			information that it will use to prevent a legitimate user to access
			the service by appropriately setting the maximum number of IP ports
			conveyed in an IP-Port-Limit-Info attribute, exhaust the port quota
			of a user by installing many mapping entries (IP-Port-Forwarding-Map
			attribute), prevent incoming traffic to be delivered to its
			legitimate destination by manipulating the mapping entries installed
			by means of an IP-Port-Forwarding-Map attribute, discover the IP
			address and port range assigned to a given user and which is reported
			in an IP-Port-Range attribute, etc. The root cause of these attack
			vectors is the communication between the RADIUS client and server.
			This document targets deployed where a trusted relationship is in
			place between the RADIUS client and server with communication
			optionally secured by IPsec or Transport Layer Security (TLS)
			[RFC6614].
	7. IANA Considerations		7. IANA Considerations
	This document requires new code point assignments for both IPFIX		This document requires new code point assignments for both IPFIX
	Information Elements and RADIUS attributes as explained in the		Information Elements and RADIUS attributes as explained in the
	following sub-sections.		following sub-sections.
	It is assumed that Extended-Type-1 "241" will be used for RADIUS		It is assumed that Extended-Type-1 "241" will be used for RADIUS
	attributes in Section 7.2.		attributes in Section 7.2.
	skipping to change at page 34, line 5 ¶		skipping to change at page 34, line 29 ¶
	IP-Port-Range-Start 9 see Section 3.2.9		IP-Port-Range-Start 9 see Section 3.2.9
	IP-Port-Range-End 10 see Section 3.2.10		IP-Port-Range-End 10 see Section 3.2.10
	IP-Port-Local-Id 11 see Section 3.2.11		IP-Port-Local-Id 11 see Section 3.2.11
	8. Acknowledgements		8. Acknowledgements
	Many thanks to Dan Wing, Roberta Maglione, Daniel Derksen, David		Many thanks to Dan Wing, Roberta Maglione, Daniel Derksen, David
	Thaler, Alan Dekok, Lionel Morand, and Peter Deacon for their useful		Thaler, Alan Dekok, Lionel Morand, and Peter Deacon for their useful
	comments and suggestions.		comments and suggestions.
	Special thanks to Lionel Morand for the Shepherd review.		Special thanks to Lionel Morand for the Shepherd review and to
			Kathleen Moriarty for the AD review.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities",		[IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities",
	<http://www.iana.org/assignments/ipfix/ipfix.xhtml>.		<http://www.iana.org/assignments/ipfix/ipfix.xhtml>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	skipping to change at page 35, line 31 ¶		skipping to change at page 36, line 5 ¶
	[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and		[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
	P. Roberts, "Issues with IP Address Sharing", RFC 6269,		P. Roberts, "Issues with IP Address Sharing", RFC 6269,
	DOI 10.17487/RFC6269, June 2011,		DOI 10.17487/RFC6269, June 2011,
	<http://www.rfc-editor.org/info/rfc6269>.		<http://www.rfc-editor.org/info/rfc6269>.
	[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-		[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
	Stack Lite Broadband Deployments Following IPv4		Stack Lite Broadband Deployments Following IPv4
	Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,		Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
	<http://www.rfc-editor.org/info/rfc6333>.		<http://www.rfc-editor.org/info/rfc6333>.
			[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
			"Transport Layer Security (TLS) Encryption for RADIUS",
			RFC 6614, DOI 10.17487/RFC6614, May 2012,
			<http://www.rfc-editor.org/info/rfc6614>.
	[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable		[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable
	Operation of Address Translators with Per-Interface		Operation of Address Translators with Per-Interface
	Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012,		Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012,
	<http://www.rfc-editor.org/info/rfc6619>.		<http://www.rfc-editor.org/info/rfc6619>.
	[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and		[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
	P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,		P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
	DOI 10.17487/RFC6887, April 2013,		DOI 10.17487/RFC6887, April 2013,
	<http://www.rfc-editor.org/info/rfc6887>.		<http://www.rfc-editor.org/info/rfc6887>.
End of changes. 13 change blocks.
	14 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/