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/