IETF Logo Mail Archive

RE: Packets leaking and escaping from domains ....

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Mon, 11 May 2020 00:47 UTC

Return-Path: <albert.e.manfredi@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E213A0C2A for <ipv6@ietfa.amsl.com>; Sun, 10 May 2020 17:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
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 KmMRrnHPkG7f for <ipv6@ietfa.amsl.com>; Sun, 10 May 2020 17:47:31 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.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 4153D3A0C29 for <ipv6@ietf.org>; Sun, 10 May 2020 17:47:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 04B0lRLx000756; Sun, 10 May 2020 20:47:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1589158048; bh=waTHogxo88b0rHALEbmxoNIkrRAfgNsDTGlHgB99F3o=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=WZBCoqLkBRYVoM9fdF56+ft2iaYsELPXOvTaAmWgDmy6SiqOW3cgxdXHOkvX8LGWe MuMRTGb7TcjFH+wVcT93PsFA3JiYODrgvF0+j6/IsGgIk3ob0g68fPXgkKKKF22iQ1 o3i1xuy40lAMCZ8otSC1TZWP7VqLD/LHX9QPWNPeE0d6zSNy51K9xoG4XTU87zhrIm gZm/oM93DTG+d3Ixfb7fVhrJHKx5EoXaY6XCSQCKxp4I1khe6zSY2gFfRu+KAPHKAv q84Nvyw/gBCjEMRtdHASd4fWp0lAAIs+SJe52hyZU4R0eP4MMbR+ux5aqV7+cGgq+y lYApPlqrLhTvA==
Received: from XCH16-01-12.nos.boeing.com (xch16-01-12.nos.boeing.com [144.115.66.70]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 04B0lNpI000645 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Sun, 10 May 2020 20:47:23 -0400
Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-12.nos.boeing.com (144.115.66.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Sun, 10 May 2020 17:47:22 -0700
Received: from XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b]) by XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b%4]) with mapi id 15.01.1979.003; Sun, 10 May 2020 17:47:22 -0700
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Robert Raszuk <robert@raszuk.net>
CC: 6man WG <ipv6@ietf.org>
Subject: RE: Packets leaking and escaping from domains ....
Thread-Topic: Packets leaking and escaping from domains ....
Thread-Index: AQHWJq6XbfhVDig73UaKlznlVBq49qihn58AgAABP4CAAEJLAIAABxwAgABb9oD//8O0UA==
Date: Mon, 11 May 2020 00:47:21 +0000
Message-ID: <7c5d444bfa8e4e1c95458ba3f51a12d8@boeing.com>
References: <CAOj+MMG22BVKvb8tFBUOjPZUjWNvY-Pe7+-mmpXV0gxhn1zBiw@mail.gmail.com> <8f6a6db1-86c5-144b-8f51-9824d1e8dc47@foobar.org> <CAOj+MMHzV=mTjdM8WGrPxujLWBAMg59tZgKzVM4JuJU5=o84NQ@mail.gmail.com> <CALx6S346T8GoQEamVyWm18mcpdyf-GrnAM+QUJcQ2euTM6qWcg@mail.gmail.com> <CAOj+MMHgE3xMDnXrr5z2N-7vCEhdM3D81upRXddFJgNtJ5oddw@mail.gmail.com> <a08a12ca-25c3-80c8-3890-036eccc64e78@gmail.com>
In-Reply-To: <a08a12ca-25c3-80c8-3890-036eccc64e78@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.115.204.6]
x-tm-snts-smtp: DE5F2AC64C4FABC83D704CAEB0A641D9E1DF206B2F2CF772728BF19C5889164E2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zbgvTLKqKnJv-WEM8WNym1ZFIA0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2020 00:47:36 -0000

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Brian E Carpenter

> I agree with you that the worst consequence is dropped packets, if they leak. But debugging connection failures of this kind is essentially impossible and can drive users and help desks crazy. Who is inserting an SRH in my packet and then sending it on to the outside world? Where is the tiny configuration error that causes this? (Maybe there's a corner case bug in the PSP code?)
>
> That's why the ecapsulation model is fundamentally better; it limits the problem to the encap/decap tunnel by construction, and leaked SRHs simply cannot happen.

+1.

Following through the arguments pro and con, in this long thread, including arguments along the lines of what people do in the privacy of their own bedrooms. It's seems to be a case of someone doing something fundamentally funky, but wanting to get a blessing for doing so.

Why ask for a blessing? If a user is experiencing some inexplicable problem, and the user's network domain, or the destination's domain, are doing unnatural acts, the onus of debugging should fall immediately on that questionable practice.

There are other examples of individual companies creating their own proprietary tricks, without necessarily asking for a blessing. And yes, they do cause problems. Just look at the special, clever tricks, a long and diverse list, involved in IGMP snooping.

Bert

v2.23.0 | Report a Bug | By Email