Subject: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt

From: Tom Herbert <[email-masked]>
Date: Thu, 19 May 2016 11:17:09 -0700

Hello,

We are working on a method to encapsulate transport protocols over
UDP. This has two goals that are intended to address transport
protocol ossification in the Internet:

1) Allow applications to run their own transport layer stack (i.e.from
userspace). This eliminates dependencies on the OS (e.g. solves a
major dependency issue for Facebook on clients).
2) Make transport layer headers (all of L4) invisible to the network
so that they can't do intrusive actions at L4. This will be enforced
with DTLS in use.

Any comments or suggestions are welcome.

Thanks,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Thu, May 19, 2016 at 10:57 AM
Subject: New Version Notification for draft-herbert-transports-over-udp-00.txt
To: Tom Herbert <[email-masked]>

A new version of I-D, draft-herbert-transports-over-udp-00.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-transports-over-udp
Revision:       00
Title:          Transport layer protocols over UDP
Document date:  2016-05-19
Group:          Individual Submission
Pages:          20
URL:
https://www.ietf.org/internet-drafts/draft-herbert-transports-over-udp-00.txt
Status:
https://datatracker.ietf.org/doc/draft-herbert-transports-over-udp/
Htmlized:       https://tools.ietf.org/html/draft-herbert-transports-over-udp-00

Abstract:
   This specification defines a mechanism to encapsulate layer four
   transport protocols over UDP. Such encapsulation facilitates
   deployment of alternate transport protocols or transport protocol
   features on the Internet. DTLS can be employed to encrypt the
   encapsulated transport header in a packet thus minimizing the
   exposure of transport layer information to the network and so
   promoting the end-to-end networking principle.

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 11:59:43 -0700

Whats the likely use-case for this ? Many transports already have a UDP binding,
some like RTP ONLY work across UDP. Even if there is no pre-existing UDP or better
yet dTLS encap, why would someone with transport X choose this scheme over a home-grown one
using UDP/dTLS ? This should be written out with explicit examples to motivate this draft
better.

I haven't spent enough time to understand it all in detail, but the mobility aspect is
of course quite important and necessarily complex. It would be great to write down a
section comparing how you're trying to solve it with your session identifiver vs. how
MT-TCP solves it. I can't see how you provide good mobility and therefore IP address
independency without adding new signaling packets. I am also concerned about creating a
new session identifier to replace transport addresses because that impacts applications
building eg: a TCP connection and whose APIs might need to change. But as said: Mostly
FUD and not enough detailled understanding of your drafts bits & pieces here.

Wrt to your claim that its useful to protect the L4 headers: I would like to see text
that explicitly writes out what specific elements are protected by this scheme with or
without dTLS and how this reduces which attack vectors. For example, yes: you may not
be able to see TCP session setup/teardown messages and may therefore make life more
miserable for middleboxes, even those trying to do a good thing, but dTLS session
signaling would likely more than compensate for that.

Wrt to protect every single last bit of a transport layer header from middleboxes, let me bring 
this up in another thread.

Cheers
    toerless

On Thu, May 19, 2016 at 11:17:09AM -0700, Tom Herbert wrote:
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

-- 
---
Toerless Eckert, [email-masked]

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 May 2016 12:39:11 -0700

> using UDP/dTLS ? This should be written out with explicit examples to motivate this draft
The current use case we are developing is TCP over UDP. Our deployment
scenario is that we want to embed a TCP stack in the client
application (Facebook app in this instance), and will update out
server stacks appropriately. With the transport stack under our
control we can now modify it quickly and not depend on underlying OS
to leak out features. An example feature that we'd like to have is TCP
Fast Open (TFO). TFO was developed nearly five years ago, but we still
cannot effectively use this because Android hasn't supported it.
Once we control both the client and server stacks and don't need to
worry to affects in the network of changing the transport protocol,
implementing new features like TFO in a timely manner becomes
feasible.

> signaling would likely more than compensate for that.
We want to hide the full TCP header from middle boxes. While for the
most part middlebox inspection of L4 headers may be innocuous or even
beneficial, there are several known cases of middleboxes maliciously
mucking with headers. Some middleboxes have dropped TCP options they
don't like, so called TCP optimizers rewrite recv window or drop data.
There are also injection attacks in TCP streams that can mess up TLS.
Another problem is that middleboxes are not guaranteed to have
complete flow state. A stateful FW for instance requires that all
packets for the flow got through the same device, this reeks havoc
with multihoming or mobility. Hiding flow state from such devices
nullifies the ad hoc requirement that all packets of a flow must
follow the same path.

Tom

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 13:21:34 -0700

> implementing new features like TFO in a timely manner becomes

Thanks.

If where to translate this into text i'd like to see it would say:
Operating System Transport Protocol Stacks are not agile enough with latest improvements
in Transport protocols, especially extensions to widely used ones like TCP (example TFO).
Various experiements where and are being done to implement transport layer protocols
over UDP to allow them to be implemented in application layer code. A standard
encapsulation would allow interoperability between different implementations and
allow to not having to reinvent the encap across different transport protocols.

> nullifies the ad hoc requirement that all packets of a flow must

Unless all this is in some reference to your doc i've overlooked, this would all be
good text to ad and better motivate the work. That would still not persuade me that
your approach is the best one to address these issues though ;-):

TLS should not be attackable this way. Isn't this fixed in 1.3 ? You don't want
to be a baby sitter for TLS. TLS has to be a standalone babysitter. That why we
hired it ;-)

The other cases are just examples of bad middleboxes. So let's say TCP optimizers.
If you hide everything from them you also negate their good effects. Like 
localizing retransmissions on lousy paths. Of course, they will suck in specific
scenarios because don't support them. The solution for this IMHO only be more
complex. The way i'd do it is
  a) definitely transport over UDP so we can let apps instead OS libs do the work
  b) have the option to hide or NOT-hide the transport layer in the encap.
  c) do happy-eyeball to figure out what works best. Start with exposing transport
     headers. That should give you flow-control improved performance. Change
     to hiding it when you see that something is not working well.

Btw: a well configured middlebox should give traffic that it can not figure out
only the lowest bandwidth class anyhow. The nicer you play with the middlebox, the
nier it should play with your traffic ;-))

Cheers
    Toerless

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 May 2016 13:57:10 -0700

> allow to not having to reinvent the encap across different transport protocols.
Yes, also the part about interactions of middleboxes with new
transport layer features is probably equally important as the client
OS issue.

> your approach is the best one to address these issues though ;-):
Thanks, I'll add that.

> to be a baby sitter for TLS. TLS has to be a standalone babysitter. That why we
If an attacker successfully injects a packet into the TCP stream (by
predicting seq #s for instance) couldn't that mess up TLS?

> nier it should play with your traffic ;-))
Right, the way we're dealing with seems to be a textbook application
of the robustness principle.

Tom

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 14:06:39 -0700

> predicting seq #s for instance) couldn't that mess up TLS?

Define "mess up". And yes, maybe. But the more interesting question is if there
is no such attack (inject faked packets to make connction unworkable) againt dTLS.

Cheers
    Toerless

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 May 2016 14:36:33 -0700

There are many ways to support user-land transport protocols (raw IP,
tun/tap devices, etc.) and some good reasons not to (lack of
coordination with kernel-based transports).

