On Wed, Dec 17, 2008 at 6:51 PM, Narayanan, Vidya <[email protected]> wrote: >> -----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'm quite confident you don't mean that designing a protocol that isn't subject to certain attacks is a bad thing. In terms of a threat analysis, obviously it's nothing formal, but what's been in this thread so far is that any entity authorized to send messages across the overlay can send an arbitrary number of messages through a given peer, consuming as much state as the rate at which they are able to send messages times the timeout for that state. The impact is fairly obvious, and we haven't reached consensus on the effectiveness or complexity of the solutions yet. >> 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. > Remember that requiring peers to not interleave messages severely restricts the amount of buffer space required (to essentially max message size + max out of order (10 is very reasonable) * MTU per connection. Obviously there can be an attack on network resources, but it's true that you can DoS any node in the Internet by flooding it with random data. That's not a protocol-specific attack. >> 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. > FWIW, storing forwarding state vs appending to the via list is a long-standing option in the protocol. The only thing that is new is whether to do hop-by-hop reassembly. I'd be interested in seeing a proposal for a DoS mitigation technique on this type of attack that has nearly the effectiveness or simplicity of hop-by-hop reassembly. For that matter, I'd be interested in a DoS mitigation approach for storing return path state that is simpler than using reassembly as a fall-back strategy. Bruce > 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
