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

[Mirja Kühlewind <[e-mail]>]

Two comments inline.

> Am 23.05.2016 um 17:50 schrieb Toerless Eckert <[e-mail]>:
> 
> On Mon, May 23, 2016 at 05:34:24PM +0200, Brian Trammell wrote:
>>> 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.
>> 
>> 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.
> 
> 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.

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…

> 
>>> 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.
>> 
>> ...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.
> 
> 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.
> 
>>> 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.
>> 
>> 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.
> 
> Sure, thats why i said to encrypt it, so only your orgs firewalls can decrypt it.
> 
>>> And in such an environment it certainly
>>> is necessary to do the PLUS signaling from the OS level etc. pp.
>> 
>> 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".
> 
> 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.

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


> 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
>> 
>> Cheers,
>> 
>> Brian
>> 
>>> Cheer
>>>   Toerless
>>> 
>>>> Cheers,
>>>> 
>>>> Brian
>>>> 
>>>>> 
>>>>> 
>>>>>>> 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.
>>>>> 
>>>>> _______________________________________________
>>>>> Spud mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/spud
>>>> 
>>> 
>>> 
>>> 
>>>> _______________________________________________
>>>> Spud mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/spud
>>> 
>>> 
>>> --
>>> ---
>>> Toerless Eckert, [e-mail]
>>> 
>>> _______________________________________________
>>> Spud mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spud
>> 
> 
> 
> 
> -- 
> ---
> Toerless Eckert, [e-mail]