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

[[e-mail]]

Hi Jan-Frederik, 

Thank you for the follow-up and clarifications.

Feel free to implement changes as you see appropriate.

Cheers,
Med

> -----Message d'origine-----
> De : Jan-Frederik Rieckers <[e-mail]>
> Envoyé : mardi 7 avril 2026 15:10
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> The IESG <[e-mail]>
> Cc : [e-mail]
> Objet : Re: [radext] Mohamed Boucadair's Yes on draft-ietf-radext-
> radiusdtls-bis-15: (with COMMENT)
> 
> 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: +49
> 30884299-370
> 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