IMO, adding a layer of encapsulation (and all that entails, including
the need for PLPMTUD, other ICMP signal relaying between layers, etc.)
is a very inefficient and complex way to overcome an implementation
convenience issue.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 May 2016 14:59:31 -0700

> coordination with kernel-based transports).
Raw IP and tun/tap require privileged access and as you mention
requires coordination with kernel stack (if nothing else we need to
deal with allocations in TCP tuple namespace). We have support for
neither of those available in the application environment we need to
run in.

> is a very inefficient and complex way to overcome an implementation
As far as the kernel is concerned this is just another UDP application
so PMTU discovery and ICMP should work normally as long as the ICMP
messages are sent pertaining to the UDP packet.

It is true that if we run a TCP stack in userspace we lose quite a bit
of efficiency compared to a stack running in kernel that is well
integrated with lower layers, routing, NIC offloads, etc. (at my last
count Linux TCP stack interacted with other layers and other parts of
the kernel at about fifty different points). This is why I believe we
want an asymmetric implementation. For our Internet clients we want to
run the TCP stack as part of the application to achieve OS
independence (from Android, iOS, etc.); on the server side where
scalability is the primary issue I will use a modified kernel stack
that implements TOU.

Tom

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 15:11:02 -0700

On Thu, May 19, 2016 at 02:36:33PM -0700, Joe Touch wrote:
> tun/tap devices, etc.)

All options not available to non-privileged user processes across the board
of OSs and programming language libraries (C,C++,python,java,javascript).

> and some good reasons not to (lack of coordination with kernel-based transports).

And example why i'd care for coordination with kernel based transports ?

> the need for PLPMTUD, 

Just use IPv6 and < 1280 packets. IN my book, Jumbo packets should be the last dinosaurs
on their way out.

> other ICMP signal relaying between layers, etc.)

Example ?

> is a very inefficient and complex way to overcome an implementation

Do you think you can come with metrics for "inefficient and complex" that everybody
agrees to ? Eg: The overhead of going from IPv4 to IPv6 addresses is higher than
the UDP encap. Does that make IPv6 "very very inefficient" ?

Also: your convenience issue is my market innovation/agility/ossification and adoption issue.
How do we build agreeable metrics around those criteria ?

Name calling is easy. Quantification is not.

Cheers
   Toerless

If we where

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 May 2016 15:21:18 -0700

> of OSs and programming language libraries (C,C++,python,java,javascript).

There's a reason for that; a protocol hack is not a good rationale for
an end-run around the legitimate desire for security in these systems.

> And example why i'd care for coordination with kernel based transports ?
At some point, when the version of TCP you want is in the kernel, you'll
want to transition. That begs the question of demuxing incoming
services, and whether the kernel peeks into the packet to send them to
the right place (which might be at a different port inside the kernel).
> Just use IPv6 and < 1280 packets. IN my book, Jumbo packets should be the last dinosaurs

You can't expect support for these new TCP variants, but you expect
ubiquitous support for IPv6?
>> other ICMP signal relaying between layers, etc.)

see draft-ietf-intarea-tunnels, section 4.5
> the UDP encap. Does that make IPv6 "very very inefficient" ?

I'm confused now; above you assumed IPv6. Now you're comparing UDP/IPv4
vs. IPv6?

> How do we build agreeable metrics around those criteria ?

Your ossification is my stability. Let's say you migrate to using this
encapsulation. What happens later when you want to transition to a more
native version? How do you coordinate whether to use the encapsulated
version or not? or will you now require the kernel to do the extra UDP
encapsulation?

I'm not in favor of creating a mess for the future for a little
short-term benefit. Effort would be better spent getting the desired
features into these OS transport implementations.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 May 2016 15:22:23 -0700

Your intent is to thus reinvent the Internet over UDP, solely to get
around the fact that you don't have permission to do so otherwise?

Again, a very poor justification for this level of complexity. I don't
consider RFCs useful when they address only temporary concerns.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 May 2016 15:31:00 -0700

> around the fact that you don't have permission to do so otherwise?
A somewhat coarse way of phrasing it, but otherwise correct. Running
over UDP seems to be the best solution to defeating protocol
ossification in the Internet-- RFC7663, SPUD, QUIC, and others attest
to that.

> consider RFCs useful when they address only temporary concerns.
Unfortunately, protocol ossification does not seem to be a temporary issue.

Tom

---

From: Ca By <[email-masked]>
Date: Thu, 19 May 2016 15:32:11 -0700

> consider RFCs useful when they address only temporary concerns.
+1 for joe.

This and similarly quic are creating an arms race.

