RE: TCP + TLS on the same port

["Bernard Aboba" <bernard_aboba@hotmail.com>]

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).  

-----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/>