[RADIATOR] AuthRADSEC and radsecproxy are incompatible!

[Stefan Winter]

Hi,

> Yes that would be worth considering. If there are two proxies talking to
> each other, why should the Proxy-State attribute suddenly be forbidden
> for one message type? If a NAS adds Proxy-State, that may not be useful,
> but proxy <--> proxy is a bit different.

Sorry, I strongly disagree here. Status-Server is always sent in the
client role; i.e. Radiator is here turned into a "NAS" talking to its
server. Proxy-State has no role here. Both the definition of Proxy-State
and the Status-Server RFC are pretty clear here.

> Sending is not the problem, mapping the responses back to outstanding
> request is why Radiator uses Proxy-State :)

Other implementations use Status-Server without needing this. The
src/dest ip/port + packet ID is there for identification purposes.

> It would be much more robust if all responses could be looked up based
> on the same method. Status-Server does not have its own response message
> type, so an Access-Accept for Status-Server is very much in-band and can
> not be identified as a management related message based on e.g., message
> type.

They are different packet codes; and follow different rules. That has
nothing to do with robustness. It is simply a different code path
because the server does different things.

>> Independently of this, it remains a bit unclear to me why Radiator needs
>> the extended-IDs in Proxy-State anyway; if you run out of packet IDs on
>> a given src/dest port/ip combination: you can choose a new source port
>> to send your request from there! There's plenty of source ports.
> 
> Radiator uses Proxy-State for RadSec where the TCP connection fixes the
> source and destination address and port. Since RFC 2865 provides
> Proxy-State, Radiator uses this for working around the 8 bit Identifier.

RADIUS/TLS does not fix the source port. You are free to open a second
connection if your IDs run out on the first one.

That still means you *can* of course use Proxy-State (for
authentications) to avoid that if you like - there are just other means
of getting around this.

> Also, there is no requirement by Radiator or by the RFC that the
> Proxy-State is actually sent anywhere by the next hop. The only thing
> the next hop proxy needs to do is to add the unmodified Proxy-State
> value in the response. This means there is no extra burden for the
> proxies further down in the chain since handling Proxy-State can be kept
> a local thing between the two proxies.

That is how Proxy-State is designed, correct. For Access-Requests, and
for proxies. Not for Status-Server, and not for clients (NASes).

> If Proxy-State is dropped from Status-Server messages, Radiator could
> consider the Access-Accepts without Proxy-State as responses to
> Status-Server requests. This requires separate bookkeeping: one for
> plain Status-Server Identifiers and the other for extended-ID
> identifiers for the other message types.

Or, you stop sending them with Proxy-State altogether. Then one
bookkeeping is perfectly sufficient.

> As mentioned above: A thing to note about Status-Server is that their
> responses are very much in-band. The response is an Access-Accept so
> unfortunately it is not possible to catch them with e.g., based on their
> own message type.
> 
> In summary: handling Status-Server responses without Proxy-State is
> doable. It does complicate the code since more logic is needed to handle
> the two cases: instead of just doing a lookup based on the received
> Proxy-State for all responses to find the matching request,
> Access-Accepts without Proxy-State need to be considered as
> Status-Server responses with their own lookup.

Yes, I believe this is where your aversion really comes from: Radiator
is pretty much exclusively used in its server and proxy role; it doesn't
usually take the NAS role. So you probably have code which
unconditionally always adds a Proxy-State. It's probably unprecedented
in the code that Radiator finds itself in a situation where it's not
supposed to do that. Well, it's a new feature - so adding new code to do
it right is basically a "That's life" situation.

> Sending Status-Servers from their own source port or using a different
> RadSec connection for them sort of defeats the purpose of figuring out
> if the next hop is still reachable with the current communication
> parameters (ports and addresses).
> 
>> The only reason why identifiers really could run out is if you've used
>> up all your source ports * 256 identifiers for one single destination
>> server. And if you are that busy, you don't need Status-Server :-)
> 
> Yes, that's true with UDP. For TCP, the idea is to use the other means
> the RADIUS RFC provides.

Why? RFC6613 has detailed provisions on how to do this over TCP
properly. Section 2.6.5 states:

"The RADIUS ID field is one octet in size.  As a result, any one TCP
   connection can have only 256 "in flight" RADIUS packets at a time.
   If more than 256 simultaneous "in flight" packets are required,
   additional TCP connections will need to be opened."

So, this works fine without Proxy-State - just like with UDP.

And it goes on to say:

"Implementations SHOULD reserve ID zero (0) on each TCP connection for
   Status-Server packets.  This value was picked arbitrarily, as there
   is no reason to choose any one value over another for this use."

Which means you'd always have a free packet ID on your TCP connection.

IMHO, the RFC couldn't be much clearer than that.

> For UDP extended identifier space can also be useful. For example, when
> there are strict firewall rules that restrict what the source ports can be.

I agree that in such situations, Proxy-State helps (during
authentication). If you want to stick to the same source port for
Proxy-State, just do the analogous that RFC6613 suggests for TCP:
reserve one packet ID code, so that you can always send Status-Server
from that source port.

If you don't want to statically take the "0" you could also see to it
that only at max 255 authentications are in flight, and reserve the
256th for a potential Status-Server that might be coming up.

Greetings,

Stefan Winter

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
Url : http://www.open.com.au/pipermail/radiator/attachments/20130718/5ccb9fc4/attachment.bin