Subject: [Spud] on trust and lying

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Mar 2015 13:56:45 -0500

A comment was made at the microphone that middle boxes will lie to end
hosts and end hosts will lie to middle boxes.  That is not strictly
true, and we have an existence proof of when it is not: that is TCP. 
The intended point of Joe's slide to map SPUD states to TCP wasn't just
a simple example.  The behavior of TCP on the hosts can be observed by
the middle box and based on that behavior the middlebox can make
appropriate decisions.  The most classic example of this is simply
blocking inbound SYNs to block opening of new connections.  New
connections do not establish absent that first naked SYN.  Similarly,
the network can assume that only connections that are already open will
contain an ACK, knowing that a host will reject an unsolicited packet
that contains that flag.  That three way handshake is in effect an
implicit behavior contract between the end host and middle boxes.

Whatever SPUD becomes, it has to establish, at the very least, that
implicit behavior contract for UDP.  Today it simply doesn't exist in
the general sense, although there are may be a higher few protocols that
allow for that.

Eliot

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 25 Mar 2015 19:19:59 +0000

I do think that we need a way to establish a trust relationship 
not only between the endpoints but also among the end points and the
middle boxes as well as among the middle boxes 

br
Salvatore

> On 25 Mar 2015, at 13:56, Eliot Lear <[email-masked]> wrote:
> 
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Roland Bless <[email-masked]>
Date: Wed, 25 Mar 2015 20:53:09 +0100

Hi

Eliot Lear wrote:
> implicit behavior contract for UDP.  Today it simply doesn't exist
> in the general sense, although there are may be a higher few 
> protocols that allow for that.

Especially for future protocols, the middleboxes have to believe/trust
on the information given in the SPUD encapsulation, since they may not
be able to check what the protocol is actually doing inside due to
encryption.

Regards,
 Roland

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 25 Mar 2015 21:28:57 +0000

Eliot,

>true, and we have an existence proof of when it is not: that is TCP.

We cannot naively rely on TCP experience though, because part of the 
security that firewalls attribute to TCP's connection life-cycle 
controls (SYN, SYN/ACK, FIN, RST etc) derives from being able to 
assume their universal support on all hosts. SPUD doesn't have that luxury.

For instance, any TCP host will always discard a data segment that 
was not preceded by a SYN. But UDP hosts out there today without a 
firewall in their stack will accept a UDP datagram whether or not it 
is preceded by a SPUD open command (because they don't recognise SPUD 
commands).

So if a perimeter firewall today is blocking all UDP from red-side 
(to protect such unprotected hosts), it is not going to allow through 
UDP datagrams to any green-side host, just because the datagram says 
"SPUD-open". At best the firewall will be reprogrammed to allow 
SPUD-open through to green-side hosts that have previously registered 
that they support SPUD. The firewall policy might be more 
restrictive, e.g. it might allow SPUD-open from only specific 
red-side hosts to certain green-side SPUD hosts.

That's why I said, at the mic today, that the SPUD-ack-open command 
is the significant one in security terms. You can think of that as 
either of two dual functions:
i) the command that a green-side host uses to register its SPUD 
support to the firewall within a long-term security context.
ii) Or you can think of it as equivalent to a "SYN/ACK preceding a 
SYN" for the short-term security context of a tube.
It should be possible for one command to support either type of context.

I am not disagreeing with your general point that TCP is an 
exsistence proof of a protocol that has sufficient hooks to be able 
to mitigate the effects of lying. I'm just saying we have to think 
about SPUD security from scratch, not just rely on mimicking TCP, 
because SPUD has the additional dimension of incremental deployment.

Bob

________________________________________________________________
Bob Briscoe,                                                  BT