RE: Protected message
RE: Text message
Re: Incoming Fax
Re: Hello
Re: DARPA get's it right this time, takes aim at IT sacred cows
At 01:52 17/03/04, Scott Michel wrote: 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. I am afraid you confuse layers. You can understand "firewall" as a traffic filter (what you obviously consider here): this would be obviously absurd fro what I address. You can also consider it as the appropriate protection for the considered layers, what we mean. If you want an exemple, look at Intelliwall (http://www.bee-ware.net). They are addressing the firewalling of applications. Traffic filtering is really the third lowest level (after electric and frame protection). I will address the point more generally at the end - when discussing FLAPPS. 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. Let not confuse the IPv6 protocol and the various IPv6.001,010, 011,etc. numbering plans. I am only talking about numbering plans. Which may outlive or be independent from IPv6. 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... :-) I said I would not comment on ATM. Another story. 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. Here you talk of N-C as ABC. I am talking of cyberspace (or e-space), as there is airspace, outerspace, sea, or land ... and joint operations. 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. Decision to puts Cyberse
callplot tool for generating call flows
One of the challenges in producing an Internet Draft is the creation of ASCII art call flow diagrams (aka sequence diagrams), such as those in http://www.ietf.org/rfc/rfc3665.txt. I tend to do a lot of these in the drafts I write. To make the process easier, a colleague of mine, Dave Ladd, wrote a tool called callplot. Callplot takes a source file that describes the callflow, and then compiles it into an ASCII art version suitable for inclusion in Internet drafts. It does automatic message numbering, labeling, and so on. It can also spit out other formats that can be included in MS Office documents, for example. To illustrate, running callplot on this input: opt/columnPitch/15 guy/f/Fred guy/b/Barney f->b/Please note/b/Gives bowling ball b->f/Stuff b..f/RTP f->b/Thank You b->f/You're Welcome produces this diagram: Fred Barney | | | | | | |Please| |->| | | | | | |Gives bowling ball | | | | | | |Stuff | |<-| | | | | |RTP | |..| | | | | |Thank You | |->| | | | | |You're Welcome| |<-| | | | | | | | | I think this tool would be useful to the IETF community at large. As a result, we've decided to make the tool open source, available at sourceforge at: http://sourceforge.net/projects/callplot Callplot is written in Java. Please feel free to download, use, and provide improvements on this tool. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D.600 Lanidex Plaza Chief Technology OfficerParsippany, NJ 07054-2711 dynamicsoft [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com
Re: Apology Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Ed Gerck wrote: > > > Dean Anderson wrote: > > > > On Tue, 16 Mar 2004, Ed Gerck wrote: > > > > > 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 ;-) > > > > I think you must have missed my message noting our disagreement. > > http://www.ietf.org/mail-archive/ietf/Current/msg24213.html > > Let me make sure. You think then that a spam filter can be 100% > efficient? If you do, please log off and go sell it. If you > don't then I agree with you. No, that isn't what I said. You need to re-read the message. It is fairly clear. --Dean
Categorization of TCP/IP service provision types (was: Re: The right to refuse, was: Re: Principles of Spam-abatement) (FWD: I-D ACTION:draft-klensin-ip-service-terms-00.txt)
Last week's version of the spam discussions, led to an interesting (to me) side-discussion about what was, and was not, an "Internet connection" service. There have been discussions on and off for years (since before the User Services area was inactivated) about doing such a set of definitions. On my general theory that it is better to try to actually do something than it is to discuss forever how desirable it might be, I've hacked a preliminary document together and posted it as draft-klensin-ip-service-terms-00.txt. This clearly isn't finished, indeed, it is not much more than a skeleton with a few examples. It needs more work, probably additional categories, and more clarity about the categories that are there. If there is real interest in the subject, I'd like to see someone else take over the writing and editing. If there isn't any real, perhaps we can stop spending time discussing the subject. I-D announcement attached. john --- Begin Message --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Terminology for Describing Internet Connectivivy Author(s) : J. Klensin Filename: draft-klensin-ip-service-terms-00.txt Pages : 6 Date: 2004-3-17 As the Internet has evolved, many types of arrangements have been advertised and sold as 'Internet connectivity'. Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, has cause considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-klensin-ip-service-terms-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: "FILE /internet-drafts/draft-klensin-ip-service-terms-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --- End Message ---
Re: GRE and L2TP
Rohit Gupta wrote: Hi, What is it in L2TP that i cant do with a simple GRE tunneling when implementing a remote access VPN for a mobile client to connect to the corporate network. In L2TP, since it uses PPP end-to-end, the LNS is able to supply dynamic IP address using IPCP to the remote client. LNS takes this IP address from a pool of IP addresses it has. If one were to use GRE, then the same can be done by using some out-of-band mechanism (or even have a fixed IP address which the mobile client is instructed to use). GRE will tunnel the data packet originated from the mobile client, the inner IP header will have the ip addresses as assigned by the corporate network. The outer IP header will contain the IP address of teh ISP and the gateway to reach the corporate network. GRE is an encapsulation. If you can manually provision or have some other "out of band" mechanism that does everything L2TP and PPP would otherwise do for you, then by all means use GRE - or IP in IP for that matter as your scenario with fixed IP addresses for all mobile clients (which I would think is a showstopper from the start) does not obviate the need for a GRE shim either. L2TP is an encapsulation that allows multiplexing of multiple PPP sessions between two IP-connected endpoints, and a control protocol for dynamically establishing and maintaining the emulation of these PPP sessions. This is very different than GRE (though there are some ways to deploy L2TP between two routers to make it look like it is doing what GRE typically does in a bit more of a dynamic manner, though this is really a subset of L2TP's overall functionality). Since you indicate that this is for a mobile environment, you might want to look at using Mobile IP. My whole point is that i want to know as to what is the burning need to have L2TP! This question probably has more to do with whether you need PPP. If you do, L2TP could work for you to transport that PPP session (or many PPP sessions) over an IP network. If not, I see no reason for you to be burning with need for L2TP! - Mark Regards, Rohit P.S. Am not sure if this is indeed the right place to ask this question. But since there will be a lot of experienced people on this list who would have worked on both these protocols, replying to this one should be very easy. __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
Re: Apology Re: Principles of Spam-abatement
Dean, I'm not gonna feed the troll. The bottom line is that spam filters are not 100% effective and anti-spam protocols are not 100% effective either, in the same way that your car is not 100% fuel effective. The reason is pretty much the same. Thus, your indefatigable assertion that there are no technical solutions for spam strikes me as irrelevant. We all work with and improves things that will never be 100% effective. The good part of this is that we shan't run out of work ;-) If you don't agree with any of the above, pls email me in PVT. Cheers, Ed Gerck Dean Anderson wrote: > > On Wed, 17 Mar 2004, Ed Gerck wrote: > > > > > > > Dean Anderson wrote: > > > > > > On Tue, 16 Mar 2004, Ed Gerck wrote: > > > > > > > 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 ;-) > > > > > > I think you must have missed my message noting our disagreement. > > > http://www.ietf.org/mail-archive/ietf/Current/msg24213.html > > > > Let me make sure. You think then that a spam filter can be 100% > > efficient? If you do, please log off and go sell it. If you > > don't then I agree with you. > > No, that isn't what I said. You need to re-read the message. It is > fairly clear. > > --Dean
Re: Apology Re: Principles of Spam-abatement
[EMAIL PROTECTED] (Ed Gerck) writes: > Dean, > > I'm not gonna feed the troll. ... NOW you're not gonna feed the troll? where's the "...any more!" ?? it does me no good to filter out postings from known whackjobs if you and others are just going to reply anyway, often including the very drivel that i'd avoided having to look at directly. please show some self-restraint. -- Paul Vixie
Re: "Principles" of "Spam-abatement"
On Wed, 17 Mar 2004, Doug Royer wrote: > Dean Anderson wrote (in part): > > >> c) Work out what to do about relays and proxies, again to prevent > >>man-in-the-middle DoS more than anything else. One site should not be > >>able to generate mail that it "forwards" with fictitious headers and > >>evil content so that it appears to come from some hapless but innocent > >>network. > >> > >> > > > >Relays don't add ficticious headers, nor do they add evil content. They > >may place their (true) headers on top of ficticious headers. They cannot > >verify that the headers given are accurate. This is true of all relays, > >open or closed. > > > > > Sounds like his first point - fix it so they are checkable. If I am > going to relay for X number of domains, it seems reasonable that we > share some kind of shared key or password so they the headers they pass > me can be verified. The premise that relays add ficticious headers and evil content is wrong. But header checking would not be practical. It quickly becomes: "I am going to relay for some domains. The domains I am going to relay for are unknown in advance (or very much in advance) because the customer may add new domains. Further, that customer may themselves relay for some number of unknown domains." The description I gave of reasons that RMX won't work also applies. You may have to relay for other domains. The problem is very similar to, but much, much larger than the BGP route registries' configuration databases. There are about 140,000 or so advertised network number prefixes, and providers change their routing to other providers relatively infrequently compared with end users. The Route registry, in principle, allows one to automatically generate router configurations based on the what routes might be advertized by which AS numbers. In practice, it hasn't been such a success, though it does have it's proponents. It sounds much better in theory than it does in practice. Trying to do the same for millions of domains would be impractical, since the routing of those domains is even less static than the network routes between service providers. At the end of this, all you find out is that spammers will stop using forged headers. But quite a lot of spam these days doesn't have any forged headers. Indeed, it seems that spammers/abusers have lost interest in adding forged headers, as they have lost interest in open relay abuse. There is a related point that the IP addresses in the forged headers appear to be chosen randomly. So some percentage of these will not be routed, and will not be allocated. One could easily implement a check which simply tested all the IP addresses in the headers for routability. Of course, spammers would stop picking addresses at random, and would simply start selecting random addresses from the route tables. Such a test is obviously not worth implementing. > There is (1.0) legal spam and (2.0) illegal spam. > > Illegal spam can be (2.1) advertisements or (2.2) viruses. > > (1.0) Is most often traceable using the headers and content. > This is getting easier to stop and there can be things done > to make it easier - a computer parseable unsubscribe link and >a standard protocol to unsubscribe. CAN-SPAM prescribed the use of unsubscription methods, and 56% of spammers were fully compliant in January, and 95% were partially compliant in January. I've been using the links on some spam from genuine spammers, (eg tekmailer.com). They've been providing a mail-to url and an http url for unsubscription. These are already computer parsable. However, the hard part is to distinguish the genuine spammers from the fake spammers. I've been able to do this in most cases by examining the headers and the company--genuine spammers won't have any forgeries at all, and looking up information on them will turn up the fact that they are a real company. Fake spammers have web sites, too, and their unsubscribe links result in further mail bombing. But so far I've been able to pick them out, as they have to fake something, else they'd be real. > (2.1) Often is traceable by the content, and almost never by the headers. This isn't true. After the abuser has injected the message, the subsequent headers will be true. So abuse is traceable by the headers back to the SMTP injection point. Forged headers are always detectable, since they try to make one believe that mail was handled by a machine IP address that didn't actually handle the message. It is easy to see where the authentic recieved headers stop and the forged headers start. However, one can (and SpamCop does**) forward a complaint to the responsible party for each listed relay and domain. Those parties can then determine by looking at the message and their logs if their users were responsible for the message. If the message was injected by an open proxy, you can trace back to the open proxy. You may not be able to trace beyond that,
Re: Apology Re: Principles of Spam-abatement
Did anyone expect professional behavior from someone who doesn't have an AUP on their own sites, someone who supports demonstrated abusers, someone who associates with court-proven liars, and someone who posts misleading information about their own legal experiences? I didn't. Clearly, technical competence does not equate to honesty and integrity. It also does not equate to professional conduct. And of course, those who lack intelligence to make sensible arguments have to resort to name-calling. I'm surprised it took this long to resort to name-calling. --Dean On 18 Mar 2004, Paul Vixie wrote: > [EMAIL PROTECTED] (Ed Gerck) writes: > > > Dean, > > > > I'm not gonna feed the troll. ... > > NOW you're not gonna feed the troll? where's the "...any more!" ?? > > it does me no good to filter out postings from known whackjobs if you > and others are just going to reply anyway, often including the very > drivel that i'd avoided having to look at directly. > > please show some self-restraint. >
Re: Apology Re: Principles of Spam-abatement
Well, you are the one trying to attribute statements that "you agree with" to me, even though I've made it clear that we don't agree, and why we don't agree. If you can't understand what your opponents position is, and what points you agree and disagree with, there is no point in discussing it, until you do. --Dean On Thu, 18 Mar 2004, Ed Gerck wrote: > Dean, > > I'm not gonna feed the troll. The bottom line is that spam > filters are not 100% effective and anti-spam protocols are not > 100% effective either, in the same way that your car is not > 100% fuel effective. The reason is pretty much the same. > > Thus, your indefatigable assertion that there are no technical > solutions for spam strikes me as irrelevant. We all work with > and improves things that will never be 100% effective. The good > part of this is that we shan't run out of work ;-) > > If you don't agree with any of the above, pls email me in PVT. > > Cheers, > Ed Gerck > > Dean Anderson wrote: > > > > On Wed, 17 Mar 2004, Ed Gerck wrote: > > > > > > > > > > > Dean Anderson wrote: > > > > > > > > On Tue, 16 Mar 2004, Ed Gerck wrote: > > > > > > > > > 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 ;-) > > > > > > > > I think you must have missed my message noting our disagreement. > > > > http://www.ietf.org/mail-archive/ietf/Current/msg24213.html > > > > > > Let me make sure. You think then that a spam filter can be 100% > > > efficient? If you do, please log off and go sell it. If you > > > don't then I agree with you. > > > > No, that isn't what I said. You need to re-read the message. It is > > fairly clear. > > > > --Dean > >
L2TP Deployment Scenario?
Hi, > L2TP is an encapsulation that allows multiplexing of multiple PPP sessions > between two IP-connected endpoints, and a control protocol for dynamically Since L2TP is so strongly tied with PPP, can i assume that it will be *mostly* used when a user dials (ISDN/modem) into the ISP network (LAC) to contact the corporate network. Can I then connect a small branch office to the corporate network using L2TP? Does it make any sense doing that. I am now talking of a deployment scenario. Do you ever have two branches connected via L2TP? I searched the internet and found only scenarios wherein a remote access user dials into the ISP to access the corporate network using L2TP. Is the former possible? In theory, one could have a small office with some < 10 users connected to switch which in turn dials into the ISPs network. Is this possible? With regards, Rohit P.S. And thanks to everybody for responding both on the list and offline! __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
Re: Private message from John Klensin
It is considered bad taste to forward private message to public list without the author permission, regardless of the reasons you have to do so. james Dean Anderson wrote: This is the message to which Pete Resnick refers. I did not get this until Pete mentioned the message number and I searched for it. It is the _last_ private message John sent to me. In his other previous messages, John did not mention this experience. --Dean
