Re: [Spud] Return routability and feedback (was: Questions based on draft-trammell-spud-req-00)

[Roland Bless <[e-mail]>]

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