Stefan said:
"Ok... 3579 defines it to be that way, simply pointing to dynauth; my
draft could do so, too, of course.
5080 lists that it is done elsewhere but doesn't reference a particular
RFC; looks to me like it could refer to RFC3579."
[BA] Yes.
Stefan also said:
"Interesting use. I don't recall "Error-Cause = Invite" being specified
anywhere; it's not in the list of enumerated Error-Cause reasons in the
IANA registry anyway.
And it's one message on the list that was never replied to. Looks to me
like it's one particular NAS sending weird things out-of-spec."
[BA] Since the message was posted on the FreeRADIUS list, I was hoping
that Alan could enlighten us. The meaning of "Error-Cause=Invite" wasn't
obvious to me (e.g. it didn't look like there was an error involved),
and as you mentioned, "Invite" isn't in the list of enumerated Error-Cause
values.
Stefan said:
"I would like to note however that ICMP Port Unreachable is a *very*
coarse-grained way of NAKing accounting that is of little use anyway...
That being said, I can change the spec to "patch" the situation with
your suggestion of using Accounting-Response + Error-Cause. It may be
the adequate thing to do since this specification is going for
Experimental only.
[BA] I agree that an ICMP Port Unreachable is not a useful way for a
RADIUS server to tell a RADIUS client that it can't process a particular
Accounting-Request. However, it does allow the destination to indicate
that RADIUS accounting is not supported at all, in a way that can be
distinguished from a server or network failure. That's the functionality
missing in RADIUS over TLS.
Stefan said:
"In the long run though, I think this solution is inadequate; if
Accounting-NAK signalling is to be fixed, it should be fixed properly
(i.e. on a per-packet basis) for all transports, not just this one.
Maybe by updating 2866 with a consistent use of Error-Cause, or maybe by
adding an Accounting-NAK packet type, analogous to the dynauth NAKs.
It is definitely a useful thing to work on; but it's not for the
RAIDUS/TLS draft to decide. That would need a wg chartered item (luckily
radext is discussing rechartering right now; this might be worthwhile to
include...)"
[BA] I agree that ICMP Port Unreachable or an equivalent in RADIUS/TLS
is not a solution to the other problems you mention.
Stefan said:
"Please let me know if you'd prefer the Error-Cause "patch" to be in this
spec; I'll do as you say ;)
[BA] Here is suggested text:
(5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly
allocated UDP port to signal that a peer RADIUS server does not
support reception and processing of RADIUS Accounting packets.
Since RADIUS/TLS does not utilize a separate port for Accounting
packets, this mechanism is not available. In the event that a
client is misconfigured to send Accounting-Request packets to
a RADIUS/TLS server which does not support accounting, the
RADIUS/TLS server SHOULD reply with an Accounting-Response
containing an Error-Cause attribute with value 406
"Unsupported Extension". A RADIUS/TLS accounting client
receiving such an Accounting-Response SHOULD log the error.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf