At Thu, 19 Jun 2008 11:43:14 +0800, JiangXingFeng wrote: > > Yes, I agree some sort of keep alive is needed to detect liveness on > > these connection. We also need to be able to deal with receiving a TCP > > RST for the TLS connections. > > IMHO, a new keepalvie message is needed and could detect the connection > failure in time. A keepalive mechanism between two peers could also be used > to distribute some information like peers' capability or their changes so > that other peers could know the changes in time.
We already have a keepalive message: UPDATE. > > Well, I'm going to blame some other author on the 2^32 :-) but > > seriously this is allowed to be much larger than the IP MTU. The > > transport will need to deal with fragmenting and sending this. Clearly > > TCP already does this and in the case of UDP, reload provides > > fragmentation. There is not too much on that yet as it's fairly well > > understood how to do it and we just need to go add text and work with > > the transport folks on getting it right. > > Basically, I don't like the fragmentation/reassembly idea. Because I think > it will introduce some security threats. For instance, a malicious peer may > send most of the fragments and does not send the rest on purpose, so that > the reassembly will not succeed in the destination peer. Then DoS attack > happens and will make the overlay unstable. This is a consequence of having operations involving amounts of data larger than can fit in a single MTU. It doesn't matter where in the protocol that sort of reassembly happens. For instance, you can do it at the TCP or TLS layer instead. Moreover, I don't think this is much of a security threat. There are well-known techniques for avoiding excessive resource consumption from fragment reassembly. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
