Subject: [Spud] Connect and ACK Bits: Why?

From: Jacob Chappell <[email-masked]>
Date: Wed, 8 Jul 2015 13:32:24 -0400

Good afternoon, everyone.

There's been something bothering me since I started working with SPUD. Now
that I realize there's a mailing list, I figure why not ask here?

My question is, why is connect/ack part of the SPUD protocol? The purpose
of these commands does not seem clear from the draft. For one, SPUD runs
over UDP, so there's no guarantee the connect or ack will even make it to
the other side. Second, a previous message on this mailing list from the
archives indicates that you don't even have to wait for an ack to send a
data packet. This makes sense, because the ack may be lost in transit (or
maybe the original connect was lost in transit). But if this is the case,
what's the point in even having connect/ack as part of the protocol?

It seems like a possible alternative would be to just send data packets
spontaneously. The client can just be sure to generate a new tube ID when
sending to a new destination/port pair, and maintain that state.
Ultimately, you're going to have to use timers to expire state in case of
packet loss, so why not just use timers exclusively?

Jacob Chappell

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 13 Jul 2015 14:09:44 +0200

Hi Jacob,

I believe nobody answered this mail so far, so I’ll have a try. We’ve been discussing this a lot and also have not decided if we will need these flags or not. See further below.

> Am 08.07.2015 um 19:32 schrieb Jacob Chappell <[email-masked]>:
> 
> There's been something bothering me since I started working with SPUD. Now that I realize there's a mailing list, I figure why not ask here?
> 
> My question is, why is connect/ack part of the SPUD protocol? The purpose of these commands does not seem clear from the draft.

May I ask which draft you are referring here? The prototype draft really only is a prototype which mean one example protocol that might or might not address the needs. In the mean time there is also a requirement draft as well as a use case draft that are basically independent of the finally protocol design. The both also suggest to have a start flag as well as an ACK and maybe give slightly more discussion on this (but might also need more discussion). While it is less clear if we actually need a start bit, we definitely would like to require SPUD to basically send an ACK… see below.

> For one, SPUD runs over UDP, so there's no guarantee the connect or ack will even make it to the other side. Second, a previous message on this mailing list from the archives indicates that you don't even have to wait for an ack to send a data packet. This makes sense, because the ack may be lost in transit (or maybe the original connect was lost in transit). But if this is the case, what's the point in even having connect/ack as part of the protocol?

The idea is to assist network devices to set up state. E.g. a firewall might forward the connect/start packet to the receiver behind the firewall but is only willing to forward additional packets if the receiver send at least one packet to confirm that this is a wanted connection. That’s why we think an ACK is useful.

The connect/start is rather to distinguish if there actually is a newly starting flow or a middlebox only sees the middle of a flow because the flow was e.g. rerouted. In this case the middlebox might not be willing to sst up state but maybe sends an error message to the sender instead. As I said this is all still under discussion.

The question if you are going to resent a connect/start packet in SPUD because it or the corresponding ACK packet was lost depends on the higher layer protocol you are using over SPUD. SPUD (over UDP) is not indented to be used as a stand-alone transport protocol but is rather a shim layer between network and transport. So you could have e.g. TCP over SPUD over UDP or UDP over SPUD over UDP. In case of TCP you probably retransmit the SYN and therefore also the SPUD connect. In case of UDP you might not retransmit and simply try to send data without knowing if they will be received or not as your application might do it over UDP today as well.

> 
> It seems like a possible alternative would be to just send data packets spontaneously. The client can just be sure to generate a new tube ID when sending to a new destination/port pair, and maintain that state. Ultimately, you're going to have to use timers to expire state in case of packet loss, so why not just use timers exclusively?

As described above it’s more about network state then client state. However, you probably will always need timers because you can never be sure that certain information will be delivered. However, if you can get more explicitly signals (and that’s why we also would like to have a SPUD finish/stop packet) you can assist network nodes as well as end host to e.g remove state quicker  and maybe also use SPUD to set timer values correctly (see the use case draft).

Mirja

