TheArchive/iodine
1
0
Fork 0
mirror of https://github.com/yarrick/iodine.git synced 2025-08-14 23:07:26 +00:00
Code Issues Packages Projects Releases Wiki Activity

start merging common and docs #76

Browse Source
This commit is contained in:
J. A. Bezemer
2009-09-20 21:10:38 +00:00
committed by Erik Ekman
parent 92b160a416
commit 05e99c7a3f
4 changed files with 185 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
doc/proto_00000501.txt
View File

@@ -83,6 +83,12 @@ Server sends:
Server may disregard this option; client must always use the downstream
encoding type indicated in every downstream DNS packet.
l or L: Lazy mode, server will keep one request unanswered until the
next one comes in. Applies only to data transfer; handshake is always
answered immediately.
i or I: Immediate (non-lazy) mode, server will answer all requests
(nearly) immediately.
Probe downstream fragment size:
Client sends:
First byte r or R
@@ -160,6 +166,39 @@ The server response to Ping and Data packets is a DNS NULL type response:
If server has nothing to send, data length is 0 bytes.
If server has something to send, it will send a downstream data packet,
prefixed with 2 bytes header as shown above.
"Lazy-mode" operation
=====================
Client-server DNS traffic sequence has been reordered to provide increased
(interactive) performance and greatly reduced latency.
Idea taken from Lucas Nussbaum's slides (24th IFIP International Security
Conference, 2009) at http://www.loria.fr/~lnussbau/tuns.html. Current
implementation is original to iodine, no code or documentation from any other
project was consulted during development.
Server:
Upstream data is acked immediately*, to keep the slow upstream data flowing
as fast as possible (client waits for ack to send next frag).
Upstream pings are answered _only_ when 1) downstream data arrives from tun,
OR 2) new upstream ping/data arrives from client.
In most cases, this means we answer the previous DNS query instead of the
current one. The current query is kept in queue and used as soon as
downstream data has to be sent.
*: upstream data ack is usually done as reply on the previous ping packet,
and the upstream-data packet itself is kept in queue.
Client:
Downstream data is acked immediately, to keep it flowing fast (includes a
ping after last downstream frag).
Also, after all available upstream data is sent & acked by the server (which
in some cases uses up the last query), send an additional ping to prime the
server for the next downstream data.
======================================================