On Sat, Feb 4, 2012 at 10:38 PM, Ondrej Mikle ondrej.mikle@gmail.com wrote:
On 02/01/2012 10:01 AM, Jacob Appelbaum wrote:
That sounds good. I'll wait for the first draft and send feedback.
First draft is ready here:
https://github.com/hiviah/torspec/blob/master/proposals/ideas/xxx-dns-dnssec...
Cool! Since you're calling it a draft, I'm not assigning it a number yet; please let me know when you want that to change.
Some initial comments:
DNS_BEGIN payload:
RR type (2 octets) RR class (2 octets) ID (2 octets) length (1 octet) query (variable)
The RR type and class match counterparts in DNS packet. ID is for identifying which data belong together, since response can be longer than single cell's payload. The ID MUST be random and MUST NOT be copied from xid of request DNS packet (in case of using DNSPort).
I think you can dispense with the "ID" field entirely; the "StreamID" part of the relay cell header should already fulfill this role, if I'm understanding the purpose of "ID" correctly.
Like Jakob, I'm wondering why there isn't any support for setting flags.
I wonder whether the "length" field here is redundant with the "length" field in the relay header. Probably not, I guess: Having a length field here means we can send
DNS_RESPONSE payload:
ID (2 octets) data length (2 octets) total length (4 octets) data (variable)
So to be clear, if the reply is 1200 bytes long, then the user will receive four cells, with relay payload contents: { ID = x, data_len = 490, total_len = 1200, data = (bytes[0..489] } { ID = x, data_len = 490, total_len = 1200, data = (bytes[490..979] } { ID = x, data_len = 220, total_len = 1200, data = (bytes[980..1199], zero padding} }
As above, I think we can eliminate the ID field. Also, in this case, I think the length field in this packet _is_ redundant with the length field of the relay cell header.
I think the total_len field could be replaced with a single bit to indicate "this is the last cell".
Data contains the reply DNS packet. Total length describes length of complete response packet.
I think we want to do some sanitization on the reply DNS packet. In particular, we have no need to say what the transaction ID was, or
Initial Questions:
When running in dnsport mode, it seems we risk leaking information about the client resolver based on which requests it makes in what order. Is that so?
How many round trips are we looking at here for typical use cases, and what can we do to reduce them? We've found that anything that adds extra round trips to opening a connection in Tor is a real problem for a lot of use cases, and so we should try to avoid them as much as possible.