I think if we can add a security layer between Routing Layer and Application Layer in RELOAD, in which some common and important security modules can be defined. Maybe we can define the common APIs of these security modules and don't care about the specific protocols or methods used in them.
2008/7/4 Eric Rescorla <[EMAIL PROTECTED]>: > At Thu, 03 Jul 2008 14:50:21 +0800, > songhaibin 64081 wrote: > > > > > > > > > At Thu, 03 Jul 2008 11:10:37 +0800, > > > jiangxingfeng 36340 wrote: > > > > > > > > > At Wed, 02 Jul 2008 09:48:27 +0800, > > > > > jiangxingfeng 36340 wrote: > > > > > > > > > > > > Hi,all: > > > > > > > > > > > > The authors of RELOAD-4 have done a great work to address > > > security> > > issues in P2P system. But I don't think it addresses > > > all security > > > > > > issues. Especially the malicious behaviors of authenticated > > > peer are > > > > > > not well dealt with, for example, misroute the packet, > > > discard the > > > > > > packet silently,etc. > > > > > > > > > > Well, we certainly never claimed to address all security issues, > > > > > so I'm not going to disagree with that. > > > > > > > > > > That said, I don't really expect a basic p2p protocol to do much > > > > > to address this sort of low-grade packet mismanagement attack. > > > > > > > > I don't think it is a low-grade issue because its negative > > > impact on the routing. > > > > > > There are a large number of ways to damage routing. It's not clear > > > to me that these are especially bad, and, as I said earlier, > > > the defensive techniques depend primarily on the DHT. > > > > > > > Because the P2P overlay is an self-organizing system, there are good > > or bad intermediate peers between the source peer and the destination > > peer. These intermediate peers may discard messages, misroute messages, > > do replay attacks, and etc. > > You say discard, misroute, and replay, as if they're all the same. > But they're not. > > Replay isn't a big issue: peers are expected to handle it correctly. > Misroute is either annoying or serious depending on how it's used. > Note that the fact that data is signed removes a lot of the practical > uses of misroute. > Discard is an issue, but as discussed below, it's hard to solve > generically. > > > > Or some peers can put victim's contact > > information under popular resource to cause DoS attacks, > > > or manufacture a chosen-ID attack, > > Which is why RELOAD uses a central assignment server, to prevent this > stuff. > > > > and so many. I do think some of these > > attacks are very bad to the p2p overlay. I do believe the 'basic' > protocol > > should provide the 'basic' defense for some general attacks, but not for > all > > important attacks. > > Which it does for some of the atacks you mention, but not all > of them. > > > > > > > Although topology plugin can isolate specific mechanisms from the > > > > base protocol, the evovling security or other mechanisms have > > > > requirements for the protocol messages which should help the > > > > realization of the mechaisms. So that means at least RELOAD should > > > > support adding new messages or extending existing messages to > > > > achieve that. > > > > > > RELOAD supports both of these already. > > > > I don't like the idea to isolate many issues to specific P2P algorithms, > > unless these security issues are caused by the P2P algorithms. > > Yes, but in the specific case of discard and misrouting, they are > intricately intertwined with the routing algorithm. Consider that the > two best-known techniques for this kind of attack are: > > - Multiple routing to the target [Castro et al, 2002] > - Rapidly churning the overlay [Condie et al 2006] > > While RELOAD provides facilities to implement both of these, > actually implementing them requires understanding the overlay. > > > If you believe there are some specific set of generic techniques > that ought to be supported by RELOAD, I encourage you to write > a draft describing them. > > -Ekr > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip >
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
