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

From: Vasilenko Eduard <[email-masked]>
Date: Sat, 1 Aug 2020 16:45:50 +0000

Hi all,

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.

Eduard

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 31 июля 2020 г. 22:32
To: [email-masked]
Cc: [email-masked]
Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the IPv6 Operations WG of the IETF.

        Title           : Operational Implications of IPv6 Packets with Extension Headers

        Authors         : Fernando Gont

                          Nick Hilliard

                          Gert Doering

                          Warren Kumari

                          Geoff Huston

                          Will (Shucheng) Liu

               Filename        : draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt

               Pages           : 16

               Date            : 2020-07-31

Abstract:

   This document summarizes the operational implications of IPv6

   extension headers, and attempts to analyze reasons why packets with

   IPv6 extension headers may be dropped in the public Internet.

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/

There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-00

https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-00

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

_______________________________________________

v6ops mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ole Troan <[email-masked]>
Date: Sun, 2 Aug 2020 14:05:25 +0200

> On 1 Aug 2020, at 18:47, Vasilenko Eduard <[email-masked]> wrote:
> 
> 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”
> 
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. 

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

Cheers 
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 3 Aug 2020 08:34:05 +1200

On 03-Aug-20 00:05, Ole Troan wrote:
>> > 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.*
>>
>>  
>>

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 3 Aug 2020 07:36:20 -0300

Hello, Eduard,

> 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. :-)

[....]
>  > 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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1