So I wanted to pick back up on this thread since it didn't go too far, but I think this is a very important area. I think that the diagnostic mechanisms are something we really need to have, and I have been re-reading and think that the work in the diagnostic draft is the right direction, so I wanted to get a bit more discussion going on this item before the meeting, hoping that we can resolve this and have a good path for the authors on the diagnostics draft to go forward with for a new version coming out of San Francisco.
For those of you who aren't familiar, the basic idea is that you want some mechanism to be able to collect diagnostic information from each peer that comprises a path through the overlay, in order to be able to diagnose any problems that may exist in that path/evaluate the peers/etc., so there is a problem that you really do want information from each peer along the path. Cullen's concern here is with the mechanism described in 4 (1) of the draft: ECHO message being sent out, and getting back a response from each peer along the path. You have something like this: a->b->c->d->e but generate responses at each hop: b->a c->a d->a e->a Hence a ddos risk if I send out a bunch of messages randomly and claim they are all from a...(understanding that other mechanisms in RELOAD may prevent that of course) The alternative in 4 (2) is an iterative mechanism: a->b b->a (and suggests c) a->c c->a (and suggests d) a->d d->a (and suggest e) e->a In the draft, the suggestion is that 4 (1) may be appropriate in a managed network. I think that we would want to clarify the definition of managed network, for example perhaps these type of requests are only valid when signed by a? This may still be problematic (I can no longer dos someone else, but I may be able to generate a lot of unneeded traffic, which still could severely compromise the overlay) in terms of generating lots of traffic. Perhaps even a stronger requirement that the signer be an admin of some sort (although now determining who is an admin and the mechanisms for deciding that a message is signed by the admin crop up -- this starts to be in BCP land) 4 (2), using the recursive mechanism eliminates the specific issue I think Cullen brought up, but of course opens the problems of NAT traversal. Another idea that struck me (rather complex timer issues make it rather ugly) was to have the request go out using standard symmetric recursive routing, with each peer appending information as it returns. There is a timer issue here in that if the message fails on some leg, the last one to send it needs to send back a response anyway. In otherwords if the path should have been: a->b->c->d->e->d->c->b->a but d is dead, you still need that as diagnostic information, and need something like: a->b->c->XXX ...some time passes... c(w/XXX)->b->a The timers there look ugly (a is likely to time out first, not c, and if c times out last and sends, how do we prevent this turning into recursive (i.e., b fails and sends back, then c fails and sends, etc), and also the messages could be very large for large path lengths (good thing we are talking about fragmentation now :) ) I don't have a particular solution I think makes sense here, and it may be that we want to offer each as a mechanism. However, I think that having something like what is in the diagnostics draft is essential, but I read Cullen's email and he certainly has some valid ddos issues with the echo approach. I wanted to share my thoughts and see if we could get some list discussion here to try to get this one ironed out... David (as individual) On Tue, Mar 3, 2009 at 2:26 AM, Song Haibin <[email protected]> wrote: > Dear Cullen, > > You have the same concern with Bruce and Henning. The authors do not think > this method is broadly suitable for the diagnostics in the open Internet > environment either. However, it may be used in some administrative p2p > overlays. The usage of Echo method is limited to certain application > scenarios. > > As we said in the draft: "An Echo request message is used to retrieve the > diagnostic information of the specified path in administrative p2p overlays > where all the peers in the overlay are trusted or based on specific > authorization. For example, it can be used in a p2p overlay where all peers > deployed by the operator to provide services to the customers (clients), > where the diagnostics happens between peers in the p2p overlay. For the > untrusted p2p overlays, e.g. some end user equipments can be the peers in > the overlay network, then the Echo method must be used with care for the > consideration of potential DoS attack. Compared with Path_Track method, > Echo method brings less messages to the p2p overlay network." > > > Best Regards, > Haibin > Skype: alexsonghw > > >>-----Original Message----- >>From: [email protected] [mailto:[email protected]] On Behalf Of >>Cullen Jennings >>Sent: Tuesday, March 03, 2009 5:23 AM >>To: P2PSIP WG >>Subject: [P2PSIP] Comment on p2psip-diagnostics >> >> >>One comment on the Echo design.... I'm worried about a method where >>sending a single request can cause a whole bunch of responses. This >>has congestion and DOS issues. It is also not clear how all the >>retransmissions timers would work with it. >> >>We should think about if it is possible to move away from the one >>request, multiple responses design. >> >>Cullen <as an individual contributor> >> >> >> >> >>_______________________________________________ >>P2PSIP mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
