draft-ietf-l2tpext-radius-ext-nas-port-00 comments
Carlos Pignataro <[email protected]>
| Newsgroups | gmane.ietf.l2tpext |
|---|---|
| Organization | cisco Systems, Inc. |
| Message-ID | <[email protected]> |
Hi,
Please find a few review comments on
http://tools.ietf.org/id/draft-ietf-l2tpext-radius-ext-nas-port-00
Group, please read and comment.
~~~~~
Abstract
This document defines additional Layer 2 Transfer Protocol (L2TP) and
s/Transfer/Tunneling/
~~~~~
Abstract
This document defines additional Layer 2 Transfer Protocol (L2TP) and
Remote Authentication Dial In User Service (RADIUS) Attribute-Value
Pairs (AVPs) to communicate Network Access Server (NAS) informational
ASCII text and port usage information between L2TP peers during call
Why ASCII if the AVP definition allows for strings in UTF-8 charset
(strings internationalized)?
~~~~~
1. Introduction
...
Authorization
to restrict users to particular given access types or
interfaces.
This seems like a significant difference from the objective stated in
several other parts throughout the document, which is only for logging
purposes to aid in debugging and troubleshooting (i.e., the protocol
takes no action due to the values in these AVPs).
~~~~~
1. Introduction
...
L2TP [RFC2661] already has a Physical Channel ID AVP that may be used
to provide port usage information. However, its usefulness is
There is no reference to L2TPv3 [RFC3931], and I believe these AVPs
should also apply to L2TPv3 (also including the Physical Channel ID
AVP), with a normative reference.
~~~~~
1. Introduction
...
This makes the task of de-constructing the Physical Channel ID AVP
contents at the LNS for (RADIUS) authorization/accounting server
extremely difficult.
That deconstruction should likely not happen for authorization (or other
reasons), from RFC2661 and RFC3931:
Physical Channel ID is a 4 octet value intended to be used for
logging purposes only.
~~~~~
2. L2TP Extended NAS-Port AVPs
...
o Each AVP has defined behaviour associated with it, namely:
This bullet should include a pointer to the actual definitions in
l2tpext-tunnel-switching. This section should use those definitions and
explain how they relate to the new AVPs.
~~~~~
2. L2TP Extended NAS-Port AVPs
Relayed AVPs: See [I-D.ietf-l2tpext-tunnel-switching] for
definition. In summary, if this AVP is received by a node
participating in a multi-hop scenario, then the AVP MUST be
copied as-is to the next hop. A locally generated AVP MAY be
generated if required and appended in the outbound message to
the next hop.
The definition of Relayed (pass-through) AVPs doesn't seem to allow for
the "MAY generate and append a local copy".
~~~~~
2. L2TP Extended NAS-Port AVPs
Stackable AVPs: See [I-D.ietf-l2tpext-tunnel-switching] for
definition. In summary, if this AVP is received by a
participating in a multi-hop scenario, then the AVP MUST be
copied as-is to the next hop. A locally generated AVP MUST be
generated and appended in the outbound message to the next hop.
If no value is appropriate then an AVP of Length 6 (minimum AVP
length) MUST be appended.
Regarding the last sentence, "an AVP with a null value, as determined by
the AVP definition, MUST be appended", which can be different than "null
AVP Attribute Value" (from Length 6). Or does this intend to mean that
the "null value for all NAS-Port AVPs is a null Attribute value"?
In any case, the default value for all these AVPs should also probably
be explicitly mentioned.
~~~~~
2. L2TP Extended NAS-Port AVPs
...
The following are valid values for the Attribute Type field:
TBD - Platform Information
Could these TBDs be ennumerated (such as AVP-TBD-1, AVP-TBD-N) to
simplify and avoid confusions in the IANA allocations?
~~~~~
2. L2TP Extended NAS-Port AVPs
...
TBD - Platform Information
...
TBD - System Identification Information
...
TBD - Software Information
...
For incoming calls, these AVPs are valid either on ICRQ or ICCN.
If sent on both, the ICCN AVP MUST override the ICRQ value. For
outgoing calls, the AVPs are valid on OCRP and OCCN, with similar
override behavior.
One thing I was wondering, why these values of system-wide (LCCE-wide)
parameters are to be sent in Session Management AVPs? Would it be
sensible and more efficient to include these AVPs in Tunnel (Control
Connection Management) AVPs, as they describe the peer itself?
~~~~~
2. L2TP Extended NAS-Port AVPs
...
TBD - Platform Information
This AVP, length 0-253, allows a UTF-8 string to be sent with a
human-readable description of the platform.
The length depicted is the length of the Attribute Value (and not the
AVP Length), correct? Could this be clarified?
I think that UTF-8 probably needs a citation to [RFC3629]. Also, is
there a need to define the use of the default language [RFC2277] if
there is no Preferred Language AVP, for all internationalized strings?
Similar comment applies to the other AVPs.
~~~~~
2. L2TP Extended NAS-Port AVPs
...
TBD - Vendor-Information AVP
How does this AVP relate to the Vendor Name AVP, Attribute Type 8?
Except for the distinction of charset encoding (US-ASCII versus UTF-8),
they seem to be very similar. Please also see Section 9 of RFC3931.
~~~~~
2. L2TP Extended NAS-Port AVPs
...
TBD - Shelf
TBD - Slot
TBD - Module
...
TBD - Virtual Lan
TBD - Virtual Interface
TBD - Virtual Sub-interface
This AVP, length 0 or 4, is an octet integer value,
representing a specific Extended NAS-Port AVP value at this
L2TP node.
These AVPs do not seem to have an description; does the last para apply
to all of them? If so, what is the actual encoding/length of the
Attribute Values? Are they 4-octet unsigned integer values? If they are
relayed, then there is no need to have a "default null".
~~~~~
2. L2TP Extended NAS-Port AVPs
...
All Extended NAS-Port AVPs SHOULD be used in conjunction with the
port type values defined in [RFC2058] and [RFC2059].
Please note that these 2 RFCs have been obsoleted. You can follow that
from the top-left corner of:
http://tools.ietf.org/html/rfc2058
http://tools.ietf.org/html/rfc2059
~~~~~
3. RADIUS Extended NAS-Port AVP
...
The key distinction is that for RADIUS we have a single new attribute
with multiple Extensions, encoded as string attribute-value pairs of
the form "<extension>=<value>". These Extensions exist in a one-to-
one mapping with the previously defined L2TP AVPs.
It may be useful to explain the reason for this difference (RADIUS
attribute type resources?)
~~~~~
3. RADIUS Extended NAS-Port AVP
...
Type
TBD for Extended NAS-Port
Could this be "RADIUS-TBD" to differentiate in the IANA section?
~~~~~
3. RADIUS Extended NAS-Port AVP
This AVP, length 3-255, allows a UTF-8 string to be sent
A nit: This sentence prefaces all extensions, but there is only one AVP
(and multiple extensions), should the text about be "This extension"?
Also the length seems redundant, as it was defined as ">= 3" for all the
extensions.
~~~~~
3. RADIUS Extended NAS-Port AVP
...
Examples: "vpi=3", "vci=0", "vlan=12345"
In the last example, the 802.1Q VLAN ID is 12-bits, I'd change the value
to within 1-4094.
~~~~~
3. RADIUS Extended NAS-Port AVP
...
The use of the character '"' in this document is included purely as a
visual aid in identifying the beginning and end of strings. It MUST
Is the scope of this paragraph "in this section"? If it is "in this
document", then it should be placed further above in the document.
~~~~~
3.1. Table of Attributes
It may be useful to define "0" and 0+", as postamble to the tables,
like:
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in packet.
~~~~~
3.2. Interactions with other RADIUS attributes
If a RADIUS vendor detects conflicting values between NAS-Port and
Extended NAS-Port, Extended NAS-Port SHOULD be taken as the more
accurate value.
Can that conflict/incompatibility be really detected?
~~~~~
4. Security Considerations
This document describes mechanisms where port termination information
can be sent between L2TP peers. Users of these AVPs should have the
There seems to be more information that "port termination" only (such as
platform, etc). WOuld "port termination-related information" be more
accurate?
~~~~~
5. IANA Considerations
The "Call Information", "Platform Information", "Software
Information", and "Vendor Information" AVPs needs to be assigned an
IETF "Attribute Type" from the "Control Message Attribute Value
Pairs" maintained by IANA for L2TP.
What about the other AVPs? The RADIUS type seems missing as well. It
would be useful to enumarate all the registration requests with
AVP-TBD-N format.
~~~~~
6.2. Informative References
[I-D.ietf-aaa-diameter-nasreq]
Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application",
This became RFC 4005.
~~~~~
General:
1. The abbrev title ("RADIUS & L2TP AVPs") doesn't seem descriptive, the
"Extended NAS-Port AVPs" part seems more descriptive.
2. It would be useful to add an "Acknowledgements" section listing how
this l2tpext document combines 3 I-Ds, and acknowledging the
respective authors/editors.
--
--Carlos Pignataro.
Escalation RTP - cisco Systems