From ogud@ogud.com Wed Dec 1 11:38:50 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6BD33A6C9A for ; Wed, 1 Dec 2010 11:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaSVjF2gH+EG for ; Wed, 1 Dec 2010 11:38:47 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 44DBA3A6CF0 for ; Wed, 1 Dec 2010 11:38:47 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oB1Je0vG019965 for ; Wed, 1 Dec 2010 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 1 Dec 2010 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20101201_194000_071164.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-hoffman-server-has-tls-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 19:38:51 -0000 Count: 13 Network Working Group P. Hoffman Internet-Draft VPN Consortium Intended status: Standards Track November 30, 2010 Expires: June 3, 2011 Specifying That a Server Supports TLS draft-hoffman-server-has-tls-00 Abstract A server that hosts applications that can be run with or without TLS may want to communicate with clients whether the server is hosting an application only using TLS or also hosting the application without TLS. Doing so tells clients that try using TLS but fail to set up a TLS session whether or not they should even try to set up an insecure session with the server. This document describes the use cases for this type of communication and a secure method for communicating that information. From ajs@shinkuro.com Thu Dec 2 04:40:43 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD2628C0F8 for ; Thu, 2 Dec 2010 04:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.641 X-Spam-Level: X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OijdsIc5FSs4 for ; Thu, 2 Dec 2010 04:40:37 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7CADB28C101 for ; Thu, 2 Dec 2010 04:40:32 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8E3C01ECB41D for ; Thu, 2 Dec 2010 12:41:38 +0000 (UTC) Date: Thu, 2 Dec 2010 07:41:36 -0500 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20101202124136.GE2525@shinkuro.com> References: <201009131301.o8DD1VT8024641@cichlid.raleigh.ibm.com> <20100913130817.6B6D522808@thrintun.hactrn.net> <4C8E320F.3030109@ogud.com> <20100917235317.DA40F22808@thrintun.hactrn.net> <4C9765C3.7000204@ogud.com> <56923363-9619-418D-B60D-C75C9CEFADE4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56923363-9619-418D-B60D-C75C9CEFADE4@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dns-dir] multicastdns (Re: "Bonjour" protocol doc suite) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 12:40:43 -0000 On Thu, Nov 18, 2010 at 12:03:55PM +0000, Ralph Droms wrote: > All three docs are in IETF last call and will are on the agenda of Dec 2 IESG telechat. I'd like to get DNS Directorate reviews of the current rev of the docs prior to the telechat. Has anyone begun any of the reviews? Volunteers? > I didn't see any other reviews, so I reviewed _very quickly_ draft-cheshire-dnsext-multicastdns-12. As I guess I've said before, I think this needs to be published, even if it isn't perfect. That said, I think it is in much better shape than many documents. I think it has the right mix of explanatory text and specification. I think the protocol is completely specified here. (I spent some time working through some issues over the past year with Bonjour using previous versions of this draft, and I was never able to find things that weren't covered in it. Would that I could say the same thing for the DNS specifications!) There remains in this document the awkward fact that it is directing IANA to reserve part of the namespace. The argument in Appendix G is a little bizarre, given that the document officially says that it is _not_ DNS but rather a DNS-like protocol on port 5353. That said, the same argument cites RFC 2860, and I think the argument is on stronger ground there. The rule in Appendix F that you're not allowed to put ACE-compatible encodings in mDNS is obviously wrong on its face, because ASCII is just a subset of UTF-8 and therefore any ACE-compatible encoded label (what the IDNA2008 documents call an A-label) is automatically a valid mDNS label, though one that will be hard to use. The "just use UTF-8" approach in this document for internationalization is probably not quite as effective as the authors think it should be, but I think it is probably good enough for the purposes. I think the document does address in passing most of the effective issues with this strategy (and says everything that can be said without the document turning into a discussion of languages, strings, scripts, and user interface design). Since mDNS is intended really for LAN use anyway, the bizarre situations that can arise with such considerations on the global Internet are unlikely to arise in this context. I think the document is forthright that there is a potential security nightmare in cases where mDNS is in use and there is intermittent service from the global DNS. The basic story it has for that is that it amounts to a user interface problem. This is a deeply unsatisfying response, even though it appears to be true in practice. There just is no way to have a locally-scoped and globally-scoped namespace available simultaneously to users, and to make it perfectly impossible for an attacker to fake out users. Given that we can't even achieve such security in the globally-scoped namespace anyway, I am not sure that such a goal is reasonable. This protocol (or variations of it) are widely deployed. I take seriously Doug Barton's point that the IETF isn't here to stamp "standard" on vendors' specifications, and it isn't clear that different interoperating implementations can be generated from this specification (since we have in the field different implementations that seem to differ in their behaviour). But the way we used to address that was to publish the document as PS so that everyone had something stable to implement against. I have no idea whether Avahi and the various Bonjours are all implemented agains the same draft, and so we have an interoperability problem anyway. So I think this document should be published, and on the standards track. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Thu Dec 2 05:16:43 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4D128C10B for ; Thu, 2 Dec 2010 05:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.641 X-Spam-Level: X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfiMFzVOpuV7 for ; Thu, 2 Dec 2010 05:16:42 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7D0BF28C100 for ; Thu, 2 Dec 2010 05:16:42 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5218F1ECB41D for ; Thu, 2 Dec 2010 13:17:57 +0000 (UTC) Date: Thu, 2 Dec 2010 08:17:55 -0500 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20101202131755.GG2525@shinkuro.com> References: <201009131301.o8DD1VT8024641@cichlid.raleigh.ibm.com> <20100913130817.6B6D522808@thrintun.hactrn.net> <4C8E320F.3030109@ogud.com> <20100917235317.DA40F22808@thrintun.hactrn.net> <4C9765C3.7000204@ogud.com> <56923363-9619-418D-B60D-C75C9CEFADE4@gmail.com> <20101202124136.GE2525@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202124136.GE2525@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [dns-dir] dns-sd (Re: "Bonjour" protocol doc suite) X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 13:16:43 -0000 Hi, Just as with the multicast DNS draft, I reviewed draft-cheshire-dnsext-dns-sd-07 very quickly. Sorry these are coming so late. I should note that as part of my day job, I've actually been working with the dns-sd stuff for over a year. As far as I can tell, it works. There are some actual interoperability problems between Apple's Bonjour and Avahi; this is to me an argument that we need an RFC out soon so that people have something stable against which to implement. The name of this approach is a little unfortunate, because it makes it seem that it is intending to allow users to "discover their DNS". That's not, of course, what it is doing: it presents a mechanism via the DNS for users to discover other services. The discussion about structured service names in section 4.1 is rather combative in tone, although having followed the history of this I can't say that's surprising. The plan to "fall back" to "Punycode" is a bit of a disaster, in that the description talks about "converting labels to Punycode". It's worth quoting the entire passage: The portion of the Service Instance Name specifies the DNS subdomain within which the service names are registered. It may be "local.", meaning "link-local Multicast DNS" [mDNS], or it may be a conventional unicast DNS domain name, such as "ietf.org.", "cs.stanford.edu.", or "eng.us.ibm.com." Because service names are not host names, they are not constrained by the usual rules for host names [RFC 1033][RFC 1034][RFC 1035], and rich-text service subdomains are allowed and encouraged, for example: Building 2, 1st Floor . example . com . Building 2, 2nd Floor . example . com . Building 2, 3rd Floor . example . com . Building 2, 4th Floor . example . com . In addition, because Service Instance Names are not constrained by the limitations of host names, this document recommends that they be stored in the DNS, and communicated over the wire, encoded as straightforward canonical precomposed UTF-8, Unicode Normalization Form C [UAX15]. In cases where the DNS server returns a negative response for the name in question, client software MAY choose to retry the query using "Punycode" [RFC 3492] encoding, beginning with using Punycode encoding for the top level label, and then issuing the query repeatedly, with successively more labels converted to Punycode each time, and giving up if it has converted all labels to Punycode and the query still fails. Now, the "fallback to Punycode" approach will work fine for the portion of the identifier that is just the local part. But claiming that you can start at the top level and "convert the label to Punycode" is an underspecification, since under IDNA2008 you're supposed to check putative A-labels to see whether they are such (though there cannot, of course, be a general-purpose rule that you're not allowed to look up a putative A-label without checking it, since your lookup might be IDNA-unaware). The recommendation to use UTF-8 labels for the whole name is not consistent with IDNA2008 recommendations, although it will probably interoperate. I would like to suggest a single sentence advising users of this specification to be aware of the constraints on domain names entailed by IDNA2008. I do _not_ think this should block publication of the document, but I expect that there will be evidence that emerges soon about how this works in practice (because of increasing IDNA deployment), and perhaps as the document advances on the standards track this part can be cleaned up in light of experience. It is the rejection of the LDH rule that reveals the basic bias in the document towards the LAN. Nevertheless, mature DNS implementations ought no longer to require the LDH rule for all labels (if ever they did). While it would have been nice if they'd used an RRTYPE other than TXT for part of this, the fact is that they used it, and it's widely deployed. It's too late to undo this. If it were my protocol, I'd have done a more complete job on subtyping (this has caused me some pain over the past year). But within the limits prescribed here, the subtyping seems to work, and the document is quite clear that it isn't pretending to offer more. Again, also, the protocol is widely deployed, so attempting to change this is unlikely to yield the results we want. I think the document should be published, even though I'm a little uncomfortable with the implications of the discussion in 4.1. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ogud@ogud.com Thu Dec 2 11:38:56 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DBF83A69DB for ; Thu, 2 Dec 2010 11:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 083ktQsfG5BL for ; Thu, 2 Dec 2010 11:38:50 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id BEEDC3A69D5 for ; Thu, 2 Dec 2010 11:38:49 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oB2Je0bk030101 for ; Thu, 2 Dec 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Thu, 2 Dec 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20101202_194001_077051.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-jenkins-cdni-problem-statement-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 19:38:56 -0000 Count: 54 Network Working Group B. Niven-Jenkins Internet-Draft Velocix (Alcatel-Lucent) Intended status: Informational F. Le Faucheur Expires: June 5, 2011 Cisco N. Bitar Verizon December 2, 2010 Content Distribution Network Interconnection (CDNI) Problem Statement draft-jenkins-cdni-problem-statement-00 Abstract Content Delivery Networks (CDNs) provide numerous benefits: reduced delivery cost for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result, existing CDN providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an end user regardless of that user's location or attachment network. This creates a requirement for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. However, no standards or open specifications currently exist to facilitate such CDN interconnection. The goal of this document is to outline the problem area for the IETF with a view towards creating a working group. This working group would work on interoperable and scalable solutions for CDN interconnection. From ogud@ogud.com Fri Dec 3 11:38:44 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2BFB3A6993 for ; Fri, 3 Dec 2010 11:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2D-tcu+L00U for ; Fri, 3 Dec 2010 11:38:44 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id BB76E3A6995 for ; Fri, 3 Dec 2010 11:38:43 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oB3Je1Qn038810 for ; Fri, 3 Dec 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Fri, 3 Dec 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20101203_194001_041153.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 19:38:44 -0000 Count: 243 IPv6 Operations J. Livingood Internet-Draft Comcast Intended status: Informational December 3, 2010 Expires: June 6, 2011 IPv6 AAAA DNS Whitelisting Implications draft-ietf-v6ops-v6-aaaa-whitelisting-implications-00 Abstract The objective of this document is to describe what whitelisting of DNS AAAA resource records is, or DNS whitelisting for short, as well as what the implications of this emerging practice are and what alternatives may exist. The audience for this document is the Internet community generally, including the IETF and IPv6 implementers. From ogud@ogud.com Mon Dec 6 11:38:41 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3740A3A68CB for ; Mon, 6 Dec 2010 11:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STQ3+sNwUbcW for ; Mon, 6 Dec 2010 11:38:38 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 2EDC33A68C2 for ; Mon, 6 Dec 2010 11:38:38 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oB6Je1Pn063402 for ; Mon, 6 Dec 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Mon, 6 Dec 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20101206_194001_024009.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-v6ops-multihoming-without-nat66-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 19:38:41 -0000 Count: 59 Internet Engineering Task Force O. Troan, Ed. Internet-Draft Cisco Intended status: Informational D. Miles Expires: June 9, 2011 Alcatel-Lucent S. Matsushima SOFTBANK TELECOM Corp. T. Okimoto NTT D. Wing Cisco December 6, 2010 IPv6 Multihoming without Network Address Translation draft-v6ops-multihoming-without-nat66-00 Abstract Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of IPv6 NAT. However, NAT should be avoided, if at all possible, to permit transparent host-to- host connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria . From ogud@ogud.com Mon Dec 6 11:38:41 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781603A68C2 for ; Mon, 6 Dec 2010 11:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfj6Ez+DR9rA for ; Mon, 6 Dec 2010 11:38:38 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 2ED9D3A68B3 for ; Mon, 6 Dec 2010 11:38:38 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oB6Je14S063380 for ; Mon, 6 Dec 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Mon, 6 Dec 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20101206_194001_092924.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-hoffman-dns-last-hop-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 19:38:41 -0000 Count: 87 Network Working Group P. Hoffman Internet-Draft VPN Consortium Intended status: Standards Track December 5, 2010 Expires: June 8, 2011 Wrapping DNS for Traffic Protection draft-hoffman-dns-last-hop-00 Abstract DNS queries from one resolver to an upstream resolver are often run over connections with no protection of any kind. This connection, is currently susceptible to both malicious and unintentional alteration that prevents the querying resolver from being sure that the results it receives are valid. Some middleboxes can prevent a querying resolver that does DNSSEC validation from getting enough information to validate a response. Further, a non-validating, non-iterative resolver querying a trusted recursive resolver is susceptible to active attacks in which the results are purposely altered. The protocols described in this document provide two methods to avoid these problems and thus make resolution significantly more secure. These protocols can be used between any two DNS resolvers, but they are particularly useful for queries from "last-hop" stub resolvers to trusted recursive resolvers. From ogud@ogud.com Wed Dec 8 11:38:35 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DEEF3A6823 for ; Wed, 8 Dec 2010 11:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjF8+WD4QPXf for ; Wed, 8 Dec 2010 11:38:33 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 370C73A6869 for ; Wed, 8 Dec 2010 11:38:33 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oB8Je0Yp083573 for ; Wed, 8 Dec 2010 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 8 Dec 2010 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20101208_194000_055069.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-mccann-picklepacket-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 19:38:35 -0000 Count: 66 Motorola P. McCann Internet-Draft Intended status: Standards Track S. Gilbert Expires: June 10, 2011 Motorola, Inc. December 7, 2010 Authenticated Middlebox Traversal with the Pickle Packet draft-mccann-picklepacket-00 Abstract This document describes the Pickle Packet, a message that can be used to coordinate the opening of a transport connection with various middleboxes that may lie on the path. It contains the DNS names of both the initiator and the responder of the connection and some authentication data. Because the authentication data uses public key cryptography, any middlebox can independently authenticate the initiator and make a policy decision whether to allow or deny the flow based on the DNS names. The Pickle Packet allows for middleboxes to establish state such as firewall pinholes or security associations that can be used to filter out unwanted traffic. From dromasca@avaya.com Fri Dec 10 03:37:38 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C073A6944; Fri, 10 Dec 2010 03:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.234 X-Spam-Level: X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zT9oQASL-HX; Fri, 10 Dec 2010 03:37:34 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 01EF63A6990; Fri, 10 Dec 2010 03:37:31 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKufAU3GmAcF/2dsb2JhbACkAXimEAKZC4VKBI4n X-IronPort-AV: E=Sophos;i="4.59,323,1288584000"; d="scan'208";a="49413207" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 10 Dec 2010 06:38:59 -0500 X-IronPort-AV: E=Sophos;i="4.59,323,1288584000"; d="scan'208";a="553401070" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Dec 2010 06:38:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Dec 2010 12:38:43 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the December 16, 2010 IESG Teleconference Thread-Index: AcuX9fxAUiWyWIoGTNq8RFJqXbeitwAZ0Yxg From: "Romascanu, Dan (Dan)" To: "IETF DNS Directorate" , , , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the December 16, 2010 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 11:37:39 -0000 =20 Please find below the preliminary agenda of the 12/16 IESG telechat. Please send me your comments, questions and concerns before 12/15 COB. Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2.1.1 New Items o draft-ietf-mpls-fastreroute-mib-15 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute (Proposed Standard) Note: Loa Andersson (loa@pi.nu) is the document shepherd. Token: Adrian Farrel o draft-ietf-httpstate-cookie-19 HTTP State Management Mechanism (Proposed Standard) Token: Peter Saint-Andre o draft-ietf-sipcore-event-rate-control-05 Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control (Proposed Standard) Note: Adam Roach (adam@nostrum.com) is the document shepherd. Token: Robert Sparks Was deferred by Cindy Morgan on 2010-12-02 o draft-ietf-morg-list-specialuse-05 IMAP LIST extension for special-use mailboxes (Proposed Standard) Note: Timo Sirainen is the document shepherd. Token: Alexey Melnikov o draft-ietf-roll-trickle-06 The Trickle Algorithm (Proposed Standard) Note: JP Vasseur (jpv@cisco.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-tls-ssl2-must-not-03 Prohibiting SSL Version 2.0 (Proposed Standard) Note: Joe Salowey (jsalowey@cisco.com) is the document shepherd. Token: Alexey Melnikov o draft-ietf-avt-rtp-svc-24 RTP Payload Format for Scalable Video Coding (Proposed Standard) Note: Roni Even is the document shepherd (Even.roni@huawei.com) Token: Gonzalo Camarillo o draft-ietf-xmpp-address-07 Extensible Messaging and Presence Protocol (XMPP): Address Format (Proposed Standard) Note: Ben Campbell (ben@nostrum.com) is the document shepherd. Token: Gonzalo Camarillo Was deferred by Cindy Morgan on 2010-12-02 o draft-ietf-sieve-notify-presence-03 Sieve Notification Using Presence Information (Proposed Standard) Note: Cyrus Daboo is the document shepherd. Token: Alexey Melnikov Was deferred by Robert Sparks on 2010-12-01 o draft-ietf-mpls-ip-options-05 Requirements for Label Edge Router Forwarding of IPv4 Option Packets (Proposed Standard) Note: George Swallow (swallow@cisco.com) is the Document Shepherd. Token: Adrian Farrel o draft-ietf-v6ops-3177bis-end-sites-00 IPv6 Address Assignment to End Sites (BCP) Note: Fred Baker (fred@cisco.com) is the document shepherd. Token: Ron Bonica o draft-ietf-morg-fuzzy-search-03 IMAP4 Extension for Fuzzy Search (Proposed Standard) Note: Barry Leiba (one of the MORG chairs) is the document shepherd. Token: Alexey Melnikov o draft-ietf-tcpm-tcp-timestamps-02 Reducing the TIME-WAIT state using TCP timestamps (BCP) Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Token: Lars Eggert 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items o draft-cheshire-dnsext-dns-sd-07 DNS-Based Service Discovery (Proposed Standard) Token: Ralph Droms o draft-cheshire-dnsext-multicastdns-12 Multicast DNS (Proposed Standard) Token: Ralph Droms 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-ipfix-mediators-framework-09 IPFIX Mediation: Framework (Informational) Note: Juergen Quittek is the document shepherd Token: Dan Romascanu o draft-ietf-opsec-protect-control-plane-04 Protecting The Router Control Plane (Informational) Token: Ron Bonica o draft-ietf-ipfix-anon-05 IP Flow Anonymisation Support (Experimental) Note: Nevil Brownlee is the Document Shepherd Token: Dan Romascanu o draft-ietf-v6ops-incremental-cgn-02 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition (Informational) Note: Joel Jaeggli (joelja@bogus.com), v6ops co-chair is the document shepherd. Token: Ron Bonica o draft-ietf-bmwg-reset-03 Device Reset Characterization (Informational) Note: Al Morton (acmorton@att.com) is the document shepherd. Token: Ron Bonica 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-linowski-netmod-yang-abstract-04 Extending YANG with Language Abstractions (Experimental) Note: Mehmet Ersue is the document shepherd. Token: Dan Romascanu o draft-arkko-ipv6-transition-guidelines-09 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment (Informational) Note: Kurt Erik Lindqvist (kurtis@kurtis.pp.se) is the document shepherd. Token: Ron Bonica 3.2.2 Returning Items o draft-cheshire-dnsext-nbp-09 Requirements for a Protocol to Replace AppleTalk NBP (Informational) Token: Ralph Droms 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o draft-saito-mmusic-sdp-ike-08 Media Description for IKE in the Session Description Protocol (SDP) (Informational) Note: See the Ballot Writeup for the working 5742 response Token: Robert Sparks o draft-templin-iron-13 The Internet Routing Overlay Network (IRON) (Experimental) Note: Tony Li (tony.li@tony.li) is the document shepherd. Token: Jari Arkko 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Audio/Video Transport Payloads (payload) Token: Robert Sparks o Metric Blocks for use with RTCP's Extended Report Framework (xrblock) Token: Robert Sparks o Audio/Video Transport Core Maintenence (avtcore) Token: Robert Sparks o Audio/Video Transport Extensions (avtext) Token: Robert Sparks o ControLling mUltiple streams for TElepresence (clue) Token: Gonzalo Camarillo 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Transparent Interconnection of Lots of Links (trill) Token: Ralph Droms o Ad-Hoc Network Autoconfiguration (autoconf) Token: Jari Arkko From ogud@ogud.com Sat Dec 11 11:38:30 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5A73A6B9F for ; Sat, 11 Dec 2010 11:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ebh3Tt78E5J for ; Sat, 11 Dec 2010 11:38:29 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id F1BF83A6B9B for ; Sat, 11 Dec 2010 11:38:28 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oBBJe14f011261 for ; Sat, 11 Dec 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Sat, 11 Dec 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20101211_194001_081808.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-xmpp-address-08.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 19:38:30 -0000 Count: 11 XMPP P. Saint-Andre Internet-Draft Cisco Updates: 3920 (if approved) December 10, 2010 Intended status: Standards Track Expires: June 13, 2011 Extensible Messaging and Presence Protocol (XMPP): Address Format draft-ietf-xmpp-address-08 Abstract This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non- ASCII characters. This document updates RFC 3920. From ogud@ogud.com Tue Dec 14 11:38:25 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EB0928C0F0 for ; Tue, 14 Dec 2010 11:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWDCeTMheQNH for ; Tue, 14 Dec 2010 11:38:24 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 2E87D28C0EF for ; Tue, 14 Dec 2010 11:38:21 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oBEJe17i075630 for ; Tue, 14 Dec 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Tue, 14 Dec 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20101214_194001_065882.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-dane-protocol-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 19:38:25 -0000 Count: 48 Network Working Group P. Hoffman Internet-Draft VPN Consortium Intended status: Standards Track J. Schlyter Expires: June 16, 2011 Kirei AB December 13, 2010 Using Secure DNS to Associate Certificates with Domain Names For TLS draft-ietf-dane-protocol-00 Abstract TLS and DTLS use certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. Instead of trusting a certification authority to have made this association correctly, the user might instead trust the authoritative DNS server for the domain name to make that association. This document describes how to use secure DNS to associate the TLS server's certificate with the the intended domain name. From ogud@ogud.com Wed Dec 15 11:38:19 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6726928C0E0 for ; Wed, 15 Dec 2010 11:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slo50D5HX5yf for ; Wed, 15 Dec 2010 11:38:18 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6332928B797 for ; Wed, 15 Dec 2010 11:38:18 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oBFJe0AY095766 for ; Wed, 15 Dec 2010 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 15 Dec 2010 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20101215_194000_098759.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-cheshire-dnsext-special-names-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 19:38:19 -0000 Count: 18 Internet Engineering Task Force S. Cheshire Internet-Draft M. Krochmal Intended status: Standards Track Apple Inc. Expires: June 15, 2011 Dec 12, 2010 Special-Use Domain Names draft-cheshire-dnsext-special-names-00 Abstract This document describes what it means to say that a DNS name is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. From ogud@ogud.com Wed Dec 22 11:38:04 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E853A6A06 for ; Wed, 22 Dec 2010 11:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4A4JaTerTfa for ; Wed, 22 Dec 2010 11:38:02 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 8410B3A6A55 for ; Wed, 22 Dec 2010 11:38:02 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oBMJe0Kw058247 for ; Wed, 22 Dec 2010 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 22 Dec 2010 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20101222_194000_079850.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-levine-iprangepub-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 19:38:04 -0000 Count: 64 Internet Research Task Force J. Levine Internet-Draft Taughannock Networks Intended status: Experimental December 21, 2010 Expires: June 24, 2011 An efficient method to publish ranges of IP addresses in the DNS draft-levine-iprangepub-00 Abstract The DNS has long been used to publish lists of IPv4 address ranges in blacklists and whitelists. The size of the IPv6 address space makes the entry-per-IP approach used for IPv4 lists impractical. A new technique for publishing IPv6 address ranges is described. It is intended to permit efficient publishing and querying, and to have good DNS cache behavior. From ogud@ogud.com Fri Dec 31 11:37:58 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B993A6821 for ; Fri, 31 Dec 2010 11:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt1pjTWTN2n0 for ; Fri, 31 Dec 2010 11:37:57 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id AEB5E3A67F1 for ; Fri, 31 Dec 2010 11:37:54 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id oBVJe0bc026317 for ; Fri, 31 Dec 2010 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Fri, 31 Dec 2010 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20101231_194000_002780.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-xwwang-ipv6tesf-00.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 19:37:58 -0000 Count: 12 Network Working Group XingWei. Wang Internet-Draft ZhanKao. Wen Intended status: Standards Track Jun. Liu Expires: May 8, 2011 WeiDong. Wang PengCheng. Liu NEU November 4, 2010 TESF Based on True IPv6 Address Access draft-xwwang-ipv6tesf-00.txt Abstract The current Email infrastructure has the property that any host sending mail to the mail system can identify itself as any user name it wants. Furthermore, the current Email framework neither authenticates the sender nor traces the source of the mail, so even find a spam, the method is just to reject the mail or insert the mail source into "blacklist", and both of these methods can!_t deracinate the generation of spam. This document design a Email source address authentication based on true IPv6 address access to identify and authenticate the mail source address, to trace the mail sender effectively, and to deracinate the generation of spam.