This is a recap of status for Issue 101 (raised by Pasi Eronen), which consists of a number of sub-issues. All sub-issues are considered to have an acceptable action proposal and unless we hear otherwise, the action will be taken.
------------------------------------------------------------
Issue 101-1
Description: Section 1.1 contains some unnecessary terminology that is not used anywhere later in the document: "Access Point (AP)", "Association", "Port Access Entity (PAE)", "Station (STA)"
Discussion: Paul Congdon accepted recommentation on 9/13/05. Pasi Eronen accepted on 9/14/05.
Action: Remove unused terminology from section 1.1 as noted in issue description.
-------------------------------------------------------------
Issue 101-2
Description: Section 2.2: "If accounting is enabled on the NAS, it MUST generate an Accounting-Request (Stop) message upon session termination."
So the NAS must send a Stop message, even though it has not sent a Start message for this session yet? RFC 2866 seems suggest that a session always has a Start message before Stop, but does not seem to outright prohibit sending a stand-alone Stop
message. Is this a common practice, or are there any problems associated with it?
Discussion: 9/13/05 - Paul asserted that this behavior of not sending a start before the stop should not be an issue. 9/14/05 - Pasi was happy with proposal
Action: No change; leave text as is
-------------------------------------------------------------
101-3
Description: Section 3.1: 802.1Q does not use the abbreviation "VLANID" but rather "VID". Should this document also follow that convention? (but maybe VLANID is more understandable)
Discussion: 9/13/05 - Paul says, "Yes, 802.1Q most often uses VID for VLAN Identifier. It sometimes uses VLAN ID (with a space). However, RFC 3580 uses VLANID and since this document is most likely used in conjunction with RFC 3580, I suggest we just leave VLANID as is." 9/14/05 - Pasi was happy with propsal.
Action: No change; leave text as is
-------------------------------------------------------------
101-4
Description: Section 3.1: "Padding bits SHOULD be 0 (zero)." Why "SHOULD" instead of "MUST"? (according to RFC 2119, it would mean there are valid reasons to send something else in some circumstances?) (This same issue occurs also in Section 4.2.)
Discussion: 9/13/05 - Paul says, "This can be changed to MUST. The desired behavior, IMO, is to require the bits to be set to 0, but not require them to be checked on receipt. The simple MUST or SHOULD wording doesn't really reflect this, so it is probably best that we make this a MUST. Agree to change this SHOULD to a MUST here and in 4.2" 9/14/05 - Pasi was happy with proposal.
Action: Change SHOULD to MUST per issue description.
-------------------------------------------------------------
101-5
Description: Section 3.3: If VLAN-Name has basically the same meaning as Egress-VLANID, IMHO their names should reflect this. Perhaps "Egress-VLAN-Name"?
Discussion: 9/13/05 - Paul says, "Sure, no objection. Change the name of the VLAN-Name attribute to Egress-VLAN-Name everywhere in the document." 9/14/05 - Pasi was happy with proposal.
Action: Several document edits to change 'VLAN-Name' attribute to 'Egress-VLAN-Name'.
-------------------------------------------------------------
101-6
Description: Using "START OF HEADING" (0x01) and "START OF TEXT" (0x02) control characters to indicate tagged/untagged might make it unnecessarily difficult to enter this attribute in a management interface... maybe something like 0x74/0x75 ("t"/"u") or 0x31/0x32 ("1"/"2") would be easier?
Discussion: 9/13/05 - Paul asserts that desire exists to have Egress-VLANID and Egress-Vlan-Name to have as similar format as possible. Moreover, Paul feels 0x01/0x02 do not waste bits. He proposes no change. 9/14/05 - Pasi contends that 0x31/0x32 do not waste bits and would not prevent additional code values to be defined in the future. 9/14/05 - Paul acquieces and accepts Pasi's recommendation of using 0x31/0x32 variant.
Action: Change the one-byte field that specifies tagged/untagged for Egress-VLANID (section 3.1) and Egress-VLAN-Name (section 3.3) from 0x01/0x02 to 0x31/0x32.
-------------------------------------------------------------
101-7
Description: Section 3.3 Probably should have reference to UTF-8? [RFC3629]
Discussion: 9/13/05 Paul says, "yes, Add a reference to [RFC3629] here and then a formal reference in section 8." 9/14/05 - Pasi was happy with proposal.
Action: In section 3.3, addd reference to RFC3629 and in section 8, add an informative reference to RFC3629.
-------------------------------------------------------------
101-8
Description: Section 3.4: "The table, expressed as an 8 octet string, maps the incoming priority (if one exists - the default is 0) into one of seven regenerated priorities." If the regenerated priority is an integer in range 0-7, should that be "eight regenerated priorities"?
Discussion: 9/13 Paul says, "yes, change to "eight regenerated priorities." 9/14 - Pasi was happy with proposal
Action: Change affected sentence to "…eight regenerated priorities."
-------------------------------------------------------------
101-9
Description: Pasi recommends an alternative bit figure format for section 3 and 4.
Discussion: 9/13 - Paul expresses concerns that there would many changes necessary to the document. 9/14 - Pasi outlines a series of changes limited to sections 3.1, 3.3, and 4.1. 9/14 - Paul accepts recommendation
Action: Make changes to document per Pasi's recommendation:
- combining the two figures in 3.1
- fixing the figure in 4.1 (explicitly show that the attribute
contains both a 64-bit counter and a string according to
NAS-Filter-Rule; calling the counter a part of the string
is misleading, since it doesn't even consist of printable
characters...)
- Add figure to section 3.3 (explicitly showing that the
attribute contains two different items)
-------------------------------------------------------------
101-10
Description: If the semantics of Acct-EAP-Auth-Method are identical to Diameter EAP (as Section 4.2 claims), then it can
also be included in Access-Accept messages. (Or if it can't, then the semantics are not identical, and need to be described
in this document.)
Discussion: 9/13 - Paul points out Acct-EAP-Auth-Method is slated to be removed from document entirely
Action: None for this issue; 'acct-EAP-auth-method' to be removed because of issue 114.
-------------------------------------------------------------
101-11
Description: Section 7: It looks like this security considerations section was just copied from somewhere without much thought for how well it actually applies to this document. Most of the text looks redundant to me; we don't need to describe how to use IPsec with RADIUS in every document that defines a new RADIUSattribute.
On the other hand, there's exactly zero discussion about newthreats caused by the attributes defined in _this_ document.
And to me it looks like there are new attacks that e.g. a malicious or compromised RADIUS server or proxy could do with
these attributes (compared to the situation where NAS does not support these attributes). At least Egress-VLANID,
Ingress-Filters and NAS-Filter-Rule have some pretty obvious possibilities for abuse... (and maybe some non-obvious as well)
Discussion: 9/13 - Paul asks Posi to suggest new wording 9/14 - Posi puts forth a suggested wording 9/14 - Paul takes Posi recommended wording and weaves into existing section 7 wording. 9/15 - Posi contends his wording was supposed to be wholesale replacement of section 7, not an addition. 9/15 - Paul recommends at least some intro wording to Posi's original suggested wording and puts forth yet another suggested wording 9/16 - Posi accepts Paul's latest suggestion 9/16 Paul asks for confirmation from mailing list 9/16 - Emile van Bergen seconds the wording
Action: Replace existing section 7 wording suggested by Paul on 9/15.
-------------------------------------------------------------
101-12
Description: References: Both 802.1Q and .1D look normative to me, but RFC1321 and 802.11i probably are just informative.
Discussion: 9/13 - Paul accepts Posi's recommendation and proposing swaping reference locations.
Action: Swap refrence locations to make 802.1Q and 802.1D informative and make RFC1321 and 802.11i informative.
-------------------------------------------------------------
101-13
Description: Document cites [DiamEAP] and [NASREQ], but they're not included in the references section. Both are
normative.
Discussion: 9/13 - Paul accepts Posi's recommendation to add both to the references section
Action: Add [DiamEAP] and [NASREQ] to the references section.
--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
Procurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5555
Roseville CA, 95747-5557
916.785.1910 Tel
916.785.1815 Fax
mauricio.sanchez@hp.com
--------------------------------------------