Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision
"Proshin, Maksim" <mproshin@mera.ru> Fri, 01 March 2019 13:56 UTC
Return-Path: <mproshin@mera.ru>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87412130E81 for <tsvwg@ietfa.amsl.com>; Fri, 1 Mar 2019 05:56:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 8bIFiwjyWXcA for <tsvwg@ietfa.amsl.com>; Fri, 1 Mar 2019 05:56:17 -0800 (PST)
Received: from mail.mera.ru (mail.mera.ru [188.130.168.162]) (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 9103D130E79 for <tsvwg@ietf.org>; Fri, 1 Mar 2019 05:56:17 -0800 (PST)
Received: from e16srv01.merann.ru ([192.168.50.31]) by mail.mera.ru with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) (envelope-from <mproshin@mera.ru>) id 1gzidN-000Ar7-9L; Fri, 01 Mar 2019 16:55:29 +0300
Received: from e16srv03.merann.ru (2001:67c:2344:50::33) by e16srv01.merann.ru (2001:67c:2344:50::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1591.10; Fri, 1 Mar 2019 16:56:14 +0300
Received: from e16srv03.merann.ru ([fe80::2cb7:1925:fc4a:82dc]) by e16srv03.merann.ru ([fe80::2cb7:1925:fc4a:82dc%12]) with mapi id 15.01.1591.012; Fri, 1 Mar 2019 16:56:14 +0300
From: "Proshin, Maksim" <mproshin@mera.ru>
To: Michael Tuexen <tuexen@fh-muenster.de>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] SCTP RANDOM parameter in case of INIT collision
Thread-Index: AdTQLVHtlActtV+uQSOp8/Lo4JDYOv//2JSA///KAxCAADtogP//zKIw
Date: Fri, 01 Mar 2019 13:56:04 +0000
Deferred-Delivery: Fri, 1 Mar 2019 13:55:36 +0000
Message-ID: <e5b512447af1449da3e1b7140688b98c@mera.ru>
References: <2b50678935f34e25aff2f6b21eca9374@mera.ru> <997A9DE0-5AD2-4991-8D09-7F1C00072929@fh-muenster.de> <588a6ab909d14fd78ca8715aec951954@mera.ru> <05B1E876-F942-4AF6-8DDF-FF77295A2D49@fh-muenster.de>
In-Reply-To: <05B1E876-F942-4AF6-8DDF-FF77295A2D49@fh-muenster.de>
Accept-Language: en-US, ru-RU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.201.113]
x-inside-org: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Src-IF-Name: mail.mera.ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/fESgEuHYMtzKMW-bY6KyX9LAC7o>
Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2019 13:56:20 -0000
No, FreeBSD is not tested yet. BR, Maxim -----Original Message----- From: Michael Tuexen [mailto:tuexen@fh-muenster.de] Sent: Friday, March 1, 2019 16:49 To: Proshin, Maksim <mproshin@mera.ru> Cc: tsvwg@ietf.org Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision > On 1. Mar 2019, at 14:46, Proshin, Maksim <mproshin@mera.ru> wrote: > > Hi Michael, > > Yes, it seems lksctp always puts a new random number into INIT ACK when it receives INIT. I see. Did you also test with FreeBSD? However, it seems to be a motivation to add SCTP-AUTH support to packetdrill... Best regards Michael > Thanks for your prompt response! > > BR, Maxim > > -----Original Message----- > From: Michael Tuexen [mailto:tuexen@fh-muenster.de] > Sent: Friday, March 1, 2019 16:29 > To: Proshin, Maksim <mproshin@mera.ru> > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision > > > >> On 1. Mar 2019, at 14:05, Proshin, Maksim <mproshin@mera.ru> wrote: >> >> Hi Michael, tsvwg, >> >> I have a doubt about the RANDOM parameter from RFC 4895 which was caused by interoperability tests with different SCTP implementations. >> RFC 4895 has the following text in Section 6.1: >> In case >> of INIT collision, the rules governing the handling of this Random >> Number follow the same pattern as those for the Verification Tag, as >> explained in Section 5.2.4 of RFC 2960 [5]. Therefore, each endpoint >> knows its own Random Number and the peer's Random Number after the >> association has been established. >> >> and RFC 4960 which obsoletes RFC 2960 has the following statement in Section 5.2.1: >> >> Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST >> respond with an INIT ACK using the same parameters it sent in its >> original INIT chunk (including its Initiate Tag, unchanged). >> >> Based on those 2 statements I assume that SCTP must always respond with the same Random Number when it sends INIT ACK in response to INIT received in the COOKIE-WAIT state. Is my understanding correct? > Yes, I would say so. > > Is an open source implementation not following these rules? > > Best regards > Michael >> >> BR, Maxim >
- [tsvwg] SCTP RANDOM parameter in case of INIT col… Proshin, Maksim
- Re: [tsvwg] SCTP RANDOM parameter in case of INIT… Michael Tuexen
- Re: [tsvwg] SCTP RANDOM parameter in case of INIT… Proshin, Maksim
- Re: [tsvwg] SCTP RANDOM parameter in case of INIT… Michael Tuexen
- Re: [tsvwg] SCTP RANDOM parameter in case of INIT… Proshin, Maksim
- Re: [tsvwg] SCTP RANDOM parameter in case of INIT… Michael Tuexen