Fw: New member seeks direction
-Original Message- From: [EMAIL PROTECTED] from Dan Melendez [mailto:[EMAIL PROTECTED]] Sent: Monday, February 14, 2000 11:19 AM To: [EMAIL PROTECTED] Subject: New member seeks direction Hello, I am interested in the following topics: 1) Internet television(all related tech info) 2) High speed Internet fundamentals 3) 801.11 DS cards (11mbps) If you can refer me to some web files, I would greatly appreciate it. Thank you for your time and make it a great day. dan Dear Dan Subject : ( PayTVs + FreeTVs + Internet ) Satellite Receiver PC Card We would like to introduce PC cards for satellite Internet/TV on PC, as an official PC-Card supplier of EuropeOnline etc. For its specifications and company introduction, pls surf WWW.pentamedia.com FOB Korea Prices of PC cards satellite Internet + FTA TV + PayTV (Pent@VISION-CI) - sample(1~5) price : U$ 300 / unit - over 1,000 pcs : U$ 270 / unit satellite Internet + FreeToAir TV (Pent@VISION) - sample(1~5) price : U$ 250 / unit - over 1,000 pcs : U$ 230 / unit satellite Internet (Pent@NET) - sample(1~5) price : U$ 160 / unit - over 1,000 pcs : U$ 130 / unit satellite Internet (Pent@U : USB type) - sample(1~5) price : U$ 270 / unit - over 1,000 pcs : U$ 200 / unit We also do satellite internet fundamentals including IP gateway to RSMS, RF etc. Please let me know your requirements. Mike KIM / PentaMedia Co., Ltd. DEVELOPER MANUFACTURER of Satellite Internet / TV Receiver PC card Email : [EMAIL PROTECTED] Tel +82.2.3463.3164 Mobile +82.19.320.0106 Fax +82.2.3461.9486
Re: Internet SYN Flooding, spoofing attacks
Date:Mon, 14 Feb 2000 00:37:29 -0500 From:"Donald E. Eastlake 3rd" [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | I think that making egress filtering a BCP, applying community | pressure, bringing law suites, etc., will be about as effective | at eliminating forged source address packets on the Internet as | similar measures have been in eliminating open SMTP relays... | | They help, but not much. I'm not sure there is a good analogy there.There's no good purpose in sending packets with incorrect source addresses I can think of, and stopping the practice is the basic intent of the filters. The only justification for not doing it is cost - and then just just becomes a part of the cost benefit analysis - will it cost us more or less to implement this? On the other hand, SMTP relays are not a problem anyone cares about of themselves - just the contrary in fact, smtp relaying can be a very useful function to have available (eg: you're travelling with your laptop and have a bunch of mail waiting to go - you get a connection for a few minutes between flights, but your normal home relay is unreachable right now - being able to pick some other friendly relay and simply park your mail on it can be a real advantage). The thing to be fixed there is the unwanted spam that is also using the services of the relay, that is, it isn't the relay that is really the issue, it is the spam, if all the spam went away, so-one would care about relays any more (other than now to regret that whereas previously most sites would be happy to relay mail now far fewer are). Further, it isn't at all clear that preventing relaying will do much, if anything, to stop spam - certainly blocking receiving mail from relays will currently cut the amount of spam you receive a lot - but that's because comparatively few people do that, and so the spammers are content to ignore them and just continue making use of the relay services that they can latch onto. But should everyone stop relaying, does anyone really believe that all the spammers are simply going to decide that there is no point continuing, and all just go away? Really? Even if it means that the spammers have to send all their mail directly, they'll do it as long as the benefit from sending spam (at least appears to) outweigh the costs. So, the two issues are really not much alike - in one there's no good purpose to be served by not blocking outgoing packets with bogus source addresses, in the other there are lots of philosphical reasons for not stopping relaying - hence there are some of us quite willing to do one but not the other. Spam is a social problem, and needs to be solved by social/legal means, not technical ones (there is no technical difference between spam and any other mailing list mail - it all looks the same - the only difference is whether the recipient wanted to receive it or not.) But we're technocraats, all our tools are technical ones, so it is easy to see how we grasp at any technical solution we think might help - the only technical solution we've been able to find that seems like it might help (a passing illusion really). Unfortunately, the appearance of a technical solution reduces the pressure on the social/legal types to come up with a solution that really works - if we all would just admit that technically there's nothing that can really be done ablut spam, and simply stopped trying at all (allow it all through) the user pressure to get this problem solved some other way would be much much greater... On the other hand, sending packets with an incorrect source address is a technical problem - those packets don't meet the IP specs - what is supposed to be in that field is the IP address of the sending node. This is a problem entirely open to a technical solution. kre
Re: IETF Adelaide and interim meetings for APPS WGs
From: Keith Moore [EMAIL PROTECTED] ... RFC 2418 states: Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings. ... - This applies to all face to face meetings held for the purpose of conducting working group discussion and to which the working group is invited, even if labelled "informal" or otherwise labelled to distinguish them from official working group meetings. I'm not a lawyer, but that sounds like it might conflict with the U.S. Constitution's provisions concerning freedom of assembly. It also sounds hard to police; if some working group participants encounter each other in an airport waiting room, are they not allowed to talk business? What about participants who work for the same outfit and see each other daily? Are you going to apply the same rules to meetings of the IAB and IESG? You could doubtless fix those modest hassles with the wording of this demand that RFC 2418 be honored, but what is the point? Unless you going to slide the IETF the rest of the way into the ITU/IEEE/ANSI swamp, won't the mailing lists continue to be the only official forums for the working groups? Won't the working group meetings continue to be effectively informal, slightly more than social gatherings? In other words and politically correct pretense asside, the IETF is not an international organization. Despite its posturing, the IETF is a U.S. or perhaps North American organization that welcomes non-U.S. participants and occasionally spends a lot of its U.S. participants' time and money to try to make people outside of North America feel welcome. If the IETF did honestly aspire to be an international organization, it would need the characteristics of the ITU (e.g. translators and high prices for documents). Do you think that would be a good thing? (I've never attended an IETF working group meeting, despite working group participation for a lot of years. I've never felt the lack as far as technical things go. I can't find words in RFC 2418 that say that the mailing list is the authoritative forum, which strikes me as a terrible omission or catastrophic de facto change.) Vernon Schryver[EMAIL PROTECTED]
Re: IETF Adelaide and interim meetings for APPS WGs
At 05:45 PM 2/14/00 -0700, Vernon Schryver wrote: Unless you going to slide the IETF the rest of the way into the ITU/IEEE/ANSI swamp, won't the mailing lists continue to be the only official forums for the working groups? Won't the working group meetings continue to be effectively informal, slightly more than social gatherings? I realize that you have not been (ahem) a regular attendee at IETF meetings, but in my experience this has never been the case. Yes, we do most of our work on mailing lists, and we check meeting consensus on mailing lists before declaring it sealed in blood. But Face to Face meetings have always been places where high bandwidth discussions take place to clarify and progress work which is also being done on the mailing list. They are official meetings. So, by the way, are interim meetings, under RFC 2418. We could discuss major initiatives which have made effective use of them the entire SNMP development, the development of RSVP and Diff-serv, the development of OSPF, and many more. PPP development has happened as much at the interoperability workshops held by Pac Bell and the PPP Consortium as they have at IETF meetings. Declaring an interim meeting to make progress is a Good Thing, and we don't see a problem with that. But we need to make sure that the process is open to all who choose to participate, and to that end the authors of RFC 2418 specified that there needed to be AD approval, sufficient notice, a strong agenda, and minutes just as there are at the plenary meetings. Declaring an interim meeting for the purpose of avoiding a plenary meeting is a slap in the face to the many engineers who come from all over to the interim and plenary meetings that we have had for lo these 14 years. They have paid quite a bit of money and time to be intimately involved in the process. It would be much easier, from a planning perspective, to have the meetings in one or two spots, as the ITU does in Geneva, but we have always worked on an ethic that says "if I am contributing to the work, the meeting must occasionally be near me." One sixth or more of our contributors come from Europe. A relatively small contingent comes from the South Pacific. Quite a large percentage come from North America. Hence, we put about one meeting in six in Europe and most of our meetings in North America. Is it not fair to put one meeting in 47 in the South Pacific? And why is it not an affront to those who have faithfully come from there, have contributed and chaired working groups from there, to complain about doing once what they have been doing for over a decade?
Re: Internet SYN Flooding, spoofing attacks
Phil Karn wrote: tomorrow demands. And, agreed, bogus source IPs _does_ at present time look like nothing but the devils work. But in, say, 10 years a new flashy techology could be requiring that you have the ability to stamp packets with other IPs than your own. Unfortunately, back in year 2000, somebody put in There already are some perfectly legitimate reasons to send packets with "alien" IP source addresses. Mobile IP is the best example, but various virtual private networking schemes also do this. For example, I have a VPN set up over my cable modem so I can have a block of static IP addresses for my home network. I had to do some work to evade the $#@!! source IP address ingress filtering in my cable network. I do it by tunneling the upstream packets through a machine at work. Yes, and you chose the CORRECT solution. Think about it... VPN in most cases also means encryption, and at that probably back to a central site. Gabriel wrote RFC 2344 for reverse tunnels, and it does essentially what you did. Being forced to tunnel not only increases the size of each packet, but also entails suboptimum routing and reliance on yet more network elements. I use the new Linux policy routing mechanisms to tunnel only those packets that have to be tunneled, which helps. But it would sure be nice if I didn't have to tunnel my outbound packets at all. Sorry. You're at the point where technology meets policy. Fact is, your host identifier in the IP stack is the source IP address. Enforcing the validity of that identifier has become necessary. Source address ingress filtering is one of those ideas that seems like a good one when you first think about it, but it just doesn't pan out. It interferes with some perfectly legitimate activities, it doesn't really stop the bad guys, and it deflects attention away from the real solutions. The case for "legitimate use" of source spoofing has not been sufficiently made. Operational reality is such that it's not sustainable. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com
Re: Who is interested in wireless cards for the Adelaide IETF meeting?
On Tue, Feb 15, 2000 at 12:57:57PM +1030, Mark Prior wrote: The package being offered is a WaveLAN IEEE Turbo 11Mbps PC card for AU$276.36 (approx US$175). Drivers are available from Lucent for (at least) Windows 95, 98, NT, CE, 2000, MacOS and Linux. Could people that are interested please send expressions of interest to [EMAIL PROTECTED] so I can let Lucent know how many cards are needed. I'd be interested in borrowing a pair of wavelan cards. -dorian
Re: IETF Adelaide and interim meetings for APPS WGs
From: "Steven M. Bellovin" [EMAIL PROTECTED] ... I'm not a lawyer, but that sounds like it might conflict with the U.S. Constitution's provisions concerning freedom of assembly. (a) The U.S. constitution applies to the Federal government (and sometimes to the state governments); it does not apply to private groups. How arms-length is the connection between the IETF and the Federal government? No more NFS money, but what about the ITU entanglements? Could Civil Service employees find it hard to get travel requests approved for attending meetings of an outfit that gets carried away in its rules and regulations on who can talk to whom? (b) No one ever said that these folks can't meet; they just can't do it under the imprimatur of the IETF. I read the dictum as stronger than that. Didn't it say something about prohibiting meetings that are nominally not WG meetings for the purpose of subverting RFC 2418? That's why I quoted } or otherwise } labelled to distinguish them from official working group meetings. That's the part that I don't see as enforcable or wise, although I sympathize with the motivation. ... The point is that some things are better accomplished in a high-bandwidth environment. Yes, that's often true, but the talk of "high-bandwidth" has always been exaggerated. As I've said, I've never attended an IETF meeting, but I've read an awful lot of minutes over the last dozen years. I haven't read many that showed evidence effective use of that high bandwidth. (Perhaps I'm too unimpressed by simply letting people have their say before continuing with what was inevitable.) ... If the IETF did honestly aspire to be an international organization, it would need the characteristics of the ITU (e.g. translators and high prices for documents). ... I'm afraid I don't follow the logic of your penultimate sententce. The current schedule has about 1 meeting out of 3 outside of North America. The locations of meetings do not make the IETF international any more than Congressional junkets do the same for Congress. (That there is no need to specify which congress I'm talking about is emblematic of the reality that contradicts the politically correct posturing.) The U.N. and the ITU are international organizations. I've attended as many meetings of them as of the IETF, so maybe my distinct impression that they do things differently than the IETF is mistaken. Let's see, how many RFC's are not in English? How many WG meetings or mailinglists? That the IETF is de facto an U.S. outfit is not by itself a bad thing. There are and for centuries have been many organizations in many places that are not really international, but that welcome distant participants. It is bad to refuse to call a "digging implement adapted for being pushed into the ground with the foot" a spade. ] From [EMAIL PROTECTED] Mon Feb 14 18:54:53 2000 ]... Yes, we do ] most of our work on mailing lists, and we check meeting consensus on ] mailing lists before declaring it sealed in blood. But Face to Face ] meetings have always been places where high bandwidth discussions take ] place to clarify and progress work which is also being done on the mailing ] list. They are official meetings. "High-bandwidth" does not need official sanction. You can have productive technical discussions without any official sanction, and usually better without the burdens of officialness. What is the difference between "official but nothing is signed in blood" and "where things are signed in blood"? If nothing can be finally decided (i.e. signed in blood), what is the substance, of "official" besides ensuring that accountants accept expense reports? ] So, by the way, are interim meetings, under RFC 2418. We could discuss ] major initiatives which have made effective use of them the entire SNMP ] development, the development of RSVP and Diff-serv, the development of ] OSPF, and many more. PPP development has happened as much at the ] interoperability workshops held by Pac Bell and the PPP Consortium as they ] have at IETF meetings. Those are good examples of the distinction between engineering and official meetings. The PPP development I saw at Pac Bell's San Ramon facility was a matter individuals talking semi-privately. The semi-formal discussions at the ends of the days announced but did not decide anything. Note also that at least some of those meetings did not have any IETF sanction. I wonder if the uglier parts of the SNMP saga would not have come out far better without one or two of the official IETF WG meetings. ] ... Declaring an ] interim meeting for the purpose of avoiding a plenary meeting is a slap in ] the face ... That's certainly true, but I don't see how you're going to
Re: Who is interested in wireless cards for the Adelaide IETF meeting?
On Mon, Feb 14, 2000 at 10:31:16PM -0500, Dorian Kim wrote: I'd be interested in borrowing a pair of wavelan cards. *sigh* apologies for not watching the cc: line. -dorian
Re: IETF Adelaide and interim meetings for APPS WGs
Let's see, how many RFC's are not in English? How many WG meetings or mailinglists? That the IETF is de facto an U.S. outfit is not by itself a bad thing. You seem to be making the assumption that the English language is the property of the USA. Perhaps, you have forgotten that the English language was spoken in a quite a lot of the world before the USA existed. Keith.
Re: Internet SYN Flooding, spoofing attacks
Robert Elz [EMAIL PROTECTED] wrote: I'm not sure there is a good analogy there.There's no good purpose in sending packets with incorrect source addresses I can think of, and stopping the practice is the basic intent of the filters. "In his early days at Intel, Andy Grove was approached by an employee who suggested the company start work on a personal computer based on its chips. Skeptical, he asked what a personal computer might do. The employee, searching for a good example, said it could be used to store recipes. Grove thought about the millions he'd have to spend on research, development, and marketing, then considered the imperfect but steady quality of an alphabetized loose-leaf binder. He finally passed on the idea and decided to concentrate on the lucrative business of supplying chips for traffic lights." It is rarely very easy to see what requirements the future will bring and particularly in this business you can't be sure what the technology of tomorrow demands. And, agreed, bogus source IPs _does_ at present time look like nothing but the devils work. But in, say, 10 years a new flashy techology could be requiring that you have the ability to stamp packets with other IPs than your own. Unfortunately, back in year 2000, somebody put in IP filters at all ISPs and now, 10 years after, these filters is so integrated a part of the ISP software that reprogramming would cost a fortune. Also consider the size of the group of Internet users that send out packets with incorrect source IPs. Using IP filters would be like illegalizing coffee because a fraction of the people on the earth is allergic to caffeine. - Anders Feder
Re: Internet SYN Flooding, spoofing attacks
Robert Elz wrote: There's no good purpose in sending packets with incorrect source addresses I can think of, and stopping the practice is the basic intent of the filters. Mobile IP would like to send out packets with the mobile node's home address, while it is attached to a network in a foreign domain. The home address is likely to look "incorrect" from the standpoint of such a filter. Plus I don't think the gain is worth the pain. I'd rather see a technology that actually solves the problem instead of swatting at gnats with a sledge hammer. What if routers could preferentially keep track of things like SYN packets and so on for a few seconds, and we had some traceback management software and security associations with our neighbors enough to do some automatic detection? It might cost 2% more for the memory buffers, geez I don't know. Regards, Charlie P.
Re: Internet SYN Flooding, spoofing attacks
tomorrow demands. And, agreed, bogus source IPs _does_ at present time look like nothing but the devils work. But in, say, 10 years a new flashy techology could be requiring that you have the ability to stamp packets with other IPs than your own. Unfortunately, back in year 2000, somebody put in There already are some perfectly legitimate reasons to send packets with "alien" IP source addresses. Mobile IP is the best example, but various virtual private networking schemes also do this. For example, I have a VPN set up over my cable modem so I can have a block of static IP addresses for my home network. I had to do some work to evade the $#@!! source IP address ingress filtering in my cable network. I do it by tunneling the upstream packets through a machine at work. Being forced to tunnel not only increases the size of each packet, but also entails suboptimum routing and reliance on yet more network elements. I use the new Linux policy routing mechanisms to tunnel only those packets that have to be tunneled, which helps. But it would sure be nice if I didn't have to tunnel my outbound packets at all. Source address ingress filtering is one of those ideas that seems like a good one when you first think about it, but it just doesn't pan out. It interferes with some perfectly legitimate activities, it doesn't really stop the bad guys, and it deflects attention away from the real solutions. In the case of MS-DOS (Multiple Source-Denial of Service) attacks like the ones we saw last week, we need to deploy better inter-router mechanisms to deal with congestion by moving the packet drop points as far upstream as possible toward the senders. And if these mechanisms can work for deliberate flooding attacks, they'll also deal with non-deliberate congestion. Phil
Re: Internet SYN Flooding, spoofing attacks
At 03:41 PM 02/14/2000 -0800, Charles E. Perkins wrote: Mobile IP would like to send out packets with the mobile node's home address, while it is attached to a network in a foreign domain. The home address is likely to look "incorrect" from the standpoint of such a filter. If I'm not mistaken (although my coauthor has tracked the mobile ip cruft more than have I), there is some notion of a tunneling mechanism from the first-hop mobile ip gateway, such that the bogon source is really never seen in that fashion (as a bogon). Again, I admit complete ignorance of mobile ip cruft. Plus I don't think the gain is worth the pain. I'd rather see a technology that actually solves the problem instead of swatting at gnats with a sledge hammer. Well, right now, you get swatted. Figure out a better way, and you'll stop getting swatted. - paul
Re: IETF Adelaide and interim meetings for APPS WGs
In message [EMAIL PROTECTED], Vernon Schryver writes : I'm not a lawyer, but that sounds like it might conflict with the U.S. Constitution's provisions concerning freedom of assembly. (a) The U.S. constitution applies to the Federal government (and sometimes to the state governments); it does not apply to private groups. (b) No one ever said that these folks can't meet; they just can't do it under the imprimatur of the IETF. It also sounds hard to police; if some working group participants encounter each other in an airport waiting room, are they not allowed to talk business? What about participants who work for the same outfit and see each other daily? Are you going to apply the same rules to meetings of the IAB and IESG? ?? I'll let the IESG speak for itself. The IAB does not meet physically except at IETF meetings. Instead, we have monthly conference calls. We do hold workshops (which is expressly provided for in RFC 1601); the last such workshop was in Utrecht. Not all IAB members attend all workshops; a number of outsiders are invited. You could doubtless fix those modest hassles with the wording of this demand that RFC 2418 be honored, but what is the point? Unless you going to slide the IETF the rest of the way into the ITU/IEEE/ANSI swamp, won't the mailing lists continue to be the only official forums for the working groups? Won't the working group meetings continue to be effectively informal, slightly more than social gatherings? The point is that some things are better accomplished in a high-bandwidth environment. In other words and politically correct pretense asside, the IETF is not an international organization. Despite its posturing, the IETF is a U.S. or perhaps North American organization that welcomes non-U.S. participants and occasionally spends a lot of its U.S. participants' time and money to try to make people outside of North America feel welcome. If the IETF did honestly aspire to be an international organization, it would need the characteristics of the ITU (e.g. translators and high prices for documents). Do you think that would be a good thing? I'm afraid I don't follow the logic of your penultimate sententce. The current schedule has about 1 meeting out of 3 outside of North America. --Steve Bellovin
Who is interested in wireless cards for the Adelaide IETF meeting?
Lucent will be making available 802.11 DS wireless technology for the forthcoming meeting in Adelaide. They have offered a similar deal to Nortel at the last meeting where IETFers can loan a card for the duration of the meeting and/or buy a card. They would like to get some idea of how many people attending the meeting would like to take up this offer so they can ensure they have sufficent stocks to meet the demand. The package being offered is a WaveLAN IEEE Turbo 11Mbps PC card for AU$276.36 (approx US$175). Drivers are available from Lucent for (at least) Windows 95, 98, NT, CE, 2000, MacOS and Linux. Could people that are interested please send expressions of interest to [EMAIL PROTECTED] so I can let Lucent know how many cards are needed. Thanks, Mark.
Re: Internet SYN Flooding, spoofing attacks
"Charles E. Perkins" wrote: Robert Elz wrote: There's no good purpose in sending packets with incorrect source addresses I can think of, and stopping the practice is the basic intent of the filters. Mobile IP would like to send out packets with the mobile node's home address, while it is attached to a network in a foreign domain. The home address is likely to look "incorrect" from the standpoint of such a filter. Mobile IP took advantage of a convenient occurrence of the Internet as it was, believing all routing would occur based on destination address only. That is no longer a valid assumption. In response to this changing world, the Mobile IP folks went back to the drawing board and created RFC 2344. I suggest folks go implement it. Tunnels are the topologially correct answer when you're trying to do something like Mobile IP. Mobile IP also took advantage of directed broadcast in the original designs, though it is less clear whether anyone actually implemented using it. See the discussion on this topic in RFC 2644 for more details on that. Plus I don't think the gain is worth the pain. I'd rather see a technology that actually solves the problem instead of swatting at gnats with a sledge hammer. Routing based on source and destination address in combination is already a possible approach for traffic shaping and firewalling purposes. What if routers could preferentially keep track of things like SYN packets and so on for a few seconds, and we had some traceback management software and security associations with our neighbors enough to do some automatic detection? So, you'd prefer to have the routers on the Internet be stateful devices? Somehow, I thought we really didn't want to go there. There are known issues with some equipment which does fast switching based on setting up "flows." A design that several folks have come up with relies on a general purpose processor to program "flow" information into a silicon-assisted fabric. Such implementations suffer greatly at the hands of a DoS attack, where flows are coming in at extremely high rate. State isn't necessarily the answer. It might cost 2% more for the memory buffers, geez I don't know. The memory cost isn't the issue. You're going to pay more for a lot of ASICs to be doing that operation at wire speed. The work to do what you suggest adds considerably more complexity than doing filtering at wire speeds in ASICs (a capability which is available on products shipping today). -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com
RE: Internet SYN Flooding, spoofing attacks
Steve, Let's be clear: a DOS attack is something the end point itself can do very little to prevent, since it usually fails or succeeds upstream of that end point. Therefore, the end point relies on its upstream ISPs to "do the right thing" and indeed, each of those ISPs relies on other ISPs to similarly filter. Each point can mitigate the damage to the point where in sum these attacks become ineffective. Each RPF check can remove bad packets. Each violated ACL can remove and LOG the bad packets. These are the best controls available today. Shall we not use them? Also, we raise the bar from some kid injecting packets to someone breaking into an ISP, a more difficult challenge (at least a level 3 attack on my Dungeons and Dragons guide of Hackers ;-). - Original Message - From: Stephen Kent [EMAIL PROTECTED] Newsgroups: cisco.external.ietf Sent: Saturday, February 12, 2000 1:55 PM Subject: Re: Internet SYN Flooding, spoofing attacks Paul, 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? it is a bad thing if one bases defenses on the assumption that ALL the access points into the Internet will perform such filtering, and will do it consistently. Even if all ISPs, and down stream providers performed the filtering, there is no guarantee that attackers could not circumvent the filter controls, either through direct attack on the routers, or through indirect attack on the management stations used to configure them. I'm just saying that while edge filtering is potentially useful, it would not be a good idea to assume that it will be effective. 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. In talking with the operations folks at GTE-I, they expressed concern over the performance hit for many of their edge routers, based on the number of subscribers involved and other configuration characteristics. 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. I would state that devices that examine IP headers and make routing decisions entirely on interface cards are optimized for traffic forwarding, vs. firewall-style devices that focus on header examination and ACL checking, and which typically do this by passing a packet through a general purpose processor, vs. in I/O interfaces. But, these are just generalizations. 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. Not necessarily. The traffic from a controller to the clients may be sufficiently offset in time as to make tracing back to the controller hard. I agree that tracing to the traffic sources (or at least to the sites where the traffic sources are) would be easier if edge filtering were in place, and if it were not compromised. 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
RE: Proposal: reclassify RFC2549, 1149 as historical
I would tend to agree with Lloyd Regards Mark Paton CEO/DIR. Internet Network Eng Mercury Network Systems Limited +44 585 649051 http://www.mnsl.org "Mercury Network Systems - The Unstoppable Force" This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information if you are not, or suspect that you are not, the named addressee or the person responsible for delivering the message to the named addressee, please telephone us immediately. Please note that we cannot guarantee that this message or any attachment is virus free or has not been intercepted and amended. The views of the author may not necessarily reflect those of the Company. -Original Message- From: Lloyd Wood [mailto:[EMAIL PROTECTED]] Sent: 14 February 2000 21:26 To: [EMAIL PROTECTED] Subject: Proposal: reclassify RFC2549, 1149 as historical I move we reclassify RFC2549 and RFC1149 as historical. Evidence to support this: 'end of an era' according to http://www.telegraph.co.uk/et?ac=000111464 113065pg=/et/00/2/14/wpig14.html below. In particular, I don't think the QoS additions have ever been fully field tested; the WFQ proposal leads to observable instances of dropped tails during measurement. L. don't you just hate thinking about sending yourself valentines? [EMAIL PROTECTED]PGPhttp://www.ee.sur rey.ac.uk/Personal/L.Wood/ ELECTRONIC TELEGRAPH, ISSUE 1725 Monday 14 February 2000 Spread of radio switches off political pigeon post By Jon Stock in New Delhi MORE than 600 Indian police carrier pigeons face early retirement after officials decided to replace them with radios. The decision to ground the birds before Wednesday's state assembly elections in Orissa, eastern India, marks the end of an era. They previously played a unique role in India's electoral process. They last saw active duty during last year's general election, when they carried messages to and from far-flung polling booths in the remote Orissa districts of Koraput and Dhenkanal. The messages detailed the law and order situation during polling. The pigeons are kept in 28 lofts throughout the state and will now become showpieces used solely for ceremonial purposes, according to Baikunthanath Das, Superintendent of Police (Signals), who looks after them. Their demise has been caused by what he called the advent of new technology. He said: "Even the most remote interior areas now have VHF radios." The service was the only one of its kind in India. It was started in 1946 during British rule by the state police's Signal Establishment, which bought more than 1,000 pigeons from the Indian Army after the Second World War. BEGIN:VCARD VERSION:2.1 N:Paton;Mark.;J.S;; FN:Mark. J.S Paton ORG:Mnsl;Consultancy TITLE:Network Design / Support TEL;WORK;VOICE:+44 0585 649051 TEL;CELL;VOICE:+44 (0585) 649051 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;Basingstoke;Willow Cottage=0D=0AReading Road;Mattingley;Hampshire;RG27 8JU;= United Kingdom LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Basingstoke=0D=0AWillow Cottage=0D=0AReading Road=0D=0AMattingley, Hampshire= RG27 8JU=0D=0AUnited Kingdom URL: URL:http://www.mnsl.org EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:19990422T133901Z END:VCARD
