Good day, What NSPs do filter packets, and can really deal with DoS and DDoS attacks? UUNet? Best Regards, -Abdullah Bin Hamad A.K.A Arabian http://www.ArabChat.Org arabian@ArabChat.Org ___________________________________________________________ Chat with us yet? Try http://Chat.ArabChat.Org Make new friends, with ArabChat Now! Get your Free ArabMail http://Mail.ArabChat.Org
IMO, Commercial ISPs should never filter customer packets unless specifically requested to do so by the customer, or in response to a security/abuse incident. Consumer ISPs are much more likely to have clauses in the AUPs that are enforced premptively via packet filtering - antispoof filters (honestly, antispoof filtering is, IMHO, the one expection to my "commercial ISPs should not filter" rule), port blocks to prevent customers running servers, outbound SMTP blocks to off-provider systems to stop direct-to-MX spamming, ICMP rate limiting, et al. All of which are fine by me as long as they clearly assert their right to do so in their AUP - that is, as long as there's a comparable provider I can use instead. -C On Sun, Aug 04, 2002 at 02:37:12PM +0000, bmanning@karoshi.com wrote:
Good day,
What NSPs do filter packets, and can really deal with DoS and DDoS attacks?
-Abdullah Bin Hamad A.K.A Arabian
The shorter shorter list would be the NSPs that do NOT filter packets. I can't think of an NSP that does not filter.
--bill
but wait... you have refined the question. It was "which NSPs filter", not "which NSPs filter customers" Different question with a different answer.
--FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
IMO, Commercial ISPs should never filter customer packets unless=20 specifically requested to do so by the customer, or in response to a=20 security/abuse incident.=20
Consumer ISPs are much more likely to have clauses in the AUPs that are=20 enforced premptively via packet filtering - antispoof filters (honestly,=20 antispoof filtering is, IMHO, the one expection to my "commercial ISPs=20 should not filter" rule), port blocks to prevent customers running=20 servers, outbound SMTP blocks to off-provider systems to stop direct-to-MX= =20 spamming, ICMP rate limiting, et al. All of which are fine by me as long=20 as they clearly assert their right to do so in their AUP - that is, as=20 long as there's a comparable provider I can use instead.
-C
On Sun, Aug 04, 2002 at 02:37:12PM +0000, bmanning@karoshi.com wrote:
Good day, =20 What NSPs do filter packets, and can really deal with DoS and DDoS atta= cks? =20 -Abdullah Bin Hamad A.K.A Arabian =20 The shorter shorter list would be the NSPs that do NOT filter
=20 packets. I can't think of an NSP that does not filter. =20 --bill
--FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9Te7GqP/YiunDNcERAt1+AJ0fT1Zp88n+1vDPzMnszf1FZrFRQQCg2u2M iGNyH2z/A9SLMwuudeCZILw= =pWj4 -----END PGP SIGNATURE-----
--FCuugMFkClbJLl1L--
IMO, Commercial ISPs should never filter customer packets unless specifically requested to do so by the customer, or in response to a security/abuse incident.
Let's say the customer operates some big enterprise network, runs their infrastructure in RFC1918 space ("for security," hah), and spews a couple kilobits of DNS query from that RFC1918 space toward the root nameservers. Assume that either pride or ignorance will prevent the customer from ever asking you to filter what you know to be garbage traffic. Does your rule to "never filter customer packets" mean you're going to sit and watch those packets go by? If yes, why? Stephen
I would filter only if the root server operator is complaining about it...not to say I would do nothing; I would most definitely give the customer a call and strongly advise them to set up a local resolver, citing the volume of redundant traffic they're paying for... -C On Sun, Aug 04, 2002 at 09:15:26PM -0700, Stephen Stuart wrote:
IMO, Commercial ISPs should never filter customer packets unless specifically requested to do so by the customer, or in response to a security/abuse incident.
Let's say the customer operates some big enterprise network, runs their infrastructure in RFC1918 space ("for security," hah), and spews a couple kilobits of DNS query from that RFC1918 space toward the root nameservers. Assume that either pride or ignorance will prevent the customer from ever asking you to filter what you know to be garbage traffic. Does your rule to "never filter customer packets" mean you're going to sit and watch those packets go by?
If yes, why?
Stephen
Or you could be a good neighbor and have your DNS answer NXDOMAIN for the RFC1918 zones and stop the traffic before it left your network. If you have clients that are using RFC1918 and YOUR NS's then don't let those packets out. Give a NXDOMAIN answer back towards them and save us all. :) On Mon, Aug 05, 2002 at 09:05:28AM -0400, Chris Woodfield wrote:
I would filter only if the root server operator is complaining about it...not to say I would do nothing; I would most definitely give the customer a call and strongly advise them to set up a local resolver, citing the volume of redundant traffic they're paying for...
-C
On Sun, Aug 04, 2002 at 09:15:26PM -0700, Stephen Stuart wrote:
IMO, Commercial ISPs should never filter customer packets unless specifically requested to do so by the customer, or in response to a security/abuse incident.
Let's say the customer operates some big enterprise network, runs their infrastructure in RFC1918 space ("for security," hah), and spews a couple kilobits of DNS query from that RFC1918 space toward the root nameservers. Assume that either pride or ignorance will prevent the customer from ever asking you to filter what you know to be garbage traffic. Does your rule to "never filter customer packets" mean you're going to sit and watch those packets go by?
If yes, why?
Stephen
--On Monday, August 05, 2002 15:09:43 -0700 "John M. Brown" <jmbrown@ihighway.net> wrote:
Or you could be a good neighbor and have your DNS answer NXDOMAIN for the RFC1918 zones and stop the traffic before it left your network.
If you have clients that are using RFC1918 and YOUR NS's then don't let those packets out. Give a NXDOMAIN answer back towards them and save us all. :)
Or set up an AS112 server, let the customer win2k boxes send updates and then *accept*those*updates*. Watch badly configured networks go bellyup when the updates are served out again and then over-written. *evil grin* -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
On Sun, Aug 04, 2002 at 09:15:26PM -0700, Stephen Stuart wrote:
IMO, Commercial ISPs should never filter customer packets unless specifically requested to do so by the customer, or in response to a security/abuse incident.
Let's say the customer operates some big enterprise network, runs their infrastructure in RFC1918 space ("for security," hah), and spews a couple kilobits of DNS query from that RFC1918 space toward the root nameservers. Assume that either pride or ignorance will prevent the customer from ever asking you to filter what you know to be garbage traffic. Does your rule to "never filter customer packets" mean you're going to sit and watch those packets go by?
If yes, why?
Everyone should turn on either the equivalent of the Cisco 'ip verify unicast source reachable-via any' on their peer/upstream interfaces as well as to internal and bgp customer interfaces that may not be able to be checked with a stricter rpf. This will drop packets from people that you have no return path for in the cef path. I know other vendors either have or should have this feature. While it will not stem a true DoS based on real ip addresses, zombies, whatnot.. it will stop all the rfc1918 headed towards the roots or other space that is not in the global routing table. if your vendor doesn't have such a knob, i do suggest asking them :) i've seen a lot of traffic get dropped by using such a check on interfaces. it is not a large amount compared to the overall packets but does reduce what you end up transporting and customer support queries about why 10.* is sending them packets. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
But keep in mind that there is a difference between IP Header Source being RFC-1918, and the payload having a query for something in RFC-1918 space. Yes, dropping packets that you have no valid return path for is not bad. Dropping queries from your network asking for things in RFC-1918 space is also good thing (tm) On Mon, Aug 05, 2002 at 11:06:50AM -0400, Jared Mauch wrote:
On Sun, Aug 04, 2002 at 09:15:26PM -0700, Stephen Stuart wrote:
IMO, Commercial ISPs should never filter customer packets unless specifically requested to do so by the customer, or in response to a security/abuse incident.
Let's say the customer operates some big enterprise network, runs their infrastructure in RFC1918 space ("for security," hah), and spews a couple kilobits of DNS query from that RFC1918 space toward the root nameservers. Assume that either pride or ignorance will prevent the customer from ever asking you to filter what you know to be garbage traffic. Does your rule to "never filter customer packets" mean you're going to sit and watch those packets go by?
If yes, why?
Everyone should turn on either the equivalent of the Cisco 'ip verify unicast source reachable-via any' on their peer/upstream interfaces as well as to internal and bgp customer interfaces that may not be able to be checked with a stricter rpf.
This will drop packets from people that you have no return path for in the cef path. I know other vendors either have or should have this feature. While it will not stem a true DoS based on real ip addresses, zombies, whatnot.. it will stop all the rfc1918 headed towards the roots or other space that is not in the global routing table.
if your vendor doesn't have such a knob, i do suggest asking them :)
i've seen a lot of traffic get dropped by using such a check on interfaces. it is not a large amount compared to the overall packets but does reduce what you end up transporting and customer support queries about why 10.* is sending them packets.
- jared
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Watch that Good Thing (tm) Martha Stewart might have something to say about that:):). On Mon, 5 Aug 2002, John M. Brown wrote:
But keep in mind that there is a difference between IP Header Source being RFC-1918, and the payload having a query for something in RFC-1918 space.
Yes, dropping packets that you have no valid return path for is not bad.
Dropping queries from your network asking for things in RFC-1918 space is also good thing (tm)
On Mon, Aug 05, 2002 at 11:06:50AM -0400, Jared Mauch wrote:
On Sun, Aug 04, 2002 at 09:15:26PM -0700, Stephen Stuart wrote:
IMO, Commercial ISPs should never filter customer packets unless specifically requested to do so by the customer, or in response to a security/abuse incident.
Let's say the customer operates some big enterprise network, runs their infrastructure in RFC1918 space ("for security," hah), and spews a couple kilobits of DNS query from that RFC1918 space toward the root nameservers. Assume that either pride or ignorance will prevent the customer from ever asking you to filter what you know to be garbage traffic. Does your rule to "never filter customer packets" mean you're going to sit and watch those packets go by?
If yes, why?
Everyone should turn on either the equivalent of the Cisco 'ip verify unicast source reachable-via any' on their peer/upstream interfaces as well as to internal and bgp customer interfaces that may not be able to be checked with a stricter rpf.
This will drop packets from people that you have no return path for in the cef path. I know other vendors either have or should have this feature. While it will not stem a true DoS based on real ip addresses, zombies, whatnot.. it will stop all the rfc1918 headed towards the roots or other space that is not in the global routing table.
if your vendor doesn't have such a knob, i do suggest asking them :)
i've seen a lot of traffic get dropped by using such a check on interfaces. it is not a large amount compared to the overall packets but does reduce what you end up transporting and customer support queries about why 10.* is sending them packets.
- 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, Aug 04, 2002 at 09:15:26PM -0700, Stephen Stuart wrote:
IMO, Commercial ISPs should never filter customer packets unless specifically requested to do so by the customer, or in response to a security/abuse incident.
Let's say the customer operates some big enterprise network, runs their infrastructure in RFC1918 space ("for security," hah), and spews a couple kilobits of DNS query from that RFC1918 space toward the root nameservers. Assume that either pride or ignorance will prevent the customer from ever asking you to filter what you know to be garbage traffic. Does your rule to "never filter customer packets" mean you're going to sit and watch those packets go by?
If yes, why?
One would hope that, unless there is a complaint, you wouldn't be invading their private to look at their traffic in the first place. If a root server operator complained about it, I'd say thats reasonable grounds to filter it and contact the customer, the same as if they had a compromised box spewing out DoS. Filtering piddly stuff like this without consultation is usually unwelcome at best, and a disruption at worst. It is also a serious investment of time and acl resources which could be better spent somewhere else. And lastly, it sets a bad precedent for what ISPs "can" do to proactively filter. After all, if we "can" do this, why can't we also filter illegal MP3 exchanges too. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Filtering piddly stuff like this without consultation is usually unwelcome at best, and a disruption at worst. It is also a serious investment of time and acl resources which could be better spent somewhere else. And lastly, it sets a bad precedent for what ISPs "can" do to proactively filter. After all, if we "can" do this, why can't we also filter illegal MP3 exchanges too.
One is envelope, the other is payload. Until there is some technical means of "return to sender" for IP, filtering bad envelopes is the next best thing.
On Mon, Aug 05, 2002 at 12:03:18PM -0400, bdragon@gweep.net wrote:
Filtering piddly stuff like this without consultation is usually unwelcome at best, and a disruption at worst. It is also a serious investment of time and acl resources which could be better spent somewhere else. And lastly, it sets a bad precedent for what ISPs "can" do to proactively filter. After all, if we "can" do this, why can't we also filter illegal MP3 exchanges too.
One is envelope, the other is payload.
Until there is some technical means of "return to sender" for IP, filtering bad envelopes is the next best thing.
They are exactly the same. In the first example you filter based on udp port 53 source rfc1918 and perhaps dest rootservers, and hope you're only hitting bad traffic, but you don't really know that the payload is DNS. You can also filter mp3 exchanging services by header information and most likely hit only them too. Poking into anything other than dst ip or src/dest/port flows without reason is an intrusion IMHO. Of course in the example Stephen gave, RPF filters on the customer would have likely solved the problem quite nicely. That is the only kind of filtering which should be done on customers by default. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Until we have a dos called "return to sender " :) On Mon, Aug 05, 2002 at 12:03:18PM -0400, bdragon@gweep.net wrote:
Filtering piddly stuff like this without consultation is usually unwelcome at best, and a disruption at worst. It is also a serious investment of time and acl resources which could be better spent somewhere else. And lastly, it sets a bad precedent for what ISPs "can" do to proactively filter. After all, if we "can" do this, why can't we also filter illegal MP3 exchanges too.
One is envelope, the other is payload.
Until there is some technical means of "return to sender" for IP, filtering bad envelopes is the next best thing.
IMO, Commercial ISPs should never filter customer packets unless specifically requested to do so by the customer, or in response to a security/abuse incident.
We already have BCP 38, which strongly recommends packet filtering on the customer-ISP edge. There are now two major vendors who have strict mode uRPF. This which covers 80% of the BCP 38 packet filtering on the customer-ISP edge. With a few BGP config tweaks, strict mode uRPF can cover a lot of the last 20% (all those multihomed customers). Q. What is wrong with BCP 38 filtering? We also have Loose Mode uRPF that can work on all the ISP edges. While this was originally done to allow source based remote-triggered black hole filtering, Loose Mode uRPF does do some sanity checking of the packets. It drops any packet whose source is not in the global route table. So it is an effective bogon, RFC 1918, and martin filter on the ISP-ISP edge. Q. What is wrong with filtering packets with source address that should not be out there floating on the Net? The only thing that has been holding up uRPF deployment has been ISP migrating to images that support uRPF (mostly done) and operational confidence in the feature (so the operators know it is not going to hose their network). Both of these are well on their way with more operators turning on uRPF (Strict or Loose mode). So it is really a matter of time before we have a lot of uRPF doing packet filtering on the ISP edges. But, what if you could "strict mode" packet filter on the ISP-ISP side? Lets say there was a dynamic uRPF filter that checked the source addresses against the eBGP routes coming into a link. In other words, if the source address from an ISP does not match the eBGP prefixes coming across from the peer, the packet would drop. So if some /8 prefixes are filtered on the eBGP side, they would get dropped on the ISP-ISP peering interface. For example, if I only send routes from AS X, then any packet whose source address is outside of AS X (say from AS Y) would not pass the uRPF check - resulting in a drop. Since this is based on the dynamics of the eBGP prefixes coming across the peering session, it would allow a "strict mode like" uRPF packet filtering on the ISP-ISP edge (with all the asymmetry found on the ISP-ISP edge). The question is whether this is something people would want as an option. A uRPF mode that would enforce a peering agreement with dynamic packet filtering (dynamic is based on the eBGP advertisements that get through the peering filter). Barry
On Mon, Aug 05, 2002 at 11:59:04PM +0800, Barry Raveendran Greene wrote:
We already have BCP 38, which strongly recommends packet filtering on the customer-ISP edge. There are now two major vendors who have strict mode uRPF. This which covers 80% of the BCP 38 packet filtering on the customer-ISP edge. With a few BGP config tweaks, strict mode uRPF can cover a lot of the last 20% (all those multihomed customers).
Except vendor J doesn't spend much time at the customer edge, and vendor F seems to think that you should do per-interface RPF with acl's. Also, vendor J's implementation of loose mode is significantly different from everyone elses. It seems they mean "is it feasible for this src ip to be routed to this interface regardless or route selection", not "it is feasible for this src ip to be routes to any interface on the box". Or to put it another way, say you peer with someone who sends you 5000 routes, but you only accept 4000 as best-path. If you feasible filter it, you'll be allowing src IPs from those 5000 prefixes, not from all 100k+ on the box. While this is potentially a neat feature, it isn't the same as true "loose". Between that and only being able to set strict or feasible for the entire box and not per-interface, I'd say vendor J's implementation is almost completely useless at this point. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
On Mon, Aug 05, 2002 at 12:39:08PM -0400, Richard A Steenbergen wrote:
On Mon, Aug 05, 2002 at 11:59:04PM +0800, Barry Raveendran Greene wrote:
We already have BCP 38, which strongly recommends packet filtering on the customer-ISP edge. There are now two major vendors who have strict mode uRPF. This which covers 80% of the BCP 38 packet filtering on the customer-ISP edge. With a few BGP config tweaks, strict mode uRPF can cover a lot of the last 20% (all those multihomed customers).
Except vendor J doesn't spend much time at the customer edge, and vendor F seems to think that you should do per-interface RPF with acl's.
Also, vendor J's implementation of loose mode is significantly different from everyone elses. It seems they mean "is it feasible for this src ip to be routed to this interface regardless or route selection", not "it is feasible for this src ip to be routes to any interface on the box". Or to put it another way, say you peer with someone who sends you 5000 routes, but you only accept 4000 as best-path. If you feasible filter it, you'll be allowing src IPs from those 5000 prefixes, not from all 100k+ on the box. While this is potentially a neat feature, it isn't the same as true "loose".
Juniper I believe is working on a "super-loose" check which will mimick the cisco behaviour. As always, check with your vendor for more detailed information, etc..
Between that and only being able to set strict or feasible for the entire box and not per-interface, I'd say vendor J's implementation is almost completely useless at this point.
Their 'loose' is interesting only in the case of customer interfaces and not so interesting in the network core. Also I seem to recall that it's a global option currently. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
richard; sorry for latency on this one but might be worth reading andre's: "Internet expansion, refinement and churn", http://www.caida.org/outreach/papers/2002/EGR/ which shows that most prefixes in the table come from large providers. among.andre.conclusions (there is quite a bit in the paper): "transit ASes originate prefixes than non-transit ASes despite the fact that there are five times as many non-transit as transit ASes. [see table 16 of paper, p.11] the number of non-transit multihomed ASes grew from 46% to 49% from 2000 to 2001, but their share of global routes remained stable at 30%." etc etc there's a lot of stuff in there not at all a waste of time k ----- Forwarded message from Richard A Steenbergen <ras@e-gerbil.net> ----- Date: Mon, 29 Jul 2002 19:43:32 -0400 From: Richard A Steenbergen <ras@e-gerbil.net> Subject: Re: routing table size To: Brian <bri@sonicboom.org> Cc: "nanog@merit.edu" <nanog@merit.edu> On Mon, Jul 29, 2002 at 03:35:19PM -0700, Brian wrote: > > the large quantity of /24 announcements is, I suspect, from comapnies just > large enough to want the benefits of multihoming. You know, 2 t1s on a > small router, and stuff like that.. Everyone and their mother says they "suspect" that, but noone ever proves it. Ever wonder why? Let's take it by the numbers: Total ASes present in the Internet Routing Table: 13448 Origin-only ASes present in the Internet Routing Table: 11641 Origin ASes announcing only one prefix: 5154 Transit ASes present in the Internet Routing Table: 1807 Even if every origin-only AS was a smalltime company with just enough IPs for a /24, it would take around 6-7 /24s each to account for the number of /24s announced. If someone has done an actual study of where these /24s (and probably /23s too) come from, please point it out. Until then, my money is on clueless redist connected/statics, large cable/dsl providers who announce a /24 per pop/city/whatever to their single transit provider, and general ignorance. Why attribute to functionality what can easily be explained by incomptence. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) ----- End forwarded message -----
On Wed, Aug 07, 2002 at 05:32:34PM -0700, k claffy mooed:
richard; sorry for latency on this one
but might be worth reading andre's: "Internet expansion, refinement and churn", http://www.caida.org/outreach/papers/2002/EGR/ which shows that most prefixes in the table come from large providers. among.andre.conclusions (there is quite a bit in the paper):
On a related note, from a paper we're about to submit to the Internet Measurement Workshop, see: http://nms.lcs.mit.edu/~dga/aspathfrac.eps for a breakdown of prefix by origin AS. It's fairly clear where most of the prefixes come from.. (hi, UUNET). -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
On Mon, 5 Aug 2002, Barry Raveendran Greene wrote:
But, what if you could "strict mode" packet filter on the ISP-ISP side? Lets say there was a dynamic uRPF filter that checked the source addresses against the eBGP routes coming into a link. In other words, if the source address from an ISP does not match the eBGP prefixes coming across from the peer, the packet would drop. So if some /8 prefixes are filtered on the eBGP side, they would get dropped on the ISP-ISP peering interface. For example, if I only send routes from AS X, then any packet whose source address is outside of AS X (say from AS Y) would not pass the uRPF check - resulting in a drop. Since this is based on the dynamics of the eBGP prefixes coming across the peering session, it would allow a "strict mode like" uRPF packet filtering on the ISP-ISP edge (with all the asymmetry found on the ISP-ISP edge).
How would this work for BGP Conditional Advertisement as per page 118 of "Cisco ISP Essentials?" :-) Hank
The question is whether this is something people would want as an option. A uRPF mode that would enforce a peering agreement with dynamic packet filtering (dynamic is based on the eBGP advertisements that get throughthe peering filter).
Barry
Might be of interest, BBC-2 has a story on the impact of Sept-11 on comms networks (7:30 GMT). Seems a little dramatic given the real (to comms) impact it had but it may make interesting viewing. Alan.
On Tue, 6 Aug 2002 04:41:59 +1000 (EST), Alan Sawyer wrote:
Might be of interest, BBC-2 has a story on the impact of Sept-11 on comms networks (7:30 GMT). Seems a little dramatic given the real (to comms) impact it had but it may make interesting viewing.
Alan.
I happened to switch the TV on part way through. It wasn't exactly overwhelming on actual detail. They concentrated solely on the AT&T network (not being familiar with the US network there I don't know if there are others involved). They explained some of the basic principles that the network management team used to cope with the demand but the most technical they got was showing the AT&T switch building that got severely damaged when one of the minor buildings collapsed. They did stretch to cover wireless coverage and how the mobile phone network was affected along with emergency plans of bringing in mobile transmitting units to keep the network running.
I happened to flick over to this right at the start, and thought the content was actually quite factual for this kind of programme. They obviously concentrated on Voice, lots of interviews with Verizon and AT&T types, lots of footage of the West Street CO which must have been 60-70% of the content. The bits that did touch on data seemed to actually be quite accurate if very brief, correctly "getting it" that the Internet didn't suffer any major problems in the immediate aftermath, and that e-mail was a major communications mechanism, although individual news content providers were swamped. They also had a good description of how a SONET ring works, so they must have had a decent technical advisor. There was a small segment on the New York Times website, and the steps they took drop graphical content to try and keep things running. Not too bad overall, I normally switch this kind of thing off as the content is usually hopelessly inaccurate but watched this right up to the end. -- Rob. --On 06 August 2002 09:28 +0100 cw <security@fidei.co.uk> wrote:
On Tue, 6 Aug 2002 04:41:59 +1000 (EST), Alan Sawyer wrote:
Might be of interest, BBC-2 has a story on the impact of Sept-11 on comms networks (7:30 GMT). Seems a little dramatic given the real (to comms) impact it had but it may make interesting viewing.
Alan.
I happened to switch the TV on part way through. It wasn't exactly overwhelming on actual detail. They concentrated solely on the AT&T network (not being familiar with the US network there I don't know if there are others involved). They explained some of the basic principles that the network management team used to cope with the demand but the most technical they got was showing the AT&T switch building that got severely damaged when one of the minor buildings collapsed. They did stretch to cover wireless coverage and how the mobile phone network was affected along with emergency plans of bringing in mobile transmitting units to keep the network running.
-- Rob.
I'll clarify this...I already noted that antispoof filtering is an exception, and I'll agree that RPF fits loosely under the antispoofing definition as well, albiet in the other direction. -C On Sun, Aug 04, 2002 at 11:19:35PM -0400, Chris Woodfield wrote:
IMO, Commercial ISPs should never filter customer packets unless specifically requested to do so by the customer, or in response to a security/abuse incident.
Consumer ISPs are much more likely to have clauses in the AUPs that are enforced premptively via packet filtering - antispoof filters (honestly, antispoof filtering is, IMHO, the one expection to my "commercial ISPs should not filter" rule), port blocks to prevent customers running servers, outbound SMTP blocks to off-provider systems to stop direct-to-MX spamming, ICMP rate limiting, et al. All of which are fine by me as long as they clearly assert their right to do so in their AUP - that is, as long as there's a comparable provider I can use instead.
-C
On Sun, Aug 04, 2002 at 02:37:12PM +0000, bmanning@karoshi.com wrote:
Good day,
What NSPs do filter packets, and can really deal with DoS and DDoS attacks?
-Abdullah Bin Hamad A.K.A Arabian
The shorter shorter list would be the NSPs that do NOT filter packets. I can't think of an NSP that does not filter.
--bill
On Sun, 4 Aug 2002, Abdullah Bin Hamad - Arabian wrote:
Good day,
What NSPs do filter packets, and can really deal with DoS and DDoS attacks?
UUNet?
Yes, only during attacks at customer request.
Best Regards,
-Abdullah Bin Hamad A.K.A Arabian http://www.ArabChat.Org arabian@ArabChat.Org
___________________________________________________________ Chat with us yet? Try http://Chat.ArabChat.Org Make new friends, with ArabChat Now! Get your Free ArabMail http://Mail.ArabChat.Org
participants (18)
-
Abdullah Bin Hamad - Arabian -
Alan Sawyer -
Barry Raveendran Greene -
bdragon＠gweep.net -
bmanning＠karoshi.com -
Chris Woodfield -
Christopher L. Morrow -
cw -
David G. Andersen -
Hank Nussbacher -
Jared Mauch -
John M. Brown -
k claffy -
Måns Nilsson -
Richard A Steenbergen -
Rob Pickering -
Scott Granados -
Stephen Stuart