Re: [tsvwg] SCTP RANDOM parameter in case of INIT collision
Michael Tuexen <tuexen@fh-muenster.de> Fri, 01 March 2019 13:57 UTC
Return-Path: <tuexen@fh-muenster.de>
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 60B90130E7B for <tsvwg@ietfa.amsl.com>; Fri, 1 Mar 2019 05:57:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 FiGiBqr3PH0e for <tsvwg@ietfa.amsl.com>; Fri, 1 Mar 2019 05:57:52 -0800 (PST)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEA0130E81 for <tsvwg@ietf.org>; Fri, 1 Mar 2019 05:57:51 -0800 (PST)
Received: from [192.168.1.9] (p57BB42E6.dip0.t-ipconnect.de [87.187.66.230]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 7185B721E281E; Fri, 1 Mar 2019 14:57:47 +0100 (CET)
From: Michael Tuexen <tuexen@fh-muenster.de>
Message-Id: <DBD61CBD-33B5-4BA0-B995-2077FAA72D62@fh-muenster.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_4F2A356B-326B-40E6-87CC-CC815314A5BA"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 01 Mar 2019 14:57:46 +0100
In-Reply-To: <e5b512447af1449da3e1b7140688b98c@mera.ru>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
To: "Proshin, Maksim" <mproshin@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> <e5b512447af1449da3e1b7140688b98c@mera.ru>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/AfR040fn5_DaGvXyBlWqqqK0Yso>
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:57:55 -0000
> On 1. Mar 2019, at 14:56, Proshin, Maksim <mproshin@mera.ru> wrote: > > No, FreeBSD is not tested yet. OK. If you test it and find problem, drop me an email. Best regards Michael > > 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