[radext] Re: Mohamed Boucadair's Yes on draft-ietf-radext-radiusdtls-bis-15: (with COMMENT)

[Jan-Frederik Rieckers <[e-mail]>]

Hi Mohamed,

thanks for your review and your comments, I've added my replies below.

On 3/1/26 10:19, Mohamed Boucadair via Datatracker wrote:
> # Source port number selection
> 
> CURRENT (3.1):
>     The client source port used for
>     RadSec connections is not fixed -- it is typically an ephemeral port
>     picked by the client Operating System.
> 
> Can this also mention the mechanism in RFC6056?
> 
> If randomization is followed, then this would help with this:
> 
> Section 6.5.2
> 
>     RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS
>     packets to different servers from the same source socket.

We could add a reference to RFC 6056. Personally, my observation of 
current implementations is that selection of source ports is done on OS 
layer, so adding 6056 does not bring benefits to this document, instead 
it suggests that implementations should deal with the source port 
selection themselves instead of using the existing APIs provided by the OS.
(But that's only my personal opinion, I can be persuaded.)

> 
> # keepalive
> 
> CURRENT:
>     RadSec implementations MUST utilize the existence of a TCP, TLS or
>     DTLS connection where applicable in addition to the application-layer
>     watchdog defined in [RFC3539], Section 3.4 when determining the
>     liveness of each connection.
> 
> I guess by “utilize the existence” you meant implement some
> heartbeat/keepalives.
> 
> For TCP, please note that rfc9293#3.8.4 says:
> 
>     Implementers MAY include "keep-alives" in their TCP implementations
>     (MAY-5), although this practice is not universally accepted.
> 
> I don’t see an issue with the behavior in the spec given that 3539 requires
> anyway the following:
> 
>     AAA protocols MUST support
>     an application layer watchdog message.

What we mean there is not keepalives, but really the existence, as in: 
if the other end sends a TCP FIN or RST or a TLS close notification, or 
the OS times out the connection by itself if it hasn't seen any traffic 
in some time and requests are unanswered, then the connection does not 
exist any more.
And if the connection does not exist any more, the watchdog is useless 
and will come to the same result, only with a delay.

> # Logging
> 
> Some events are better logged for operational needs. For example, the following
> events (and similar) should be logged
> 
> CURRENT:
>     That is, the implementation SHOULD send a TLS close
>     notification and, in the case of RADIUS/TLS, the underlying TCP
>     connection MUST be closed if any of the following circumstances are
>     seen:

I've opened a github issue on this, right now I think we only have one 
mention of logging in the whole document.

> # server IP?

I've already replaced IP with IP address and port with port number in 
the editor's copy on github, it will be included in the next I-D.

> # Same behavior
> 
> Section 3.1
>     RadSec endpoints MUST NOT use the old RADIUS/UDP or RADIUS/TCP ports
>     for RADIUS/DTLS or RADIUS/TLS.
> 
> Section 3.12
>     Implementations MUST NOT exchange both insecure and secure traffic on
>     the same UDP or TCP port.  It is RECOMMENDED that implementations
>     make it impossible for such a configuration to be created.
> 
> These are covering the same points. May be consider having this discussion in
> one single place.
> 
> Alternatively, consider linking both such as:
> 
> NEW
>     RadSec endpoints MUST NOT use the old RADIUS/UDP or RADIUS/TCP ports
>     for RADIUS/DTLS or RADIUS/TLS. See also Section 3.12.

They are not covering the exact same points.
Section 3.1 forbids using 1812/1813 (and the old non-standard 1645/1646) 
for RadSec, independent on whether the RADIUS server is accepting 
RADIUS/UDP or RADIUS/TCP over these ports.

But the wording "old RADIUS/UDP ..." may be suboptimal, I'll see if we 
can make that more clear.



> # packets, records, and datagrams
> 
> CURRENT:
>     RADIUS/DTLS endpoints MUST send exactly one RADIUS packet per DTLS
>     record.  This ensures that the RADIUS packets do not get fragmented
>     at a point where a re-ordering of UDP packets would result in
>     decoding failures.  The DTLS specification mandates that a DTLS
>     record must not span multiple UDP datagrams.  We note that a single
>     UDP datagram may, however, contain multiple DTLS records.  RADIUS/
>     DTLS endpoints MAY use this behavior to send multiple RADIUS packets
>     in one UDP packet.
> 
> Maybe add a pointer to rfc9147#section-4.3?
> 
> I would delete “we note”.
Thanks for the hint, it's updated in the editor's copy and will be 
included in the next I-D version.

Cheers,
Janfred
-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: [e-mail] | Fon: [phone] | Fax: [phone]
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Alina Hain
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822