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

<Jewgenij.Bytschkow@t-systems.com> Thu, 18 February 2016 13:12 UTC

Return-Path: <Jewgenij.Bytschkow@t-systems.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 93AFA1A1AB5 for <pppext@ietfa.amsl.com>; Thu, 18 Feb 2016 05:12:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.277
X-Spam-Level:
X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, URG_BIZ=0.573] autolearn=ham
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 fTmSjl_jO9Ei for <pppext@ietfa.amsl.com>; Thu, 18 Feb 2016 05:12:24 -0800 (PST)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B971A1A34 for <pppext@ietf.org>; Thu, 18 Feb 2016 05:12:23 -0800 (PST)
X-Mailbb-Crypt: true
Received: from he111460.emea1.cds.t-internal.com (HELO he111460) ([10.151.92.48]) by tcmail21.telekom.de with ESMTP/TLS/AES256-SHA; 18 Feb 2016 14:09:32 +0100
Received: from QDEZC2.de.t-internal.com ([10.125.181.10]) by he111460 (Totemo SMTP Server) with SMTP ID 137 for <pppext@ietf.org>; Thu, 18 Feb 2016 14:09:31 +0100 (CET)
From: <Jewgenij.Bytschkow@t-systems.com>
X-IronPort-AV: E=Sophos;i="5.22,465,1449529200"; d="p7s'?scan'208";a="409193393"
X-Mailbb-Crypt: true
X-Mailbb-SentCrypt: true
Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 18 Feb 2016 14:09:31 +0100
Received: from HE113670.emea1.cds.t-internal.com ([fe80::3dd9:9d1f:26aa:c9ef]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 18 Feb 2016 14:09:31 +0100
To: <pppext@ietf.org>
Importance: high
X-Priority: 1
Date: Thu, 18 Feb 2016 14:09:11 +0100
Thread-Topic: Technical Request about a correct protocol behavior (RFC2661)
Thread-Index: AdFqTX5WIjIjJ0msQTyWUO8o9T+iIQ==
Message-ID: <8DB67D970E0F5D4AB8FD7C6FEF9D2FA9064BD172FC1A@HE113670.emea1.cds.t-internal.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0082_01D16A55.E99007F0"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pppext/1pBxoO2d4ATDf-vult_0n9saTvI>
X-Mailman-Approved-At: Thu, 18 Feb 2016 09:43:17 -0800
Subject: [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 13:12:27 -0000

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.

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.

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?
- Should the local Nr counter be incremented in the implementation or not?
- Should the peer's (sender's) Ns counter be incremented after several
  unacknowledged retransmissions of that control message or not?


Thank you in advance for your help!

Best regards
Jewgenij Bytschkow 

T-Systems International GmbH
IT Division, Global IT Operations
GCU MPHS, Security Consulting & Engineering
Security Consulting I
Jewgenij Bytschkow, Dipl.-Ing./Dipl.-Math., CCNA certified
Senior Security Consultant
Deutsche-Telekom-Allee 7, 64295 Darmstadt
+49 (0)6151 583-4944 (Phone)
+49 (0)6151 583-7753 (Fax)
+49 (0)170 6156507 (Mobile)
E-Mail: Jewgenij.Bytschkow@t-systems.com
Internet: http://www.t-systems.com

T-Systems International GmbH
Aufsichtsrat: Thomas Dannenfeldt (Vorsitzender)
Geschäftsführung: Reinhard Clemens (Vorsitzender), Dr. Ferri Abolhassan, Thilo Kusch, Dr. Markus Müller, Georg Pepping, Hagen Rickmann
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr. DE50335567


-----Ursprüngliche Nachricht-----
Von: Amy Vezza via RT [mailto:iesg-secretary@ietf.org] 
Gesendet: Mittwoch, 17. Februar 2016 23:15
An: Bytschkow, Jewgenij
Betreff: [www.ietf.org/rt #113526] Technical Request about a correct protocol behavior (RFC2661)

Hi Jewgenij Bytschkow,

You have reached the IETF Secretariat, the administrative branch of the IETF,
and as such we are not qualified to answer your technical question.

The RFC you are asking about came out of the now-closed PPPEXT Working Group in
the Internet Area. The group may be closed, but the mailing list remains open.
You may try posting your question to the list at pppext@ietf.org.
Alternatively, you may ask your question of the Area Directors for the Internet
Area, Brian Haberman and Terry Manderson (int-ads@ietf.org).

Best regards,

Amy Vezza
IETF Secretariat



On Wed Feb 17 07:45:36 2016, 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 on the basis of RFC2661 a proper, standard-compliant
> behavior of L2TP implementations on LAC/LNS related to our use case.
> The use case I’m talking about is unfortunately NOT covered by
> the RFC2661 but is still very important for the functioning of the
> L2TP protocol on LAC/LNS in general and for real operation of
> LAC/LNS at Deutsche Telekom in particular.
>
> Can you please forward this e-mail request to the authors of the
> RFC2661 (L2TP) standard who can answer such a question? A technical
> description of the mentioned use case will be then posted to these
> IETF colleagues who are responsible for the RFC2661 life cycle.
>
> Thank you for your help!
>
> Best regards
> Jewgenij Bytschkow
>
> T-Systems International GmbH
> IT Division, Global IT Operations
> GCU MPHS, Security Consulting & Engineering
> Security Consulting I
> Jewgenij Bytschkow, Dipl.-Ing./Dipl.-Math., CCNA certified
> Senior Security Consultant
> Deutsche-Telekom-Allee 7, 64295 Darmstadt
> +49 (0)6151 583-4944 (Phone)
> +49 (0)6151 583-7753 (Fax)
> +49 (0)170 6156507 (Mobile)
> E-Mail: Jewgenij.Bytschkow@t-systems.com
> Internet: http://www.t-systems.com
>
> T-Systems International GmbH
> Aufsichtsrat: Thomas Dannenfeldt (Vorsitzender)
> Geschäftsführung: Reinhard Clemens (Vorsitzender), Dr. Ferri
> Abolhassan, Thilo Kusch, Dr. Markus Müller, Georg Pepping, Hagen
> Rickmann
> Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
> Sitz der Gesellschaft: Frankfurt am Main
> WEEE-Reg.-Nr. DE50335567
>
>