draft-ietf-radext-radius-fragmentation-04.txt		draft-ietf-radext-radius-fragmentation-05.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: September 2, 2014 University of Murcia		Expires: September 8, 2014 University of Murcia
	D. Lopez		D. Lopez
	Telefonica I+D		Telefonica I+D
	A. DeKok		A. DeKok
	Network RADIUS		Network RADIUS
	March 2014		March 7, 2014
	Support of fragmentation of RADIUS packets		Support of fragmentation of RADIUS packets
	draft-ietf-radext-radius-fragmentation-04		draft-ietf-radext-radius-fragmentation-05
	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 September 2, 2014.		This Internet-Draft will expire on September 8, 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 10, line 31		skipping to change at page 10, line 31
	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 postpone 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. This postponement also affects to the		have been received. This postponement also affects to the
	verification that the Access-Request packet contains some kind of		verification that the Access-Request packet contains some kind of
	authentication attribute (e.g. User-Password, CHAP-Password, State		authentication attribute (e.g. User-Password, CHAP-Password, State
	or other future attribute), as required by [RFC2865]. This checking		or other future attribute), as required by [RFC2865]. This checking
	will therefore be delayed until the original large packet has been		will therefore be delayed until the original large packet has been
	rebuilt, as some of the chunks may not contain any of them.		rebuilt, as some of the chunks may not contain any of them. The
			authors acknowledge this is formally violating [RFC2865], but there
			are no known operational issues with it. Once this document goes
			beyond being considered as experimental, it will state it updates
			[RFC2865].
	Non-compliant servers (i.e. servers not implementing fragmentation)		Non-compliant servers (i.e. servers not implementing fragmentation)
	should also see the Service-Type requesting provisioning for an		should also see the Service-Type requesting provisioning for an
	unknown service, and return Access-Reject. Other non-compliant		unknown service, and return Access-Reject. Other non-compliant
	servers may return an Access-Reject, Access-Challenge, or an Access-		servers may return an Access-Reject, Access-Challenge, or an Access-
	Accept with a particular Service-Type other then Additional-		Accept with a particular Service-Type other then Additional-
	Authorization. Compliant NAS implementations MUST treat these		Authorization. Compliant NAS implementations MUST treat these
	responses as if they had received Access-Reject instead.		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
End of changes. 5 change blocks.
	5 lines changed or deleted		9 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/