Larger RADIUS Packets: Larger Packets for RADIUS over TCP
Lets RADIUS over TCP carry packets far bigger than the old 4096-octet limit, with a new error packet for when they are too big.
Hartman, S., "Larger Packets for RADIUS over TCP", RFC 7930, DOI 10.17487/RFC7930, August 2016, <https://www.rfc-editor.org/info/rfc7930>.
@misc{rfc7930,
series = {Request for Comments},
number = 7930,
howpublished = {RFC 7930},
publisher = {RFC Editor},
doi = {10.17487/RFC7930},
url = {https://www.rfc-editor.org/info/rfc7930},
author = {S. Hartman},
title = {{Larger Packets for RADIUS over TCP}},
pagetotal = 10,
year = 2016,
month = aug,
} RFC text
Contents
Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 7930 Painless Security
Updates: 6613 August 2016
Category: Experimental
ISSN: 2070-1721
Larger Packets for RADIUS over TCP
Abstract
The RADIUS-over-TLS experiment described in RFC 6614 has opened
RADIUS to new use cases where the 4096-octet maximum size limit of a
RADIUS packet proves problematic. This specification extends the
RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS
packets. This specification compliments other ongoing work to permit
fragmentation of RADIUS authorization information. This document
registers a new RADIUS code, an action that required IESG approval.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7930.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Changes to Packet Processing . . . . . . . . . . . . . . . . 4
2.1. Status-Server Considerations . . . . . . . . . . . . . . 4
3. Forward and Backward Compatibility . . . . . . . . . . . . . 5
3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol-Error Code . . . . . . . . . . . . . . . . . . . . . 7
5. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The experiment with Remote Authentication Dial-In User Service
(RADIUS) over Transport Layer Security (TLS) [RFC6614] provides
strong confidentiality and integrity for RADIUS [RFC2865]. This
enhanced security has opened new opportunities for using RADIUS to
convey additional authorization information. As an example,
[RFC7833] describes a mechanism for using RADIUS to carry Security
Assertion Markup Language (SAML) messages in RADIUS. Many attributes
carried in these SAML messages will require confidentiality or
integrity such as that provided by TLS.
These new use cases involve carrying additional information in RADIUS
packets. The maximum packet length of 4096 octets is proving
insufficient for some SAML messages and for other structures that may
be carried in RADIUS.
One approach is to fragment a RADIUS message across multiple packets
at the RADIUS layer. RADIUS fragmentation [RFC7499] provides a
mechanism to split authorization information across multiple RADIUS
messages. That mechanism is necessary in order to split
authorization information across existing unmodified proxies.
However, there are some significant disadvantages to RADIUS
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.
Also, there is no current mechanism to discover the Path Maximum
Transmission Unit (PMTU) across the entire path that the fragment
will travel. As a result, fragmentation is likely both at the RADIUS
layer and at the transport layer. When TCP is used, much better
transport characteristics can be achieved by fragmentation only at
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.
This specification is published as an Experimental specification
because the TCP extensions to RADIUS are currently experimental. The
need for this specification arises from operational experience with
the TCP extensions. However, this specification introduces no new
experimental evaluation criteria beyond those in the base TCP
specification; this specification can be evaluated along with that
one for advancement on the Standards Track.
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Changes to Packet Processing
The maximum length of a RADIUS message is increased from 4096 to
65535. A RADIUS Server implementing this specification MUST be able
to receive a RADIUS packet of maximum length. Servers MAY have a
maximum size over which they choose to return an error, as discussed
in Section 5, rather than processing a received packet; this size
MUST be at least 4096 octets.
Clients implementing this specification MUST be able to receive a
RADIUS packet of maximum length; that is, clients MUST NOT close a
TCP connection simply because a large packet is sent over it.
Clients MAY include the Response-Length attribute defined in
Section 6 to indicate the maximum size of a packet that they can
successfully process. Clients MAY silently discard a packet greater
than some configured size; this size MUST be at least 4096 octets.
Clients MUST NOT retransmit an unmodified request whose response is
larger than the client can process, as subsequent responses will
likely continue to be too large.
Proxies MUST be able to receive a RADIUS packet of maximum length
without closing the TCP connection. Proxies SHOULD be able to
process and forward packets of maximum length. When a proxy receives
a request over a transport with a 4096-octet maximum length and the
proxy forwards that request over a transport with a larger maximum
length, the proxy MUST include the Response-Length attribute with a
value of 4096.
2.1. Status-Server Considerations
This section extends processing of Status-Server messages as
described in Sections 4.1 and 4.2 of [RFC5997].
Clients implementing this specification SHOULD include the Response-
Length attribute in Status-Server requests. Servers are already
required to ignore unknown attributes received in this message. By
including the attribute, the client indicates how large of a response
it can process to its Status-Server request. It is very unlikely
that a response to Status-Server is greater than 4096 octets.
However, the client also indicates support for this specification,
which triggers the server behavior below.
If a server implementing this specification receives a Response-
Length attribute in a Status-Server request, it MUST include a
Response-Length attribute indicating the maximum size request it can
process in its response to the Status-Server request.
3. Forward and Backward Compatibility
An implementation of [RFC6613] will silently discard any RADIUS
packet larger than 4096 octets and will close the TCP connection.
This section provides guidelines for interoperability with these
implementations. These guidelines are stated at the SHOULD level.
In some environments, support for large packets will be important
enough that roaming or other agreements will mandate their support.
In these environments, all implementations might be required to
support this specification, thus removing the need for
interoperability with RFC 6613. It is likely that these guidelines
will be relaxed to the MAY level and support for this specification
made a requirement if RADIUS over TLS and TCP are moved to the
Standards Track in the future.
Clients SHOULD provide configuration for the maximum size of a
request sent to each server. Servers SHOULD provide configuration
for the maximum size of a response sent to each client. If dynamic
discovery mechanisms are supported, configuration SHOULD be provided
for the default maximum size of RADIUS packets sent to clients and
servers. If an implementation provides more granular configuration
for some classes of dynamic resources, then the implementation SHOULD
also provide configuration of default maximum packet sizes at the
same granularity. As an example, an implementation that provided
granular configuration for resources using a particular trust anchor
or belonging to a particular roaming consortium SHOULD provide
default packet size configuration at the same granularity.
If a client sends a request larger than 4096 octets and the TCP
connection is closed without a response, the client SHOULD treat the
request as if a "Request Too Big" error (Section 5) specifying a
maximum size of 4096 is received. Clients or proxies sending
multiple requests over a single TCP connection without waiting for
responses SHOULD implement capability discovery as discussed in
Section 3.2.
By default, a server SHOULD NOT generate a response larger than 4096
octets. The Response-Length attribute MAY be included in a request
to indicate that larger responses are acceptable. Other attributes
or configurations MAY be used as an indicator that large responses
are likely to be acceptable.
A proxy that implements both this specification and RADIUS
fragmentation [RFC7499] SHOULD use RADIUS fragmentation when the
following conditions are met:
1. A RADIUS packet is being forwarded towards a next hop whose
configuration does not support a packet that large.
2. RADIUS fragmentation can be used for the packet in question.
3.1. Rationale
The interoperability challenge appears at first significant. This
specification proposes to introduce behavior where new
implementations will fail to function with existing implementations.
However, these capabilities are introduced to support new use cases.
If an implementation has 10000 octets of attributes to send, it
cannot, in general, trim down the response to something that can be
sent. Under this specification, a large packet would be generated
that will be silently discarded by an existing implementation.
Without this specification, no packet is generated because the
required attributes cannot be sent.
The biggest risk to interoperability would be if requests and
responses are expanded to include additional information that is not
strictly necessary. So, avoiding creating situations where large
packets are sent to existing implementations is mostly an operational
matter. Interoperability is most impacted when the size of packets
in existing use cases is significantly increased and least impacted
when large packets are used for new use cases where the deployment is
likely to require updated RADIUS implementations.
There is a special challenge for proxies or clients with a high
request volume. When an implementation of RFC 6613 receives a packet
that is too large, it closes the connection and does not respond to
any requests in process. Such a client would lose requests and might
find it difficult to distinguish "Request Too Big" situations from
other failures. In these cases, the discovery mechanism described in
Section 3.2 can be used.
Also, RFC 6613 is an experiment. Part of running that experiment is
to evaluate whether additional changes are required to RADIUS. A
lower bar for interoperability should apply to changes to
Experimental protocols than Standard protocols.
This specification provides good facilities to enable implementations
to understand packet size when proxying to/from Standards Track UDP
RADIUS.
3.2. Discovery
As discussed in Section 2.1, a client MAY send a Status-Server
message to discover whether an authentication or accounting server
supports this specification. The client includes a Response-Length
attribute; this signals the server to include a Response-Length
attribute indicating the maximum packet size the server can process.
In this one instance, Response-Length indicates the size of a request
that can be processed rather than a response.
4. Protocol-Error Code
This document defines a new RADIUS code, 52, called Protocol-Error.
This packet code may be used in response to any request packet, such
as Access-Request, Accounting-Request, CoA-Request, or Disconnect-
Request. It is a response packet sent by a server to a client. The
packet indicates to the client that the server is unable to process
the request for some reason.
A Protocol-Error packet MUST contain an Original-Packet-Code
attribute, along with an Error-Cause attribute. Other attributes MAY
be included if desired. The Original-Packet-Code contains the code
from the request that generated the protocol error so that clients
can disambiguate requests with different codes and the same ID.
Regardless of the original packet code, the RADIUS Server calculates
the Message-Authenticator attribute as if the original packet were an
Access-Request packet. The identifier is copied from the original
request.
Clients processing Protocol-Error MUST ignore unknown or unexpected
attributes.
This RADIUS code is hop by hop. Proxies MUST NOT forward a Protocol-
Error packet they receive.
5. Too Big Response
When a RADIUS Server receives a request that is larger than can be
processed, it generates a Protocol-Error response as follows:
The code is Protocol-Error.
The Response-Length attribute MUST be included and its value is
the maximum size of request that will be processed.
The Error-Cause attribute is included with a value of 601.
The Original-Packet-Code attribute is copied from the request.
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
RADIUS fragmentation. In other cases, this code will provide for
better client error reporting and will avoid retransmitting requests
guaranteed to fail.
6. IANA Considerations
A new RADIUS Packet Type Code is registered in the "RADIUS Packet
Type Codes" registry discussed in Section 2.1 of RFC 3575 [RFC3575].
The name is "Protocol-Error" and the code is 52.
The following RADIUS attribute Type values [RFC3575] are assigned.
The assignment rules in Section 10.3 of [RFC6929] are used.
+----------------------+-----------+--------------------------------+
| Name | Attribute | Description |
+----------------------+-----------+--------------------------------+
| Response-Length | 241.3 | An attribute of type "integer" |
| | | per Section 5 of RFC 2865 |
| | | containing maximum response |
| | | length. |
| | | |
| Original-Packet-Code | 241.4 | An integer attribute |
| | | containing the code from a |
| | | packet resulting in a |
| | | Protocol-Error response. |
+----------------------+-----------+--------------------------------+
The Response-Length attribute MAY be included in any RADIUS request.
In this context, it indicates the maximum length of a response the
client is prepared to receive. Values are between 4096 and 65535.
The attribute MAY also be included in a response to a Status-Server
message. In this case, the attribute indicates the maximum size
RADIUS request that is permitted.
A new Error-Cause value is registered in the "Values for RADIUS
Attribute 101, Error-Cause Attribute" registry at
<http://www.iana.org/assignments/radius-types> for "Response Too Big"
with value 601. The range of valid values for the Error-Cause
attribute in the "Values for RADIUS Attribute 101, Error-Cause
Attribute" registry originally defined in RFC 5176 are extended. Two
new ranges are defined:
6xx fatal errors committed by a RADIUS server
7xx fatal errors committed by a RADIUS client
7. Security Considerations
This specification updates [RFC6613] and will be used with [RFC6614].
When used over plain TCP, this specification creates new
opportunities for an on-path attacker to impact availability. These
attacks can be entirely mitigated by using TLS. If these attacks are
acceptable, then this specification can be used over TCP without TLS.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<http://www.rfc-editor.org/info/rfc2865>.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
DOI 10.17487/RFC3575, July 2003,
<http://www.rfc-editor.org/info/rfc3575>.
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
Authentication Dial In User Service (RADIUS) Protocol",
RFC 5997, DOI 10.17487/RFC5997, August 2010,
<http://www.rfc-editor.org/info/rfc5997>.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613,
DOI 10.17487/RFC6613, May 2012,
<http://www.rfc-editor.org/info/rfc6613>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<http://www.rfc-editor.org/info/rfc6614>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929,
DOI 10.17487/RFC6929, April 2013,
<http://www.rfc-editor.org/info/rfc6929>.
8.2. Informative References
[RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia,
F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of
Fragmentation of RADIUS Packets", RFC 7499,
DOI 10.17487/RFC7499, April 2015,
<http://www.rfc-editor.org/info/rfc7499>.
[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
RADIUS Attribute, Binding, Profiles, Name Identifier
Format, and Confirmation Methods for the Security
Assertion Markup Language (SAML)", RFC 7833,
DOI 10.17487/RFC7833, May 2016,
<http://www.rfc-editor.org/info/rfc7833>.
Acknowledgements
Sam Hartman's time on this document was funded by JANET as part of
Project Moonshot.
Alan DeKok provided valuable review and text for the Protocol-Error
packet code.
Alejandro Perez Mendez provided valuable review comments.
Author's Address
Sam Hartman
Painless Security
Email: hartmans-ietf@mit.edu
ISO Plain Language
On this page
§1Why RADIUS Needs Bigger Packets
The experiment with RADIUS over TLS provides strong confidentiality and integrity for RADIUS, and that stronger security has opened new opportunities for using RADIUS to convey additional authorization information. The example given is a mechanism for carrying SAML messages in RADIUS, whose attributes will often need the confidentiality or integrity that TLS provides.
These new use cases involve carrying more information in RADIUS packets, and the maximum packet length of 4096 octets is proving insufficient for some SAML messages and for other structures that may be carried in RADIUS.
One approach is to fragment a RADIUS message across multiple packets at the RADIUS layer, as described in RFC 7499. That mechanism is needed in order to split authorization information across existing unmodified proxies, but it has significant disadvantages. RADIUS is a lock-step protocol, so only one fragment can be in transit at a time as part of a given request. There is also no mechanism to discover the path maximum transmission unit across the entire path the fragment will travel, so fragmentation is likely both at the RADIUS layer and at the transport layer. When TCP is used, much better transport characteristics are achieved by fragmenting only at the TCP layer, and this specification provides a way to get them.
There are two ways to send a big message: split it into several small ones, or make the container bigger. Splitting has its own costs in round trips, so the document makes the container bigger where TCP is already in use.
§2Changes to Packet Processing
The maximum length of a RADIUS message is increased from 4096 to 65535. A server implementing this specification must be able to receive a RADIUS packet of the maximum length. Servers may have a maximum size above which they choose to return an error rather than processing a received packet, and that size must be at least 4096 octets.
Clients must also be able to receive a packet of the maximum length, and must not close the TCP connection simply because a large packet is sent over it. They may include the Response-Length attribute to indicate the maximum size of a packet they can successfully process, and they may silently discard a packet larger than some configured size, which must be at least 4096 octets. Clients must not retransmit an unmodified request whose response is larger than they can process, since subsequent responses will likely continue to be too large.
Proxies must be able to receive a packet of the maximum length without closing the connection, and should be able to process and forward packets of that size. When a proxy receives a request over a transport with a 4096-octet maximum and forwards it over a transport with a larger maximum, it must include the Response-Length attribute with a value of 4096.
Every participant has to be able to handle a big message without hanging up. A proxy that can only pass on 4096-byte messages says so with a number in the request, so the sender does not build something the proxy will choke on.
- Receive the maximumServers, clients and proxies must all be able to receive a packet of the maximum length without dropping the connection.
- Never close earlyA client must not close the connection just because a large packet arrived on it.
- Do not resend the same requestA client must not retransmit an unmodified request whose response is too large to process.
- Announce the older limitA proxy forwarding to a 4096-octet transport must include Response-Length with a value of 4096.
§3Compatibility With Older Implementations
An implementation of RFC 6613 will silently discard any RADIUS packet larger than 4096 octets and will close the TCP connection. The memo gives guidelines for interoperability with those implementations, stated at the SHOULD level. In some environments support for large packets will be important enough that roaming agreements will mandate it, removing the need for interoperability with RFC 6613. The memo thinks these guidelines will be relaxed to the MAY level, and support made a requirement, if RADIUS over TLS and TCP move to the Standards Track.
Clients should provide configuration for the maximum size of a request sent to each server, and servers for the maximum size of a response sent to each client. If a client sends a request larger than 4096 octets and the connection is closed without a response, the client should treat the request as if a Request Too Big error specifying a maximum size of 4096 had been received. By default a server should not generate a response larger than 4096 octets, and the Response-Length attribute may be included in a request to indicate that larger responses are acceptable.
The memo acknowledges that this introduces behaviour where new implementations will fail to function with existing ones, and argues that the risk is mostly operational: the biggest risk would be requests and responses being expanded to include information that is not strictly necessary, so avoiding large packets towards existing implementations is largely a matter of care. A proxy that implements both this specification and RADIUS fragmentation should use fragmentation when a packet is being forwarded to a next hop that cannot take a packet that large and fragmentation can be used for it.
An older peer will hang up rather than answer, so the new behaviour has to be used carefully. The guidance is: only send big messages when you know the other end can take them, and fall back to splitting when a proxy in the way cannot.
| Rule | RADIUS over TCP (RFC 6613) | With this specification |
|---|---|---|
| Maximum packet length | 4096 octets | 65535 octets |
| A packet that is too large | Discarded, and the connection is closed | Answered with a Protocol-Error packet |
| How a peer learns the limit | Not possible | The Response-Length attribute |
§4The Protocol-Error Packet and Too Big Response
The document defines a new RADIUS code, 52, called Protocol-Error. It may be used in response to any request packet, such as an access request, an accounting request or a change-of-authorization request. It is a response packet sent by a server to a client, indicating that the server cannot process the request for some reason.
A Protocol-Error packet must contain an Original-Packet-Code attribute, along with an Error-Cause attribute, and may include other attributes. The Original-Packet-Code holds the code from the request that caused the error, so that clients can tell apart requests with different codes and the same identifier. Whatever the original packet code, the server calculates the Message-Authenticator attribute as if the original packet were an access request, and the identifier is copied from the original request. Clients processing a Protocol-Error must ignore unknown or unexpected attributes. The code is hop by hop, so proxies must not forward a Protocol-Error packet they receive.
When a server receives a request that is larger than it can process, it generates a Protocol-Error response with the Response-Length attribute set to the maximum size of request it will process, the Error-Cause attribute set to 601, and the Original-Packet-Code copied from the request. Clients will not typically be able to adjust and resend requests when this error is received, though in some cases they can fall back to RADIUS fragmentation; in other cases the code gives better client error reporting and avoids retransmitting requests guaranteed to fail.
The new error packet says three things: the request was too big, here is the biggest one I will take, and this is the kind of request you sent. A proxy must not pass it on, because it is about the conversation between one client and one server.
- 52Protocol-Error — The new RADIUS packet type code.
- 241.3Response-Length — The maximum length of a response the client can process.
- 241.4Original-Packet-Code — The code of the request that caused the error.
- 601Response Too Big — The Error-Cause value used when a request is too large.
§6IANA Registrations
A new RADIUS packet type code is registered: the name is Protocol-Error and the code is 52. Two RADIUS attribute types are assigned as well, using the assignment rules of section 10.3 of RFC 6929.
The Response-Length attribute has type 241.3 and is an attribute of type integer, as defined in section 5 of RFC 2865, containing a maximum response length. The Original-Packet-Code attribute has type 241.4 and is an integer attribute containing the code from a packet resulting in a Protocol-Error response. The Response-Length attribute may be included in any RADIUS request, where it indicates the maximum length of a response the client is prepared to receive, with values between 4096 and 65535. It may also be included in a response to a Status-Server message, where it indicates the maximum size of RADIUS request that is permitted.
A new Error-Cause value is registered for Response Too Big with the value 601. The valid range of the Error-Cause attribute, originally defined in RFC 5176, is extended with two new ranges: 6xx for fatal errors committed by a RADIUS server and 7xx for fatal errors committed by a RADIUS client.
Three new numbers are registered: the code for the new error packet, the two attributes it and the size negotiation use, and the error cause that says a request was too big.
§7Security Considerations
The specification updates RFC 6613 and will be used with RFC 6614. When used over plain TCP, it creates new opportunities for an on-path attacker to impact availability, because a peer that receives a message larger than it expects may simply close the connection. These attacks can be entirely mitigated by using TLS. If they are acceptable, the specification can be used over TCP without TLS.
Over plain TCP, a peer on the path can hurt you by sending something big and making the connection drop. Running the same traffic inside TLS removes that risk.