Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer

[Tom Herbert <[e-mail]>]

On Tue, Jul 28, 2020 at 1:36 AM Vasilenko Eduard
<[e-mail]> wrote:
>
> Hi Tom,
> Is APNIC a reliable source for you?
> https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/
> RIPE has replicated it here: https://labs.ripe.net/Members/joel_jaeggli/ipv6-flow-label-misuse-in-hashing
> "Cases have been observed where devices that connect to hashed endpoints do not in fact honour this behaviour. By in large, this flow label changing behaviour has been traced to IPv6 supporting CPE/firewalls, which change the flow label between the initial syn and the ack."

The rationale for this is: "The use of the flow label as a hash
element for any stateful application requires that the flow label
remain unchanged over the life of the flow.". This is really directed
towards stateful intermediate nodes like stateful firewalls. Yes, it's
true that they will break if the flow label changes in flight. On the
host, we've tried to ensure that the flow label is consistent for the
lifetime of the flows, I don't know what firewalls are doing in
changing them.

> They have disputable conclusion: "Avoid using the flow label as a hash component".

This guidance could just as easily be "Avoid fragmentation", "Avoid
using any protocols other than UDP or TCP", "Avoid using extension
headers", "Avoid ICMP", "Avoid using encapsulation", "Avoid using
encryptions" as any of these can break some meddling device somewhere
such that packet delivery becomes unreliable on the Internet. More
generally, the guidance could simply be "Avoid doing anything that
disrupts the status quo"!

>
> Additional corner case: https://github.com/pypa/warehouse/issues/5454
>
> Eduard
> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: 27 июля 2020 г. 22:24
> To: Vasilenko Eduard <[e-mail]>
> Cc: Fernando Gont <[e-mail]>; IPv6 Operations <[e-mail]>; [e-mail]
> Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer
>
> On Mon, Jul 27, 2020 at 11:05 AM Vasilenko Eduard <[e-mail]> wrote:
> >
> > Hi Tom,
> > I believe that risk still exist that some application would no use flow label properly.
>
> Exactly which applications are you concerned about?
>
> > Hence, it is better on LB to deep dive into UDP/TCP. More predictable/reliable result.
>
> You seem to be assuming a very limited traffic profile that consists only of plain UDP/TCP packets. Any use case that deviates from that then breaks your LB (i.e. encapsulation, tunneled encryption, SCTP, IPSec, etc.). Flow label is in all IPv6 packets and is mostly set properly for the vast majority of packets on the Internet and processing it is completely independent of the protocols, so when taking the full scope of the problem into account it is actually more generic and more predictable/reliable.
>
> Tom
>
> > Eduard
> > -----Original Message-----
> > From: Tom Herbert [mailto:[e-mail]]
> > Sent: 27 июля 2020 г. 17:15
> > To: Vasilenko Eduard <[e-mail]>
> > Cc: Fernando Gont <[e-mail]>; IPv6 Operations
> > <[e-mail]>; [e-mail]
> > Subject: Re: [v6ops] Operational Implications of IPv6 Packets with
> > Extension Headers - Load Balancer
> >
> > On Mon, Jul 27, 2020 at 2:08 AM Vasilenko Eduard <[e-mail]> wrote:
> > >
> > > Hi Fernando,
> > > Hence again, following the logic of this draft (the level of detalization that you have given to 5.1) - may be you need additional section 5.1.x: Load Balancer have to look into TCP/UDP ports. Moreover, it could not trust "Flow label" - it is not reliable practice for LB.
> >
> > Eduard,
> >
> > What exactly does "not reliable practice for LB" mean.? If this means that the flow label might change during the flow's lifetime then I will point out that UDP is equally unreliable for that reason (i.e.
> > the UDP ports for a QUIC connection can change during the connection's lifetime). For that matter, a TCP header might be encrypted or in an encapsulation that the LB doesn't understand so the LB can't access the TCP ports at all-- in the this case the flow label is actually more reliable than TCP since it's never encrypted and is purposely designed to be consumed by intermediate nodes without the need for expensive DPI.
> >
> > Tom
> > > Or alternatively you could say something about LB in section 5.1.2,
> > > but because it is a little special case - may be better to have
> > > separate 5.1.x
> > >
> > > Eduard
> > > -----Original Message-----
> > > From: v6ops [mailto:[e-mail]] On Behalf Of Fernando
> > > Gont
> > > Sent: 26 июля 2020 г. 8:46
> > > To: IPv6 Operations <[e-mail]>
> > > Cc: [e-mail]
> > > 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-packe
> > > t-
> > > 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: [e-mail]
> > > To: Fernando Gont <[e-mail]>, Gert Doering
> > > <[e-mail]>, Geoff Huston <[e-mail]>, Warren Kumari
> > > <[e-mail]>, Nick Hilliard <[e-mail]>
> > >
> > >
> > > 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-packe
> > > t-
> > > drops-04.txt
> > > Status:
> > > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-dr
> > > op
> > > s/
> > > Htmlized:
> > > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-0
> > > 4
> > > Htmlized:
> > > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-pack
> > > et
> > > -drops
> > > Diff:
> > > https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-d
> > > ro
> > > ps-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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/v6ops
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/v6ops
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/v6ops