Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

[Tom Herbert <[e-mail]>]

On Wed, Feb 20, 2019 at 2:04 PM Colin Perkins <[e-mail]> wrote:
>
> > On 20 Feb 2019, at 16:59, Tom Herbert <[e-mail]> wrote:
> >
> > On Wed, Feb 20, 2019 at 8:07 AM <[e-mail]> wrote:
> >>
> >> I've been describing the general state of the art of QoE measurements based on network QoS parameters. I've been picking TCP as an example. The change from unencrypted TCP transport to TLS is a fair example how to increase the difficulties to judge QoE based on network QoS parameters. QUIC has been encrypted from start on.
> >>
> > Okay, TCP was just an example. So if I'm using another protocol like
> > SCTP, QUIC, TCP in a tunnel then how do I get the same features and
> > network services like plain TCP/IP gets?
> >
> >> Please briefly describe how to reliably determine per packet end-to-end RTT as could be done by TCP Ack screening replacing the latter by IOAM. I didn't follow IOAM closely. Is that generally possible by now or does it depend on options which have to be supported by equipment owned by different stakeholders?
> >>
> > Connection oriented protocols, like TCP and QUIC, track RTT per flow.
> > If this information is interesting to the network it can be provided
> > in HBH option. IOAM should carry a variant usable for RTT measurement.
> >
> >> Network QoS based QoE estimation us done for the mass market, if a network provider serves it. SCTP and tunnels and the like are corner case transport options. Further, I don't recollect that research cared too much about different TCP dialects.
> >
> > I do not know what "corner case transport options" are. Can you please
> > define that term?
> >
> >>
> >> I don't think the approach to have a single solution to monitor all transport options is feasible.
> >
> > It's not the intent to expose all transport options. As an application
> > and transport protocol developer I am only willing to expose
> > information to the network in plaintext that is absolutely necessary
> > for viable communications, not one bit more than that. I have no
> > interest in exposing everything just on the off chance that some
> > random device in the network might find it useful. I may be willing to
> > provide specific pieces of information if I know how it will be used
> > and an who will use it. This is the reallly the only resonable
> > security model for my users.
> >
> >> It will likely be too generic to provide useful input if it works end-to-end or it will be too specific to work end-to-end in a majority of cases, I guess. It's also a little hard to understand why an extra overhead should to be attached to a packet if the same information could be exposed within existing packet headers. I'm not talking about breaking consumer privacy here.
> >
> > Again, by "existing packet headers" you are implying that plain TCP/IP
> > is the the only thing that exists and needs to be supported. If the
> > Internet is to move evolve, we need to get beyond this limited view.
>
>
> The example I gave was a UDP-based transport protocol…
>
Colin,

Right, but as you said "Secure RTP is one example, where the payload
is encrypted but the headers are left in the clear.". That's true for
any payload encryption-- the headers are all in the clear as they were
in other examples. The draft states:

"One scenario is when transport protocols provide consistent
information to the network by intentionally exposing a part of the
transport header."

My interpretation of that is that a transport protocol developer would
encrypt some parts of the transport header and leave other parts in
the clear. An example of that would be the spin bit in QUIC. So QUIC
may be the best example, and assuming it hasn't yet been relegated to
the "corner case transport options" bucket by network operators, it
makes for a good case study.

Consider Lloyd's example where receive windows are modified in flight
to optimize a flow. As he mentioned, in some scenarios this
optimization allows TCP to dramatically outperform QUIC. It seems
unlikely that people are going to abandon using QUIC just because of
this, so the obvious question is how can QUIC take advantage of the
same optimization.

The naive approach would just be to expose a receive window field in
the QUIC header and have network devices process it like a receive
window in TCP. This doesn't work! The network identifies QUIC packets
by UDP port number, and as described in RFC7605 port numbers only have
meaning at the endpoints. So if intermediate devices are modifying
some UDP payload that isn't actually QUIC, then this is systematic
silent data corruption. This is not robust protocol and the offered
benefits of the feature don't justify changing fundamental semantics
transport port numbers.

The correct approach is to create a "Receive window guidance"
modifiable Hop-by-Hop option. This could contain a receive window that
the network can modify in flight. The QUIC implementation would be
modified to send and process the option accordingly. Of course, since
the information is no longer in the transport layer, the protocol can
be used with any transport layer protocol or TCP in an encrypted
tunnel.

Tom




> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>