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. I believe per-hop reassembly provides a way to eliminate one significant avenue for DoS attacks, and there is a compatible optimization strategy for those who wish to do a more complex implementation with associated DoS mitigation. 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
