draft-ietf-radext-bigger-packets-00.txt   draft-ietf-radext-bigger-packets-01.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft Painless Security Internet-Draft Painless Security
Updates: 6613, 6614 (if approved) April 25, 2014 Updates: 6613, 6614 (if approved) July 2, 2014
Intended status: Experimental Intended status: Experimental
Expires: October 27, 2014 Expires: January 3, 2015
Larger Packets for RADIUS over TCP Larger Packets for RADIUS over TCP
draft-ietf-radext-bigger-packets-00.txt draft-ietf-radext-bigger-packets-01.txt
Abstract Abstract
The RADIUS over TLS experiment described in RFC 6614 has opened The RADIUS over TLS experiment described in RFC 6614 has opened
RADIUS to new use cases where the 4096-octet maximum RADIUS packet RADIUS to new use cases where the 4096-octet maximum RADIUS packet
proves problematic. This specification extends the RADIUS over TCP proves problematic. This specification extends the RADIUS over TCP
experiment to permit larger RADIUS packets. This specification experiment to permit larger RADIUS packets. This specification
compliments other ongoing work to permit fragmentation of RADIUS compliments other ongoing work to permit fragmentation of RADIUS
authorization information. authorization information. This document registers a new RADIUS
code, an action which requires IESG approval.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). 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 October 27, 2014. This Internet-Draft will expire on January 3, 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 2, line 15 skipping to change at page 2, line 16
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Changes to Packet Processing . . . . . . . . . . . . . . . . 3 2. Changes to Packet Processing . . . . . . . . . . . . . . . . 3
2.1. Status-Server Considerations . . . . . . . . . . . . . . 3 2.1. Status-Server Considerations . . . . . . . . . . . . . . 3
3. Forward and backward Compatibility . . . . . . . . . . . . . 4 3. Forward and backward Compatibility . . . . . . . . . . . . . 4
3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 6 4. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 6
5. Response Length Attribute . . . . . . . . . . . . . . . 6 5. Response Length Attribute . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. References . . . . . . . . . . . . . . . . . . . . . . . 7 8.2. References . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The Remote Access Dial-In User Server (RADIUS) over TLS [RFC6614] The Remote Access Dial-In User Server (RADIUS) over TLS [RFC6614]
experiment provides strong confidentiality and integrity for RADIUS experiment provides strong confidentiality and integrity for RADIUS
[RFC2865]. This enhanced security has opened new opportunities for [RFC2865]. This enhanced security has opened new opportunities for
using RADIUS to convey additional authorization information. As an using RADIUS to convey additional authorization information. As an
example, [I-D.ietf-abfab-aaa-saml] describes a mechanism for using example, [I-D.ietf-abfab-aaa-saml] describes a mechanism for using
RADIUS to carry Security Assertion Markup Language (SAML) messages in RADIUS to carry Security Assertion Markup Language (SAML) messages in
skipping to change at page 2, line 51 skipping to change at page 3, line 4
One approach is to fragment a RADIUS message across multiple packets One approach is to fragment a RADIUS message across multiple packets
at the RADIUS layer.RADIUS Fragmentation at the RADIUS layer.RADIUS Fragmentation
[I-D.ietf-radext-radius-fragmentation] provides a mechanism to split [I-D.ietf-radext-radius-fragmentation] provides a mechanism to split
authorization information across multiple RADIUS messages. That authorization information across multiple RADIUS messages. That
mechanism is necessary in order to split authorization information mechanism is necessary in order to split authorization information
across existing unmodified proxies. across existing unmodified proxies.
However, there are some significant disadvantages to RADIUS However, there are some significant disadvantages to RADIUS
fragmentation. First, RADIUS is a lock-step protocol, and only one fragmentation. First, RADIUS is a lock-step protocol, and only one
fragment can be in transit at a time as part of a given request. fragment can be in transit at a time as part of a given request.
Also, there is no current mechanism to discover the path Maximum Also, there is no current mechanism to discover the path Maximum
Transmission Unit (MTU) across the entire path that the fragment will Transmission Unit (MTU) across the entire path that the fragment will
travel. As a result, fragmentation is likely both at the RADIUS travel. As a result, fragmentation is likely both at the RADIUS
layer and at the transport layer. When TCP is used, much better layer and at the transport layer. When TCP is used, much better
transport characteristics can be achieved by fragmentation only at transport characteristics can be achieved by fragmentation only at
the TCP layer. the TCP layer. This specification provides a mechanism to achieve
these better transport characteristics when TCP is used. As part of
this specification, a new RADIUS code is registered.
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Changes to Packet Processing 2. Changes to Packet Processing
The maximum length of a RADIUS message is increased from 4096 to The maximum length of a RADIUS message is increased from 4096 to
skipping to change at page 6, line 14 skipping to change at page 6, line 17
As discussed in Section 2.1, a client MAY send a Status-Server As discussed in Section 2.1, a client MAY send a Status-Server
message to discover whether an authentication or accounting server message to discover whether an authentication or accounting server
supports this specification. The client includes a Response-Length supports this specification. The client includes a Response-Length
attribute; this signals the server to include a Response-Length attribute; this signals the server to include a Response-Length
attribute indicating the maximum packet size the server can process. attribute indicating the maximum packet size the server can process.
In this one instance, Response-Length indicate the size of a request In this one instance, Response-Length indicate the size of a request
that can be processed rather than a response. that can be processed rather than a response.
4. Too Big Response 4. Too Big Response
Define a new RADIUS code indicating that a server has received a When a RADIUS server receives a request that is larger than can be
request that is larger than can be processed. Include mandatory processed, it generates a Too-Big response as follows:
attribute indicating the maximum size that is permitted.
The code is TBDCODE.
The identifier is the identifier from the request.
The Response-Length attribute MUST be included and its value is
the maximum size of request that will be processed.
No other attributes SHOULD be included. Additional attributes
MUST be ignored by the client.
Clients will not typically be able to adjust and resend requests when Clients will not typically be able to adjust and resend requests when
this error is received. In some cases the client can fall back to this error is received. In some cases the client can fall back to
RADIUS Fragmentation. In other cases this code will provide for RADIUS Fragmentation. In other cases this code will provide for
better client error reporting and will avoid retransmitting requests better client error reporting and will avoid retransmitting requests
guaranteed to fail. guaranteed to fail.
5. Response Length Attribute 5. Response Length Attribute
The following RADIUS attribute type values [RFC3575] are assigned. The following RADIUS attribute type values [RFC3575] are assigned.
skipping to change at page 6, line 35 skipping to change at page 7, line 4
The following RADIUS attribute type values [RFC3575] are assigned. The following RADIUS attribute type values [RFC3575] are assigned.
The assignment rules in section 10.3 of [RFC6929] are used. The assignment rules in section 10.3 of [RFC6929] are used.
+---------------------+---------------+-----------------------------+ +---------------------+---------------+-----------------------------+
| Name | Attribute | Description | | Name | Attribute | Description |
+---------------------+---------------+-----------------------------+ +---------------------+---------------+-----------------------------+
| Response-Length | TBD | 2-octet unsigned integer | | Response-Length | TBD | 2-octet unsigned integer |
| | | maximum response length | | | | maximum response length |
+---------------------+---------------+-----------------------------+ +---------------------+---------------+-----------------------------+
The Response-Length attribute MAY be included in any RADIUS request. The Response-Length attribute MAY be included in any RADIUS request.
In this context it indicates the maximum length of a response the In this context it indicates the maximum length of a response the
client is prepared to receive. Values are between 4096 and 65535. client is prepared to receive. Values are between 4096 and 65535.
The attribute MAY also be included in a response to a Status-Server The attribute MAY also be included in a response to a Status-Server
message. In this case the attribute indicate the maximum size RADIUS message. In this case the attribute indicate the maximum size RADIUS
request that is permitted. request that is permitted.
6. IANA Considerations 6. IANA Considerations
Once this document is more complete it will define a new RADIUS code A new RADIUS packet type code is registered in the RADIUS packet type
and attribute. Figure out if we have IANA policy lossage defining a codes registry discussed in section 2.1 of RFC 3575 [RFC3575]. The
code in an experimental document. name is "Too-Big" and the code is TBDCODE. The IESG is requested to
approve this registration along with approving publication of this
document.
IANA is requested to assign the RADIUS type defined in section IANA is requested to assign the RADIUS type defined in section
Section 5 Section 5
7. Security Considerations 7. Security Considerations
This specification updates RFC 6613 and will be used with [RFC6614]. This specification updates RFC 6613 and will be used with [RFC6614].
When used over plain TCP, this specification creates new When used over plain TCP, this specification creates new
opportunities for an on-path attacker to impact availability. these opportunities for an on-path attacker to impact availability. these
attacks can be entirely mitigated by using TLS. attacks can be entirely mitigated by using TLS.
 End of changes. 13 change blocks. 
16 lines changed or deleted 30 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/