On 13.11.2007 16:09, Grant Taylor wrote: > On 11/11/07 19:51, sAwAr wrote: >> Is there any way to recognize ( and then shape ) p2p traffic which is >> encrypted? Modern p2p clients have this ability moreover some of >> them have this enabled by default. Now I'm using ipp2p for iptables >> but as I know this doesn't recognize encrypted traffic. > > Does this mean that we are down to handling traffic based on the > sustained stream(s)? I.e. how long the streams have been active, how > many packets per second, how many streams a given end point has, speed > of traffic, average size of packets? > > Encrypted or not, I believe all traffic can be somewhat recognized by > its usage pattern(s). However there may be more false positives. We > may end up recognizing what we know as good and putting the rest at a > lower class of service. Well, you can surely try. But then again, I have been doing research (publication pending) in traffic-pattern-based detection of VoIP flows and peer-to-peer connections. While it usually is easy to find a pattern matching your particular traffic class very well, part of this research has been dedicated to automatically circumvent these systems. Why that? Simple. Application evolve to circumvent detection. If you can simulate that evolution in the lab, you can find out where your detection algorithms will fail. Of course, that enumeration of possible failure modes is non-exhaustive. Bottom line: This is an arms race. Unless you do lots of research and testing, detection will always be trying to catch up. If detection manages to catch up, circumvention will advance, but you may have a small time window where you can enjoy the "win". However, winning becomes more and more expensive. Clients can expend considerable amount of CPU power to avoid detection. You don't have that luxury in filter systems unless you have one filter per client. Regards, Carl-Daniel _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