These things wont stop, and the next step is your local middle box provider
requiring users to install their mitm cert :(

We already saw this this "http trusted proxies"

> > On Thu, May 19, 2016 at 2:36 PM, Joe Touch <[email-masked] <javascript:;>>
> wrote:
> [email-masked] <javascript:;>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 15:43:32 -0700

> We already saw this this "http trusted proxies"

*Sob*

First of all, there will not be an arms race on one front: We will escape
ossification of the transport stack implementations because OS vendors MUST
keep UDP sockets available to apps. So we can long term continue to plan to
use the for app based transport stack. Btw: The alternative that app vendors
are going to guarantee they have a predictasble transprt stack is to build their
apps into VMs so they have control over the kernel. That a lot more complex
in my book.

Secondly: SPUD is exactly the proposal to avoid having the need for these
"http trusted proxies"

Toerless

---

From: Ca By <[email-masked]>
Date: Thu, 19 May 2016 15:52:56 -0700

On Thursday, May 19, 2016, Toerless Eckert <[email-masked]> wrote:

> > On Thursday, May 19, 2016, Joe Touch <[email-masked] <javascript:;>>
> wrote:
> >
I hear you.

> apps into VMs so they have control over the kernel. That a lot more complex
1. The IETF recommends using existing transport. Translation, the IETF says
dont do this with udp
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-13#section-3

2.  Udp is and will be blocked in many cases, so you are just forcing the
evil telcos to plug another hole

UDP is already blocked in many context, your app must always fall back to
work in these common scenarios ... So blocking udp is just a downgrade
attack.

> Secondly: SPUD is exactly the proposal to avoid having the need for these
Again, udp will be blocked if used in this way.

I wish not to have an arms race, but playing out the moves on the chess
board ....

Toerless
> > > > On Thu, May 19, 2016 at 2:36 PM, Joe Touch <[email-masked]
> <javascript:;> <javascript:;>>
> > > wrote:
> > > [email-masked] <javascript:;> <javascript:;>
> Toerless Eckert, [email-masked] <javascript:;>
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 May 2016 15:55:48 -0700

On the point of an arms race:

On 5/19/2016 3:43 PM, Toerless Eckert wrote:
> keep UDP sockets available to apps.
But they can and may end up blocking access to whatever port is assigned
to this service, exactly because it's an end-run around OS protections
(i.e., anyone can then run a System port service inside UDP on a User
port number).

And it'll end up impacting things like ECMP, requiring router vendors to
peek even further inside packets to find the "real" transport.

---
In the end, this has been tried before. The most notable example is
Active Nets, which was created to overcome the problem with deploying
multicast and IPv6. Yet our "ossified" kernels now have multicast and
IPv6 but not Active Nets.

It was the rationale for the GENI testbed and so-called "clean slate"
approaches. Which have yet to yield anything operational.

Can we please learn from the past?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 May 2016 16:03:18 -0700

On 5/19/2016 3:58 PM, Toerless Eckert wrote:
> On Thu, May 19, 2016 at 03:22:23PM -0700, Joe Touch wrote:
> Its not about reinventing the Internet over UDP, its just about providing
> an amendment to the Internet architecture that defines a better demarkation
> between OS-land and application-land.

The Internet architecture has no knowledge of that distinction.

At best, it had the knowledge of privileged vs non-privileged in the
assignment of transport port numbers, but that assumption has been
depcrated.

>  There is no reason whatsoever why 
> anything more than transport layer demultiplexing must be in the kernel,
> and there are a lot of good reasons to have per-application differences in
> any of the more advanced transport layer functions.
>
> Expecting the superset of state-of-the art transport layer functions to ALL
> exist in ALL OS kernels of internet hosts is just a ridiculous architecture
> proposition.
And there is nothing in the Internet architecture that constrains any of
this.

Your issue is with the OS, not the Internet.

Please don't *#*!-up the Internet to fix an OS implementation issue.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 15:58:59 -0700

between OS-land and application-land. There is no reason whatsoever why 

UDP is the only solution to empower apps to have the advanced transport  layer
functions they want, running on the OSs they need to.

This is architecturally the cleanest solution. There is no simpler or better
option, because UDP really is only that: a transport layer demultipler in the
kernel.

Slavery was a mistake in 1789, not thinking about userland agility for
transport functions was a mistake in the original internet architecture.
We need an amendment that fixes this.

> consider RFCs useful when they address only temporary concerns.

Again: please define the metrics for you name calling ("level of complexity").

Cheers
    Toerless

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 May 2016 16:23:14 -0700

> Your issue is with the OS, not the Internet.
But there is the issue issue with Internet. Middleboxes will drop
packets they don't like for arbitrary reasons. RFC2460 clearly states
that intermediate devices should not inspect EH and yet they do and
often drop these packets. As I pointed out we've seen middleboxes that
drop TCP packets that contain options unknown to it, ones that drop
SYN packets that contain data (problem with deploying TFO),
middleboxes that take it upon themselves to rewrite parts of the TCP
header as they see fit. Heck, before we were using TLS we had
middleboxes parsing TCP payloads and doing strange things to it like
inserting their own ads into http (see accord BOF).

The common theme here is that these middlebox activities are not done
per any standard, there is no security or accountability, and we have
no way to distinguish malicious versus beneficial interaction; but we
(application providers) have to worry about all of this since it is
reality. Middlebox invasiveness at layer 4 runs contrary to the
end-to-end model and is a primary source of protocol ossification.
Either we need to wait for middelboxes to stop being invasive or we
need to eliminate the opportunity to be invasive. I don't see that
waiting the for the problem to be fixed for us is productive, hence we
will pursue the latter.

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 May 2016 16:30:18 -0700

On 5/19/2016 4:23 PM, Tom Herbert wrote:
> ...

Now your issue is with the ISOC for not enforcing compliance, or at
least requiring validation before using terms like "supports Internet
protocols and standards".

However, like problems with OS implementation, these issues cannot be
corrected with technology. All you will accomplish is to "move the
goalposts" and escalate the problems you're already experiencing.

Joe

---

From: Ca By <[email-masked]>
Date: Thu, 19 May 2016 16:32:28 -0700

On Thursday, May 19, 2016, Tom Herbert <[email-masked]> wrote:

> On Thu, May 19, 2016 at 4:03 PM, Joe Touch <[email-masked] <javascript:;>>
> wrote:
> >
> >
I am sympathetic to your argument. But please answer this

1) if the middleboxes block xyz today, why will they not block your udp
innovations ?

2) udp is blocked in many places, so thinga like quic fall back to tcp.

3) given 1 and 2,  is your innovation suceptable to a bid-down attack that
makes the effort useless ?

My view is that middle boxes dont scale and are going away. TCP / TLS / H2
along with decreased  latencies in LTE make  the escalating cost of middle
boxes not smart.

My view is based on one real network that had L4 middle boxes for 5+
years and removed them with growing LTE penetration that made scale a
problem and benefits marginal.

Ymmv

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 May 2016 16:38:54 -0700

> goalposts" and escalate the problems you're already experiencing.
I disagree. Applying TLS to all of TCP on the Internet has halted
middlebox invasiveness beyond layer 4 and is a clear security win for
our users (much to the chagrin of some network operators who were
parsing payload for legitimate reason, but we will work to adapt their
needs to the encrypted world). I don't see why moving the obfuscation
point to include transport headers won't have the same effect. If the
network can't see it, it can't ossify it.

Tom

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 16:48:36 -0700

> Your issue is with the OS, not the Internet.

Definitely, thats one issue.

> Please don't *#*!-up the Internet to fix an OS implementation issue.

Still haven't made the point why this is *#*!-up the Internet.

Toerless

---

From: Tom Herbert <[email-masked]>
Date: Thu, 19 May 2016 16:50:18 -0700

> 1) if the middleboxes block xyz today, why will they not block your udp
They can choose to arbitrarily block UDP if they want (again that is
not standard, but we can't stop them). The assumed rationale is that
all UDP is generally a DOS problem, however presuming we using well
known ports for transport protocols that are properly congestion
controlled and not source of reflection attacks, those specific ports
can be allowed as safely as packets with IP protocol number 6 are.

> 2) udp is blocked in many places, so thinga like quic fall back to tcp.
Yes, that is a given. Anything new we deploy on the Internet, be it
IPv6, SCTP, UDP, TFO, extension headers will necessitate fallback to
least common denominator like simple TCP/IP.

> makes the effort useless ?
I think that depends on how pervasive UDP drop are. The data presented
in BA and QUIC deployment data seems to indicate that UDP is mostly
deployable on the Internet right now.

Tom

> My view is based on one real network that had L4 middle boxes for 5+ years
> and removed them with growing LTE penetration that made scale a problem and
> benefits marginal.
>
> Ymmv
>
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 16:55:48 -0700

> deployable on the Internet right now.

Btw: If your goal is to only get foo over UDP without SPUD then i think this
would be the main disagrement i'd have. But i still think any work that leads
to more business relevant UDP traffic over non-well known ports will have middlebox
operators wake up to the problem, having to let UDP through, and tht
ultimatelly will increate ask for SPUD.

;-))

Cheers
    Yoerless

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 May 2016 16:55:56 -0700

> Still haven't made the point why this is *#*!-up the Internet.
I did - in summary: you're adding a new protocol that we don't otherwise
need, can't seamlessly transition to kernel-based transports without
requiring the additional encapsulation overhead, and only end up making
DPI look one more header in.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 17:13:23 -0700

> the right place (which might be at a different port inside the kernel).

Nah. Thats where i started off from as well. But then think about you having
this wonderful application that started out with a cool & better TCP stack.
Maybe the kernel catches up some time to do exactly what you want. But it
could equally evolve into soment which may be better but not really for
your application - at least not without improving/changing your app.

If i want to deploy one binary of an app and let it run stable, kernel changes
are the worst thing that can happen to me. Having my transport stack in my
app is a godsend to decouple me from this.

