Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

["Lubashev, Igor" <[e-mail]>]

> On Tue, Oct 15, 2019 at 7:22 PM From: Tom Herbert <[e-mail]> wrote:
> 
> On Tue, Oct 15, 2019 at 2:32 PM Lubashev, Igor <[e-mail]>
> wrote:
> >
> > > On Sat, Oct 12, 2019 at 12:02 PM Tom Herbert <[e-mail]>
> wrote:
> > >
> > > I do believe that there will be valid use cases for hosts to signal
> > > the network for services. There is a least one robust, explicit, and
> > > transport agnostic method to allow hosts to signal the network with
> > > transport related information and even application layer
> > > information-- that's Hop-by-Hop Options extension header. A critical
> > > difference with parsing transport layers, is that the end host is in
> > > control of what information is exposed in HBH options. As I've said
> > > several times, I believe this draft is missing on the opportunity to
> > > propose this as the "solution" to middleboxes losing visibility because of
> encryption.
> >
> > +1
> > An explicit signal-to-network, such as IPv6 HBH option, is architecturally far
> superior to a hotch-podge of protocol-specific signals.  I think it would be
> great for this draft to encourage design and standardization of such explicit
> signal.
> >
> > We know too well, unfortunately, that such signal, IPv6 HBH option, will
> not work for most of Internet traffic today (IPv4 traffic and IPv6 traffic
> flowing over links blocking IPv6 HBH option). The speed with which we can
> deploy encrypted-header protocols (i.e. QIUC) and a reliable explicit-signal-
> to-network HBH option differ greatly. What are we to do in the interim?
> >
> Hi Igor,
> 
> The statement that IPv6 HBH will not work for most of the Internet traffic
> today is a rather broad generalization. In a sense, we could also that IPv6
> doesn't work for most of the Internet traffic. I will accept that there is not
> ubiquitous support for HBH EH in all networks, but in the same way that IPv6
> can be deployed before there's 100% support we need to be able to deploy
> things like HBH options.

I am NOT saying "don't define an IPv6 HBH EH that would solve this problem, because it would not work everywhere".  Quite the opposite -- we should do something like IPv6 HBH EH, because all traffic should be IPv6 w/ HBH EH working in the future.

The argument is that we should _also_ do something, possibly temporary, to take care of the very significant portion of the network where IPv6 w/ HBH EH does not work today.  (I know that temporary things have a tendency to last forever, and it stinks, but we are talking about a very large portion of the traffic today.)

<snip>

> So to me the fundamental question is more about how do we deploy new
> protocols or existing protocols that are hard to deploy because of
> ossification. The answer lies in answering these two questions: 1) how do we
> work around the existing brokenness 2) how do we motivate fixing the
> brokenness.
> 
> For the workaround, we can apply the philosophy of IPv6 "happy eyeballs"
> which is essentially using probing or external information to determine if the
> path to the destination supports a certain protocol (e.g. IPv6, HBH EH, UDP,
> etc.).

The "brokenness" this draft points to is the lack of network signals.  IPv6 HBH workaround is good, but it would not help for the majority of connections today.  So the workaround is incomplete.

<snip>

> For motivation, this seems to be a matter of demonstrating incentive for
> middlebox vendors to fix their solutions. Network signaling should be a good
> incentive.

Yes, complete agreement here. A useful signal that cannot be received by a device is a good incentive for the operators to fix the device or to buy a different one. But while filtering IPv6 HBH EH is up to the operators, the use of IPv4 instead of IPv6 on a dual-protocol network is out of operators' control, so operator incentives are not a complete solution, unfortunately.

> Tom

- Igor