Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-ipv6-ehs-packet-drops-06: (with COMMENT)

From: Fernando Gont <[email-masked]>
Date: Fri, 28 May 2021 04:13:35 -0300

Hello, Roman,

Thanks a lot for your feedback! In-line....

On 21/4/21 12:37, Roman Danyliw via Datatracker wrote:
[....]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** Section 1.
> However, common implementation limitations suggest
>     that EHs present a challenge for IPv6 packet routing equipment and
>     middle-boxes, and evidence exists that IPv6 packets with EHs are
>     intentionally dropped in the public Internet in some network
>     deployments.
> 
> Can you clarify a “common implementation limitations” -- is that the same as
> saying vendors aren’t supporting EHs?

Common limitations: limits on the number of EHs they can process, limit 
on the EH chain lengths they can process, etc.

> ** Section 4.  Are there more updated references for the trends identified
> in[PMTUD-Blackholes], [Linkova-Gont-IEPG90] and [RFC7892] as the freshest of
> these is 6 year old data?

I'll ask Geoff if he refreshed any of these experiments.

> 
> ** Sections 6.1 and 6.2 don’t have clear text like Section 6.4 and 6.5 that
> explains how layer-4 inspections leads to dropped packets.

FWIW, subsections 6.¿ are meant to illustrate why intermediate systems 
may need to access layer-4 information.  Itś Section 7.1 that notes that 
if they are unable, they may have to resort ot drop the packets.

(Maybe we could/should add a forward reference to Section 7 at the top 
of Section 6?)

> ** Section 6.4
> Use of extension headers can be problematic for NIDS/IPS, since:
> 
>     o  Extension headers increase the complexity of resulting traffic,
>        and the associated work and system requirements to process it.
> 
>     o  Use of unknown extension headers can prevent an NIDS/IPS from
>        processing layer-4 information.
> 
>     o  Use of IPv6 fragmentation requires a stateful fragment-reassembly
>        operation, even for decoy traffic employing forged source
>        addresses (see e.g., [nmap]).
> 
> -- Per (1), this seems analogous to the argumentation in Section 5 but in that
> section there were details around the limitation of hardware support.  Is there
> an analogous reference here?  That is, asserting that computation requirements
> to process EH is a significant additional load?

For the *complexity* bit, a possible reference could be:
    [Atlasis2014]
               Atlasis, A., "A Novel Way of Abusing IPv6 Extension
               Headers to Evade IPv6 Security Devices", May 2014,
               <http://www.insinuator.net/2014/05/a-novel-way-of-abusing-
               ipv6-extension-headers-to-evade-ipv6-security-devices/>.

For performance, not sure thereś one.

> -- How is the core issue of (3) different than handling fragments in IPv4
> (i.e., operators dropping them at the border and NIPS/NIDS also have to
> reassembly them to avoid evasion)?

It is not. Fragmentation is bad in both cases. :-)

(strictly speaking, it actually *used* to be worse. See RFC7112)

> ** Section 6.5.  Thanks for including the reference to [Zack-FW-Benchmark].
> Due to the age of the benchmark, another sentence explaining how 2013-era
> firewalls are still quite similar to those used now would be helpful

I will ask Eldad and see if they have any more recent (public) 
references we could use. :-)

That aside, let me just say that this reference *was* recent when the 
effort on this document started ;-) The amount of time it takes the IETF 
to publish document makes the issue of "recent references" challenging 
at times ;-)

Thanks!

Regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Gert Doering <[email-masked]>
Date: Fri, 28 May 2021 09:21:14 +0200

Hi,

On Mon, Apr 26, 2021 at 05:10:45AM -0700, Tom Herbert wrote:
> As Eric pointed out in his review "Please also note that many high
> speed routers are now VMs with normal generic processors in a data
> center (of course not in the public Internet).". If you add in all the
> servers that run a virtual router to serve VM, it may very well be
> that the majority of routers are actually implement in CPU and not in
> fixed hardware logic. 

Even so it would be irrelevant for the question "send a packet with EH
across the Internet" - because most routers "outside of datacenter 
deployments" are *not* VMs.  And it's not really relevant for the result
if there is "just one" router in the path that drops your packets, or 
"all of them".

Also, "high speed routers" tend to be "not VMs", for any *current *
definition of "high speed" - like "multiple 100Gbit ports".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279