Re: DARPA get's it right this time, takes aim at IT sacred cows
At 21:45 15/03/04, Scott Michel wrote: jfcm wrote: Interesting as this matches the conclusions of our own meetings in Dec/Jan on national vulnerability to internet. Sounds like the internet is a threat, not a tool. (Ok, I know you're not a native English speaker, but it was hard to resist.) It sounds right. The threats are the weaknesses of the tool. And their impact on cirtical resources. Let assume the DNS "stops" (attacked, polluted, hijacked, disputed): what is the impact on the nation? We identified five main (immediate/middle terms) threats (and agree with the USG they may be critical [we say "vital"]): - DNS centralization - IPv6 unique numbering plan - mail usage architecture (not SMTP) - governance confusion - non concerted national R&Ds (starting withthe US one) This lead to the notion of "national firewall". Not the same architecture and layers as a local firewall, but an equivalent mission. One can consider global, users groups and local firewalling. Global means to prevent destructive access to the nets (like sending spammers to jail, making sure the root is stable, secure and safe, reaction to PathFinder like attempts). Users Groups (nations, regions/states, cities, structures, coporations etc.) mean addressing, directory, access portall protection. Local is what we are used to (but here port and traffic filtering should be less and less the main issue and call for more sophisticated tools). Agreed. But for a non US observer this sounds in line with the pro-IPv6 stance of DoD: obeying http://whitehouse.gov/pcipb marching orders. To be fair, it was NATO and the Allies who started in the v6 direction first. DoD is just merely keeping up with its various international partners. hmmm. May be you did not evaluate what the worldwide control of IPv6.001 gives to who allocates the addresses (ICANN) and whould build an run an IPv6 "DNS". May be am I candid, but I tend to think that when a military person speaks, it is with a purpose. And usually that telling what you exactly want is the best way to obtain it. The article does not say they want to kill IP, but that they want solutions. There are three possibilities to support changes: - to fix IP - to change IP - to replace IP Generally speaking, military officers do speak with a purpose in mind, but I disagree that the thrust you're enumerating. "Fix IP" is probably true, "Change IP" fits with "Fix IP", but "Replace IP" is patently untrue. After all, the DoD spent a lot of time and money on ATM in the mid and late 90's only to fall back to IP. ATM was an abject failure. I will not comment on ATM. "Fix IP" means in my mind to keep IPv4/IPv6 and modifiy some features. "Change IP" means to look at a new IPvX. "Replace IP" means another kind of protocol/paradigm. I do not talk abuot what DARPA may do, but what we have as options. I read they have identified a need (the same as NSI said they had a need through PathFinder) and that the ball is in the IAB and IETF's field (for a short while if you consider how long NSI awaited before suing ICANN) I'm not sure I agree with this at all -- the research community is much more agile than the IETF and IAB, so it's more likely that the IETF will play catch-up as the DARPA reearch produces tangible results. I think we agree there. I say the ball is in IAB/IETF field, and that they have to move fast, or DARPA and many others will take the lead. The problem is that this "agility" is to be housed somewhere. Let assume DARPA produces tangible results soon (what I is quite credible) we are not in the 80s anymore, on "ARPA Internet". We are on Global Internet, and a Global body is to publish it. This leads to ITU. And as long as ITU-I has not been created on purpose, I am afraid it is acceptable to no one. Let see the situation through military eyes. The battlefield is what it is. For the new Cyber Forces, the internet battlefield is what is used today. So they are interested in what is available/under serious development - or in what worked before/aside the IP technology and which could be deployed quick (so, most probably a total change for a clean sheet, low cost and confidential restart). The emphasis is and has been "network centric warfare". The current DARPA director is interested in a good mix of solutions that can be deployed in the immediate, near and future terms. "Deployed" as in "deployed out in the field with the warfighter" (on the back of a US Marine.) We agree. But we are considering today/tomorrow warfare. The Irak action started with the first real "cyberbattle", a two days saturation spamming preparation. Exactly like before a Marines landing with artillery (what they had on the boarder too if I am right?). Snipers coordinate through cyberspace. Soft unstabilization of Europe is hopefully right now a cyber activity, rather than a Marines one :-). Throwing away the current IP infrastructure or completely redesigning the protocols would be one of those way o
Re: Apology Re: Principles of Spam-abatement
On Tue, 16 Mar 2004, Dr. Jeffrey Race wrote: > On Mon, 15 Mar 2004 18:12:22 -0800, Ed Gerck wrote: > >BTW, how can we talk about "actions that have consequences" in terms of a > >technical solution that the IETF can pursue? > > > The whole point is there are NO TECHNICAL SOLUTIONS and never will be. Correct, and I gave an explanation for this in inforamtion theory. > (There are some technical aspects to improving traceability, however.) The traceability is about as good as it will get. If you have an IP address and a time, that is all you need, and like a phone number, all you might hope to get. While an open proxy can hide the true IP of the abuser, you still get the IP of the open proxy. Likewise, if the dialup account is stolen, you may get the IP address assigned to users of the dialup gateway, which also isn't the culprit. Even cryptographic methods start by having ISP's issues certificates. The certificates, like other accounts might be thought of as disposable. Or they might be stolen. Authentication is not a solution to spam. As you might recall, after the east coast power outage, it was suspected that the outage might have been related to a virus. While it turned out not to be, it didn't take long for the virus author to be tracked down by law enforcement. There is nothing wrong with the current traceability. What anti-spammers want is to have access to private information. This will not happen without proper legal procedures. CAN-SPAM explicitly permits information to be obtained by subpoena, but basically, this was all obtainable before, as AOL and many others have demonstrated. > IETF would not apply the consequences; the victims would apply the > (behavioral) consequences using established guidelines, employing > technical measures already established in RFCs. > > IETF and other standards bodies can bless agreed procedures for using > the existing technical steps in new behavioral ways. > > There are two reasons this is crucial: > > 1) Courts often, perhaps usually, defer to declared norms of industry >standards bodies, in establishing reasonableness of disputed >behavior. We can be decisive in establishing these norms. The >courts can't easily act to use the COMPLETELY ADEQUATE EXISTING >LAWS in part because of this lacuna. Example? Given that you seem to think open relays are bad (from you proposal), and since the only time I've ever heard such a claim involved open relays, I'm guessing that's what you mean. Having litigated the issue--it was so frivolous that it didn't get to a filing but there were lawyers involved, I can report to you that the reasonableness of running open relays in particular has nothing to do with technical standards. The central issue is that there a genuine reasons to provide unauthenticated or post-authenticated relay services outside one's assigned IP address space, and secondly, the claims that open relays are somehow associated with spam or provide some benefit to spammers doesn't hold up to legal scrutiny. Open relays are not the same as anonymous relays. Open relay use doesn't in any way impede investigation of spam. Nor does open relay use impede spam blocking. There are two types of people who speak against open relays: The first type are misled. They have very little idea of what an open relay is or why they would be used. They've just been told that open relays are bad, and have come to believe this fervently themselves. It is an article of faith, and not of logic. The second type abuses them. Genuine spammers of the sort that would be subject to the CAN-SPAM act do not abuse open relays. Only radical anti-spammers search for, and abuse open relays. > 2) Normative documents, and personal leadership, convert a group or a >mob into an "emergent structure" (say a business firm, a dance >company, a charitable organization, a military unit, a religious >order, a teen gang) in which the norms absolutely bind the behavior >of the participants, even to death. > > I say, in a completely non-deprecating way, that these points from law > and sociology may not be apparent to engineers (or in fact to anyone else > who is not an attorney or a sociologist) but they are completely true > and completely binding on human behavior. > > > >The consequences are not > >technical. In addition, they would need to be arbitrated and we know how > >long, ineffective and expensive that can be. > > > No arbitration needed. Please re-read the proposal. > > My proposal (which received input from many people) is basically just > common sense. That's what we need now. The answers are in. The > proof is in. Let's do it. Now. Actually, common sense would be that anytime you interfere with someone's rights, there will be legal procedures involved. But this is another weakness in the cherished assumptions of the radical anti-spammers. They seem to think that they are the only people with rights.
Re: [ga] LatinoamerICANN publica versión en españolde los Estatutos delICANN
On Mon March 15 2004 23:19, Jeff Williams wrote: > Dave Aronson wrote: > > Jeff Williams wrote (though I get the impression he's summarizing > > other people's objections, not raising them himself, as he then > > answers them): > > I sure did, and for what should have been an obvious reason. It > seems in your case Dave, what is plainly obvious escapes you. That > is indeed a sad commentary on the IETF... Well excuse... mee!!! B-P Your diatribe that I responded to, was the first appearance of this thread on the IETF list, at least according to my trash-folder. Looks like you crossposted it. If you don't want our input, then don't bother us. > > 1) The people at the UN are, generally speaking, career > > diplomats. Knowing foreign languages and cultures is part of their > > way of life. > > This is true in some UN agencies, and certainly not in others as > several are almost entirely volunteers... Fair enough. I was speaking mainly of the General Assembly delegates, though they are a minority of the entirety of UN employees, observers, etc. Even regarding the others, the UN's entire point is international cooperation for basically its own sake (even if specific agencies have more specific missions). It seems obvious to me that they will be more often people who have an interest in foreign languages, than will most other groups, even those that operate internationally. > > Even if they do not know the particular language someone else is > > speaking in, they should at least be basically familiar with the > > most popular languages of the world. > > Agreed as should most IETF'ers or ICANN'ers as they espouse to > be an international organization. I suspect that many, if not most, of us would still be here even if the network were only available in our own respective nations. (Though admittedly, it would then be less useful, especially to the smaller nations.) That it lets me also communicate with the other side of the world is great, but frankly, the vast majority of the people I communicate with via the Internet, live here in the US. So, the international aspect of it is not as important *to me* (I won't presume to speak for anyone else), as (I ass-u-me) the UN's is to its people. Again, recall that the international aspect is basically the entire point of the UN > So Erick in this instance should > have been easily to be able to provide an english translation as > would be in keeping with good manners. However he did not... Whatever. Remember, the IETF list did not get the background messages to which you refer. > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders > strong!) "Be precise in the use of words and expect precision from > others" - Pierre Abelard "Be conservative in what you send, and liberal in what you accept." -Popular paraphrasing of Jon Postel from RFC 791 (Internet Protocol) -- Dave Aronson, Senior Software Engineer, Secure Software Inc. Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org (Opinions above NOT those of securesw.com unless so stated!) WE'RE HIRING developers, auditors, and VP of Prof. Services.
Re: move to second stage, Re: Principles of Spam-abatement
Ed Gerck wrote: In a separate thread, under Yakov's suggestion, the solution part of this discussion is now probably moving on to the closed ASRG list (with open archive) as posted in http://article.gmane.org/gmane.ietf.asrg.smtpverify/300 I'd like to now address the other part of Yakov's reply below, or "Why not keep the old design if we can get back to the old assumption?" Comments inlined. The solution to spam lies squarely in the IETF hands. We need an Internet design where the end points are less trusted than the connection. The opposite of what we have today. Only then, IMHO, can we have those kind of solutions that the IETF can take on in order to really reduce the problem. Of course, updating the Internet design to fit its current operating conditions is useful not only to stop spam. Social engineering and spoofing attacks also rely on the old honor system where users are trusted. "Trust no one" should be the initial state under the new Internet paradigm. So the bottom line is that we lack trust. This echoes the comments made by the IAB in section 3.1 of (http://www.iab.org/documents/drafts/draft-iab-e2e-futures-05.txt). How would introducing trust help with the spam problem? Would the cost of doing so perhaps would be so prohibitive that we will not be able to do so? Is it really possible to introduce trust that will actually work? Yakov
Re: Apology Re: Principles of Spam-abatement
Dean Anderson wrote: > > On Tue, 16 Mar 2004, Dr. Jeffrey Race wrote: > > > > The whole point is there are NO TECHNICAL SOLUTIONS and never will be. > > Correct, and I gave an explanation for this in inforamtion theory. What information theory says is that the probability of detecting spam is less than 100%. This has nothing to do with what or what not the IETF can do to prevent spam. This result is useful only for an end-user, to feel good about his spam filter not being 100% effective. This is a user result, not an IETF goal. What interests the IETF are technical spam solutions, for example, that would prevent email that comes from unidentifiable or rogue senders/MTAs to be ever received. Not because spam is detected as such but because untrusted, unidentifiable or rogue senders/MTAs are detected. Yeah, this would still leave room for trusted and identifiable senders/MTAs to send spam messages. But such spammers are no longer a hidden target. And it would be a lot harder for someone to send spam on behalf of you. These are examples of feasible technical, IETF-relevant solutions to spam, not at all denied by information theory. To implement these solutions, we need an Internet design where we recognize that the end points have become much less trusted than the connection. This is the opposite of what the DARPA Internet assumed and was designed for. So, some things gotta change. For example, saying that you're "[EMAIL PROTECTED]" should not be so easy to do when you're sending email, even though it should still be easy to set "[EMAIL PROTECTED]" as your address in your MUA. Cheers, Ed Gerck
Re: move to second stage, Re: Principles of Spam-abatement
Yakov Shafranovich wrote: > So the bottom line is that we lack trust. Depends how you define trust. In my view, the bottom line is that trust depends on corroboration with multiple channels while today we have neither (a) the multiple channels nor (b) the corroboration mechanisms. So, we lack trust because we can't communicate it. It's an even more basic limitation than just lacking it ;-) > How would introducing trust help with the spam problem? By allowing trust to be earned between humans and machines, and to each other. Machines can then become our agents also in terms of trust decisions. > Would the cost > of doing so perhaps would be so prohibitive that we will not be able to > do so? Anything else will be more expensive because there is no other solution. Trust is that which provides meaning to information (Shannon: information is that which you do not expect, information is surprise). Without trust, all we have is a string of bits. Let me give you some examples. 1. If I ask you whether the expression in quotes "1=1" is true or false, what would you say? Looks simple enough, no? HINT: Your answer depends on the meaning you assign to the expression "1=1", which depends on what you rely upon (i.e., what you trust) when you evaluate it. The same process is reflected in software when that expression is evaluated to true or false. For example, the above expression is incorrect in C. 2. if I tell you I'll send you a GIFT, can you tell me what you think I'll send: (a) a present (b) a poison (c) anything HINT: To answer this question, you also need to assign a meaning to the word GIFT, which depends on what you rely upon (i.e., trust) in regard to me (since I formulated the question). Again, the same process is reflected in software when a tag is evaluated in a protocol. In English, (a) is correct. In German, (b) is correct. > Is it really possible to introduce trust that will actually work? It works every day. Otherwise we would not be able to cook, earn money or even talk. We just have to transpose this knowledge from our wetware to the software. Cheers, Ed Gerck
Re: move to second stage, Re: Principles of Spam-abatement
On 3/16/2004 3:41 PM, Yakov Shafranovich wrote: > How would introducing trust help with the spam problem? Would the cost > of doing so perhaps would be so prohibitive that we will not be able to > do so? Is it really possible to introduce trust that will actually work? Trust is a contiuum, like everything else related to security. Different people will have different levels of trust; having a marketplace of trust brokers -- each of whom provide different levels and strenghts based on different factors -- is appropriate. Some people and/or services will require notarization-based trust, others will be happy knowing that blacklist-dujour.org doesn't think the sender is scum. I don't see what cost has to do with it. The IETF only needs to provide standardized mechanisms for negotiating trust between end-points. Leave the brokerage functions (and the implementation costs) to the service providers who want to enter the market. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Apology Re: Principles of Spam-abatement
Ed Gerck wrote: What interests the IETF are technical spam solutions, for example, that would prevent email that comes from unidentifiable or rogue senders/MTAs to be ever received. Not because spam is detected as such but because untrusted, unidentifiable or rogue senders/MTAs are detected. Yeah, this would still leave room for trusted and identifiable senders/MTAs to send spam messages. But such spammers are no longer a hidden target. And it would be a lot harder for someone to send spam on behalf of you. Yes! I agree that the IETF can not stop spam. A very reasonable goal would be to stop or make very unlikely, or difficult to send forged spam. Or at least make it detectable early in the process of accepting email and hang up on the spammer. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug | Fax:(866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: Apology Re: Principles of Spam-abatement
On Tue, 16 Mar 2004, Ed Gerck wrote: > > > Dean Anderson wrote: > > > > On Tue, 16 Mar 2004, Dr. Jeffrey Race wrote: > > > > > > The whole point is there are NO TECHNICAL SOLUTIONS and never will be. > > > > Correct, and I gave an explanation for this in inforamtion theory. > > What information theory says is that the probability of detecting > spam is less than 100%. No, information theory doesn't say that at all. Indeed, the probably of detecting spam is probably very close to 100% > This has nothing to do with what or what not the IETF can do to prevent > spam. No, it is quite useful: The IETF can do nothing to prevent spam. > What interests the IETF are technical spam solutions, for example, > that would prevent email that comes from unidentifiable or rogue > senders/MTAs to be ever received. The only thing that can acheive this is to turn off the computer. > Not because spam is detected as such but because untrusted, > unidentifiable or rogue senders/MTAs are detected. Yeah, this would > still leave room for trusted and identifiable senders/MTAs to send spam > messages. But such spammers are no longer a hidden target. And it would > be a lot harder for someone to send spam on behalf of you. > > These are examples of feasible technical, IETF-relevant solutions to > spam, not at all denied by information theory. The IETF can specify protocols with certain features, say PKI, but doing so will not prevent spam, since the IETF (nor anyone else) cannot specify a 'spam-free' protocol. This is a result of information theory. > To implement these solutions, we need an Internet design where we > recognize that the end points have become much less trusted than the > connection. This is the opposite of what the DARPA Internet assumed and > was designed for. So, some things gotta change.
Re: move to second stage, Re: Principles of Spam-abatement
On Tue, 16 Mar 2004, Yakov Shafranovich wrote: > So the bottom line is that we lack trust. Nothing truer has ever been said. This is a feature of human society: People are not trustworthy. Lacking any way to positively, uniquely, and inalterably identify people from birth to death, we cannot implement a trust system. People (abusers) would just change their (electronic) identities or steal someone elses. What would people do who had their identities stolen? How could you _trust_ the claim of electronic identity theft? Credit card companies substantiate such claims when the purchases could not have been made by the person whose credit card was stolen. Yet it is still a major problem, and it is crime, and a lot of money is involved. My GF signed up for a Red Sox Credit card at a booth outside fenway a couple years ago. Then she got a call for activity on a credit card that she never got. Fortunately, the purchases were in stores in London, and she hadn't been to London. The credit card was deactivated and the charges removed. How do you plan to solve a "trust" problem that costs no money, and must be essentially free to the user? If you have a solution, don't bother with spam. Call Visa, and be rich. On second thought, call me. I'll split it with you :-) > This echoes the comments made > by the IAB in section 3.1 of > (http://www.iab.org/documents/drafts/draft-iab-e2e-futures-05.txt). > > How would introducing trust help with the spam problem? Would the cost > of doing so perhaps would be so prohibitive that we will not be able to > do so? Is it really possible to introduce trust that will actually work? > > Yakov > >
Re: Apology Re: Principles of Spam-abatement
On Tue, 16 Mar 2004, Ed Gerck wrote: > To implement these solutions, we need an Internet design where we > recognize that the end points have become much less trusted than the > connection. This is the opposite of what the DARPA Internet assumed and > was designed for. So, some things gotta change. I was going to say something before about this. In the original design, only _some_ ports were to be more trusted, those below 1024. Back in the mainframe day, the mainframe itself was clearly more trusted. But it was still the case that users could open untrusted ports, so the entire machine was not trusted, and all endpoints were not assumed to be trusted. And contrary to belief, we had spam (or abuse) back before commercialization, too. I remember starting a "network software engineer" job in 1991 that included system administration at Kendall Square Research (KSR). KSR was a supercomputer company, and employed some very smart people. Never-the-less, in my first week, I got to meet one bright young VLSI engineer who had a cron job running that sent an email every 5 minutes saying "you're a jerk" to someone he had gotten into a flamewar on some usenet news group. (We had a uucp 9600baud leased line, and were waiting on a 56K to Nearnet) That was a fun way to meet new people. "Hi, I'm the new guy in Swee's group. By the way, that special cron job you have going, Knock it off." > For example, saying that you're "[EMAIL PROTECTED]" should not be so > easy to do when you're sending email, even though it should still > be easy to set "[EMAIL PROTECTED]" as your address in your MUA. The From: address is just dressing. It makes no difference what its actual value is, nor that it can or can't receive email. As was pointed out, many things only send email, and don't receive it. Those things will have informative (or not) from addresses that are invalid for reception. --Dean
Re: DARPA get's it right this time, takes aim at IT sacred cows
jfcm wrote: At 21:45 15/03/04, Scott Michel wrote: We identified five main (immediate/middle terms) threats (and agree with the USG they may be critical [we say "vital"]): - DNS centralization - IPv6 unique numbering plan - mail usage architecture (not SMTP) - governance confusion - non concerted national R&Ds (starting withthe US one) You've managed to identify operational problems, not protocol problems. The Internet's continued operation may face some serious challenges if certain trends continue, vraiment. It's not a compelling reason for a "national firewall" as you described. At the risk of being particularly crass, it sounds a lot like building the Internet equivalent of the Maginot line. It's a noteworthy proposal, as you described it, but the management of such an entity would be hideous. Even if the management and policies of Internet operation/management could be compartmentalized as you describe, you'd still have roughly the same problems with domain names, address allocation, etc. I'm not sure I see what the advantages would be. To be fair, it was NATO and the Allies who started in the v6 direction first. DoD is just merely keeping up with its various international partners. hmmm. May be you did not evaluate what the worldwide control of IPv6.001 gives to who allocates the addresses (ICANN) and whould build an run an IPv6 "DNS". A few years back, I was a co-author on a few whitepapers for customers who were wondering whether they should head down the IPv6 road because European partners were already heading down that road. I'm familiar with some of the history. The problem is that this "agility" is to be housed somewhere. Let assume DARPA produces tangible results soon (what I is quite credible) we are not in the 80s anymore, on "ARPA Internet". We are on Global Internet, and a Global body is to publish it. This leads to ITU. And as long as ITU-I has not been created on purpose, I am afraid it is acceptable to no one. I was waiting for the ITU to get dragged into this discussion. Yup, the same folks who brought us all of the other unsuccessful networking standards. Sorry if I'm biased here, but as it is said, history books are written by the winners. So, getting back to that discussion about ATM... :-) We agree. But we are considering today/tomorrow warfare. The Irak action started with the first real "cyberbattle", a two days saturation spamming preparation. Exactly like before a Marines landing with artillery (what they had on the boarder too if I am right?). Snipers coordinate through cyberspace. Soft unstabilization of Europe is hopefully right now a cyber activity, rather than a Marines one :-). What you're referring to is not network-centric warfare at all. You're referring to a specific tactic in the psychological warfare operations side of the military. It's a important as the "kinetic response" (USAF and USN dropping bombs, the USMC landing ashore, etc.) It's merely part of attacking a national infrastructure just as much as reducing electrical power plants to rubble attacks a national infrastructure's capabilities. Network-centric warfare has nothing to do with psyops. N-C has more to do with command and control of assets deployed to a theater, assessing and prioritizing threats, etc. hmmm. I think you really need to read http://whitehouse.gov/pcipb. The documented priority is not only the warfighter's life, but the nation's life and way of life, in protecting critical installations and systems. SCADAs are a priority. I agree that DARPA looks also how to quickly deploy responses for urban warfare. But it is "also". All the more than cyberwarfare is a very important key to urban warfare. DARPA and DHS (and its DHSARPA) are two separate entities with different missions. DARPA's focus is the warfighter, DHSARPA's focus is homeland security. The two missions may be integrated via a White House position paper but it takes the two agencies to execute the vision. BTW: DARPA doesn't deploy anyone to anywhere... it does research and evaluation. The respective military service branches deploy people to places using technologies that may have been influenced by DARPA research or evaluated by DARPA (e.g., Internet, M-16s, ceramic armor, UAVs, etc.) The model I use is only partly 3D (a cylinder figured through half a covering elipse on the top - like an open binder you would look from the cover side). This is only to show two things: - the unlimited continuity there should be at the same layers - whatever the layers may be. And to sort it (like from individual to groups) - the fact there are common spines. Your model still sounds much to complex for ordinary mortals to grasp. While it sounds like it should show the interactions between layers of different types and models cleanly, it would probably be sliced apart by Occam's Razor. This is why the 4- and 7-layer models work so well: they are the simplest models that suffice. Well, s
Re: DARPA get's it right this time, takes aim at IT sacred cows
Thus spake "Scott Michel" <[EMAIL PROTECTED]> > As one other responder said, there is a need to accomodate different > addressing styles that separate identity from location. I agree with the > sentiment. So, [erhaps it is only necessary and sufficient to extend or > redefine IP's addressing? When you add in the (assumed) requirements of backwards compatibility with existing routers and hosts that don't implement a proposed extension, it gets messy real quick. HIP is a good start, but it's still only a BOF and the involvement is nowhere near what one would expect for (IMHO) the most significant IETF project since IPv6. > Or perhaps it's only necessary and sufficient to design a universal > application-level forwarding layer? (Warning: plug for my own research > called FLAPPS, http://flapps.cs.ucla.edu/) While that's certainly interesting in its own right, what I think DARPA (and the IETF) is looking for is something between the network and transport layers, not something above transport. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: Apology Re: Principles of Spam-abatement
Dean Anderson wrote: > > On Tue, 16 Mar 2004, Ed Gerck wrote: > > For example, saying that you're "[EMAIL PROTECTED]" should not be so > > easy to do when you're sending email, even though it should still > > be easy to set "[EMAIL PROTECTED]" as your address in your MUA. > > The From: address is just dressing. It makes no difference what its actual > value is, nor that it can or can't receive email. As was pointed out, > many things only send email, and don't receive it. Those things will have > informative (or not) from addresses that are invalid for reception. Things that send email but don't receive them can nonetheless have a valid email entry for 'no mail accepted', with no mailbox. In terms of trust as I defined before here [1], an email address for those things (or any other things) should have a *minimum* of three values: + trusted according to policy(+) 0 trust value not assigned - distrusted according to policy(-) Of course, the positive and negative range can be expanded in values as well. How to assign these values? How the trust model works? Let me copy from an earlier discussion elsewhere. This is the wrong question to ask. The real answer is, "what trust model would you like?" There is a built-in notion (given by the abstract trust definition in [1]) of the meta-rules that a trust model has to follow, but I might buy a trust model from someone and add that, design my own, or even augment one I bought. Thus, I can ask for a fingerprint and check it against the FBI, Scotland Yard, and Surite databases, check their PGP key to make sure that it was signed my Mother Theresa, ask for a letter of recommendation from either the Pope or the Dalai Lama (except during Ramadan, when only approval by an Iman will do), and then reject them out of hand if I haven't had my second cup of coffee. As flippant as I'm being, this has a lot of value. I write with a GUI framework because I don't have to worry my pretty little head about the details of how to draw a checkbox. I ask the system to draw it for me, and it does. It even handles what happens when it's clicked. I just ask the checkbox if it's on or off, and it tells me. If I want a special checkbox, I can make one of those as a subclass, and once I've done that work, I don't have to think about it again, I just use it. Similarly, if I use such a concept of trust, I may have to do some up front work to get things the way I want but I can always use an off-the-shelf validity mechanism. In either case, I just ask the trust framework if the trust assertion is valid. The framework can combine rules of thumb with special-cases as appropriate, and without my having to worry my pretty little head about it. Trust on the sender cannot be proven by the sender (self-assertions cannot induce trust -- e.g., "trust me" doesn't work), but must be calculated using sources independent of the sender. The sender may hint to a specific trust service used, and even provide it and its values, but we should be able to get that information from the service directly and/or chose our own trust services independently. In doing so, trust on the sender is what the receiver determines at a specific time based on a behavior model for the sender. If the sender cooperates, the process can be faster and easier. But the sender cannot determine the process. The problem is, thus, not how do you determine trust, especially with all the different definitions of spam possible, but how do you want to do it. Cheers, Ed Gerck [1] http://nma.com/mcg-mirror/trustdef.htm
Re: DARPA get's it right this time, takes aim at IT sacred cows
On Tue, Mar 16, 2004 at 07:09:12PM -0600, Stephen Sprunk wrote: > When you add in the (assumed) requirements of backwards compatibility with > existing routers and hosts that don't implement a proposed extension, it > gets messy real quick. The immediate handwave would be "Tunnel it." I'm not denigrating backwards compatibility, but a lot of good work has relied on tunneling in the past, e.g., Mbone and v6-v4. I'm currently waiting with baited breath the day that service providers provide v6-to-v4 as the special case to v4-only hosts. > HIP is a good start, but it's still only a BOF and the involvement is > nowhere near what one would expect for (IMHO) the most significant IETF > project since IPv6. Must find more copious free time. Must find more copious free time. > While that's certainly interesting in its own right, what I think DARPA (and > the IETF) is looking for is something between the network and transport > layers, not something above transport. You never know until you submit a proposal what DARPA **really** wants even after you get through the program-speak. FLAPPS got funded for a while under the Fault Tolerant Networks program, as did a lot of other research. Might be that there are multiple shim layers between network and transport, transport and application. That said, a lot of things can be solved in the application layer (or adding thin layers underneath the app layer) because adding them to the network and transport layer is less tractable. A good example is multicast -- it works well and fits into the network layer but the problems with routing protocols to get the distribution tree built turns out to be a long IETF standards process exercise. Application-layer mcast seems to be more of a winner than network-layer (just my perception, you may now fire at will.) In any case, it's fuel for interesting discussions. -scooter
Re: Apology Re: Principles of Spam-abatement
Dean Anderson wrote: > > On Tue, 16 Mar 2004, Ed Gerck wrote: > > What information theory says is that the probability of detecting > > spam is less than 100%. > > No, information theory doesn't say that at all. Sure it says, and that's why a spam filter will never be 100% effective. I guess we agreed on this before ;-) We also agreed that spam filters are a user matter, not IETF matter. Now, you may want to refer to that mythical element, the 'spam-free' protocol, a protocol that an information theory model says cannot be built. I guess we also agreed before that a 'spam-free' protocol is impossible. The IETF should not attempt to develop it. Thus, in asking for IETF technical solutions for spam, it is obvious that I do not mean spam filters or 'spam-free' protocols. We would all be very happy with a protocol that is almost spam-free -- in fact, I believe we would be quite happy with 90% at this time. Me thinks we don't need 100% ;-) An IETF technical solution to reduce spam is doable. Your comment on 'spam-free' is useful-free ;-) > No, it is quite useful: The IETF can do nothing to prevent spam. ;-) this mantra is becoming a spam. > > What interests the IETF are technical spam solutions, for example, > > that would prevent email that comes from unidentifiable or rogue > > senders/MTAs to be ever received. > > The only thing that can acheive this is to turn off the computer. No, it's a matter of degree. Even if not all spam is preventable, preventing email address spoofing (even to a degree) would have a range of benefits. For example, I would no longer receive those "undelivered" messages for email that I purportedly sent, but actually never did. And people receiving email from me could actually trust to some extent the outcome of their filters. And, to be clear, I'm not talking about PKI. > The IETF can specify protocols with certain features, say PKI, but doing > so will not prevent spam, since the IETF (nor anyone else) cannot specify > a 'spam-free' protocol. This is a result of information theory. Because it can't be perfect, it can't be done? No one needs perfection. All we need is to have a degree of spam-freeness that is acceptable. Sterilized milk is not bacteria-free, it just has a reduced count of bacteria -- which count is low enough to guarantee its stated shelf life. Cheers, Ed Gerck, who doesn't believe in rejecting every possible spam bit.
Re: DARPA get's it right this time, takes aim at IT sacred cows
Thus spake "Scott Michel" <[EMAIL PROTECTED]> > On Tue, Mar 16, 2004 at 07:09:12PM -0600, Stephen Sprunk wrote: > > When you add in the (assumed) requirements of backwards compatibility > > with existing routers and hosts that don't implement a proposed extension, > > it gets messy real quick. > > The immediate handwave would be "Tunnel it." I'm not denigrating > backwards compatibility, but a lot of good work has relied on tunneling in > the past, e.g., Mbone and v6-v4. I'm currently waiting with baited breath > the day that service providers provide v6-to-v4 as the special case to > v4-only hosts. The Mbone and 6bone are different beasts, as they're about tunneling traffic from capable hosts across an incapable core. In the case of an identity layer between IP and TCP, we would need to be backwards-compatible with non-capable hosts and applications (not just non-capable routers) and so tunnels don't seem a workable solution. > > HIP is a good start, but it's still only a BOF and the involvement is > > nowhere near what one would expect for (IMHO) the most significant > > IETF project since IPv6. > > Must find more copious free time. Must find more copious free time. Ditto... > > While that's certainly interesting in its own right, what I think DARPA (and > > the IETF) is looking for is something between the network and transport > > layers, not something above transport. > > You never know until you submit a proposal what DARPA **really** wants > even after you get through the program-speak. All too true. We do, however, know many of the IETF's needs in the identifier/locator arena, e.g. for Mobile IP and IPv4/6 multihoming. That may be a good starting point to determine what, if any, additional requirements DARPA has. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Welcome to DRIS discussion list!
Welcome to DRIS discussion list! After holding the BOF in 59th meeting, we will start the WG application process. As the advice of APPS, we still should found more people to join its discussion list. DRIS is a large system, without enough people, the new WG may not meet its milestone. If you are interested in this topic, sincerely wish your could join its discussion. As the agenda of IIRI (http://www.ietf.org/ietf/04mar/iiri.txt), This new WG will cover the Internet search engine, Digital Library, Information GRID, etc. Any related topic could be discussed in this list. We all have a common goal: a usable Internet information infrastructure. Although it's the first time that IETF organized the formal discuss for Internet information retrieval problem, there has been many sporadic discussion for it in other place like IRTF. Now search engine has become the hottest topic since 2003. Some disadvantages in current search engine attracted many experts to find the better solution. IETF may be the best place to discuss the new Internet information retrieval system. Mailing list: [EMAIL PROTECTED] subscribe: [EMAIL PROTECTED], to subscribe,send a message with title "subscribe" new site: http://dris.hust.edu.cn Regards Wang Liang
Re: Apology Re: Principles of Spam-abatement
On Tue, 16 Mar 2004, Ed Gerck wrote: > Trust on the sender cannot be proven by the sender (self-assertions cannot > induce trust -- e.g., "trust me" doesn't work), but must be calculated using > sources independent of the sender. The sender may hint to a specific trust > service used, and even provide it and its values, but we should be able to get > that information from the service directly and/or chose our own trust services > independently. In doing so, trust on the sender is what the receiver > determines at a specific time based on a behavior model for the sender. > If the sender cooperates, the process can be faster and easier. But the > sender cannot determine the process. > > The problem is, thus, not how do you determine trust, especially with all > the different definitions of spam possible, but how do you want to do it. I wrote one whole response earlier but deleted it (fortunately, as Dean went through my points far more tersely than I was about to). Here I just can't stand it. Ed, are you not paying attention? It is fundamentally, intrinsically, eternally IMPOSSIBLE TO IDENTIFY INDIVIDUAL HUMANS on the internet. I can sit at my laptop and create a hundred entirely real accounts with no humans behind them, with real humans behind them, with me behind them, with alien invaders who will eat your head behind them. From the other side of my network connection YOU CANNOT TELL which of these are real and which are fake. You will never be able to tell without violating so many of my civil liberties that I (and everybody else on the planet) would be out in the streets rioting to get them back. Mail sent out by my perfectly functional MTA (any of them that I might choose to install or one that I might custom-write to serve a particular purpose) is for all practical trust-based purposes ANONYMOUS. Mail has always been designed to be anonymous (paper mail too). There are individually authenticated services and there are anonymous services, and mail transport is an anonymous service because it crosses authentication boundaries. Mail (paper or otherwise) has an envelope, sure, but the only thing on it that you can trust even a little bit is the set of postmarks it develops along its route to your mailbox (and even here, you can really only trust the LAST postmark in the chain, the one one hop upstream). Your MTA cannot fill in the envelope. That can only be done by my (the sender's) MTA unless you've developed that psychic mail transport mechanism. This is no different from paper mail. YOU have to fill in the address information on a paper envelope. You control the pen as surely as you control your sending MTA -- every byte or stroke can be truth or lie. You can lie about your return address. You can fill the envelope with ricin and anthrax or with money and praise (I'd prefer the latter, naturally). I cannot tell if the envelope tells the truth before opening and reading the message. I cannot even tell with CERTAINTY that the envelope tells the truth AFTER opening it except by an out of band communication with the sender. If you want to argue that all mail has to be sent the electronic equivalent of "certified mail" in the paper world, forget it and think through the metaphor. First of all nobody EVER sends certified mail in the paper world except when money is on the line because a) it COSTS money to have it certified; and b) it is a pain in the ass to have it certified (it costs time). Finally, even in the paper world, "certified mail" generally means that you send it TO a positively identified receiver with a guarantee that they will receive it. You are generally NOT required to show some sort of id proving that the return address is valid and that you are the person corresponding to the return address and indemnity information. Maybe you are. Maybe you aren't. Maybe you're just a messenger boy. Maybe you're sending well-certified anthrax and lie about everything on the return/sender forms you fill out. In any event, you likely own, literally, the certifying machine (the sender). Spam and paper mail abuse is not a problem that can be solved by addressing trust of identities. It is fundamentally a problem WITH real identification. In the HUMAN world, it is remarkably difficult, and remarkably uncommon, to validate that a human is who they say they are; most glib examples that have been cited to show that it can easily be done show the opposite -- that it is NOT easy and it IS expensive and a PITA. My kids have to bring birth certificates and photo id's to certain things (SAT tests, school registrations). These documents/tokens are not easy to file, to find, to to keep straight and available and are easily lost or stolen. I have to show certain forms of legally certified id in order to validate certain transactions, mostly involving money, and I have to jealously guard them as they are easily lost or stolen. Rituals involving them (such as getting a loan or cas
Re: [ga] LatinoamerICANN publica versión en españolde los Estatutos delICANN
Dave and all, Dave Aronson wrote: > On Mon March 15 2004 23:19, Jeff Williams wrote: > > Dave Aronson wrote: > > > Jeff Williams wrote (though I get the impression he's summarizing > > > other people's objections, not raising them himself, as he then > > > answers them): > > > > I sure did, and for what should have been an obvious reason. It > > seems in your case Dave, what is plainly obvious escapes you. That > > is indeed a sad commentary on the IETF... > > Well excuse... mee!!! B-P Your diatribe that I responded > to, was the first appearance of this thread on the IETF list, at least > according to my trash-folder. No excuse Dave as this thread originated on the DNSO GA forum, and your previous response did a disservice to others on that forum by you removing [EMAIL PROTECTED] from the recipients of that forum. > Looks like you crossposted it. If you > don't want our input, then don't bother us. I "CC'ed" [EMAIL PROTECTED] because my response included the IETF by name. Hence it would have been rude and irresponsible not to ensure those IETF members on the main IETF forum the opportunity to respond/remark and/or contribute. If doing so is offensive to you in particular Dave, you have my empathy... However being one that is and has always been interested in, and supportive of inclusiveness, reasonable transparency as well as a long time IETF participant, it seemed reasonable and prudent that I am interested in my fellow IETF participants... So "us" is inclusive of you and I, Dave... >;) > > > > > 1) The people at the UN are, generally speaking, career > > > diplomats. Knowing foreign languages and cultures is part of their > > > way of life. > > > > This is true in some UN agencies, and certainly not in others as > > several are almost entirely volunteers... > > Fair enough. I was speaking mainly of the General Assembly delegates, > though they are a minority of the entirety of UN employees, observers, > etc. Well sorry again Dave, but you are still mistaken. Most of the UN General Assembly delegates are english speakers and all while in the general assembly meetings have real time translation capability both ways... > Even regarding the others, the UN's entire point is international > cooperation for basically its own sake (even if specific agencies have > more specific missions). It seems obvious to me that they will be more > often people who have an interest in foreign languages, than will most > other groups, even those that operate internationally. You MAY have a good point here I will grant you. But it is a speculative point at least... > > > > > Even if they do not know the particular language someone else is > > > speaking in, they should at least be basically familiar with the > > > most popular languages of the world. > > > > Agreed as should most IETF'ers or ICANN'ers as they espouse to > > be an international organization. > > I suspect that many, if not most, of us would still be here even if the > network were only available in our own respective nations. (Though > admittedly, it would then be less useful, especially to the smaller > nations.) That it lets me also communicate with the other side of the > world is great, but frankly, the vast majority of the people I > communicate with via the Internet, live here in the US. So, the > international aspect of it is not as important *to me* (I won't presume > to speak for anyone else), as (I ass-u-me) the UN's is to its people. > Again, recall that the international aspect is basically the entire > point of the UN Also mostly agreed here too. However as the UN is and has been less than well respected on an international basis for various reasons based on repeated errors in judgment and subsequent action they as a international body, hardly are representative in any superior way to many other international bodies that are not UN related... > > > > So Erick in this instance should > > have been easily to be able to provide an english translation as > > would be in keeping with good manners. However he did not... > > Whatever. Remember, the IETF list did not get the background messages > to which you refer. True the [EMAIL PROTECTED] forum didn't get the background messages because the IETF was not mentioned.. > > > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders > > strong!) "Be precise in the use of words and expect precision from > > others" - Pierre Abelard > > "Be conservative in what you send, and liberal in what you accept." > -Popular paraphrasing of Jon Postel from RFC 791 (Internet Protocol) > > -- > Dave Aronson, Senior Software Engineer, Secure Software Inc. > Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org > (Opinions above NOT those of securesw.com unless so stated!) > WE'RE HIRING developers, auditors, and VP of Prof. Services. Regards, -- Jeffrey A. Williams Spokesman for INEGro
Re: Apology Re: Principles of Spam-abatement
On Wed, 17 Mar 2004 00:44:58 -0500 (EST), Robert G. Brown wrote: >Ed, are you not paying attention? > >It is fundamentally, intrinsically, eternally IMPOSSIBLE TO IDENTIFY >INDIVIDUAL HUMANS on the internet. "No one knows you're a dog on the Internet" seems to capture it. (Dilbert?)
Re: Apology Re: Principles of Spam-abatement
"Robert G. Brown" wrote: > > Ed, are you not paying attention? Read below and draw your own conclusions, please. > It is fundamentally, intrinsically, eternally IMPOSSIBLE TO IDENTIFY > INDIVIDUAL HUMANS on the internet. Who is talking about humans? I am talking about EMAIL ADDRESSES, MTAs, MUAs, END POINTS. Trust at the end points -- the end point is able to do TCP/IP, end points are not human. It is also not relevant if there is, or there is not, a human in control of an end point. It can very well be another machine. I also mentioned that trust should be based on the same definition betwen machines as we use for millenia between humans. Why? So that machines could use well-developed, real-world, tested notions of trust -- and be thus useful as our agents. This answers the rest of your email. Are you paying attention? ;-) Cheers, Ed Gerck PS: BTW, take a look at a work some 5 years ago allowing ISPs to identify who was at the keyboard by their usage pattern, in a household, to properly target advertising. Humans are more identifiable on the Internet than you think. But this is 100% irrelevant to what I wrote about. Humans can't do TCP/IP.
RE: Apology Re: Principles of Spam-abatement
> >It is fundamentally, intrinsically, eternally IMPOSSIBLE TO IDENTIFY > >INDIVIDUAL HUMANS on the internet. > >"No one knows you're a dog on the Internet" seems to capture it. > >(Dilbert?) Actually, this cartoon was published in The New Yorker on July 5, 1993, by Peter Steiner. "On the Internet, nobody knows you're a dog." (A dog, sitting at a computer terminal, talking to another dog.) -- Christian Huitema
