Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Security as Functionality

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 27 Jul 2020 08:57:32 +0000

Hi Fernando,
Security is sometimes functionality, not vulnerability or attack vector. The good example is Firewall. Firewall needs to parse all headers to be useful.
Hence, I believe it is in the logic of this draft to have section 5.1.5: one additional "use case" when parsing of ALL headers are mandatory. FW, IDPS
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: 26 июля 2020 г. 8:46
To: IPv6 Operations <[email-masked]>
Cc: [email-masked]
Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt)

Folks,

We have posted a rev of our IETF I-D "Operational Implications of IPv6 Packets with Extension Headers".

The I-D is available at: 
https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt

Your feedback will be appreciated.

Thanks!

Cheers,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
Date: Sat, 25 Jul 2020 22:28:50 -0700
From: [email-masked]
To: Fernando Gont <[email-masked]>, Gert Doering <[email-masked]>, Geoff Huston <[email-masked]>, Warren Kumari <[email-masked]>, Nick Hilliard <[email-masked]>

A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
has been successfully submitted by Fernando Gont and posted to the IETF repository.

Name:		draft-gont-v6ops-ipv6-ehs-packet-drops
Revision:	04
Title:		Operational Implications of IPv6 Packets with Extension Headers
Document date:	2020-07-25
Group:		Individual Submission
Pages:		15
URL: 
https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/
Htmlized: 
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-04

Abstract:
    This document summarizes the security and operational implications of
    IPv6 extension headers, and attempts to analyze reasons why packets
    with IPv6 extension headers may be dropped in the public Internet.

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.

The IETF Secretariat

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Jul 2020 06:25:07 -0300

Hello, Edward,

> Hence, I believe it is in the logic of this draft to have section 5.1.5: one additional "use case" when parsing of ALL headers are mandatory. FW, IDPS

It's indeed normally necessary for a firewall to parse all headers, and 
certainly this might be a motivation to drop packets at the edge of the 
network.

However, I'm not sure if it would make sense to cover IDPS/FW in this 
I-D, since we're mostly discussing the reasons for operators (as opposed 
to say, sys admins or security administrators) to drop them.

What do folks think?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 27 Jul 2020 09:43:10 +0000

There is no any restriction in the name of this draft that "Enterprises should not read this draft".
Put this restriction, then I would agree that FW is out.

Something like "Operational Implications of IPv6 Packets with Extension Headers in Telco environment".

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 27 июля 2020 г. 12:25
To: Vasilenko Eduard <[email-masked]>; IPv6 Operations <[email-masked]>
Cc: [email-masked]
Subject: Re: Operational Implications of IPv6 Packets with Extension Headers - Security as Functionality

Hello, Edward,

On 27/7/20 05:57, Vasilenko Eduard wrote:
> Hence, I believe it is in the logic of this draft to have section 
> 5.1.5: one additional "use case" when parsing of ALL headers are 
> mandatory. FW, IDPS

It's indeed normally necessary for a firewall to parse all headers, and certainly this might be a motivation to drop packets at the edge of the network.

However, I'm not sure if it would make sense to cover IDPS/FW in this I-D, since we're mostly discussing the reasons for operators (as opposed to say, sys admins or security administrators) to drop them.

What do folks think?

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Jul 2020 07:36:23 -0700

> Hence, I believe it is in the logic of this draft to have section 5.1.5: one additional "use case" when parsing of ALL headers are mandatory. FW, IDPS

Eduard,

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. The effect of this model is protocol ossification
since firewalls drop anything that they don't understand even if the
protocols are otherwise useful to the host endpoints. EH is one victim
of protocol ossification in this regard, but it's not the only the
one. For instance QUIC and any future transport protocols will encrypt
as much as the packet as possible expressly for the purpose of
avoiding ossification of these protocols by middleboxes.

Tom

---

From: Joseph Touch <[email-masked]>
Date: Mon, 27 Jul 2020 08:24:39 -0700

> On Jul 27, 2020, at 7:36 AM, Tom Herbert <[email-masked]> wrote:
> 
> firewalls can only process what they are programmed to process ….

A firewall NEEDS to balance protection with functionality.

I.e., a trivial firewall drops all packets. That’s 100% protection but 0% utility.

Dropping unknown headers protects against unknown attacks, but is not needed to protect against known ones.

I wonder whether most firewalls would provide sufficiently similar protection with increased utility by passing unknown options rather than blocking them.

Joe