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@xxxxxxxx > 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf