Subject: [Spud] What middleboxes are allowed to know (Re: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF)

From: Toerless Eckert <[email-masked]>
Date: Mon, 23 May 2016 06:43:48 -0700

Mirja: Your answer below "i don't want the middleboxes to require anything here"
is letting me totally confused. If PLUS wants to define how talk with the
middlebox (or however you want to call it "pass info to it, get info from it"),
then it is clear that the resut of this interaction is that you will not
achieve desirable outcomes if you do not send specific info to the middlebox

Please give me an example how you think PLUS will help firewall middleboxes
to decide whether or not to less some traffic flow pass. Lets assume that
same firewall today is using TCP port number policies and/or DPI. What
in your opinion should the firewall do.

> > What i really want to see is this:
> > 
> > - Allow the application to learn from the network devices what information
> >  it must present in the clear to have its traffic be passed through
> >  and/or receive additional treatment by the network.
> > 
> > Aka: "Security guard: Sure, you can go through this door if you show me your <credential> else not"
> > 
> > Then the app can decide if it wants to show <credential>. Otherwise the
> > apps have to operate like corporate drones, carrying around their corp-ID
> > in the open all the time hoping that thats the right credential.
> > 
> > Or to rephrase: if we do not even attempt to overcome TCP port numbers as
> > credentials then we're lame and will not be successful.
> 
> Okay??? I first of all have to simply say no here. I don???t want the middleboxes to require anything here, because why would a middlebox not just say ???either you show me all you content in plain or I don???t transport you data???. I believe that???s something we all don???t want and building a mechanism that could lead to this, it the last thing I want. I know what you intention is here, but we have to be more than careful here and the way you???ve just phrased it, I can just disagree. However, I would propose to have this discussion in a separate thread.

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 23 May 2016 16:05:20 +0200

(about to take off; so very short answer)

The important word here is „require“. If the information is provided by the endpoint that's good; then use it (or not); but I don’t think there should a mechanism to enforce certain exposure. So everything is only declarative: here you get some info, use it or leave it. 

That’s similar to what we have today. You see a SYN if the endpoint decides to use TCP. The big different with PLUS is, it's transport-independent and therefore should make it much easier to deploy new transports in future (as soon as PLUS is deployed).

Mirja

> Am 23.05.2016 um 15:43 schrieb Toerless Eckert <[email-masked]>:
> 
> 
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 23 May 2016 07:10:52 -0700

Yeah, today the firewall requires that you use IP packets with protocol TCP and TCP port number 80 ;-))

And the app has no idea if it tries to establish a communication on eg: a different port.

I call this "require". So it does exist today.

And btw: the "take it or leave it" was rejected by reviewers when we had first rounds of
metadata signaling concepts in the IETF: Why send a lot of information thats not needed.
Unnecessary exposure.

So the question IMHO is how we can expose the firewall policies via PLUS, so the app knows what to send.

On Mon, May 23, 2016 at 04:05:20PM +0200, Mirja K?hlewind wrote:
> The important word here is ???require???. If the information is provided by the endpoint that's good; then use it (or not); but I don???t think there should a mechanism to enforce certain exposure. So everything is only declarative: here you get some info, use it or leave it. 
> 
> That???s similar to what we have today. You see a SYN if the endpoint decides to use TCP. The big different with PLUS is, it's transport-independent and therefore should make it much easier to deploy new transports in future (as soon as PLUS is deployed).
> 
> Mirja
> 
> 

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

---

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

hi Toerless,

> On 23 May 2016, at 15:43, Toerless Eckert <[email-masked]> wrote:
> 
> 

I don't think this is what we're trying to do with PLUS: declarative information about network traffic *properties* doesn't match well to policies described in terms of particular fields in headers. Certainly, port number based firewall rules would still work for applications over PLUS if PLUS itself doesn't use UDP port numbers to identify itself (which, IMO, it shouldn't -- I'm a big fan of magic numbers for this).

One could certainly ask for an "application ID" as an application to path key for firewall use, but among indistinguishable applications, this is simply an invitation to lie, so I'm not optimistic about its usefulness.

Cheers,

Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 23 May 2016 08:01:41 -0700

> One could certainly ask for an "application ID" as an application to path key for firewall use, but among indistinguishable applications, this is simply an invitation to lie, so I'm not optimistic…

It would really help to get an example of how PLUS would help to get encrypted traffic better
through firewall middleboxes. If that goal is out of the window for PLUS lets be very clear with
it, because i think this was the starting point of SPUD.

Simple unauthenticated app-ids are of course even less trustworthy than TCP ports, so they
won't help with firewalls. They would help to do better statistics of course. DPI is often done
together with netflow just for statistics gathering in enterprises, no firewalls involved.

