[L2tpext] draft-ietf-l2tpext-radius-ext-nas-port-00 comments

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

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext