Re: [Pppext] Technical Request about a correct protocol behavior (RFC2661)

James Carlson <carlsonj@workingcode.com> Thu, 18 February 2016 21:48 UTC

Return-Path: <carlsonj@workingcode.com>
X-Original-To: pppext@ietfa.amsl.com
Delivered-To: pppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193871B342E for <pppext@ietfa.amsl.com>; Thu, 18 Feb 2016 13:48:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.333
X-Spam-Level:
X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, URG_BIZ=0.573] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prpb3C-lTLre for <pppext@ietfa.amsl.com>; Thu, 18 Feb 2016 13:48:08 -0800 (PST)
Received: from carlson.workingcode.com (carlson.workingcode.com [75.150.68.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B8F1B341F for <pppext@ietf.org>; Thu, 18 Feb 2016 13:48:06 -0800 (PST)
Received: from [10.49.72.142] (fw-lex.abinitio.com [65.170.40.234]) (authenticated bits=0) by carlson.workingcode.com (8.14.9/8.14.9/SuSE Linux 0.8) with ESMTP id u1ILm3W9008835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <pppext@ietf.org>; Thu, 18 Feb 2016 16:48:04 -0500
To: pppext@ietf.org
References: <8DB67D970E0F5D4AB8FD7C6FEF9D2FA9064BD172FC1A@HE113670.emea1.cds.t-internal.com>
From: James Carlson <carlsonj@workingcode.com>
Message-ID: <56C63C13.4010204@workingcode.com>
Date: Thu, 18 Feb 2016 16:48:03 -0500
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <8DB67D970E0F5D4AB8FD7C6FEF9D2FA9064BD172FC1A@HE113670.emea1.cds.t-internal.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-DCC-MGTINTERNET-Metrics: carlson 1170; Body=1 Fuz1=1 Fuz2=1
Archived-At: <http://mailarchive.ietf.org/arch/msg/pppext/UbIWgIl9h1BwjT5i4aejXc50leo>
Subject: Re: [Pppext] Technical Request about a correct protocol behavior (RFC2661)
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pppext/>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2016 21:48:10 -0000

On 02/18/16 08:09, Jewgenij.Bytschkow@t-systems.com wrote:
> Dear IETF colleagues,
> 
> we, at Deutsche Telekom Germany, have an urgent technical request
> regarding behavior of LAC/LNS during L2TPv2 (RFC2661) protocol
> communication. The question is not an errata report. We need only to
> verify the MUST behavior of a LAC/LNS implementation on the basis
> of the RFC2661.

Although design of L2TP was started in the IETF PPPEXT working group,
most of the original people involved have moved over to the L2TPEXT
working group.  You may also wish to consult with them:

https://datatracker.ietf.org/wg/l2tpext/charter/

> It is needed to clarify a proper, standard-compliant behavior of
> L2TP protocol implementations related to the following use case.
> 
> RFC 2661 (L2TPv2 standard):
> 
>       "The Mandatory (M) bit within the Message Type AVP has special
>       meaning. Rather than an indication as to whether the AVP itself
>       should be ignored if not recognized, it is an indication as to
>       whether the control message itself should be ignored.
>       If the M-bit is not set, then the implementation may ignore an unknown
>       message type."  
> 
> According to the RFC2661 statement quoted above, an unknown non-mandatory (M=0)
> control message received from the peer may be ignored. While ignoring that
> unknown control message in our use case, the implementation does not send
> ZLB-Ack also after several retransmissions of that control message by the peer.

Although I agree that the text of the document is somewhat ambiguous, I
don't believe that common sense supports reading it that way.

L2TP is designed to operate on unreliable media, so simply omitting ZLB
ACK sounds quite wrong to me.  There would be no way to recover from
such an omission.

My understanding is that when the Message Type AVP has M=0 and the type
is unknown to the receiver, the receiver is expected to skip
*processing* of that message -- including all of the AVPs contained in
the message, and sending no new message in reply -- but then resume
normal handling of the message stream, including any acknowledgement
requirements.

In other words, a sequence with multiple ignored (non-mandatory)
messages might look like this:

Peer A                Peer B
SCCRQ ->
Nr: 0, Ns: 0
                   <- UNKNOWN1
                      Nr: 1, Ns: 0
ZLB ->
Nr: 1, Ns: 1
                   <- SCCRP
                      Nr: 1, Ns: 1
UNKNOWN2 ->
Nr: 2, Ns: 1
SCCN ->
Nr: 2, Ns: 2
                   <- ZLB
                      Nr: 3, Ns: 2

> Questions:
> ---------
> - If the implementation receives and ignores (without ZLB Acknowledgement) an
>   unknown non-mandatory (M=0) control message, what should happen with the Nr
>   counters in the implementation according to the RFC2661?

This should not happen.  I argue that failing to send a proper ZLB when
the transmission queue is empty is an error, and a system that does this
is faulty.

> - Should the local Nr counter be incremented in the implementation or not?

Nr reflects the number of in-order messages received, regardless of
whether or not those messages were understood.  So, yes.

> - Should the peer's (sender's) Ns counter be incremented after several
>   unacknowledged retransmissions of that control message or not?

No, the Ns number is not incremented for retransmissions.  See B.2 in
the spec.

The sender should, in my estimation, retry multiple times and then
terminate the connection.  Once the sender has determined that the
recipient is broken, there's no need to send it any more packets.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>