[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: We need to split streamid into recognized and streamid



On Thu, Dec 18, 2003 at 12:46:30PM -0500, Paul Syverson wrote:
> The sha1 hash is per stream not per circuit yes? And if the node has already
> taken down that stream, which is why it doesn't recognize the stream ID,
> then the integrity checking on it doesn't matter.

The sha1 hash is per circuit. Specifically, one hash for each direction
for each hop of each circuit. That way we can ensure integrity on control
relay cells such as circuit-level sendmes. And that way we don't need
the overhead of a new key exchange for each stream (currently no crypto
handshake is needed for streams).

> Are you concerned about the node passing on a cell it should have
> removed, thus wrecking the circuit from then on in that direction?

That is an issue yes. It's probably also an anonymity issue we don't
fully understand -- e.g., if there aren't open streams beyond your hop
in the circuit, and a series of relay cells are sent past you that don't
get responses, then you can guess that a stream just closed earlier in
the circuit.

In general, being able to know that a relay cell was destined for your
hop in the circuit seems like a really important feature. I was surprised
to realize that our current design isn't very good at it.

> > The semantics of the begin relay cell can change now too, since we can
> > simply start using the new streamid directly.
> 
> What new streamid?

The new streamid for the new stream which is opened because of the begin
relay cell.

> If I understand you in general, your proposal would stop
> `accidentally' forwarding a cell from wrecking the circuit (by getting
> the stream ciphers out of synch). I like the modularity as long as the
> overhead isn't too high. The scenario is then something like: node
> gets a cell that is for him but that he doesn't have a known streamid
> for.  With the separation, node doesn't forward the cell but instead
> kills the circuit (because something is wrong with it) as opposed to
> wrecking it in one direction.

Actually, we don't kill the circuit. There are some edge cases which will
deliver relay cells after the stream has died. Some examples are relay
end cells (we don't have all the edge cases fixed there, so sometimes
both sides end the stream near enough in time that they've forgotten about
the stream by the time the other relay end arrives) or relay sendme cells
(which might get sent back before the relay end is processed). I'd like
to reduce the number of edge cases that cause this to happen, but I'm
not optimistic that we can remove all of them. So I think we'll need to
accept (and drop) unknown relay cells for now.

--Roger