Subject: RE: TCP + TLS on the same port

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 25 Aug 2010 08:59:12 -0700

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:[email-masked]] 
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Stefan Winter <[email-masked]>
Date: Thu, 26 Aug 2010 08:33:30 +0200

Hi,

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

Greetings,

Stefan Winter

> archive:<http://psg.com/lists/radiusext/>

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

---

From: Stig Venaas <[email-masked]>
Date: Fri, 27 Aug 2010 14:16:11 -0700

> 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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 28 Aug 2010 21:10:11 -0700

Let us presume that there is a NAT (perhaps a carrier grade NAT) located between
a RADIUS over TLS client and server.   Bringing up a TLS connection to the RTLS
server and using this for traffic in both directions has several advantages, it seems
to me:

a.  RADIUS DynAuth traffic from the DAC to DAS can now traverse the NAT 
(assuming that the RTLS server is acting as the DAC and the NAS as the DAS). 

b.  Both the NAS/DAS and the RTLS server/DAC do not need to have both TLS
client and TLS server certs. 

Does this make sense?

---

From: Alan DeKok <[email-masked]>
Date: Sun, 29 Aug 2010 09:52:27 +0200

> server and using this for traffic in both directions has several
...
> Does this make sense?

  Yes.

  Should we have a separate document saying that multiple packet types
can go over the same port?

  I think the issue of CoA support can be handled.  i.e. if the NAS
doesn't support CoA, how is it supposed to tell the server that?

  The answer, I think, is the same as for accounting packets.  If the
NAS sends an Accounting-Request and the server never responds, the NAS
simple has to deal with it.  The server may not accept accounting
packets, or it may be proxying to an unresponsive home server, etc.

  It's largely up to the administrator to notice that large amounts of
"request" packets are never receiving "responses".  And then to
configure the client to stop sending those requests to the server.

  Alan DeKok.