Review of draft-ietf-radext-tcp-transport (Part II)

Section 2

Adding TCP as a RADIUS transport has a number of impacts on the

protocol, on applications using the protocol, and on networks that

deploy the protocol. In short, RADIUS over TCP is little more than

sending RADIUS formatted messages over a TCP connection.

As always, there are additional details that need to be discussed.

This section outlines the various impacts of using RADIUS over TCP,

and the discusses the proposal in more detail.

[BA] How about this?

RADIUS over TCP involves sending RADIUS formatted messages over a TCP connection.

In the sections that follow, we discuss the implications for the RADIUS packet format

(Section 2.1), port usage (Section 2.2), RADIUS MIBs (Section 2.3) and RADIUS proxies

(Section 2.5). TCP-specific issues are discussed in Section 2.6.

Section 2.1

The changes to RADIUS implementations required to implement this

specification are largely limited to the portions that send and

receive packets on the network.

[BA] Is this sentence necessary? What portions of a RADIUS implementation *don’t* relate

To sending and receiving packets? I’d recommend that it be deleted.

Section 2.2

These ports are unused by existing RADIUS applications.

Implementations SHOULD use the assigned values as the default ports

for RADIUS over TCP.

[BA] You might say “Since these ports are unused by existing RADIUS implementations,

the assigned values SHOULD be used as the default ports for RADIUS over TCP.”

I would merge section 2.4 into this section so that one section can cover ports

for both RADIUS over TCP and RADIUS over TLS.

Section 2.3

You might revise this section to make it clear that the advice for use of MIBs

with RADIUS over TCP also applies to RADIUS over TLS.

Section 2.4

I’d merge this with Section 2.2.

Section 2.5

[BA] Suggest this section be renamed “Liveness Detection”.

If a request is proxied through intermediate proxies, it is not

possible to detect which of the later hops is responsible for the

absence of a reply. An intermediate proxy also cannot signal that

the outage lies in a later hop because RADIUS does not have the

ability to carry such signalling information. This issue is further

exacerbated by some proxy implementations that do not reply to a

client if they do not receive a reply to a proxied request.

[BA] This paragraph makes it seem that absence of a response by a proxy is incorrect behavior.

Suggest:

“Within RADIUS as defined in [RFC2865], proxies typically only forward

traffic between the NAS and RADIUS server, and do not generate their

own responses. As a result, when a NAS does not receive a response to

a request, this could be the result of packet loss between the NAS

and proxy, a problem on the proxy, loss between the RADIUS proxy and

server, or a problem with the server.”

For RADIUS over TCP, the continued existence of the TCP connection

SHOULD be used to deduce that the service on the other end of the

connection is still responsive. Further, the application layer

watchdog defined in [RFC3539] Section 3.4 enables clients to

determine that the server is "live", even though it may not have

responded recently to non-watchdog requests.

[BA] Suggest the following:

“For RADIUS over TLS/TCP, it is RECOMMENDED that implementations

utilize the existence of a TCP connection along with the

application layer watchdog defined in [RFC3539] Section 3.4 to

determine that the server is "live”.”

Additional issues with RADIUS proxies involve transport protocol

changes where the proxy receives packets on one transport protocol,

and forwards them on a different transport protocol. There are

several situations in which the law of "conservation of packets"

could be violated on an end-to-end basis (e.g. where more packets

could enter the system than could leave it on a short-term basis):

* Where TCP is used between proxies, it is possible that the

bandwidth consumed by incoming UDP packets destined to a given

upstream server could exceed the sending rate of a single TCP

connection to that server, based on the window size/RTT estimate.

* It is possible for the incoming rate of TCP packets destined to

a given realm to exceed the UDP throughput achievable using the

transport guidelines established in [RFC5080]. This could happen,

for example, where the TCP window between proxies has opened, but

packet loss is being experienced on the UDP leg, so that the

effective congestion window on the UDP side is 1.

Intrinsically, proxy systems operate with multiple control loops

instead of one end-to-end loop, and so are less stable. This is true

even for TCP-TCP proxies. As discussed in [RFC3539], the only way to

achieve stability equivalent to a single TCP connection is to mimic

the end-to-end behavior of a single TCP connection. This typically

is not achievable with an application-layer RADIUS implementation,

regardless of transport.

[BA] I suggest this material be put into a different section entitled

“Congestion Control Issues”, since it doesn’t relate to liveness detection

(the subject of the rest of the section).

Section 2.6

The guidelines defined in [RFC3539] for implementing an AAA protocol

operating over a reliable transport MUST be followed by implementors

of this specification.

[BA] Not sure the MUST adds value here. I suggest:

“The guidelines defined in [RFC3539] for implementing a AAA protocol over

reliable transport are applicable to RADIUS over TLS/TCP.”

Implementations MUST NOT confuse UDP and TCP transport. That is,

RADIUS clients and servers MUST be treated as unique based on a key

of the three-tuple (IP address, port, transport protocol).

Implementations MUST permit different shared secrets to be used for

UDP and TCP connections to the same destination IP address and

numerical port.

[BA] I’d suggest “RADIUS over TLS/TCP Implementations MUST support receiving RADIUS packets over both UDP and TLS/TCP transports originating from the same endpoint.

RADIUS packets received over UDP MUST be replied to over UDP; RADIUS packets received over TLS/TCP MUST be replied to over TLS/TCP. That is,

RADIUS clients and servers MUST be treated as unique based on a key

of the three-tuple (IP address, port, transport protocol).

Implementations MUST permit different shared secrets to be used for

UDP and TLS/TCP connections to the same destination IP address and

numerical port.

2.6.2. Head of Line Blocking

   When using UDP as a transport for RADIUS, there is no ordering of

   packets.  If a packet sent by a client is lost, that loss has no

   effect on subsequent packets sent by that client.

   Unlike UDP, TCP is subject to issues related to Head of Line (HoL)

   blocking.  This occurs when when a TCP segment is lost and a

   subsequent TCP segment arrives out of order.  While the RADIUS server

   can process RADIUS packets out of order, the semantics of TCP makes

   this impossible.  This limitation can lower the maximum packet

   processing rate of RADIUS over TCP.

[BA] Suggest:

   When using UDP as a transport for RADIUS, there is no ordering of

   packets.  If a packet sent by a client is lost, that loss has no

   effect on subsequent packets sent by that client.

   Unlike UDP, TLS/TCP is subject to issues related to Head of Line (HoL)

   blocking.  This occurs when when a TLS/TCP segment is lost and a

   subsequent TLS/TCP segment arrives out of order.  While the RADIUS server

   can process RADIUS packets out of order, the semantics of TLS/TCP makes

   this impossible.  This limitation can lower the maximum packet

   processing rate of RADIUS over TLS/TCP.

2.6.3. Shared Secrets

   The use of shared secrets in calculating the Response Authenticator,

   and other attributes such as User-Password or Message-Authenticator

   [RFC3579] MUST be unchanged from previous specifications

[BA] I’d suggest that this text be merged with Section 2.1, and that the

above paragraph be changed to the following:

“The use of TLS/TCP transport does not change the calculation of security-related

fields (such as the Response-Authenticator) in RADIUS [RFC2865] or RADIUS Dynamic

Authorization [RFC5176].  Calculation of attributes such as

User-Password [RFC2865] or Message-Authenticator [RFC3579] also does not change.”

Section 2.6.4

Implementations of this specification SHOULD treat the "silently

discard" texts referenced above as "silently discard and close the

connection."

[BA] What is the alternative to this behavior? Could this be a MUST?

TCP connections MAY be closed if any of the circumstances outlined

below are seen. Alternatively, the TCP connection MAY remain open if

any of the following circumstances are seen, but the invalid packet

MUST BE silently discarded.

[BA] Not sure how you can do this in practice. Are you assuming that the

Length field remains valid?

Section 2.6.6

Given the discussion in Section 1.1, I’m wondering if this section (or some other section)

shouldn’t make a recommendation on the maximum RADIUS message size applicable to use with

RADIUS/EAP. It seems to me that using a larger RADIUS message size would make a lot of

sense.