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

From: Mirja Kühlewind <[email-masked]>
Date: Sat, 8 Aug 2015 11:16:57 +0200

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

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

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

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.

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

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 00:28:19 -0700

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

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

> ???> No

Ack.

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

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.

> ???> Yes, if supported by the overlying protocol

Yes.

> ??? 

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.

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

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

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

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

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

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

> ???> Yes (faster state tear-down), but the overlying protocol must be resilient to it not being sent, not being received.???

Sure.

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

> ???> No, e.g. start packet

Right.

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

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

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

> -> 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 p…

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.

> -> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Roland Bless <[email-masked]>
Date: Tue, 11 Aug 2015 09:23:01 +0200

Hi,

Am 08.08.2015 um 11:16 schrieb Mirja Kühlewind:
> 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.

But potentially hitting different middleboxes along asymmetric paths,
i.e., the ACK is routed back along a different path than the initial
packet. A 2WHS is also vulnerable against state exhaustion attacks.

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

>From a security perspective, a 3WHS with a DoS protection cookie would
be the most reasonable option.

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

See above. On the one hand an ACK is maybe not enough to set up state. A
SYN Flood would otherwise also set up state in the SPUD box. On the
other hand, SPUD boxes must be prepared to react to flows/tubes that
neither have Start, ACK, or Close due to temporary re-routing events.

> 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 don't think that it is needed, see previous point.

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

I don't understand this, is that different from a close?

Regards,
 Roland

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 11 Aug 2015 11:38:22 +0200

Hi Roland,

see below.

> Am 11.08.2015 um 09:23 schrieb Roland Bless <[email-masked]>:
> 
> Hi,
> 

No, it’s close. The question is do we need an explicate signal for close (and maybe even close/ack) or is it sufficient to just let the state time out because middleboxes anyway need a timer as they can never rely on seeing a close.

Mirja

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 11 Aug 2015 15:07:54 +0200

Hi Mirja,

Am 11.08.2015 um 11:38 schrieb Mirja Kühlewind:
>>> 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.​
>> 
> No, it’s close. The question is do we need an explicate signal for
> close (and maybe even close/ack) or is it sufficient to just let the
> state time out because middleboxes anyway need a timer as they can
> never rely on seeing a close.

SPUD doesn't make much sense without a close. I understood that
one advantage of SPUD would be the explicit state teardown indication
without waiting for a (non-uniform) timeout. However, SPUD doesn't
make the timer obsolete.

Regards,
 Roland

---

From: Tom Herbert <[email-masked]>
Date: Tue, 11 Aug 2015 09:55:57 -0700

Hi Mirja,

A few comments in line...

On Sat, Aug 8, 2015 at 2:16 AM, Mirja Kühlewind
<[email-masked]> wrote:
> —> 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?)
>
> —> 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.
>
> —> 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.
>
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.

> -> 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…
Authenticating the header should be an option in cases where we want
to prevent any packet-mangling.

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

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

> —> Yes (faster state tear-down), but the overlying protocol must be resilient to it not being sent, not being received.
>
>
> -> Not clear; maybe not and packets on the five-tuple that don't have a tube identifier aren't assigned any tube.
>
> -> 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.
>
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).

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 11 Aug 2015 19:37:53 +0200

Hi Tom,

> be able to secure the SPUD bits as needed regardless of overlay or

That means, you would like to provide key exchange mechanisms in SPUD?

> to prevent any packet-mangling.

If you already have a trust relationship which the other end, that’s easy but that only helps for information provided from end-points. However you might not be able to provide authenticated information from a middlebox. And sometimes it might even been on purpose that one middlebox should be able to overwrite the information form another middlebox, e.g. if the shortest time-out on the path is requested.