Why do apps want containers ? To decouple them from the variability of userland.
And arguably most userland evolution is good. But it creates incompatibilityes
and ongoing app-update work. Wasted effort for many apps. Same argument can be
made about transport stack in the app.

> You can't expect support for these new TCP variants, but you expect ubiquitous support for IPv6?

pretty much, yes. But i am right now just representing a strategic interest.
the quicker yo want to get things running the more hacks you may need.

> see draft-ietf-intarea-tunnels, section 4.5

Nice. Yeah. ICMP is a challenge. Doesn't make the strategy wrong though.

> I'm confused now; above you assumed IPv6. Now you're comparing UDP/IPv4

No, i am saying that a loss in packet efficiency (sizze of header) did not
stop us to do IPv6, it shouldn't stop us to run transport over UDP. If we
do transport UDP purely with encap this creates more overhead. Ultimately,
i wish we would only crearte new transports natively on UDP eg: without
duplicating anything UDP already does.

> version or not? or will you now require the kernel to do the extra UDP

Your stability is my stability as explained above.  So i am all for
that. The ossification comes i want to avoid is to share a single transport stack
version forced onto me by some crazy OS-vendor roadmaps across 30 applications
i am running on my host, and they all have different transport requirements.
Once threy have their own transport stack bound to them i am home free. My
new cool app will have the new cool transport improvements, while my legacy
"do not touch me" app will not feel any negative impact from me upgrading
my OS once a year because my vendor forces me to.

> features into these OS transport implementations.

This is really a matter of lifecycle management of software.a And you do NOT
want to get all "desired" features into OS implementations. Just think about
an important app you wrote depending on some transport stack feature that
later was found to be not such a good idea, but the app itself is still
business critical. And not developed any further. What do you do ? Put
it in a VM, right ? If it would have just started with it's own transport stack
library, you'd get away much easier.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 17:20:14 -0700

> DPI look one more header in.

- Ideally, you would just design optimized new transports that use
  UDP as demux layer. Think about it. Just try to imagine you'd be doing TCP
  with IP proto UDP... how much more overhead would you need to add ?

- IMHO there are only minute benefits of in-kernel transport protocol. I'd be happy
  to have them die out. OS vendors can happily implement TCP wih UDP ports as
  a library. That immediately makes it part of my docker container and gives
  me predictable behavior when i distribute my container.
- No deeper look with DPI needed.

Cheers
    Toerless

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 May 2016 18:06:11 -0700

> app is a godsend to decouple me from this.
I don't disagree with the potential benefits. I disagree with using UDP
encapsulation to achieve an end-run around the OS exerting control.

> Why do apps want containers ? To decouple them from the variability of userland.
Hmm. So containers are good, but doing a full hypervisor with an
(encapsulated) OS isn't as good?

See the analogy? You're arguing for user access to rawIP.

> stop us to do IPv6, it shouldn't stop us to run transport over UDP.
I wasn't arguing solely on the basis of the additional bytes. It's the
additional protocol layer that is expensive.

...
> This is really a matter of lifecycle management of software. And you do NOT
> want to get all "desired" features into OS implementations.
OK, so put differently, I don't want to create a mess in the Internet to
fix an OS problem. The OS problem is lack of access to raw IP. If you
had that, you wouldn't need any of this.

That's a simple direct target. A lot simpler than untangling the mess
that this reinvention will cause.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 May 2016 18:08:35 -0700

On 5/19/2016 5:20 PM, Toerless Eckert wrote:
>   UDP as demux layer. Think about it. 

That's why I said you were reinventing the Internet at the UDP layer. 
If you expect the end game is that we keep UDP as an additional demuxing
layer, I think this is not just a bad idea, it's a VERY bad idea.

>   a library. 

Some do. I recall that there were ways to update old versions of Windows
with new transport stacks (Trumpet, I think?).

> That immediately makes it part of my docker container and gives

I agree. So go fix that, IMO, and leave the Internet alone.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 18:24:31 -0700

> encapsulation to achieve an end-run around the OS exerting control.

Don't think of it as UDP. Think of it as creating multiple layers inside the current
transport layer. The lowest layer is demultiplexing. Architecturally very clean.

> (encapsulated) OS isn't as good?

Well. one logical reason why is the demultiplexing: Everything below
it is naturally shared, everything above it IMHO naturally not. That makes it
realistically harder to virtualilze IP. But yes, we've been thinking about doing that.
In IPv6 it's easy, we'd have enough address space per-app. And there are nice examples
for this even if some of them are mostly driven by runarounds on arch limits (port number
space).

> See the analogy? You're arguing for user access to rawIP.

No, not really. But i am also not a fan for architectural and pragmatic reasons to use IP extensions. I
The why is longer, but lets just say that without them, i see no use-case requirements to
virtualize the IP layer in a host.

> additional protocol layer that is expensive.

Well, if we stick to architectural vision, there is no additional protocol layer.
Just strict sublayering with explicit interfaes between.  And reuse one well
working demux layer - UDP.

> had that, you wouldn't need any of this.

Well, i told you why i think it's not a mess but good. 

> that this reinvention will cause.

No, not really, because we can't agree on criteria to quantify 'mess'.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 19 May 2016 18:26:24 -0700

> layer, I think this is not just a bad idea, it's a VERY bad idea.

Why ?

> with new transport stacks (Trumpet, I think?).

Sure, but i want to have a network architecture whose API standards allow all OSs to do this.
The solutions you're talking about have OS specific APIs. ANd i want UDP as the cross-OS
demux layer.

Cheers
    Toerless

---

From: Michael Welzl <[email-masked]>
Date: Fri, 20 May 2016 09:33:09 +0200

BRAAAAAAA TOOOOOOOOOOOOOTTT  TOOOOOOOOOOT BRRRAAAAA TOOOOOOOOOOOTT   !!!!!

> least common denominator like simple TCP/IP.

