First steps towards RadSec support
Now that version 2.1.7 has been released, the git repository has been updated with the first step to RadSec support. For now, it only provides RADIUS transport over TCP, as per the following document: http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-01 Using "bare" TCP without TLS is't a good idea in most cases. But it's useful for testing, and can help with the transition to RadSec. Alan DeKok.
Hi, Alan DeKok <aland@deployingradius.com> wrote:
Now that version 2.1.7 has been released, the git repository has been updated with the first step to RadSec support.
For now, it only provides RADIUS transport over TCP, as per the following document:
http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-01
Using "bare" TCP without TLS is't a good idea in most cases. But it's useful for testing, and can help with the transition to RadSec.
Just thinking out loud, but RADIUS over SCTP I would have thought would be been more appropriate than TCP (as RFC3436 describes SCTP with TLS) with the multiplexing of sessions being built in? Would mean your ID field limitation could be removed... However, as I do not plan on submitting patches, do ignore me :) Cheers -- Alexander Clouter .sigmonster says: If God is One, what is bad? -- Charles Manson
Alexander Clouter wrote:
Just thinking out loud, but RADIUS over SCTP I would have thought would be been more appropriate than TCP (as RFC3436 describes SCTP with TLS) with the multiplexing of sessions being built in?
Yes. But that's even more work....
Would mean your ID field limitation could be removed...
We could do that with RADIUS over TCP. But that's another story... Alan DeKok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/09/2009 20:11, Alan DeKok wrote:
Alexander Clouter wrote:
Just thinking out loud, but RADIUS over SCTP I would have thought would be been more appropriate than TCP (as RFC3436 describes SCTP with TLS) with the multiplexing of sessions being built in?
Yes. But that's even more work....
Would mean your ID field limitation could be removed...
We could do that with RADIUS over TCP. But that's another story...
Wasn't one of the points in the RFC that TCP is mature and implemented properly in most modern operating systems... - -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqzdkcACgkQcaklux5oVKIqQwCfUw9ghYeL+exfrdeWIHDePvXH RYEAn37h17mwPvV//FKTvQsE5KklfU4R =8nkg -----END PGP SIGNATURE-----
Arran Cudbard-Bell wrote:
Wasn't one of the points in the RFC that TCP is mature and implemented properly in most modern operating systems...
The "RADIUS over TCP" document is really just an into to RadSec, which is RADIUS over SSL over TCP. Using RADIUS over TCP all by itself is really not a good idea. For NAS to server communication, there isn't enough traffic to keep TCP happy. For inter-server proxying, it has no more security and privacy than normal RADIUS. Alan DeKok.
Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk> wrote:
On 17/09/2009 20:11, Alan DeKok wrote:
Alexander Clouter wrote:
Just thinking out loud, but RADIUS over SCTP I would have thought would be been more appropriate than TCP (as RFC3436 describes SCTP with TLS) with the multiplexing of sessions being built in?
Yes. But that's even more work....
Would mean your ID field limitation could be removed...
We could do that with RADIUS over TCP. But that's another story...
Wasn't one of the points in the RFC that TCP is mature and implemented properly in most modern operating systems...
So because something is new we should overlook that it was designed to avoid some of the pitfuls of TCP (for example one session per connection, with SCTP you get the multiplexing for free) and instead we should just ignore it? I have heard (making statements without references) that SCTP is pretty handy in the cases of VoIP and gaming. To me, the proxying of requests, especially EAP, made with FreeRADIUS fits in perfectly with SCTP built in multiplexing....of course it would run against the grain probably with all the UDP session handling malarkey in there already. Of course, someone needs to produce patches...RFCs...and so on. As that person is not me...I'll leave that along side with all my other ponderings...like why the IEEE decided that not using Token Ring-esque stuff for wifi was a Good Idea(tm)[1] :-/ Just thinking out loud... :) Cheers [1] along a similar vain I guess folk thought "well Ethernet is simpler and more 'mature' than Token Ring"....'yay' :-/ -- Alexander Clouter .sigmonster says: BOFH excuse #130: new management
Alexander Clouter wrote:
To me, the proxying of requests, especially EAP, made with FreeRADIUS fits in perfectly with SCTP built in multiplexing....of course it would run against the grain probably with all the UDP session handling malarkey in there already.
The issue is RADIUS session handling, not UDP session handling. RADIUS can only have 256 packets between any (src ip/port, dst ip/port) key. This is the same for TCP. Since SCTP adds the concept of "connections", where an end host may have multiple addresses, this actually makes things *worse* for RADIUS, because of the 256 packet limit.
Of course, someone needs to produce patches...RFCs...and so on. As that person is not me...I'll leave that along side with all my other ponderings...like why the IEEE decided that not using Token Ring-esque stuff for wifi was a Good Idea(tm)[1] :-/
All of the SCTP docs I've read say that converting a TCP application to SCTP is about as simple as replacing TCP with SCTP in the source code. Since FR now has TCP transport... SCTP might not be that difficult. Alan DeKok.
participants (3)
-
Alan DeKok -
Alexander Clouter -
Arran Cudbard-Bell