Hi,
comments inline.
"Indeed. I'll update the text to that end. Note though that adding
Error-Cause is a MAY only in 5176, so it may very well be that an
implementation which doesn't support dynauth would still send only a
"naked" NAK, ignoring the MAY."
[BA] It's a MAY in RFC 5176 because existing implementations didn't
support Error-Cause at all. However, in this particular case, since
you're requiring that RADIUS/TLS implementations support NAK in the
first place, you can also say that they SHOULD send an Error-Cause
attribute. So I'd suggest that the MAY be stronger, so as to remove
a potential ambiguity about the meaning of the NAK.
It is sufficient that upon
receiving such a packet, an unconditional NAK is sent back to
indicate that the action is not supported.
[BA] The problem is that a NAK does NOT mean that the action is
unsupported according to RFC 5176, unless there is an Error-Cause
attribute present that indicates that.
Okay, the argument for a SHOULD sunds very reasonable. I have updated my
working copy to that end.
Stefan said:
"I'm slightly confused here. To my best knowledge, Error-cause is only
specified in the context of DynAuth (RFC5176). That attribute is listed
as only allowed in a NAK as per the attribute occurrence table in 5176."
[BA] While RFC 5176 only mentions use of Error-Cause in dynamic authorization
it can also be used in other contexts. For example, Error-Cause is referenced
in the following other RFCs:
RFC 3579: Error-Cause use in Access-Challenge and Access-Reject (see Section
3.3)
RFC 5080: Error-Cause in Access-Reject (See Section 2.6.1)
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.
Stefan said:
"I would be hesitant to use Error-Cause in RADIUS Accounting packets -
unless the corresponding RFCs get updated to specify that this attribute
is now also to be used in Accounting semantics."
[BA] Apparently, Error-Cause is being sent in Accounting-Request packets, see:
http://lists.cistron.nl/pipermail/freeradius-users/2011-January/msg00255.html
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. I don't
really like that as an example to be honest.
With respect to Accounting-Response, RFC 2866 does prohibit inclusion of
attributes relating to a service, but not attributes like Proxy-State or
Vendor-Specific.
So I'd argue that Error-Cause fits within the category of attributes that
would
be permissible -- an Informational attribute that can be ignored without
damage.
Stefan said:
"The non-ability to indicate "No accounting please" has been discussed in
a radext wg meeting. The conclusion was that auth and acct are two
separate, unrelated items. RADIUS Accounting needs to be configured
differently and explicitly; so there is little risk that accounting
packets are sent "by chance" anyway. If they are sent to the wrong
place, that is an administrative error: misconfigured on the sender-side."
[BA] If a RADIUS over UDP packet is sent to the wrong place, an ICMP
message will result that the RADIUS Accounting client can act on, such
as by logging the error.
In this case, you are mandating that the RADIUS over TLS server ignore
the request, resulting in continuing connection attempts and retransmissions
by the RADIUS over TLS client, who doesn't receive evidence of the
misconfiguration.
So I'd argue that RADIUS over TLS is creating a new problem.
I take your point only partially. It's true that NASes could act on
receipt of ICMP Port Unreachable, and they can't as per this spec.
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.
Consider classic RADIUS, and a proxy environment where a server provides
accounting services for some clients, but not for others (or even more
fine-grained: for some realms, but not for others - even if they arrive
via the same RADIUS client): a UDP port is either open or closed; it is
an entirely binary way of signalling whether a server processes
accounting for a given client or not.
It is not possible to signal to the misconfigured peer that *his* (or
only some of his) packets are unwanted, while others are.
That is the situation in classic RADIUS, and makes ICMP Port Unreachable
a very poor way of signalling this condition. That's why I don't have
any scruple sacrificing it. (That, and that the wg discussion also was
rather unimpressed about the consequences of this).
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.
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...)
Please let me know if you'd prefer the Error-Cause "patch" to be in this
spec; I'll do as you say :-)
I promised my AD to publish the -11 revision for IESG review later
today; if our conversation didn't converge until then, there can always
be a -12. Probably necessary after the IESG review anyway :-)
Greetings,
Stefan Winter
_______________________________________________
radext mailing list
radext(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/radext
--
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
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf