Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EAP Section #13

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

EAP Section #13

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions draft-ietf-radext-radiusdtls-bis.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -368,6 +368,7 @@ In order to avoid congestive collapse, is is RECOMMENDED that RADIUS/TLS clients
This change is imperfect, but will at least help to avoid congestive collapse.

### Differing Retransmission Requirements
{:#differing_retransmission_requirements}

Due to the lossy nature of UDP, RADIUS/UDP and RADIUS/DTLS transports are required to perform retranmissions as per {{RFC5080, Section 2.2.1}}. In contrast, RADIUS/TCP and RADIUS/TLS transports are reliable, and do not perform retransmissions. These requirements lead to an issue for proxies when they send packets across protocol boundaries with differing retransmission behaviors.

Expand All @@ -381,11 +382,21 @@ The above requirements are a logical extension of the common practice where a cl

In an ideal world, a proxy could also apply the suggestion of the previous section, by discarding Acct-Delay-Time from Accounting-Request packets, and replacing it with Event-Timestamp. However, this process is fragile and is not known to succeed in the general case.

## EAP Sessions
When RADIUS clients send EAP requests using RADIUS/(D)TLS, they MUST choose the same connection for all packets related to one EAP session. This practice ensures that problems with any one connection affect the minimum number of EAP sessions.

A simple method that may work in many situations is to hash the contents of the Calling-Station-Id attribute, which normally contains the Media Access Control (MAC) address. The output of that hash can be used to select a particular connection.
Comment on lines +385 to +388
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused about this MUST requirement.

Just for my own understanding: we are talking about actual clients (i.e. NAS), and not proxies?

I'm not very familiar with EAP on a NAS. I would expect that a client is always aware of the EAP sessions - but its details area outside of this specification. To me this is a prerequieiste for this MUST statement. If we can't guarantee this for a client, then we can't put a MUST here.

The second paragraph is confusing me. Having to keep EAP sessions together based on a radius attribute is something a proxy might do - as stated above a client should already know the EAP sessions. If a client has to guess the EAP sessions from a radius attribute, we can't call this a MUST.

I would propose to remove the second paragraph (if my initial assumption of clients having perfect knowledge about EAP sessions is true).


However, EAP packets for one EAP session can still be transported from client to server over multiple paths, due to issues with a client connection. Therefore, when a server receives a RADIUS request containing and EAP request, it MUST be processed without considering the transport protocol. The algorithm suggested in {{RFC5080, Section 2.1.1}} SHOULD be used to track EAP sessions, as it is independent of the source port and transport protocol.

The retransmission requirements of {{differing_retransmission_requirements}}, above, and {{duplicates_and_retransmissions}}, below, MUST be applied to RADIUS-encapsulated EAP packets. That is, EAP retransmissions MUST NOT result in retransmissions of RADIUS packets over a particular connection. EAP retransmissions MAY result in restransmission of RADIUS packets over a different connection, but only when the previous connection is marked DOWN.

# RADIUS/TLS specific specifications

This section discusses all specifications that are only relevant for RADIUS/TLS.

## Duplicates and Retransmissions
{:#duplicates_and_retransmissions}

As TCP is a reliable transport, RADIUS/TLS peers MUST NOT retransmit RADIUS packets over a given TCP connection.
Similarly, if there is no response to a RADIUS packet over one RADIUS/TLS connection, implementations MUST NOT retransmit that packet over a different connection to the same destination IP address and port, while the first connection is in the OKAY state ({{RFC3539, Appendix A}}. [^what_is_a_server_2]{:jf}
Expand Down