ICANN Board to implement IPv6 in root servers
http://www.ist-ipv6.org/modules.php?op=modloadname=Newsfile=articlesid=567 ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
STD series of documents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 May I suggest that a URL like: http://www.ietf.org/std/std0051.txt be made that can refer to the STD series of documents? - -- ] ON HUMILITY: to err is human. To moo, bovine. [ ] Michael Richardson,Seaway Networks Corporation[ ] [EMAIL PROTECTED] http://www.seawaynetworks.com/ [ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Finger me for keys iD8DBQFAtk0i22r3dfT9QZERAiWLAJ9O9dRISdt7fagCGJyfAS7hdUSrZACfWRWW 6LKcWWq7HHXPFDZp7w0xHmk= =iDjo -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
... HREF=http://sa.vix.com/~vixie/mailfrom.txt;MAIL-FROM/A. I do not see a draft in the ietf process anyplace . Was this ever submitted ? I do notice that several of the other proposal's make mention of this work , But in none of them do they mention it as a draft or other ietf work . there was no working group where it was appropriate at the time it was written. i've sent it to every one of the dozen people who have asked me to review some similar, and usually ill considered thing. i've also sent it to several spam-related and dns-related mailing lists, including this one (ietf@). Any plans to submit it as a draft . Tia , JimL MARID is basically a layer 9 exercise, uninterested in engineering as such. it was formed to merge two ill considered ideas, one from yahoo and one from microsoft, in a way that would cause either no loss of face, or equal loss of face, for those two parties. the people who submit their own ideas to it are wasting their time. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: ICANN Board to implement IPv6 in root servers
The headline is misleading. The recommendation is to support IPv6 registration of TLD servers in the root zone. The root servers themselves still need some testing before registration of their IPv6 capabilities. --bill manning ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
Iljitsch van Beijnum wrote: On 27-mei-04, at 16:56, [EMAIL PROTECTED] wrote: (I've yet to see a proposal that works if the spammers start utilizing zombie machines that snarf the already-stored credentials of the user to send mail) The question is whether spammers can obtain new credentials (stolen or otherwise) faster than others can blacklist them. And, if you had actually read the message you replied to, you would have realized that the answer is yes. Send out a worm that makes N zombies, have each zombie send one message under the local user's credentials, and none of them will get blacklisted. -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |The light at the end of the tunnel is a terawatt laser cannon. | \===/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Msg reply
Your_complaint.cpl Description: Binary data ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
From: John Stracke [EMAIL PROTECTED] (I've yet to see a proposal that works if the spammers start utilizing zombie machines that snarf the already-stored credentials of the user to send mail) The question is whether spammers can obtain new credentials (stolen or otherwise) faster than others can blacklist them. And, if you had actually read the message you replied to, you would have realized that the answer is yes. Send out a worm that makes N zombies, have each zombie send one message under the local user's credentials, and none of them will get blacklisted. Here's a defense for that scenario: 1. block port 25 to external IP addresses for all of your customers except those with what draft-klensin-ip-service-terms-01.txt calls Full Internet Connectivity. 2. Do not sell Full Internet Connectivity to anyone running Microsoft software exposed to the Internet. Possibly relax this with a $2000 bond forfeited along with connectivity at the first propagation of a worm or other spam. 3. The effects of #1 and #2 include forcing all mail from the usual suspects through your own mail systems so that you can do as the credit card companies do. Track SMTP envelope Mail_To values or other characteristics for each customer. When you see a change, contact the customer by voice to check. In practice, you could probably get by with detecting changes in mail volumes, since a spam spew of 1 message/zombie is at least 10 and probably 1000 times too low to be practical for high volume spammers. As far as I can tell, the typical user sends only about a dozen messages/day. Of course, the fatal problem with this spam defense is that it is not based on other people doing the work and paying the costs. It is not a coincidence that as far as I can tell Yahoo continues to be the most important U.S. host for Nigerian 419 spammers or that Windows XP practically requires or at least strongly encourages individual users to run their browsers and MUAs as administrator. It is not a coincidence that sender validating systems including those Yahoo and Microsoft are based on the rest of the Internet doing most of the work. The howls from the Special People who feel that they are entitled to Full Internet Connectivity at prices and terms they find comfortable (and about the per capita income in large parts of the world) are also related to the fundamental cause of all spam. There would be no spam problem including worms if every ISP would look after its own problems by terminating all spammers including customers who let their machines be owned or if all users were willing to pull their own weight instead of expecting something for nothing. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Summary of the ad-hoc WiFi problems at IETF meetings?
Greetings again. I was at a conference this week that offered WiFi. They had the same problems we had at the past two IETFs with a few folks doing ad-hoc mode, thereby knocking out access for many of us. Was there any writeup from the IETF NOC teams about the problem and how we fixed it? If so, it would be great to make that information available to the wider world. Please send responses to me, and I'll summarize them to the list. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
Paul, MARID was formed to merge Microsoft Caller-ID with SPF and so far has been successfully used by Microsoft to bully us to submit to their own proposal or else ... There are better ways to implement mail-from (i.e. as from Paul's draft which is basicly still the basis for MARID) which would not require reusing TXT records, nor is it totally clear that Mail-from is what we actually need to protect, it is being done under pretese of anti-spam measures but the reality shows that it will most likely have minimum effect as its far too easy for spammers to adapt to it anyway. There are however good reasons to have MARID as IETF WG anyway and hopefully the worst ideas implementation details can be stopped and new ideas discussed in the future if the group is extended. Yahoo is different proposal which has nothing to do with MARID and is being discussed at the ASRG. It is basicly a header containing a signature added to mail message that signs the content (including headers) with public key encryption and with public key available in DNS to verify the signature at the other end. The idea is not new and its a good idea, but yahoo's implementation is just bad and I think it breaks far too many things (it breaks with almost all maillists) and offers security that is too weak because its based on 348-bit key size. It should have been done different by reusing most likely PGP implementation but with message signed by MTAs and public key available through dns and if necessary being split into multiple dns records to have each at 512k. On Thu, 27 May 2004, Paul Vixie wrote: ... HREF=http://sa.vix.com/~vixie/mailfrom.txt;MAIL-FROM/A. I do not see a draft in the ietf process anyplace . Was this ever submitted ? I do notice that several of the other proposal's make mention of this work , But in none of them do they mention it as a draft or other ietf work . there was no working group where it was appropriate at the time it was written. i've sent it to every one of the dozen people who have asked me to review some similar, and usually ill considered thing. i've also sent it to several spam-related and dns-related mailing lists, including this one (ietf@). Any plans to submit it as a draft . Tia , JimL MARID is basically a layer 9 exercise, uninterested in engineering as such. it was formed to merge two ill considered ideas, one from yahoo and one from microsoft, in a way that would cause either no loss of face, or equal loss of face, for those two parties. the people who submit their own ideas to it are wasting their time. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: spoofing email addresses
1. block port 25 to external IP addresses for all of your customers except those with what draft-klensin-ip-service-terms-01.txt calls Full Internet Connectivity. ... and receive a flood of complaints because 10% of your users are using a mail service provided by someone else than you. 2. Do not sell Full Internet Connectivity to anyone running Microsoft software exposed to the Internet. Regardless of whether Microsoft's software can be secured (it can), this is a big no-op as a PC behind a home firewall is still at risk from e-mail viruses and questionable web downloads. 3. The effects of #1 and #2 include forcing all mail from the usual suspects through your own mail systems so that you can do as the credit card companies do. Track SMTP envelope Mail_To values or other characteristics for each customer. When you see a change, contact the customer by voice to check. So the solution to Spam has to be a massive surrender of privacy! I am afraid that you are falling in the very trap that you often denounce, present you personal definitive solution to Spam... -- Christian Huitema ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
At 9:17 PM + 05/27/2004, Paul Vixie wrote: MARID is basically a layer 9 exercise, uninterested in engineering as such. it was formed to merge two ill considered ideas, one from yahoo and one from microsoft, in a way that would cause either no loss of face, or equal loss of face, for those two parties. the people who submit their own ideas to it are wasting their time. As the AD who sponsored this work, I have to disagree. The MARID work came out of the LMAP area of the Anti-Spam Research Group, and there were multiple proposals there. All of them are being treated as input into MARID, and that fact is called out in the charter. The recent interim meeting resulted in an agreement to work on a converged spec taking ideas from SPF and Caller-ID. There are two other proposals on the table which address other parts of the mail exchange, and there was a sense in the meeting that they were sufficiently orthogonal that they might progress independently. None of the work mentioned above relates to Yahoo's proposal. Anyone interested in the work is welcome to participate in MARID's mailing list; it has a very tight deadline and a very high volume mailing list, and those willing to put engineering effort into it are more than welcome. Speaking as a participant, I have to say that this is a hard set of problems, both to define well and to solve. The efforts to define it well do occasionally drift into layer 9, and limiting that is something everyone involved has to watch. But I do believe there are some tractable pieces here we can pull off of the problem and solve, and I believe the working group is committed to that task, no matter who proposes the solution. regards, Ted Hardie ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: spoofing email addresses
From: Christian Huitema [EMAIL PROTECTED] 1. block port 25 to external IP addresses for all of your customers except those with what draft-klensin-ip-service-terms-01.txt calls Full Internet Connectivity. ... and receive a flood of complaints because 10% of your users are using a mail service provided by someone else than you. That's a significant problem, but so what? Stopping spam is not without costs. The spam problem exists only because service providers sell other than Full Internet Connectivity and cannot charge enough for the other flavors to squash abuse. The reason spam is a problem is that ISPs are unwilling or unable to pay the costs necessary to zap spamming customers. If spam were a certain path to termination with prejudice, there would be no significant spam. If ISPs would immediately and permanently terminate all spamming customers and refuse to exchange STMP/TCP/IP with other ISPs that fail to terminate spammers, there would be no spam problem and no need for blocking port 25 and so forth. If Microsoft would have been willing to pay the costs to ship secure software for the last 10 years, than the spam distribution mechanism currently favored by the worst spammers would not exist. 2. Do not sell Full Internet Connectivity to anyone running Microsoft software exposed to the Internet. Regardless of whether Microsoft's software can be secured (it can), As we all know, that is true in Microsoft marketing liturature and plausible theories but false in practice. As I said, practically all desktop Windows XP and NT installations have users running browsers and MUAs as administrator. Contrary to the knowingly misleading statements from Microsoft appologists, that fact makes Windows a hopelessly insecure system. Then there are the versions of Windows not related to Windows NT that cannot be secured even in theory. this is a big no-op as a PC behind a home firewall is still at risk from e-mail viruses and questionable web downloads. A PC running Microsoft software behind a home firewall for most meanings of that phrase including Microsoft's is not protected. It must not be exposed to the Internet. 3. The effects of #1 and #2 include forcing all mail from the usual suspects through your own mail systems so that you can do as the credit card companies do. Track SMTP envelope Mail_To values or other characteristics for each customer. When you see a change, contact the customer by voice to check. So the solution to Spam has to be a massive surrender of privacy! This statement is disingenous. No existing privacy is lost. It is just as false and dishonest to claim that the credit card companies reduce someone's privacy with their anti-fraud mechanisms. Exactly the same mail information is already present in ISP SMTP server logs. Privacy is not lost by people acting on your private information. It is lost when your private information is collected. Changing how computers manipulate your no-longer-private information does not reduce your privacy. Disclosing the fact that you do not have privacy does not reduce your privacy. If you want privacy, you must use cash instead of a credit card. You must also buy full internet connectivity, run your own SMTP client, and use at least SMTP-TLS, and of course, that's only a start toward mail privacy. I am afraid that you are falling in the very trap that you often denounce, present you personal definitive solution to Spam... My modest proposal would stop spam, but is not unique. As I wrote in words you did not quote, the spam problem results from service providers such as UUNet, Comcast, and Yahoo and software vendors such as your employer refusing to pay their shares of the costs to stop network abuse. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: STD series of documents
* From [EMAIL PROTECTED] Fri May 28 05:58:39 2004 * To: [EMAIL PROTECTED] * Date: Thu, 27 May 2004 16:19:15 -0400 * From: Michael Richardson [EMAIL PROTECTED] * X-Mailman-Approved-At: Fri, 28 May 2004 08:19:57 -0400 * Subject: STD series of documents * X-BeenThere: [EMAIL PROTECTED] * X-Mailman-Version: 2.1.5 * List-Id: IETF-Discussion ietf.ietf.org * List-Unsubscribe: https://www1.ietf.org/mailman/listinfo/ietf, *mailto:[EMAIL PROTECTED] * List-Post: mailto:[EMAIL PROTECTED] * List-Help: mailto:[EMAIL PROTECTED] * List-Subscribe: https://www1.ietf.org/mailman/listinfo/ietf, *mailto:[EMAIL PROTECTED] * X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean * X-MailScanner-From: [EMAIL PROTECTED] * X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on boreas.isi.edu * X-Spam-Level: * X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 *autolearn=no version=2.63 * X-Status: * X-Keywords: * X-UID: 3100 * * -BEGIN PGP SIGNED MESSAGE- * Hash: SHA1 * * * May I suggest that a URL like: * * http://www.ietf.org/std/std0051.txt * * be made that can refer to the STD series of documents? Note that: ftp://ftp.rfc-editor.org/in-notes/std/std51.txt already works. Bob Braden for the RFC Editor ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
On 28-mei-04, at 15:06, John Stracke wrote: (I've yet to see a proposal that works if the spammers start utilizing zombie machines that snarf the already-stored credentials of the user to send mail) The question is whether spammers can obtain new credentials (stolen or otherwise) faster than others can blacklist them. And, if you had actually read the message you replied to, you would have realized that the answer is yes. I don't see why. Send out a worm that makes N zombies, have each zombie send one message under the local user's credentials, and none of them will get blacklisted. That makes the number of spam messages received by an email user (on average) equal to the number of email users divided by the number of systems vulnerable to becoming a zombie. So one spam a day/week/month or so = a lot better than the current situation. Don't assume that the high level of vulnerability we're seeing today will remain the same in the future. (It will remain 0 though.) There was a time when desktop systems would completely crash regularly because badly written software would take down the whole system. Software quality isn't beter these days, but desktop operating systems are now able to protect the system against most software errors. I'm sure we'll see similar developments in the area of security. Zone Alarm (network access restricted on a per-application basis) and the MacOS keychain system (access to passwords and certificates restricted on a per-application basis) are the way of the future. -- Every computer sold in the US is safe by default. It is powered off, disconnected, in a factory sealed box - Sean Donelan, on NANOG ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
telecom recovery unlikely as long as best effort is industry's only business model
Since mid March I have been leading a private mail list and came out with a conclusion last weekend that there can be no telecom recovery as long as the industry relies solely on the best effort business model which I believe is not economically sustainable. This has led to two articles on my June-July issue conclusions this week in the trade press. Something that has never happened to me before. :-) The first is ISP Planet and the second Broadband Edge. Here are the urls http://www.isp-planet.com/perspectives/2004/cook_internet.html (monday) http://bbedge.mblast.com/presentation/page798-878156.asp (today) Finally my summary, table of contents and list of contributors is at http://cookreport.com/13.04.shtml Enjoy the weekend. -- = The COOK Report on Internet Protocol, 431 Greenway Ave, Ewing, NJ 08618 USA 609 882-2572 (PSTN) 703 738-6031 (Vonage) Subscription info prices at http://cookreport.com/subscriptions.shtml Report on economic black hole of best effort networks at: http://cookreport.com/13.04.shtml E-mail [EMAIL PROTECTED] = ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RFC 3757 on Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag
A new Request for Comments is now available in online RFC libraries. RFC 3757 Title: Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag Author(s): O. Kolkman, J. Schlyter, E. Lewis Status: Standards Track Date: May 2004 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 8 Characters: 16868 Updates:3755, 2535 I-D Tag:draft-ietf-dnsext-keyrr-key-signing-flag-12.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3757.txt With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set. A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3755. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3757.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 3786 on Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit
A new Request for Comments is now available in online RFC libraries. RFC 3786 Title: Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit Author(s): A. Hermelin, S. Previdi, M. Shand Status: Montilio Inc., Cisco Systems, Cisco Systems Date: May 2004 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 14 Characters: 29164 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-isis-ext-lsp-frags-02.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3786.txt This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. This document is a product of the IS-IS for IP Internets Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3786.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
