Re: [Spud] Questions based on draft-trammell-spud-req-00

[Tom Herbert <[e-mail]>]

Hi Mirja,

A few comments in line...

On Sat, Aug 8, 2015 at 2:16 AM, Mirja Kühlewind
<[e-mail]> wrote:
> Hi all,
>
> based on the discussion in section of draft-trammell-spud-req-00, we (the current group of authors) have phrased some questions we would like get further feedback from you!
>
> For some/most questions we already provided an answer which reflects part of the discussions we had on this so far. However, none of the provided answers are final and in a couple of cases we also don’t have consensus between the small group of us authors. To further proceed here we would like to get more input from the broader community to hopefully find a way to evolve!
>
> Please go ahead and provide feedback to some or all of the questions! If you want to further discuss only one aspect of the questions below, please think about changing the subject of your mail, such that we have a chance to separate different discussions.
>
> Thanks and have a nice weekend!
> Mirja
>
>
> ———————————————
> 1) Tradeoffs in tube identifiers
> ----
>
> a) What the scope of a tube? Is the tube scoped to the 5-tuple, 4-tuple, or even 3-tuple or can even two different flows have the same tube ID (privacy vs. mobility)?
> —> 5-tuple, with unidirectional the default. Note that this means the tube-id itself cannot be used to do mobility. A return flow may use the same tube-id, if it wants to signal that it is part of the same exchange, but it is not required to do so. (5-tuple + tube id = 6-tuple; maybe 7-tuples for per-path-element communication as well?)
>
> b) Does SPUD need to send a start message for each tube (independent of the semantics or the overlying protocol)?
> —> Yes, e.g. if you have multiple MPTCP subflows each has its own tube ID. However, maybe this is should only be aSHOULD.  It's a useful message when you expect it to be used to start initiating state in middleboxes, but there may be conditions where the treatment requested for the flow means that this is not required.
>
> c) Can one packet have more than one tube ID?
> —> No
>
>
> 2) Property binding
> ---
>
> a) Should it be possible to bind properties (only) to a tube or (also) to single packets?
> —> Only to a tube.  If you need to have a packet that should have different treatment, it needs a new tube-id. Therefore start new tube should be cheap.
>
> b) Can properties bound to a tube be changed later on during the connection?
> -> Probably not. Also start a new tube in this case as new tube should be cheap.
>
>
> 3) Tradeoffs in integrity protection
> ---
> a) Should SPUD provide support to use the authentication mechanism of the overlying transport for SPUD information provided by an endpoint to check the authenticity and integrity when the information arrive at the other endpoint?
> —> Yes, if supported by the overlying protocol
>
Yes, but this seems independent of the overlying protocol. We should
be able to secure the SPUD bits as needed regardless of overlay or
underlay.

> b) How can packet-mangling (middleboxes changing accidental or intentionally information provided by others, both middblebox and endpoints) by on-path ndes be detected?
> -> Lying can potentially be detected if information can be verify over a different mechanism. However it might not be possible to detect who provided these wrong information. Off-path devices would need to know the tube id to provide wrong information which may be unlikely.
>
Authenticating the header should be an option in cases where we want
to prevent any packet-mangling.

> c) If a trust relationship already exists that would allow to authenticate information provided by a middlebox, does SPUD need to provided further support for this case?
> -> Yes? (Similar as question a)
>
> d) Is there a value in SPUD having its own (encrypted) end-2-end channel?
> -> Not fully clear yet, maybe not; Encrypted end-2-end infos can either be handled by the overlying (encrypted) protocol, or an encryption boundery  within SPUD to provided end-2-end information we can be commonly used by multiple protocols. However (encrypted) end-2-end information might be an own overlying protocol (maybe even another shim layer) and not SPUD itself.
>
>
> 4) Return routability and feedback
> —-
>
> a) 2WHS vs. 3WHS?
> —> SPUD should/must (?) provide a 2WHS, that means an ACK in response to the initial packet should be generated by SPUD even if the overlying protocol does not support this semantic. Note this mean the ACK may only have a SPUD header but no overlying protocol data.  This would make all SPUD flows/tubes bidirectional. Further SPUD should also provided the semantics for an 3WHS but may only send a third packet if the overlying protocol implements it or there is another reason for the application to explicitly request a SPUD-only 3WHS.
>
I believe 3WHS is essential to deal with "syn" attacks and this
includes synchronizing on unique random values generated by both
endpoints. 2WHS may be performed if a receiver has other means to
authenticate the sender, or the communication is something like
request/response.

