Bruce,
> songhaibin 64081 wrote: > >> - I think the "traceroute" idea is interesting, but I have > mixed > >> feelings about it. On the one hand, it offers the capability > of > >> giving > >> a rather quick diagnostic answer to which hop is failing. On > the > >> other > >> hand, it seems like it's in danger of being a "please DoS me" > bit. > >> Effectively, the overlay is going to have to route and the > >> requesting > >> peer receive Echo Response messages at 1/3 the sending rate of > the > >> peers. Especially given the load this might impose on the > >> overlay, I > >> think it's safer to implement traceroute the conventional way > >> starting > >> with the ttl set to 1 and receiving a response from each peer > as > >> the > >> message exceeds its ttl, then increasing ttl by one. It takes > >> longer, > >> but it has the virtue of not being an amplification attack. > > > > > > Bruce, what you propose is interesting an works. Now suppose in > a Chord overlay with one million peers, if the successor list > length is 32, then if my memory is correct, the average hops for a > message is 1/2 * (20-5) = 7.5. There are not so many messages to > the source peer. Additionally, the traceroute message is not > initiated so often. It is only initiated when a peer wants to > diagnose where the problem happens for its failed routing, or t > > o collect some information of the overlay for other purposes. So > traceroute message works. > > I personally prefer just to look at it as O(log N), which is 20 in > this > case. (recognizing that it's not entirely correct, but I think > it's > better guideline.) > > I have mixed feelings about this. Overall it's fewer messages to > do a > traceroute along the entire path at once, and it's lower latency. > And > there aren't *that* many echo response messages. But it still > strikes > me as dangerous. There are no problems for the source node to handle these responses. I realize that for the convential traceroute, it sets different TTL to track the route may because the consideration of not introducing attacks to the routers in the path (not sure). But in the p2p overlay, things are different, intermediate peers not only forward the messages like routers, they do more than that, at least in Reload, they need to modify the via list, add r oute-log entry(optionally), and etc.. I have a little confusion here if we look the intermediate peers as just routing peers(compared to the routers), or else. I will consider the details of setting different TTL to construct the Echo traceroute, perhaps it will look more safe in that mode, but it looks more complex, I am not clear about that right now. > > > > The traceroute will not amplify attacks itself. In p2p overlay, > each peer can reply to the source node when it receives a message > unless you can have a mechanism to only allow the destination peer > to repond. However, for diagnostics and error report reasons, you > can't do that limit. > > > > I'm not sure I understand. This is the only proposal I've seen to > have > every peer along a path generate a new unique response. (route- > log and > similar build a long list, but it is maintained as a single message) I guess here is a trade-off if you want a big all-in-one report or step-by-step report. -Song Haibin > Bruce > > > > Do you satisfy with my clarification? > > > > Best Regards > > -Song Haibin > > > > > >> Bruce > >> > >> > > > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
