Re: [Spud] Possible WG-forming follow-on to SPUD BoF

[Tom Herbert <[e-mail]>]

On Tue, May 31, 2016 at 1:29 AM, Brian Trammell <[e-mail]> wrote:
> hi Szilveszter,
>
> Thanks for the review and the questions; answers to a few of these inline below...
>
>> On 25 May 2016, at 18:27, Szilveszter Nadas <[e-mail]> wrote:
>>
>> Hi,
>>
>> I read the charter and most of the discussion on the list and I am wondering about a few questions.
>>
>> -scope of PLUS declarations. There was quite an amount of discussion 1) about trusted domain firewalls. Also 2) about all middleboxes in the e2e path. So 1) or 2) or both?
>
> The design implied by the current requirements is about signaling to all middleboxes on the end to end path. It might be interesting to be able to target information at a specific middlebox on path (or a middlebox-role) if you have an existing cryptographic relationship with it (which I think is a superset of your case 1) -- in this case, the content would be accessible to the targeted middlebox and the remote endpoint, and integrity protected for verification by both the targeted middlebox and the endpoint.
>
> We've thought about this use case for a while. The crypto bits are not easy to get right IMO, but then, I'm not a crypto guy. I'll note that this is something that can probably run on top of a generic signaling framework (where you get end-to-end integrity protection of everything, plus possibly end-to-middle confidentiality and authenticity of certain information elements using a different crypto context), so might be a good candidate for an extension that runs over PLUS.
>
> One of the discussions I'd like to see happen at the BoF (...should it be approved...) is whether this use case is in scope.
>
>> -"allow applications and transport protocols to explicitly provide limited information in cleartext to devices on path" vs. "sending endpoint", "receiving endpoints". The terminology is not 100% clear to me. What is the difference between "applications and transport protocols" and "endpoints" here?
>
> Some information to be exposed (e.g. expected constant data rate) might come from the application layer, and some information (e.g. transport reordering tolerance, measurement headers that look something like those in the PDM DO header the IPPM WG is currently working on) comes from the transport layer. In this case, the transport should always allow the application to know what is being sent, and to have control over whether it is sent, but may keep the application from changing the values exposed. This is up to the transport/app API.
>
>> -What do we gain by limited vocabulary ("limited information")? Is not any set of declarations too much for some users/countries/whatever and too few for others? Is not it forcing the WG participant's ethics by protocol design?
>
> A few things; mostly, we gain some control at the process level against subversion of endpoint control.
>
>> -There was a comment "PLUS header would make this behavior visible to *everyone* on the network. That alone is IMO a reason it wouldn't be deployed in this way". I agree with this, PLUS would/shall make every non-e2e conversation as explicit as possible. Is that protection enough? Is it possible to make this explicitness as transparent as possible? Is it necessary to have further protection as e.g. limited vocabulary?
>
> WRT "limited vocabulary", the thing it's hard to defend against here is someone defining their own declaration, the meaning of which is secret and the name obfuscated. If I see that an app is radiating something to the path over PLUS, but I can't understand it, well, I do know that app may be up to no good, but I don't know what *kind* of no good. It's not clear to me whether that's enough to qualify as "transparent".
>
>> -PLUS as supercookie layer.
>
> First of all, in draft-trammell-spud-req, which assumes a tube ID for packet grouping and protocol binding as well as proof of on-path-ness for direct feedback, the tube ID is always scoped to 5-tuple and must be random. It's explicitly not a supercookie, and I'd assume that this requirement holds for PLUS as well. So the built-in signaling that makes PLUS work wouldn't be usable as a supercookie here. The size of the tube ID should be selected to be sparse enough that possession of a tube ID is a probable indication of on-path-ness, but not so sparse that it makes sense to ignore the MUST on randomness, and try to stuff a "Internet-wide flow ID" into it.
>
>> I think it is pretty easy to insert supercookies to TCP/UDP/QUIC flows already today (see e.g. https://rd.orbit.com/rd/free/RD623051.pdf ). Of course the receiving end might be able to detect some irregularities. One can also imagine a supercookie removal box, but it is questionable, whether such a general box can be created (unless it acts in a higher and integrity protected layer like TP or APP).
>
> I'll note that if there was a "app-to-path-cleartext-supercookie" information element in PLUS (which I don't think would be a useful one to have, nor would it meet any goal we have), it would *not* be removable by a middlebox, since it would be integrity protected end-to-end. A supercookie mitigation box in PLUS would have to notice the existence of the supercookie, drop the packet, and send back a direct feedback message that said "I'm sorry, I don't permit supercookies, please reset the superstrate transport session and try again without the supercookie."
>
>> -trust in applications. Who decides what can be communicated over PLUS? Is it possible to have PlusBlock (~AdBlock-like function for declarations)? Is that an OS function or a browser function? Shall the device owner be able decide to clear or alter declarations? Shall the OS be able to add/remove/police/alter/sign declarations? Why (for all questions:) )?
>
> All good questions, all largely to be handled within the endpoint. End-user alteration of the content would probably be an advanced administrative/configuration function, but I would suspect there would be a checkbox on a privacy preferences tab somewhere for disabling PLUS signaling (aside from transport layer semantics) completely.
>
>> -The charter still says "goal is to enable the deployment of new, encrypted transport protocols". I think that whether to encrypt or not is the decision of the TP, and while I agree that encryption really helps there by avoiding further ossification, I think it shall not be the scope/decision of PLUS.
>
> Yes, but: in order for integrity protection of declared information to work, PLUS needs a mechanism to share a secret between endpoints, so it either needs its own keying or it needs to borrow a key generated from the superstrate's session key. And if we are to meet the requirement to prevent future ossification of the transport layer (or rather, to re-ossify around the path layer provided by PLUS), then we need to encrypt the transport layer headers. So IMO this is very much in scope.
>
>> -From list "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." - Why is it a problem if they work better?
>
> Unbreaking firewalls in the face of transport encryption is a necessary first step. What you do after that is a separate question.
>
Brian,

Like Szilveszter mentions the choice to encrypt must be up to the
application or TP. Applications should not have to ask for permission
from the network to use encryption, nor can deployment of encryption
be gated on middleboxes being updated with PLUS (it's unrealistic to
think we are going to wait N years for PLUS deployment in middleboxes
before starting to encrypt transport headers).

As for "Unbreaking firewalls in the face of transport encryption is a
necessary first step" can you elaborate exactly how firewalls are
broken in this regard? I don't see a good description of this problem
in RFC7663 and your UDP data as well as the fact that QUIC is
currently being deployed don't seem to be illustrating a widespread
reachability issue using UDP in the Internet.

Thanks,
Tom

> Cheers,
>
> Brian
>
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud
>