[Spud] SPUD Scope?

[Szilveszter Nadas <[e-mail]>]

Hi all,

I browsed through the mails since last ietf the other day, and I have seen quite big variety in the scope of SPUD in the different mails.

The rage looked like this to me on a high level:
a) only start/stop, hide everything in DTLS
b) Some declarative, safe to ignore, trust but verify markings are OK, but it shall be minimized.
c) "common, middlebox friendly connection/packet signaling layer", extensibility, any communication and behavior is OK as long as it is explicit.

I am personally closest to group c), still I understand that this is far from the average view and that it would be pretty hard to reach a consensus regarding this. I think that it is very hard to "replace DPI" with easy to verify info (assuming encrypted payload) and with declarations with very light consequences. One can argue that middleboxes shall never be able to have that detailed knowledge ever again, still if we embrace the role of middleboxes we probably need more than a) or b).

I completely agree that all kind of signaling shall be safe to ignore and in a normal case ignoring a signal should not result in denial of the service but rather result in some kind of default behavior.  I also think that signaling shall not result on delayed start of the connection (usually it is enough to change handling later on, no real reason to delay the start)

However I do not really see problems with one of the end-point accepting an offer of a middlebox and communicating with the middlebox with a proprietary vocabulary. SPUD is clearly a good way to offer these improvements to end-hosts. Whether the follow up communication is using SPUD as a sub-transport for the signaling conversation or not is a question. Also this communication (when accepted) might have consequences, e.g. some change in charging. Obviously some kind of security solution is needed to authenticate the middlebox and the end-point, which is far from trivial.

At the same time even with the above assumptions, it is not quite clear how something like this can happen.

I really like the philosophy of the "Tussle in Cyberspace" article. Things like "Do not design so as to dictate the outcome". Also the part about "Interfaces of tussle" and their "properties": "Visible exchange of value", "Exposure of cost of choice", "Visibility (or not) of choices made" and "Tools to resolve and isolate faults and failures". I think that if we want to cooperate with middleboxes these are very good guiding principles. I also think that many of us are actually biased towards trying to dictate the outcome. If we provide possibility to achieve a functionality in an explicit way is not it better than making network vendors to invent their own not so transparent solutions for the same?

Assuming something like c) is not happening in SPUD where do you think it could/should happen?

Cheers,
Sz.