[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Review of Issue: Review of draft-chowdhury-mip6-radius-02
Hi Pasi,
Thanx for the review. I belive we have addressed most of your comments.
The responses are enclosed. The comments were addressed in
ietf-mip6-radius-01.txt
There are some issues that were not addressed. Take a look at: 7, 11
and 13.
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").
[Avi] Sounds like a good idea. The attributes are now called:
MIP6-HA
MIP6-HA-FQDN
MIP6-HL-Prefix
MIP6-HOA
DNS-Update-MO
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.
[avi] The following attributes MAY be included in RADIUS Accounting
Packets:
MIP6-HA so that backoffice may know which is the serving HA for this
session.
MIP6-HA-FQDN same reason as above (one or the other or both maybe used)
MIP6-HOA so that the backoffice may know the IP address of the MN.
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).
[avi] I agree. Done.
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).
[avi] The difference is Prefix-Length. Done.
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).
[avi] Seems reasonable. Done.
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".
If we don't use two attributes as suggested by comment 7 then reword:
FQDN of the mobile node:
The data field MUST contain a FQDN as described in [9].
TO:
In an Access-Request the data field MUST contain a FQDN. In an
Access-Accept the FQDN MAY contain a FQDN. FQDN is as specified in [9].
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.
[avi] Okay. BTW CUI didnt do this. If we try to econmomize radius
attributes then lets not do this. Otherwize why not.
Not done.
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."
[Avi] Seems okay. Done.
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).
We kept the attributes in the Access-Request.
They can act as a hint to the RADIUS server that a) the NAS supports
dynamic HA assignment and b)
they can be a suggestion as to what values should be used when the
RADIUS server does assing the
HA in the visited network. The RADIUS server may use these values or
may use other values.
10) Section 8: The table should probably include accounting messages and
CoA-Request as well.
[avi] Done. Not sure if we need anything in COA since I cant think of
any dynamic "actions".
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).
[avi] Service Type we should not touch. NAS-Port-Type should be
HA-MIP6 or something like that.
We need to find out what is going on in Diameter with this.
Not sure about calling Station-ID or Called Station id, I don't think we
should specify anything for those. SDOs or specific deployements may
use those attributes.
12) The document talks about doing EAP authentication over RADIUS, but
never mentions RFC 3579?
[avi] Add an informational reference to 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.
[Avi] What do you mean by that? In the split scenario this document
does not send an MSK to the HA.
[Avi] I don't think we should specify how the MSK is carried. The
specific EAP methods do that see EAP-AKA EAP-TLSbis etc...
We could say in the absence of a method to transport MSK, the method
specified by RFC 2548 SHOULD be used.
Note that that is not enough, since we have to specify what goes in the
SEND KEY and RECEIVE KEY.
14) The document should probably have at least informative reference to
RFC 4306.
[avi] Sure. Done.
15) And last (but not least, as everyone who has followed RADEXT knows
:-): the document does not have a Diameter considerations section.
Done From vlan06.txt Modified for our purposes.
Diameter Considerations
When used in Diameter, the attributes defined in this specification
can be used as Diameter AVPs from the Code space 1-255 (RADIUS
attribute compatibility space). No additional Diameter Code values
are therefore allocated. The data types and flag rules for the
attributes are as follows:
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
| | |SHLD| MUST| |
Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|
-------------------------------|----+-----+----+-----|----|
HA-IPv6 Address | M | P | | V | Y |
HA-FQDN UTF8String | M | P | | V | Y |
Home-Link-Prefix OctetString| M | P | | V | Y |
HOA-IPv6 Address | M | P | | V | Y |
DNS-UPDATE-TYPE OctetString| M | P | | V | Y |
-------------------------------|----+-----+----+-----|----|
Other than HA-IPv6 and HOA-IPv6, the attributes in this specification
have no special translation
requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
they are copied as is, except for changes relating to headers,
alignment, and padding. See also [RFC 3588] Section 4.1 and [RFC
4005] Section 9. HA-IPv6 and HOA-IPv6 must be translated between
their RADIUS representation of String to a Diameter Address format
which requires that the AddressType field be set to 2 for IP6 (IP
version 6)
What this specification says about the applicability of the
attributes for RADIUS Access-Request packets applies in Diameter to
AA-Request [RFC 4005] or Diameter-EAP-Request [RFC 4072]. What is
said about Access-Challenge applies in Diameter to AA-Answer [RFC
4005] or Diameter-EAP-Answer [RFC 4072] with Result-Code AVP set to
DIAMETER_MULTI_ROUND_AUTH.
What is said about Access-Accept applies in Diameter to AA-Answer or
Diameter-EAP-Answer messages that indicate success. Similarly, what
is said about RADIUS Access-Reject packets applies in Diameter to AA-
Answer or Diameter-EAP-Answer messages that indicate failure.
What is said about COA-Request applies in Diameter to Re-Auth-Request
[RFC 4005].
What is said about Accounting-Request applies to Diameter Accounting-
Request [RFC 4005] as well.
========================
Avi Lior
Bridgewater Systems Corporation
Phone : +1 (613) 591-9104 x6417
Cell : +1 (613) 796-4183
E-mail : mailto:avi@bridgewatersystems.com
<mailto:avi@bridgewatersystems.com>
www.bridgewatersystems.com <http://www.bridgewatersystems.com/>
--
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/>