> and extra memory that needs to be allocated for each flow (possibly

For time-outs I rather would like to see a mechanism where this information is reflected over the receiver because what you are actually looking for it not the time-out of your local firewall (you might already know that over a different channel) but the minimum time-out of all middleboxes on the path. Otherwise if you just request the time-out, every (Spud-aware) middlebox on the path would need to send you a separate reply. Of course the middlebox with the smallest time-out might not be spud-aware but that’s different problem.

Mirja

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 11 Aug 2015 10:59:59 -0700

A quick thought on explicit close, FWIW. Sending an explicit close packet
often involves a client or a server sending a packet, usually after some
amount of quiescence. When on a cellular device, this requires the device
to pull up the radio and spend energy on sending/receiving a packet that
basically contains little to no information. This design is generally being
eschewed in favor of a connection timeout at the ends, especially when the
endpoints can negotiate on a timeout period.

One way for a middlebox to learn about connection close would be to have an
explicit negotiation in SPUD that is visible to the network... but I don't
think that relying on connection close packets for signaling a connection's
termination is going to be adequate.

On Tue, Aug 11, 2015 at 2:38 AM, Mirja Kühlewind <
[email-masked]> wrote:

> No, it’s close. The question is do we need an explicate signal for close
> (and maybe even close/ack) or is it sufficient to just let the state time
> out because middleboxes anyway need a timer as they can never rely on
> seeing a close.
>
> Mirja
>
> >
> > Regards,
> > Roland
> >

---

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Aug 2015 13:28:54 -0700

> endpoints can negotiate on a timeout period.

​So, the problem with this approach is that the negotiation of the timeout
period doesn't involve just the endpoints; it involves the network elements
that are maintain state and allocations.  To keep them at their task, lots
of systems send heartbeat packets at regular intervals when no other
traffic is present.  Those also wake the radio and consume battery.​

So, whether the trade-off with an explicit close is worth may depend on the
traffic pattern of the application and the state being held in the
network.  In some cases, the close message would go with the last packet,
and so be "free" from a radio perspective.   I'd  guess that it would
generally be worth it in any system containing a SPUD-compliant NAT or STUN
server, but there are cases (DNS over SPUD) where even then it might not be
a win for the client.

But the client itself is the best judge of this, which is why I favor
including the functionality, but making it optional.  All the systems have
to be redundant to that packet being lost anyway.

> One way for a middlebox to learn about connection close would be to have
> an explicit negotiation in SPUD that is visible to the network... but I
> don't think that relying on connection close packets for signaling a
> connection's termination is going to be adequate.
>
>
​From a coding perspective, that seems to be really painful.  When some
Harry Potter app uses 17 second timeouts in homage to the Galleon, it's
going to need custom timers.

Ted

---

From: Tom Herbert <[email-masked]>
Date: Tue, 11 Aug 2015 13:36:55 -0700

> That means, you would like to provide key exchange mechanisms in SPUD?
The end points do need a key exchange, if they are already doing TLS
for encrypting the payload maybe that can be leveraged. IIRC QUIC
headers are authenticated but cleartext, and payload is always
encrypted, so they may have already solved this...

> If you already have a trust relationship which the other end, that’s easy but that only helps for information provided from end-points. However you might not be able to provide authenticated inform…
Right, but there's also fields in the headers which should be declared
immutable in the path-- which likely includes the session ID and cmd.
We should be able to get integrity and end to end authentication of
those. If mutable fields are also present, then some options are:

- Define a mechanism to indicate those fields are excluded from
authentication and integrity check
- Place mutable fields outside of the headers. For instance,
middleboxes can respond directly to the source instead of modifying
packets inflight and relying on reflection
- Middlebox encapsulates in another header so it can set any fields as
desired, but receiver will need to untangle that

> For time-outs I rather would like to see a mechanism where this information is reflected over the receiver because what you are actually looking for it not the time-out of your local firewall (you…
How big of problem is this likely to be? How many middleboxes do you
foresee in paths that will be maintaining flow state with timeouts?

Also, see my comment about keep-alivess, I'm hoping we can get a
better solution which eliminates the need for knowing timeouts and
sending keep-alives in the first place!

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 14:01:45 -0700

> No, it’s close. The question is do we need an explicate signal for close (and maybe even close/ack) or is it sufficient to just let the state time out because middleboxes anyway need a timer as the…

You might want to look at the Delta-T protocol if you're willing to let
time manage state this way.

Joe