Subject: Re: Comments on L2TP drafts

From: [email-masked]
Date: Mon, 1 Oct 2001 09:45:14 -0500

Archie,

Thanks for your comments. Here's what I think.

l2tp-ppp :
------------

1. Proxy Authen Name : This is the name of the ppp entity that is getting
authenticated.
If the group thinks the present verbiage needs to be changed becuase it is
unclear,
it can be done.

2. You are right,  Sequencing Required AVP is not described in [L2TP].
It is described in the l2tp-ppp draft. This will be corrected.

The intent of the Sequencing Required AVP is this:

An LCCE  SHOULD set the sequence number on outgoing packets.
However, the only way this can be *enforced*  by its peer receiving those
packets is to send the Sequencing Required AVP.

Hope this is clear now

thanks
-Madhvi

---

From: Jed Lau <[email-masked]>
Date: Mon, 1 Oct 2001 17:35:15 -0700 (PDT)

Hi Archie,

Thanks for your feedback.  I was aware of 2 of the 4 problems that you
flagged in the base draft.  I'll take care of them in the next revision.

Jed

On Fri, 28 Sep 2001, Archie Cobbs wrote:

> 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: Jed Lau <[email-masked]>
Date: Mon, 1 Oct 2001 17:52:14 -0700 (PDT)

On Fri, 28 Sep 2001, Archie Cobbs wrote:

> Archie Cobbs wrote:
> 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.

Yep, I agree.  I'll remove the latter case.

> 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.

Which I don't think is desirable.  Besides, an LCCE shouldn't have to wait
for an SCCRP from a peer even though it knows that the control connection
is going down.  The reverse lookup, I believe, is a mechanism that was
recommended when the l2tpbis draft was written.

Jed

> A similar logic applies to the Assigned Session ID.
>
> Thanks,
> -Archie
>