[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE:Issue 52: Review of CUI-01
> "The NAS may use the original value of the User-Name(1) attribute (the
> one sent in the Access-Request packet) in the Accounting-Request packets
> to ensure the billing follows the same path as authentication packets.
Here is what RFC 2865, Section 5.1 says about including the User-Name
attribute in the Access-Accept:
" It MAY be sent in an Access-Accept packet, in which case the
client SHOULD use the name returned in the Access-Accept packet in
all Accounting-Request packets for this session."
So while a NAS does not have to include the returned User-Name attribute
in subsequent Accounting-Request packets, that is not the recommended
practice.
> For example, the EAP peer may construct the NAI with additional
> information (e.g., example.com@intermediary.com) to influence routing of
> the AAA packet through a preferred intermediary network. This is
> rewritten by the intermediary network (i.e., "intermediary.com" ) to
> example.com <mailto:username@example.com> . As a result, the home
> RADIUS server in "example.com" may not even be aware of
> "intermediary.com" and therefore sends a User-Name(1) containing CUI
> (i.e., CUI <mailto:CUI@example.com> @example.com
> <mailto:CUI@example.com> ) in the Access-Accept to the NAS. If the NAS
> uses the User-Name(1) of the received Access-Accept in
> Accounting-Request (as recommended by a strong SHOULD in RFC 2865), then
> the resulting Accounting-Request would be routed differently than the
> Access-Request, which might cause problems.
I don't think you need to go into this level of detail. You can just say:
"The User-Name attribute included in the Access-Request may be used for
the purpose of request routing, and in the process may be rewritten by
intermediaries. As a result, a RADIUS server receiving an Access-Request
packet relayed by a proxy cannot assume that the User-Name attribute
remained unmodified.
On the other hand, rewriting of a User-Name attribute sent within
an Access-Accept packet occurs more rarely, since a Proxy-State
attribute can be used to route the Access-Accept packet without
parsing the User-Name attribute. As a result, a RADIUS server cannot
assume that a proxy stripping routing information from a User-Name attribute
within an Access-Request will add this information to a User-Name
attribute included within an Access-Accept. The result is that when
a User-Name attribute is sent in an Access-Accept it is possible that
the Access-Request and Accounting-Request packets will follow different
paths. Where this outcome is undesirable, another mechanism is required
to provide a billable identity within an Accounting-Request."
> > I think you want to say that RADIUS proxies MUST NOT modify the CUI
> > attribute, and that NAS devices that support CUI MUST include
> > it in the Accounting-Request unmodified, no?
>
> Your statement is correct. And we say that in sectoin 2.1 -- couple of
> paragraphs below. but here we are simply stating that the entities
> outside the home network MUST NOT modify CUI.
Are you requesting some behavior *other* than having proxies leave the CUI
along and having NAS devices include it in the Accounting-Request?
> You are right, so how about this?
>
> "
> RFC 2865 states that A RADIUS server or client ignore Attributes with
> an unknown Type. Therefore, RADIUS client (Proxy or NAS) that does not
> support the CUI attribute MAY ignore this attribute.
> "
I'd suggest you quote RFC 2865, rather than paraphrasing it.
> I agree. But, there is no capabilities attribute for RADUS now, and as
> you know we have a proposal for capabilities attribute but no progerss
> yet - we may want to accelerate this.
I'll post a proposal for a Capabilities attribute to the list.
> Are you implying that RADIUS has a session-id -- I wasn't aware of that.
Disconnect or COA messages can only be sent after the service has been
started. Therefore the Acct-Session-Id attribute can be included in
either a Disconnect-Request or CoA-Request mesage in order to identify the
specific session which is to be affected. See [RFC3576] Section 3.2.
> I thought Glen Zorn is proposing this in one of his drafts. Anyhow, I
> guess you are suggesting to remove this paragraph - yes?
Yes.
> NASREQ does not have this attribute. Does NASREQ automatically cover
> new RADIUS attributes? CUI will not be used in EAP - unless you correct
> me by describing a use-case for it.
NASREQ describes how RADIUS-Diameter gateways handle translation of
attributes within the standard RADIUS attribute space. A good
implementation will apply that processing to new RADIUS attributes.
Otherwise new code would be required in the gateway whenever
a new RADIUS attribute is created, which creates maintenance headaches.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>