Google
  Web www.spinics.net

Re: How to fight with encrypted p2p

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

[Bugtraq]     [Fedora Legacy]     [GCC Help]     [Yosemite News]     [Yosemite Photos]     [IP Tables]     [Netfilter Devel]     [Fedora Users]

Powered by Linux