> 
> Jacob Chappell
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Christian Huitema <[email-masked]>
Date: Mon, 13 Jul 2015 17:19:54 +0000

> -----Original Message-----
> From: Spud [mailto:[email-masked]] On Behalf Of 
> On Monday, July 13, 2015 5:10 AM, Mirja Kühlewind wrote:
> ...
> As described above it’s more about network state then client state. However,
> you probably will always need timers because you can never be sure that certain
> information will be delivered. However, if you can get more explicitly signals
> (and that’s why we also would like to have a SPUD finish/stop packet) you can
> assist network nodes as well as end host to e.g remove state quicker  and maybe
> also use SPUD to set timer values correctly (see the use case draft).

We have to account for possible route changes, without the endpoint being aware. That means that the first packet visible on the new path will not be the first packet end-to-end. This is a strong argument for NOT relying on an explicit "Start" flag. 

Then there is the flip side that any explicit signal STOP can be spoofed, which enables DOS attacks. On the other hand, "absence of traffic" cannot be easily spoofed.

-- Christian Huitema

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jul 2015 10:25:37 -0700

Route changes:

the middleboxes of interest are setup so that route-changes don't
matter, eg: eithre single point of failure or chassis redundancy or
the like.

Teardown:

Explicit teardown in TCP doesn't seem to be bad enough of a
problem that TCP was changed, right ? And it is sen as valuable by
middlebox vendors. 

On Mon, Jul 13, 2015 at 05:19:54PM +0000, Christian Huitema wrote:
> > As described above it???s more about network state then client state. However,
> > (and that???s why we also would like to have a SPUD finish/stop packet) you can

-- 
---
Toerless Eckert, [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Jul 2015 10:45:20 -0700

On 7/13/2015 10:19 AM, Christian Huitema wrote:
...
> We have to account for possible route changes, without the endpoint
> being aware. That means that the first packet visible on the new path
> will not be the first packet end-to-end. This is a strong argument for
> NOT relying on an explicit "Start" flag.

It doesn't matter whether that state change is signaled by an explicit
START flag or not.

If you have state that persists between messages, then you have to know
when that state is established and which messages it affects, and the
result is the same.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Mon, 13 Jul 2015 19:49:56 +0200

On 7/13/15 7:19 PM, Christian Huitema wrote:
> We have to account for possible route changes, without the endpoint being aware. 

Unless p2a informs the a of the change.

Eliot

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Jul 2015 10:51:32 -0700

On 7/13/2015 10:25 AM, Toerless Eckert wrote:
...
> problem that TCP was changed, right ? 

See RFCs 4953 and 5961. This is also one reason why BGP sessions use
either graceful restart (4724 - to reduce the impact of the lost
connection) or are directly protected against spoofing by TCP MD5 (2385)
or TCP-AO (5925).

I.e., TCP and TCP uses were changed to address this issue.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Jul 2015 14:07:16 -0400

> problem that TCP was changed, right ? And it is sen as valuable by

TCP was designed in an era when malice was rarely considered as part of
network design and when it was considered it was (correctly) regarded as
secondary to getting the system working at all.

So the lack of authenticated teardown is certainly a concern, but not that
difficult to address using some lightweight symmetric crypto:

Sender, on session startup:
   Generate nonce n1, send 128 bits of H(n1) with connect message.

Sender on session shutdown:
   Send nonce n1 with teardown message.

Middleboxen:

* On receipt of packet without connect, optionally buffer till connect is
visible

* On receipt of teardown, keep connection open for MAX_TIME seconds.

Once a sender has sent a teardown message it is contracting that it is not
going to source any further packets without re-establishing the connection.
So while a middleboxen may see packets out of order, if it sees packets
after the max network time to live has expired, it is an error and they can
be discarded.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jul 2015 11:11:48 -0700

> I.e., TCP and TCP uses were changed to address this issue.

Right, my choice of words wasn't ideal. I meant to say that we
should ismply consider applying fundamentally the same mechanisms
used with TCP, just simplified wherever possible. MD5/A0 do seem to
make a lot of sense.

Cheers
    Toerless