draft-ietf-radext-radius-fragmentation-03.txt		draft-ietf-radext-radius-fragmentation-04.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: August 17, 2014 University of Murcia		Expires: September 2, 2014 University of Murcia
	D. Lopez		D. Lopez
	Telefonica I+D		Telefonica I+D
	A. DeKok		A. DeKok
	Network RADIUS		Network RADIUS
	February 13, 2014		March 2014
	Support of fragmentation of RADIUS packets		Support of fragmentation of RADIUS packets
	draft-ietf-radext-radius-fragmentation-03		draft-ietf-radext-radius-fragmentation-04
	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 August 17, 2014.		This Internet-Draft will expire on September 2, 2014.
	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 2, line 31		skipping to change at page 2, line 31
	4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 8		4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 8
	4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 9		4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 9
	4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 13		4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 13
	5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 16		5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6. Allowed large packet size . . . . . . . . . . . . . . . . . . 17		6. Allowed large packet size . . . . . . . . . . . . . . . . . . 17
	7. Handling special attributes . . . . . . . . . . . . . . . . . 18		7. Handling special attributes . . . . . . . . . . . . . . . . . 18
	7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 18		7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 18
	7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 19		7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 19
	7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 20		7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 20
	7.4. Rebuilding the original large packet . . . . . . . . . . . 20		7.4. Rebuilding the original large packet . . . . . . . . . . . 20
	8. New RFC6929 Reserved flag definition . . . . . . . . . . . . . 20		8. New flag T field for the Long Extended Type attribute
			definition . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9. New attribute definition . . . . . . . . . . . . . . . . . . . 21		9. New attribute definition . . . . . . . . . . . . . . . . . . . 21
	9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 21		9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 21
	9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 22		9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 22
	9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 23		9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 23
	10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23		10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23
	10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23		10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23
	10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 24		10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 24
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 25		11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	skipping to change at page 10, line 24		skipping to change at page 10, line 24
	Example-Long-1 [M]		Example-Long-1 [M]
	Example-Long-1 [M]		Example-Long-1 [M]
	Example-Long-1 [MT]		Example-Long-1 [MT]
	Frag-Status = More-Data-Pending		Frag-Status = More-Data-Pending
	Service-Type = Additional-Authorization		Service-Type = Additional-Authorization
	Message-Authenticator		Message-Authenticator
	Figure 2: Access-Request (chunk 1)		Figure 2: Access-Request (chunk 1)
	Compliant servers (i.e. servers implementing fragmentation) receiving		Compliant servers (i.e. servers implementing fragmentation) receiving
	this packet will see the Frag-Status attribute, and suspend all		this packet will see the Frag-Status attribute, and postpone all
	authorization and authentication handling until all of the chunks		authorization and authentication handling until all of the chunks
	have been received. Non-compliant servers (i.e. servers not		have been received. This postponement also affects to the
	implementing fragmentation) should also see the Service-Type		verification that the Access-Request packet contains some kind of
	requesting provisioning for an unknown service, and return Access-		authentication attribute (e.g. User-Password, CHAP-Password, State
	Reject. Other non-compliant servers may return an Access-Reject,		or other future attribute), as required by [RFC2865]. This checking
	Access-Challenge, or an Access-Accept with a particular Service-Type		will therefore be delayed until the original large packet has been
	other then Additional-Authorization. Compliant NAS implementations		rebuilt, as some of the chunks may not contain any of them.
	MUST treat these responses as if they had received Access-Reject
	instead.		Non-compliant servers (i.e. servers not implementing fragmentation)
			should also see the Service-Type requesting provisioning for an
			unknown service, and return Access-Reject. Other non-compliant
			servers may return an Access-Reject, Access-Challenge, or an Access-
			Accept with a particular Service-Type other then Additional-
			Authorization. Compliant NAS implementations MUST treat these
			responses as if they had received Access-Reject instead.
	Compliant servers who wish to receive all of the chunks will respond		Compliant servers who wish to receive all of the chunks will respond
	with the following packet. The value of the State here is arbitrary,		with the following packet. The value of the State here is arbitrary,
	and serves only as a unique token for example purposes. We only note		and serves only as a unique token for example purposes. We only note
	that it MUST be temporally unique to the server.		that it MUST be temporally unique to the server.
	Access-Accept (ID = 23)		Access-Accept (ID = 23)
	Frag-Status = More-Data-Request		Frag-Status = More-Data-Request
	Service-Type = Additional-Authorization		Service-Type = Additional-Authorization
	State = 0xabc00001		State = 0xabc00001
	skipping to change at page 20, line 44		skipping to change at page 20, line 44
	o State (except the one in the first chunk, if present)		o State (except the one in the first chunk, if present)
	o Service-Type = Additional-Authorization		o Service-Type = Additional-Authorization
	o Frag-Status		o Frag-Status
	o Proxy-State (except the ones in the last chunk)		o Proxy-State (except the ones in the last chunk)
	o User-Name (except the one in the first chunk)		o User-Name (except the one in the first chunk)
	8. New RFC6929 Reserved flag definition		8. New flag T field for the Long Extended Type attribute definition
	This document defines a new field in the Reserved field of the "Long		This document defines a new field in the "Long Extended Type"
	Extended Type" attribute format. This field is one bit in size, and		attribute format. This field is one bit in size, and is called "T"
	is called "T" for Truncation. It indicates that the attribute is		for Truncation. It indicates that the attribute is intentionally
	intentionally truncated in this chunk, and is to be continued in the		truncated in this chunk, and is to be continued in the next chunk of
	next chunk of the sequence. The combination of the flags "M" and "T"		the sequence. The combination of the flags "M" and "T" indicates
	indicates that the attribute is fragmented (flag M), but that all the		that the attribute is fragmented (flag M), but that all the fragments
	fragments are not available in this chunk (flag T). Proxies		are not available in this chunk (flag T). Proxies implementing
	implementing [RFC6929] will see these attributes as invalid (they		[RFC6929] will see these attributes as invalid (they will not be able
	will not be able to reconstruct them), but they will still forward		to reconstruct them), but they will still forward them as [RFC6929]
	them as [RFC6929] section 5.2 indicates they SHOULD forward unknown		section 5.2 indicates they SHOULD forward unknown attributes anyway.
	attributes anyway.
			As a consequence of this addition, the Reserved field is now 6 bits
			long. The following figure represents the new attribute format.
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length | Extended-Type |M|T| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Value ...
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 12: Updated Long Extended Type attribute format
	9. New attribute definition		9. New attribute definition
	This document proposes the definition of two new extended type		This document proposes the definition of two new extended type
	attributes, called Frag-Status and Proxy-State-Len. The format of		attributes, called Frag-Status and Proxy-State-Len. The format of
	these attributes follows the indications for an Extended Type		these attributes follows the indications for an Extended Type
	attribute defined in [RFC6929].		attribute defined in [RFC6929].
	9.1. Frag-Status attribute		9.1. Frag-Status attribute
	skipping to change at page 21, line 31		skipping to change at page 21, line 43
	figure represents the format of the Frag-Status attribute.		figure represents the format of the Frag-Status attribute.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Extended-Type | Code		| Type | Length | Extended-Type | Code
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Code (cont) |		Code (cont) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 12: Frag-Status format		Figure 13: Frag-Status format
	Type		Type
	To be assigned (TBA)		To be assigned (TBA)
	Length		Length
	7		7
	Extended-Type		Extended-Type
	To be assigned (TBA).		To be assigned (TBA).
	Code		Code
	4 byte. Integer indicating the code. The values defined in this		4 byte. Integer indicating the code. The values defined in this
	specifications are:		specifications are:
	skipping to change at page 22, line 36		skipping to change at page 22, line 46
	following:		following:
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Extended-Type | Value		| Type | Length | Extended-Type | Value
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Value (cont) |		Value (cont) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 13: Proxy-State-Len format		Figure 14: Proxy-State-Len format
	Type		Type
	To be assigned (TBA)		To be assigned (TBA)
	Length		Length
	7		7
	Extended-Type		Extended-Type
	skipping to change at page 23, line 26		skipping to change at page 23, line 37
	| Kind of packet |		| Kind of packet |
	+-----+-----+-----+-----+		+-----+-----+-----+-----+
	Attribute Name | Req | Acc | Rej | Cha |		Attribute Name | Req | Acc | Rej | Cha |
	----------------------+-----+-----+-----+-----+		----------------------+-----+-----+-----+-----+
	Frag-Status | 0-1 | 0-1 | 0 | 0-1 |		Frag-Status | 0-1 | 0-1 | 0 | 0-1 |
	----------------------+-----+-----+-----+-----+		----------------------+-----+-----+-----+-----+
	Proxy-State-Len | 0 | 0-1 | 0 | 0-1 |		Proxy-State-Len | 0 | 0-1 | 0 | 0-1 |
	----------------------+-----+-----+-----+-----+		----------------------+-----+-----+-----+-----+
	Figure 14		Figure 15
	10. Operation with proxies		10. Operation with proxies
	The fragmentation mechanism defined above is designed to be		The fragmentation mechanism defined above is designed to be
	transparent to legacy proxies, as long as they do not want to modify		transparent to legacy proxies, as long as they do not want to modify
	any fragmented attribute. Nevertheless, updated proxies supporting		any fragmented attribute. Nevertheless, updated proxies supporting
	this specification can even modify fragmented attributes.		this specification can even modify fragmented attributes.
	10.1. Legacy proxies		10.1. Legacy proxies
	skipping to change at page 24, line 41		skipping to change at page 24, line 50
	|<---------------------------------------------------|		|<---------------------------------------------------|
	| |		| |
	| Access-Request(2)(User-Name,State1, |		| Access-Request(2)(User-Name,State1, |
	| Example-Long-1[M],Example-Long-1[M], |		| Example-Long-1[M],Example-Long-1[M], |
	| Example-Long-1[M],Example-Long-1} |		| Example-Long-1[M],Example-Long-1} |
	|--------------------------------------------------->|		|--------------------------------------------------->|
	PROXY MODIFIES ATTRIBUTE Data INCREASING ITS		PROXY MODIFIES ATTRIBUTE Data INCREASING ITS
	SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS		SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS
	Figure 15: Updated proxy interacts with NAS		Figure 16: Updated proxy interacts with NAS
	+-+-+-+-+ +-+-+-+-+		+-+-+-+-+ +-+-+-+-+
	| Proxy | | AS |		| Proxy | | AS |
	+-+-+-+-+ +-+-+-+-+		+-+-+-+-+ +-+-+-+-+
	| |		| |
	| Access-Request(3){User-Name,Calling-Station-Id, |		| Access-Request(3){User-Name,Calling-Station-Id, |
	| Example-Long-1[M],Example-Long-1[M], |		| Example-Long-1[M],Example-Long-1[M], |
	| Example-Long-1[M],Example-Long-1[M], |		| Example-Long-1[M],Example-Long-1[M], |
	| Example-Long-1[MT],Frag-Status(MDP)} |		| Example-Long-1[MT],Frag-Status(MDP)} |
	|--------------------------------------------------->|		|--------------------------------------------------->|
	skipping to change at page 25, line 32		skipping to change at page 25, line 32
	| Example-Long-1[MT],Frag-Status(MDP)} |		| Example-Long-1[MT],Frag-Status(MDP)} |
	|--------------------------------------------------->|		|--------------------------------------------------->|
	| |		| |
	| Access-Challenge(1){User-Name, |		| Access-Challenge(1){User-Name, |
	| Frag-Status(MDR),State3} |		| Frag-Status(MDR),State3} |
	|<---------------------------------------------------|		|<---------------------------------------------------|
	| |		| |
	| Access-Request(5){User-Name,State3,Example-Long-1} |		| Access-Request(5){User-Name,State3,Example-Long-1} |
	|--------------------------------------------------->|		|--------------------------------------------------->|
	Figure 16: Updated proxy interacts with AS		Figure 17: Updated proxy interacts with AS
	11. Security Considerations		11. Security Considerations
	As noted in many earlier specifications ([RFC5080], [RFC6158], etc.)		As noted in many earlier specifications ([RFC5080], [RFC6158], etc.)
	RADIUS security is problematic. This specification changes nothing		RADIUS security is problematic. This specification changes nothing
	related to the security of the RADIUS protocol. It requires that all		related to the security of the RADIUS protocol. It requires that all
	Access-Request packets associated with fragmentation are		Access-Request packets associated with fragmentation are
	authenticated using the existing Message-Authenticator attribute.		authenticated using the existing Message-Authenticator attribute.
	This signature prevents forging and replay, to the limits of the		This signature prevents forging and replay, to the limits of the
	existing security.		existing security.
End of changes. 15 change blocks.
	32 lines changed or deleted		50 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/