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

On Sat, Aug 08, 2015 at 11:16:57AM +0200, Mirja Kühlewind wrote:
> 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.
> 
> ?????????????????????????????????????????????
> 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?)

My preference for Tube-ID is to identify a single bidirectional multipath or
mobile transport connection consisting of one or more 5-tuple flows between
two endpoints.

I can't see how we could have network elements understand multipath/mobile
connections without such a common identification. Sure, this means SPUD would
need to define a common multipath/mobility layer, but thats a good thng.

And this can be done incrementally. SPUD can start first defining just
single 5-tuple mechanisms, as long as w don't block the way to make it support
multipath/mobility.

And transport protocols like MP-TCP that want to continue work unchanged
can always choose different Tube-IDs for their different 5-tuples.  Likely
at future loss of best interaction with the network though.

Unidirectional, you have to specify what you really want:

a) SPUD signaling is built such that a network device only seeing a single
direction of the flow (asymmetric routing as common in the internet)
still gets all SPUD signaling information.

For example, each endpoint
could just reflect the other sides last SPUD message. I think this is
useful but difficult, and current midpoints don't expect to be able to
work under these conditions anyhow. SO it might be a useful value add
to make midpoints support SPUD..

b) SPUD signaling is bidirectional but allows to identify separate
information for both direction. 

I definitely think this is useful, but i don't see why both directions
would need separate Tube-IDs.

c) SPUD signaling is unidirectional only for a unidirectional only traff flow.

This makes things quite difficult, especially anything security. I
would reserve thinking about purely unidirectional signaling for multicast
if you ever want to support that - because those flows are intrinsically
unidirectional. In Unicast i wouldn't bother.

> 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.

Well, with my preference there needs to be a start message for every 5-tuple 
of a Tube-ID.

> c) Can one packet have more than one tube ID?
> ???> No

Ack.

> 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.

The ICE/RTCweb experience is quite clear that we need to minimize the
in-network flow-state requirements, so opening up multiple tubes
for a potential large number of sub-flows is not an option.

Network devices have per-flow and per-packet operations. SPUD must
allow to exploit both of those capabilities.

If SPUD continues to be a layer with per-packet overhead (header), it would
be a big waste of such a layer to not have per-packet properties but only 
per-flow properties. In that case SPUD should not have per-packet header,
but just some additional packets carrying flow properties, eg: in the way
some of our drafts proposed to expand STUN/ICE signalling.

> 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.

> 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.
> ??? 

SPUD SHOULD/MUST have a way for middleboxes to officially insert/modify
information as a way of explicit communication from network to endpoint.
Together with 3a) this means something like:

There is immutable and mutable SPUD information/signaling elements.
middleboxes are only allowed to touch/create mutable elements. 
Higher layer transport authenticity/integrity checks will only
include the immutable SPUD information. Trust relationship between
the middlebox and the endpoints (if necessary) is done through
different ways.

> 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)

Yes would be lovely, but i can't come up with a good example of this
right now, and i wouldn't want to burden SPUD with stuff i have no
idea on how to do ;-)

> 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.

Rule of thumb is not to re-invent security solutions
unnecessary. To me this means i'd first look in how to make
SPUD work with dTLS, and it seems most easy to use SPUD as
an underlay and figure out how to include the immutable pieces
of SPUD into the dTLS security layer and the mutable not.

Once we have such a solution i wonder what else we'd be missing.
(beside middlebox<->endpoint trust/authentication of course,
 but thats a different matter).

> 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 think we want 3WHS for two reasons:

a) Allow upper layer protocols that use 3WHS to include their 3WHS metadata into
   SPUD 3WHS to make SPUD as RTT efficient as any protocols it carries - while
   still allowing middleboxes to just have to deal with a single 3WHS of SPUD.

b) Leverage 3WHS to do happy eyeballs / (multipath) selection correctly:
   You start off exploring potentially in parallel multiple 5-tuples
   with SYN/SYN-ACK and then the initiator sends the ACK only for
   those 5-tuples(s) it wants to use. 

> 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????

I'd make it a MUST because it looks easier. I can't see how SHOULD would
make it easier. 

> 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

a) Start per (Tube-ID,5-tuple). 

b) re-start:

rerouting makes a tube go across a firewall middlebox that has no tube-id state.
It should be allowed to modify drop packets and send SPUD-ICMP "re-start". This
would trigger re-start process (eg: 3WHS repeat).

> 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.???

Sure.

> 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.???

See above. If you don't want to support per-packet attributes, then you can
go with a model that we started with STUN -SPUD is just signaling
packets identifies by a signature in the packet and data packets of
the same 5 tuple(s) are not encumbered. I did vote for per-packet signaling
capability.

> b) Do all SPUD packets need to have overlying protocol data?
> ???> No, e.g. start packet

Right.

> 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

per-packet SPUD header should be small, eg<= 64 byte.
SPUD signaling only packets can be up to 1280. total amount of
per-tube signaling information could exceed 1280 by being split
up across multiple SPUD signaling only packets, but not sure if
thats needed any time soon.

> 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.

SPUD-ICMP: Do what we should (according to IETF architecture) do
with ICMP via SPUD-ICMP messages so that SPUD stacks/apps can rely
on their non-privileged UDP (SPUD) sockets to send/receive those
SPUD-ICMP.

I'd like to say: by default, don't come up with SPUD-ICMP messages/message-exchange
that would not be permitted as ICMP messages.  But the current thinking of
what ICMP should be permitted to do may be too stringent. Eg: wonder if
in my above SPUD-ICMP "re-start" message would be permitted to be
sent as ICMP not to the originator of the filtered packet but the recipient...

> We at least need the ability for path elements to send pdec's when they've got the capability.

'pdec' ?

> 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..?

Lets be clear about responsibilties here:

Middleboxes such as HTTP proxies break packet conservation 
all the time when operating at transport flow level
(eg: additional HTTP/HTML headers etc..). Nobody blames TCP.

SPUD will not force middleboxes to do any amplification. If a
middlebox chooses to do so, its in its realm of responsiblity to protect
itself and the good endpoints against those attacks.

So yes, middleboxes can request additional information, but
SPUD does not fore them to. And we can reuse a bunch of the ideas
we'd put into prior protocol work to minimize the need to do so.

> 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.

Not sure i mean what "reflection to receiver" means.

IMHO: middlebox adds information as mutable data to existing SPUD
packet, eg: 3WHS SYN. receiver then reflects thast information back
to sender. Flow can perfectly be unidirectional, SPUD does not care,
SPUD expects bidirectional signaling.

> g) Must SPUD information be provided reliably or are those information always unreliable?
> -> hopefully unreliable is enough as we want an incrementally deployable solution

Is TCP 3WHS reliable ? Same thing. Aka: as long as we have something like
a middlebox "re-start" to re-request information (both from middleboxes
and endpoints), i am sure we can come up with the most lightweight soft-state
approach.

Cheers
    Toerless
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud