Re: [Spud] on trust and lying

[Bob Briscoe <[e-mail]>]

Eliot,

At 18:56 25/03/2015, Eliot Lear wrote:
>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.

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