Subject: [v6ops] FW: New Version Notification for draft-vyncke-v6ops-james-01.txt

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 20 Mar 2022 07:02:59 +0000

The major changes are:
- adding measurements for destination options header with different lengths
- adding measurements about two (mainly IPv6) protocols, 59 (NoNextHeader) and 143 (Ethernet payload per RFC 8986)
- adding the source code repo

Minor changes include typo fixes, change of the document flow, ...

The authors are looking forward to discussing this document at IEPG on Sunday and V6OPS WG meeting. Comments and suggestions will be welcome.

Regards

-éric

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Sunday, 20 March 2022 at 07:55
To: Raphaël Léas <[email-masked]>, Eric Vyncke <[email-masked]>, Eric Vyncke <[email-masked]>, Justin Iurman <[email-masked]>, Raphaël Léas <[email-masked]>
Subject: New Version Notification for draft-vyncke-v6ops-james-01.txt

    A new version of I-D, draft-vyncke-v6ops-james-01.txt
    has been successfully submitted by Éric Vyncke and posted to the
    IETF repository.

    Name:		draft-vyncke-v6ops-james
    Revision:	01
    Title:		Just Another Measurement of Extension header Survivability (JAMES)
    Document date:	2022-03-20
    Group:		Individual Submission
    Pages:		17
    URL:            https://www.ietf.org/archive/id/draft-vyncke-v6ops-james-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-vyncke-v6ops-james/
    Html:           https://www.ietf.org/archive/id/draft-vyncke-v6ops-james-01.html
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-james
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-vyncke-v6ops-james-01

    Abstract:
       In 2016, RFC7872 has measured the drop of packets with IPv6 extension
       headers.  This document presents a slightly different methodology
       with more recent results.  It is still work in progress.

    The IETF Secretariat

---

From: Mark Smith <[email-masked]>
Date: Sun, 20 Mar 2022 22:07:04 +1100

Hi,

Any specific reason why ESP hasn't been/isn't being tested?

One way to think of what ESP does is that it enforces through encryption
the Internet transparency to packet payloads that should already exist.
Blocking ESP is in a sense an assertion that the network doing the ESP
blocking is stating that it is going to inspect packet payloads because it
is forcing clear text packets.

I'm also interested because this presentation from Microsoft about the Xbox
One, from Nanog 59/2013, says that the Xbox One uses IPv6 + IPsec in
transport mode. I haven't heard of any issues with Xbox and IPv6 + IPsec,
however it could be useful to have a measure of IPv6 Internet ESP
transparency.

https://archive.nanog.org/sites/default/files/wed.general.palmer.xbox_.47.pdf

Regards,
Mark.

On Sun, 20 Mar 2022, 18:03 Eric Vyncke (evyncke), <evyncke=
[email-masked]> wrote:

> The authors are looking forward to discussing this document at IEPG on
> Sunday and V6OPS WG meeting. Comments and suggestions will be welcome.
>
> Regards
>
> -éric
>
>
> To: Raphaël Léas <[email-masked]>, Eric Vyncke <
> [email-masked]>, Eric Vyncke <[email-masked]>, Justin Iurman <
> [email-masked]>, Raphaël Léas <[email-masked]>
>     URL:
> https://www.ietf.org/archive/id/draft-vyncke-v6ops-james-01.txt
>     Status:
> https://datatracker.ietf.org/doc/draft-vyncke-v6ops-james/
>     Html:
> https://www.ietf.org/archive/id/draft-vyncke-v6ops-james-01.html
>     Htmlized:
> https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-james
>     Diff:
> https://www.ietf.org/rfcdiff?url2=draft-vyncke-v6ops-james-01
>
>     Abstract:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 20 Mar 2022 12:06:00 +0000

Mark,

Actually, the only reason was that we have assumed that as IPsec VPN works (albeit often over UDP encapsulation) accross the Internet, it was useless to test ESP 'fate' when crossing the global Internet.

The cost of adding ESP on our next run is rather small of course and we would add it.

Regards and thanks for reading our draft and commenting on it,

-éric

From: Mark Smith <[email-masked]>
Date: Sunday, 20 March 2022 at 12:08
To: Eric Vyncke <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] FW: New Version Notification for draft-vyncke-v6ops-james-01.txt

