[v6ops] Hurting routers ? Re: FW: New Version Notification for draft-vyncke-v6ops-james-01.txt

[Toerless Eckert <[e-mail]>]

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

On Mon, Mar 21, 2022 at 02:34:55AM +1100, Mark Smith wrote:
> Hi Eric,
> 
> On Sun, 20 Mar 2022 at 23:06, Eric Vyncke (evyncke) <[e-mail]> wrote:
> >
> > 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.
> >
> >
> 
> 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.
> 
> >
> > Regards and thanks for reading our draft and commenting on it,
> >
> >
> >
> > -éric
> >
> >
> >
> > From: Mark Smith <[e-mail]>
> > Date: Sunday, 20 March 2022 at 12:08
> > To: Eric Vyncke <[e-mail]>
> > Cc: v6ops list <[e-mail]>
> > Subject: Re: [v6ops] FW: New Version Notification for draft-vyncke-v6ops-james-01.txt
> >
> >
> >
> > 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=[e-mail]> 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
> >
> > 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: "[e-mail]" <[e-mail]>
> > Date: Sunday, 20 March 2022 at 07:55
> > To: Raphaël Léas <[e-mail]>, Eric Vyncke <[e-mail]>, Eric Vyncke <[e-mail]>, Justin Iurman <[e-mail]>, Raphaël Léas <[e-mail]>
> > 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
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
---
[e-mail]