....... this is so true, and this is happening so little for transports because applications are tied to the protocol (or at least can't use features of protocols other than TCP or UDP, even with higher-level APIs), and this is why the TAPS WG is so important.

TAPS needs more activity I think...

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 May 2016 13:15:28 +0200

hi Michael,

> On 20 May 2016, at 09:33, Michael Welzl <[email-masked]> wrote:
> 

Agree completely; I think one of the things that will drive *that* is more diversity of transports to choose from.

Cheers,

Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 May 2016 10:22:04 -0700

On 5/19/2016 6:26 PM, Toerless Eckert wrote:
> O there are only minute benefits of in-kernel transport protocol. I'd be happy

UDP is not an API. 

Posix is what you want to extend, not the Internet.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 May 2016 10:22:08 -0700

> transport layer. The lowest layer is demultiplexing. Architecturally very clean.
Here's why it's not:

TCP isn't a layer by itself; it relies on the IP pseudoheader.

TCP in UDP in IP is architecturally incomplete.

TCP in IP in UDP in IP would be fine, as would TCP in IP in IP. But we
already have those.

That's why we don't need this and why it's a mess.

That's also why other tunnels - which encapsulate transport through net
or link inside transport, net, or link - are much more architecturally
clean and have not generated this reaction.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 20 May 2016 11:21:15 -0700

Thanks, Joe, inline

> TCP isn't a layer by itself; it relies on the IP pseudoheader.

Ack.

> TCP in UDP in IP is architecturally incomplete.

Right. but i am claiming that is possible and not too difficult. Eg:
remove TCP header port fields, just rely on UDP port fields, adopt
pseudoheader rules for TCP/UDP, etc. pp.

> That's why we don't need this and why it's a mess.

Still not clear how you jump from architectural incomplete to "no need, it's a mess".

> clean and have not generated this reaction.

I think network layer overlay solutions are architecturally fare less clean
that modularizing the transport layer and cleaning up historic dependencies
against network layer.

Toerless

---

From: Tom Herbert <[email-masked]>
Date: Fri, 20 May 2016 11:24:51 -0700

> That's why we don't need this and why it's a mess.
If it's more palatable we can accurately call this a new application
layer protocol that implements reliability and congestion control
instead of phrasing it encapsulation of TCP over UDP. In one variant,
the protocol has the same packet format and same algorithm processing
as TCP except for how connection lookup is done (other variants would
be things that look like SCTP, DCCP, etc).  The implementation of this
application layer protocol in no way affects the existing transport
protocols or otherwise affects the network (network just sees UDP
packets). There are many instances of applications implementing their
own congestion controlled and reliable protocols, so I don't see that
we're doing anything different than those in this except that are
trying leverage existing transport protocols and implementation.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 May 2016 11:31:48 -0700

> pseudoheader rules for TCP/UDP, etc. pp.

But the port fields don't add entropy - you wouldn't want to do that
within a transport. At best, they represent a portion of the entropy of
the TCP ports. However, that's a poor (and smaller) substitute for the
IPv6 flow field (and you are assuming IPv6).

Further, you've just admitted this is a mess architecturally.
> Still not clear how you jump from architectural incomplete to "no need, it's a mess".

I've already repeatedly explained why this isn't needed, including the
port demux issue above, as well as the existence of numerous other more
appropriate tunneling mechanisms below. It's a mess exactly because of
the hack you need to define an appropriate pseudoheader. Adding
protocols and layers we don't actually need only makes the Internet
architecture messier.
> that modularizing the transport layer and cleaning up historic dependencies

If you want to clean up transport dependencies, have at it. That's not
the goal of this doc.

I've written quite a bit over the past 20 years about why network layer
overlay solutions are architecturally clean. I'll let that work - and
the prevalence of their current use - speak for itself.

I've registered my position. At this point, it would be useful for
others to speak up.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 20 May 2016 11:32:30 -0700

> pseudoheader rules for TCP/UDP, etc. pp.
NAT makes life complicated, especially if we want to have connections
survive across UDP NAT address/port remapping. Most of the draft is
about dealing with this. One nice feature (that I borrowed from QUIC)
is to negotiate a shared session identifier for the connection that is
unique to both sides. With this a connection is identified (at the end
nodes) without using the addresses or UDP port numbers. So connection
identification becomes location independent which solves the NAP
remapping problem and also allows for mobility.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 May 2016 11:34:49 -0700

On 5/20/2016 11:24 AM, Tom Herbert wrote:
> instead of phrasing it encapsulation of TCP over UDP.

You're trying very hard to find a nail for this hammer.

Instead, you might consider DCCP or SCTP.

If you need to tunnel those to transit a NAT, we already have support
for that with other tunnel mechanisms.

There is no clear rationale for needing this solution except to overcome
OS implementation issues.

Again, that is my position and I've made it fairly clear at this point.
I'd like to see how others feel.

Joe

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 20 May 2016 19:13:53 +0000

> NAT makes life complicated, especially if we want to have connections survive across UDP NAT address/port remapping. Most of the draft is about dealing with this. One nice feature (that I borrowed from > QUIC) is to negotiate a shared session identifier for the connection that is unique to both sides. With this a connection is identified (at the end
> nodes) without using the addresses or UDP port numbers. So connection identification becomes location independent which solves the NAP remapping problem and also allows for mobility.

Ahhh, Section 3.2 is really cool...

I can clearly see the tremendous improvement for user privacy if the highly privacy-sensitive TCP header fields finally get all encrypted, including things like flags, sequence numbers etc., if there is now a new clear text identifier that just happens to be unique per subscriber. What a great improvement for privacy in the Internet! And even better that it seems compatible with QUIC...

Sorry, I really could not resist.

Michael

---

From: Christian Huitema <[email-masked]>
Date: Fri, 20 May 2016 23:38:07 +0000

On Friday, May 20, 2016 9:14 AM, Michael Scharf wrote: 
> To: Tom Herbert <[email-masked]>; Toerless Eckert
> <[email-masked]>
> Cc: Joe Touch <[email-masked]>; spud <[email-masked]>
> Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-
> transports-over-udp-00.txt
> 
> survive across UDP NAT address/port remapping. Most of the draft is about
> dealing with this. One nice feature (that I borrowed from > QUIC) is to
> negotiate a shared session identifier for the connection that is unique to both
> sides. With this a connection is identified (at the end
> I can clearly see the tremendous improvement for user privacy if the highly
> privacy-sensitive TCP header fields finally get all encrypted, including things
> like flags, sequence numbers etc., if there is now a new clear text identifier
> that just happens to be unique per subscriber. What a great improvement for
> privacy in the Internet! And even better that it seems compatible with QUIC...
> 

Actually, using a 64 bit QUIC-like identifier to support mobility or multi path is a terrible idea. The best way to describe it is, "clear text super cookie." It allows adversaries to link connections originating from different IP addresses. Providing such linkability is a boon for traffic analysis and user tracking, and of course a big loss for privacy. And yes, MP-TCP is doing something similar, but at least they acknowledge the problem and want to find a solution. If we want privacy, the identifiers used to link several connections together have to be placed inside the crypto envelope, not in a clear text header.

-- Christian Huitema

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sat, 21 May 2016 06:04:39 +0000

> Actually, using a 64 bit QUIC-like identifier to support mobility or
> multi path is a terrible idea. The best way to describe it is, "clear
> text super cookie." It allows adversaries to link connections
> originating from different IP addresses. Providing such linkability is
> a boon for traffic analysis and user tracking, and of course a big loss
> for privacy. And yes, MP-TCP is doing something similar, but at least
> they acknowledge the problem and want to find a solution. If we want
> privacy, the identifiers used to link several connections together have
> to be placed inside the crypto envelope, not in a clear text header.

But in a user space UDP-based transport protocol the app has full control over how the super cookie is used, and where it is placed in the packet, right?

What prevents this from becoming the common substrate for super cookies?

Michael

---

From: Dave Dolson <[email-masked]>
Date: Sat, 21 May 2016 14:23:57 +0000

Another way of explaining the need for PLUS is that the internet architecture is deficient because it only provides connectivity between hosts, whereas there is a need to provide connectivity between applications running on hosts. This is becoming more relevant as processes are jailed (using various approaches) for security.

Raw sockets require root privilege to prevent different apps from reading or forging each others' packets. I think this restriction still makes sense on single-user machines‎, so it would not be right to say the fix is to loosen O/S security.

So, one role of the PLUS layer is to extend the network-layer address to being able to address the application at IP address + port.

This is why I don't think there is a layering travesty here. It's redefining the network layer to be between applications.

-Dave

  Original Message
From: Joe Touch
Sent: Friday, May 20, 2016 2:40 PM
To: Tom Herbert
Cc: Toerless Eckert; spud
Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 21 May 2016 08:53:00 -0700

> Actually, using a 64 bit QUIC-like identifier to support mobility or multi path is a terrible idea. The best way to describe it is, "clear text super cookie." It allows adversaries to link connecti…

Is there actually some good text to read up on how today tracking of IP addresses
is used today by any party with only transit-path access, aka: anyone who is neither
one of my access-SP nor one of the cloud services i talk to and provide an 
app-level-identity to. And neither a party in collusion with these, exchanging
info with them.

I am asking, because i need legal protection against perpass by those parties, not
technical ones. Or competition that does give me legal promises beyond what the law
guarantees me by default. 

Eg: doing improvements on this piece and declaring privacy achieved when you've
got it encrypted looks like security theater to me.

Toerless

---

From: Tom Herbert <[email-masked]>
Date: Sat, 21 May 2016 08:53:20 -0700

> Actually, using a 64 bit QUIC-like identifier to support mobility or multi path is a terrible idea. The best way to describe it is, "clear text super cookie." It allows adversaries to link connecti…
We assume that strong security must be applied, so unlike MP-TCP the
transport headers are encrypted and the only information sent in plain
text is the session identifier (serving as an SPI) and DTLS headers.
In the case of a connection surviving across NAT remapping an attacker
could observe that the connection has been remapped, but that reveals
no new information about the connection than it had previously except
that the it was remapped by an intermediate device. That does
potentially reveal information about the NAT device, for instance it
could probably ascertain the timeout, but I don't know how useful that
would be in and it could probably be determined by other means.

But even given that, yes, I would prefer that anything that identifies
flows on the network (UDP tuples, session identifiers, flow labels) is
periodically rotated to reduce the ability of intermediate nodes to
track my flows over long periods of time. The protocol to negotiate a
new session identifier can be implemented in the encrypted portion of
the packet. To change the UDP tuple a client can pick a different
ephemeral source port (in userspace sockets implementation this would
close one socket and create a new and do a connect without explicit
bind).

Tom

---

From: Jana Iyengar <[email-masked]>
Date: Sat, 21 May 2016 20:03:26 -0700

Possibly unsurprisingly, I like this draft. I'd like to argue some of the
choices made in the draft but I'll do that separately. For now, I just
wanted to articulate a few thoughts as I caught up on this thread:

- The ship has sailed on new native-IP transports. I worked on SCTP for 6
years and tried and watched it get nowhere in terms of deployment over
native-IP. It wasn't because it was in the kernel, it was primarily because
of NATs and various middleboxes. Yes this is definitely my opinion, but
arguing this point is silly. No new native IP transport has seen
significant deployment over the internet over the past 20 years, and it's
not for lack of trying.

- People reasonably consider timescales of a few years when thinking about
building and deploying a new transport. QUIC took a few years to build and
deploy over UDP, and the Adobe folks did RTMFP over UDP as well (a while
ago) in a reasonable time frame.

- Encryption is the *only* way to attempt avoiding ossification. Its
certainly reasonable to consider that it may not do the job, but without an
alternative, I'm afraid it will have to do for now.

- Michael raised a point about QUIC connection ID, which is incorrect: The
QUIC connection ID is NOT unique per user. It's a connection ID, and on a
single-path connection, it exposes exactly as much as TCP, DCCP, or SCTP do
(unique per 4-tuple). On a multipath connection, it exposes exactly as much
as MPTCP does. We can perhaps do better than MPTCP for multipath in terms
of privacy, I don't want to engage on this point on this thread since it's
not relevant to this thread.

- jana
On May 21, 2016 8:53 AM, "Tom Herbert" <[email-masked]> wrote:

> about
> multi path is a terrible idea. The best way to describe it is, "clear text
> super cookie." It allows adversaries to link connections originating from
> different IP addresses. Providing such linkability is a boon for traffic
> analysis and user tracking, and of course a big loss for privacy. And yes,
> MP-TCP is doing something similar, but at least they acknowledge the
> problem and want to find a solution. If we want privacy, the identifiers
> used to link several connections together have to be placed inside the
> crypto envelope, not in a clear text header.
> >

---

From: Joe Touch <[email-masked]>
Date: Sat, 21 May 2016 21:14:10 -0700

On 5/21/2016 7:23 AM, Dave Dolson wrote:
> Another way of explaining the need for PLUS is that the internet architecture is deficient because it only provides connectivity between hosts, whereas there is a need to provide connectivity between applications running on hosts. 

Tunnels already provide that.

A tunnel is fundamentally a link layer over which network layer(s)
transit. UDP/IP can provide that capability through a variety of
existing ways.

However, it's nonsensical to expect a transport to use a tunnel
directly, just as TCP doesn't run over Ethernet.

> This is becoming more relevant as processes are jailed (using various approaches) for security.
>

Again, now you're getting at an OS implementation issue. That is never
usefully fixed by the network architecture.

> So, one role of the PLUS layer is to extend the network-layer address to being able to address the application at IP address + port.
That's what IP in UDP already accomplishes.
> This is why I don't think there is a layering travesty here. It's redefining the network layer to be between applications.

Apps live inside hosts, and are identified by transport ports. Hosts are
identified by IP addresses. If you have a host inside a host, you need
to treat the outer host as a router+host, and the guest OSes as other
hosts on that router. See:
J. Touch, T. Faber, “Dynamic Host Routing for Production Use of
Developmental Networks <http://www.isi.edu/touch/pubs/icnp97/>,” in
/Proc. ICNP ’97/, Atlanta, Oct. 1997, pp. 285-292.

There's no problem solving any of this with a network layer inside UDP.
The problem is assuming that you can virtualize a network using just the
transport layer - a layer that fundamentally depends on addresses at a
network layer you fail to provide.

UDP already is used for tunnels in ways that solve this problem
correctly. Why do we need an incorrect approach?

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 22 May 2016 00:21:31 -0400

> to be a baby sitter for TLS. TLS has to be a standalone babysitter. That

There is nothing in TLS to stop it being attacked. All TLS can do is to
prevent certain attacks from succeeding and it is only designed to prevent
Confidentiality or Integrity attacks.

TLS isn't at all good at stopping denial of service attacks. When an attack
occurs, there isn't much that can be done apart from closing the socket and
trying again.

If you want to add in robustness, you need to be able to detect which of
your TCP packets were mangled and that really isn't possible in user space.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 22 May 2016 17:30:33 +0000

> would be in and it could probably be determined by other means.

I am not sure who would care so much about the NAT device. But, e.g., what about the privacy impact on users of cascaded NATs or some form of onion routing (e.g. TOR-like)?

(Disclaimer: I am not an expert for those, so I apologize if I miss something here.)

> close one socket and create a new and do a connect without explicit

Well, "periodic rotation" rotation can mean a lot, including 10 years or so. What order of magnitude would you suggest? 

Michael

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 22 May 2016 17:30:07 +0000

Regarding the statement that my comment is incorrect:

·         I did not want to imply that the QUIC connection ID *is* unique per subscriber in the current prototype. I haven’t checked the code but for sure I assume that it is not implemented this way. My concern is about a protocol that by design *does not prevent* that and leaves the decision e.g. up to an application developer decision.

·         The root cause of the problem may be that draft-tsvwg-quic-protocol-02 lacks a security consideration section. The privacy implications of the connection ID require IMHO significant attention there. But, indeed, this discussion does not belong on this list.

·         I disagree that any connection ID that is meant to be location-independent (i.e., independent of the 5-tuple) exactly exposes the same information as the 5 tuple. A trivial counter-example is a connection ID that is build from the MAC address concatenated by some random bits. For instance, this would be an easy way to construct a unique 64bit identifier that would survive NAT rebinding, but, well, this would have some privacy impact, no? Specifically, since it may show up in every packet at a constant offset, one could use this ID for “interesting” purposes, or do I miss something? What prevents a user-space transport protocol implementation from picking the MAC address? Some MUST in some I-D?

Furthermore, I believe that this discussions matters for PLUS/SPUD, since:

·         If two different, worked-out candidate users of the common substrate seem to have similar requirements for signaling information in clear-text, this could be some lessons learnt for what may be required in the common substrate.

·         Even if this is not the case, the current excessive use of the term “encryption” in the PLUS/SPUD charter IMHO has to be reviewed, since at least two potential candidate protocols actually seems to use information in clear text. Example: “The primary goal of PLUS is to enable the deployment of arbitrary, fully encrypted transport protocols”. Well, at least I learn now that not everything is “fully” encrypted…

·         Finally, from the current charter I don’t understand whether PLUS/SPUD would consider the requirements of middleboxes designed to provide user anonymity (e.g., TOR-like). I’d personally be fine with flagging their specific requirements as out-of-scope. But for sure there is a user community of that sort of infrastructure and it may make sense to discuss early how to deal with that.

Michael

From: Jana Iyengar [mailto:[email-masked]]
Sent: Sunday, May 22, 2016 5:03 AM
To: Tom Herbert
Cc: Toerless Eckert (eckert); [email-masked]; Christian Huitema; Joe Touch; Scharf, Michael (Nokia - DE)
Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt

Possibly unsurprisingly, I like this draft. I'd like to argue some of the choices made in the draft but I'll do that separately. For now, I just wanted to articulate a few thoughts as I caught up on this thread:

- The ship has sailed on new native-IP transports. I worked on SCTP for 6 years and tried and watched it get nowhere in terms of deployment over native-IP. It wasn't because it was in the kernel, it was primarily because of NATs and various middleboxes. Yes this is definitely my opinion, but arguing this point is silly. No new native IP transport has seen significant deployment over the internet over the past 20 years, and it's not for lack of trying.

- People reasonably consider timescales of a few years when thinking about building and deploying a new transport. QUIC took a few years to build and deploy over UDP, and the Adobe folks did RTMFP over UDP as well (a while ago) in a reasonable time frame.

- Encryption is the *only* way to attempt avoiding ossification. Its certainly reasonable to consider that it may not do the job, but without an alternative, I'm afraid it will have to do for now.

- Michael raised a point about QUIC connection ID, which is incorrect: The QUIC connection ID is NOT unique per user. It's a connection ID, and on a single-path connection, it exposes exactly as much as TCP, DCCP, or SCTP do (unique per 4-tuple). On a multipath connection, it exposes exactly as much as MPTCP does. We can perhaps do better than MPTCP for multipath in terms of privacy, I don't want to engage on this point on this thread since it's not relevant to this thread.

- jana
On May 21, 2016 8:53 AM, "Tom Herbert" <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, May 20, 2016 at 4:38 PM, Christian Huitema
<[email-masked]<mailto:[email-masked]>> wrote:
>> To: Tom Herbert <[email-masked]<mailto:[email-masked]>>; Toerless Eckert
>> <[email-masked]<mailto:[email-masked]>>
>> Cc: Joe Touch <[email-masked]<mailto:[email-masked]>>; spud <[email-masked]<mailto:[email-masked]>>

Tom

_______________________________________________
Spud mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spud

---

From: Michael Welzl <[email-masked]>
Date: Sun, 22 May 2016 21:43:44 +0200

Hi,

I still didn’t get to read the draft - apologies!  I probably like it  :-)   but I hope it allows putting multiple TCP connections under one single UDP 5-tuple.
Anyway, not speaking pro- or con- this draft, just a comment in line:

> On 22. mai 2016, at 05.03, Jana Iyengar <[email-masked]> wrote:
> 
“The ship has sailed” and “it’s not for lack of trying” are both wrong IMO. How many applications have tried to use SCTP/IP and fallen back to TCP in case it doesn’t work? How many applications do you expect to change in order to get such a change to happen? And why should anyone expect someone designing or maintaining a router or middlebox to support native SCTP when they never even see the packets and never even hear anyone say “my application works better elsewhere because of SCTP” ?

This is what TAPS is trying to address. It’s a very deep architectural problem of the Internet - an inability to automate fall-backs, which unnecessarily burdens application developers. Rant, rant, rant, make me stop   :-)

