Subject: Comments on L2TP drafts

From: Archie Cobbs <[email-masked]>
Date: Fri, 28 Sep 2001 13:31:13 -0700

Hi,

Here are some comments on the current L2TP drafts. I'm new to this
mailing list and apologize in advance if some of this has already
been hashed over.

l2tp-base-00.txt
----------------

  Section 4.3
  
    Is it worth mentioning that the MD5 should process the attribute
    number in network order?

  Section 5.6

    This section is missing or there is a misnumbering.

  Section 6.11

    Seems like some stuff got accidentally deleted here.
    There is no description of the CDN or WEN messages.

    Also, the Sequencing Required AVP mentioned in l2tp-ppp-00.txt
    is never defined in this document.

l2tp-ppp-00.txt
---------------

  Section 5.1.3

    Description of Proxy Authen Name: "It contains the name specified
    in the client's authentication response". This is possibly vague,
    e.g., if both sides authenticate. Also "username" might be a better
    word to use.

  Section 6.1

    4th paragraph: Sequencing Required AVP is not described in [L2TP].

    It doesn't sound like there's any way for a device to require that
    the peer device not deliver rec'd packets out of order (because the peer
    device is free to ignore sequence numbers and/or not restore the order
    of out-of-order packets). Is this the intent?

    If so, what's the point of the Sequencing Required AVP?

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

---

From: Archie Cobbs <[email-masked]>
Date: Fri, 28 Sep 2001 14:39:04 -0700

> mailing list and apologize in advance if some of this has already

More comments..

  Assigned Control Connection ID:

  "If an LCCE needs to send a StopCCN to a peer but has not received an 
   Assigned Control Connection ID AVP from the peer, there are two cases
   to consider.  If an Assigned Control Connection ID AVP has been sent
   to the peer in a previous message, its value MUST be sent as the
   Assigned Control Connection ID AVP in the StopCCN to allow the peer
   to try to identify the appropriate control connection via a reverse
   lookup.  Alternatively, if an Assigned Control Connection ID has not
   been sent to the peer in a previous message, a Control Connection ID
   SHOULD be allocated and sent as the Assigned Control Connection ID
   AVP so that the StopCCN may be reliably delivered."

The Assigned Control Connection ID is a required AVP in a SCCRQ. So
it seems like the only way you would need to send a StopCCN when you
have not received an Assigned CCID from the peer would be if you
initiated the connection (you sent the SCCRQ) but you have not received
the SCCRP from the peer yet. But then you must have sent the Assigned
CCID in your SCCRQ, which means the second case described above is
impossible.

Perhaps it would be simpler if instead of requiring the 'reverse lookup'
business, the device would be required to simply wait for the SCCRP to
arrive from the peer with the peer's Assigned CCID before sending the
StopCCN -- or, if no SCCRP arrives by some timeout, then do nothing.
This may require a change to the state tables.

A similar logic applies to the Assigned Session ID.

Thanks,
-Archie