At 09:32 PM 16-07-04 -0400, Jared Mauch wrote: For June 2004 (AS378 - Israel): top 10 sending ports: Rank Port Bytes in Gigabytes Packets 1 http (80/tcp) 1561 GB 1620273534 2 edonkey (4662/tcp) 162 GB 459762654 3 0/icmp 120 GB 851624490 4 ssh (22/tcp) 89 GB 104515538 5 ftpdata (20/tcp) 78 GB 68494269 6 rtsp (554/tcp) 70 GB 54885058 7 https (443/tcp) 66 GB 138954839 8 0/unknown 56 GB 55661555 9 gnutella-svc (6346/tcp) 50 GB 145165558 10 domain (53/udp) 49 GB 371635845 top 10 receiving ports Rank Port Bytes in Gigabytes Packets 1 smtp (25/tcp) 344 GB 759247104 2 edonkey (4662/tcp) 186 GB 442992500 3 5662/tcp 154 GB 252829581 4 1026/udp 125 GB 205236837 5 1027/udp 119 GB 197314910 6 microsoftds (445/tcp) 91 GB 1721773411 7 netbiosns (137/udp) 88 GB 1209221595 8 http (80/tcp) 87 GB 1073140502 9 2048/icmp 62 GB 974609659 10 6970/udp 57 GB 103562134 We have hourly, daily, weekly and monthly stats. -Hank

this is from a 10-15 min sample period, based on flow count, not bytecount.

TOP TEN:

(tcp) 80, 25, 6699, 4662, 1433 443, 445, 6881, 7171, 6346

(udp) 53, 6257, 27960, 1026, 135 27015, 22321, 1027, 3310, 28960

- jared

-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On Sun, 18 Jul 2004, Walter De Smedt wrote:

How are ISPs monitoring P2P traffic these days? Monitoring based on Netflow/cflowd data and fixed port numbers for application classification doesn't seem to do the trick anymore as more P2P applications use random port numbers or even use port 80, with the purpose of circumventing potential ISP policies or accounting. With Netflow/fixed port nrs the amount of 'unknown traffic' is increasing steadily.

The next step in P2P recognition seems to be deep packet inspection with signature based detection. The major problem here is scalability - I don't see some device analyzing 1G, the typical uplink capacity of Internet gateways in a medium SP network, of traffic at layer 7. If this should be feasable, what if P2P applications would employ encryption schemes (e.g. IPSec) - this would render signature-based recognition useless.

you can also be fairly accurate from the flow data.. eg genuine web traffic is short small transfers, P2P is long-lived flows of continous high usage Steve

Mikael Abrahamsson wrote:

On Sun, 18 Jul 2004, Stephen J. Wilcox wrote:

...

you can also be fairly accurate from the flow data.. eg genuine web traffic is short small transfers, P2P is long-lived flows of continous high usage

In the long run, there is no way to accurately determine what kind of traffic everything is, and short of making encryption illegal and doing deep packet inspection, there is no future for those kinds of measures anyway.

Only way I see is to use L3 information as that's basically the only thing we're asked from our customers to handle (in most cases anyway), we move packets from one IP address to another IP address.

This might be true from a transit provider standpoint or 'packet mover', but not for DSL/Cable operators which are also ISP. They see big traffic increases over the last 2 years mostly due to P2P that trigger expensive network upgrades in the access - network load (and the investments related to it) and the revenues from subscribers are diverging. Such operators typically have flat rates and have a limited nr of profiles in terms of up-/downstream BW and Cap/month. A small percentage of the subs (20-30%) is responsable for a large percentage of the aggregated load on the network (60-80%). It makes more sense to introduce more differentiation in product offerings (pricing) where BW 'hoggers' pay more than the 'moderate' users instead of a general price increase. The net effect should be that profits increase, either by reduced network load or by higher revenues from product differentiation. This differentiation is less effective when it is based purely on US/DS BW and CAP alone. The main issue from a access network standpoint lies in the concurrent usage during peak hours where BW hoggers could affect the casual surfer. Surely, the monthly cap and rate-limitations mitigates this somewhat but only to a certain degree. A more efficient way would be to offer differentiated application-based services (e.g. gaming, P2P, VoIP, ...) Some of the applications could be accounted for at the service endpoint (e.g. gaming portal,voip services provided by the ISP), others need network-based metering/control. accounting/monitoring applications => know your users => define products => network-based enforcement Caveat: this might be an utopian vision ;-) -walter

Walter De Smedt wrote:

The next step in P2P recognition seems to be deep packet inspection with signature based detection. The major problem here is scalability - I don't see some device analyzing 1G, the typical uplink capacity of Internet gateways in a medium SP network, of traffic at layer 7. If this should be feasable, what if P2P applications would employ encryption schemes (e.g. IPSec) - this would render signature-based recognition useless.

We can do realistically 1.3G with current bits. I´m not ready to talk about performance by the end of the year. As a bonus, you'll get classification and population reports for both p2p and backdoored / virused hosts without performance impact. (export these with BGP4 to fancy effects, or simple ACL / firewall list for more traditional approach) Pete