Now all this being said, I also don’t fully get why some folks have such a big problem with running stuff over UDP. I’m not against doing that, if only as a temporary solution that would serve to convince people that the transport (option, ..) is useful.
In a TAPS world, it’s just another option to try…

Cheers,
Michael

---

From: Ca By <[email-masked]>
Date: Sun, 22 May 2016 13:06:24 -0700

On Sunday, May 22, 2016, Michael Welzl <[email-masked]> wrote:

> Hi,
>
> I still didn’t get to read the draft - apologies!  I probably like it  :-)
>   but I hope it allows putting multiple TCP connections under one single
> UDP 5-tuple.
> On 22. mai 2016, at 05.03, Jana Iyengar <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> “The ship has sailed” and “it’s not for lack of trying” are both wrong
> IMO. How many applications have tried to use SCTP/IP and fallen back to TCP
> in case it doesn’t work? How many applications do you expect to change in
> order to get such a change to happen? And why should anyone expect someone
> designing or maintaining a router or middlebox to support native SCTP when
> they never even see the packets and never even hear anyone say “my
> application works better elsewhere because of SCTP” ?
>
> This is what TAPS is trying to address. It’s a very deep architectural
> problem of the Internet - an inability to automate fall-backs, which
> unnecessarily burdens application developers. Rant, rant, rant, make me
> stop   :-)
>
> Now all this being said, I also don’t fully get why some folks have such a
> big problem with running stuff over UDP. I’m not against doing that, if
> only as a temporary solution that would serve to convince people that the
> transport (option, ..) is useful.
The fact that udp is mostly (by volume) internet attack traffic  is my
concern with udp.

