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

Hi Roland,

see below.

> Am 11.08.2015 um 09:23 schrieb Roland Bless <roland.bless@kit.edu>du>:
> 
> 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?

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
> 
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud