draft-ietf-radext-radius-fragmentation-07.txt		draft-ietf-radext-radius-fragmentation-08.txt
	RADIUS EXTensions Working Group A. Perez-Mendez		RADIUS EXTensions Working Group A. Perez-Mendez
	Internet-Draft R. Marin-Lopez		Internet-Draft R. Marin-Lopez
	Updates: RFC6929 (if approved) F. Pereniguez-Garcia		Updates: RFC6929 (if approved) F. Pereniguez-Garcia
	Intended status: Experimental G. Lopez-Millan		Intended status: Experimental G. Lopez-Millan
	Expires: January 5, 2015 University of Murcia		Expires: April 6, 2015 University of Murcia
	D. Lopez		D. Lopez
	Telefonica I+D		Telefonica I+D
	A. DeKok		A. DeKok
	Network RADIUS		Network RADIUS
	July 4, 2014		October 3, 2014
	Support of fragmentation of RADIUS packets		Support of fragmentation of RADIUS packets
	draft-ietf-radext-radius-fragmentation-07		draft-ietf-radext-radius-fragmentation-08
	Abstract		Abstract
	The Remote Authentication Dial-In User Service (RADIUS) protocol is		The Remote Authentication Dial-In User Service (RADIUS) protocol is
	limited to a total packet size of 4096 octets. Provisions exist for		limited to a total packet size of 4096 octets. Provisions exist for
	fragmenting large amounts of authentication data across multiple		fragmenting large amounts of authentication data across multiple
	packets, via Access-Challenge. No similar provisions exist for		packets, via Access-Challenge. No similar provisions exist for
	fragmenting large amounts of authorization data. This document		fragmenting large amounts of authorization data. This document
	specifies how existing RADIUS mechanisms can be leveraged to provide		specifies how existing RADIUS mechanisms can be leveraged to provide
	that functionality. These mechanisms are largely compatible with		that functionality. These mechanisms are largely compatible with
	skipping to change at page 1, line 44		skipping to change at page 1, line 44
	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 January 5, 2015.		This Internet-Draft will expire on April 6, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 3, line 44		skipping to change at page 3, line 44
	[RFC6158] recommends three approaches for the transmission of large		[RFC6158] recommends three approaches for the transmission of large
	amount of data within RADIUS. However, they are not applicable to		amount of data within RADIUS. However, they are not applicable to
	the problem statement of this document for the following reasons:		the problem statement of this document for the following reasons:
	o The first approach does not talk about large amounts of data sent		o The first approach does not talk about large amounts of data sent
	from the NAS to a server. Leveraging EAP (request/challenge) to		from the NAS to a server. Leveraging EAP (request/challenge) to
	send the data is not feasible, as EAP already fills packet to		send the data is not feasible, as EAP already fills packet to
	PMTU, and not all authentications use EAP. Moreover, as noted for		PMTU, and not all authentications use EAP. Moreover, as noted for
	NAS-Filter-Rule ([RFC4849]), this approach does entirely solve the		NAS-Filter-Rule ([RFC4849]), this approach does entirely solve the
	problem of sending large amounts of data from a server to a NAS.		problem of sending large amounts of data from a server to a NAS,
			as many current RADIUS attributes are not permitted in an Access-
			Challenge packets.
	o The second approach is not usable either, as using names rather		o The second approach is not usable either, as using names rather
	than values is difficult when the nature of the data to be sent is		than values is difficult when the nature of the data to be sent is
	highly dynamic (e.g. SAML sentences or NAS-Filter-Rule		highly dynamic (e.g. SAML statement or NAS-Filter-Rule
	attributes). URLs could be used as a pointer to the location of		attributes). URLs could be used as a pointer to the location of
	the actual data, but their use would require them to be (a)		the actual data, but their use would require them to be (a)
	dynamically created and modified, (b) securely accessed and (c)		dynamically created and modified, (b) securely accessed and (c)
	accessible from remote systems. Satisfying these constraints		accessible from remote systems. Satisfying these constraints
	would require the modification of several networking systems (e.g.		would require the modification of several networking systems (e.g.
	firewalls and web servers). Furthermore, the set up of an		firewalls and web servers). Furthermore, the set up of an
	additional trust infrastructure (e.g. PKI) would be required to		additional trust infrastructure (e.g. PKI) would be required to
	allow secure retrieving of the information from the web server.		allow secure retrieving of the information from the web server.
	o PMTU discovery does not solve the problem, as it does not allow to		o PMTU discovery does not solve the problem, as it does not allow to
	skipping to change at page 9, line 48		skipping to change at page 9, line 48
	4. Fragmentation of packets		4. Fragmentation of packets
	When the NAS or the AS desires to send a packet that exceeds the size		When the NAS or the AS desires to send a packet that exceeds the size
	limit, it is split into chunks and sent via multiple client/server		limit, it is split into chunks and sent via multiple client/server
	exchanges. The exchange is indicated via the Frag-Status attribute,		exchanges. The exchange is indicated via the Frag-Status attribute,
	which has value More-Data-Pending for all but the last chunk of the		which has value More-Data-Pending for all but the last chunk of the
	series. The chunks are tied together via the State attribute.		series. The chunks are tied together via the State attribute.
	The delivery of a large fragmented RADIUS packet with authorization		The delivery of a large fragmented RADIUS packet with authorization
	data can happen before or after the end user has been authenticated		data can happen before or after the end user has been authenticated
	by the AS. We can distinguish two phases:		by the AS. We can distinguish two phases, which can be omitted if
			there is no authorization data to be sent:
	1. Pre-authorization. In this phase, the NAS can send a large		1. Pre-authorization. In this phase, the NAS MAY send a large
	packet with authorization information to the AS before the end		packet with authorization information to the AS before the end
	user is authenticated.		user is authenticated. Only the NAS is allowed to send
			authorization data during this phase.
	2. Post-authorization. In this phase, the AS can send a large		2. Post-authorization. In this phase, the AS MAY send a large
	packet with authorization data to the NAS after the end user has		packet with authorization data to the NAS after the end user has
	been authenticated.		been authenticated. Only the AS is allowed to send authorization
			data during this phase.
	The following subsections describe how to perform fragmentation for		The following subsections describe how to perform fragmentation for
	packets for these two phases, pre-authorization and post-		packets for these two phases, pre-authorization and post-
	authorization. We give the packet type, along with a RADIUS		authorization. We give the packet type, along with a RADIUS
	Identifier, to indicate that requests and responses are connected.		Identifier, to indicate that requests and responses are connected.
	We then give a list of attributes. We do not give values for most		We then give a list of attributes. We do not give values for most
	attributes, as we wish to concentrate on the fragmentation behaviour,		attributes, as we wish to concentrate on the fragmentation behaviour,
	rather than packet contents. Attribute values are given for		rather than packet contents. Attribute values are given for
	attributes relevant to the fragmentation process. Where "long		attributes relevant to the fragmentation process. Where "long
	extended" attributes are used, we indicate the M (More) and T		extended" attributes are used, we indicate the M (More) and T
	skipping to change at page 19, line 37		skipping to change at page 19, line 37
	According to [RFC6929], a Long-Extended-Type provides a payload of		According to [RFC6929], a Long-Extended-Type provides a payload of
	251 octets. Therefore, the SAML assertion described above would		251 octets. Therefore, the SAML assertion described above would
	result into 60 attributes, requiring of 4 round-trips to be		result into 60 attributes, requiring of 4 round-trips to be
	completely transmitted.		completely transmitted.
	7. Handling special attributes		7. Handling special attributes
	7.1. Proxy-State attribute		7.1. Proxy-State attribute
	RADIUS proxies may introduce Proxy-State attributes into any Access-		RADIUS proxies may introduce Proxy-State attributes into any Access-
	Request packet they forward. Should they are unable to add this		Request packet they forward. If they are unable to add this
	information to the packet, they may silently discard forwarding it to		information to the packet, they may silently discard forwarding it to
	its destination, leading to DoS situations. Moreover, any Proxy-		its destination, leading to DoS situations. Moreover, any Proxy-
	State attribute received by a RADIUS server in an Access-Request		State attribute received by a RADIUS server in an Access-Request
	packet MUST be copied into the reply packet to it. For these		packet MUST be copied into the reply packet to it. For these
	reasons, Proxy-State attributes require a special treatment within		reasons, Proxy-State attributes require a special treatment within
	the packet fragmentation mechanism.		the packet fragmentation mechanism.
	When the RADIUS server replies to an Access-Request packet as part of		When the RADIUS server replies to an Access-Request packet as part of
	a conversation involving a fragmentation (either a chunk or a request		a conversation involving a fragmentation (either a chunk or a request
	for chunks), it MUST include every Proxy-State attribute received		for chunks), it MUST include every Proxy-State attribute received
	skipping to change at page 29, line 43		skipping to change at page 29, line 43
	in this document be registered by the Internet Assigned Numbers		in this document be registered by the Internet Assigned Numbers
	Authority (IANA) from the RADIUS namespaces as described in the "IANA		Authority (IANA) from the RADIUS namespaces as described in the "IANA
	Considerations" section of [RFC3575], in accordance with BCP 26		Considerations" section of [RFC3575], in accordance with BCP 26
	[RFC5226]. For RADIUS packets, attributes and registries created by		[RFC5226]. For RADIUS packets, attributes and registries created by
	this document IANA is requested to place them at		this document IANA is requested to place them at
	http://www.iana.org/assignments/radius-types.		http://www.iana.org/assignments/radius-types.
	In particular, this document defines two new RADIUS attributes,		In particular, this document defines two new RADIUS attributes,
	entitled "Frag-Status" and "Proxy-State-Len" (see section 9),		entitled "Frag-Status" and "Proxy-State-Len" (see section 9),
	assigned values of TBD1 and TBD2 from the Long Extended Space of		assigned values of TBD1 and TBD2 from the Long Extended Space of
	[RFC2865]:		[RFC6929]:
	Tag Name Length Meaning		Tag Name Length Meaning
	---- ---- ------ -------		---- ---- ------ -------
	TBD1 Frag-Status 7 Signals fragmentation		TBD1 Frag-Status 7 Signals fragmentation
	TBD2 Proxy-State-Len 7 Indicates the length of the		TBD2 Proxy-State-Len 7 Indicates the length of the
	received Proxy-State attributes		received Proxy-State attributes
	The Frag-Status attribute also defines a 8-bit "Code" field, for		The Frag-Status attribute also defines a 8-bit "Code" field, for
	which the IANA is to create and maintain a new sub-registry entitled		which the IANA is to create and maintain a new sub-registry entitled
	"Code values" under the RADIUS "Frag-Status" attribute. Initial		"Code values" under the RADIUS "Frag-Status" attribute. Initial
End of changes. 13 change blocks.
	13 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/