[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mobile IP support: draft-adrangi-radius-attributes-extension-00.t xt
Hi,
I have a question regarding the Mobile IP HA support in Farid's draft:
Although adding attributes for carrying MIP HA address and IP addresses may be enough for support of base MIP RFC. Many other attributes would be required to support MIP-AAA specs are coming out. Given that Diameter-MIP application provides a large number of AVPs for this and it seems that Diameter compatibility is now a must for RADIUS extensions, shouldn't we allow for more MIP related information to be carried by RADIUS?
Since new data models are being planned, may be we should allow a VSA type attribute that can carry multiple pieces of information for Mobile IP support.
How does that sound?
Regards,
Madjid
-----Original Message-----
From: owner-radiusext@ops.ietf.org
[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Jari Arkko
Sent: Wednesday, June 02, 2004 8:27 AM
To: Adrangi, Farid; radiusext@ops.ietf.org
Subject: comments on draft-adrangi-radius-attributes-extension-00.txt
Hi Farid et al,
Most of the functions in this draft appear valid
and useful. I do have a number of comments again,
however ;-) Some of these comments have to do with
the User Alias Identity. I'm uncertain whether
it should be done like this, or if the existing User-Name
AVP is sufficient. Certainly the way that its now specified
in the draft appears to have some privacy issues. Other set
of comments involves making these attributes work with
Diameter too (surprisingly, even the RADIUS capabilities
discovery may be useful for Diameter). I also have
some issues with the 1-byte long enumerated fields.
In more detail:
Substantial:
> This document describes additional Remote Authentication Dial In
> User Service (RADIUS) [1] attributes for use of RADIUS AAA
> (Authentication, Authorization, Accounting) in both Wireless and
> wired networks.
This is otherwise OK abstract, but I would like to have
it say something more about what the attributes do. Also
make it less-RADIUS specific. How about this:
This document describes additional Authentication, Authorization,
Accounting (AAA) attributes for network access. It provides
an IPv4 address type control mechanism, mobile IPv4 home
agent discovery mechanism, and a RADIUS capabilities discovery
mechanism.
> 2. Operation
>
> Operation is identical to that defined in [1] and [2].
Like in the other draft, this seems to say very little.
How about deleting this and adding the following text
to the end of the Introduction: "This document assumes
that the RADIUS protocol operates as specified in [1, 2]
and that the Diameter protocol operates as specified in
[RFC 3588, NASREQ, EAP].
> This document describes a number of additional attributes that are
> needed to enable use of RADIUS AAA in various types of access
> network in an interoperable manner.
First some editorials: s/access network/access networks/
and s/RADIUS AAA/the RADIUS and Diameter AAA protocols/.
Then to the substantive comment: I'm not sure I understand
what is claimed here. Is this the draft that makes RADIUS
interoperable? I'm pretty sure it adds new features.
It certainly is likely that this specification is more
interoperable than the existing VSAs, but lets state that
then:
This document describes a number of additional attributes
for the RADIUS and Diameter AAA protocols. These attributes
are needed to provide <a set of functions> for wired and
wireless access networks. Some of these functions already
exist as vendor-specific solutions, but it is expected that
this draft makes these functions interoperable among different
vendors.
> 2.1 RADIUS Support for Specifying User Alias Identity
>
> Rationale
> In certain authentication methods such as, EAP-PEAP or EAP-
> TTLS, the true identity of the subscriber is hidden from the
> RADIUS AAA infrastructure. In these methods the User-name(1)
> attribute contains an anonymous identity sufficient to route
> the RADIUS packets to the home network but otherwise
> insufficient to identify the subscriber. While this mechanism
> is good practice there are situations where this creates
> problems. For example, in certain roaming situations
> intermediaries and visited network require to be able to
> correlate an authentication session with a user identity; A
> broker may require to implement a policy where by only session
> is allowed per user entity. Third party billing brokers may
> require to match accounting records to a user identity.
>
> The User Identity Alias provides a solution to the above
> problem. When the home network assigns a value to the User
> Identity Alias it asserts that this value represents a user in
> the home network. The assertion should be temporary. Long
> enough to be useful for the external applications and not too
> long to such that it can be used to identify the user.
Here's what RFC 3579 says: "The User-Name attribute within the Access-
Accept packet need not be the same as the User-Name attribute in the
Access-Request."
I wonder if this could be used to implement the functionality that
you want, without adding a new attribute. But you could still
include the explanation of the problem and guidelines for the
servers.
> When the home network assigns a value to the User
> Identity Alias it asserts that this value represents a user in
> the home network. The assertion should be temporary. Long
> enough to be useful for the external applications and not too
> long to such that it can be used to identify the user.
(snip)
> 00 � reserved
> 01 � IMSI
> 02 � NAI
> 03 � E.164 number
> 04 � SIP URL (as defined in [13])
> 05 � Opaque string
I find the first statement and types 1, 3, and 4
contradictory. This appears to be another reason why
the RFC 3579 approach might be better. Alternatively,
define the opaque string case only.
(Type 2 is problematic too if not constructed the right way.)
> 2.2 RADIUS Support for Advertising Application-based capabilities
I would add the following text somewhere: This discovery also
enables a Diameter translation agent to discover
whether it can initiate these functions and expect them to
succeed when translated to RADIUS. This attribute SHOULD
be translated as is to Diameter, to enable the server
make these decisions as well. A translation agent
converting a Diameter AAR command to a RADIUS Access-Request
packet SHOULD include this attribute iwith the
value <TBD> to indicate that Diameter can support, for instance,
dynamic authorization.
> This attribute indicates IPv4 address type options. It can be
> present in Access-Request, Access-Accept, and Accounting-
> Request records where the Acc-Status-Type is set to Start or
> Stop. When it is used in an Access-Accept and Accounting-
> Request packets, the Address Type value MUST be 1 or 2.
RADIUS-specific. Suggested rewrite:
This attribute indicates IPv4 address type options. In RADIUS,
it can be present in Access-Request, and Access-Accept messages.
In Diameter, it can be present in AAR, AAA, and RAR commands. In
both protocols, it can be present in
Accounting-Request messages where the Acc-Status-Type is set to Start or
Stop. When it is used in an Access-Accept and Accounting-
Request packets, the Address Type value MUST be 1 or 2.
> A RADIUS server includes
> this attribute in the Access-Accept to specify an IP address
> type option for the PWLAN client.
Rewrite:
A server includes this attribute in the RADIUS Access-Accept
packet or Diameter AAA and RAR commands to specify an IP address
type option for the PWLAN client.
> A RADIUS server MUST NOT include this attribute in the Access-
> Accept if the IP Address Type options were not advertised in
Why? Seems like this adds a rule to the server side, but
sending an attribute which the NAS will ignore does not
seem to harm anyone. Or am I missing something?
> the Access-Request. If an invalid IP Address Type option is
> received in the Access-Accept, then the AN MUST use its default
> IP Address Type option for the client. Otherwise, the AN MUST
In the other document an invalid attribute resulted in an
Access-Reject. Why is this different?
> assign an IP address according to the specified type option.
> In either case it MUST include this attribute in Accounting-
> Request packets to indicate the used IP address type option.
Which one? The one that the server sent, or the one that the NAS
chose?
> If an IP address type option is not specified in the Access-
> Accept, the NAS MUST NOT include this attribute in Accounting-
> Request packets.
s/Access-Accept/RADIUS Access-Accept or Diameter RAR and
AAA commands/
> This draft introduces new RADIUS Attributes. Therefore, there is
> a need for obtaining new attribute TYPE numbers from IANA.
I think the document should also say something about the
future allocations in the defined enumerated spaces.
How about this additional text:
New enumerated values within the attributes defined here
can be allocated using the policies defined in RFC 3575,
i.e., Designated Expert.
> 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 |IP Address Type|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
(snip)
> Length
>
> 1
This does not seem to match the usual (?) RADIUS style
where integer/enumerated attributes have a 32-bit
integer.
> The format of this Integer is as follows:
>
> 0xCCCTSSSS
>
> Where:
> CCC is a 12-bit indicator that identifies the capability ID.
(snip)
> SSSS is 16-bit indicator that identifies the sub-capabilities ID.
Uh oh. This is getting pretty complicated, and requires server
side code (not just regexp) to handle. Are we really, really
sure that we couldn't survive without the sub-capability IDs?
Editorial:
> 4. Security Considerations
>
> The attributes in this document have no additional security
> considerations beyond those already identified in [?].
Missing reference.
> PWLAN client
This seems a bit too WLAN specific. Just say network access
client.
(Multiple places.)
> RADIUS Attributes Extension
A bit generic name for the system.
> and sever are
s/sever/server/
> 2.1 RADIUS Support for Specifying User Alias Identity..............2
> 2.2 RADIUS Support for Advertising Application-based capabilities..4
> 2.3 RADIUS Support for Specifying a Mobile IP Home Agent...........6
> 2.4 RADIUS Support for Specifying IP Address Type Options..........7
Suggest s/RADIUS Support for Specifying// and
s/RADIUS Support for Advertising/ in order to make
the titles short.
> Remote Access Dial In User Service (RADIUS) [1],[2],[3] is the
> dominant Authentication, Authorization, and Accounting (AAA)
> protocol in use across broadband wireless and wired networks
> globally.
True, but not really relevant to the specification task at hand.
Suggestion: delete paragraph. Move references to the next paragraph.
> user�s
Non-ASCII char.
> 00 � reserved
> 01 � IMSI
> 02 � NAI
> 03 � E.164 number
> 04 � SIP URL (as defined in [13])
> 05 � Opaque string
>
Non-ASCII char.
> later be indicated to the client through several means � for
> example, it can be relayed in the �home agent address� field of
Non-ASCII chars.
> Authors� Addresses
Non-ASCII char.
--Jari
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>