>
> b) Does the semantics of the SPUD protocol need to provide an explicit start signal as well as start/ack signal?
> -> Yes, start is needed to distinguish start and middle of a tube; ack is needed to finally set up state. However, not clear yet if all SPUD tubes MUST send a start signal or only SHOULD. If a start was received, however, a ACK must be sent…?
>
> c) Should it be possible to send multiple START signal on the same tube (e.g to re-initiate state)?
> -> Not clear if this is really needed
>
I think one goal of SPUD should be to eliminate the motivation for
sending keep-alives. Hosts should not be rewarded for sending
otherwise useless packets into the network, and these are known to be
bad for battery consumption on mobile devices. To accomplish this, it
seems like the states for eviction from a middlebox state could be
chosen at random. An evicted state can be reconstructed with new
packets seen in both directions that indicate the tube is still open
at both endpoints.

> c) Is a stop flag needed/useful?
> —> Yes (faster state tear-down), but the overlying protocol must be resilient to it not being sent, not being received.
>
>
> 5) In-band, out-of-band, piggybacked, and interleaved signaling
> —-
>
> a) Do all packets of a flow (where one packet already has a spud header) need to have a SPUD header or could there be single packets in an spud-enabled flow that don’t have one?
> -> Not clear; maybe not and packets on the five-tuple that don't have a tube identifier aren't assigned any tube.
>
> b) Do all SPUD packets need to have overlying protocol data?
> —> No, e.g. start packet
>
> c) Do all SPUD information have to fit into one packet?
> —> probably yes (and other should be out-of-band using an overlying transport) but not clear yet
>
> d) Can a middlebox generate SPUD packets?
> -> not clear yet, alternative is that the endpoint provides a place-holder that can be filled by middlebox (and reflected by the receiving endpoint) which implies all middlebox information need to be requested by the sending endpoint; probably doesn’t work for e.g. error messages and therefore the system must allow them to generate them, but we also have to recognize that they may be consumed by the path before reaching their intended destination. Further it makes it difficult to do async signaling of changes.
>
> We at least need the ability for path elements to send pdec's when they've got the capability.
>
> e) Can a middlebox request application declaration information from an endpoint and/or provide unrequested path declaration information?
> -> Not clear yet, to avoid amplification attacks maybe apply the packet conservation principle here, e.g. a middlebox can generate a packet/an error message if it drops a packet..?
>
> f) Should middlebox information be reflected over the receiver or can they also be send directly to the sender (and might take a different route)?
> -> Maybe there should be a possibility to sent directly to the sender; for unidirectional flows the receiver may not have a bearer flow to carry the message back and thus would generate spud-only packets which maybe quite a bit overhead. However reflection over the receiver should be preferred.
>
Middleboxes often have a locality associated with them, e.g. home
router, enterprise firewall. In such cases, it seems like returning
information directly is a better use of resources and limits the
exposure of the data. For example, if your firewall wants to provide
the client with it's connection timeout, it can send that back
directly rather than forwarding this to some server halfway around the
world and expecting the them to properly reflect the information when
they should not care about this. To the server this is just extra work
and extra memory that needs to be allocated for each flow (possibly
millions of them).

> g) Must SPUD information be provided reliably or are those information always unreliable?
> -> hopefully unreliable is enough as we want an incrementally deployable solution
>
>
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud