draft-ietf-radext-tcp-transport-06.txt		draft-ietf-radext-tcp-transport-07.txt
	Network Working Group A. DeKok		Network Working Group A. DeKok
	INTERNET-DRAFT FreeRADIUS		INTERNET-DRAFT FreeRADIUS
	Category: Experimental		Category: Experimental
	<draft-ietf-radext-tcp-transport-06.txt>		<draft-ietf-radext-tcp-transport-07.txt>
	Expires: November 27, 2010		Expires: November 20, 2010
	27 April 2010		20 May 2010
	RADIUS Over TCP		RADIUS Over TCP
	draft-ietf-radext-tcp-transport-06		draft-ietf-radext-tcp-transport-07
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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 Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 November 27, 2010		This Internet-Draft will expire on November 20, 2010
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 12		skipping to change at page 2, line 12
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Abstract		Abstract
	The Remote Authentication Dial In User Server (RADIUS) Protocol has		The Remote Authentication Dial In User Server (RADIUS) Protocol has
	traditionally used the User Datagram Protocol (UDP) as its underlying		traditionally used the User Datagram Protocol (UDP) as its underlying
	transport layer. This document defines RADIUS over the Transmission		transport layer. This document defines RADIUS over the Transmission
	Control Protocol (TCP), in order to address handling issues related		Control Protocol (TCP), in order to address handling issues related
	to RADIUS over Transport Layer Security [RTLS]. It is not intended		to RADIUS over Transport Layer Security [RTLS]. It is not intended
	to define TCP as a transport protocol for RADIUS in the absence of		to define TCP as a transport protocol for RADIUS in the absence of a
	TLS.		secure transport layer.
	Table of Contents		Table of Contents
	1. Introduction ............................................. 4		1. Introduction ............................................. 4
	1.1. Applicability of Reliable Transport ................. 5		1.1. Applicability of Reliable Transport ................. 5
	1.2. Terminology ......................................... 6		1.2. Terminology ......................................... 7
	1.3. Requirements Language ............................... 7		1.3. Requirements Language ............................... 7
	2. Changes to RADIUS ........................................ 7		2. Changes to RADIUS ........................................ 7
	2.1. Packet Format ....................................... 7		2.1. Packet Format ....................................... 7
	2.2. Assigned Ports for RADIUS Over TCP .................. 8		2.2. Assigned Ports for RADIUS Over TCP .................. 8
	2.3. Management Information Base (MIB) ................... 8		2.3. Management Information Base (MIB) ................... 9
	2.4. Detecting Live Servers .............................. 9		2.4. Detecting Live Servers .............................. 9
	2.5. Congestion Control Issues ........................... 9		2.5. Congestion Control Issues ........................... 10
	2.6. TCP Specific Issues ................................. 10		2.6. TCP Specific Issues ................................. 10
	2.6.1. Duplicates and Retransmissions ................. 11		2.6.1. Duplicates and Retransmissions ................. 11
	2.6.2. Head of Line Blocking .......................... 12		2.6.2. Head of Line Blocking .......................... 12
	2.6.3. Shared Secrets ................................. 12		2.6.3. Shared Secrets ................................. 12
	2.6.4. Malformed Packets and Unknown Clients .......... 12		2.6.4. Malformed Packets and Unknown Clients .......... 12
	2.6.5. Limitations of the ID Field .................... 13		2.6.5. Limitations of the ID Field .................... 13
	2.6.6. EAP Sessions ................................... 14		2.6.6. EAP Sessions ................................... 14
	2.6.7. TCP Applications are not UDP Applications ...... 14		2.6.7. TCP Applications are not UDP Applications ...... 14
	3. Diameter Considerations .................................. 15		3. Diameter Considerations .................................. 15
	4. IANA Considerations ...................................... 15		4. IANA Considerations ...................................... 15
	5. Security Considerations .................................. 15		5. Security Considerations .................................. 15
	6. References ............................................... 15		6. References ............................................... 15
	6.1. Normative References ................................ 15		6.1. Normative References ................................ 15
	6.2. Informative References .............................. 15		6.2. Informative References .............................. 16
	1. Introduction		1. Introduction
	The RADIUS Protocol has been defined in [RFC2865] as using the User		The RADIUS Protocol has been defined in [RFC2865] as using the User
	Datagram Protocol (UDP) for the underlying transport layer. While		Datagram Protocol (UDP) for the underlying transport layer. While
	there are a number of benefits to using UDP as outlined in [RFC2865]		there are a number of benefits to using UDP as outlined in [RFC2865]
	Section 2.4, there are also some limitations:		Section 2.4, there are also some limitations:
	* Unreliable transport. As a result, systems using RADIUS have to		* Unreliable transport. As a result, systems using RADIUS have to
	implement application-layer timers and re-transmissions, as		implement application-layer timers and re-transmissions, as
	skipping to change at page 4, line 31		skipping to change at page 4, line 31
	poorly tested code path on network devices. Some devices appear		poorly tested code path on network devices. Some devices appear
	to be incapable of transporting fragmented UDP packets, making it		to be incapable of transporting fragmented UDP packets, making it
	difficult to deploy RADIUS in a network where those devices are		difficult to deploy RADIUS in a network where those devices are
	deployed.		deployed.
	* Connectionless transport. Neither clients nor servers receive		* Connectionless transport. Neither clients nor servers receive
	positive statements that a "connection" is down. This information		positive statements that a "connection" is down. This information
	has to be deduced instead from the absence of a reply to a		has to be deduced instead from the absence of a reply to a
	request.		request.
			* Lack of congestion control. Clients can send arbitrary amounts
			of traffic with little or no feedback. This lack of feedback can
			result in congestive collapse of the network.
	As RADIUS is widely deployed, and has been widely deployed for well		As RADIUS is widely deployed, and has been widely deployed for well
	over a decade, these issues have been minor in some use-cases, and		over a decade, these issues have been minor in some use-cases, and
	problematic in others. For use-cases such as inter-server proxying,		problematic in others. For use-cases such as inter-server proxying,
	[RTLS] suggests an alternative transport and security model -- RADIUS		[RTLS] suggests an alternative transport and security model -- RADIUS
	over TLS. That document describes the transport implications of		over TLS. That document describes the transport implications of
	running RADIUS over TLS.		running RADIUS over TLS.
			The choice of TCP as a transport protocol is largely driven by the
			desire to improve the security of RADIUS by using RADIUS over TLS.
			For practical reasons, the transport protocol (TCP) is defined
			separately from the security mechanism (TLS).
	Since "bare" TCP does not provide for confidentiality or enable		Since "bare" TCP does not provide for confidentiality or enable
	negotiation of credible ciphersuites, its use is not appropriate for		negotiation of credible ciphersuites, its use is not appropriate for
	inter-server communications where strong security is required. As a		inter-server communications where strong security is required. As a
	result the use of "bare" TCP transport (i.e., without additional		result "bare" TCP transport MUST NOT be used without TLS, IPsec, or
	confidentiality and security) is NOT RECOMMENDED, as there has been		other secure upper layer.
	little or no operational experience with it.
	"Bare" TCP transport MAY, however, be used when another method such		"Bare" TCP transport MAY, however, be used when another method such
	as IPSec [RFC4301] is used to provide additional confidentiality and		as IPSec [RFC4301] is used to provide additional confidentiality and
	security. Should experience show that such deployments are useful,		security. Should experience show that such deployments are useful,
	this specification could be moved to standards track.		this specification could be moved to standards track.
	1.1. Applicability of Reliable Transport		1.1. Applicability of Reliable Transport
	The intent of this document is to address transport issues related to		The intent of this document is to address transport issues related to
	RADIUS over TLS [RTLS] in inter-server communications scenarios, such		RADIUS over TLS [RTLS] in inter-server communications scenarios, such
	as inter-domain communication between proxies. These situations		as inter-domain communication between proxies. These situations
	benefit from the confidentiality and ciphersuite negotiation that can		benefit from the confidentiality and ciphersuite negotiation that can
	be provided by TLS. Since TLS is already widely available within the		be provided by TLS. Since TLS is already widely available within the
	operating systems used by proxies, implementation barriers are low.		operating systems used by proxies, implementation barriers are low.
	In scenarios where RADIUS proxies exchange a large volume of packets		In scenarios where RADIUS proxies exchange a large volume of packets,
	(10+ packets per second), it is likely that there will be sufficient		it is likely that there will be sufficient traffic to enable the
	traffic to enable the congestion window to be widened beyond the		congestion window to be widened beyond the minimum value on a long-
	minimum value on a long-term basis, enabling ACK piggy-backing.		term basis, enabling ACK piggy-backing. Through use of an
	Through use of an application-layer watchdog as described in		application-layer watchdog as described in [RFC3539], it is possible
	[RFC3539], it is possible to address the objections to reliable		to address the objections to reliable transport described in
	transport described in [RFC2865] Section 2.4 without substantial		[RFC2865] Section 2.4 without substantial watchdog traffic, since
	watchdog traffic, since regular traffic is expected in both		regular traffic is expected in both directions.
	directions.
	In addition, use of RADIUS over TLS has been found to improve		In addition, use of RADIUS over TLS has been found to improve
	operational performance when used with multi-round trip		operational performance when used with multi-round trip
	authentication mechanisms such as RADIUS over EAP [RFC3579]. In such		authentication mechanisms such as RADIUS over EAP [RFC3579]. In such
	exchanges, it is typical for EAP fragmentation to increase the number		exchanges, it is typical for EAP fragmentation to increase the number
	of round-trips required. For example, where EAP-TLS authentication		of round-trips required. For example, where EAP-TLS authentication
	[RFC5216] is attempted and both the EAP peer and server utilize		[RFC5216] is attempted and both the EAP peer and server utilize
	certificate chains of 8KB, as many as 15 round-trips can be required		certificate chains of 8KB, as many as 15 round-trips can be required
	if RADIUS packets are restricted to the common Ethernet MTU (1500		if RADIUS packets are restricted to the common Ethernet MTU (1500
	octets) for EAP over LAN (EAPoL) use-cases. Fragmentation of RADIUS		octets) for EAP over LAN (EAPoL) use-cases. Fragmentation of RADIUS
	skipping to change at page 5, line 45		skipping to change at page 5, line 49
	routers, firewalls and NATs. However, since RADIUS over UDP		routers, firewalls and NATs. However, since RADIUS over UDP
	implementations typically do not support MTU discovery, fragmentation		implementations typically do not support MTU discovery, fragmentation
	can occur even when the maximum RADIUS over UDP packet size is		can occur even when the maximum RADIUS over UDP packet size is
	restricted to 1500 octets.		restricted to 1500 octets.
	These problems disappear if a 4096 application-layer payload can be		These problems disappear if a 4096 application-layer payload can be
	used alongside RADIUS over TLS. Since most TCP implementations		used alongside RADIUS over TLS. Since most TCP implementations
	support MTU discovery, the TCP MSS is automatically adjusted to		support MTU discovery, the TCP MSS is automatically adjusted to
	account for the MTU, and the larger congestion window supported by		account for the MTU, and the larger congestion window supported by
	TCP may allow multiple TCP segments to be sent within a single		TCP may allow multiple TCP segments to be sent within a single
	window.		window. Even those few TCP stacks which do not perform path MTU
			discovery can already support arbitrary payloads.
	Where the MTU for EAP packets is large, RADIUS/EAP traffic required		Where the MTU for EAP packets is large, RADIUS/EAP traffic required
	for an EAP-TLS authentication with 8KB certificate chains may be		for an EAP-TLS authentication with 8KB certificate chains may be
	reduced to 7 round-trips or less, resulting in substantially reduced		reduced to 7 round-trips or less, resulting in substantially reduced
	authentication times.		authentication times.
	In addition, experience indicates that EAP sessions transported over		In addition, experience indicates that EAP sessions transported over
	RTLS are less likely to abort unsuccessfully. Historically, RADIUS		RTLS are less likely to abort unsuccessfully. Historically, RADIUS
	over UDP implementations have exhibited poor retransmission behavior.		over UDP implementations have exhibited poor retransmission behavior.
	Some implementations retransmit packets, others do not, and others		Some implementations retransmit packets, others do not, and others
	skipping to change at page 11, line 44		skipping to change at page 12, line 5
	supposed to be sent by the proxy back over that connection to the		supposed to be sent by the proxy back over that connection to the
	client. Since the client connection is closed, those responses from		client. Since the client connection is closed, those responses from
	the home server to the proxy server SHOULD be silently discarded by		the home server to the proxy server SHOULD be silently discarded by
	the proxy.		the proxy.
	Despite the above discussion, RADIUS servers SHOULD still perform		Despite the above discussion, RADIUS servers SHOULD still perform
	duplicate detection on received packets, as described in [RFC5080]		duplicate detection on received packets, as described in [RFC5080]
	Section 2.2.2. This detection can prevent duplicate processing of		Section 2.2.2. This detection can prevent duplicate processing of
	packets from non-conformant clients.		packets from non-conformant clients.
	As noted previously, RADIUS packets SHOULD NOT be re-transmitted to		RADIUS packets SHOULD NOT be re-transmitted to the same destination
	the same destination IP and numerical port, but over a different		IP and numerical port, but over a different transport protocol.
	transport layer. There is no guarantee in RADIUS that the two ports		There is no guarantee in RADIUS that the two ports are in any way
	are in any way related. This requirement does not, however, forbid		related. This requirement does not, however, forbid the practice of
	the practice of putting multiple servers into a fail-over or load-		putting multiple servers into a fail-over or load-balancing pool. In
	balancing pool. In that situation, RADIUS request MAY be		that situation, RADIUS request MAY be retransmitted to another server
	retransmitted to another server that known to be part of the same		that known to be part of the same pool.
	pool.
	2.6.2. Head of Line Blocking		2.6.2. Head of Line Blocking
	When using UDP as a transport for RADIUS, there is no ordering of		When using UDP as a transport for RADIUS, there is no ordering of
	packets. If a packet sent by a client is lost, that loss has no		packets. If a packet sent by a client is lost, that loss has no
	effect on subsequent packets sent by that client.		effect on subsequent packets sent by that client.
	Unlike UDP, TLS is subject to issues related to Head of Line (HoL)		Unlike UDP, TCP is subject to issues related to Head of Line (HoL)
	blocking. This occurs when when a TLS segment is lost and a		blocking. This occurs when when a TCP segment is lost and a
	subsequent TLS segment arrives out of order. While the RADIUS server		subsequent TCP segment arrives out of order. While the RADIUS server
	can process RADIUS packets out of order, the semantics of TLS makes		can process RADIUS packets out of order, the semantics of TCP makes
	this impossible. This limitation can lower the maximum packet		this impossible. This limitation can lower the maximum packet
	processing rate of RADIUS over TLS.		processing rate of RADIUS over TCP.
	2.6.3. Shared Secrets		2.6.3. Shared Secrets
	The use of TLS transport does not change the calculation of security-		The use of TLS transport does not change the calculation of security-
	related fields (such as the Response-Authenticator) in RADIUS		related fields (such as the Response-Authenticator) in RADIUS
	[RFC2865] or RADIUS Dynamic Authorization [RFC5176]. Calculation of		[RFC2865] or RADIUS Dynamic Authorization [RFC5176]. Calculation of
	attributes such as User-Password [RFC2865] or Message-Authenticator		attributes such as User-Password [RFC2865] or Message-Authenticator
	[RFC3579] also does not change.		[RFC3579] also does not change.
	Clients and servers MUST be able to store and manage shared secrets		Clients and servers MUST be able to store and manage shared secrets
	skipping to change at page 15, line 28		skipping to change at page 15, line 31
	As the RADIUS packet format, signing, and client verification are		As the RADIUS packet format, signing, and client verification are
	unchanged from prior specifications, all of the security issues		unchanged from prior specifications, all of the security issues
	outlined in previous specifications for RADIUS over UDP are also		outlined in previous specifications for RADIUS over UDP are also
	applicable here.		applicable here.
	As noted above, clients and servers SHOULD support configurable		As noted above, clients and servers SHOULD support configurable
	connection limits. Allowing an unlimited number of connections may		connection limits. Allowing an unlimited number of connections may
	result in resource exhaustion.		result in resource exhaustion.
			Implementors should consult [RTLS] for issues related the security of
			RADIUS over TLS, and [RFC5246] for issues related to the security of
			the TLS protocol.
			Since "bare" TCP does not provide for confidentiality or enable
			negotiation of credible ciphersuites, its use is not appropriate for
			inter-server communications where strong security is required. As a
			result "bare" TCP transport MUST NOT be used without TLS, IPsec, or
			other secure upper layer.
	There are no (at this time) other known security issues for RADIUS		There are no (at this time) other known security issues for RADIUS
	over TCP transport.		over TCP transport.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote		[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
	Authentication Dial In User Service (RADIUS)", RFC 2865, June		Authentication Dial In User Service (RADIUS)", RFC 2865, June
	2000.		2000.
	[RFC3539] Aboba, B. et al., "Authentication, Authorization and		[RFC3539] Aboba, B. et al., "Authentication, Authorization and
	Accounting (AAA) Transport Profile", RFC 3539, June 2003.		Accounting (AAA) Transport Profile", RFC 3539, June 2003.
			[RTLS] Winter, S. et. al., "TLS encryption for RADIUS over TCP
			(RadSec)", draft-ietf-radext-radsec-06.txt, March 2010 (work
			in progress).
	6.2. Informative References		6.2. Informative References
	[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.		[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
	[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial		[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
	In User Service) Support For Extensible Authentication		In User Service) Support For Extensible Authentication
	Protocol (EAP)", RFC 3579, September 2003.		Protocol (EAP)", RFC 3579, September 2003.
	[RFC4301] Kent, S. and R. Atkinson, "Security Architecture for the		[RFC4301] Kent, S. and R. Atkinson, "Security Architecture for the
	Internet Protocol", RFC 4301, December, 2005.		Internet Protocol", RFC 4301, December, 2005.
	skipping to change at page 16, line 37		skipping to change at page 17, line 5
	User Service (RADIUS) Implementation Issues and Suggested		User Service (RADIUS) Implementation Issues and Suggested
	Fixes", RFC 5080, December 2007.		Fixes", RFC 5080, December 2007.
	[RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote		[RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote
	Authentication Dial In User Service (RADIUS)", RFC 5176,		Authentication Dial In User Service (RADIUS)", RFC 5176,
	January 2008.		January 2008.
	[RFC5216] Simon, D., etc al., "The EAP-TLS Authentication Protocol", RFC		[RFC5216] Simon, D., etc al., "The EAP-TLS Authentication Protocol", RFC
	5216, March 2008.		5216, March 2008.
			[RFC5246] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS)
			Protocol Version 1.2", RFC 5246, August 2008.
	[STATUS] DeKok, A., "Use of Status-Server Packets in the Remote		[STATUS] DeKok, A., "Use of Status-Server Packets in the Remote
	Authentication Dial In User Service (RADIUS) Protocol", draft-		Authentication Dial In User Service (RADIUS) Protocol", draft-
	ietf-radext-status-server-07.txt, April 2010 (work in		ietf-radext-status-server-08.txt, May 2010 (work in progress).
	progress).
	[RTLS] Winter, S. et. al., "TLS encryption for RADIUS over TCP
	(RadSec)", draft-ietf-radext-radsec-06.txt, March 2010 (work
	in progress).
	Acknowledgments		Acknowledgments
	None at this time.		None at this time.
	Authors' Addresses		Authors' Addresses
	Alan DeKok		Alan DeKok
	The FreeRADIUS Server Project		The FreeRADIUS Server Project
	http://freeradius.org/		http://freeradius.org/
End of changes. 20 change blocks.
	43 lines changed or deleted		62 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/