If legitimate traffic starts using udp in volume, it will make
distiguishing and thwarting voulmetric attacks very difficult at scale.
Without currently curbing n * 100g blasts of udp traffic with blanket
policers, i would not be able to keep my network up... This is a daily
issue.  For example, my usual udp volume is about 1%. If it goes to 10%
suddenly, it is likely smart to drop 11% and onwards as a 10x increase in
udp is 100% certainly not legit.

My request to quic and spud is simply use a different transport protocol
number so that their interesting and innovative traffic does not run up
against the many network policers that are required to enforce well known
baselines of good normal udp traffic. The quic folks say that they cannot
do that since 10 year old cpe only passes udp and tcp, then they rant about
ossified stacks and how we need to put everything on udp to make progess
... Seems like they are just choosing to ossify on udp ...  And udp is
already considered trash (reflection attacks) ...So we agree to disagree, i
guess

https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00

Cheers,

---

From: Michael Welzl <[email-masked]>
Date: Sun, 22 May 2016 22:24:49 +0200

> On 22. mai 2016, at 22.06, Ca By <[email-masked]> wrote:
> 
> 
> 
> On Sunday, May 22, 2016, Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
>> On 22. mai 2016, at 05.03, Jana Iyengar <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> 
> The fact that udp is mostly (by volume) internet attack traffic  is my concern with udp. 
> 
> If legitimate traffic starts using udp in volume, it will make distiguishing and thwarting voulmetric attacks very difficult at scale. Without currently curbing n * 100g blasts of udp traffic with blanket policers, i would not be able to keep my network up... This is a daily issue.  For example, my usual udp volume is about 1%. If it goes to 10% suddenly, it is likely smart to drop 11% and onwards as a 10x increase in udp is 100% certainly not legit. 
> 
> My request to quic and spud is simply use a different transport protocol number so that their interesting and innovative traffic does not run up against the many network policers that are required to enforce well known baselines of good normal udp traffic. The quic folks say that they cannot do that since 10 year old cpe only passes udp and tcp, then they rant about ossified stacks and how we need to put everything on udp to make progess ... Seems like they are just choosing to ossify on udp ...  And udp is already considered trash (reflection attacks) ...So we agree to disagree, i guess 
> 
> https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 <https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00>

