Re: FW: Re: Is there a line of defense against Distributed Reflective attacks?
At 09:29 PM 1/17/2003, Christopher L. Morrow wrote:
On Fri, 17 Jan 2003, Stewart, William C (Bill), RTLSL wrote:
-----Original Message----- From: Stewart, William C (Bill), RTLSL Sent: Friday, January 17, 2003 5:35 PM To: 'nanog-post@trapdoor.merit.edu' Subject: Re: Is there a line of defense against Distributed Reflective attacks?
Many of these attacks can be mitigated by ISPs that do anti-spoofing filtering on input - only accepting packets from user ports
Sure, but this is a proven non-scalable solution. HOWEVER, filtering as close to the end host is scalable and feasible... do it there, it makes MUCH more sense to do it there.
Well, let's see... on dialup circuits it should be done and should be a no-brainer. After all, ISPs are required (by UUNet at least) to push in filters to ensure dialup users can only reach port 25 of that ISPs mail servers and be blocked from all other spots. How hard is it to push in one more filter that checks the source IP address of the dialup user to ensure the address coming from the user is the one assigned? Sure, dialups are not the only problem, but it's an example of blocking close (very close) to the edge. Each time an ISP sells a T1 with a router and assigns a block of addresses, there's an opportunity to configure that router with filters (ingress/egress depending on which side you look at it from) and at least simple firewalling rules. Is this an expense to the installing ISP, or a cost savings in not having to deal with attacks that came from that network later? Even when a customer provides the CPE, providing sample configurations really costs little and would help. In many cases, the vendor supplying that T1 is one of the same companies which also handles the "core" so it's REALLY in their best interest to take little steps to protect their edges (hard to point fingers from the core and say "it's the edge vendor's problem" when you're also the edge vendor in some cases). While it's nice that router vendors implemented unicast RPF to make configuration in some cases easier, using simple ACLs isn't necessarily hard at the edges either. The stumbling block for ingress filtering has always been pretty simple: By implementing ingress, the network you save will be someone else's. You have to trust that other network operators will implement ingress filtering and in so doing save your network. Sadly, folks tend to avoid doing things that might help others, and so I continue to wait for a negligence lawsuit to wake folks up on this issue. Eliminating spoofed addresses from the backbone, even if it were possible to do 100%, would not eliminate denial of service attacks. The DDoS attacks using coordinated "owned" machines demonstrates this. As spoofing becomes more difficult, tracing back the source of attacks becomes easier. Network operators will still find machines on their networks performing attacks, but when that phone call comes from another network with attack details, the chances of finding the offending host are much greater.
On Sat, Jan 18, 2003 at 08:58:13AM -0500, Daniel Senie wrote:
While it's nice that router vendors implemented unicast RPF to make configuration in some cases easier, using simple ACLs isn't necessarily hard at the edges either.
It might be nice if all router vendors were able to associate the interface configured address(es)/nets as a variable for ingress filters. So for in the Cisco world, a simple example would be: interface Serial0 ip address 192.0.2.1 255.255.255.128 ip access-group 100 in ! interface Serial1 ip address 192.0.2.129 255.255.255.128 ip access-group 100 in ! access-list 100 permit ip $interface-routes any access-list 100 deny ip any any Those sorts of features could make the scaling issue much easier for large providers and environments where routers may have lots of interfaces. An operator could also essentially build tools to automatically configure/verify configurations this way, but I think it would be better for the router vendors to do this for us. John
Once upon a time, John Kristoff <jtk@aharp.is-net.depaul.edu> said:
It might be nice if all router vendors were able to associate the interface configured address(es)/nets as a variable for ingress filters. So for in the Cisco world, a simple example would be:
interface Serial0 ip address 192.0.2.1 255.255.255.128 ip access-group 100 in ! interface Serial1 ip address 192.0.2.129 255.255.255.128 ip access-group 100 in ! access-list 100 permit ip $interface-routes any access-list 100 deny ip any any
How is this different than "ip verify unicast reverse-path" (modulo CEF problems and bugs, which of course NEVER happen :-) )? Multihomed customers are more interesting, but if all the single homed customers had uRPF (or $VENDOR's equivalent) enabled it would cut down on a significant amount of the spoofed traffic. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Everyone probably knows... But if not -- just a reminder that you can also add access-list number after 'ip verify unicast reverse-path' to allow any hosts you think that should be able to get allowed through the filter :-) It's convenient when you are doing some mobileIP+vpn stuff in which some type of setup breaks when there is egress filtering. Multihomed customers should use uRPF at their Ethernet/local interface as egress filter... Using uRPF as ingress filter at ISP connections (such as Serial3/0, Pos2/0, whatever connects to your ISP's) when you are doing BGP can be quite a nightmare.. :-D So I guess they would have to use plain-old manual access-list at their ISP-connection interfaces for ingress filtering. i.e.. ! int Gig2/0 des backbone connection, egress ip add 192.0.2.21 255.255.255.252 ip ver unicas reverse-path 180 ! int Pos3/0 des OC-3 from XXX ISP, ingress ip add 199.99.99.99 255.255.255.252 ip access 101 i ! ! acc 101 remark plain-old regular ingress filter for multihomed networks acc 101 den ip $my_network an acc 101 den ip 10.0.0.0 0.255.255.255 an acc 101 den ip 172.16.0.0 0.15.255.255 an acc 101 den ip 192.168.0.0 0.0.255.255 an acc 101 per ip an an acc 180 remark exceptions to egress filtering acc 180 per ip host 199.59.9.110 an ! ! -hc Chris Adams wrote:
Once upon a time, John Kristoff <jtk@aharp.is-net.depaul.edu> said:
It might be nice if all router vendors were able to associate the interface configured address(es)/nets as a variable for ingress filters. So for in the Cisco world, a simple example would be:
interface Serial0 ip address 192.0.2.1 255.255.255.128 ip access-group 100 in ! interface Serial1 ip address 192.0.2.129 255.255.255.128 ip access-group 100 in ! access-list 100 permit ip $interface-routes any access-list 100 deny ip any any
How is this different than "ip verify unicast reverse-path" (modulo CEF problems and bugs, which of course NEVER happen :-) )?
Multihomed customers are more interesting, but if all the single homed customers had uRPF (or $VENDOR's equivalent) enabled it would cut down on a significant amount of the spoofed traffic.
On Sat, Jan 18, 2003 at 10:45:11PM -0600, Chris Adams wrote:
How is this different than "ip verify unicast reverse-path" (modulo CEF problems and bugs, which of course NEVER happen :-) )?
It would be useful for all sorts of things besides verifying a source address. So in addition to complicated configurations such as multi- homing/paths that you mention, it could also be useful for standard filters on protocols, ports, logging and so on. John
On Sat, 18 Jan 2003, Daniel Senie wrote:
At 09:29 PM 1/17/2003, Christopher L. Morrow wrote:
On Fri, 17 Jan 2003, Stewart, William C (Bill), RTLSL wrote:
-----Original Message----- From: Stewart, William C (Bill), RTLSL Sent: Friday, January 17, 2003 5:35 PM To: 'nanog-post@trapdoor.merit.edu' Subject: Re: Is there a line of defense against Distributed Reflective attacks?
Many of these attacks can be mitigated by ISPs that do anti-spoofing filtering on input - only accepting packets from user ports
Sure, but this is a proven non-scalable solution. HOWEVER, filtering as close to the end host is scalable and feasible... do it there, it makes MUCH more sense to do it there.
Well, let's see... on dialup circuits it should be done and should be a no-brainer. After all, ISPs are required (by UUNet at least) to push in filters to ensure dialup users can only reach port 25 of that ISPs mail servers and be blocked from all other spots. How hard is it to push in one more filter that checks the source IP address of the dialup user to ensure the address coming from the user is the one assigned?
Sure, dialups are a fixable problem, and mostly they are fixed... and.... most dialups are platforms that can't readily spoof so the threat level is low. I'd point out one thing though, for larger dial platform providers the decision to put filters on the radius users isn't under their direct control... They may mandate to the people that lease the service from them the requirement for radius profile filters, but the implementation is solely up to the leasee. Most times its also not implemented until the next contract cycle ;( Anyway, you are correct, this is a fairly easy win, provided the dial platform can support the filtering on hundreds of ppp connections. (I don't have any good or bad data on this so I know not the scaling issues here)
Sure, dialups are not the only problem, but it's an example of blocking close (very close) to the edge.
Each time an ISP sells a T1 with a router and assigns a block of addresses, there's an opportunity to configure that router with filters (ingress/egress depending on which side you look at it from) and at least simple firewalling rules. Is this an expense to the installing ISP, or a cost savings in not having to deal with attacks that came from that network
This is certainly true, UUNET has been doing this for some time now... (+1.5 years I believe?) Unfortunately, many of the larger providers only manage a small number of their customer's CPE, this means the config is subject to change immediately on arrival at customer site :( I'd note that UUNET also went through some pain to push CPE configs with 'good' passwds for telnet and enable, now there are tens (perhaps hundreds) of CPE routers with 'cisco' as the vty passwd... Don't customers' care about security? This is the issue, there aren't enough people with 'constant vigilance' about security, Convenience is always more important :( Never mind that their CPE device is now being used to DoS several hosts on the internet and their link charges are showing that each month... that cost isn't enough for them to change their ways.
later? Even when a customer provides the CPE, providing sample configurations really costs little and would help. In many cases, the vendor supplying that T1 is one of the same companies which also handles the "core" so it's REALLY in their best interest to take little steps to protect their edges (hard to point fingers from the core and say "it's the edge vendor's problem" when you're also the edge vendor in some cases).
Ok, so here we get to the meat of my arguement. The end user needs to filter, they know best what/where/how their network is used. The 'core' provider simply knows that there are 6 /24's and a /23 routed to the T1 in question. The filtering can be MUCH more effective at the end user site, where each ether interface can include a simple 1 line acl that fixes the problems of spoofing. There was some chatter at NANOG in Oregon last October about some 'default' settings on interfaces for 'small' routers that would accomplish this task. I believe it was 'turn on uRPF strict for all small platform routers' and make it a simple 'no uRPF' to turn it off. Barry Greene or the other Cisco fellow in the back of the room should recall more precisely, eh? This seems like a great first step, keeping in mind that its a year or more to roll that out, atleast its a start :)
While it's nice that router vendors implemented unicast RPF to make configuration in some cases easier, using simple ACLs isn't necessarily hard at the edges either.
This completely depends on the part of the edge you run... ask Ebay how it is to filter on their Gig ports facing their servers, or Microsoft on their 10Gig interfaces... acls suck when packet rates increase, uRPF is a win here since it is just a FIB lookup, not a acl processing task. (Yes, 10Gig ints likely have acls in asics, but point is fib lookups win.)
The stumbling block for ingress filtering has always been pretty simple: By implementing ingress, the network you save will be someone else's. You have to trust that other network operators will implement ingress filtering and in so doing save your network. Sadly, folks tend to avoid doing things that might help others, and so I continue to wait for a negligence lawsuit to wake folks up on this issue.
Actually, the stumbling block has been getting end users to do it... the core is just not the place to do this, too complex to do and not enough granularity at that level.
Eliminating spoofed addresses from the backbone, even if it were possible to do 100%, would not eliminate denial of service attacks. The DDoS attacks
This was precisely the point of Mr. Gill from AOL at the aforementioned NANOG meeting, I believe his quote goes something like: "The ip address used for the attack is orthogonal to the problem..." To me this makes perfect sense... People really do get stuck on the red herring of 'stopping all spoofing'. That isn't the problem, as you say below here its trivial to use owned hosts by the thousands to attack with unspoofed addresses... Rob Thomas has some good data on attacks against IRC servers and other hosts on the internet, his data last I recall was something like 80% of attacks use spoofed addresses, though more and more his tracked attacks are showing from non-spoofed hosts. He can certainly jump in and correct me though :) I can speak authoritatively from the network I work on's perspective on this issue, more and more we have seen non-spoofed attacks. There are still plenty of spoofed attacks, but frankly we prefer that as its MUCH easier to track and stop. For those that wonder 'how would you track that? It's spoofed!' please visit: http://www.secsup.org and read the provided links... its simple, free, proven, tested and used everyday by atleast UUNET and I believe Sprint? If you have an upstream you should push them to implement these things also so you can be protected and get resolution faster... or like I said, switch to a provider that DOES these things and HAS a security crew on staff 24/7. Its in your best interest if you think you might be a target.
using coordinated "owned" machines demonstrates this. As spoofing becomes more difficult, tracing back the source of attacks becomes easier. Network operators will still find machines on their networks performing attacks, but when that phone call comes from another network with attack details, the chances of finding the offending host are much greater.
Hi, NANOGers. You just knew I couldn't stay out of this thread for long. ;) ] I'd note that UUNET also went through some pain to push CPE configs with ] 'good' passwds for telnet and enable, now there are tens (perhaps ] hundreds) of CPE routers with 'cisco' as the vty passwd... Don't During the year 2002 I added at least 17683 compromised Cisco routers to my hacked device database. One bot included a list of 2827 compromised Cisco routers for use as bounces. Most of these are CPE routers, not ISP-managed routers. All of them had cisco/cisco as the login and password. This isn't limited to Cisco routers, however. I collected an impressive list of broadband and other vendor routers as well, for a total of just over 30K compromised routers in 2002. As Chris points out, this is an issue that requires vigilance beyond teams at ISPs. ] addresses... Rob Thomas has some good data on attacks against IRC ] servers and other hosts on the internet, his data last I recall was ] something like 80% of attacks use spoofed addresses, though more and more In 2002 I logged several thousand DDoS attacks. Approximately 70% used bogon source addresses or spoofing, but that trend was changing by the end of the year. In 2003 I have logged approximately 267 DDoS attacks, NONE of which used spoofing. Does anti-spoofing help? Absolutely! Is it a cure-all? No. The combination of very large (circa 94K) botnets and DoSnets and the failure of many providers to respond to abuse alerts means that the miscreants don't generally need to spoof. A study I performed of an often-attacked site showed that a bit over 60% of all the naughty packets were from _obvious_ bogon addresses. The total amount of spoofing is difficult to deduce. You can view the data included in a presentation here: http://www.cymru.com/Presentations/60Days.ppt http://www.cymru.com/Presentations/60Days.zip Blocking spoofing and bogons (remember, uRPF works best if the RIB is free from garbage) is worth the time. Building a strong and motivated security team is even more valuable. :) ] For those that wonder 'how would you track that? It's spoofed!' please ] visit: http://www.secsup.org and read the provided links... its simple, This is an excellent resource, and I encourage everyone to review it. Tracking spoofed-source attacks is far easier than you may believe. I have a lesser and rather lame method here: http://www.cymru.com/Documents/tracking-spoofed.html The method from UUNET is far superior. :) The point is that spoofed source packets can be tracked. All that aside, the method and ease of tracking makes no difference if the source of pain is unwilling or unable to respond. I'm certain everyone now realizes that Internet security is all about "The Other Guy." Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
On Sat, 18 Jan 2003, Christopher L. Morrow wrote:
Eliminating spoofed addresses from the backbone, even if it were possible to do 100%, would not eliminate denial of service attacks. The DDoS attacks
This was precisely the point of Mr. Gill from AOL at the aforementioned NANOG meeting, I believe his quote goes something like: "The ip address used for the attack is orthogonal to the problem..." To me this makes perfect sense... People really do get stuck on the red herring of 'stopping all spoofing'. That isn't the problem, as you say below here its trivial to use owned hosts by the thousands to attack with unspoofed addresses... Rob Thomas has some good data on attacks against IRC servers and other hosts on the internet, his data last I recall was something like 80% of attacks use spoofed addresses, though more and more his tracked attacks are showing from non-spoofed hosts. He can certainly jump in and correct me though :) I can speak authoritatively from the network I work on's perspective on this issue, more and more we have seen non-spoofed attacks. There are still plenty of spoofed attacks, but frankly we prefer that as its MUCH easier to track and stop.
you could partly get around this by blocking all 'SYN' packets going to your customers :-) Unless/until the kiddies start using UDP... messy.
On Sat, 18 Jan 2003, Avleen Vig wrote:
On Sat, 18 Jan 2003, Christopher L. Morrow wrote:
Eliminating spoofed addresses from the backbone, even if it were possible to do 100%, would not eliminate denial of service attacks. The DDoS attacks
This was precisely the point of Mr. Gill from AOL at the aforementioned NANOG meeting, I believe his quote goes something like: "The ip address used for the attack is orthogonal to the problem..." To me this makes perfect sense... People really do get stuck on the red herring of 'stopping all spoofing'. That isn't the problem, as you say below here its trivial to use owned hosts by the thousands to attack with unspoofed addresses... Rob Thomas has some good data on attacks against IRC servers and other hosts on the internet, his data last I recall was something like 80% of attacks use spoofed addresses, though more and more his tracked attacks are showing from non-spoofed hosts. He can certainly jump in and correct me though :) I can speak authoritatively from the network I work on's perspective on this issue, more and more we have seen non-spoofed attacks. There are still plenty of spoofed attacks, but frankly we prefer that as its MUCH easier to track and stop.
you could partly get around this by blocking all 'SYN' packets going to your customers :-)
and we are hoping none are hosting webservers or mail servers or.... right? Oh wait! I'll just make them use my datacenters, right?? or were you not talking about the attacks?
Unless/until the kiddies start using UDP... messy.
On Sun, 19 Jan 2003, Christopher L. Morrow wrote:
you could partly get around this by blocking all 'SYN' packets going to your customers :-)
and we are hoping none are hosting webservers or mail servers or.... right? Oh wait! I'll just make them use my datacenters, right?? or were you not talking about the attacks?
I was refering specifically to end user workstations. For example home machines on dial up or broadband connections. A lot of broadband providers already prohibit running servers and block certain inbound ports (eg 21 and 80). *shrug* just seems like it would make more sense to block all incoming 'syn' packets. Wouldn't that be faster than inspecting the destination port against two seperate rules? I don't know how these operators do their blocking..
*shrug* just seems like it would make more sense to block all incoming 'syn' packets. Wouldn't that be faster than inspecting the destination port against two seperate rules?
blocking all SYN's will break too much other stuff (Instant Messangers, games ...). I think we would be much better off if they (consumer ISPs) would block 135-139 and 445, maybe 21 and 80. The rest could be handled with a simple IDS (doesn't even need to match patterns... just count packets going to 27374 and the like) I keep saying ISPs would be much better off if they implement these filters. But not all of them agree. IMHO: less 'zombies' -> better service -> less support phonecalls. -- -------------------------------------------------------------------- jullrich@euclidian.com Collaborative Intrusion Detection join http://www.dshield.org
Hi, NANOGers. ] The rest could be handled with a simple IDS (doesn't even need ] to match patterns... just count packets going to 27374 and the like) There is no "simple IDS" for OC48+ links. :) Counters are possible, though adding that many ACLs can be more than burdensome on certain code and hardware releases. Don't even mention logging. :/ While some ports are more obvious than others, there is still the question of what is in the payload of a packet that increments a counter. It may be quite benign, e.g. a SYN packet to port 80 from source port 27374. At the edge some of these things are quite possible. At aggregation and transit points, however, such suggestions don't scale. ] I keep saying ISPs would be much better off if they implement these ] filters. But not all of them agree. IMHO: less 'zombies' -> better ] service -> less support phonecalls. I agree. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
On Sun, 19 Jan 2003, Avleen Vig wrote:
On Sun, 19 Jan 2003, Christopher L. Morrow wrote:
you could partly get around this by blocking all 'SYN' packets going to your customers :-)
and we are hoping none are hosting webservers or mail servers or.... right? Oh wait! I'll just make them use my datacenters, right?? or were you not talking about the attacks?
I was refering specifically to end user workstations. For example home machines on dial up or broadband connections. A lot of broadband providers already prohibit running servers and block certain inbound ports (eg 21 and 80). *shrug* just seems like it would make more sense to block all incoming 'syn' packets.
Doesn't this stop kazaa/morpheus/gnutella/FTP/<some aim stuff like private chats>? This is a problematic setup, and woudl require the cable modem provider to maintain a quickly changing 'firewall' :( I understand the want to do it, but I'm not sure its practical to see it happen based solely on the hassle factor :( Hmm, security, "you gotta pay to play" (Some famous man once said that I believe)
Wouldn't that be faster than inspecting the destination port against two seperate rules?
I don't know how these operators do their blocking..
On Mon, 20 Jan 2003, Christopher L. Morrow wrote:
I was refering specifically to end user workstations. For example home machines on dial up or broadband connections. A lot of broadband providers already prohibit running servers and block certain inbound ports (eg 21 and 80). *shrug* just seems like it would make more sense to block all incoming 'syn' packets.
Doesn't this stop kazaa/morpheus/gnutella/FTP/<some aim stuff like private chats>? This is a problematic setup, and woudl require the cable modem provider to maintain a quickly changing 'firewall' :( I understand the want to do it, but I'm not sure its practical to see it happen based solely on the hassle factor :( Hmm, security, "you gotta pay to play" (Some famous man once said that I believe)
Indeed it does break that. P2P clients: Mostly transfer illegal content. As much as a lot of people love using these, I'm sure most realise they're on borrowed time in their current state. And I'm sure that if they were gone tomorrow, I'm sure they'd be back in another fashion soon. Ftp/HTTP etc I believe most cable providers currently block these anyway :-) There's a chance it'd break things like file transfers on IM clients but I'm sure they'd be altered too.
Stoned koalas drooled eucalyptus spit in awe as Avleen Vig exclaimed:
Doesn't this stop kazaa/morpheus/gnutella/FTP/<some aim stuff like private chats>? This is a problematic setup, and woudl require the cable modem provider to maintain a quickly changing 'firewall' :( I understand the want to do it, but I'm not sure its practical to see it happen based solely on the hassle factor :( Hmm, security, "you gotta pay to play" (Some famous man once said that I believe)
Indeed it does break that. P2P clients: Mostly transfer illegal content. As much as a lot of people love using these, I'm sure most realise they're on borrowed time in their current state.
And it's your job as a network provider to determine the legality of your users' activities? Plus, you said the magic word "mostly" What about legit uses of P2P networks? Do you also stop your users from using NNTP as well, since it's "mostly" used for porn and warez? How about email? since, from the looks of my mail logs, SMTP traffic is "mostly" spam and sircam. :) I'm sure your users would certainly pack up and take their business elsewhere if you placed these restrictions on them. Why not just put them all behind a firewall on RFC-1918 addresses, if you are going to block all incoming SYNs?
And I'm sure that if they were gone tomorrow, I'm sure they'd be back in another fashion soon.
Any true P2P system is going to need at least one end user to receive a SYN.
Ftp/HTTP etc I believe most cable providers currently block these anyway
I also believe this is usually stated in their TOS that they're not allowed to run services on their home computers. If I'm on IRC and I initiate an outgoing DCC chat, the open port on my box awaiting the connection is hardly a "service."
There's a chance it'd break things like file transfers on IM clients but I'm sure they'd be altered too.
Unless I'm missing something, wouldn't it be necessary to modify both the clients and the servers to pass all FT traffic through the servers? I'm sure those who sell bandwidth to AOL and Yahoo would love it if they did that, but I don't see it happening. -Jeff -- Jeff Workman | jworkman@pimpworks.org | http://www.pimpworks.org
On Mon, 20 Jan 2003, Avleen Vig wrote:
Doesn't this stop kazaa/morpheus/gnutella/FTP/<some aim stuff like private chats>? This is a problematic setup, and woudl require the cable modem provider to maintain a quickly changing 'firewall' :( I understand the want to do it, but I'm not sure its practical to see it happen based solely on the hassle factor :( Hmm, security, "you gotta pay to play" (Some famous man once said that I believe)
Indeed it does break that. P2P clients: Mostly transfer illegal content. As much as a lot of people love using these, I'm sure most realise they're on borrowed time in their current state. And I'm sure that if they were gone tomorrow, I'm sure they'd be back in another fashion soon.
That may be, but its still a problem... I believe http and ftp also transfer illegal content, should we shut them down? Email too? Often there is illegal content in email. :(
Ftp/HTTP etc I believe most cable providers currently block these anyway :-)
for FTP I was talking about non-passive data traffic.
On Tue, 21 Jan 2003, Christopher L. Morrow wrote:
Indeed it does break that. P2P clients: Mostly transfer illegal content. As much as a lot of people love using these, I'm sure most realise they're on borrowed time in their current state. And I'm sure that if they were gone tomorrow, I'm sure they'd be back in another fashion soon.
That may be, but its still a problem... I believe http and ftp also transfer illegal content, should we shut them down? Email too? Often there is illegal content in email. :(
Ok before this gets out of hand :-) I wasn't talking about ISP's policing their customers in any way. I was merely stating that the blocking of inbound SYN packets would put a dent in the number of usable zombie DoS clients while at th same time having the side effect of breaking other server-type software such as P2P clients. I also went on to state that if the functionality of such clients really did break as a result of this, the majority of people wouldn't have (too much) of a right to complain as the clients are (mostly) used for illegal traffic. Yes this would probably cause a large loss of business in *some* areas where multiple broadband providers are availible. In other places where a broadband monopoly exists, you would either see a switch to business level contracts or a slight dip in business or people just living with it. For the record I'm not in favour of ISP's (or anyone else for that matter) policing the internet.
And their are legal uses for p2p. I have a customer who works with some of these technologies for legal and approved file transfers like game publishing. ----- Original Message ----- From: "Christopher L. Morrow" <chris@UU.NET> To: "Avleen Vig" <lists-nanog@silverwraith.com> Cc: "Christopher L. Morrow" <chris@UU.NET>; "Daniel Senie" <dts@senie.com>; <nanog@trapdoor.merit.edu> Sent: Monday, January 20, 2003 5:22 PM Subject: Re: FW: Re: Is there a line of defense against Distributed Reflective attacks?
On Mon, 20 Jan 2003, Avleen Vig wrote:
Doesn't this stop kazaa/morpheus/gnutella/FTP/<some aim stuff like
chats>? This is a problematic setup, and woudl require the cable modem provider to maintain a quickly changing 'firewall' :( I understand the want to do it, but I'm not sure its practical to see it happen based solely on the hassle factor :( Hmm, security, "you gotta pay to play" (Some famous man once said that I believe)
Indeed it does break that. P2P clients: Mostly transfer illegal content. As much as a lot of people love using these, I'm sure most realise
private they're
on borrowed time in their current state. And I'm sure that if they were gone tomorrow, I'm sure they'd be back in another fashion soon.
That may be, but its still a problem... I believe http and ftp also transfer illegal content, should we shut them down? Email too? Often there is illegal content in email. :(
Ftp/HTTP etc I believe most cable providers currently block these anyway :-)
for FTP I was talking about non-passive data traffic.
On Mon, 20 Jan 2003, Avleen Vig wrote:
On Mon, 20 Jan 2003, Christopher L. Morrow wrote:
I was refering specifically to end user workstations. For example home machines on dial up or broadband connections. A lot of broadband providers already prohibit running servers and block certain inbound ports (eg 21 and 80). *shrug* just seems like it would make more sense to block all incoming 'syn' packets.
Indeed it does break that. P2P clients: Mostly transfer illegal content. As much as a lot of people love using these, I'm sure most realise they're on borrowed time in their current state.
Well, blocking TCP SYNs is not a way to block establishment of sessions between _cooperating_ hosts. Simply make a small hack in TCP stack to leave SYN flag clear, and use some other bit instead. To really block something you need an application proxy... and then there are always ways to subvert those. Elimination of covert channels is one of the hardest problems. In any case, no sane provider will restrict traffic only to applications which can be served by its proxies. Going further, the growing awareness of the importance of security will cause more and more legitimate apps to create totally indiscriminate encrypted traffic... and it is a good idea to routinely encrypt all traffic, to avoid revealing importance of particular communications. Leaving identity of applications (different port #s) in the clear is also a bad idea, security-wise. --vadim
VA> Date: Mon, 20 Jan 2003 19:59:08 -0800 (PST) VA> From: Vadim Antonov VA> Well, blocking TCP SYNs is not a way to block establishment VA> of sessions between _cooperating_ hosts. With cooperating hosts, anything goes. Hack up the IP stack, and have specially-crafted DNS queries carry the ISN. Or use GRE tunnels. Or have special ICMP Unreachable packets... Sort of reminds me of the "email me a file" substitute for FTP that was fairly popular years ago. VA> To really block something you need an application proxy... VA> and then there are always ways to subvert those. Elimination VA> of covert channels is one of the hardest problems. In any VA> case, no sane provider will restrict traffic only to VA> applications which can be served by its proxies. It would be nice if all protocols were proxy-friendly without requiring proxies. Of course, that does nothing for encrypted and steganographic traffic. Is elimination of covert channels even possible? I'd say not. One of the most useful protocols (SMTP) is virtually always proxied... rarely does anyone use end-to-end SMTP without any intervening MX. Allowing customer<-->* traffic vs. intercepting and/or logging is up to the provider. At least one then can have known flows to inspect, rather than wondering what the "push the button" vector is. Sadly, port perversion seems very common. I've added about a dozen different ports on my home Squid cache. Any attempts to demand full RFC compliance seem futile. It begins to sound like peering... are decisions made based on technical merit, or on not losing customers who whine because they demand to use a broken implementation? Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
Vadim - the instant someone sues a Provider for sexual harassment from their spam epidemic you will start to see things change. The reason that No-Sane provider will block these ports or services is because they have been listening to their Network Admins too long, and in fact the problem is that they are not sane providers. What they are, and this is pretty much true across the board, is people that just don't care what they do to earn a buck otherwise we would not have these problems, and this is especially true of those Network Operators that push all those billions of bytes of illicit SPAM and throw their hands up and say "What do you expect us to do" - well the answer is simple. I expect you folks to operate within the law and to cooperate in stopping people who use your services in violation of the laws. And if the providers out there don't like that - then they should find other businesses. Todd Glassey ----- Original Message ----- From: "Vadim Antonov" <avg@kotovnik.com> To: "Avleen Vig" <lists-nanog@silverwraith.com> Cc: <nanog@trapdoor.merit.edu> Sent: Monday, January 20, 2003 7:59 PM Subject: Re: FW: Re: Is there a line of defense against Distributed Reflective attacks?
On Mon, 20 Jan 2003, Avleen Vig wrote:
On Mon, 20 Jan 2003, Christopher L. Morrow wrote:
I was refering specifically to end user workstations. For example
machines on dial up or broadband connections. A lot of broadband providers already prohibit running servers and block certain inbound ports (eg 21 and 80). *shrug* just seems like it would make more sense to block all incoming 'syn' packets.
Indeed it does break that. P2P clients: Mostly transfer illegal content. As much as a lot of people love using these, I'm sure most realise
home they're
on borrowed time in their current state.
Well, blocking TCP SYNs is not a way to block establishment of sessions between _cooperating_ hosts.
Simply make a small hack in TCP stack to leave SYN flag clear, and use some other bit instead.
To really block something you need an application proxy... and then there are always ways to subvert those. Elimination of covert channels is one of the hardest problems. In any case, no sane provider will restrict traffic only to applications which can be served by its proxies.
Going further, the growing awareness of the importance of security will cause more and more legitimate apps to create totally indiscriminate encrypted traffic... and it is a good idea to routinely encrypt all traffic, to avoid revealing importance of particular communications. Leaving identity of applications (different port #s) in the clear is also a bad idea, security-wise.
--vadim
On Tue, 21 Jan 2003, todd glassey wrote:
Vadim - the instant someone sues a Provider for sexual harassment from their spam epidemic you will start to see things change. The reason that No-Sane provider will block these ports or services is because they have been listening to their Network Admins too long,
We were talking about P2P, not spam. P2P participants _want_ to talk to each other, unlike spammer and his victims. ISPs already agressively fight spammers by termninating their service completely - no port blocking or lawsuits are needed. Blocking ports is not going to prevent communication between parties which wish to communicate. And carriage of bits is about an order of magintude bigger economically than the whole entertaintment industry. RIAA already was stupid enough to make enemies of telcos (with that Verizon lawsut). The tech industry was bending themselves over to court Hollywood because the common wisdom was that the content is going to be what people will pay for. Wrong. Content-based dotcoms died, and people still pay for Internet connectivity, in ever-increasing numbers. And spend more and more time in front of computers instead of TVs. Simply because live people on the other end of the wire are infinitely more interesting than the prechewed corporate crud called "content". So I think we'll see some fireworks on the legal front, but the outcome is already clear - unfiltered connectivity is what consumers wish to pay for, not the sanitized disneys. --vadim
Vadim - the newest form of SPAM uses the Messenger facility to place a pop-up in the middle of your screen without any email, pop, smtp or other service being involved. I apologize for the tone of the first posting, but I still stand by it. When ISP's are held accountable for what people do with the BW they sell them, then these issues will all be moot. Until then, the lie is that there is no way to stop these behaviors and its the one the ISP's proffer exclusively. Todd ----- Original Message ----- From: "Vadim Antonov" <avg@kotovnik.com> To: "todd glassey" <todd.glassey@worldnet.att.net> Cc: <nanog@trapdoor.merit.edu> Sent: Tuesday, January 21, 2003 5:51 PM Subject: Re: FW: Re: Is there a line of defense against Distributed Reflective attacks?
On Tue, 21 Jan 2003, todd glassey wrote:
Vadim - the instant someone sues a Provider for sexual harassment from
their
spam epidemic you will start to see things change. The reason that No-Sane provider will block these ports or services is because they have been listening to their Network Admins too long,
We were talking about P2P, not spam. P2P participants _want_ to talk to each other, unlike spammer and his victims. ISPs already agressively fight spammers by termninating their service completely - no port blocking or lawsuits are needed.
Blocking ports is not going to prevent communication between parties which wish to communicate. And carriage of bits is about an order of magintude bigger economically than the whole entertaintment industry. RIAA already was stupid enough to make enemies of telcos (with that Verizon lawsut).
The tech industry was bending themselves over to court Hollywood because the common wisdom was that the content is going to be what people will pay for. Wrong. Content-based dotcoms died, and people still pay for Internet connectivity, in ever-increasing numbers. And spend more and more time in front of computers instead of TVs. Simply because live people on the other end of the wire are infinitely more interesting than the prechewed corporate crud called "content".
So I think we'll see some fireworks on the legal front, but the outcome is already clear - unfiltered connectivity is what consumers wish to pay for, not the sanitized disneys.
--vadim
On Tue, 21 Jan 2003, todd glassey wrote:
Vadim - the newest form of SPAM uses the Messenger facility to place a pop-up in the middle of your screen without any email, pop, smtp or other service being involved. I apologize for the tone of the first posting, but I still stand by it. When ISP's are held accountable for what people do with the BW they sell them, then these issues will all be moot. Until then, the lie is that there is no way to stop these behaviors and its the one the ISP's proffer exclusively.
No, we evil network admins are NOT saying there is no way to stop these behaviors. We're saying that the solutions put such a crimp on open standards and legitimate behavior that their value is negative. The problem is a social one, not a technical one. The technical problem is the vulnerability that exists; the social problem is that as long as ANY vulnerability exists, people will try to exploit that vulnerability. Technology can mitigate the vulnerabilities, but it cannot mitigate the desire to exploit. For instance, substitute "airport" for "network", as in "airport security". There are ways for law enforcement to be 100% positive that no terrorists ever steps foot on a plane. Unfortunately, the cost involved, along with the reduction in efficiency, would make normal travel impossible. Do you try to hold realestate developers responsible for what the homeowner does with their house? Do you try to hold the power company responsible for the people who use their electricity to grow weed? I assume you were beating down the doors of Congress, tyring to get rock artists to be responsible for the people who committed suicide after listening to their albums? Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
On Tue, 21 Jan 2003, todd glassey wrote:
Vadim - the newest form of SPAM uses the Messenger facility to place a pop-up in the middle of your screen without any email, pop, smtp or
other
service being involved. I apologize for the tone of the first posting, but I still stand by it. When ISP's are held accountable for what people do with the BW they sell them, then these issues will all be moot. Until then,
Andy - ----- Original Message ----- From: "Andy Dills" <andy@xecu.net> To: "todd glassey" <todd.glassey@worldnet.att.net> Cc: "Vadim Antonov" <avg@kotovnik.com>; <nanog@trapdoor.merit.edu> Sent: Wednesday, January 22, 2003 9:07 AM Subject: Re: FW: Re: Is there a line of defense against Distributed Reflective attacks? the
lie is that there is no way to stop these behaviors and its the one the ISP's proffer exclusively.
No, we evil network admins are NOT saying there is no way to stop these behaviors. We're saying that the solutions put such a crimp on open standards and legitimate behavior that their value is negative.
Who gave you the right to decide which laws you were going to abide by and which ones you were not?
The problem is a social one, not a technical one. The technical problem is the vulnerability that exists; the social problem is that as long as ANY vulnerability exists, people will try to exploit that vulnerability.
The reason that the vunerability is there is becuase of TCP/IP's inherent weaknesses, but that aside, there are processes that could easily be put in place to address these issues, the problem is that they cost money and that means they have to be paid for and ISP's like many other businesses are run to be as profitable as possible so that means that their owners will do as little as humanly possible to address these issues to keep the bottom lines where they are... Otherwise there wouldn't be the problems with SPAM and DDoS or other Attack Forms that exist today.
Technology can mitigate the vulnerabilities, but it cannot mitigate the desire to exploit.
So then the problem is the ISP's facilitating the evil forces of the world to do their worst???
For instance, substitute "airport" for "network", as in "airport security".
Well, this is really funny - see I used to do Network and Systems Operations for UAL at the SFO site and I think your commentary is so funny its almost ludicrous. The problems with the Airlines is the ALPA and its membership and the various other Unions that have a strangle hold on the carriers. You folks are not unionized are you?
There are ways for law enforcement to be 100% positive that no terrorists ever steps foot on a plane. Unfortunately, the cost involved, along with the reduction in efficiency, would make normal travel impossible.
The same is not true of networking though.
Do you try to hold realestate developers responsible for what the homeowner does with their house? Do you try to hold the power company responsible for the people who use their electricity to grow weed?
of course not - but I do hold the provider responsible for not enforcing the laws regarding digital fraud. And everytime one of your email servers passes a forged email along another hop in its trip, you actively participate in the fraud, so you are not the grower of the weed but rather the reseller of it.
I assume you were beating down the doors of Congress, tyring to get rock artists to be responsible for the people who committed suicide after listening to their albums?
Hardly, and Tipper and I disagree on many things.
Andy
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
Not to mention that fact that 99.99% of current consumer connections are not up to the task. Standard full-screen video digital stream is ~6Mbps, HDTV requires 19.4Mbps. Don't know many consumers with T3s. ;) As always, it gets down to doing the math, something may dot bombers weren't (aren't) very good at. AOL/Time Warner is just the first major example of this 'not yet ready for prime time' business plan. Not to mention the effect everyone on AOL going to broadband and downloading Disney clips all the time would have on their settlement plans with backbone providers. When fiber-to-the-curb is the norm we'll be able to 'Ride the Light' Until then, your mileage may vary. You might also see some change in settlement plans and consumer pricing about that same time. Best regards, ______________________________ Al Rowland
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Vadim Antonov Sent: Tuesday, January 21, 2003 5:51 PM To: todd glassey Cc: nanog@trapdoor.merit.edu Subject: Re: FW: Re: Is there a line of defense against Distributed Reflective attacks?
On Tue, 21 Jan 2003, todd glassey wrote:
Vadim - the instant someone sues a Provider for sexual harassment from their spam epidemic you will start to see things change. The reason that No-Sane provider will block these ports or services is because they have been listening to their Network Admins too long,
We were talking about P2P, not spam. P2P participants _want_ to talk to each other, unlike spammer and his victims. ISPs already agressively fight spammers by termninating their service completely - no port blocking or lawsuits are needed.
Blocking ports is not going to prevent communication between parties which wish to communicate. And carriage of bits is about an order of magintude bigger economically than the whole entertaintment industry. RIAA already was stupid enough to make enemies of telcos (with that Verizon lawsut).
The tech industry was bending themselves over to court Hollywood because the common wisdom was that the content is going to be what people will pay for. Wrong. Content-based dotcoms died, and people still pay for Internet connectivity, in ever-increasing numbers. And spend more and more time in front of computers instead of TVs. Simply because live people on the other end of the wire are infinitely more interesting than the prechewed corporate crud called "content".
So I think we'll see some fireworks on the legal front, but the outcome is already clear - unfiltered connectivity is what consumers wish to pay for, not the sanitized disneys.
--vadim
Al Rowland wrote:
Not to mention that fact that 99.99% of current consumer connections are not up to the task. Standard full-screen video digital stream is ~6Mbps, HDTV requires 19.4Mbps. Don't know many consumers with T3s. ;)
VDSL or ADSL2+ would cut it, until fiber to the curb gets the norm. However many school/university dorms and new housing developments are well networked already so high bandwidth consumer connectivity exists in large numbers. (where did you think the KaZaa supernodes and DirectConnect hubs are?) Pete
At 09:28 AM 1/22/2003 -0800, Al Rowland wrote:
Not to mention that fact that 99.99% of current consumer connections are not up to the task. Standard full-screen video digital stream is ~6Mbps, HDTV requires 19.4Mbps. Don't know many consumers with T3s. ;)
Drifting off-topic, but those are 'raw' data rates. Compression algorithms along with motion-estimation allow you to get full-screen video down to ~1.5 Mbps with not much in the way of image quality loss. That puts you into DSL/Wireless range.
As always, it gets down to doing the math, something may dot bombers weren't (aren't) very good at. AOL/Time Warner is just the first major example of this 'not yet ready for prime time' business plan. Not to mention the effect everyone on AOL going to broadband and downloading Disney clips all the time would have on their settlement plans with backbone providers.
When fiber-to-the-curb is the norm we'll be able to 'Ride the Light' Until then, your mileage may vary. You might also see some change in settlement plans and consumer pricing about that same time.
I think you'll see it long before every house has fiber run to it. My 2 cents anyway. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless! \ Director, Engineering | @ @ | \ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Wholesale Internet Services - http://www.megapop.net
speaking of HDSL over copper, does anyone know anything about a company called Rose Tekephone that reportedly has an HDTV over T1 service? ----- Original Message ----- From: "Chris Parker" <cparker@starnetusa.net> To: <nanog@trapdoor.merit.edu> Sent: Wednesday, January 22, 2003 1:02 PM Subject: RE: FW: Re: Is there a line of defense against Distributed Reflective attacks?
At 09:28 AM 1/22/2003 -0800, Al Rowland wrote:
Not to mention that fact that 99.99% of current consumer connections are not up to the task. Standard full-screen video digital stream is ~6Mbps, HDTV requires 19.4Mbps. Don't know many consumers with T3s. ;)
Drifting off-topic, but those are 'raw' data rates. Compression
algorithms
along with motion-estimation allow you to get full-screen video down to ~1.5 Mbps with not much in the way of image quality loss.
That puts you into DSL/Wireless range.
As always, it gets down to doing the math, something may dot bombers weren't (aren't) very good at. AOL/Time Warner is just the first major example of this 'not yet ready for prime time' business plan. Not to mention the effect everyone on AOL going to broadband and downloading Disney clips all the time would have on their settlement plans with backbone providers.
When fiber-to-the-curb is the norm we'll be able to 'Ride the Light' Until then, your mileage may vary. You might also see some change in settlement plans and consumer pricing about that same time.
I think you'll see it long before every house has fiber run to it.
My 2 cents anyway.
-Chris
-- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless! \ Director, Engineering | @ @ | \ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Wholesale Internet Services - http://www.megapop.net
1. I also remember when web page standards required you to design everything to fit in a 640x400 screen. DTV/HDTV will significantly change your 'not much in the way of image quality loss' yardstick. My viewing habits have changed significantly in the year plus I've been DTV/HDTV. Among other things, I go to the movies a lot less. DVD quality (which is lower than HDTV) is better than most movie theaters and there's no gum/spilled drink (most of the time) on my floor. 2. I already have it. It's called broadcast. $100 (could have been less but I always over design) antenna and $20 of coax. No monthly fee. I do pay for the DirecTV feed, but that's a separate flame war. Of course, you could just as easily be right. Best regards, ______________________________ Al Rowland
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Chris Parker Sent: Wednesday, January 22, 2003 10:02 AM To: nanog@trapdoor.merit.edu Subject: RE: FW: Re: Is there a line of defense against Distributed Reflective attacks?
At 09:28 AM 1/22/2003 -0800, Al Rowland wrote:
SNIP
Drifting off-topic, but those are 'raw' data rates. Compression algorithms along with motion-estimation allow you to get full-screen video down to ~1.5 Mbps with not much in the way of image quality loss.
SNIP
I think you'll see it long before every house has fiber run to it.
My 2 cents anyway.
-Chris
-- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless! \ Director, Engineering | @ @ | \ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-------------------------------------------- ---------- \ Wholesale Internet Services -
At 10:58 AM 1/22/2003 -0800, Al Rowland wrote:
1. I also remember when web page standards required you to design everything to fit in a 640x400 screen. DTV/HDTV will significantly change your 'not much in the way of image quality loss' yardstick. My viewing habits have changed significantly in the year plus I've been DTV/HDTV. Among other things, I go to the movies a lot less. DVD quality (which is lower than HDTV) is better than most movie theaters and there's no gum/spilled drink (most of the time) on my floor.
Agreed, however the source video that I've seen demoed is from DVD. Side by side comparison shows slight degradation, but solo viewing is more than adequate. This also isn't targetted to people at the end of the bell curve for technology adopters and purists, rather at the fat middle section that isn't upgrading to ( or doesn't care about ) HDTV yet and for whom current "digital video" quality is "just fine".
2. I already have it. It's called broadcast. $100 (could have been less but I always over design) antenna and $20 of coax. No monthly fee. I do pay for the DirecTV feed, but that's a separate flame war.
Last I checked "premium" channels came via Cable or Satellite. :) If you have separate DSL line and DirecTV then you are doubling up on delivery costs. Would the average consumer like to "add" video to their DSL connection? The cable company cuts you a deal if you have video and data on the same line. Wouldn't the telco's like to compete in that market?
Of course, you could just as easily be right.
Who knows? :) Reality will probably end up somewhere in the middle. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless! \ Director, Engineering | @ @ | \ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Wholesale Internet Services - http://www.megapop.net
Its actually funny you mention this. I'd been working on a way to deliver television via atm for years just never had much interest. But basically by attaching to the cloud and then being able to draw pvc's over to dsl lines it should be quite possible. Don't forget also many of us in given areas have faster than 1.5 down in my case its 6 down which should be pleanty for a good tv picture. I'm sure bell would love to put a set top box in when you buy dsl, maybe even have it part of the shipping package you get when you join which delivers tv. Give you phone, net and tv over one pair they should eat that up! Not to mention theoretically isp's should be able to offer it as well with their own offerings. On Wed, 22 Jan 2003, Chris Parker wrote:
At 10:58 AM 1/22/2003 -0800, Al Rowland wrote:
1. I also remember when web page standards required you to design everything to fit in a 640x400 screen. DTV/HDTV will significantly change your 'not much in the way of image quality loss' yardstick. My viewing habits have changed significantly in the year plus I've been DTV/HDTV. Among other things, I go to the movies a lot less. DVD quality (which is lower than HDTV) is better than most movie theaters and there's no gum/spilled drink (most of the time) on my floor.
Agreed, however the source video that I've seen demoed is from DVD. Side by side comparison shows slight degradation, but solo viewing is more than adequate. This also isn't targetted to people at the end of the bell curve for technology adopters and purists, rather at the fat middle section that isn't upgrading to ( or doesn't care about ) HDTV yet and for whom current "digital video" quality is "just fine".
2. I already have it. It's called broadcast. $100 (could have been less but I always over design) antenna and $20 of coax. No monthly fee. I do pay for the DirecTV feed, but that's a separate flame war.
Last I checked "premium" channels came via Cable or Satellite. :) If you have separate DSL line and DirecTV then you are doubling up on delivery costs. Would the average consumer like to "add" video to their DSL connection? The cable company cuts you a deal if you have video and data on the same line. Wouldn't the telco's like to compete in that market?
Of course, you could just as easily be right.
Who knows? :) Reality will probably end up somewhere in the middle.
-Chris
-- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless! \ Director, Engineering | @ @ | \ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Wholesale Internet Services - http://www.megapop.net
Drifting off-topic, but those are 'raw' data rates. Compression algorithms along with motion-estimation allow you to get full-screen video down to ~1.5 Mbps with not much in the way of image quality loss.
Raw HDTV is about 1.2Gbps. RAW NTSC SDI bitstream is a few hundred. The 6 and 19.8 are already compressed. Obviously putting more horsepower to the compression you can achieve smaller data rates. However applying for example MPEG4 instead of MPEG2 for 1080i or 720p ups the computational requirements beyond current consumer state of the art.
I think you'll see it long before every house has fiber run to it.
75% is enough. Pete
Hello; On Wednesday, January 22, 2003, at 06:04 PM, Petri Helenius wrote:
Drifting off-topic, but those are 'raw' data rates. Compression algorithms along with motion-estimation allow you to get full-screen video down to ~1.5 Mbps with not much in the way of image quality loss.
Raw HDTV is about 1.2Gbps. RAW NTSC SDI bitstream is a few hundred. The 6 and 19.8 are already compressed. Obviously putting more horsepower to the compression you can achieve smaller data rates. However applying for example MPEG4 instead of MPEG2 for 1080i or 720p ups the computational requirements beyond current consumer state of the art.
The first MPEG-4 HD set top boxes are beginning to appear http://www.sigmadesigns.com/news/press_releases/030108.htm Watch this space.... Regards Marshall Eubanks
I think you'll see it long before every house has fiber run to it.
75% is enough.
Pete
\
T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html
The first MPEG-4 HD set top boxes are beginning to appear
http://www.sigmadesigns.com/news/press_releases/030108.htm
Watch this space....
If you read the document carefully, you´ll figure that they support MPEG2 HDTV (1920x1080) and MPEG4 SDTV (640x480/720x576), which was my point earlier. So they are little less than two cycles of Moore´s law away from MPEG4 HDTV. That would put it three years away but if the market is there, we´ll probably see it earlier. SDTV video-over-ip services should take off first though or we´ll end up with peer2peer set top boxes sharing premium channel services over broadband networks. Pete
"Al Rowland" <alan_r1@corp.earthlink.net> writes:
mention the effect everyone on AOL going to broadband and downloading Disney clips all the time would have on their settlement plans with backbone providers.
Of course, because you are definitely being kept in the loop regarding the AOL settlement plans? /vijay
Perhaps, continuing the off-topic thread... The best compression techniques that do not use block-based methods (as in MPEG-2/4) can achieve much better compression capabilities than listed below and in the other follow-on thread. For an excellent overview of what this may do for video on demand over the Internet, check out the September 22nd issue of The Economist. There are basically three types of approaches: wavelet, fractal, and heuristic (or object?). They are also either software-only or hardware-assisted. I've seen one of them that claims 1.1 Mbps typically for standard definition (480i), and about 3 Mbps for HDTV (1080i). I'm no codec expert, but I was amazed at the clarity, even with packet loss. I think we'll find video on demand and other streaming entertainment services over our xDSL connections and Cable Modems much sooner than most people expect. I hope network operators are prepared for it. You can get a typed copy of The Economist Article at: http://fox.rollins.edu/~tlairson/ecom/video.html Regards, Jeff Turner jlt@interstream.org
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Al Rowland Sent: Wednesday, January 22, 2003 9:28 AM To: nanog@trapdoor.merit.edu Subject: RE: FW: Re: Is there a line of defense against Distributed Reflective attacks?
Not to mention that fact that 99.99% of current consumer connections are not up to the task. Standard full-screen video digital stream is ~6Mbps, HDTV requires 19.4Mbps. Don't know many consumers with T3s. ;)
Al Rowland
(Taking NANOG out, as this is moving a little towards personal conversation) On Tue, 21 Jan 2003 16:44:26 -0800 "todd glassey" <todd.glassey@worldnet.att.net> wrote:
Vadim - the instant someone sues a Provider for sexual harassment from their spam epidemic you will start to see things change. The reason that No-Sane provider will block these ports or services is because they have been listening to their Network Admins too long, and in fact the problem is that they are not sane providers. What they are, and this is pretty much true across the board, is people that just don't care what they do to earn a buck otherwise we would not have these problems, and this is especially true of those Network Operators that push all those billions of bytes of illicit SPAM and throw their hands up and say "What do you expect us to do" - well the answer is simple. I expect you folks to operate within the law and to cooperate in stopping people who use your services in violation of the laws.
And if the providers out there don't like that - then they should find other businesses.
I think you're *nuts* if you think an ISP should be held entirely accountable for its customers actions. I'm one of a handful of administrators in a small ISP, and we do our damnedest to ensure that everything runs smoothly. We have a fairly strict AUP that we actually enforce, we do egress filtering (not enough, but we're working towards it), we contact customers that are infected with virii and worms, and we have *zero* tolerance for script kiddies (usually instant blackholes). IMHO, that is about all you can expect an ISP to do. Have an AUP that incorporates all of your problems (spam, abuse, viruses, etc), and enforce it. You can *not* expect the ISP to police absolutely everything that its customers do. You can *not* expect the ISP to be held responsible for three of its fifteen thousand customers browsing child porn. You can *not* expect the ISP to be accountable for its two hundred script kiddies. You *can* expect the ISP to have an AUP. You *can* expect the ISP to react, and to react quickly. You *can* expect the ISP to co-operate with the proper authorities, if it goes to that level. You *can* expect the ISP to contact and work with (when and where needed) other ISPs to track down and solve problems. I am a Network Admin, and I am *still* looking for an effective way to block outbound spam from our customers. I spent two months purging all our mail servers of FormMail, and scan them every night for more vulnerable versions. Do you think that I should be sued because one of these slips through the cracks (there's a 24-hour window in which one can be installed and abused), and you get some porn spam? I certainly hope not. Being able to sue ISPs for their customers actions is pure insanity, and will just lead to massive ISP shutdown world-wide. However, being able to sue ISPs for *negligence* and for *ignoring* customers actions is a whole different boat, and I think is an idea worth looking at. - Damian Gerow, an overworked, underpaid, underappreciated Network Administrator. Strung out on caffeine, because I spent most of last night hashing out some more details on our anti-spamming actions.
On Wed, 22 Jan 2003 11:11:19 -0500 Damian Gerow <damian@sentex.net> wrote:
(Taking NANOG out, as this is moving a little towards personal conversation)
Apparently, I didn't read my own Cc: line. Sorry, folks.
On Tue, 21 Jan 2003, todd glassey wrote:
Vadim - the instant someone sues a Provider for sexual harassment from their spam epidemic you will start to see things change. The reason that No-Sane provider will block these ports or services is because they have been listening to their Network Admins too long, and in fact the problem is that they are not sane providers. What they are, and this is pretty much true
However, the US courts and US law don't agree with you. http://news.com.com/2100-1023-981800.html In what legal experts describe as a first, a federal appeals court has upheld a ruling that America Online and other Internet service providers are not liable for "hostile code" sent between subscribers.
Vadim - the instant someone sues a Provider for sexual harassment from
spam epidemic you will start to see things change. The reason that No-Sane provider will block these ports or services is because they have been listening to their Network Admins too long, and in fact the problem is
On Tue, 21 Jan 2003, todd glassey wrote: their that
they are not sane providers. What they are, and this is pretty much true
Actually, most provider won't block ports due to service contracts with customers. Mail filters easily allow for exceptions to the rule. However, IP layer filters do not allow such exceptions without extensive overhead. Is a rural ISP that is forced to use older routers for modem banks to deal with rural telco issues required to run an authentication method that allows per user filtering despite the fact that such methods seriously inhibit the performance of the modem bank? Or should such a provider block specific IP ranges or ports at a global level despite the fact their clients actually use the valid services registered to those ports? It is not the responsibility of the provider to secure the individual's machines. The provider's responsibility is to the network as a whole. We designed a stupid network so that interoperability would be optimal. The second you start building smart networks, you have conflicts. Look at the caching engines of today. There is not a single cache mechanism that is guaranteed to work with 100% of the content its designed to cache. Another example would be the recent 69/8 issues; Smart networks trying to protect themselves and damaging legitimate traffic in the process. Jack Bates Network Engineer BrightNet Oklahoma
participants (24)
-
Al Rowland -
Andy Dills -
Avleen Vig -
Chris Adams -
Chris Parker -
Christopher L. Morrow -
Damian Gerow -
Daniel Senie -
E.B. Dreger -
hc -
Jack Bates -
Jeff Workman -
Johannes Ullrich -
John Kristoff -
Marshall Eubanks -
Max's Lists -
Numetra -
Petri Helenius -
Rob Thomas -
Scott Granados -
Sean Donelan -
todd glassey -
Vadim Antonov -
Vijay Gill