On Jan 31 2008, Robert Hailey wrote: >For all decisions particularly with regards to routing, we *only* use >the network id that we finally assign to them.
OK... so we're essentially creating a map of the network, identifying subnets and numbering them? For local subnets we check which of our immediate peers can reach which others, and possibly override the network IDs they advertise - for remote subnets we just trust the network IDs learned from successful replies? If a peer reports that it can reach subnet X and we don't have any immediate peers in subnet X, how can we verify that information? >Consider node "B" who is between "A" & "C" (A-B-C). He tells "C" a UID >& Secret [a randomly generated long?], and "C" stores that secret/uid >as part of our peernode record. Node "B" then sends node "A" a routed >ping with the same UID, and if node "A" returns the pong with the >correct secret it is a success. So we're only using the pings to identify which of our immediate peers can reach which others without going through us? Sorry, in that case ping spoofing shouldn't be a problem - but how do we determine reachability beyond our immediate peers? >Surely dropping (or sabatoging) the pings would only get a malicious >node could only negatively effect him; that is, it would only get him >stuffed into his own 'network' box by us. Right, it's spoofing pings that concerns me, not dropping them. >> How do you prevent an attacker from >> forwarding pings but dropping (selected) requests? > >I think that this is a fundamental problem even now. Absolutely - I'm not trying to say that your proposal is causing the problem, only that it doesn't seem to solve the problem unless the attacker behaves. >Whereas dropping >the request would cause a backoff, I presume you mean DNF. Right. >This amounts to allowing a node to be labeled as in the network they are >actually in, but they play unfair. Yes, exactly - they are part of the same network as us, they don't appear to be a dungeon/rabbit-hole/separate-network/whatever, and therefore they can persuade other nodes in our network not to occupy a certain region of the key space. As I understand it, your proposal is meant to allow each subnet to occupy the whole key space. I'm imagining an attacker who wants to exclude non-attacker nodes from a region of the key space. So our goal is to identify the attacker's subnet; the attacker's goal is to avoid being identified as a separate subnet. >But creating a new subnet does not control a keyspace region, >particularly if it is correctly identified as a subnet. What it does >is create a duplicate keyspace region, which may-or-may-not be routed >into (presently the code is undecerning). Exactly - the attacker wants us to think he's in the same subnet as us. >No, no... advertising in the sense that a network location is >presently 'advertised' it is a single value that we remember per-peer, >and not a thing to be flooded or forwarded. For each peer-node we >would now additionally need to remember four things: >(1) a CRAM-UID, >(2) a CRAM-Secret, >(3) a network-id-they-advertise, and >(4) a network-id that we assign to them. OK... the CRAM-UID and CRAM-Secret are for the challenge-response protocol you described above? I'm still not sure why peers need to advertise a network ID if we're going to assign them one based on their connectivity to our other peers... what am I missing? >> An attacker could respond normally to requests but advertise a >> different >> network ID each time to prevent network IDs from stabilising. > >Not so. Good-behaving nodes would only re-examine there network id >every 'x' minutes/seconds, without respect to when or how often their >peers change the network id that they advertise. Right, sorry, I misunderstood what you meant by advertising - I was referring to the network IDs in successful replies - a malicious node could reset each one to a unique value to fill our routing table with nonexistent subnets. >Admittedly, the routing-to-a-distant-network portion is the weakest >portion of this idea; Matthew has called it 'escape routes'. OK, so if we're not going to route to other subnets, what's the purpose of network IDs? Just to avoid routing to peers that aren't well-connected to our other peers? (Not that that's not useful, but it seems like it could be achieved without network IDs.) >I suppose that if this were to be >implemented as proposed, we would need a separate LRU per peer, and >some kind of probabilistic filtering with respect to the net id's we >forward (e.g. only if it is our network-id or is "established"?). I still don't see, in general, how you can distinguish between distant subnets that really exist and distant subnets invented by an attacker. (This is a different attacker from the one that wants to occupy a region of the key space, BTW - this one's goal is to make you search a large number of nonexistent subnets before giving up, and possibly to stop you discovering real subnets by flooding your routing table.) Cheers, Michael
