> -----Original Message----- > From: Bruce Lowekamp [mailto:[email protected]] > Sent: Wednesday, December 17, 2008 12:46 PM > To: Narayanan, Vidya > Cc: Salman Abdul Baset; [email protected] > Subject: Re: [P2PSIP] RELOAD fragmentation > > You're right that there's always a need for DoS mitigation, but we > need to make the protocol immune from attacks when we can.
That's not how security solutions should be designed. Addressing threats without an analysis of the risk of the threat, burden on the attacker, impact of the attack and effectiveness vs complexity of solutions is not useful. > I believe > per-hop reassembly provides a way to eliminate one significant avenue > for DoS attacks, I don't believe so. We need to design protocols that are robust and have some ways to mitigate DoS attacks (cannot really eliminate DoS) that have high impact. In this case, per-hop reassembly actually does not even effectively mitigate the attack - one could be consuming resources by sending more and more fragments. Consider the case when a sender (attacker) starts with a large via list already - even if there were bounds on the size of the actual message, this is possible. > and there is a compatible optimization strategy for > those who wish to do a more complex implementation with associated DoS > mitigation. Providing options increases the complexity of the protocol and this is certainly not a place where I see the need for options. The DoS mitigation techniques will be needed regardless and that is always optional. Vidya > Admittedly, there are still other attacks. But with > static sized buffers, this seems to eliminate a big one to me. > > Bruce > > > > On Wed, Dec 17, 2008 at 2:14 PM, Narayanan, Vidya <[email protected]> > wrote: > > I agree with Salman here. I also agree with Ted in that introducing > options when it is really not needed is a bad thing. I don't see the > logic of avoiding DoS attacks with hop-by-hop fragmentation and > reassembly. Nodes can be subject to DoS attacks either way. And, this > won't be the first time we'd be designing protocols that have to deal > with state exhaustion attacks. > > > > I suggest we stick to keeping return path state and talk about DoS > attack mitigation strategies in the document. > > > > Vidya > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On > >> Behalf Of Salman Abdul Baset > >> Sent: Wednesday, December 17, 2008 10:53 AM > >> To: Bruce Lowekamp > >> Cc: [email protected] > >> Subject: Re: [P2PSIP] RELOAD fragmentation > >> > >> > >> Unless, overlay and nodes can somehow enforce message size, we > cannot > >> assume minimal size messages (2-3 frags). > >> > >> The return path state is simply a back pointer to the node (IP > address, > >> message identifier) from which the message was received. > >> > >> The concern about return path state is that it may tremendously > >> increase > >> the use of memory because: > >> 1. a significant portion of inprogress messages timeout wasting > >> memory. > >> 2. peers are under DoS so that there a lot of inprogress messages. > >> > >> However, for fragmentation: > >> (1) 1. is still a problem. > >> (2) peers can also be under DoS using fragmentation. > >> a) A peer(s) try to store a large data object or > >> b) send many messages within the desired fragment count (2 or > 3) > >> to > >> chew up memory space at the next hop. > >> > >> > >> For return path state, a solution to 2. is to limit the inprogress > >> messages from a certain peer to a configured number. If the peer > still > >> sends more messages, it can be informed to do ROUTE-QUERY. > >> > >> For fragmentation, a solution to (2-a) is that nodes limit the > number > >> of maximum fragments per message. However, that does not address (2- > b). > >> > >> (2-b) requires the same scheme as for return path state, i.e., > >> rate-limit and ask the exceeding sender to perform ROUTE-QUERY. > >> > >> Reassembly is still e2e. > >> > >> It is not clear to me that space-wise, why per-hop reassembly of 2-3 > >> 1500 > >> bytes segment is better than storing a <10 byte message identifier > >> and a 4-byte IP address of the node from which the message was > >> received. > >> > >> Observe that return-path state or via-lists are required to maintain > >> symmetric routing. However, it is not clear to me why this should be > a > >> MUST. If sender->destination routing is done on object-ID and > >> destination->sender routing is done on sender ID, then there is no > need > >> for via-lists or return-path states. Such scheme utilizes existing > >> connections between peers. > >> > >> -salman > >> _______________________________________________ > >> P2PSIP mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
