Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00 - Middleboxes

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 02 August 2020 20:34 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831863A0BF4 for <v6ops@ietfa.amsl.com>; Sun, 2 Aug 2020 13:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.147
X-Spam-Level:
X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, 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=gmail.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 a5GB9Fd5jxMI for <v6ops@ietfa.amsl.com>; Sun, 2 Aug 2020 13:34:14 -0700 (PDT)
Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7948F3A0BF3 for <v6ops@ietf.org>; Sun, 2 Aug 2020 13:34:14 -0700 (PDT)
Received: by mail-pl1-x643.google.com with SMTP id u10so10222799plr.7 for <v6ops@ietf.org>; Sun, 02 Aug 2020 13:34:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MUkMK9EGFbrwJ9D1s7NKKizX+Y0QSlULzzuraaqCqGs=; b=hM8X/s5BHrV7qzq7WWRuh99K24aseoUQ3n0rwDVnJo6gbIzFr13o4/TOokw2MJbkQ8 umSUTBAk1nz1IFEeb1tWWMhqOQFRGULvVqprLt6lRseYQp7t4FebWCqd9BUNlTQ50eEx PHN1FfpPh/JMggazAIuYBkRjTa7giLSyk1D0hlJ/6l6wMPSJUAfYu2edwMsmhTpj3l0c 1W3ZVtzOiUgcHjunbdV2V4PKHZboZXSHRkbr5RBTNGImgMM44AV0FVvh7/kVTPKyE68V 8YG3lpIbpRJSmEV2Q4K0FZNWvwnWE6kpsQX+rK+5f9B15Wy4h/h9MCZ1HWQbwbUxPbeN ZcAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MUkMK9EGFbrwJ9D1s7NKKizX+Y0QSlULzzuraaqCqGs=; b=O5ZfPfVAIRI7KJj/i82r07Myghe5YHKK1tLg/jnkuwD8MmjxfI1EIz1RD8s4Psy1tM DUoEC4FoFaKFC0iN5kb5EE7u2BmEm0yPrB2gp9hy48xHPKF79boyeRQXNLX4/gxq9P7t 2wwYLvzwXtbsVFdYCIbvQo+1+tgf8cBVWtTVgvcWXq79KO5R4F7WPVtr8Xq3HZKXOVkH hIe8z27q4zYxIC/Mu70ngKf4fzXvGom7U7Gq+ZX2XSmq7WpyWisyixhUWUDYuBjkGG+v iXXZvZGGIVTDq4R/n+QzwSuHYRFBim9Pv6UdI5RXtc9NlJAIFH48FPcZhhkJ5TNP2Fmf q00g==
X-Gm-Message-State: AOAM533VbCjYWV4oG3usssduuA3/uWIE5bOjoX6kkCsL6aKVPpsvu3Aj hu07vZgBGinmkPQjRX7NGK4GcYxtjgU=
X-Google-Smtp-Source: ABdhPJzZ6BrU5hlNnVZWtu3Xou8Ha7HZIlTnoorSdFgjvcsl04jNxV8FlqmnZtSL7LctMC/tzU/ANw==
X-Received: by 2002:a17:90a:380b:: with SMTP id w11mr14773329pjb.213.1596400452663; Sun, 02 Aug 2020 13:34:12 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id lb1sm2522725pjb.26.2020.08.02.13.34.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Aug 2020 13:34:07 -0700 (PDT)
To: Ole Troan <otroan@employees.org>, Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
References: <f65dff980756428e9aeec77fe87d8138@huawei.com> <F35B476E-CA80-4442-976D-214CAF1FD75D@employees.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <5d793092-70b2-3002-0853-dcdbf30ccc71@gmail.com>
Date: Mon, 3 Aug 2020 08:34:05 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <F35B476E-CA80-4442-976D-214CAF1FD75D@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bgM5tfvxR1HV_m27eyPLU9l7K2Q>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00 - Middleboxes
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Aug 2020 20:34:15 -0000

On 03-Aug-20 00:05, Ole Troan wrote:
> 
> 
>> On 1 Aug 2020, at 18:47, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
>>
>> I am still not happy that middleboxes (Firewall, Load Balancer) are discarded as the reasons for EH drops.
>>
>> Tom (Herbert) is right that “FWs and middleboxes that insist on meddling in protocol layers beyond the networking layer where both the standard and the Internet architecture say they are not supposed to look at”
>>
>> But they are! We should not ignore the reality.
>>
>> It is especially evident that they are among reasons for EHs drops after response:
>>
>> > I would love to see the firewall device that is capable of processing ALL protocol headers in the IETF protocol suite! *Reality is that firewalls can only process what they are programmed to process which is typically a very small subset of the possible protocols a host might want to use.*
>>
>>  
>>
>> It is not good to ignore/hide some type of drops that we do not like.
>>
> I think you have a good point. 
> 
> If I was implementing a function to wash traffic in front of a set of eg DNS servers, why would I ever let any EH through? Known or unknown.
> 
> There’s a chicken and egg situation. Awaiting  an across the Internet useful EH option. 

Indeed. This was actually the main reason that SHIM6 failed to take off. It was by definition useful across the Internet if it was useful at all, and in fact it could and did successfully cross transit networks, but the only way to get it out of and into end sites was to bypass the site firewalls.

> Apart from measuring the transparency level of the core Internet, it’s unclear to me what useful conclusions we can draw from this work. 

Measuring the transparency of the core seems like a very good thing to do, since the traditional Internet archictecture assumes a transparent core.

Regards
     Brian