Is there an updated list of ports used by Napster and various games (Doom, Unreal, etc)? At this point we're just collecting data points and not actively filtering anything, but of course the IANA port number list is sadly out of date with regard to these tools. Thanks in advance, Jeff Kell <jeff-kell@utc.edu> Systems/Network Administrator University of Tennessee at Chattanooga
This is an irritating problem with no update on the port list, there must be an update somewhere but it is not publicly available... And I am not finding one for Europe to see if they use different ports... Jeff Kell wrote:
Is there an updated list of ports used by Napster and various games (Doom, Unreal, etc)? At this point we're just collecting data points and not actively filtering anything, but of course the IANA port number list is sadly out of date with regard to these tools.
Thanks in advance, Jeff Kell <jeff-kell@utc.edu> Systems/Network Administrator University of Tennessee at Chattanooga
-- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh
> > Is there an updated list of ports used by Napster and various games > > (Doom, Unreal, etc)? At this point we're just collecting data points > > and not actively filtering anything, but of course the IANA port number > > list is sadly out of date with regard to these tools. Best port-number list I know of is the one that's included in the nmap distribution. -Bill
Europe uses the same port numbers. J -- Joshua Goodall IP Systems Development Team Leader Tel: +31 20 711 3200 SpeedPort Global Network Mob: +31 6 2859 3949 On Tue, 7 Mar 2000, Henry R. Linneweh wrote:
This is an irritating problem with no update on the port list, there must be an update somewhere but it is not publicly available...
And I am not finding one for Europe to see if they use different ports...
Jeff Kell wrote:
Is there an updated list of ports used by Napster and various games (Doom, Unreal, etc)? At this point we're just collecting data points and not actively filtering anything, but of course the IANA port number list is sadly out of date with regard to these tools.
Thanks in advance, Jeff Kell <jeff-kell@utc.edu> Systems/Network Administrator University of Tennessee at Chattanooga
-- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh
At 11:09 PM 3/6/2000 -0500, you wrote:
Is there an updated list of ports used by Napster and various games (Doom, Unreal, etc)? At this point we're just collecting data points and not actively filtering anything, but of course the IANA port number list is sadly out of date with regard to these tools.
If you're intending to filter at some point, then who cares what the ports are? Filter the ports that are using too much traffic on your network. If Napster/Doom/whatever isn't using too much bandwidth, blow it off. There's a very big difference between filtering to correct a problem, and prior restraint.
When you have limited bandwidth you need to ensure that it is used for what it is purchased for (email access to network based resources etc) and also as Napster moves MP3's you need to ensure that your facilities are not used for infringement on other's intellectualproperty so that you and your organization are not sued by rapacious lawyers unfortunate but there it is here is a short list in ACL format of Napster and other MP3 servers. ! ! Napster's Servers & Networks ! deny ip 208.49.228.0 0.0.0.255 any deny ip 208.184.216.0 0.0.0.255 any deny ip 208.49.239.240 0.0.0.15 any deny ip 208.178.175.128 0.0.0.7 any deny ip 208.178.163.56 0.0.0.7 any ! ! Other MP3 ! deny ip 202.36.148.5 0.0.0.255 any deny ip 202.36.147.16 0.0.0.255 any Shawn McMahon wrote:
At 11:09 PM 3/6/2000 -0500, you wrote:
Is there an updated list of ports used by Napster and various games (Doom, Unreal, etc)? At this point we're just collecting data points and not actively filtering anything, but of course the IANA port number list is sadly out of date with regard to these tools.
If you're intending to filter at some point, then who cares what the ports are?
Filter the ports that are using too much traffic on your network. If Napster/Doom/whatever isn't using too much bandwidth, blow it off.
There's a very big difference between filtering to correct a problem, and prior restraint.
At Tuesday 09:48 AM 3/7/00 , Scott McGrath wrote:
When you have limited bandwidth you need to ensure that it is used for what it is purchased for (email access to network based resources etc) and also as Napster moves MP3's you need to ensure that your facilities are not used for infringement on other's intellectualproperty so that you and your organization are not sued by rapacious lawyers unfortunate but there it is here is a short list in ACL format of Napster and other MP3 servers.
"need to ensure" ? By doing so, you forfeit your liability exception as a carrier - the "Prodigy defense". Next thing you know, the US Attorney is on your doormat with a demand to block this tiny list of 756 disparate /26's that are known to harbor overseas gambling sites. 5 minutes later, RIAA lawyers are coming in with a list of 2759 'uncooperative' (in their opinion, as far as music intellectual property protection is concerned) overseas networks they'd like blocked - or their lawyers will threaten your lawyers. Quickly, your ACL or 'null0' routing table grows to the size of the entire Internet. Your router will melt. It's the end of the Internet. Denial of knowledge of "rampant" illegal acts - except maybe those that cripple your own infrastructure :) - is the only solution: How else could cops stand the thought of knowing that everyone is driving 15 mph over the posted speed limit, and they can only catch one in a hundred speeders :) In the face of your own network melting, your actions should be limited to preventing such a meltdown only. No more. Rule #1 for bandwidth: "Bandwidth expands to fit the waste available" (Voidmstr's law) QoS that is adaptive to bandwidth consumption is the real solution for this many-to-many traffic problem. Because many-to-many filtering just won't work, not even at the edge of the network. bye,Kai
On Tue, 7 Mar 2000, Scott McGrath wrote:
! ! Other MP3 ! deny ip 202.36.148.5 0.0.0.255 any deny ip 202.36.147.16 0.0.0.255 any
In case people didn't notice these networks are used by ORBS (see www.orbs.org) and people associated it with it. Perhaps some may wish to block them but it's a little pathetic for Scott to try and sneak them into other people's access lists in this way. -- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz System/Network Admin. | T&C Enforcement | Home: simon@darkmere.gen.nz Ihug Limited, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
I am a corporate end user so the common carrier exception does not apply to me and the intellectual property demon does. re: ORBS I got those addresses from my traffic analyis on where the MP3 traffic was coming from and I apologize to the list and it's members for not checking who the block belongs to. I have no desire to add fuel to the ORBS controversy. Internet access has become critical to many business processes and we need to come up with mechanism to allow traffic like MP3 to fill slack in our networks however in my case I need to ensure that bandwith is available for the purpose for which it is purchased for. If Napster and it's ilk were well written applications I could create custom queues for it and discard when necessary like I do for non business related web traffic rather than my current heavy handed ACL's If anyone on the list has a alternate method I would appreciate hearing about it and my users would love me for giving them back access to Napster and other music sites. Apologetically - Scott Simon Lyall wrote:
On Tue, 7 Mar 2000, Scott McGrath wrote:
! ! Other MP3 ! deny ip 202.36.148.5 0.0.0.255 any deny ip 202.36.147.16 0.0.0.255 any
In case people didn't notice these networks are used by ORBS (see www.orbs.org) and people associated it with it. Perhaps some may wish to block them but it's a little pathetic for Scott to try and sneak them into other people's access lists in this way.
-- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz System/Network Admin. | T&C Enforcement | Home: simon@darkmere.gen.nz Ihug Limited, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
What would be your suggestions on making Napster a more network friendly app? Certainly it would be easier to queue it if it only used one port for client->client transfer, but the problem is that there's no way to know if that port would be in use. Also, for people behind firewalls you need to tunnel in sometimes (of course, that works only a small portion of the time). I don't know what the numbers look like, but it may be the case that just queueing up the default data port would catch some large percentage of the Napster file transfering. Anyway, if there are constructive suggestions, we're all ears. -Michael On Tue, Mar 07, 2000 at 11:48:25AM -0500, Scott McGrath wrote: --snip--
for which it is purchased for. If Napster and it's ilk were well written applications I could create custom queues for it and discard when necessary like I do for non business related web traffic rather than my current heavy handed ACL's If anyone on the list has a alternate method I would appreciate hearing about it and my users would love me for giving them back access to Napster and other music sites.
Apologetically - Scott --snip--
-- Michael Ridley <michael@napster.com>
One of the big problems from my standpoint is that I know of no well known data port that I can queue for for web traffic from other than authorized sites I use a low priority queue which during busy times drops packets but when the usage is low all web traffic flows smoothly. Another way would be to tag the Napster frames with QoS information so that Napster usage could be controlled with QoS policies. I really DO NOT WANT to prohibit access to Napster but I do NEED to deliver the critical services first and "fill up the corners" with entertainment services which make our end-users happy. Michael Ridley wrote:
What would be your suggestions on making Napster a more network friendly app? Certainly it would be easier to queue it if it only used one port for client->client transfer, but the problem is that there's no way to know if that port would be in use. Also, for people behind firewalls you need to tunnel in sometimes (of course, that works only a small portion of the time). I don't know what the numbers look like, but it may be the case that just queueing up the default data port would catch some large percentage of the Napster file transfering.
Anyway, if there are constructive suggestions, we're all ears.
-Michael
On Tue, Mar 07, 2000 at 11:48:25AM -0500, Scott McGrath wrote: --snip--
for which it is purchased for. If Napster and it's ilk were well written applications I could create custom queues for it and discard when necessary like I do for non business related web traffic rather than my current heavy handed ACL's If anyone on the list has a alternate method I would appreciate hearing about it and my users would love me for giving them back access to Napster and other music sites.
Apologetically - Scott --snip--
-- Michael Ridley <michael@napster.com>
Scott McGrath wrote:
I could create custom queues for it and discard when necessary like I do for non business related web traffic rather than my current heavy handed ACL's If anyone on the list has a alternate method I would appreciate hearing about it and my users would love me for giving them back access to Napster and other music sites.
I've been thinking and talking about this a lot with some of my peers in the University environment the last couple of weeks. Like yourself, I am trying to come up with a fairness policy and implementation based on technical limitations of IP and our network equipment. Some of the most important thoughts/conclusions I have had are as follows: Avoid mucking with TCP and end-to-end transparency as much as possible. Let IP and RFC 2581 do its job. Managing by UDP/TCP port is unreliable. All it takes is for someone to change configuration, find the next killer app or even more fun, implement some type of "port hopping" mechanism. I'm just waiting for this to happen. Using ToS fields *seems* to be the right approach to provide *some* of what we want. Coupled with something like WRED in our Cisco routers at the our Internet border. More sophisticated QoS mechanisms than that seems to be an effort in futility. KISS. I'm thinking a simple low priority, high priority ToS setting for packets that are either within or outside of the local definition of fair. For example, I like the idea where all packets exceeding an average rate of X bps get tagged low priority and dropped by WRED as necessary. Be prepared to find that by using ToS bits, you break something (see http://micro.uoregon.edu/macintosh/mactcp.html). You might be able to influence what comes into your network from the outside through these mechanisms, but you can't control them. You also can't count on any service guarantees past your administrative control. A few more good reasons to avoid anything overly complex. It is often easier and cheaper to just add bandwidth than trying to tweak utilization and apply QoS throughout your network. I'm having a hard time applying this fairness concept down to the user port level, if anyone has any thoughts or feedback, I'd appreciate it if you contact me (and also see my post in the unisog list). John
At 09:48 AM 3/7/2000 -0500, you wrote:
When you have limited bandwidth you need to ensure that it is used for what it is purchased for (email access to network based resources etc) and also as Napster moves MP3's you need to ensure that your facilities are not used for infringement on other's intellectualproperty so that you and your organization are not sued by rapacious lawyers unfortunate but there it is here is a short list in ACL format of Napster and other MP3 servers.
It is not possible to do either, and by undertaking to do so you open yourself up to legal liabilities that otherwise wouldn't exist. On the other hand, if you block things that are consuming excessive bandwidth, you're in good shape.
As a member of the dreaded 'Corporate America' and a end user I need to block it for now because of 1 excessive b/w usage. 2. "Mr J. Random Engineer did you knowingly allow a service to enter your premises which allowed my clients intellectual property to be infringed yes or no?" We need a system which allows "internet radio" for legitimate content and allows us to control bandwidth usage on end-user networks. The common carriers have an entirely different set of needs and to keep their common carrier exemption they cannot do anything about "excessive traffic" besides if your customers want more of your product (bandwidth) more power to them assuming of course that you have a method to charge for it! Shawn McMahon wrote:
At 09:48 AM 3/7/2000 -0500, you wrote:
When you have limited bandwidth you need to ensure that it is used for what it is purchased for (email access to network based resources etc) and also as Napster moves MP3's you need to ensure that your facilities are not used for infringement on other's intellectualproperty so that you and your organization are not sued by rapacious lawyers unfortunate but there it is here is a short list in ACL format of Napster and other MP3 servers.
It is not possible to do either, and by undertaking to do so you open yourself up to legal liabilities that otherwise wouldn't exist.
On the other hand, if you block things that are consuming excessive bandwidth, you're in good shape.
participants (10)
-
Bill Woodcock -
Henry R. Linneweh -
Jeff Kell -
John Kristoff -
Joshua Goodall -
Kai Schlichting -
Michael Ridley -
Scott McGrath -
Shawn McMahon -
Simon Lyall