Hi,

One way to think of what ESP does is that it enforces through encryption the Internet transparency to packet payloads that should already exist. Blocking ESP is in a sense an assertion that the network doing the ESP blocking is stating that it is going to inspect packet payloads because it is forcing clear text packets.

I'm also interested because this presentation from Microsoft about the Xbox One, from Nanog 59/2013, says that the Xbox One uses IPv6 + IPsec in transport mode. I haven't heard of any issues with Xbox and IPv6 + IPsec, however it could be useful to have a measure of IPv6 Internet ESP transparency.

Regards,
Mark.
On Sun, 20 Mar 2022, 18:03 Eric Vyncke (evyncke), <evyncke=[email-masked]<mailto:[email-masked]>> wrote:
The major changes are:
- adding measurements for destination options header with different lengths
- adding measurements about two (mainly IPv6) protocols, 59 (NoNextHeader) and 143 (Ethernet payload per RFC 8986)
- adding the source code repo

Regards

-éric

-----Original Message-----
From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, 20 March 2022 at 07:55
To: Raphaël Léas <[email-masked]<mailto:[email-masked]>>, Eric Vyncke <[email-masked]<mailto:[email-masked]>>, Eric Vyncke <[email-masked]<mailto:[email-masked]>>, Justin Iurman <[email-masked]<mailto:[email-masked]>>, Raphaël Léas <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-vyncke-v6ops-james-01.txt

    Abstract:

    The IETF Secretariat

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

---

From: Mark Smith <[email-masked]>
Date: Mon, 21 Mar 2022 02:34:55 +1100

Hi Eric,

> Actually, the only reason was that we have assumed that as IPsec VPN works (albeit often over UDP encapsulation) accross the Internet, it was useless to test ESP 'fate' when crossing the global Int…

That's part of my interest. UDP encapsulation of ESP is to facilitate
IPv4 NAT traversal (RFC3948), so UDP encapsulation of ESP shouldn't be
necessary on the IPv6 Internet.

It also relates to RFC6092, "Recommended Simple Security Capabilities
in Customer Premises Equipment (CPE) for Providing Residential IPv6
Internet Service". That has a general recommended inbound default deny
(as expected), however defaults to allowing IKE and ESP because
they;re authenticated and encrypted protocols. Going by the Microsoft
Xbox presentation, they have been assuming this residential CPE
IKE/ESP default permit.

So one perspective on testing ESP transparency could be that as
residential CPE is supposed to allow it per RFC6092, so how successful
is the Internet in carrying it?

> The cost of adding ESP on our next run is rather small of course and we would add it.

Excellent.

Thanks very much,
Mark.

> On Sun, 20 Mar 2022, 18:03 Eric Vyncke (evyncke), <evyncke=[email-masked]> wrote:
>
> The major changes are:

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 21 Mar 2022 11:58:09 +0100

Eric/*:

Very nice work.  Thanks!

2 points:

1) I wonder what we're supposed to be able to learn from the results beside:

a) If you want to use an option, chances for it to proliferate over time are kinda ok (good)
b) You can obviously never expect to get very high percentage support, so never try to
   propose something one would have to DEPEND upon.

What else ?

2) Hurting routers

Here is i think what would be important to consider investigating, to learn something
i am quite interested in and i am not sure the current procedures do this:

Are routers hurting because of the options being processed ?

My now rather old experience, was that we did have routers hurting by doing slow-path
processing of traffic. And that did lead to the disabling/filtering of traffic with 
the properties that lead to slow-path processing.

This is really nasty, because the applications relying on that behavior did worked at
first, then they became popular, causing too much pain and then they where filtered.

Maybe one option to test for hurting would be to do an actual throughput test of
TCP (or equally CC UDP): one flow without the option, one flow with the option. Run
in parallel for 10..30 seconds, and in the end compare the numbers. If the throughput
is significantly lower with the option applied, then we should assume that some router
along the way could have been hurting. Of course, if one would do maybe more flows in parallel
50/50 with/without option, the results might become better. Room for research.

(past work did look into latency, which was increased because of slow-path, but IMHO that
 does not work well enough across long Internet paths.)

Cheers
    Toerless

-- 
---
[email-masked]