
Trickles - Stateless High Performance Networking - andrewflnr
http://www.cs.cornell.edu/~ashieh/trickles/protocol.php
======
emin_gun_sirer
I just noticed that this work got linked from HN today. This is my PhD student
Alan Shieh's work, jointly with my colleague Andrew Myers. I'm surprised to
see it here, as we did the work back in '05 or so. But it was a lot of fun and
I think it still represents the extreme point in pushing state out of the
server to the client side.

So, I'll try to answer some of the questions here and provide some of the
insights and background that do not appear in academic papers.

The intuition behind trickles is that the packets act like continuations, the
same continuations you may be familiar with from programming languages like
Scheme. Instead of a server holding state, it pushes that state to the client.
To get service, the client presents the continuation to any server host, which
can reinstate its state, and provide the service.

Since the servers are stateless, you can direct a client request to any host.
This kind of handoff is, let's just say, not easy to do when you have stateful
TCP connections to maintain.

Not every state machine can be converted into a format where it can run over
Trickles. But I think the community was surprised to see that something as
complicated as TCP could be trickle-ized.

~~~
andrewflnr
I just stumbled on it in a lambda-the-ultimate thread and thought it looked
neat.

------
dllthomas
Interesting notion, but I'd be leery of the security implications of running
code on my server that the client had its hands on. Which is not to say it
_couldn't_ be secured properly.

~~~
mjb
Their use of a MAC to prevent tampering and encryption to add confidentiality
it seems like they have that covered rather well.

Their replay attack prevention mechanism
(<http://www.cs.cornell.edu/~ashieh/trickles/security.php>) seems to be a
little bit weaker at first glance. They're preventing replays by enforcing
freshness and keeping short-term state about packets that have been seen
recently. That seems strong enough, but also seems like exploiting the limited
size of the short-term state store may be DoS attack vector, or a vector that
allows you to do replay attacks during high-traffic periods. I haven't read
their proposal in enough detail yet, though.

~~~
tptacek
Regarding the general concept of pushing state out to clients and using
cryptography to protect it, I agree, and further think the DOS vector you're
considering isn't very attractive.

Regarding this particular implementation: it's not documented well enough to
tell, is it? It does use an HMAC. It does use AES. In the few minutes I gave
myself to go through the code, I can't even figure out what mode they're
running AES in, though, or what order the operations are applied in. How are
keys generated? What keys are shared between client and server, and what keys
are held serverside?

The latter questions are irrelevant to the academic project of proving the
Trickles concept, so I'm not criticizing the team. I'm just saying, there's a
_lot_ of detail you'd want to have before saying they've got things covered.

~~~
ashieh
The prototype did not use AES to encrypt continuations. As you said, the
details are tricky. For instance, CTR mode may well be insecure. In a
stateless environment, it's quite likely that the client could trick the
server into encrypting multiple plaintexts with the same counter value.

The prototype did use AES to compute and check nonces -- AES is faster than
HMAC for such small input sizes.

Since the server is effectively sending encrypted data and MACs to itself,
there is no need for key distribution. Only the server holds keys; the client
treats the encrypted data and MACs as opaque data.

