From f031abd948eb3487e871a97b4b3b1cd3d931f49c Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Thu, 3 Jul 2008 17:00:42 +0000 Subject: r16695@tombo: nickm | 2008-07-03 13:00:38 -0400 add new proposal 149: using netinfo data svn:r15629 --- proposals/149-using-netinfo-data.txt | 43 ++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 proposals/149-using-netinfo-data.txt (limited to 'proposals/149-using-netinfo-data.txt') diff --git a/proposals/149-using-netinfo-data.txt b/proposals/149-using-netinfo-data.txt new file mode 100644 index 0000000..6ee96a0 --- /dev/null +++ b/proposals/149-using-netinfo-data.txt @@ -0,0 +1,43 @@ +Filename: 149-using-netinfo-data.txt +Title: Using data from NETINFO cells +Version: $Revision$ +Last-Modified: $Date$ +Author: Nick Mathewson +Created: 2-Jul-2008 +Status: Open + +Overview + + Current Tor versions send signed IP and timestamp information in + NETINFO cells, but don't use them to their fullest. This proposal + describes how they should start using this info in 0.2.1.x. + +Motivation + + Our directory system relies on clients and routers having + reasonably accurate clocks to detect replayed directory info, and + to set accurate timestamps on directory info they publish + themselves. NETINFO cells contain timestamps. + + Also, the directory system relies on routers having a reasonable + idea of their own IP addresses, so they can publish correct + descriptors. This is also in NETINFO cells. + +Learning the time and IP + + We need to think about attackers here. Just because a router tells + us that we have a given IP or a given clock skew doesn't mean that + it's true. We believe this information only if we've heard it from + a majority of the routers we've connected to recently, including at + least 3 routers. Routers only believe this information if the + majority inclues at least one authority. + +Avoiding MITM attacks + + Current Tors use the IP addresses published in the other router's + NETINFO cells to see whether the connection is "canonical". Right + now, we prefer to extend circuits over "canonical" connections. In + 0.2.1.x, we should refuse to extend circuits over non-canonical + connections without first trying to build a canonical one. + + -- cgit v1.2.3-54-g00ecf