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

Fernando Gont <fernando@gont.com.ar> Mon, 03 August 2020 10:37 UTC

Return-Path: <fernando@gont.com.ar>
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 304EC3A0DFF for <v6ops@ietfa.amsl.com>; Mon, 3 Aug 2020 03:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.725
X-Spam-Level:
X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.212, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 2ZfGPvMG9umb for <v6ops@ietfa.amsl.com>; Mon, 3 Aug 2020 03:37:19 -0700 (PDT)
Received: from tools.si6networks.com (v6toolkit.go6lab.si [IPv6:2001:67c:27e4::57]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13913A0DFE for <v6ops@ietf.org>; Mon, 3 Aug 2020 03:37:19 -0700 (PDT)
Received: from [IPv6:2800:810:464:1f7:10e9:dc78:74f7:a148] (unknown [IPv6:2800:810:464:1f7:10e9:dc78:74f7:a148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tools.si6networks.com (Postfix) with ESMTPSA id 65BEE40021; Mon, 3 Aug 2020 12:37:16 +0200 (CEST)
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, "v6ops@ietf.org" <v6ops@ietf.org>
References: <f65dff980756428e9aeec77fe87d8138@huawei.com>
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <f6dbce57-d511-648e-c80d-871293f9d34d@gont.com.ar>
Date: Mon, 03 Aug 2020 07:36:20 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <f65dff980756428e9aeec77fe87d8138@huawei.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/wFAEAB0ruocweJZGi1mexCrpr-o>
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: Mon, 03 Aug 2020 10:37:21 -0000

Hello, Eduard,

On 1/8/20 13:45, Vasilenko Eduard wrote:
> 
> I am still not happy that middleboxes (Firewall, Load Balancer) are 
> discarded as the reasons for EH drops.

FWIW, we will include a discussion of these in the next revision of the 
document -- please bear with us. :-)



[....]
> 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.*

Please note that this is somewhat mixing up two different issues issues:

1) The ability to process packets

2) A filtering policy


Firewalls, by definition, must perform #2. And quite normally they can 
do fragment reassembly, and even inspect packets above layer-4. In many 
cases, even if they can process a packet, they may drop the packet as a 
result of the filtering policy (e.g., default deny, which is typical 
among firewalls) -- i.e., only allow the traffic you are expected to 
receive. This obviously happens at the destination AS, close to the 
destination system.

OTOH, many devices (such as modern routers) may have an operational 
requirement of doing things (Sections 6.2-6.4), and packets with EHs get 
in the way. It's not that they are meant to do a default-deny (in many 
cases, they actually implement a default-allow policy), but packets with 
EHs put them in a position that they cannot even perform a "default 
allow" policy, and hence they need to be dropped.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1