IETF Logo Mail Archive

Re: [Tsv-art] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

Wes Hardaker <wjhns1@hardakers.net> Tue, 11 December 2018 22:56 UTC

Return-Path: <wjhns1@hardakers.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450F6130F58; Tue, 11 Dec 2018 14:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 rO1HR9xTyPWn; Tue, 11 Dec 2018 14:56:42 -0800 (PST)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911D8130F62; Tue, 11 Dec 2018 14:56:42 -0800 (PST)
Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id A20182076F; Tue, 11 Dec 2018 14:56:35 -0800 (PST)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Wes Hardaker <wjhns1@hardakers.net>, Nick Hilliard <nick@foobar.org>, tsv-art <tsv-art@ietf.org>, OPSEC <opsec@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org
References: <CAL9jLaYHVdHr+rVoWeNtXTXgLxbTaX8V9gn3424tvsLW60Kvow@mail.gmail.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <CAN-Dau0go6_Puf0A9e7KBpk0ApJBUvcxYtezxnwNc-8pKJ3PwQ@mail.gmail.com> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <F17C4944-09EC-4AAC-84A0-B660E36AAE89@strayalpha.com> <20181205133821.GL1543@Space.Net> <B6280E0C-6B20-43C1-BB34-170FB06F1EF7@strayalpha.com> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <CCFEFC5B-53AE-4079-B64A-A72A71274FAD@employees.org> <cda0e10e-a56d-4598-dcd4-eabeeac52fb0@gmail.com> <a1b478a7-4396-3d9e-0282-c8c66250526c@gmail.com> <f86a07c8-c421-56db-005c-4db3ce4f3fe0@gmail.com> <3744b28c-3a5a-1ce4-9ff7-5374804d332e@gmail.com> <35277330-4743-4690-8ae0-9a9ab7e34f05@foobar.org> <3a182a82-b933-2d9b-52a8-24805717879b@gmail.com> <ybl4lbjsu9a.fsf@w7.hardakers.net> <d970fa54-f36b-13fd-7442-b301813567fb@gmail.com>
Date: Tue, 11 Dec 2018 14:56:35 -0800
In-Reply-To: <d970fa54-f36b-13fd-7442-b301813567fb@gmail.com> (Brian E. Carpenter's message of "Wed, 12 Dec 2018 11:38:58 +1300")
Message-ID: <ybllg4vr7to.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/gHdOOCJyPiX_u7mhxLYmjbmWSLo>
Subject: Re: [Tsv-art] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2018 22:56:44 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> writes:

> It's a shame. Can you characterise those sessions in any way?
> 
> (This shouldn't invalidate ECMP/LAG usage as described in RFC6438,
> since there it is the operator that sets the flow label.)

I had to go dig out the bug that we dealt with "way back then" (to be
fair, btw, credit to Duane Wessles at Verisign who tracked down and
could reproduce the issue).

There were two issues:

1) The linux kernel ECMP support had a bug in that they were including
the ECN bits of the flow label.  But even fixing this didn't fix the
problem, because

2) Some clients were sending a flowlabel for the initial TCP handshake
and then zeroing it out in subsequent packets:

SYN:
    .... .... .... 1101 0111 0101 0110 0100 = Flow Label: 0xd7564

SYNACK from server: (no label)

ACK from client:
    .... .... .... 1101 0111 0101 0110 0100 = Flow Label: 0xd7564

First data packet:
    .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000

Which what was causing the problem.

-- 
Wes Hardaker
USC/ISI

v2.23.0 | Report a Bug | By Email