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

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

> On Wed, Oct 16, 2019 at 6:25 PM Tom Herbert <[e-mail]> wrote:
> 
> On Wed, Oct 16, 2019 at 2:49 PM Lubashev, Igor <[e-mail]>
> wrote:
> >
> > > 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.
> >
> 
> That's why we're looking at HBH options for IPv4 also (draft-herbert-ipv4-
> hbh-destopt-00).

The concern expressed here is the encryption of usable signals and the lack of alternatives deployed within the same timeframe.  The language in draft-herbert-ipv4-hbh-destopt-00 states that "it is unlikely that packets with IPv4 Hop-by-Hop Options or Destination Options extension headers can be ubiquitously deployed over the Internet".

The goal of any "for the network" signal is improved QoS.  Hence, if there is a non-trivial chance that inclusion of such signal will actually degrade QoS (by causing packets with the signal to be dropped), no sender will include such signals (and "happy eyeballs" style code is too complex and risky for the benefit).

As architecturally "ugly" as it sounds, I can only see the QUIC header and the most significant TTL bits as viable alternatives to be deployable widely on the Internet for IPv4.  For IPv6, even HBH and Dest Options are still too "risky" for packets, but that is likely to be improving.

(Tom, are you interested in something like ConEx RFC 7837, except with HBH Options instead of Destination Options?)

- Igor

> Tom