[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TCP + TLS on the same port

Stefan Winter wrote:

 Hi,
RADIUS itself is not NAT friendly; if a NAT exists between a RADIUS client 
and server, this can cause authentication to fail (e.g. shared secret is
based on the source address).
That's true, but with RADIUS/TLS, it can *become* NAT-friendly, by supporting operation modes independent of source addresses and shared secrets.
Re-using the TCP or UDP ports for both TLS and classic, the NAT unfriendliness comes back, by producing ambiguous assumptions about the client's state on the server. Using separate ports makes these assumptions unnecessary; which is a good thing IMHO. 

For TLS in particular, but also TCP, I think it's also good to allow the
same connection (which obviously the same destination port) to be used
for all RADIUS messages.

This mainly to reduce the amount of state, and cycles spent on TLS,
certificate verification etc.

Stig


Greetings,

Stefan Winter


-----Original Message-----
From: Stefan Winter [mailto:stefan.winter@restena.lu]
Sent: Wednesday, August 25, 2010 5:25 AM
To: Alan DeKok
Cc: Bernard Aboba
Subject: Re: TCP + TLS on the same port

   Hi,


And that is not even true for DTLS.

    Yes.  But NATs are bad. :(
They are. But they are also here to stay for a long while. I don't think we 
should ignore them.


    It may be time to have an accounting NAK, with error-cause "can't
do it", or "no response from upstream".  But that's out of the scope
of this solution.

That would be good to have, agreed. But definitely out of scope.


This has consequences for the dynamic discovery though. The NAPTRs
and SRVs can't just be about service "radius". They then need to be
separate for "auth" "acct" and (maybe) "dynauth". That gets us pretty
close to dime's "application discovery in DNS" :-(

    Yup.  Any solution ends up being ugly.

Well, it's not so bad. At least in RADIUS, the service fields would be
limited to three different entries. Say, radius-auth, radius-acct,
radius-dynauth. In Diameter, there's a big number of applications, which
leads to a proliferation of service tags.
I think the effort to update the dynamic discovery draft to consider three 
service tags is certainly doable; and I don't mind doing it.

Greetings,

Stefan

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche 6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive:<http://psg.com/lists/radiusext/>






--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>