Well - still wearing my TAPS glasses, I’d simply say “okay, in this case, try native too, and prefer that if it works".

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Mon, 23 May 2016 16:32:47 +0200

hi Michael,

On your questions as to the PLUS charter:

> On 22 May 2016, at 19:30, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
> 

This is a good point, and a reason for coordination between the PLUS and QUIC efforts (should WGs be chartered here).

> ·         Even if this is not the case, the current excessive use of the term “encryption” in the PLUS/SPUD charter IMHO has to be reviewed, since at least two potential candidate protocols actuall…

This is imprecise language and should be cleaned up. The point is that everything above a PLUS shim layer is encrypted, and everything below open to the path. There should probably be something outlining the broad architecture here, which would make this more clear.

> ·         Finally, from the current charter I don’t understand whether PLUS/SPUD would consider the requirements of middleboxes designed to provide user anonymity (e.g., TOR-like). I’d personally b…

I *think* this is orthogonal -- I can't see what in PLUS would break TOR, or how stuff in PLUS could make TOR work better, without partially redesigning both... can you say more about what your concerns are here?

Cheers,

Brian

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 23 May 2016 14:56:02 +0000

> I *think* this is orthogonal -- I can't see what in PLUS would break TOR, or how stuff in PLUS could make TOR work better, without partially redesigning both... can you say more about what your con…

I don't think it is orthogonal, but I could imagine some quite contradicting design objectives on the required signaling e.g. between end system and TOR proxies. But I am not a TOR expert.

Why don't e.g. the BoF chairs reach out to the TOR community to get feedback and to ensure openness in the IETF process regarding all possibly affected users in the Internet?

For instance, if there is no feedback from the a certain community, it would be easy to argue that something can be excluded in the charter.

Michael

---

From: Tom Herbert <[email-masked]>
Date: Mon, 23 May 2016 08:36:44 -0700

On Sun, May 22, 2016 at 1:06 PM, Ca By <[email-masked]> wrote:
>> but I hope it allows putting multiple TCP connections under one single UDP
>> 5-tuple.
>> arguing this point is silly. No new native IP transport has seen significant
>> deployment over the internet over the past 20 years, and it's not for lack
>> of trying.
>>
>> unnecessarily burdens application developers. Rant, rant, rant, make me stop
>> :-)
>>
>> big problem with running stuff over UDP. I’m not against doing that, if only
>> as a temporary solution that would serve to convince people that the
> If legitimate traffic starts using udp in volume, it will make distiguishing
> and thwarting voulmetric attacks very difficult at scale. Without currently
> curbing n * 100g blasts of udp traffic with blanket policers, i would not be
> able to keep my network up... This is a daily issue.  For example, my usual
> udp volume is about 1%. If it goes to 10% suddenly, it is likely smart to
> drop 11% and onwards as a 10x increase in udp is 100% certainly not legit.
>
> baselines of good normal udp traffic. The quic folks say that they cannot do
> that since 10 year old cpe only passes udp and tcp, then they rant about
> ossified stacks and how we need to put everything on udp to make progess ...
> Seems like they are just choosing to ossify on udp ...  And udp is already
> considered trash (reflection attacks) ...So we agree to disagree, i guess
>
Isn't any other protocol besides TCP also considered trash right now?

UDP based transport protocols would use well know port numbers. A
firewall can allow UDP port X that carries a properly congestion
controlled protocols not subject to reflection attacks, but disallow
other UDP ports.

Tom

---

From: Brian Trammell <[email-masked]>
Date: Mon, 23 May 2016 17:42:57 +0200

hi Michael,

> On 23 May 2016, at 16:56, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
> 

Thanks for the suggestion; will do.

Thanks, cheers,

Brian

---

From: Ca By <[email-masked]>
Date: Mon, 23 May 2016 08:51:59 -0700

On Monday, May 23, 2016, Tom Herbert <[email-masked]> wrote:

> On Sun, May 22, 2016 at 1:06 PM, Ca By <[email-masked] <javascript:;>>
> wrote:
> >
> >
> > On Sunday, May 22, 2016, Michael Welzl <[email-masked]
> <javascript:;>> wrote:
> >>
> >> Hi,
> >>
> UDP
> >> On 22. mai 2016, at 05.03, Jana Iyengar <[email-masked] <javascript:;>>
> wrote:
> >>
> significant
> stop
> only
> distiguishing
My network only "manages" udp.  Ymmv.

firewall can allow UDP port X that carries a

A "firewall" is a enterprise solution that does not scale for large
national internet providers in the usa

Yes, the bulk of the trash is less than 20 source ports (chargen, ntp,
snmp, ntp, dns, ....). But we also get very large bot swarms doing straight
packet attacks with udp.  Even a novice like me can write to udp sockets in
python on any port and stuff data through it.

> properly congestion

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 May 2016 09:05:25 -0700

On 5/21/2016 9:21 PM, Phillip Hallam-Baker wrote:
>
>
> On Thu, May 19, 2016 at 4:21 PM, Toerless Eckert <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
> There is nothing in TLS to stop it being attacked. All TLS can do is
> to prevent certain attacks from succeeding and it is only designed to
> prevent Confidentiality or Integrity attacks.
>
> TLS isn't at all good at stopping denial of service attacks. When an
> attack occurs, there isn't much that can be done apart from closing
> the socket and trying again. 
>
> If you want to add in robustness, you need to be able to detect which
> of your TCP packets were mangled and that really isn't possible in
> user space.

You can detect anything in user space that the OS allows access to,
including link, network, and transport errors.

If you delegate demuxing to the OS and don't have an override, then
*that* is what stands in your way, not any property of the Internet
stack or its protocols.

Joe