diff options
author | Christian Grothoff <christian@grothoff.org> | 2009-07-08 22:11:46 +0000 |
---|---|---|
committer | Christian Grothoff <christian@grothoff.org> | 2009-07-08 22:11:46 +0000 |
commit | 191131b599cc0dc1219930221f84155b870ec6cd (patch) | |
tree | d52ea99dbcd8f3ebe4a886bedd81c59d5fbb2ffb /TODO | |
parent | ed5070624e71754775c514124a1f18eff8e16944 (diff) | |
download | gnunet-191131b599cc0dc1219930221f84155b870ec6cd.tar.gz gnunet-191131b599cc0dc1219930221f84155b870ec6cd.zip |
notes_and_debugging
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 38 |
1 files changed, 33 insertions, 5 deletions
@@ -1,12 +1,40 @@ | |||
1 | PHASE #1: (Goal: settle key design questions) | 1 | PHASE #1: (Goal: settle key design questions) |
2 | 2 | ||
3 | core: | ||
4 | - test fails with fresh /tmp directory (but passes when run a second time) | ||
5 | problem seems to be caused by HELLO validation (unvalidated | ||
6 | HELLO not used to connect for good, then somehow SETKEY never happens); | ||
7 | * double-check crypto involved in HELLO validation (PONG signature check; | ||
8 | what about MiM? Might be trivial right now; adding source IP-address | ||
9 | to PONG signature might help? How would we validate that (given that | ||
10 | we may be learning our source IP address(es) the same way...)) | ||
11 | + if we add address to transport-level PONG, we may be able to simplify | ||
12 | WELCOME messages (no need to add addresses there anymore, right?); | ||
13 | + we probably want some kind of voting/counting for learning IP addresses | ||
14 | (maybe including IP addresses in ads proportional to how often others | ||
15 | report them? we at least need some protection against >64k HELLOs!), | ||
16 | + provide a way to give the user a list of "learned" IP addresses and | ||
17 | a way to easily "veto" addresses off the list! | ||
18 | => If MiM attacker uses vetoed address, blacklist the specific IP for | ||
19 | the presumed neighbour! | ||
20 | * Use special, non-WELCOMEing TCP-connection for HELLO/address validation; | ||
21 | that way, we can avoid confusion between a dozen parallel validating connections | ||
22 | and the real one, avoid queueing messages on validating connections and | ||
23 | shut those down immediately after sending/receiving the PONG | ||
24 | (and maybe avoid some signalling about connections to the other layers) | ||
25 | * core notifies clients about "encrypted" connections being up well before | ||
26 | we get the encrypted PONG; sometimes this may be OK (for topology killing | ||
27 | unwanted connnections), but of course not in general. I suspect we want | ||
28 | to signal on PONG and have topology hook directly into transport to | ||
29 | kill plaintext connections before they have a chance to become encrypted | ||
30 | (may require minor hack in transport API) | ||
31 | |||
3 | Util: | 32 | Util: |
4 | * improve disk API [Nils] | 33 | * improve disk API [Nils] (Nils, is this done? -Christian) |
5 | * Windows: use events instead of pipes to signal select()s [Nils] | 34 | * Windows: use events instead of pipes to signal select()s [Nils] |
6 | * only connect() sockets that are ready (select()) | 35 | * only connect() sockets that are ready (select()) [Nils] |
7 | [Nils: I'm not sure what you mean by this; fresh sockets are always | 36 | [On W32, we need to select after calling socket before |
8 | ready for connect(), just 'write' after connect needs select AFAIK; | 37 | doing connect etc.] |
9 | please clarify. --Christian] | ||
10 | 38 | ||
11 | TESTCASES WANTED: | 39 | TESTCASES WANTED: |
12 | For these functions, it would be nice if we had testcases ("make check") | 40 | For these functions, it would be nice if we had testcases ("make check") |