Issue 200: RADIUS Response and Retransmissions Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: June 16, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00570.html Document: FIXES-03 Comment type: T Priority: '1' Should Fix Section: New Rationale/Explanation of issue:
We are seeing RADIUS client implementations in the field that do not correctly handle receipt of RADIUS responses after retransmissions. The recommended text is as follows: "X.X Responses Received After Retransmissions RFC 2865 Section 2.5 states: If the NAS is retransmitting a RADIUS request to the same server as before, and the attributes haven't changed, you MUST use the same Request Authenticator, ID, and source port. If any attributes have changed, you MUST use a new Request Authenticator and ID. Therefore for a RADIUS retransmission it is possible that the ID and Request Authenticator will remain the same or that they will change. Regardless of whether a retransmission utilizes the same ID and Request Authenticator or changes them, it is possible to receive a RADIUS response to a previous transmission after a retransmission has been sent. RADIUS client implementations SHOULD validate those responses, rather than silently discarding them. "
[Alan DeKok]
I'm not sure what is meant by a "retransmission" if the
Access-Request packet contents change. Which attributes determine a
"session"?
Section 1.2 of RFC 2865 says:
session Each service provided by the NAS to a dial-in user
constitutes a session, with the beginning of the session
defined as the point where service is first provided and
the end of the session defined as the point where service
is ended. A user may have multiple sessions in parallel or
series if the NAS supports that.
But it doesn't describe how to distinguish multiple parallel
sessions on the same NAS. Many implementations assume a unique
session is at least (NAS-IP-Address, NAS-Port), but there may be other
viable approaches.
In the absence of a clear and consistent definition for "session",
the RADIUS server MAY treat a "retransmit with new ID" as a different
session. It MAY return Access-Accept for one request, and
Access-Reject for another. This can happen when multiple simultaneous
login restrictions are enforced, among other scenarios.
So the problem appears to be larger than just the NAS behavior.
Again, in the absence of a clear and consistent definition for
"session", the presumed behavior of a NAS when it "retransmits with a
new ID" is that the old session is being discarded, and a new session
is being initiated. In that case, the response of the server (if any)
is irrelevant, as the NAS has decided to stop supporting that session.
So silently discarding the response associated with the "old"
session would appear to be the correct thing to do. The NAS *could*
validate the response, but that would serve as a check that it was a
valid response, and an indication that the RADIUS server is still
alive. That response would make no difference in subsequent NAS
behavior, as it already had decided to drop that session.
My question is that if the NAS is supposed to validate the
response... what does it do then with that response? How does it's
behavior cange over silently dropping the response? How does it
handle the case where one "session" returns Access-Accept, and the
other Access-Reject? Which session wins, and why?
Silently discarding the old session would seem to me to be the
safest thing to do.
[Bernard Aboba]
I'm not sure what is meant by a "retransmission" if the Access-Request packet contents change. Which attributes determine a "session"?
I'm not sure, either, but RFC 2865 section 2.5 mentions "retransmitting" and changing the ID in the same paragraph:
If the NAS is retransmitting a RADIUS request to the same server as before, and the attributes haven't changed, you MUST use the same Request Authenticator, ID, and source port. If any attributes have changed, you MUST use a new Request Authenticator and ID.
In the absence of a clear and consistent definition for "session", the RADIUS server MAY treat a "retransmit with new ID" as a different session. It MAY return Access-Accept for one request, and Access-Reject for another. This can happen when multiple simultaneous login restrictions are enforced, among other scenarios. So the problem appears to be larger than just the NAS behavior.
Right. It is probably worth adding a caveat about the effects of changing the Request ID.
Again, in the absence of a clear and consistent definition for "session", the presumed behavior of a NAS when it "retransmits with a new ID" is that the old session is being discarded, and a new session is being initiated. In that case, the response of the server (if any) is irrelevant, as the NAS has decided to stop supporting that session.
RFC 2865 doesn't give an indication that change of ID relates to aborting the session. For example, we could be talking about re-authentication or a situation where an Event-Timestamp attribute is being included (such as is recommended in RFC 3576). That would lead to a change on ID with each retransmission. Yet the session is still in progress.
My question is that if the NAS is supposed to validate the response... what does it do then with that response? How does it's behavior cange over silently dropping the response? How does it handle the case where one "session" returns Access-Accept, and the other Access-Reject? Which session wins, and why?
What we are seeing is that the RADIUS client RTO is less than the time it takes for the RADIUS server to respond. The ID isn't necessarily changing, but the RADIUS client is dropping the Response. If the RTO is not backed off, this can continue for quite a while without success, even though an Access-Accept is being continually returned.
If we are talking about retransmission as discussed in Section 2.5, I don't think RFC 2865 defines what happens when the Response to one transmission has a different result than the Response to a retransmission.
Silently discarding the old session would seem to me to be the safest thing to do.
If the ID has changed, that might be reasonable, but if it hasn't, then I don't see why it shouldn't be processed.
[Alan DeKok]
> Right. It is probably worth adding a caveat about the effects of
changing
> the Request ID.
I'll try to write up some text for inclusion in the issues & fixes
document.
> RFC 2865 doesn't give an indication that change of ID relates to aborting
> the session. For example, we could be talking about re-authentication or
a
> situation where an Event-Timestamp attribute is being included (such as is
> recommended in RFC 3576). That would lead to a change on ID with each
> retransmission. Yet the session is still in progress.
I quite agree. But how does the NAS know that the server will agree
it's the same session? It can guess, but...
> What we are seeing is that the RADIUS client RTO is less than the time it
> takes for the RADIUS server to respond. The ID isn't necessarily
changing,
> but the RADIUS client is dropping the Response. If the RTO is not backed
> off, this can continue for quite a while without success, even though an
> Access-Accept is being continually returned.
That's an independent problem, I think, caused by two issues:
1) RTO is fixed and unchanging (and probably much less than 30s)
2) old request packets are discarded
The side-effect of (1) means that the NAS isn't doing exponential
backoff, which is a well-known solution to delay/congestion in networks.
The side effect of (2) means that the NAS has no idea of knowing
what the RTO *should* be.
RADIUS clients typically use fixed time intervals for RTO & total
packet time. The "Issues & Fixes" document already talks about
congestive back-off. Maybe it's worth adding a section about RTO's in
general. If poor retransmission methods cause problems in
non-congested situations, that's reason to have a separate section.
I'll see if I can write up some text this week.
Proposed Resolution: Discuss
Issue 201: IESG DISCUSS Comments Submitter name: Ralph Droms Submitter email address: rdroms@cisco.com Date first submitted: June 15, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00568.html Document: Delegated-Prefix-01 Comment type: T Priority: S Section: Rationale/Explanation of issue:
Here is a draft of new replacement text for section 4 in
draft-ietf-radext-delegated-prefix, based on Jari's template. If the
substance of the text is acceptable, I will clean up the various citations
and references.
Not knowing any better, I used OctetString as the datatype for the
Delegated-IPv6-Prefix. Also, not being intimately familiar with Diameter,
the last three paragraphs may need some editing or correction.
Note that I modified the text from Jari's template, and suggest those
editorial changes be considered for the template in the future.
- Ralph
OLD:
4. Diameter Considerations
A definition is needed for an identical attribute with the same Type
value for Diameter [4]. The attribute should be available as part of
the NASREQ application [5], as well as the Diameter EAP application
[6].
NEW:
When used in Diameter, the attribute defined in this specification
can be used as a Diameter AVP from the Code space 1-255, i.e.,
RADIUS attribute compatibility space. No additional Diameter Code
values are therefore allocated. The data types of the attributes
are as follows:
Delegated-IPv6-Prefix OctetString
The attribute in this specification has no special translation
requirements for Diameter to RADIUS or RADIUS to Diameter gateways,
i.e., the attribute is copied as is, except for changes relating to
headers, alignment, and padding. See also [RFC 3588] Section 4.1
and [RFC 4005] Section 9.
The text in this specification describing the applicability of the
Delegated-IPv6-Prefix attribute for RADIUS Access-Request applies
in Diameter to AA-Request [RFC 4005] or Diameter-EAP-Request [RFC
4072].
The text in this specification describing the applicability of the
Delegated-IPv6-Prefix attribute for RADIUS Access-Accept applies in
Diameter to AA-Answer or Diameter-EAP-Answer that indicates
success.
The text in this specification describing the applicability of the
Delegated-IPv6-Prefix attribute for RADIUS Accounting-Request
applies to Diameter Accounting-Request [RFC 4005] as well.
[Bernard Aboba]
As described in RFC 4005, the Framed-IPv6-Prefix attribute in Diameter is of type OctetString, so I think that it's ok for the Delegated Prefix attribute to be of the same type.
I also think you need to include text on the AVP flag rules, along the lines of what is in the Framed-IPv6-Prefix attribute:
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST| |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Framed-IPv6- 97 6.11.6 OctetString| M | P | | V | Y |
Prefix | | | | | |
Proposed Resolution: Accept
Issue 202: Diameter-RADIUS gateway behavior not complete specified Submitter name: Glen Zorn Submitter email address: gwz@cisco.com Date first submitted: August 26, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00822.html Document: draft-ietf-radext-filter-01.txt Comment type: T Priority: 1 Section: 4 Rationale/Explanation of issue:
The last sentence of section 4 says:
"Note that since a Diameter AVP can be larger than the maximum RADIUS packet size (4096), translation from Diameter to RADIUS may not be possible in all cases."
While this is true, the behavior of the Diameter-RADIUS gateway in this case is left unspecified. Is the response forwarded back toward the requests' originator without the untranslatable AVPs? In the case of an Access-Accept message, Section 1.2 says:
"If a NAS conforming to this specification receives an Access-Accept packet containing a NAS-Filter-Rule attribute which it cannot apply, it MUST act as though it had received an Access-Reject.",
It might be reasonable for the gateway to translate the Access-Accept into an Access-Reject, since an attribute that is missing because untranslatable can obviously not be applied. In the case of a CoA message with an untranslatable attribute, should the message be translated into a Disconnect-Request or just discarded? Or in both cases, should the gateway respond to the originating/responding Diameter peer with an appropriate error (e.g., DIAMETER_INVALID_AVP_LENGTH) and let it figure out the next step? If so, it still seems that the peers behavior must be specified.
[Bernard Aboba]
I think the major issue here is translation from Diameter to RADIUS in the case where the translated RADIUS packet does not fit within the maxium (4096) byte packet size. Is that correct? This problem is not unique to the NAS-Filter-Rule, so if possible I'd prefer a general solution, rather than one specific to NAS-Filter-Rule. My take is that a solution: a. Needs to notify the Diameter client or server of the problem so that it can be logged and hopefully fixed; b. Needs to avoid sending an illegal RADIUS packet. The way to think about this is that the Diameter/RADIUS proxy conceptually translates the Diameter message to a RADIUS packet and then checks whether it fits within the length constraints. If not, then it needs to translate the oversize RADIUS packet to something else rather than sending it. This problem can even occur in other scenarios, such as a RADIUS proxy which attempts to add a Proxy-State attribute but finds that the packet exceeds the 4096 octet size limit. My suggestion is to translate an oversize RADIUS Access-Accept into a RADIUS Access-Reject with an Error-Cause attribute of value 505 "Other Proxy Processing Error ". Not sure what Diameter error message would be appropriate. In the case of server-initiated messages, I think the correct thing is to translate an oversize RADIUS CoA-Request to a Disconnect-Request, also with Error-Cause value 505.
[Barney Wolff]
I agree that the behavior should be specified. It would seem that this is an opportunity to take advantage of Diameter's M-bit in governing the gateway's behavior.
[Bernard Aboba] In theory the Diameter/RADIUS gateway could discard Diameter AVPs without the 'M' bit set in order to fit within the RADIUS packet size limit. However if there are multiple attributes of a given type, it might not be appropriate to discard some but not all of them. So in practice, the rules might get quite complex. If we believe that this is a problem which is only likely to occur due to mis-configuration, then it might be better for the gateway just to indicate that a problem has occurred to the source and destination and leave it at that.
[Glen Zorn]
In this case, I think the problem would likely stem from misconfiguration, but in general I don't believe that that is a good assumption. I'm seeing requests to send truly huge objects via Diameter (& therefore, potentially through RADIUS)
[Barney Wolff]
> Right, but RFC 4005 says that the M-bit MUST be set on the > NAS-Filter-Rule AVP... Sigh. It seems to me that 3588 4.1 at least in spirit says that a gateway getting an attribute with an M-bit that it cannot for whatever reason translate, MUST reject the message. I would truly hate to have to specify gateway behavior for each attribute type, and hate even more having to implement type-specific behavior, just to handle message overflow - or, for that matter, for any other reason.
[Bernard Aboba] The proposed resolution is:
In Section 4, change:
"Note that since a Diameter AVP can be larger than the maximum RADIUS packet size (4096), translation from Diameter to RADIUS may not be possible in all cases."
To:
"Note that a translated Diameter message can be larger than the maximum RADIUS packet size (4096). Where a Diameter/RADIUS gateway receives a Diameter message containing a NAS-Filter-Rule AVP that is too large to fit into a RADIUS packet, the Diameter/RADIUS gateway will respond to the originating Diameter peer with the DIAMETER_INVALID_AVP_LENGTH error (5014), and with a Failed-AVP AVP containing the NAS-Filter-Rule AVP. Since repairing the error will probably require re-working the filter rules, the originating peer should treat the combination of a DIAMETER_INVALID_AVP_LENGTH error and a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal error."
Proposed Resolution: Accept
Issue 203: Review of draft-chowdhury-mip6-radius-02 Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: August 23, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00812.html Document: draft-chowdhury-mip6-radius-02 Comment type: T/E Priority: 1 Section: Various Rationale/Explanation of issue:
1) The document should give all new attributes short names that don't contain spaces (e.g. "MIP6-Home-Link-Prefix" or just "Home-Link-Prefix"). 2) Section 5: "The attributes MAY be present in the Access-Accept and the Accounting-Request." The accounting part is too ambiguous; does e.g. requesting DNS update really make sense for accounting messages? At the very least, the document should explicitly say what is included in accounting messages and what it means. 3) Section 5.2: This attribute should use the same data type as other attributes containing FQDNs (i.e., just the FQDN, without the zeroes in the beginning). 4) Section 5.3: This attribute should use the same data type as other attributes containing IPv6 prefixes (e.g. Framed-IPv6-Prefix in RFC 3162). 5) Section 5.5: This section should describe that the status code field uses values defined in "draft-ietf-mip6-bootstrapping-split-02"; now it gives the impression that totally number space is created (but doesn't give any IANA considerations on how to manage it). 6) Section 5.5 first says "response to the request MAY not carry a FQDN value" but then changes its mind "The data field MUST contain a FQDN". 7) Section 5.5: This attribute should probably be split to 2..3 separate attributes (e.g. DNS-Update-FQDN and DNS-Update-Result); this would be better in line with other recent RADIUS documents. 8) Section 5: Suggest rephrasing "All bits set to 0" to "The bits MUST be initialized to zero by the sender, and MUST be ignored by the receiver." 9) Section 8: According to Section 5, the first four attributes are sent by the RADIUS server to the NAS, so the first column should be "0" instead of "0-1" (alternatively, Section 5 needs to specify what these attributes mean in Access-Requests). 10) Section 8: The table should probably include accounting messages and CoA-Request as well. 11) For the split scenario, the document should define what to put in Service-Type and NAS-Port-Type attributes (and maybe also Calling-Station-Id and Called-Station-Id). 12) The document talks about doing EAP authentication over RADIUS, but never mentions RFC 3579? 13) The document should either point to RFC 2548, or explicitly say that this document does not contain an interoperable solution for the split scenario, since it does not specify (either here or by referencing some other document) how to send the MSK from the RADIUS server to the HA. 14) The document should probably have at least informative reference to RFC 4306. 15) And last (but not least, as everyone who has followed RADEXT knows :-): the document does not have a Diameter considerations section.
Proposed Resolution: Discuss
Issue 204: Review of draft-ietf-radext-delegated-prefix-02 Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 27, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00833.html Document: draft-ietf-radext-delegated-prefix-02 Comment type: E Priority: S Section: Various Rationale/Explanation of issue:
Section 1 The Delegated-IPv6-Prefix is a RADIUS attribute [1] that carries an IPv6 prefix to be delegated to the user, for use in the user's network. For example, the prefix in a Delegated-IPv6-Prefix attribute can be delegated to another node through DHCP Prefix Delegation [2]. [BA] Is there another potential use of the Delegated-IPv6-Prefix attribute? Suggest this be changed to: "The Delegated-IPv6-Prefix is a RADIUS attribute [1] that carries an IPv6 prefix to be delegated to the user, for use in the user's network, via DHCP Prefix Delegation [2]." The Framed-IPv6-Prefix attribute [4] serves a similar purpose, but may also be used for other purposes other than delegating a prefix for use in a user's network. Definition of the Delegated-IPv6-Prefix allows the simultaneous use of the Framed-IPv6-Prefix for other purposes and the Delegated-IPv6-Prefix for prefix delegation. [BA] The Framed-IPv6-Prefix attribute is used to indicate a prefix that is announced via RS/RA, which is not really a "similar" purpose. Suggest this be changed to: "The Framed-IPv6-Prefix attribute defined in [4] as not designed for use in prefix delegation, and therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet." The definition of the Delegated-IPv6-Prefix Attribute is based on the Framed-IPv6-Prefix attribute [4]. While the attributes are similar in format, they are used for different purposes. Suggest that this sentence be deleted.
Section 3 The following table describes which messages the Delegated-IPv6- Prefix attribute can appear in and in what quantity. +------------------------------------------------------+ | Request Accept Accounting # Attribute | | Request | | 0+ 0+ 0+ TBD Delegated-IPv6-Prefix | +------------------------------------------------------+ In this table 0+ means that zero or more instances of this attribute MAY be present in packet. This attribute MUST NOT appear in any packet not listed in the table. Please use the standard table format from RFC 3162; Attribute Tables are typically included in a separate section. Suggest the following: "4. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge Accounting # Attribute 0+ 0+ 0 0 0+ TBD Delegated-IPv6-Prefix The meaning of the above table entries is as follows: 0 This attribute MUST NOT be present. 0+ Zero or more instances of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present. 1 Exactly one instance of this attribute MUST be present. 1+ One or more of these attributes MUST be present." Section 4
I think you need to include text on the AVP flag rules, along the lines of what is in the Framed-IPv6-Prefix attribute:
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP | | |SHLD| MUST| |
Attribute Name Code Value Type |MUST| MAY | NOT| NOT|Encr|
----------------------------------|----+-----+----+-----|----|
Delegated-IPv6- 97 OctetString| M | P | | V | Y |
Prefix | | | | | |
Proposed Resolution: Accept
Issue 205: IANA Error
Submitter name: Wolfgang Beck
Submitter email address: BeckW@t-systems.com
Date first submitted: September 21, 2006
Reference:
https://ops.ietf.org/lists/radiusext/2006/msg00869.html
Document: RFC 4590
Comment type: E
Priority: S
Section: 7
Rationale/Explanation of issue:
Alexander
> In table 2 the Digest-Nextnonce and Digest-Response-Auth are
> numbered 106 and 107. But further down they are numbered in
> reverse order.
This is ugly. The numbering is consistent in the main text
and in the attributes table. The exception is section 7, IANA
considerations. It's wrong in the IANA registry www.iana.org
as well.
Not an excuse, but an explanation: the IANA section is inserted
at the end of the standardization process. It did not get the
same attention and review time as the rest of the text.
> If you already know about this problem I am sorry for
> spamming you. But I feel it is important that this error
> doesn't sneek it's way into implementations...
Hopefully, the implementors will stick to the text and to the
attribute table in section 5.
I've cc'ed this mail to the chairs of the RADEXT WG. We should
correct the IANA registry entries and issue an errata.
106 is Digest-Response-Auth
107 is Digest-Nextnonce
[Bernard Aboba]
I agree that we need to get the IANA web pages corrected and also need to submit an errata to the RFC Editor.However, I'm concerned that even with these measures, there is the potential for confusion to linger.
As I recall, the original RADIUS RFCs had to be re-issued to fix a port
allocation problem.
Proposed Resolution: Accept
Issue 206: Attribute Table
Submitter name: Alan DeKok
Submitter email address: aland@nitros9.org
Date first submitted: Sept. 26, 2006
Reference:
https://ops.ietf.org/lists/radiusext/2006/msg00870.html
Document: RFC 4590
Comment type: Technical
Priority: S
Section: 5
Rationale/Explanation of issue:
The body text, and examples in Section 6 appear to indicate that at
least Digest-Method is required in every Access-Request. Yet in
Section 5, the Table of Attributes indicates that no Digest attributes
are required in an Access-Request packet.
I first ran into this issue when I was looking at an implementation of
RFC 4590, and wanted to enforce the requirement that the
Message-Authenticator attribute must appear in every packet
implementing Digest authentication. If the server sends an
Access-Accept or Access-Challenge packet with Digest attributes, it is
simple to determine that the Message-Authenticator must be included in
the packet.
However, for Access-Request, there appears to be no way to determine
if the request is, in fact a request for Digest authentication,
because there is no requirement that any Digest attributes exist in
the Access-Request.
Reading Section 1.3, the paragraph at the top of page 6 seems to
indicate that a Digest-Method is always sent in an Access-Request.
Other text in the document also indicates that the first
Access-Request always contains a Digest-Method attribute.
It may be that Digest-Method does NOT have to appear in Access-Request
if the Access-Request is in response to an Access-Challenge, but this
is not clear from the text. My recommendation is to make
Digest-Method required in the Access-Request, which simplifies
implementation. It also appears that this requirement is the intent
in RFC 4590, because all of the examples have Digest-Method in every
Access-Request.
I also have noted that none of the Access-Challenges in the examples
contain a State attribute, and the State attribute is not mentioned
anywhere in RFC 4590. That indicates to me that the Access-Request in
response to an Access-Challenge MUST contain sufficient information to
finish the authentication process, and have the server return either
Access-Accept or Access-Reject. The alternative is for the server to
repeatedly challenge the client, which does not appear to be the
intent.
That says to me that the Access-Challenge MUST contain a State
attribute, which is copied to the subsequent Access-Request. The
server MUST respond with either an Access-Accept or Access-Reject to
an Access-Request that contains a State attribute. The server MUST
NOT respond with Access-Challenge to an Access-Request that contains a
State attribute.
I believe that may be another issue.
Requested change:
Update the Table of Attributes as follows:
...
| 1 | 0 | 0
| 0 | 108 | Digest-Method
|
...
Proposed Resolution: Accept
Issue 207: Diameter Considerations Section
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: November 23, 2006
Reference:
Document: RFC 3576bis
Comment type: Technical
Priority: S
Section: 4
Rationale/Explanation of issue:
RFC 3576bis has no Diameter Considerations section.
The proposed resolution is to add a Section 4 as follows:
"4. Diameter Considerations
Due to differences in handling change-of-authorization requests in
RADIUS and Diameter, it may be difficult or impossible for a
Diameter/RADIUS gateway to successfully translate a Diameter Re-Auth-
Request (RAR) to a CoA-Request and vice versa. For example, since a
CoA-Request only initiates an authorization change but does not
initiate re-authentication, a RAR command containing a Re-Auth-
Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be
directly translated to a CoA-Request. A Diameter/RADIUS gateway
receiving a CoA-Request containing authorization changes will need to
translate this into two Diameter exchange. First, the
Diameter/RADIUS gateway will issue a RAR command including a Session-
Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY".
Then the Diameter/RADIUS gateway will respond to the ensuing access
request with a response including the authorization attributes
gleaned from the CoA-Request. For the translation to be possible,
the CoA-Request MUST include a Acct-Session-Id Attribute. If the
Diameter client uses the same Session-Id for both authorization and
acccounting, then the Diameter/RADIUS gateway can copy the contents
of the Acct-Session-Id Attribute into the Session-Id AVP; otherwise,
it will need to map the Acct-Session-Id value to an equivalent
Session-Id for use within a RAR command.
To simplify translation between RADIUS and Diameter, a server
compliant with this specification MAY include a Service-Type
Attribute with value "Authorize Only" within a CoA-Request. Such a
CoA-Request MUST contain a State Attribute. A NAS supporting the
"Authorize Only" Service-Type within a CoA-Request responds with a
CoA-NAK containing a Service-Type Attribute with value "Authorize
Only", and an Error-Cause Attribute with value "Request Initiated".
The NAS will then send an Access-Request containing a Service-Type
Attribute with a value of "Authorize Only", along with a State
Attribute. A Diameter/RADIUS gateway receiving a CoA-Request
containing a Service-Type with value "Authorize Only" translates this
to a RAR with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY".
The received RAA is then translated to a CoA-NAK with a Service-Type
value of "Authorize Only". If the Result-Code AVP in the RAA has a
value in the success category, then an Error-Cause Attribute with
value "Request Initiated" is included in the CoA-NAK. If the
Result-Code AVP in the RAA has a value indicating a Protocol Error or
a Transient or Permanent Failure, then an alternate Error-Cause
Attribute is returned as suggested below.
Within Diameter, a server can request that a session be aborted by
sending an Abort-Session-Request (ASR), identifying the session to be
terminated using Session-ID and User-Name AVPs. The ASR command is
translated to a Disconnect-Request containing an Acct-Session-Id and
User-Name attribute. If the Diameter client utilizes the same
Session-Id in both authorization and accounting, then the value of
the Session-ID AVP may be placed in the Acct-Session-Id attribute;
otherwise the value of the Session-ID AVP will need to be mapped to
an appropriate Acct-Session-Id value. For a Disconnect-Request to
be translatable to an ASR, an Acct-Session-Id attribute MUST be
present. If the Diameter client utilizes the same Session-Id in both
authorization and accounting, then the value of the Acct-Session-Id
may be placed into the Session-ID AVP within the ASR; otherwise the
value of the Acct-Session-Id will need to be mapped to an appropriate
Session-ID value.
An Abort-Session-Answer (ASA) command is sent in response to an ASR
in order to indicate the disposition of the request. A
Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to
an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS". A
Disconnect-NAK received from the server is translated to an ASA
command with a Result-Code AVP which depends on the value of the
Error-Cause Attribute.
Suggested translations between Error-Cause Attribute values and
Result-Code AVP values are included below:
# Error-Cause Attribute Value Result-Code AVP
--- --------------------------- ------------------------
201 Residual Session Context DIAMETER_SUCCESS
Removed
202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS
(Ignored)
401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED
402 Missing Attribute DIAMETER_MISSING_AVP
403 NAS Identification DIAMETER_REALM_NOT_SERVED
Mismatch
404 Invalid Request DIAMETER_UNABLE_TO_COMPLY
405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED
406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED
501 Administratively DIAMETER_AUTHORIZATION_REJECTED
Prohibited
502 Request Not Routable DIAMETER_UNABLE_TO_DELIVER
(Proxy)
503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID
504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED
Removable
505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY
Error
506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED
507 Request Initiated DIAMETER_SUCCESS
Since both the ASR/ASA and Disconnect-Request/Disconnect-
NAK/Disconnect-ACK exchanges involve just a request and response,
inclusion of an "Authorize Only" Service-Type within a Disconnect-
Request is not needed to assist in Diameter/RADIUS translation, and
may make translation more difficult. As a result, inclusion of a
Service-Type of "Authorize Only" within a Disconnect-Request is NOT
RECOMMENDED."
Proposed Resolution: Accept
Issue 208: Issue on Filter-Rules-01
Submitter name: Jouni Korhonen
Submitter email address: jouni.korhonen@teliasonera.com
Date first submitted: November 10, 2006
Reference:
http://ops.ietf.org/lists/radiusext/2006/msg00963.html
Document: Filter-Rule-05, Filter-Rules-01
Comment type: Technical
Priority: S
Section: 2.5 (Filter-Rules),
Rationale/Explanation of issue:
In section 2.5 there's the following text:
Filter-ID (11) and
NAS-Traffic-Rule both define how filters are
to be applied in the NAS. These
attributes are not intended to
be used concurrently and SHOULD
NOT appear in the same RADIUS
message. Only one type of
filtering attribute must be
processed. If a Filter-ID (11)
is present, then the NAS-
Traffic-Rule MUST be ignored,
if present.
I think this text should be align with the equivalent text in
the radext-filter-05 draft. So the text saying
"..SHOULD NOT appear in the same RADIUS message." should be
"..MUST NOT appear in the same RADIUS packet." right?
[Bernard Aboba]
Maybe they both should be "SHOULD NOT be sent". That way if a Diameter gateway sends both they will both be passed through to RADIUS.At the time of RFC 4005 authoring, the NAS-Filter-Rule AVP was not expressable as a RADIUS attribute, as it has the Diameter AVP code of 400. So I doubt that combining the two was intended. Given the current lack of enthusiasm for mapping Diameter into RADIUS, that still may be the case.RFC 4005 Section 6.7 states the following with respect to the Filter-Id AVP: In non-RADIUS environments, it is RECOMMENDED that the NAS-Filter- Rule AVP be used instead. However, since this is a recommendation, it appears possible that an RFC 4005 implementation could send a NAS-Filter-Rule AVP along with aFilter-Id AVP. Based on the current text in the NAS-Filter-Rule document, such a message would not be translatable to an equivalent RADIUS packet.
I think it depends on the next issue. If this technique is now officially frowned on, then it's probably not too strict.Some questions: a. Do you, the esteemed author of RFC 4005 have an opinion on the appropriate normative language for the Section 2 text above? For example, is the "MUST NOT" too strict?
b. Is there a situation in which both the NAS-Filter-Rule and Filter-Id AVPs will need to be sent in a >Diameter message?I suspect that we (some?) believed that some servers might send both, and if the message was headed to an older system, a gateway would strip the NAS-Filter-Rule but take the Filter-ID. Of course this supposes that the Diameter system would have a defined behavior for both the Filter-ID and
Filter-Rule.
This is an area where there is a total lack of vendor standardization. The Xylogics Annex had a filtering command system unlike anything Cisco, Ascend, or 3Com had at the time. Rules typically have some sort of sequential processing assumptions, and to try to combine a predefined set (the Filter-ID definition) with another set (the Filter-Rules) it could be problematic. But the implementor of the new standard rules would have to deal with the native interface somewhere during implementation anyways. So I think any assumption of combining both was not an expectation. However, this problem could be left to the system operator given his configuration & equipment capabilities to decide. So, that may be why there is a lack of totally restrictive language. I think the original intent was to define a new common Filter-Rule for Diameter native systems (something we have not had in the past), while accommodating RADIUS standard attributes and practice. Diameter systems must define how they want to interpret this situation, since it is clearly allowed. It this attribute is also to be implemented in the RADIUS space, then they have the same problem. Sigh... this is another problem where some sort of NAS version number or capabilities field would be useful. I guess the best compromise would be to continue to allow them to be sent together. An older system would ignore the new rule and use the Filter-ID. A newer system would use the new rules (if present) and either ignore the Filter-ID or have it defined as a Non-operation. The provisioning of the rules behind a Filter-ID are still not defined.c. If such a situation exists, how is a NAS to interpret such a message? Does one AVP take precedence? Or are the AVPs combined somehow?
[David Nelson]
That may, in fact, be the best we can do. This seems OK to me.
[Mauricio Sanchez]
What happens in the instance that a diameter->radius gateway can't translate a packet? There must be some exception path, right? If so, why couldn't we leave in the MUST NOT for mixture of filter-id and nas-filter-rule attributes and have the gateway generate an error to avoid wedging both attributes into a radius packet? It just feels wrong to have to carry forward diameter sloppiness.
[Bernard Aboba]
What happens in the instance that a diameter->radius gateway can't translate a packet?RFC 4005 Section 9 describes two situations in which translation may not be possible:
" Although the Diameter protocol is in many ways a superset of RADIUS functions, a number of RADIUS representations are not allowed, so that new capabilities can be used without the old problems. There are primarily two different situations that must be handled: one in which a RADIUS request is received that must be forwarded as a Diameter request, and another in which the inverse is true. RADIUS does not support a peer-to-peer architecture, and server-initiated operations are generally not supported. See [RADDynAuth] for an alternative. Some RADIUS attributes are encrypted. RADIUS security and encryption techniques are applied on a hop-per-hop basis. A Diameter agent will have to decrypt RADIUS attribute data entering the Diameter system, and if that information is forwarded, the agent MUST secure it by using Diameter specific techniques."
My reading of RFC 4005 is that other than these situations, that RADIUS packets are expected to be translatable to Diameter. RADIUS does not have a mechanism to enable a NAS to indicate an error in response to an Access-Accept, so that if RADIUS packets are not translatable it would difficult to communicate this to a RADIUS server. If the NAS does a silent discard, then no Accounting-Request is generated. That's the only indication that a RADIUS server will have that the attributes sent were unacceptable.There must be some exception path, right?
If so, why couldn't we leave in the MUST NOT for mixture of filter-id and nas-filter-rule attributes and have the gateway generate an error to avoid wedging both attributes into a radius >packet?On the Diameter side, behavior will depend on whether the gateway silently discards the RADIUS packet (in which case no error would be sent to the Diameter NAS) or whether it acts as though an Access-Reject were received (in which case the Diameter equivalent of the Reject would be sent to the NAS).
BTW, here is what RFC 2119, Section 6 says about MUST and MUST NOT: " Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability."In this particular case, there does not appear to be an interoperability issue (in fact, the MUST NOT might create an issue), so we are left with assessing the potential for causing harm.
Proposed Resolution: Accept
Issue 209: Add Reference to RFC 3588
Submitter name: Sean Convery
Submitter email address: sconvery@gmail.com
Date first submitted: November 20, 2006
Reference:
http://ops.ietf.org/lists/radiusext/2006/msg00967.html
Document: draft-ietf-radext-filter-05.txt
Comment type: E
Priority: 2
Section: 1
Rationale/Explanation of issue:
For those uninitiated in the specifics of Diameter's document
architecture, it may be useful to add a reference to RFC3588 in the
introduction to this document (in addition to the reference in section
2). Just looking at RFC 4005 doesn't provide you the formatting of the
filter itself. Suggested rewording for section 1, paragraph 1:
This document defines the NAS-Filter-Rule attribute within the Remote
Authentication Dialin User Service (RADIUS). This attribute has the
same functionality as the Diameter NAS-Filter-Rule AVP (400) defined
in [RFC4005] Section 6.6 and the same syntax as an IPFilterRule
defined in [RFC3588] Section 4.3. This attribute may prove useful for
provisioning of filter rules.
This is great functionality, I hope the major vendors implement it.
[Bernard Aboba] The proposed resolution is to change section 1 paragraph 1 to the following:
" This document defines the NAS-Filter-Rule attribute within the Remote
Authentication Dialin User Service (RADIUS). This attribute
has the
same functionality as the Diameter NAS-Filter-Rule AVP (400)
defined
in [RFC4005] Section 6.6 and the same syntax as an IPFilterRule
defined in [RFC3588] Section 4.3. This attribute may prove
useful
for provisioning of filter rules."
Proposed Resolution: Accept
Issue 210: Editorial Comments
Submitter name: Dan Romascanu
Submitter email address: dromasca@avaya.com
Date first submitted: November 30, 2006
Reference:
http://ops.ietf.org/lists/radiusext/2006/msg00989.html
Document: draft-ietf-radext-filter-05.txt
Comment type: E
Priority: S
Section: Abstract, Section 1
Rationale/Explanation of issue:
A couple of editorial comments:
1. Acronyms in the Abstract section should be expanded. In this document
NAS and AVP are present in the Abstract section and not expanded (but
RADIUS is!)
2. In the format description there is no explanation about the Length
field other than saying '>=3'. While this may be normal in a document
where Length is explained some other part, or may be easy to understand
for people familiar with the other RADIUS documents, it is cryptic for
the reader of this document alone. It would be useful to provide at
least a reference for a definition of the Length of a attribute in
another document.
[Bernard Aboba]
Here is a rewritten Abstract: "While RFC 2865 defines the Filter-Id attribute,this requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been
pre-populated, it useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588."Indicating that the Length value is >3 is a way of sayin that a data field of zero length (e.g. Length =2) is not acceptable for the NAS-Filter-Rule attribute.
The proposed resolution is as follows:
Change the Abstract to:
" While RFC 2865 defines the Filter-Id attribute, this requires that
the Network Access Server (NAS) be pre-populated with the desired
filters. However, in situations where the server operator
does not
know which filters have been pre-populated, it useful to specify
filter rules explicitly. This document defines the
NAS-Filter-Rule
attribute within the Remote Authentication Dial In User Service
(RADIUS). This attribute is based on the Diameter
NAS-Filter-Rule
Attribute Value Pair (AVP) described in RFC 4005, and the
IPFilterRule syntax defined in RFC 3588."
Change Section 1 to:
" This document defines the NAS-Filter-Rule attribute within the Remote
Authentication Dialin User Service (RADIUS). This attribute
has the
same functionality as the Diameter NAS-Filter-Rule AVP (400)
defined
in [RFC4005] Section 6.6 and the same syntax as an IPFilterRule
defined in [RFC3588] Section 4.3. This attribute may prove
useful
for provisioning of filter rules.
While [RFC2865] Section 5.11 defines the Filter-Id attribute (11),
this requires that the Network Access Server (NAS) be pre-populated
with the desired filters. However, in situations where the
server
operator does not know which filters have been pre-populated, it
useful to specify filter rules explicitly."
Proposed Resolution: Accept
Issue 211: Review
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: February 22, 2007
Reference:
http://ops.ietf.org/lists/radiusext/2007/msg00049.html
Document: draft-ietf-radext-fixes-01.txt
Comment type: T
Priority: S
Section: 2.6, 2.11
Rationale/Explanation of issue:
Aside from the comments included below, this document looks good.
Section 2.6
Where a NAS offers multiple services, confusion may result with
respect to interpretation of a Disconnect-Request [RFC3576]. In
order to prevent confusion a RADIUS Server SHOULD identify the
session that it desires to terminate as specifically as possible.
For example, an Acct-Session-Id attribute SHOULD be included in
Disconnect-Request and CoA-Request packets, rather than just the
User-Name attribute.
I think this material might better belong in RFC 3576bis.
Section 2.11
An ISP may desire to support Prefix Delegation at the same time that
it would like to assign a prefix for the link between the NAS and the
user. The intent of the paragraph was to enable the NAS to
advertise
the prefix (such as via a Router Advertisement). If the Framed-
Routing attribute is used, it is also possible that the prefix would
be advertised in a routing protocol such as RIPNG.
You might include a reference to the RADIUS Prefix Delegation document
(now in the RFC Editor Queue).
It appears that the Framed-IPv6-Prefix is used for the link between
the NAS and CPE only if a /64 prefix is assigned. When a larger
prefix is sent, the intent is for the NAS to send a routing
advertisement containing the information present in the Framed-
IPv6-Prefix attribute.
Even if a /64 prefix is assigned, I think that the NAS is expected
to send an RA to the CPE, no? Otherwise I'm not sure how the CPE
could learn the prefix.
The other issue is how the CPE obtains a prefix to use for its own
network, in the case that the CPE is decrementing TTL. Prefix
Delegation is the mechanism created for that purpose. If the CPE
is acting as a Bridge or ND-Proxy, then it does not need to request
that a prefix be delegated. It might make sense to say a few words
about this.
[Alan DeKok]
> Section 2.6
>
> Where a NAS offers multiple services, confusion may result with
> respect to interpretation of a Disconnect-Request [RFC3576].
In
> order to prevent confusion a RADIUS Server SHOULD identify the
> session that it desires to terminate as specifically as possible.
> For example, an Acct-Session-Id attribute SHOULD be included in
> Disconnect-Request and CoA-Request packets, rather than just the
> User-Name attribute.
>
> I think this material might better belong in RFC 3576bis.
I have no objections. We should therefore remove references to RFC
3576 from the document, as that paragraph contains the only textual
reference to that document.
...
> You might include a reference to the RADIUS Prefix Delegation document
> (now in the RFC Editor Queue).
OK.
> It appears that the Framed-IPv6-Prefix is used for the link
between
> the NAS and CPE only if a /64 prefix is assigned. When a
larger
> prefix is sent, the intent is for the NAS to send a routing
> advertisement containing the information present in the Framed-
> IPv6-Prefix attribute.
>
> Even if a /64 prefix is assigned, I think that the NAS is expected
> to send an RA to the CPE, no? Otherwise I'm not sure how the CPE
> could learn the prefix.
I believe so, yes.
> The other issue is how the CPE obtains a prefix to use for its own
> network, in the case that the CPE is decrementing TTL. Prefix
> Delegation is the mechanism created for that purpose. If the CPE
> is acting as a Bridge or ND-Proxy, then it does not need to request
> that a prefix be delegated. It might make sense to say a few words
> about this.
I will add a sentence about this.
[Bernard Aboba] In Issue
Proposed Resolution: Accept
Issue 212: Review
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: February 23, 2007
Reference:
http://ops.ietf.org/lists/radiusext/2007/msg00062.html
Document: draft-ietf-radext-rfc3576bis-00.txt
Comment type: T
Priority: S
Section: 1.3, 2.2, 2.3, 5, 6.1
Rationale/Explanation of issue:
Section 1.3 Terminology RFC 3576bis uses different terminology than the RFC 3576 MIBs.Should we change the terminology in RFC 3576bis to utilize the terms defined in the RFC 3576 MIB documents? This would involve changing uses of the term "RADIUS client"/"NAS" to "Dynamic Authorization Server (DAS)" and "RADIUS server" to "Dynamic Authorization Client (DAC)". Here are the definitions of these terms from RFC 4673 Section 1.2:
Dynamic Authorization Server (DAS)
The component that resides on the NAS that processes the Disconnect
and Change-of-Authorization (CoA) Request packets [RFC3576] sent by
the Dynamic Authorization Client.
Dynamic Authorization Client (DAC)
The component that sends Disconnect and CoA-Request packets to the
Dynamic Authorization Server. Although this component often resides
on the RADIUS server, it is also possible for it to be located on a
separate host, such as a Rating Engine.
Dynamic Authorization Server Port
The UDP port on which the Dynamic Authorization Server listens for
the Disconnect and CoA requests sent by the Dynamic Authorization
Client.
Section 2.2
The following attributes MAY be sent in a CoA-Request:
Filter-ID (11) - Indicates the name of a data filter list
to be applied for the session that the
identification attributes map to.
NAS-Filter-Rule (TBD) - Provides a filter list to be applied
for the session that the identification
attributes map to.
Maybe we should include a reference to the NAS-Filter-Rule RFC? Also, the TBD
should be filled in when an attribute number is assigned.
Section 2.3
Packets received with an invalid Code field MUST be
silently discarded. RADIUS codes (decimal) for this extension are
assigned as follows:
40 - Disconnect-Request [RFC2882]
41 - Disconnect-ACK [RFC2882]
42 - Disconnect-NAK [RFC2882]
43 - CoA-Request [RFC2882]
44 - CoA-ACK [RFC2882]
45 - CoA-NAK [RFC2882]
Rather than citing RFC 2882 for the command allocation, RFC 3575 should be cited
instead. The reference to RFC 2882 can be removed.
Section 2.3
In Disconnect and CoA-Request packets, all Attributes are treated
as mandatory. A NAS MUST respond to a CoA-Request containing one
or more unsupported Attributes or Attribute values with a CoA-NAK;
a Disconnect-Request containing one or more unsupported Attributes
or Attribute values MUST be answered with a Disconnect-NAK.
RFC 3576 suggests use of the Event-Timestamp for replay protection. This
requires synchronized clocks, but even when that it is available, the replay
window is quite large. The solution (discussed in Issue 139) was to add a Nonce
attribute. However, the text above suggests that implementations sending a Nonce
attribute to a legacy implementation in a CoA-Request/Disconnect-Request will
receive a CoA-NAK or Disconnect-NAK in return. Unfortunately, the Error-Cause
attribute value Unsupported Attribute (401) doesn't provide a hint of what the
offending attribute was. Maybe we should add text suggesting that a Nonce
attribute should only be sent by a RADIUS server to a NAS that is known to
support it?
As a result, attributes
beyond those specified in Section 3.5 SHOULD NOT be included
within Disconnect or CoA packets, since this could produce
unpredictable results.
Actually, the results are not unpredictable -- the NAS will send a Disconnect-NAK/CoA-NAK,
right? I would suggest that this sentence be replaced with "As a result, if
attributes beyond those specified in Section 3.5 are included with
Disconnect-Request or CoA-Request packets, the RADIUS server may receive a
Disconnect-NAK/CoA-NAK in response, possibly containing an Error-Cause attribute
with value Unsupported Attribute (401)."
Section 3.3
A summary of the Nonce Attribute format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Is a 32-bit value large enough? Shouldn't this be at least 64-bits and probably
more like 128-bits?
Section 3.5 [Note 8] A Nonce Attribute SHOULD be included in a CoA-Request or Disconnect-Request packet that is not protected by IPsec or does not contain an Event-Timestamp Attribute, so as to prevent replay attacks. A Nonce Attribute MAY also be included in CoA-ACK, CoA-NAK, Disconnect-ACK, Disconnect-NAK, or Accounting-Request packets.It seems like a bad idea for a NAS to include a Nonce attribute in a CoA-ACK, CoA-NAK, Disconnect-ACK or Disconnect-NAK if a Nonce attribue wasn't included in the corresponding CoA-Request or Disconnect-Request.
Section 4
# Error-Cause Attribute Value Result-Code AVP
--- --------------------------- ------------------------
201 Residual Session Context DIAMETER_SUCCESS
Removed
202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS
(Ignored)
401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED
402 Missing Attribute DIAMETER_MISSING_AVP
403 NAS Identification DIAMETER_REALM_NOT_SERVED
Mismatch
404 Invalid Request DIAMETER_UNABLE_TO_COMPLY
405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED
406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED
501 Administratively DIAMETER_AUTHORIZATION_REJECTED
Prohibited
502 Request Not Routable DIAMETER_UNABLE_TO_DELIVER
(Proxy)
503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID
504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED
Removable
505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY
Error
506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED
507 Request Initiated DIAMETER_SUCCESS
Is this mapping of Error-Cause attribute values to Result-Code AVPs correct?
Section 5 IANA Considerations
Much of this section can be deleted since the values were already allocated in
RFC 3576. The only text that seems necessary relates to an allocation for the
Nonce attribute:
This specification does not create any new registries. This document uses the RADIUS [RFC2865] namespace, see <http://www.iana.org/assignments/radius-types>. Allocation of one update for the section "RADIUS Attribute Types" is requested. The RADIUS attribute for which a value is requested is: TBD - Nonce Section 6.1Alan DeKok has pointed out that the RPF check suggested in this section is somewhat cumbersome. Do we have an alternative to suggest?
Proposed Resolution: Discuss
Issue 213: Review
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: February 18, 2007
Reference:
http://ops.ietf.org/lists/radiusext/2007/msg00046.html
Document: draft-ietf-geopriv-radius-lo-10.txt
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Review of draft-ietf-geopriv-radius-lo-10.txt
Overview comments:
Overall, this document includes many normative statements relating
to privacy in a number of sections. As it stands, this makes it very
difficult to understand exactly what privacy support will be provided
in various scenarios. I would strongly urge that these statements
be consolidated into a single section.
In terms of RADIUS protocol usage, there are a few problems
(violation of a MUST NOT provision in RFC 3576, use of non-standard
RADIUS data types, inappropriate use of complex attributes)
There are also a lot of editorial issues that need to be cleaned up.
Given everything, this document requires substantial work before
it would be suitable for publication as an RFC.
Section 1
Wireless LAN (WLAN) access networks are being deployed in public
places such as airports, hotels, shopping malls, and coffee shops by
a diverse set of operators such as cellular network operators (GSM
and CDMA), Wireless Internet Service Providers (WISPs), and fixed
broadband operators.
As noted later on, these attributes are not limited to use with WLAN
networks, but the relationship to user location is probably stronger
with WLAN or LAN access than other access types. I think you need
to talk about this.
When a user executes the network access authentication procedure to
such a network, information about the location and ownership of this
network needs to be conveyed to the user's home network to which the
user has a contractual relationship.
The use of the term "need" seems wrong here, since
one of the goals of the document is to guard the privacy of location
information, only providing it where there is "need to know".
This document describes AAA attributes, which are used by a AAA
client or a AAA proxy in an access network, to convey location-
related information to the user's home AAA server.
The use of the term "AAA" here is a bit confusing. If the attributes
are applicable to both RADIUS and Diameter, this should be explicitly
stated.
Although the proposed attributes in this draft are intended for
wireless LAN deployments, they can also be used in other types of
wireless and wired networks whenever location information is
required.
I'd suggest this paragraph be combined with the first paragraph.
Location information needs to be protected against unauthorized
access and distribution to preserve the user's privacy. [10] defines
requirements for a protocol-independent model for the access to
geographic location information. The model includes a Location
Generator (LG) that creates location information, a Location Server
(LS) that authorizes access to location information, a Location
Recipient (LR) that requests and receives information, and a Rule
Maker (RM) that provides authorization policies to the LS which
enforces access control policies on requests to location information.
I would talk a bit more about the privacy model in general terms, such
as what protections it is designed to provide.
Section 2
Based on today's protocols we assume that the location information is
provided by the access network where the end host is attached. As
part of the network attachment authentication to the AAA server
location information is sent from the AAA client to the AAA server.
Earlier, the document refers to use by a AAA proxy. Could you say
a few words about where the information originates (e.g. may originate
on the NAS, or may be added a proxy). Somewhere it is also worth
stating that existing RADIUS attributes may also provide location
information (e.g. NAS-Identifier).
The authenticated identity might refer to a user, a device or
something else. Although there might often be a user associated
with
the authentication process (either directly or indirectly; indirectly
when a binding between a device and a user exists) there is no
assurance that a particular real-world entity (such as a person)
triggered this process.
Is the distinction between a user, device or machine identity
relevant for the purposes of a privacy discussion? This paragraph
leaves me wondering whether there is a legal distinction that
is relevant to the protocol design.
Since location based authorization is
executed based on the network access authentication of a particular
"user" it might be reasonable to talk about user's privacy within
this document even though scenarios exist where this might not apply
(and device or network privacy might be the better term).
Maybe you need to define the term "user" in the document as being
either a user, device or machine identity in order to clarify this.
Furthermore, the authors believe that there is a relationship between
the NAS (or other nodes in the access network) and the location of
the entity that triggered the network access authentication, such as
the user.
Why? If the NAS is a VPN server, then the user might be located halfway
around the world. Might make more sense to say "depending on the
type of access being provided, there may be a close relationship...."
You might give examples:
1) WLAN has limited range when deployed with an omni-directional
antenna, so user is probably close to the NAS in geospatial
(but not necessarily civil) terms. Also, some WLAN
access points can use "time of arrival" or other processing
techniques to determine user location accurately;
2) In LAN access, the user can't be further away from the switch
than cable length will permit.
3) Dialup or VPN user could be very far away from the NAS;
If you talk about this a bit, it might help clarify why the document
is mostly for WLAN/LAN access.
The NAS might in many cases know the location of the end
host through various techniques (e.g., wire databases, wireless
triangulation). Knowing the location of a network (where the user
or
end host is attached) might in many networks also reveal enough
information about the location of the user or the end host. A
similar assumption is also made with regard to the location
information obtained via DHCP (see for example [4]).
The DHCP case might be analagous to WLAN/LAN, but it is not analagous
to the case of VPN or dialup access where the NAS and user could be
separated by thousands of miles.
This
information might be used by applications in other protocols (such as
SIP [11] with extensions [12]) to indicate the location of a
particular user even though the location "only" refers to the
location of the network or equipment within the network. This
assumption might not hold in all scenarios but seems to be reasonable
and practicable.
I think you need to say that the assumption can be presumed to hold
for certain values of the NAS-Port-Type attribute (e.g. LAN or
WLAN access). In others it may not hold.
Section 3
Location Objects, which consist of location information and privacy
rules, are transported via the RADIUS protocol from the AAA client to
the AAA server. A few attributes are introduced for this purpose,
as
listed in Section 5, whereby delivery to the RADIUS server can happen
during the authentication/authorization phase (described in
Section 3.1), or in the mid-session using the dynamic authorization
protocol framework (described in Section 3.2). This section
describes messages flows for both delivery methods.
To me, it makes more sense to talk about what packets the location
information can be delivered in, rather than "phases". For example,
location is delivered in Access-Request or Accounting-Request packets.
Whether the Access-Request was triggered by dynamic authorization or
a new user login is not important. Also, this paragraph seems to suggest
that dynamic authorization is required to obtain mid-session location
information. Since location can be provided interim accounting packets,
this is not really true. Perhaps the point is that dynamic authorization
allows the information to be provided on demand.
Section 3.1
Figure 1 shows an example message flow for delivering location
information during the network access authentication and
authorization procedure. Upon a network authentication request from
an access network client, the NAS submits a RADIUS Access-Request
message that contains location information attributes among other
required attributes. These attributes are added based on various
criteria (such as local policy, business relationship with
subscriber's home network provider and in case of location
information also by considering privacy policies).
Even though Figure 1 mentions "out of band agreement" the text doesn't
elaborate on what this means.
Since Figure 1 shows location information provided in
an Accounting-Request, the first sentence isn't quite right.
Given the privacy issues, I think you need to qualify what
"location information" means in the second sentence. Do you
mean that the user location is being supplied by the NAS?
I think you need to say something about the default settings
(e.g. location provided, or not?) Backward compatiblity issues
also probably deserve some discussion here. You might say
a few words about when this flow might occur (e.g. challenge-incapable
NAS).
Figure 1 uses the term "Network Access Client" which isn't
defined in terminology or used in other RADIUS RFCs. I would change
all uses of this term to "User".
If the AAA server needs to obtain location information also in
accounting messages then it needs to include a Requested-Info
attribute to the Access-Accept to express that is desired (if privacy
policy allow it) and the Network Access Server SHOULD then include
location information to the RADIUS accounting messages .
I think you should say something about the packets within which the
location information can be delivered in Section 1. Something like:
"This document enables a RADIUS server to request the delivery of
location information within Access-Request packets, or additionally,
within Accounting-Request packets."
Section 3.2
This section is problematic since it specifies RADIUS attribute
usage prohibited by RFC 3576 Section 3, which states:
Where a Service-Type Attribute with value "Authorize Only" is
included within a CoA-Request or Disconnect-Request, attributes
representing an authorization change MUST NOT be included; only
identification attributes are permitted.
If the desire is to change the location information being provided
(e.g. to turn on location in accounting packets, or deliver different
types of location) why couldn't a CoA-Request be sent without an
"Authorization-Only" Service-Type? If the desire is to request
location immediately, couldn't this be encoded in the Request-Info
attribute? There seem to be ways to achieve the goal without
violating RFC 3576.
Later on in the section, it is stated:
Since location information can be sent in accounting records
(including accounting interim records), RFC 3576 [5] is only needed
for authorization changes.
Given this, it would appear that the need to obtain location mid-session
is best met by another technique, and that use of CoA-Request packets
is only a corner case. Given that RFC 3576 is not widely implemented,
I'd expect the accounting approach to be more applicable, at least
without an explanation about why this isn't a good idea (e.g. might
not need location info with each interim accounting update).
Also, this section doesn't talk about when a RADIUS server can
send a CoA-Request containing a Request-Info attribute. Wouldn't
this be restricted to cases where the NAS has previously included
a Location-Information or Challenge-Capable attribute?
Section 4
I'm not clear this section should exist as a standalone entity. It might
be best to delete Section 4.2 entirely and integrate Section 4.1 with
Sections 1 or 2.
Section 4.1
The home network operator requires location information for
authorization and billing purposes. The operator may deny service
if
location information is not available, or it may offer limited
service only. The NAS delivers location information to the home AAA
server.
The location of the AAA client and/or the end host is transferred
from the NAS to the RADIUS server (based on a pre-established
agreement or if the RADIUS server asks for it under consideration of
privacy policies). The NAS and intermediaries (if any) are not
allowed to use that information other than to forward it to the home
network.
Are the terms "NAS" and "AAA client" used interchangeably here? If so,
can we primarily use one term (NAS seems best)?
The NAS and intermediaries (if any) are not
allowed to use that information other than to forward it to the home
network.
Intermediaries (e.g. AAA proxies) sometimes log Accounting-Request
packets, since they may need them for billing purposes. Since billing is
one of the uses of location information, I don't think you can prohibit
that. Also, what does it mean for the NAS to "use" location information?
Some NASes have stable storage, so they might write Accounting-Request
packets to stable storage prior to delivery. Or they might retain
location information in memory. Do you mean that that the NAS or proxies
can't provide the location information to unauthorized parties? Or do you
mean that proxies MUST respect the privacy policies they receive from the
RADIUS server?
The RADIUS server authenticates and authorizes the user requesting
access to the network. If the user's location policies are
available
to the RADIUS server, the RADIUS server MUST deliver those policies
in an Access Accept to the RADIUS client. This information MAY be
needed if intermediaries or other elements want to act as Location
Servers (see Section 4.2). If the NAS or intermediaries do not
receive policies from the RADIUS server (or the end host itself) then
they MUST NOT make any use of the location information other than
forwarding it to the user's home network.
I would name the specific attributes rather than just saying "location
policies". You are essentially saying that some attributes MUST be
included in an Access-Accept packet. The last sentence is somewhat
more specific than just saying "allowed to use that information".
Location Information may also be reported in accounting messages.
Accounting messages are generated when the session starts, stops and
periodically. Accounting messages may also be generated when the
user roams during handoff. This information may be needed by the
billing system to calculate the user's bill. For example, there may
be different tariffs or tax rates applied based on the location.
Unless otherwise specified by authorization rules, location
information in the accounting stream MUST NOT be transmitted to third
parties.
Most of this paragraph probably belongs in Section 1 of the document.
I'm unsure what the last sentence means. I think that the part of
the last sentence from "location..." should probably be combined with
the next sentence, to clarify it:
Location information in the accounting stream MUST only be sent in
the proxy chain to the home network (unless specified otherwise).
For example, you might say "Location attributes contained within
Accounting-Request packets MUST only be made available to entities
on the proxy chain between the NAS and the home accounting
server."
Section 4.2
Location Servers are entities that receive the user's location
information and transmit it to other entities. In this second
scenario, Location Servers comprise also the NAS and the RADIUS
server. The RADIUS servers are in the home network, in the visited
network, or in broker networks.
Unless explicitly authorized by the user's location policy, location
information MUST NOT be transmitted to other parties outside the
proxy chain between the NAS and the Home RADIUS server.
Upon authentication and authorization, the home RADIUS server MUST
transmit the ruleset (if available) in an Access-Accept. The RADIUS
client, intermediate proxies are allowed to share location
information if they received ruleset indicates that it is allowed.
Is a "Location Server" somehow different from an entity eligible
to receive location information as described in the previous section?
I'm unclear whether this section is saying anything different from
Section 4.1 with respect to handling of user location information.
Section 5.1
The Operator-Name attribute SHOULD be sent in Access-Request, and
Accounting-Request records where the Acc-Status-Type is set to Start,
Interim, or Stop.
Is this attribute only sent in these packets? If so, I would say:
"MAY only be sent in Access-Request and Accounting-Request..."
The Value type is restricted to use with Integers. I think that we
are talking about a String here, no?
Section 5.2
The Location-Information attribute SHOULD be sent in Access-Request
and in Accounting-Request messages. For the Accounting-Request
message the Acc-Status-Type may be set to Start, Interim or Stop.
Is the intent that these attributes are only sent in Access-Request
and Accounting-Request messages? If so, say "MAY only be sent in..."
I think you are talking about a String type attribute, not an integer,
right?
The 16-bit unsigned integer value allows to
associate
the Location-Information attribute with
Location-Info-Civic and Location-Info-Geo
attributes.
This is not a complete sentence. I think you need to explain that
this attribute is used to provide information relating to the
information included in the Location-Info-Civic and
Location-Info-Geo attributes to which it refers (via the Index).
You should probably also state that this attribute is largely treated
as an opaque blob, like the Location-Info-Civic and Location-Info-Geo
attributes to which it refers. As a result, it is not expected that
RADIUS servers will need to change code to receive this attribute
(although location applications would have to parse it).
Section 5.3
Location-Info-Civic attribute SHOULD be sent in Access-Request and in
Accounting-Request messages. For the Accounting-Request message the
Acc-Status-Type may be set to Start, Interim or Stop.
Change to "MAY only be sent..." if that is the intent.
Please change "Value" to "String".
The 16-bit unsigned integer value allows to
associate
the Location-Info-Civic attribute with the
Location-Information attributes.
Is there an implication that multiple Location-Information attributes
will have the same Index value? That doesn't make sense to me.
Section 5.4
Location-Info-Geo attribute SHOULD be sent in Access-Request, and
Accounting-Request records where the Acc-Status-Type is set to Start,
Interim or Stop if available.
Change to "MAY only be sent" if that is the intent.
Change "Value" to "String"
Section 5.5
Should the title be "Basic-Policy-Rules Attribute"?
Policy rules control the distribution of location location
information. In some environments the the AAA client might know the
privacy preferences of the user based on pre-configuration or the
user communicated them as part of the network attachment.
This seems somewhat unlikely. Do any existing access protocols support
user-provided privacy policies? Or are we talking about generic
NAS privacy settings here?
Basic-Policy-Rules attribute SHOULD be sent in an an Access-Request,
Access-Accept, an Access-Challenge, an Access-Reject and an
Accounting-Request message.
I think you mean "MAY be sent in an Access-Request..."
o The AAA client SHOULD NOT attach location information in the
initial Access-Request message but should rather wait
for the AAA
server to receive a challenge for location information.
I think you mean "for the AAA server to send an Access-Challenge..."
I think you are instead saying that "absent NAS settings
to the contrary, the default is..." This probably should be clarified.
o If a roamig agreement or legal circumstances require the AAA
roamig -> roaming
client to transfer location information in the initial
Access-
Request message to the AAA server (even though user
specific
policies are not available to the AAA client) then the
access
network attaches default authorization policies.
Are you saying that a Basic Policy Rules attribute MUST accompany
a Location-Information, Location-Info-Geo or Location-Info-Civic
attribute?
The 'retransmission-allowed' flag MUST be set to '0'
meaning
that the location must not be shared with other parties
(other than
forarding them to the user's home network).
Are we saying that sharing of location information is controlled by the
're-transmission-allowed' flag and that parties MUST respect the flag?
This seems to contradict earlier MUST statements (which seem to imply
that sharing is not permitted, regardless of the flag value).
In case the home
network knows the user's privacy policies then these
policies
SHOULD be sent from the RADIUS server to the RADIUS
client in a
subsequent response message and these policies will be
applied to
further location dissemination and in subsequent RADIUS
interactions (e.g., when attaching location information
to
Accounting messages).
What kind of response message? Do you mean Access-Challenge here
or Access-Accept? Is there a reason why a RADIUS server would refuse
to disclose the user's privacy policies? Should those policies
ever be considered private?
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags
| Retention Expires
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retention Expires
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retention Expires
| Note Well
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Note Well
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The design of this attribute is problematic. It is different from
other complex attributes in that it is sent by the RADIUS server,
and the inclusion of timestamps implies that it needs to be computed
dynamically, rather than treated as an opaque blob.
Also, there is an implication elsewhere in the document that the
retransmission bit needs to be respected by RADIUS proxies. Most
existing RADIUS proxies cannot be configured to look at a specific
octet in an attribute, so this will not be possible.
Is there a reason that this could not be split into separate
unitary attributes, say, one for Retransmission, one for
Retention-Expires and another for Privacy-Policy? The "Retention Expires"
attribute would a 64-bit
Long Integer, the Flags would be a 32-bit integer
and the Note Well would be a string.
This would be much more compatible with the design of existing
RADIUS servers and proxies and would enable privacy policies to
be respected.
Section 5.6
The Extended-Policy-Rules attribute SHOULD be sent in an Access-
Request, an Access-Accept, an Access-Challenge, an Access-Reject and
in an Accounting-Request message whenever location information is
transmitted.
Do we mean "MAY be sent" here?
I think "String" should be used here instead of "Value"
Why is Length >=4 (rather than 3)?
Section 5.7
Why is the Challenge-Capable attribute defined if it is always
set to 0? Is the presence of the attribute sufficient to indicate
that the NAS is capable of being challenged so that the value
is irrelevant?
It would make more sense for this to be a 32-bit integer value
that only has a single value defined (1) indicating that the
NAS is capable of being challenged.
Section 5.8
The Requested-Info attribute allows the RADIUS server to indicate
whether it needs civic and/or geospatial location information of the
NAS or the end host (i.e., the entities that are indicated in the
Entity field of the Location-Information attribute).
Can't the RADIUS server ask for both NAS and end host information?
2. If the RADIUS server does not receive the
requested
information in response to the
Access-Challenge (including the
Requested-Info attribute) then
the RADIUS server responds with
an Access-Reject with an
Error-Cause attribute (including the
"Location-Info-Required"
value). Note that an Access-Reject
message SHOULD only be sent if
the RADIUS server MUST use
location information for
returning a positive access control
decision.
The combination of SHOULD and MUST is confusing. I think you mean to
say that an Access-Reject MUST only be sent if the RADIUS server
requires location information, but does not receive it, right?
This is typically the case when location
information is used for inclusion to the user's bill
only.
Rephrase to "is used only for billing".
If the RADIUS server does not send a Requested-Info attribute then
the RADIUS client MUST NOT attach location information to messages to
the RADIUS server. The user's authorization policies, if available,
MUST be consulted by the RADIUS server before requesting location
information delivery from the RADIUS client.
But earlier it is said that the NAS may send location information by
default,
correct? Or is an exception being made?
Figure 11 probably belongs earlier in the document.
The Requested-Info attribute MUST be sent by the RADIUS server if it
wants the RADIUS client to return civic and/or geospatial
information. This Requested-Info attribute MAY appear in the
Access-
Accept or in the Access-Challenge message.
Earlier it seems to imply that the NAS could sent location information
by out-of-band agreement. So do you mean to say "in the absence of
an out-of-band agreement..."?
Requested-Info (64 bits):
This text field contains an integer value that
encodes the
requested information attributes.
Each capability value represents a bit position.
It would be clearer to just say that the Requested-Info attribute
defines a bit field, where the information on CIVIC_LOCATION,
GEO_LOCATION, USERS_LOCATION, and NAS_LOCATION can be requested.
BTW, why is a 64-bit value required? wouldn't 32-bits do as well?
Section 6
If multiple
Location-Information attributes are sent then they MUST NOT contain
the same information.
Does this mean "must not have the same Index field?" Or does it mean
that they must not be identical in all respects?
Section 8.2
o The visited network is able to learn the user's identity.
I think you need a reference to NAI privacy (e.g. RFC 4282 or 4372) here.
Section 8.3
This section interrupts the document flow; it would better belong in
an Appendix.
Section 9
Two entities might act as Location Servers as shown in Section 4, in
Figure 16 and in Figure 17:
I think the sentence should end with a period, not a colon, right?
Section 9.1
In this scenario it is difficult to obtain authorization policies
from the end host (or user) immediately when the user attaches to the
network. In this case we have to assume that the visited network
does not allow unrestricted distribution of location information to
other than the intended recipients (e.g., to third party entities).
When the AAA messages traverses one or more broker networks, the
broker network is bound by the same guidelines as the visited network
with respect to the distribution of location information.
Are you just saying that proxies need to respect the 'retransmission' bit?
In practice, they won't be able to do that because their policy engines
operate at the attribute, not bit level. You'll need to have an
individual attribute for retransmission if you want this to work.
The visited network MUST behave according to the following
guidelines:
o Per default only the home network is allowed to receive location
information. The visited network MUST NOT
distribute location
information to third parties without seeing the user's
privacy
rule set.
Are you saying that the lack of distribution is the default, absent
receipt of privacy policies to the contrary? I'd suggest that this
be stated earlier on.
o If the RADIUS client in the visited network learns the basic rule
set or a reference to the extended rule set by means
outside the
RADIUS protocol (e.g., provided by the end host) then
it MUST
include the Basic-Policy-Rules and the
Extended-Policy-Rules
attribute in the Access-Request message towards the
home AAA
server. Furthermore, the visited network MUST
evaluate these
rules prior to the transmission of location information
either to
the home network or a third party. The visited
network MUST
follow the guidance given with these rules.
This seems quite unlikely. Is there a reference to a specification
where this is proposed?
o If the RADIUS client in the visited network receives the Basic-
Policy-Rules attribute with Access-Accept or the
Access-Challenge
message then the Basic-Policy-Rules MUST be attach in
subsequent
RADIUS messages which contain the Location-Information
attribute
(such as interim accounting messages).
attach -> attached
You need to include this statement in the Attribute Table section 6.
Doesn't it apply to all NASes, not just a visited network?
o If the RADIUS client in the visited network receives the
Extended-
Policy-Rules attribute with Access-Accept or the
Access-Challenge
message then the Basic-Policy-Rules attribute MUST be
attach in
subsequent RADIUS messages which contain the
Location-Information
attribute (such as interim accounting messages).
attach -> attached
I think this needs to be included in the Attribute Table section 6.
Doesn't it apply to all NASes, not just a Visited network?
Section 10
If no authorization information is provided by the user
then the visited network MUST set the authorization policies to only
allow the home AAA server to use the provided location information.
This seems to contradict Figure 1 which shows location
information sent by out-of-band agreement without any policy attributes.
It is necessary to use authorization policies to limit the
unauthorized distribution of location information. The security
requirements which are created based on [10] are inline with threats
which appear in the relationship with disclosure of location
information as described in [33]. PIDF-LO [21] proposes S/MIME to
protect the Location Object against modifications. S/SIME relies on
public key cryptography which raises performance, deployment and size
considerations. Encryption would require that the local AAA server
or the NAS knows the recipient's public key (e.g., the public key of
the home AAA server).
So are we saying that the location information attributes can be encrypted
in some cases, so that the privacy concerns are not applicable? But the
attributes don't support this, right?
Knowing the final recipient of the location
information is in many cases difficult for RADIUS entities.
Specifically, RADIUS clients only deal with RADIUS servers that are one
hop away.
Proposed Resolution: Discuss
Issue 214: Review
Submitter name: Peter Nixon
Submitter email address: listuser@peternixon.net
Date first submitted: February 18, 2007
Reference:
http://ops.ietf.org/lists/radiusext/2007/msg00047.html
Document: draft-ietf-geopriv-radius-lo-10.txt
Comment type: T
Priority: S
Section: 1
Rationale/Explanation of issue:
> The NAS might in many cases know the location of the end
> host through various techniques (e.g., wire databases,
wireless
> triangulation). Knowing the location of a network
(where the user or
> end host is attached) might in many networks also reveal
enough
> information about the location of the user or the end host.
A
> similar assumption is also made with regard to the location
> information obtained via DHCP (see for example [4]).
Also, If you consider 3G/GPRS networks, the NAS that a user connects to is
typically located in the main operations center of the operator which means
that the users location if most likely somewhere inside that country,
however when the user roams (A large and growing number of operator have
GPRS/3G roaming agreements) they could in-fact be connecting via an operator
on the other side of the world, yet the NAS at most will know the IP address
of the SGSN (another device on GSM networks is involved in the whole GPRS
process, of which each operator has at least one) and will not have an real
idea where the user is at all...
Other devices in the network (Billing systems etc) may have an "better" idea
of where the user is (the country for example..) but they also may not know
this information until several weeks or months later (when billing
information is exchanged between operators)
Proposed Resolution: Discuss
Issue 215: Usage of Service-Type in
Disconnect-Request
Submitter name: Avi Lior
Submitter email address: avi@bridgewatersystems.com
Date first submitted: March 14, 2007
Reference:
http://ops.ietf.org/lists/radiusext/2007/msg00141.html
Document: RFC3576bis-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Service-Type = "Authorize-Only" does not make sense for Disconnect
Message.
Description of problem:
Service-Type = "Authorize-Only" was added to make the Change of
Authorization compatible with the Diameter specification.
However, Diameter's ASR message directly correlates with Disconnect
Message, that is, both can be sent by the server to the client.
Therefore, the 3756 semantics for Service-Type = "Authorize-Only"
are not required for Disconnect Message.
Requested change:
Remove the use of Service-Type = 'Authorize-Only' from RFC3576bis
and disallow State in Disconnect Messages. Details follow.
In section 2.1. Disconnect Messages (DM)
*********************************************
Remove the following:
"A NAS MUST respond to a
Disconnect-Request including a Service-Type Attribute with an
unsupported value with a Disconnect-NAK; an Error-Cause Attribute
with value "Unsupported Service" MAY be included."
And remove the following:
"A NAS supporting the "Authorize Only" Service-Type within a
Disconnect-Request responds with a Disconnect-NAK containing a
Service-Type Attribute with value "Authorize Only" and an
Error-Cause
Attribute with value "Request Initiated". The NAS will then
send an
Access-Request containing a Service-Type Attribute with a value of
"Authorize Only", along with a State Attribute. The RADIUS
server
MUST reply to this Access-Request with an Access-Reject.
"
In section: 3. Attributes
**************************
Change:
A Disconnect-Request MUST contain only NAS and session
identification
attributes (see Section 3), as well as Service-Type, Nonce and
State
attributes. If other attributes are included in a Disconnect-
Request, implementations MUST send a Disconnect-NAK; an Error-Cause
Attribute with value "Unsupported Attribute" MAY be included.
To:
A Disconnect-Request MUST contain only NAS and session
identification
attributes (see Section 3), as well as Nonce. If other
attributes are
included in a Disconnect-Request, implementations MUST send a
Disconnect-NAK; an Error-Cause Attribute with value "Unsupported
Attribute" MAY be included.
In section 3.1. State
**********************
Change:
In order to provide a State attribute to the NAS, a server sending
a
CoA-Request or Disconnect-Request with a Service-Type value of
"Authorize-Only" MUST include a State Attribute, and the NAS MUST
include the State Attribute unchanged in the Access-Request.
A NAS
receiving a CoA-Request or Disconnect-Request containing a Service-
Type value of "Authorize-Only" but lacking a State attribute MUST
send a CoA-NAK or Disconnect-NAK and SHOULD include an Error-Cause
attribute with value 402 (Missing Attribute).
To:
In order to provide a State attribute to the NAS, a server sending
a
CoA-Request with a Service-Type value of
"Authorize-Only" MUST include a State Attribute, and the NAS MUST
include the State Attribute unchanged in the Access-Request.
A NAS
receiving a CoA-Request containing a Service-
Type value of "Authorize-Only" but lacking a State attribute MUST
send a CoA-NAK or Disconnect-NAK and SHOULD include an Error-Cause
attribute with value 402 (Missing Attribute).
In section 3.4. Error-Cause
****************************
Change:
"Unsupported Service" is a fatal error sent if a
Service-Type
Attribute included with the Request is sent with
an invalid or
unsupported value.
To:
"Unsupported Service" is a fatal error sent if a
Service-Type
Attribute included with the Request is sent with
an invalid or
unsupported value. Only valid when
performing Change of
Authorization.
Change:
"Request Initiated" is a fatal error sent in
response to a Request
including a Service-Type Attribute with a value
of "Authorize
Only". It indicates that the
Disconnect-Request or CoA-Request
has not been honored, but that a RADIUS
Access-Request including a
Service-Type Attribute with value "Authorize
Only" is being sent
to the RADIUS server.
To:
"Request Initiated" is a fatal error sent in
response to a CoA-Request
including a Service-Type Attribute with a value
of "Authorize
Only". It indicates that the CoA-Request
has not been honored, but that a RADIUS
Access-Request including a
Service-Type Attribute with value "Authorize
Only" is being sent
to the RADIUS server.
In section 3.5. Table of Attributes
***************************************
In the Disconnect Messages Table:
Request ACK NAK
# Attribute
Change:
0-1 0
0-1 6 Service-Type [Note 6]
To:
0 0
0 6 Service-Type
Change:
0-1 0-1
0-1 24 State [Note 7]
To:
0 0
0 24 State
Change NOTE 6 from:
[Note 6] Support for the Service-Type of "Authorize Only" is
OPTIONAL
on the NAS and RADIUS server. A NAS supporting the "Authorize
Only"
Service-Type value within Disconnect-Request or CoA-Request packets
MUST respond with a Disconnect-NAK or CoA-NAK respectively,
containing a Service-Type Attribute with value "Authorize Only",
and
an Error-Cause Attribute with value "Request Initiated". The
NAS
then sends an Access-Request to the RADIUS server with a
Service-Type
Attribute with value "Authorize Only". This Access-Request
SHOULD
contain the NAS attributes from the Disconnect or CoA-Request, as
well as the session attributes from the Request legal for inclusion
in an Access-Request as specified in [RFC2865], [RFC2868],
[RFC2869]
and [RFC3162]. As noted in [RFC2869] Section 5.19, a Message-
Authenticator attribute SHOULD be included in an Access-Request
that
does not contain a User-Password, CHAP-Password, ARAP-Password or
EAP-Message Attribute. The RADIUS server should send back an
Access-
Accept to (re-)authorize the session or an Access-Reject to refuse
to
(re-)authorize it.
A NAS that does not support the Service-Type Attribute with the
value
"Authorize Only" within a Disconnect-Request MUST respond with a
Disconnect-NAK including no Service-Type Attribute; an Error-Cause
Attribute with value "Unsupported Service" MAY be included. A
NAS
that does not support the Service-Type Attribute with the value
"Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
including no Service-Type Attribute; an Error-Cause Attribute with
value "Unsupported Service" MAY be included.
To:
[Note 6] Support for the Service-Type of "Authorize Only" is
OPTIONAL
on the NAS and RADIUS server. A NAS supporting the "Authorize
Only"
Service-Type value within a CoA-Request packet
MUST respond with a CoA-NAK,
containing a Service-Type Attribute with value "Authorize Only",
and
an Error-Cause Attribute with value "Request Initiated". The
NAS
then sends an Access-Request to the RADIUS server with a
Service-Type
Attribute with value "Authorize Only". This Access-Request
SHOULD
contain the NAS attributes from the CoA-Request, as
well as the session attributes from the Request legal for inclusion
in an Access-Request as specified in [RFC2865], [RFC2868],
[RFC2869]
and [RFC3162]. As noted in [RFC2869] Section 5.19, a Message-
Authenticator attribute SHOULD be included in an Access-Request
that
does not contain a User-Password, CHAP-Password, ARAP-Password or
EAP-Message Attribute. The RADIUS server should send back an
Access-
Accept to (re-)authorize the session or an Access-Reject to refuse
to
(re-)authorize it.
A NAS
that does not support the Service-Type Attribute with the value
"Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
including no Service-Type Attribute; an Error-Cause Attribute with
value "Unsupported Service" MAY be included.
Change:
[Note 7] The State Attribute is available to be sent by the RADIUS
server to the NAS in a Disconnect-Request or CoA-Request packet and
MUST be sent unmodified from the NAS to the RADIUS server in a
subsequent ACK or NAK packet. If a Service-Type Attribute
with value
"Authorize Only" is included in a Disconnect-Request or CoA-Request
then a State Attribute MUST be present, and MUST be sent unmodified
from the NAS to the RADIUS server in the resulting Access-Request
sent to the RADIUS server, if any. The State Attribute is
also
available to be sent by the RADIUS server to the NAS in a CoA-Request
that also includes a Termination-Action Attribute with the value of
RADIUS-Request. If the client performs the Termination-Action
by
sending a new Access-Request upon termination of the current
session,
it MUST include the State Attribute unchanged in that
Access-Request.
In either usage, the client MUST NOT interpret the Attribute
locally.
A Disconnect- Request or CoA-Request packet must have only zero or
one State Attribute. Usage of the State Attribute is
implementation
dependent. If the RADIUS server does not recognize the State
Attribute in th