Anycast details...
Hi, I am currently trying to understand Anycast and i figured out that very liitle information is available on this subject. Only a few RFCs and drafts. Are there any concrete experiences on Anycast ? Thank you. Regards, Alexis Jordan.
Latest Internet Domain Survey/ Host Count
Data from the January 2000 Internet Domain Survey is now available from the Internet Software Consortium's web site at http://www.isc.org/ds/. The latest count shows more than 72 million hosts, an increase from 56 million 6 months ago. The Internet Domain Survey is the longest running count of Internet growth, dating back to 1987. The Survey is a joint effort of Network Wizards and the Internet Software Consortium, with operational support provided by Nominum, Inc. fyi, April - April Marine Director of Operations [EMAIL PROTECTED] Nominum, Inc. +1.650.779.6006
Re: VM packaging
"Gazal, Elly" escribió: > > Can anyone explain what is "VoiceMail Packaging"??? > > Regards, > > Elly Gazal > System Engineer I supose that is a compressed format of mail contents same as MIME (last without compression). This package format must provide the posibility of sending voice withing SMTP. However, it's needs a special software to get packed data into real voice (sounds). Don't espect too much. I hasn't experience with voicemail. But I ever belive that. Thanks for reading it. (And sorry for my english) Julio Serrano
Internet SYN Flooding, spoofing attacks
Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs required to put filtering on their networks that PREVENTS packets with invalid source addresses ever entering their infrastructure? If every site connected to the Internet did this, spoofing would be much more difficult because you couldn't do it. Sure, you could spoof an address from YOUR network, but that's all. And guess what, it would be much easier to track and thus to shut down the intrusions should they occur. Thus ever edge router should have filter lists that prevent it forwarding traffic out to the Internet (ISPs network) any packet that does not have a source address that is valid from that site. I would hope that lots of ISPs already do this. But, perhaps not. - Bernie Volz Process Software
Re: Internet SYN Flooding, spoofing attacks
> Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs > required to put filtering on their networks that PREVENTS packets with > invalid source addresses ever entering their infrastructure? maybe you want to be reading the nanog mailing list, [EMAIL PROTECTED], where the problems with and tactics for this and other approaches are discussed. randy
Re: Internet SYN Flooding, spoofing attacks
At 02:40 PM 02/11/2000 -0500, Bernie Volz wrote: >Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs >required to put filtering on their networks that PREVENTS packets with >invalid source addresses ever entering their infrastructure? Because there is no "Internet Police", that's why. >If every >site connected to the Internet did this, spoofing would be much more >difficult because you couldn't do it. Sure, you could spoof an address >from YOUR network, but that's all. And guess what, it would be much >easier to track and thus to shut down the intrusions should they occur. Yes, this practice is documented in RFC2267. >Thus ever edge router should have filter lists that prevent it >forwarding traffic out to the Internet (ISPs network) any packet that >does not have a source address that is valid from that site. > >I would hope that lots of ISPs already do this. But, perhaps not. I would hope so, too, but apparently many do not. Thus, the problem at hand. - paul >- Bernie Volz > Process Software
Re: Internet SYN Flooding, spoofing attacks
At 11:57 AM 02/11/2000 -0800, Randy Bush wrote: > > Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs > > required to put filtering on their networks that PREVENTS packets with > > invalid source addresses ever entering their infrastructure? > >maybe you want to be reading the nanog mailing list, [EMAIL PROTECTED], where >the problems with and tactics for this and other approaches are discussed. Let's point folks to: http://www.nanog.org/mailinglist.html instead. The last thing I want to see on the NANOG list is a bunch of "subscribe me" messages. - paul
Re: Internet SYN Flooding, spoofing attacks
On Fri, 11 Feb 2000 14:40:15 EST, Bernie Volz <[EMAIL PROTECTED]> said: > Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs > required to put filtering on their networks that PREVENTS packets with > invalid source addresses ever entering their infrastructure? If every > site connected to the Internet did this, spoofing would be much more See RFC2267. The problem is that the IETF doesn't have the legal authority to beat ISP's into submission on this one. There's also the problem that many ISP's are somewhat marginal in cluefulness, so things like RFC2267 tend to be of the "preaching to the choir" variety. Given that RFC2267 is over 2 years old now, what *do* you suggest the network community at large do to motivate the sites that still haven't implemented it? Would somebody be interested in running a BGP blackhole feed of prefixes known not to be filtering, similar to the maps.vix.com feed for closing off E-mail spam? Perhaps if that became prevalent, ISPs would cleanup their act when their legitimate users couldn't get anyplace because their ISP wasn't filtering. ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: Internet SYN Flooding, spoofing attacks
Bernie Volz wrote: > Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs > required to put filtering on their networks that PREVENTS packets with > invalid source addresses ever entering their infrastructure? That wouldn't help with the current version of the problem. An attacker sends out a virus or worm or something; when it's running on 10^5 machines, the attacker turns them loose on the target. Each of the source addresses is valid; each of the packets sent is innocuous in and of itself. -- /=\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist || |eCal Corp. |"Genius, Brain! But what if the dragon eats us?"| |[EMAIL PROTECTED]|"That would alter our plans." | \=/
Re: Internet SYN Flooding, spoofing attacks
On Fri, Feb 11, 2000 at 02:40:15PM -0500, Bernie Volz wrote: > Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs > required to put filtering on their networks that PREVENTS packets with > invalid source addresses ever entering their infrastructure? If every > site connected to the Internet did this, spoofing would be much more > difficult because you couldn't do it. Sure, you could spoof an address > from YOUR network, but that's all. And guess what, it would be much > easier to track and thus to shut down the intrusions should they occur. Clue alert... The recent attacks were not TCP SYN Floods. Please check recent Bugtraq and Cert information regarding Distributed DoS attacks. Further references: http://xforce.iss.net/alerts/advise40.php3 http://www.cert.org/advisories/CA-2000-01.html http://www.fbi.gov/nipc/trinoo.htm Detailed analysis of TFN (Tribe Flood Network), Trin00, and Stacheldraht (Barbed Wire) are here: http://staff.washington.edu/dittrich/misc/tfn.analysis http://staff.washington.edu/dittrich/misc/trinoo.analysis http://staff.washington.edu/dittrich/misc/stacheldraht.analysis Contrary to popular belief and the common press, TFN2K (Tribe Flood Network 2000) also has Windows versions of the slave daemons as well as Solaris and Linux versions. A lot of these attacks appeared to be SMURF style attacks and TFN (Tribe Flood Network) and TFN2K have distributed smurf capabilities. This wasn't even close to being a TCP SYN flood. As far as spoofing goes, in their SMURF mode, the only spoofing is the src_addr part of the ICMP echo that the slave systems send to their LOCAL broadcast address. That src_addr is the address of the system being attacked by ICMP_ECHOREPLY packets that simply consume all its bandwidth. Check out the analysis. Anti spoofing entry filters would have been of zero effect. > Thus ever edge router should have filter lists that prevent it > forwarding traffic out to the Internet (ISPs network) any packet that > does not have a source address that is valid from that site. Would not have helped except maybe in some of the UDP attack modes of the slaves. > I would hope that lots of ISPs already do this. But, perhaps not. > - Bernie Volz > Process Software Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
Re: IETF meeting wireless "standard"
At 09:23 AM 2/9/00 -0500, Theodore Y. Ts'o wrote: >Prior. Definitely prior; that way folks don't have to spend the first >half of the week hacking support for the 802.11 DS card into NetBSD, >Linux, BSDI, et. al. :-) There is a neat FAQ at http://www.wavelan.com/products/faq/ and one of the FAQ items says: The WaveLAN Network Interface Cards (NICs) include NDIS and ODI client drivers, allowing WaveLAN to work in the Windows 95/98, Windows NT, Win2K, Apple, Linux and Novell environments. I seem to recall that someone has already done NetBSD and BSDI for these cards, but I've lost that email. >I'm definitely interested. So do we have someone with a company >connection who can get the IETF a good bulk discount on 801.11 DS cards? >Especially the 11 megabit variant... (Is Adelaide going to have 11 mbps >support?) I've been working on getting Lucent to sponsor DS 11Mbps base station support as well as a deep IETF-special discount on new 11mbps PCMCIA cards. More information to come soon. BTW, if you have older slower Wavelan gear the new base stations are backwards compatible.
Re: Internet SYN Flooding, spoofing attacks
At 03:33 PM 02/11/2000 -0500, [EMAIL PROTECTED] wrote: >Given that RFC2267 is over 2 years old now, what *do* you suggest the network >community at large do to motivate the sites that still haven't implemented it? Do you think that if RFC2267 was advanced as a BCP that it would carry more weight, and therefore more ISP's would implement RFC2267-style filtering? Coupled with the latest denial of service attacks? - paul
Re: Internet SYN Flooding, spoofing attacks
At 03:45 PM 02/11/2000 -0500, John Stracke wrote: > > Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs > > required to put filtering on their networks that PREVENTS packets with > > invalid source addresses ever entering their infrastructure? > >That wouldn't help with the current version of the problem. An attacker >sends out a virus or worm or something; when it's running on 10^5 >machines, the attacker turns them loose on the target. Each of the source >addresses is valid; each of the packets sent is innocuous in and of >itself. Yes, it would certainly help. It would allow the attacks to be traced back to the zombies (in the case of these DDoS attacks), and the perpetrators to be traced back and identified. - paul
Re: Internet SYN Flooding, spoofing attacks
Steve, That's simply propagating FUD, and I think that by making such sweeping assumptions, you are doing the Internet community a disservice. Is RFC2267-style filtering a perfect solution for every situation? No. Sure there are some scenarios where it foo bars transit traffic, but in the larger scheme of things, most dual-homed networks are not providing transit. Does it impact router performance? Perhaps. It really depends on various arbitrary issues. From an architectural perspective, it is very important _where_ you filter to be effective, not cause transit problems, and not make smoke roll out of the back of the equipment. Will it stop bogon source packets from being injected into the Internet, so that anyone foolish enough top launch a denial of service attack can be traced back, identified, and prosecuted? Absolutely. - paul At 04:59 PM 02/11/2000 -0500, Stephen Kent wrote: >Paul & Bernie, > >A more technically focused answer is that most routers are not >designed to perform the filtering without adversely impacting >throughput, and because dual homing and the mesh nature of Internet >connectivity makes it hard to apply appropriate filters for all >subscribers (remembering that some subscribers are really down stream >service providers ...) > >Steve >
Re: Internet SYN Flooding, spoofing attacks
On Fri, 11 Feb 2000 16:35:18 EST, Paul Ferguson said: > Do you think that if RFC2267 was advanced as a BCP that > it would carry more weight, and therefore more ISP's would > implement RFC2267-style filtering? Coupled with the latest > denial of service attacks? On the one hand, I think it would make a good candidate for BCP. It seems to be similar in tone with RFCs 2502 and 2644. I'd have to re-read it to see if it would need any textual changes, or if it's OK as it is. I was talking to a co-worker on this topic, and his exact quote was "We have our s--t more together than most sites, despite our best efforts". The problem is that he was right - our site may have clue, but there's a lot of uneducated sites out there. Does anybody have statistics on how effective RFC2350 (Expectations for Computer Security Incident Response) was? Or RFC2502 (Anti-Spam Recommendations for SMTP MTAs)? Or RFC2644 ( Changing the Default for Directed Broadcasts in Routers)? It would seem reasonable that moving 2267 to BCP should have a similar effectiveness... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: Internet SYN Flooding, spoofing attacks
Paul, I object to the characterization of my comments as "propagating FUD." One might equally well suggest that 2267 constitutes a naive model of how to prevent IP spoofing, but I was polite enough not to say that :-). From a security perspective, it is never desirable to rely on a mechanism that assumes that everyone else does "the right thing." When one suggests that a first tier ISP would not need to filter traffic from down stream providers, because IF they do the filtering, then the problem will not arise via those links, one is suggesting precisely this sort of model. Edge filtering would often be helpful, but it is not a panacea, as pointed out by others in regard to the current set of attacks, nor is the performance impact trivial with most current routers. Because most routers are optimized for transit traffic forwarding, the ability to filter on the interface cards is limited, as I'm sure you know. Also, several of the distributed DoS attacks we are seeing do not use fake source addresses from other sites, so simple filtering of the sort proposed in 2267 would not be effective in these cases. Finally, I am aware of new routers for which this sort of filtering would be child's play, but they are not yet deployed. One ought not suggest that edge filtering is not being applied simply because of laziness on the part of ISPs. Steve
Dave Clark was on PBS News Hour 10-Feb-2000..
..the transcript is available here.. http://www.pbs.org/newshour/bb/cyberspace/jan-june00/hack_attack_2-10.html Overall series of relatively recent related segments.. http://www.pbs.org/newshour/bb/cyberspace/internet_security.html JeffH
Re: Internet SYN Flooding, spoofing attacks
Steve, At 07:01 PM 02/11/2000 -0500, Stephen Kent wrote: > From a security perspective, it is never desirable to rely on a >mechanism that assumes that everyone else does "the right thing." I agree. Every potential target network is not only responsible for their own security, but in my opinion, they should be conscientiously motivated to do the Right Things for the Internet community at-large. Of course, it doesn't always work out that way, sadly, and I'm not delusional that it does. >When one suggests that a first tier ISP would not need to filter >traffic from down stream providers, because IF they do the filtering, >then the problem will not arise via those links, one is suggesting >precisely this sort of model. You're approaching this from the wrong perspective, in my opinion. There is no assumption implied that RFC2267 filtering is needed -- it is required. What good is it if one or two or 300 people do it, and another 157,000 do not? Well, there is a little good, but the more people that do it, the better off we all are. The bottom line here is that RFC2267-style filtering (or unicast RPF checks, or what have you) stops spoofed source address packets from being transmitted into the Internet from places they have no business being originated from to begin with. In even the worst case, those conscientious network admins that _do_ do it can say without remorse that they are doing their part, and can at least be assured that DoS attacks using spoofed source addresses are not being originated from their customer base. And this is a Bad Thing? >Edge filtering would often be helpful, but it is not a panacea, as >pointed out by others in regard to the current set of attacks, nor is >the performance impact trivial with most current routers. It is negligible at the edge in most cases, but you really need to define "edge" a little better. In some cases, it is very low speed links, in others it is an OC-12. >Because >most routers are optimized for transit traffic forwarding, the >ability to filter on the interface cards is limited, as I'm sure you >know. No, I don't know that at all. _Backbone_routers_ are optimized for packet forwarding -- I do know that. > Also, several of the distributed DoS attacks we are seeing do >not use fake source addresses from other sites, so simple filtering >of the sort proposed in 2267 would not be effective in these cases. Again, you're missing the point. If attackers are limited to launching DoS attacks using traceable addresses, then not only can their zombies be traced & found, but so can their controller (the perpetrator himself). Of this, make no mistake. >Finally, I am aware of new routers for which this sort of filtering >would be child's play, but they are not yet deployed. One ought not >suggest that edge filtering is not being applied simply because of >laziness on the part of ISPs. Steve, you said that -- I didn't. I think ISP's will do what their customers pay them to do. - paul
Re: Internet SYN Flooding, spoofing attacks
In message <[EMAIL PROTECTED]>, Valdis.Kletnieks@vt .edu writes: > > Does anybody have statistics on how effective RFC2350 (Expectations > for Computer Security Incident Response) was? Or RFC2502 (Anti-Spam > Recommendations for SMTP MTAs)? Or RFC2644 ( Changing the Default for > Directed Broadcasts in Routers)? It would seem reasonable that moving > 2267 to BCP should have a similar effectiveness... Well 2267 is addressed more towards ISPs, and while there are certainly clueless ISPs out there, I suspect that on the average they're more clueful about the net than the typical end site. (Obviously, there are exceptions in both categories; I did say *average*.) --Steve Bellovin
[fwd] Lawyers Forsee Denial Of Service Suits
It has begun. Sigh. FYI, - paul http://www.techweb.com/wire/story/TWB2211S0014
Re: Internet SYN Flooding, spoofing attacks
CC'd to NANOG, maybe we can move this there. On Fri, 11 Feb 2000, Paul Ferguson wrote: > It would allow the attacks to be traced back to the zombies (in > the case of these DDoS attacks), and the perpetrators to be traced > back and identified. To make that easier, what is needed is something associated with a downstream interface that is a part of the configuration itself, not a separate access-list. This makes it much easier to track on a large box with many hundreds of customer links and so forth. Something like so: interface XXXm/n/p.q description whatever customer encaps ... ip address x y ip allow-source blocks-that-are-valid ip allow-source ...more-blocks- so on and so forth. /vijay
Re: Internet SYN Flooding, spoofing attacks
[EMAIL PROTECTED] wrote: > > On Fri, 11 Feb 2000 16:35:18 EST, Paul Ferguson said: > > Do you think that if RFC2267 was advanced as a BCP that > > it would carry more weight, and therefore more ISP's would > > implement RFC2267-style filtering? Coupled with the latest > > denial of service attacks? > > On the one hand, I think it would make a good candidate for BCP. It seems > to be similar in tone with RFCs 2502 and 2644. I'd have to re-read it to > see if it would need any textual changes, or if it's OK as it is. > > I was talking to a co-worker on this topic, and his exact quote was > "We have our s--t more together than most sites, despite our best > efforts". The problem is that he was right - our site may have clue, > but there's a lot of uneducated sites out there. > > Does anybody have statistics on how effective RFC2350 (Expectations > for Computer Security Incident Response) was? Or RFC2502 (Anti-Spam > Recommendations for SMTP MTAs)? Or RFC2644 ( Changing the Default for > Directed Broadcasts in Routers)? It would seem reasonable that moving > 2267 to BCP should have a similar effectiveness... Ever since Paul and I wrote 2267, I've heard from ISPs and equipment vendors, letting me know they'd implemented our recommendations. Lots of folks are doing it because they understand they should do their part. As for 2644, that one has only been out there a short time. It's not clear how many people have noticed it yet. This document has two target audiences, vendors and ISPs/users. Some vendors made the change even before I wrote the document. Router Requirements (1812) have mandated devices have an on/off switch for this feature for a long time. I would hope that all manufacturers at least provided the config option. I hope the vendors who haven't changed their defaults will get to this soon. Many clueful network operators also took the time to ensure their networks were clean. The problem with directed broadcasts is that EVERY routing device really has to be checked, since with CIDR you really don't know what comprises a broadcast. Network operators, especially, need to spend the time to check the configurations on their equipment. Awareness of this issue needs to be raised. As with ingress filtering, everyone needs to do their part. Unfortunately, it may be threats of negligence lawsuits that ultimately motivates some to take heed. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com
Re: Internet SYN Flooding, spoofing attacks
Vijay, We (at least cisco, anyways) already have a knob for this: [no] ip verify unicast reverse-path We call it Unicast RPF. See also: Craig Huegen's very useful web page on minimizing the effects of DoS attacks: http://users.quadrunner.com/chuegen/smurf.cgi Cisco: Distributed Denial of Service (DDoS) News Flash, February 9, 2000 http://www.cisco.com/warp/public/707/newsflash.html Dave Dittrich's (University of Washington) very good analysis of the recent DDoS attack tools. http://www.washington.edu/People/dad/ NIPC (National Infrstructure Protection Center), TRINOO/Tribal Flood Net/tfn2k stuff: http://www.fbi.gov/nipc/trinoo.htm "Handling A Distributed Denial of Service Trojan Infection: Step-by-Step." http://www.sans.org/y2k/DDoS.htm CERT (Computer Emergency Response Team at CMU) http://www.cert.org/ Cisco: Internet Security Advisories http://www.cisco.com/warp/public/707/advisory.html Characterizing and Tracing Packet Floods Using Cisco Routers http://www.cisco.com/warp/public/707/22.html Cisco Product Security Incident Response (PSIRT) http://www.cisco.com/warp/public/707/sec_incident_response.shtml "Essential IOS" - Features Every ISP Should Consider http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip Know your enemy: Script Kiddies http://www.enteract.com/~lspitz/enemy.html Cisco Flow Logs and Intrusion Detection at the Ohio State University http://www.usenix.org/publications/login/1999-9/osu.html If anyone else has useful links (it doesn't matter who is the vendor, whatever), please let me know. - paul At 09:01 PM 02/11/2000 -0500, Vijay Gill wrote: >CC'd to NANOG, maybe we can move this there. > >On Fri, 11 Feb 2000, Paul Ferguson wrote: > > > It would allow the attacks to be traced back to the zombies (in > > the case of these DDoS attacks), and the perpetrators to be traced > > back and identified. > >To make that easier, what is needed is something associated with a >downstream interface that is a part of the configuration itself, not a >separate access-list. This makes it much easier to track on a large box >with many hundreds of customer links and so forth. > >Something like so: > >interface XXXm/n/p.q >description whatever customer >encaps ... >ip address x y >ip allow-source blocks-that-are-valid >ip allow-source ...more-blocks- > >so on and so forth. > >/vijay
Re: Internet SYN Flooding, spoofing attacks
On Fri, 11 Feb 2000, Paul Ferguson wrote: > Vijay, > > We (at least cisco, anyways) already have a knob for this: > > [no] ip verify unicast reverse-path > > We call it Unicast RPF. This only works on single homed customers. Due to asymmetric routing, the customer can source _valid_ ip addresses from an ip source address that is not routed over that interface. I too would prefer some sort of magic unicast RPF, but the best compromise is the built-in access filter. The solution must be general enough to work for multihomed, defaulting out customers with blocks from n providers, /vijay > See also: > > Craig Huegen's very useful web page on minimizing the effects > of DoS attacks: > http://users.quadrunner.com/chuegen/smurf.cgi > > Cisco: Distributed Denial of Service (DDoS) News Flash, > February 9, 2000 > http://www.cisco.com/warp/public/707/newsflash.html > > Dave Dittrich's (University of Washington) very good > analysis of the recent DDoS attack tools. > http://www.washington.edu/People/dad/ > > NIPC (National Infrstructure Protection Center), > TRINOO/Tribal Flood Net/tfn2k stuff: > http://www.fbi.gov/nipc/trinoo.htm > > "Handling A Distributed Denial of Service Trojan > Infection: Step-by-Step." > http://www.sans.org/y2k/DDoS.htm > > CERT (Computer Emergency Response Team at CMU) > http://www.cert.org/ > > Cisco: Internet Security Advisories > http://www.cisco.com/warp/public/707/advisory.html > > Characterizing and Tracing Packet Floods Using > Cisco Routers > http://www.cisco.com/warp/public/707/22.html > > Cisco Product Security Incident Response (PSIRT) > http://www.cisco.com/warp/public/707/sec_incident_response.shtml > > "Essential IOS" - Features Every ISP Should Consider > http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip > > Know your enemy: Script Kiddies > http://www.enteract.com/~lspitz/enemy.html > > Cisco Flow Logs and Intrusion Detection at the Ohio > State University > http://www.usenix.org/publications/login/1999-9/osu.html > > > If anyone else has useful links (it doesn't matter who > is the vendor, whatever), please let me know. > > - paul > > At 09:01 PM 02/11/2000 -0500, Vijay Gill wrote: > > >CC'd to NANOG, maybe we can move this there. > > > >On Fri, 11 Feb 2000, Paul Ferguson wrote: > > > > > It would allow the attacks to be traced back to the zombies (in > > > the case of these DDoS attacks), and the perpetrators to be traced > > > back and identified. > > > >To make that easier, what is needed is something associated with a > >downstream interface that is a part of the configuration itself, not a > >separate access-list. This makes it much easier to track on a large box > >with many hundreds of customer links and so forth. > > > >Something like so: > > > >interface XXXm/n/p.q > >description whatever customer > >encaps ... > >ip address x y > >ip allow-source blocks-that-are-valid > >ip allow-source ...more-blocks- > > > >so on and so forth. > > > >/vijay > > Vijay Gill |The (paying) customer is always right. [EMAIL PROTECTED], [EMAIL PROTECTED] | - Piercarlo Grandi http://www.gl.umbc.edu/~vijay | Eagles may soar, but weasels don't get These are my opinions only.| sucked into jet engines.
Re: Internet SYN Flooding, spoofing attacks
At 09:14 PM 02/11/2000 -0500, Vijay Gill wrote: >This only works on single homed customers. Due to asymmetric routing, the >customer can source _valid_ ip addresses from an ip source address that is >not routed over that interface. I too would prefer some sort of magic >unicast RPF, but the best compromise is the built-in access filter. The >solution must be general enough to work for multihomed, defaulting out >customers with blocks from n providers, No, that is a common misconception, or rather, an overstatement of a pretty easily described situation. It only breaks things in transit situations, and only in transit situations where you might not have the same forwarding path back to the source as you would via the same interface a packet came in on. This is a small percentage, I would thing, since the percentage of ISP's offering transit pales in comparison to all other "access" ISP's that do not. And in cases where ISP's _do_ offer transit, or have transit agreements, will they really do this on their transit interfaces? I think not. - paul
March COOK report Summary ONLY /Diff serv interview and 10 Gig Estandards/
GIGABIT ETHERNET RIDES ECONOMY OF SCALE AS IT ERASES LAN WAN BOUNDARY GIGABIT ETHERNET MAKES NETWORK LESS COMPLEX, EASIER TO MANAGE -- 10 GIG STANDARDS WILL DEMAND CHOICES AFFECTING ATM SONET WAN FUNCTIONALITY, pp. 1- 10 We interviewed Dan Dov Principal Engineer for LAN physical Layers with Hewlett-Packard's networks division and Mark Thompson product marketing manager for HP's ProCurve Networking Business on December 6. In Smart Letter 30 on 12/9/99 David Isenberg wrote the following very good summary of why Gigabit Ethernet is hot. "Since there are many more LANs than WANs, GigE, due to its Ethernet LAN heritage, has huge economies of scale. (Every flavor of Ethernet that has hit the marketplace has slid down a 30% per year price reduction curve.) GigE's use in both LAN and WAN gives greater scale yet. Plus by erasing the LAN/WAN boundary, GigE decreases the complexity of the network, making it even stupider, easier to manage and easier to innovate upon. So it looks like the Stupid Network will be built of GigE over glass." In the Interview Dov takes us through the technology reasons for Ethernet's increase in speed as its importance in LANs has grown and LANs themselves get larger and more bandwidth hungry. Ethernet, in short, is leveraging its ubiquity, low cost and open standards on the back of the growing importance of the Internet and its increased bandwidth. In doing so it is playing a significant role in making new industries like Application Service provision possible. Dov concludes that "the reason that the Ethernet succeeded as well as it has, its simplicity. Ethernet is a very simple, yet elegant protocol. But because of its simplicity, it's extremely inexpensive to develop and to manufacture Ethernet-compliant devices." Many people are taking gigabit Ethernet and applying it to wide area networking because of its simplicity, ease of access and simplicity of its framing. In its relationship between volume and pricing Gigabit Ethernet offers significant values. Gigabit Ethernet initially was being installed in the local area network to provide interconnection between boxes that were connecting 100 megabits, and 10megabits, to the desktop. The volume of that kind of traffic quickly becomes very large. For these applications over short distances, compared to OC-24, gigabit Ethernet is actually cheaper, even though it provides more bandwidth. What people started to realize, because of the volume of gigabit Ethernet traffic that was going out and the relative simplicity of it, the cost of gigabit Ethernet ran under cut that of OC-24 pretty quickly. And the result is that people who are making the decisions as to what will be used to hook LANs to each other and to the Internet started deciding to go with gigabit Ethernet, rather than with the OC-24 or OC-48. Gigabit Ethernet's application is at the periphery of the internet Therefore it is not being looked tofor the elimination of SONET add/drop multiplexers. With ten gigabit Ethernet some people are proposing to basically take the ten gigabit Ethernet media access controller, the MAC, and packetize the data, just like we currently do in Ethernet at ten times the rate. But they then want to send it into a SONET framer. The SONET framer will then take that data and chop it up and put it into the SONET frame. The framer will send it across the network and when it gets received on the other side, it will be effectively deframed. There are also people that are more focused on taking the current, simple Ethernet approach, which is just, take the data, put it onto an optical fiber and ship it on across the link. They don't want to get into the complexity of SONET framing and so on. HP's Thompson offered the following analogy: " It's sort of like the subway system versus the inter city train system. Once, historically, if you wanted to ride the "train" from the center of one city to the center of another, you rode the subway system to get out to the train station, took a train and then subway back into a city. So what we're talking about now is Ethernet making it robust enough and fast enough so that your subway car can simply ride from one city to the next and that you don't have to change the vehicles that are riding on the tracks, the fiber, in the meantime." In other words a simplistic design that would work for the people who are working in the local area networks would also go for people who wanted to do optical transmission with Ethernet framing cross-country" The interview concludes with a discussion of the issues being faced in the development of 10 gigabit Ethernet standards. ~~~ EXPLOSION IN CAPACITY CHASED BY EXPLOSION IN USE FIBER TO THE HOME FROM HP ORACLE AND POWER COMPANIES FOR LESS THAN $15 A MONTH -- ABOVENET ON THE NEED TO OWN FIBER pp. 10, 27 ROL
Apologies for double send !
I had one queued for IETF and stopped the transmission from eudora before it completed. Or so I thought! I had not finished my edits on it . The two pieces were not the same. But I sincerely regret letting the first escape eudora said it was still queued. Any way I sent it here primarily because I thought the Kathy Nicols interview would be interesting for those not in the diffserv WG. Rest assured I have no intention of adding ietf to my monthly distribution. again my apologies - this is not the place to suffer hand eye brain coordination lapse. ARGH - AND NOW FOR 20 MINUTES I CAN'T CONNECT WITH EARTH LINK'S SERVER.. ARGH - I AM TRYING The COOK Report on Internet Index to 8 years of the COOK Report 431 Greenway Ave, Ewing, NJ 08618 USA http://cookreport.com (609) 882-2572 (phone & fax) Battle for Cyberspace: How [EMAIL PROTECTED] Crucial Technical . . . - 392 pages just published. See http://cookreport.com/ipbattle.shtml
Re: Internet SYN Flooding, spoofing attacks
On Fri, 11 Feb 2000 21:09:47 EST, Paul Ferguson said: > We (at least cisco, anyways) already have a knob for this: > > [no] ip verify unicast reverse-path > > We call it Unicast RPF. Paul: What are the chances of setting up "The Next Release" of IOS so that for simple configs (for example, a customer backbone and one upstream link to a provider) the knob would automagically default to Doing The Right Thing? I of course am writing as a non-expert on the innnards of IOS, and I'm expecting flame-fests regarding "simple config" and "Right Thing". No, it's not a total fix. It won't fix everything. It may not even be possible. But it certainly would be nice. ;) Valdis Kletnieks Operating Systems Analyst Virginia Tech
SUMMARY: flooding and spoofing attacks
Hello: I try to summarize about what is going on. Please let me know if I miss something. I will put this later into http://ittf.vlsm.org Clue alert... the recent attacks were not TCP SYN Floods (Warfield). - Place to discuss: NANOG (The North American Network Operators' Group) Milis: http://www.nanog.org/mailinglist.html - RFCs 2267 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing http://www.ietf.org/rfc/rfc2267.txt "There is no assumption implied that RFC2267 filtering is needed -- it is required. What good is it if one or two or 300 people do it, and another 157,000 do not? (Ferguson)" "... while there are certainly clueless ISPs out there, I suspect that on the average they're more clueful about the net than the typical end site (Bellovin)." 2350 Expectations for Computer Security Incident Response http://www.ietf.org/rfc/rfc2350.txt 2502 Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment http://www.ietf.org/rfc/rfc2502.txt 2644 Changing the Default for Directed Broadcasts in Routers http://www.ietf.org/rfc/rfc2644.txt - Further references: http://xforce.iss.net/alerts/advise40.php3 http://www.cert.org/advisories/CA-2000-01.html - Analysis of TFN (Tribe Flood Network): http://staff.washington.edu/dittrich/misc/tfn.analysis http://staff.washington.edu/dittrich/misc/trinoo.analysis http://staff.washington.edu/dittrich/misc/stacheldraht.analysis - Craig Huegen's on minimizing the effects of DoS attacks: http://users.quadrunner.com/chuegen/smurf.cgi - Distributed Denial of Service (DDoS) News Flash, http://www.cisco.com/warp/public/707/newsflash.html - Dave Dittrich's analysis of the recent DDoS attack tools. http://www.washington.edu/People/dad/ - NIPC (National Infrstructure Protection Center), TRINOO/Tribal Flood Net/tfn2k stuff: http://www.fbi.gov/nipc/trinoo.htm - Handling A Distributed Denial of Service Trojan Infection: Step-by-Step. http://www.sans.org/y2k/DDoS.htm - Internet Security Advisories http://www.cisco.com/warp/public/707/advisory.html http://www.cisco.com/warp/public/707/22.html http://www.cisco.com/warp/public/707/sec_incident_response.shtml http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip - Know your enemy: Script Kiddies http://www.enteract.com/~lspitz/enemy.html - Flow Logs and Intrusion Detection at the Ohio State University http://www.usenix.org/publications/login/1999-9/osu.html - Achtung LAWyers! http://www.techweb.com/wire/story/TWB2211S0014 - The size of the internet: 72,000,000 domains/hosts. http://www.isc.org/ds/ - Sources (tararengkyu ka): Steve Bellovin Paul Ferguson Valdis Kletnieks April Marine Michael H. Warfield tabe, -- - Rahmat M. Samik-Ibrahim -- VLSM-TJT -- http://rms46.vlsm.org/ - - Always select ShutDown from the StartMenu - M$Windows after crash
Re: Internet SYN Flooding, spoofing attacks
At 11:33 PM 02/11/2000 -0500, [EMAIL PROTECTED] wrote: >What are the chances of setting up "The Next Release" of IOS >so that for simple configs (for example, a customer backbone and >one upstream link to a provider) the knob would automagically default >to Doing The Right Thing? I of course am writing as a non-expert on >the innnards of IOS, and I'm expecting flame-fests regarding "simple >config" and "Right Thing". > >No, it's not a total fix. It won't fix everything. It may not >even be possible. But it certainly would be nice. ;) Something like "ip default clueless"? Just kidding. ;-) Well, overwhelming support for any suggested default mod is always considered. Really. Overwhelming is the operative word here. We (as do many other vendors, I would suggest) operate under the "Principle of Least Astonishment": How many people would we screw if we changed the defaults of a particular command? If overwhelming community support were to set the tone for a default change, we would certainly not take it lightly. :-) - paul
Re: 1601bis: The Charter of IAB
Brian E Carpenter wrote: > I can read your words, but I really can't understand your concerns. > You seem to be worrying about dragons that I can't see. Happy New > Year, anyway. Hm... your reply is exactly my concern! Your answer is just based on "can not understand" and not based on any document or past history. Therefore, I would like to see more things in written. Is this by the way how the board in handling appeals? Who is the current IANA and RFC-Ed (chair/head/whatever)? I also believe what Klensin wrote is still valid: .. [... 22 Feb 1996 ... skipping voting out of existence, fine lunches and dinners, and irresolvable controversy pronouncements...] For questions of process, there is really a jury problem, not a technical or architectural expertise one. The IAB membership may have no special competence to make decisions on process matters and, if they were involved in the initial proposals in any way, they may be contaminated relative to making fair choices. I suggest that, for process questions, the right appeals body is a jury-like group that is chosen exactly the way the Nomcomm is chosen -- volunteers from the IETF participant pool and then at random, with no sitting IAB or IESG (or, I'd think, ISOC Trustees) members permitted to volunteer. I don't have an opinion as to whether we pick an appeals panel for a year just in case we need them or pick them only when a sufficient process appeal arises. It is not clear to me that it makes much difference -- except that, if they were picked on demand, we might just take the attendance list from the last few meetings and draw people from it on an "attendance subjects one to the risk on volunteering" basis. That has some drawbacks but some appeal. For the technical error questions, it is still not clear to me that IAB is the right appeals body, especially if they were active in formulating the position under appeal or an alternate to it. A randomly-chosen jury might still work, but might well not have the right technical expertise. As one possibility, we could move toward a formalized blue-ribbon review and mediation panel, with members of that panel being chosen by IESG, the WG leadership, and the individual or group launching the appeal. If it was appropriate to populate that panel with IAB members, that would be fine, but the review itself would not be an IAB responsibility. If the panel didn't behave fairly, that becomes a procedural question, and the appeals board outlined above takes over. It seems that the only thing that I can do is keeping records on who's who were on the board (+when), plus who were the nomcom who had elected them. Let the Vulcans, Klingons, and Ferengis make the final judgements in the next millennium. tabe, -- - Rahmat M. Samik-Ibrahim -- VLSM-TJT -- http://rms46.vlsm.org/ - - Always select ShutDown from the StartMenu - M$Windows after crash
Re: IAB Technical Comment on the Unique DNS Root
David and all, I agree completely David. You might want to let the IETF know this as they obviously don't or are now using the IETF drafting process as a political forum... But than again Donald Eastlake (Draft in questions author) has always been of a single root structure bent. David Schutt wrote: > This single root argument is getting a bit tired. > > Understandably, people are worried about name space collisions, > they would prefer that there be only one com zone. A single root > is probably the most convenient way to achieve that, but it's not > the only one. > > I've been trying out some software that lets me pick and choose where > I'll get name resolution for any particular domain, and it works just fine. > I can mix and match any way I want, use the legacy root servers, add local > TLD's, add public TLD's not referenced by the roots, or even specify name > servers for all TLD's and not reference the roots at all. > > A single root is an administrative convenience, makes it easy for everyone > to keep track of who is serving what TLD's. It's convenient enough that > most people find it much easier to continue to reference the current roots. > Elevating that to a technical necessity is stretching things a bit, > though. > > Ultimately, anyone can make the decision to get their resolution service > from a different .com TLD, and it would be difficult if not impossible to > stop them. > > The question is, why would anybody want to? > > And if no one would want to, why make a big deal out of it? > > David Schutt > > On Thu, Feb 10, 2000 at 10:44:29PM -0500, !Dr. Joe Baptista wrote: > > Looks like the IAB is a bit nervose these days. > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Internet Architecture Board Working Group of the >IETF. > > > > Title : IAB Technical Comment on the Unique DNS Root > > Author(s) : IAB > > Filename: draft-ietf-iab-unique-dns-root-00.txt > > Pages : 5 > > Date: 07-Feb-00 > > > > To remain a global network, the Internet requires the existence of a > > globally unique public name space. The DNS name space is a > > hierarchical name space derived from a single, globally unique root. > > This is a technical constraint inherent in the design of the DNS > > system. Therefore it is not technically feasible for there to be > > more than one root in the public DNS system. That one root must be > > supported by a small number of coordinated root servers, and > > administered by a unique naming authority. > > Put simply, deploying multiple public DNS roots would raise a very > > strong possibility that users of different ISPs who click on the same > > link on a web page could end up at different destinations, against > > the will of the web page designers. > > This does not preclude private networks from operating their own > > private name spaces, but if they wish to make use of names uniquely > > defined for the global Internet, they have to fetch that information > > from the global DNS naming hierarchy, and in particular from the > > coordinated root servers of the global DNS naming hierarchy. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-iab-unique-dns-root-00.txt Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail [EMAIL PROTECTED] Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
