Re: IETF Adelaide and interim meetings for APPS WGs
At 05:45 PM 2/14/00 -0700, Vernon Schryver wrote: 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. As a non-US IETF participant, I found this statement mildly insulting. But then I have to ask myself "why?". It is true that a majority of IETF participation is US-based. It is true that the IETF secretariat is wholly US-based. It is true that the IETF is an outgrowth of a US national organization. So on the face of it, your statement appears entirely true. But I am still uncomfortable with it. It implies that, somehow, any non-US participant is somehow a second class citizen, who is permitted to attend purely as a concession by the US elite whose organization this is. Maybe that also is true -- but I don't have to like it. I very much prefer the "pretense" that the IETF is an organization that provides technical direction for a truly global facility, and that it aspires to do so for the benefit of all the world's people, with equal status and consideration allowed to any who can participate, from wherever they may originate. #g -- Graham Klyne ([EMAIL PROTECTED])
Re: IETF Adelaide and interim meetings for APPS WGs
Graham Klyne wrote: But I am still uncomfortable with it. It implies that, somehow, any non-US participant is somehow a second class citizen, who is permitted to attend purely as a concession by the US elite whose organization this is. Maybe that also is true -- but I don't have to like it. I very much prefer the "pretense" In other words, the pretense is self-fulfilling: by claiming (and striving) to be global, the IETF avoids driving away non-US participants, which makes the IETF more truly global. -- /\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist |===| |eCal Corp. |Yes, sir, we've graphed the data. It's a smiley| |[EMAIL PROTECTED]|face, sir. | \/
RE: IETF Adelaide and interim meetings for APPS WGs
There is more than America out there ? ;-) -Original Message- From: John Stracke [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 15, 2000 3:21 PM To: [EMAIL PROTECTED] Subject: Re: IETF Adelaide and interim meetings for APPS WGs Graham Klyne wrote: But I am still uncomfortable with it. It implies that, somehow, any non-US participant is somehow a second class citizen, who is permitted to attend purely as a concession by the US elite whose organization this is. Maybe that also is true -- but I don't have to like it. I very much prefer the "pretense" In other words, the pretense is self-fulfilling: by claiming (and striving) to be global, the IETF avoids driving away non-US participants, which makes the IETF more truly global. -- /\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist |===| |eCal Corp. |Yes, sir, we've graphed the data. It's a smiley| |[EMAIL PROTECTED]|face, sir. | \/
product tags, vendor information in Internet protocols
A number of protocols/services expose product tags describing the vendor implementation for a variety purposes. These tags generally include the "vendor" and some "version" information and are often used by protocol peers to alter behavior. In some cases, like HTTP (RFC 2616), they may include vendor/version information of subsystems. I am looking for references to technical specifications, considerations, and discussions concerning the use of product tags in Internet protocols. I would also be interested in any published materials describing operational experience using (or abusing) such information. Please note that this message is not intended to start a discussion or debate concerning the use ( or abuse) of product tags, we've likely "been there, done that". So, please, just references to existing works. Regards, Kurt
Re: Internet SYN Flooding, spoofing attacks
From: "Charles E. Perkins" [EMAIL PROTECTED] ... I really wish "we" actually knew how to filter. But maybe filtering is putting the cart before the horse. I agree. ... From that analogy, I claim that the appropriate action is to develop tracing systems that will help to identify a wrongdoer. Here is a possible design. - Create a router feature, able to be remotely activated, to keep ... How is that different from RMON? Or better, how does it not fit naturally into RMON? ... The basic idea then would be to trace back bad packets that conform to some typically innocent, but occasionally troublesome, profiles. The profiles will become self-evident with experience, and once people know they will be caught by this traceback system they will think twice before spreading their crap around. If I were building a DDoS engine today, I'd write a conventional (Microsoft) DOS virus that does nothing except once every 3 minutes do the equivalent of: echo "GET /index.html HTTP/1.0"; echo) | telnet -r $1 80 (maybe instead with a random request instead of /index.html) After a few 1,000,000 desktops have been infected by familiar virus vectors, the victim might notice the traffic. How would you filter for them? Even if you could give routers enough processing power, what would you learn from the filtering that you'd care to apply? ... So the costs boil down to more memory, more software, some pattern-matching hardware, and maintaining security relationships with your routing partners. that's easy to say, but it doesn't sound likely to happen in my world. Vernon Schryver[EMAIL PROTECTED]
Re: IETF Adelaide and interim meetings for APPS WGs
It is traditional that most IETF meeting attendees have given the organization they are affiliated with for identification purposes, whether it is an educational institution, government, other non-profit group or company. Donald PS: I don't see "being international" as a binary thing. Or at least I don't know of any orgnaization, including the UN, that you can claim is "perfectly" international. After all, there are plenty of languages that are not official UN languages and there are always distinctions based on whether you are privileged to have a permanent seat on the Security Council or have the UN HQ in your country, etc. The primary concern in the IETF is producing good protocols. I would hope that anyone whose primary concern is how international the IETF is would find more fertile ground in some other organization. From: "Scott W Brim" [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] Date: Tue, 15 Feb 2000 16:51:44 -0500 To: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Why does the IETF registration form ask for a company name? From: Bill Manning [EMAIL PROTECTED] Subject: Re: IETF Adelaide and interim meetings for APPS WGs To: [EMAIL PROTECTED] (Mart Nurmet) Date: Tue, 15 Feb 2000 11:14:26 -0800 (PST) Cc: [EMAIL PROTECTED] [...] and note that the IETF is composed of indivduals, not corporations. You should not presume to "represent" a corporate entity within the IETF. Your just the best engineer you can be.
Re: Internet SYN Flooding, spoofing attacks
At 11:15 AM 02/15/2000 +, Lloyd Wood wrote: A lot of surveillance can be based on 'if A is talking to B, then A must be as guilty as B', and message content is irrelevant. This helps counters that. Well, get over it. ;-) (Smiley included for the humor impaired.) - paul
Static addresses for the Adelaide IETF
Just another question :-) For people who will want static IPs rather than dynamic (I assume for firewall configuration), will you want to use wireless? I'm told to keep MBONE/wired and wireless LANs apart and so I'm trying to determine if I need more than one static address pool. Note this is not the time to request a static assignment! This is just question time :-) Mark.
Re: IETF Adelaide and interim meetings for APPS WGs
On Tue, 15 Feb 2000 15:44:23 GMT, "Parkinson, Jonathan" [EMAIL PROTECTED] said: There is more than America out there ? There's a lot more out there. It's to make up for the fact that in reality, Idaho, Wyoming, and Rhode Island don't really exist - anybody claiming to be from one of these 3 states is obviously an alien impostor. ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: Internet SYN Flooding, spoofing attacks
On Mon, 14 Feb 2000 16:04:28 PST, Phil Karn said: 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. Well.. as soon as somebody presents us with "the real solution", we'll start implementing. In the meantime, filtering is the best we know how to do. 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. The problem here is that there is often a limit to how far away you can move the detection. In the case of multiple sources, it's *probable* that the inbound packets will arrive on as many as 5 to 20 different links, and not get aggregated onto one path until the last-hop link to the victim's site. And if you have 20 inbound links into a routing swamp, each one will only see a 5% fluctiation in load in order to cause a 100% congestion on the victim link. If you move the detection 2 hops out, you may be trying to spot a 1% ripple in the traffic, if there's 100 different paths that far out. The more hops you try to move the detection away, the smaller the "ripple" you need to be able to detect *without a high rate of false positives*. There's another issue, in that if you're trying to do this 2-3 hops out, you will need *secure* *low-bandwidth* communications regarding who is talking to whom, at what rates. And you get transitivity problems - some of our border routers are 3 hops from a vBNS gateway, and therefor would need to talk to them, plus are 3 hops from other routers that are probably NOT going to want the vBNS information. So you end up with a ugly mess of many overlapping "circles" containing different subsets of routers. This gets you into key management issues, and the like I'm sure there's other issues that need to be solved as well, these are just the first few problems that come to mind... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech P.S. Please note that MS-DOS is the trademark of a *SINGLE*-source vendor of denial of service ;)
Re: IETF Adelaide and interim meetings for APPS WGs
Hi Keith! Your message and actions are right on In addition to the reasons and consequences you mentioned, such behavior opens the IETF to restraint of trade challenges at least in the U.S. Thanks, Kathy Dally MITRE Corp. Keith Moore wrote: It has come to the attention of the Applications Area Directors that one or more Applications area working groups have elected to not meet in Adelaide, and instead to hold an "interim meeting" in the United States, presumably because of distance and/or cost issues. IETF is an international organization, and it is IETF's longstanding practice to hold its meetings in various locations around the planet. This serves both to encourage wider participation in IETF and also to more fairly distribute travel costs and inconvenience (over time) among all participants. The scheduleing of an interim WG meeting in the US in lieu of a WG meeting in Adelaide undermines this policy. This is insulting to non-US participants of IETF (many of whom have attended meetings in the US for years), embarassing to IETF as a whole, and a threat to IETF's international stature. Even if a working group has few participants outside the United States, a working group does not work in isolation from other working groups. Attendance at IETF meetings is an invaluable mechanism for cross-group collaboration. 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. Since normal working group meetings require advance notification via email to the entire IETF list, and the process for getting a meeting slot involves prior approval of the Area Directors, the same requirements apply to interim working group meetings. Part of the reason for prior approval being required is to ensure that the locations of the meetings are not being chosen to favor certain participants over others. There have been several violations of this policy since publication of RFC 2418. Therefore, - All interim meetings within the Applications Area which were not previously and explicitly approved by the Applications Area Directors, are hereby cancelled. - No Applications Area group will hold any interim meeting prior to April 15. - No Applications Area group which does not hold a meeting in Adelaide, will hold any interim meeting prior to July 31. (i.e. prior to the Pittsburg IETF meeting) - 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. - Exceptions to this policy may be made for recently chartered groups, but Area Director approval is still required for such groups to schedule interim meetings. for the Applications Area Directors, Keith Moore begin:vcard n:Dally;Kathy tel;fax:(703) 883-7142 tel;work:(703) 883-6058 x-mozilla-html:FALSE org:MITRE Corp.;Network and Communications Engineering adr:;;1820 Dolley Madison Blvd., W650;McLean;VA;22102;U.S.A. version:2.1 email;internet:[EMAIL PROTECTED] title:Senior Technical Staff x-mozilla-cpt:;-13520 fn:Kathy end:vcard
Re: Internet SYN Flooding, spoofing attacks
From: [EMAIL PROTECTED] ... Well.. as soon as somebody presents us with "the real solution", we'll start implementing. In the meantime, filtering is the best we know how to do. ... I really wish "we" actually knew how to filter. Just as I feared when the news broke, I'm seeing more paths where neither traceroute nor ping work, apparently because some of "us" are so expert that we turn off all of ICMP, and never mind intermittent blackholes from Path MTU Discovery or diagnosing routing or other mere technical problems. Vernon Schryver[EMAIL PROTECTED]
Re: IETF Adelaide and interim meetings for APPS WGs
Vern, The IETF has no dependency of any kind on any government and as you yourself observed it does its decision taking in cyberspace, not geographical space. It is as international as any organization I have ever known, and I spent more 20 years working for an international treaty organisation. I agree with Fred. Objecting to crossing the Pacific once in 47 meetings is not right. (Not talking about you personally of course.) Brian
Re: IETF Adelaide and interim meetings for APPS WGs
In message [EMAIL PROTECTED], "Parkinson, Jonathan" typed: There is more than America out there ? ;-) you mean america still exists - i thought it was actually a myth like atlantis -Original Message- From: John Stracke [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 15, 2000 3:21 PM To: [EMAIL PROTECTED] Subject: Re: IETF Adelaide and interim meetings for APPS WGs Graham Klyne wrote: But I am still uncomfortable with it. It implies that, somehow, any non-US participant is somehow a second class citizen, who is permitted to attend purely as a concession by the US elite whose organization this is. Maybe that also is true -- but I don't have to like it. I very much prefer the "pretense" In other words, the pretense is self-fulfilling: by claiming (and striving) to be global, the IETF avoids driving away non-US participants, which makes the IETF more truly global. -- /\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist |===| |eCal Corp. |Yes, sir, we've graphed the data. It's a smiley| |[EMAIL PROTECTED]|face, sir. | \/ cheers jon
Re: IETF Adelaide and interim meetings for APPS WGs
Keith: How do I go about geting the schedule for the meetings for the rest of the year? I'm new to this forum and will be the Inet Technologies representative in the future. Best regards, Mart Nurmet 972 543-3791
Re: IETF Adelaide and interim meetings for APPS WGs
The problem I have with the Adelaide meeting is very simple. With so few working groups holding sessions, I can't justify making the trip. This would be true for a meeting at any location more than 400 miles away. If only one group that I am interested in is holding a session, I can't go. The powers that be just won't approve it. So the side effect of not holding a session is that not only have the working groups decided that they do not want the interest and participation of non-U.S. members, but they don't want the interest and participation of U.S. members either. This leads me to question why the working group is in fact a working group in the IETF. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: Internet SYN Flooding, spoofing attacks
On Tue, Feb 15, 2000 at 10:22:46AM -0700, Vernon Schryver wrote: From: [EMAIL PROTECTED] ... Well.. as soon as somebody presents us with "the real solution", we'll start implementing. In the meantime, filtering is the best we know how to do. ... I really wish "we" actually knew how to filter. Just as I feared when the news broke, I'm seeing more paths where neither traceroute nor ping work, apparently because some of "us" are so expert that we turn off all of ICMP, and never mind intermittent blackholes from Path MTU Discovery or diagnosing routing or other mere technical problems. But some of us turn off ICMP except for ICMP_FRAG_NEEDED and keep MTU discovery alive while cutting off the ICMP food fights and script kiddie probes that seem to be endemic in our current mess. You betcha traceroute and ping are broken (figuratively and literally). Just as broken as I can make them. You don't need to be tracerouting or pinging into my network and that's my choice to make. I can break them without breaking MTU discovery. You want to diagnose routing or other technical problems, why aren't you contacting me? You cut off ICMP_ECHOREPLY and all but a tightly restricted set of UDP and you have just starved these DDoS zombies of the vast majority of their communications facility. TCP is much easier to trace, if they fall back to that (I don't see how TFN2K could - it utilizes a blind forward-only non-responding channel). Blocking spoofed packets won't do nearly as good a job since a lot of the packets aren't spoofed. Doesn't help at all in some examples I have some first hand experience with. Edge filtering and spoof protection would have been absolutely no help for one site I was help with forensics after TFN2K. They were a source of ICMP_ECHOREPLY packets in one of the storms. We STILL haven't located the zombie amongst the hundreds of potential Windows boxes (we already cleared the single Solaris and single RedHat box on the subnet and TFN2K is known to run on Windows). No spoofed packets crossed router boundries. The TFN2K command sequence was executed well before anyone noticed any bandwidth anomolies, so there's no track back to the master. (Who would have noticed 20 ICMP_ECHOREPLY packets that merely didn't correspond to any internal request?) The slaves shut down after two hours and before the admins realized that the smurf was being generated internally. They did find a bug in a router blocking of directed broadcasts. That red-herring slowed them down, thinking it was externally generated. No trace back of the smurf triggers back to the zombie (having that MAC address would do wonders) was caught since it quiet before they started sniffing the network. They broke it's back by blocking ICMP_ECHO and ICMP_ECHOREPLY (fortunately, this attack was not using one of the UDP options). I have not heard if any of the TFN scanners have turned up anything yet. TFN2K zombies are a real bummer since it can lay dormant on a network until triggered and they don't reply back to the master. These guys are on a machine by machine, file by file snark hunt looking for files that could be any one of a number of names on systems that are all different anyways. Don't you know they're having fun? The attackers are gaining in sophistication. We are begining to see effort at "covert channels" for communications. The tricks of communicating via ICMP_ECHOREPLY packets with commands in the payload and sending blobs of forward only commands with no reverse channel responses are just examples. How long before they start sneaking past those defenses by sending ICMP_UNREACHABLE/ICMP_FRAG_NEEDED with a command data payload? They don't have to resort to spoofing to pull off a lot of this. Long command time delays, covert channels, and unidirection command direction can make it just as difficult to track down as spoofing. Diagnostics are fine. Performance is fine. Diagnostics and/or performance at the expense of security and/or robustness is not. Vernon Schryver[EMAIL PROTECTED] 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 Adelaide and interim meetings for APPS WGs
% Keith: % % How do I go about geting the schedule for the meetings for the rest of the % year? % % I'm new to this forum and will be the Inet Technologies representative in % the future. % % Best regards, % Mart Nurmet % 972 543-3791 I'm not keith but can answer your question. www.ietf.org and note that the IETF is composed of indivduals, not corporations. You should not presume to "represent" a corporate entity within the IETF. Your just the best engineer you can be. --bill
Re: Internet SYN Flooding, spoofing attacks
From: "Michael H. Warfield" [EMAIL PROTECTED] ... But some of us turn off ICMP except for ICMP_FRAG_NEEDED and keep MTU discovery alive while cutting off the ICMP food fights and script kiddie probes that seem to be endemic in our current mess. Why couldn't you do as has been frequently suggested and only throttle ICMP Echo-Request/Reply? You betcha traceroute and ping are broken (figuratively and literally). Just as broken as I can make them. You don't need to be tracerouting or pinging into my network and that's my choice to make. As we all agree, what you do with your own network is only your business. However, rest assured that if you're an ISP that breaks traceroute, then you also break arbitrary UDP applications, and that means you don't get any business from anyone with any sense. I can break them without breaking MTU discovery. You want to diagnose routing or other technical problems, why aren't you contacting me? (Hypothetically, of course) Because I do not know where the problem is. Without traceroute, how should I figure out to call you? How do I discover that you're running a transit network between here and the other and that is trashing my packets)? Nonsense about calling arround is exactly why traceroute was invented, and that was back when there were a lot fewer usual suspects messing with things. Before traceroute, the only way to figure out what was wrong was to call the far end and the first hop...well, besides intelligent and laborous use of `ping` and other manual, hop-by-hop probing. Since you turn off ICMP Echo-Requests, no one can tell. You probably also turn of Record-Route, lest someone discover that your routers are in the path. You cut off ICMP_ECHOREPLY and all but a tightly restricted set of UDP and you have just starved these DDoS zombies of the vast majority of their communications facility. TCP is much easier to trace, if they fall back to that (I don't see how TFN2K could - it utilizes a blind No, TCP is not more traceable because has no more IP source addresses than UDP. Yes, unidirectional TCP is not terribly useful for legitimate traffic, but that also applies to UDP. You have a such narrow view of the possibilities for a DDoS attack that it is dangerously wrong. If you accept any packets that cause your systems to do any work, then I can write a distributed program that can trash your systems, your network, or both. All you can do is force me increase the size of my army of zombie proxies. If you do not accept any packets that cause your system to do any work (including merely sending "puzzles" or checking answers), then your system is useless. Who would send any packets to a system that does nothing? Blocking spoofed packets won't do nearly as good a job since a lot of the packets aren't spoofed. Yes, as has been repeatedly pointed out. RFC 2267 filtering is good even if it is not a pancea. The reasons advanced for bogus IP source addresses are not compelling. ... They broke it's back by blocking ICMP_ECHO and ICMP_ECHOREPLY (fortunately, this attack was not using one of the UDP options). It is also fortunate that it was not based on TCP packets to port 80 or UDP to or from port 53. I'd wonder why they didn't use a distributed, very low rate per zombie SYN attack, except I know such people are fundamentally stupid. ... The attackers are gaining in sophistication. We are begining to see effort at "covert channels" for communications. The tricks of communicating via ICMP_ECHOREPLY packets with commands in the payload and sending blobs of forward only commands with no reverse channel responses are just examples. How long before they start sneaking past those defenses by sending ICMP_UNREACHABLE/ICMP_FRAG_NEEDED with a command data payload? Also think about putting commands in packets to port 53 or 80. Yes, including TCP port 80. If you've broken into a system, you may as well listen to all raw packets and not just what the local TCP state machine thinks are kosher and not only what `ping` and `traceroute` use. Given all of that, could you remind me of why it is rational to filter ICMP-Echo's when by your own words the bad guys don't need to use them? As in the spam war, filtering ICMP-Echo's only advances the day whey they use other schemes that are harder to filter. Unlike the spam war, it is technically easy to make bad traffic that cannot be filtered (press releases from security outfits notwithstanding). Vernon Schryver[EMAIL PROTECTED]
Re: Internet SYN Flooding, spoofing attacks
Hello Vernon, Well.. as soon as somebody presents us with "the real solution", we'll start implementing. In the meantime, filtering is the best we know how to do. ... I really wish "we" actually knew how to filter. But maybe filtering is putting the cart before the horse. I compare the recent problems with phone harassment. We can install all sorts of doodads, but if we can identify the source of the harassment we can bring charges against them. From that analogy, I claim that the appropriate action is to develop tracing systems that will help to identify a wrongdoer. Here is a possible design. - Create a router feature, able to be remotely activated, to keep track of "suspicious" packets for a few seconds up to maybe a couple dozen seconds. Suspicious packets might be SYNs, or even packets with "incorrect" source addresses. - If a violation is noticed, determine the interface on which a bad packet was received, and send a request to that neighbor along with appropriate credentials that can be checked. - If, on the other hand, a neighbor sends a request for tracing a problematic packet, check the credentials that accompany the request and look at the stored data for that packet. If no stored data exists, send back the bad news, and possibly enable the pattern-matchine function to capture similarly featured packets in case of future requests. - If a neighbor's request refers to a stored packet, figure out what interface the stored packet arrived on. If the packet came from another neighbor, forward the request. Otherwise, look for the malicious source internal to the domain. The basic idea then would be to trace back bad packets that conform to some typically innocent, but occasionally troublesome, profiles. The profiles will become self-evident with experience, and once people know they will be caught by this traceback system they will think twice before spreading their crap around. According to one knowledgeable source, this strategy is undesirable because it would cause routers to maintain more state. But, I claim that we have to maintain state to do any tracing, and I also claim that we need to enable tracing in order to detect and identify wrongdoers. Since the features should be activated by request from trusted neighbors, in the usual case there should not be any significant performance degradation. Clearly, such requests have to be checked for authenticity. So the costs boil down to more memory, more software, some pattern-matching hardware, and maintaining security relationships with your routing partners. I think it's a very worthwhile tradeoff. Much better than mostly ineffective measures that have big negative effects and small positive effects, characteristics of ingress filtering as I understand it. Plus I don't like the attitude of blaming the victim without giving the victim any tools with which to find the perpetrators. Regards, Charlie P.
NATimes announcement
We are pleased to announce the release of the first issue of our newsletter of the NLANR measurement and network analysis team: The Network Analysis Times. It is available at: http://moat.nlanr.net/NATimes/. This issue includes brief overviews and the current status of each of the areas that form the core of our measurement and network analysis research: passive header trace data and active performance measurements. Also presented in this issue are an article on the Cichlid 3-D visualization system, as well as notes and updates from some of our collaborators on their research projects. We plan to use this electronic newsletter to share information about our research and start dialogues on issues of mutual interest in network analysis. There are many possibilities for new areas of research that will build upon our current Network Analysis Infrastructure and give us more understanding of areas such as Internet workload profiles, service characteristics and performance, models, metrics, and simulation. We look forward to receiving feedback from you, and working together to gain more insight and knowledge into the inner workings of the Internet and continue to work towards maximizing it as a resource. If you want to get notification of new issues, please let us know at [EMAIL PROTECTED] In addition, if you have questions or comments, or would like to add short articles to future issues of the NATimes, please discuss it with us at the same address.
Re: IETF Adelaide and interim meetings for APPS WGs
I think that, believing that the world is no bigger than America is a common problem among many US citizens. No offense, so would I if I lived in US, because after all there is quite a few states and cities to keep track of. But my point is that we, including the Americans, speak so proudly of the Internet as this global network interconnecting millions of computers around the world providing a relatively cheap means of communicating and informing across borders. Europe, Asia, Africa and Australia have all payed their part of what makes up this Internet, just like the US have. And yet some US citizens feel that the 'net somehow belongs to them and that they are superior in deciding its future. Luckily, German Daimler-Benz wasn't that short-sighted when they invented the automobile a century ago. - Anders Feder
Re: Internet SYN Flooding, spoofing attacks
From: Vernon Schryver [EMAIL PROTECTED] ... The basic idea then would be to trace back bad packets that conform to some typically innocent, but occasionally troublesome, profiles. The profiles will become self-evident with experience, and once people know they will be caught by this traceback system they will think twice before spreading their crap around. If I were building a DDoS engine today, I'd write a conventional (Microsoft) DOS virus that does nothing except once every 3 minutes do the equivalent of: echo "GET /index.html HTTP/1.0"; echo) | telnet -r $1 80 (maybe instead with a random request instead of /index.html) After a few 1,000,000 desktops have been infected by familiar virus vectors, the victim might notice the traffic. How would you filter for them? Even if you could give routers enough processing power, what would you learn from the filtering that you'd care to apply? It is possible to get more big bang in this case: virus may asks DNS servers about some generated domain names. Algoritm to fight negative caching effect is simple. With millions names in .com there is a long way to keep asking. - Leonid Yegoshin, LY22
Re: IETF Adelaide and interim meetings for APPS WGs
Jeffry; IETF is certainly US and English centric. The current rules of IETF does not explicitely prefer some country so much, though many important organizations have addresses in US and English is the language of the rules. However, the rules keep or amplify the US centric tendency, because a large number of US participants means a large number of IAB/IESG members is likely to be nominated. Moreover, English centric IETF meetings are hard to be actively attended by people whose primary language is not English. Compared to other International organizations, IETF requires too much in English capability. Worse, in IETF, inactive participation is nothing. Having a meeting in AU does not solve the latter, English, problem. However, The problem I have with the Adelaide meeting is very simple. With so few working groups holding sessions, I can't justify making the trip. This would be true for a meeting at any location more than 400 miles away. If only one group that I am interested in is holding a session, I can't go. The powers that be just won't approve it. it is a good solution for the first, US, problem. Moreover, you are saying that the recent problem of IETF that there are too many bogus WGs with too many people is also solved. Very good. So, all the future IETF meetings should be held in areas far away from US and, in addition, where English is not the major language. There many be an exception once in 10 years, of course. Masataka Ohta
Re: IETF Adelaide and interim meetings for APPS WGs
--On Tuesday, 15 February, 2000 15:22 -0600 Tim Salo [EMAIL PROTECTED] wrote: Of course, that leads to the rather interesting dilemma that we don't know whether an individual is speaking on behalf or his or her self or on behalf of an organization, (again, even if we tell that person that _we_ know which it is). FWIW, in some other standards bodies, there is a policy that, if one wants to (or is constrained to) speak on behalf of an organization, or arrives with instructions as to what to say that the individual cannot change after hearing arguments in the meeting, those restrictions/relationships must be disclosed. The rule is unenforceable, but provides some protection to the individual (especially in "my company is full of idiots, but please don't mistake me for one" situations) and for the standards group. john
RE: IETF Adelaide and interim meetings for APPS WGs
IMHO, people are reading way too much into this. Most of the participation is by folks from the US -- that stat is raised at every meeting. BTW, the Internet started in the US, those neat maps displayed at plenary sessions show an overwhelming focus of connectivity in the US, and many many technology companies are located in the US. Notwithstanding, the organization does hold meetings both inside and outside the US, because the Internet is a global entity with international involvement. While this is IMHO a Good Thing, reality is that the longer trips sometimes pose a problem for some participants -- whether that's traveling from the US to Australia, or Australia to the US. Statistically, the burden hits more people for meetings outside the US, simply because regardless of where we hold the meetings, there are more attendees from the US than from any other place. (At this juncture, I would like to salute the folks from outside the US who nonetheless attend the majority of US-based meetings.) To those of you outside the US who don't think there are enough meetings outside the US: IF YOU SPONSOR THEM, WE WILL COME. I've seen the open, standing invitations to sponsor meetings -- so step up and sponsor. For those who think Australia is a long way to go: you're right, if you are in North America or Europe. Many WG chairs may be making an 'economic' decision -- or their employers have made it for them. (I'm not going because I don't want to be away from my new baby daughter yet.) But since the work REALLY gets done on the mailing lists (so we say, officially), you can still make a difference, if you so choose. Not to say I don't think there's a lot of value to the face-to-face meetings, but when I chaired a WG, I got a lot of great input from people who never attended a single WG session in person. Bottom line: go if you can and wish to, don't whine if you can't or won't. And please quit with the "conspiracy theories" about US-centricity -- it's an accident of history, nothing more. Don't expect us Americans (or US residents) to feel guilty or go slit our wrists over it. And for whatever reason, English does seem to serve as a common tongue in the world of technology -- again, I'm not going to apologize for it. (And it doesn't stop us from working hard to figure out how to represent ALL the languages of humanity in digital form) Please forgive my typing -- my daughter is keeping one arm busy. -- Ian King, Speech Product Group, MICROSOFT CORPORATION -Original Message- From: Masataka Ohta [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 15, 2000 3:39 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: IETF Adelaide and interim meetings for APPS WGs Jeffry; IETF is certainly US and English centric. The current rules of IETF does not explicitely prefer some country so much, though many important organizations have addresses in US and English is the language of the rules. However, the rules keep or amplify the US centric tendency, because a large number of US participants means a large number of IAB/IESG members is likely to be nominated. Moreover, English centric IETF meetings are hard to be actively attended by people whose primary language is not English. Compared to other International organizations, IETF requires too much in English capability. Worse, in IETF, inactive participation is nothing. Having a meeting in AU does not solve the latter, English, problem. However, The problem I have with the Adelaide meeting is very simple. With so few working groups holding sessions, I can't justify making the trip. This would be true for a meeting at any location more than 400 miles away. If only one group that I am interested in is holding a session, I can't go. The powers that be just won't approve it. it is a good solution for the first, US, problem. Moreover, you are saying that the recent problem of IETF that there are too many bogus WGs with too many people is also solved. Very good. So, all the future IETF meetings should be held in areas far away from US and, in addition, where English is not the major language. There many be an exception once in 10 years, of course. Masataka Ohta