For the firewalls, i think we need authenticated/secure app-id: AFAIK, every apple/google store binary
has some authenticity elements. It's not hard to image how every such app binary could have a cert from the store
or app-vendor, and the PLUS signaling is a proof of posession of the Cert, so that the middlebox
can authenticate it. Encrypt the proof of posession so that you're not exposing your app-id to anyone
by your own enterprise firewall, and IMHO we'd have something highly valuable. Yes, too large to fit into
a PLUS header alone, would require to be part of PLUS session setup packets.

Of course, such a model has a tail of more security implications like: firewall needs to be able to
vet that the endpoint signaling PLUS can be trusted, eg: is administered by the enterprise IT department,
so that apps started on it are assumed not to be hacked. And in such an environment it certainly
is necessary to do the PLUS signaling from the OS level etc. pp.

Cheer
    Toerless

---

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

> On 23 May 2016, at 17:01, Toerless Eckert <[email-masked]> wrote:
> 

Ah. Here the answer is simple: by encrypting the transport headers (necessary to deossify), you take away the SYN/SYNACK/FIN/RST for flow state management, and you can give it back in a transport-neutral way with PLUS. Together with UDP port number based rules, and you preserve the status quo while getting to deploy new transports. This functionality wasn't meant to make firewalls work better than they do today, it was meant to keep from breaking them once the transport headers are encrypted.

> together with netflow just for statistics gathering in enterprises, no firewalls involved.

...as long as you don't actually need those statistics for anything other than drawing pretty graphs on the wall in the NOC, this is fine. If you're a content network, you can pretty much trust yourself not to lie. Of course, your customers might not appreciate you tagging their encrypted traffic... so there are tradeoffs.

> so that apps started on it are assumed not to be hacked.

This cuts both ways, of course; as soon as you have an architecture in which you have an encrypted in-band side channel to a firewall on path, you also need to be *very, very* careful that the thing you have the encrypted in-band side channel to is actually the firewall you think you should (or, rather, according to organization policy, must) trust.

> And in such an environment it certainly

I'd note that is in direct conflict with the requirement to support application deployability of the PLUS shim, so... I don't see this use case coexisting well with a PLUS stack "under application control".

Cheers,

Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 23 May 2016 08:50:27 -0700

> Ah. Here the answer is simple: by encrypting the transport headers (necessary to deossify), you take away the SYN/SYNACK/FIN/RST for flow state management, and you can give it back in a transport-n…

Ok. That type of explnaation should really be in the charter text because that makes a
lot of things a lot clearer. And provides the best reason why we'd want to encrypt the
transport headers. because none of the other explanations for encrypting transport headrs
that we regurgitated in the last few days made sense to me.

> ...as long as you don't actually need those statistics for anything other than drawing pretty graphs on the wall in the NOC, this is fine. If you're a content network, you can pretty much trust you…

Yes, the problem is when you would leak this information to the internet because it will have
more information than you may want to signal further.

> This cuts both ways, of course; as soon as you have an architecture in which you have an encrypted in-band side channel to a firewall on path, you also need to be *very, very* careful that the thin…

Sure, thats why i said to encrypt it, so only your orgs firewalls can decrypt it.

> I'd note that is in direct conflict with the requirement to support application deployability of the PLUS shim, so... I don't see this use case coexisting well with a PLUS stack "under application…

Well, in my order of priorities, application level implementability is top. Its
just that if i read Mirjams responses you folks don't feel too happy about giving
it its rightfull place in the charter. And with opposition by folks like Joe that
we can't define protocol stacks to make our stuff more implementable, because
"it breaks the Internet", i have an idea why you don't want to, although i'll certainly
would like to continue trying to persuade folks of the necessity.

Wrt to "OS" - If you "apps" are running in a browser, then the "OS" would actually be
the browser. You just need some trust-anchor on the client-device that can guarantee
you that an application sending authnticated identity can not fake who it is.

Cheers
   Toerless

---

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

> On 23 May 2016, at 17:50, Toerless Eckert <[email-masked]> wrote:
> 

Will add this to the list of pending charter edits, thanks.

> it its rightfull place in the charter.

I wouldn't say that (indeed "mention userspace/application implementability explicitly" is issue #2 on the charter edits list now).

Cheers,

Brian

> And with opposition by folks like Joe that

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 24 May 2016 10:44:53 +0200

Two comments inline.

> Am 23.05.2016 um 17:50 schrieb Toerless Eckert <[email-masked]>:
> 

That’s our primary use case in draft-kuehlewind-spud-use-cases. We thought about spelling it out in the charter but didn’t to keep the charter short and at the point. This argument didn’t come up early in the discussion because we were assuming that people already have this simple first step in mind. Maybe we should add a short note in the charter…

> it its rightfull place in the charter.

Just want to say that I support this goal and I’m pretty sure that we can support it with what every we get to with PLUS. However, I guess I agree with Joe that this goal should not primarily drive our architecture and therefore it simply does not belong in the charter for me. It’s in the requirements doc, section 7.3 (draft-trammels-spud-req).

Mirja