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

[Jana Iyengar <[e-mail]>]

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 <
[e-mail]> wrote:

> Hi Roland,
>
> see below.
>
> > Am 11.08.2015 um 09:23 schrieb Roland Bless <[e-mail]>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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spud
>
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud
>