On Thu, Dec 6, 2018 at 11:24 AM Jared Mauch <jared@xxxxxxxxxxxxxxx> wrote:
> On Dec 6, 2018, at 9:05 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@xxxxxxxxx> wrote:
>
> Speaking as an individual who ballots on working group charters ...
>
> On Thu, Dec 6, 2018 at 7:38 AM Stewart Bryant <stewart.bryant@xxxxxxxxx> wrote:
>
>
> On 06/12/2018 12:57, Gert Doering wrote:
> > Hi,
> >
> > On Thu, Dec 06, 2018 at 10:28:53AM +0000, Stewart Bryant wrote:
> >> However, aren't we moving to a world where new protocols get carried
> >> over UDP anyway?
> > Over HTTPS, you intended to say?
> Some and some. It depends on what aspect of the stack you spend your
> time thinking about.
>
> "you're both right" :-) ...
>
> As noted earlier in this thread, we punted new transport protocols into UDP encapsulation at roughly the "we can't get SCTP deployed at scale, we can't get DCCP deployed at scale, and we don't see any reason to think that any new transport protocol will be any different" stage, at least a decade ago. So, when I see people talking about SCTP, it's usually in a context like RTCWeb, where the stack looks like SCTP/DTLS/UDP, and QUIC is only defined over UDP.
>
> (I suspect the world would have been a slightly better place if we'd done the DCCP encapsulation in UDP from day 1, because DCCP functionality could have been really useful when we started encapsulating every known network protocol in UDP, but that's not relevant to this discussion)
>
> But since QUIC's initial deliverable includes its HTTP mapping, https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ comes into play. I would oversimplify that draft as saying "we are way more excited about applications using HTTP as a substrate now, than we were in 2002", so, yes, the future smells a lot like HTTPS over (mumble) over UDP, at least to me.
>
> I don't know that's a perfect plan, but I've been balloting on working group charters for at least 3 years, assuming that it's a plan.
Yes, we’ve also seen the security/crypto all the things overreach impact the routing area as well. We’ve not seen a suitable option to replace TCP transport that is viable due to the timescales involved. I’ve provided feedback at the mic in London in SAAG about the problems of this for people who need very reliable transport, some level of transport security but do not want or require transport privacy.
Jared,
I'm not entirely sure I know what you're talking about here. If I recall your comments at the microphone correctly, they were about the challenges with TCP-AO. However, I wouldn't really call TCP-AO an example of security/crypto overreach. Rather, it was an attempt to fulfill what we understood to be asks from the routing area (key agility, a stronger algorithm than MD5). And of course TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate on what you're referring to here?
-Ekr
- Jared
