Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 08:18:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07723 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 08:18:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao0HV-000B6C-Hy for namedroppers-data@psg.com; Tue, 03 Feb 2004 13:07:57 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao0Gy-000B4M-08 for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 13:07:24 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 084FF1E88C5 for <namedroppers@ops.ietf.org>; Tue, 3 Feb 2004 14:07:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Olaf Kolkman <olaf@ripe.net> Subject: Q-28 Clarification of the scope of the document set. Date: Tue, 3 Feb 2004 14:07:21 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q-28 Clarification of the scope of the document set. This is not a protocol issue, but also more than an editorial nit, hence a question to the WG. It is about language to be added to several parts of the document set; During recent discussions it has became clear that some of the architectural considerations where too implicit. This is a first go at a draft of text that is to be added to the intro document. It needs some work on the details. It has been sitting on my disk for a bit but I have not been able to concentrate on it for the last few days (the reason is on www.geerthe,org :-) ). Note that I think that definitions of new RCODEs or EDNS0 extensions or other solutions to 'solve' the last mile communications is out of scope. --Olaf <proposed intro text> In the DNSSEC architecture the security aware resolver determines if DNS deta is in one of three states "unsecure", "validated" or "bogus". The specification in these document set is designed to make sure these 3 states can unambiguously be determined from the answers that are returned from security aware servers. Validated: Data is "validated" if one of possibly multiple authentication chains from a trust anchor to the data itself can be established. Multiple authentication chains can exist when there are multiple DS RRs at a delegation point or when data is covered by multiple RRSIGs. A security aware resolver may not have all possible authorization chains at its disposal, either because an authorization chain is based on an algorithm that has not been implemented or because there is no trust anchor for a possible authenticatio chain available. Unsecure: If no authentication chain can be established; either because there is no appropriate trust anchor or the authentication chain was broken because of the authenticated absence of DS RRs that point to keys of algorithms the resolver is able to use. If there are no trust anchors configured than all data is marked insecure. Bogus: Data that is neither validated nor unsecure: Somewhere in the authentication chain there was an RRset for which all of the RRSIG RRs did not cryptographicly verify or were intended for a different time interval. Alternatively not all needed links in the authorization chain are available e.g. because network failures. Once security aware resolvers have determined if data is 'secure', 'insecure' or 'bogus' their work is done. This specification does not define a format for communicating why data was found to be bogus or insecure. For the communication between a security aware recursive servers and security aware stub resolvers this specification defines a default policy for communicating the 3 states. The detailed specification of a method for signaling advanced error codes and or policy between a security aware stub resolver and security aware recursive nameservers is subject to future work. </proposed intro text> In addition to this text there is language to be added to the protocol document that defines the behavior for security aware recursive nameservers. Roughly (because the CD bit behavior is ignored for now) like: If the security aware recursive nameserver validates data as "unsecure" it forwards data to the the security aware stub resolver without the ad bit set. If the security aware recursive nameserver validates data as "secure" it forwards data to the the security aware stub resolver with the ad bit set. If the security aware recursive nameserver validates data as "bogus" it returns an answer with RCODE=SERVFAIL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 12:57:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21512 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 12:57:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao4eD-000Lg7-Ov for namedroppers-data@psg.com; Tue, 03 Feb 2004 17:47:41 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao4e0-000LeG-E0 for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 17:47:28 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i13HkxjO028293 for <namedroppers@ops.ietf.org>; Tue, 3 Feb 2004 12:47:00 -0500 (EST) Message-ID: <013b01c3ea7d$ba8a8e40$b9370681@barnacle> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: Q-29: Resolver Handling of expired RRSIGs Date: Tue, 3 Feb 2004 12:47:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q-29 Resolver handling of expired RRSIGs From an earlier thread and individual comments: What, if any, should be the default resolver behavior when expired RRSIGs are contained in a response? For example, The one or more RRSIGs covering a RRset in the answer section has an expiration date in the past. Currently, the text in the Records and Protocol document state that they MUST be rejected (they are to be considered "bogus", using the newly defined terminology). Some have suggested that is too harsh, and the default should be something similar to the following: "SHOULD be rejected, but MAY use RRSIGs if other security checks were successful, depending on local policy". That way, a resolver may be able to pass on success, and the data could be marked "unsecure" and passed back to a security aware stub resolver, or passed up to the application. However, if the application or stub resolvers are not security aware, this could lead to a vulnerability. Is there consensus to relax the "MUST reject expired RRSIGs" and make it less restrictive? Please suggest text if the above is not sufficient. This formal question is mainly for closure on a discussion thread that has died down. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 13:22:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22959 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 13:22:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao56l-000Prx-5k for namedroppers-data@psg.com; Tue, 03 Feb 2004 18:17:11 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao56T-000Pq8-8M for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 18:16:53 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i13IGpK12499; Tue, 3 Feb 2004 10:16:51 -0800 From: bill <bmanning@karoshi.com> Message-Id: <200402031816.i13IGpK12499@karoshi.com> Subject: Re: Q-29: Resolver Handling of expired RRSIGs To: scottr@nist.gov (Scott Rose) Date: Tue, 3 Feb 2004 10:16:51 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <013b01c3ea7d$ba8a8e40$b9370681@barnacle> from "Scott Rose" at Feb 03, 2004 12:47:01 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Q-29 Resolver handling of expired RRSIGs > > >From an earlier thread and individual comments: > > suggested that is too harsh, and the default should be something > similar to the following: > > "SHOULD be rejected, but MAY use RRSIGs if other security > checks were successful, depending on local policy". better language, imho. > Is there consensus to relax the "MUST reject expired RRSIGs" and > make it less restrictive? Please suggest text if the above is > not sufficient. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 13:37:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23567 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 13:37:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao5Lc-0001qw-GM for namedroppers-data@psg.com; Tue, 03 Feb 2004 18:32:32 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao5LP-0001oM-1c for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 18:32:19 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i13IWGG12658; Tue, 3 Feb 2004 10:32:16 -0800 From: bill <bmanning@karoshi.com> Message-Id: <200402031832.i13IWGG12658@karoshi.com> Subject: Re: Q-28 Clarification of the scope of the document set. To: olaf@ripe.net (Olaf Kolkman) Date: Tue, 3 Feb 2004 10:32:16 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> from "Olaf Kolkman" at Feb 03, 2004 02:07:21 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit changes sprinkled throughout, mainly changing "bogus" to "indeterminant", > In the DNSSEC architecture the security aware resolver determines if > DNS deta is in one of three states "unsecure", "validated" or > "bogus". The specification in these document set is designed to make > sure these 3 states can unambiguously be determined from the answers > that are returned from security aware servers. I'm unconvinced that the resolver makes this choice. a design we are working on/with has the validator as an independent module that the resolver talks to and it is the validator that determines the "state of the data" and tells the resolver. So, alternate text: In the DNSSEC architecture a security enabled resolver receives data in one of three states, "unsecure", "validated", or "indeterminant". The specification in this document set is designed to make sure these three states can unambigiously be determined from answers received from security aware and enabled servers or caches. > Validated: Data is "validated" if one of possibly multiple > authentication chains from a trust anchor to the data itself > can be established. Multiple authentication chains can exist > when there are multiple DS RRs at a delegation point or when > data is covered by multiple RRSIGs. A security aware resolver > may not have all possible authorization chains at its > disposal, either because an authorization chain is based on an > algorithm that has not been implemented or because there is no > trust anchor for a possible authenticatio chain available. > > > Unsecure: If no authentication chain can be established; either > because there is no appropriate trust anchor or the > authentication chain was broken because of the authenticated > absence of DS RRs that point to keys of algorithms the > resolver is able to use. > > If there are no trust anchors configured than all data is > marked insecure. > > Indeterminant: Data that is neither validated nor unsecure: Somewhere in the authentication chain, at the time when authentication was tried, there was an RRset for which all of the RRSIG RRs did not cryptographically i verify or were intended for a different time interval. Alternatively not all needed links in the authorization chain were available e.g. because network failures. Recovery or Retry, in an attempt to reach a validated state are out side the scope of this definition. > Once security aware resolvers have determined if data is 'secure', 'insecure' or 'indeterminant' their work is done. This specification does not > define a format for communicating why data was found to be bogus or > insecure. For the communication between a security aware recursive > servers and security aware stub resolvers this specification defines a > default policy for communicating the 3 states. The detailed > specification of a method for signaling advanced error codes and or > policy between a security aware stub resolver and security aware > recursive nameservers is subject to future work. > > </proposed intro text> > > If the security aware recursive nameserver validates data as "indeterminant" > it returns an answer with RCODE=SERVFAIL > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 14:08:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25003 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 14:08:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao5op-0006XX-Ac for namedroppers-data@psg.com; Tue, 03 Feb 2004 19:02:43 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao5oW-0006V5-Kt for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 19:02:24 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 5EECF56852; Tue, 3 Feb 2004 11:02:21 -0800 (PST) Message-Id: <6.0.1.1.2.20040203135043.0284cc28@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 03 Feb 2004 14:02:55 -0500 To: bill <bmanning@karoshi.com>, olaf@ripe.net (Olaf Kolkman) From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: namedroppers@ops.ietf.org In-Reply-To: <200402031832.i13IWGG12658@karoshi.com> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think you're heading down the wrong direction here. There are actually 4 states. And bogus is definitely a different state than indeterminate and can get handled quite differently by a resolver. 1) Secure. I have a trust anchor, a chain of trust and I'm able to verify the signatures on all the data. 2) Unsecure. I have a trust anchor, a chain of trust, and, at the delegation point I have a signed proof of the non-existence of the DS record which makes subsequent branches in the tree provably unsecure. Resolver policy could also declare a portion of the tree unsecure from a branch point. 3) Bogus. I have a trust anchor which is giving me an expectation that subsidiary data will be signed (e.g. foo.com trust anchor implies that bar.foo.com will be signed unless its explicitly unsecure as above), but the data I'm handed fails to validate due to one or more of: missing signatures, invalid signatures (both for expiration and for the sig algorithm verification), missing data where the NXT (or what ever we're call them) say there should be data, etc. 4) Indeterminate. I have no trust anchor which would indicate that a specific portion of the tree is secure. This is the default case. Indeterminate and unsecure data should be handled more or less identically - e.g. accepted at face value if the policy allows it. Secure data should generally be accepted. Bogus data - well.... ideally this would depend on what the application cares about, but in practice it will be whatever the policy is at the caching/recursive resolver. At 01:32 PM 2/3/2004, bill wrote: > changes sprinkled throughout, mainly changing "bogus" to > "indeterminant", > > > > In the DNSSEC architecture the security aware resolver determines if > > DNS deta is in one of three states "unsecure", "validated" or > > "bogus". The specification in these document set is designed to make > > sure these 3 states can unambiguously be determined from the answers > > that are returned from security aware servers. > > I'm unconvinced that the resolver makes this choice. > a design we are working on/with has the validator as > an independent module that the resolver talks to and > it is the validator that determines the "state of the data" > and tells the resolver. So, alternate text: > > In the DNSSEC architecture a security enabled resolver receives data > in one of three states, "unsecure", "validated", or "indeterminant". > The specification in this document set is designed to make sure these > three states can unambigiously be determined from answers received > from security aware and enabled servers or caches. > > > Validated: Data is "validated" if one of possibly multiple > > authentication chains from a trust anchor to the data itself > > can be established. Multiple authentication chains can exist > > when there are multiple DS RRs at a delegation point or when > > data is covered by multiple RRSIGs. A security aware resolver > > may not have all possible authorization chains at its > > disposal, either because an authorization chain is based on an > > algorithm that has not been implemented or because there is no > > trust anchor for a possible authenticatio chain available. > > > > > > Unsecure: If no authentication chain can be established; either > > because there is no appropriate trust anchor or the > > authentication chain was broken because of the authenticated > > absence of DS RRs that point to keys of algorithms the > > resolver is able to use. > > > > If there are no trust anchors configured than all data is > > marked insecure. > > > > >Indeterminant: Data that is neither validated nor unsecure: Somewhere in the > authentication chain, at the time when authentication was > tried, there > was an RRset for which all of the RRSIG RRs did not > cryptographically i > verify or were intended for a different time interval. > Alternatively not > all needed links in the authorization chain were available e.g. > because > network failures. > > Recovery or Retry, in an attempt to reach a validated state are > out side the scope of this definition. > > > Once security aware resolvers have determined if data is 'secure', > 'insecure' or 'indeterminant' their work is done. This specification > does not > > define a format for communicating why data was found to be bogus or > > insecure. For the communication between a security aware recursive > > servers and security aware stub resolvers this specification defines a > > default policy for communicating the 3 states. The detailed > > specification of a method for signaling advanced error codes and or > > policy between a security aware stub resolver and security aware > > recursive nameservers is subject to future work. > > > > </proposed intro text> > > > > > If the security aware recursive nameserver validates data as "indeterminant" > > it returns an answer with RCODE=SERVFAIL > > > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 14:19:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25423 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 14:19:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao61D-0007pl-Iu for namedroppers-data@psg.com; Tue, 03 Feb 2004 19:15:31 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao60z-0007nS-1Y for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 19:15:17 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i13JFB913059; Tue, 3 Feb 2004 11:15:11 -0800 From: bill <bmanning@karoshi.com> Message-Id: <200402031915.i13JFB913059@karoshi.com> Subject: Re: Q-28 Clarification of the scope of the document set. To: Mike.StJohns@nominum.com (Mike StJohns) Date: Tue, 3 Feb 2004 11:15:11 -0800 (PST) Cc: bmanning@karoshi.com (bill), olaf@ripe.net (Olaf Kolkman), namedroppers@ops.ietf.org In-Reply-To: <6.0.1.1.2.20040203135043.0284cc28@localhost> from "Mike StJohns" at Feb 03, 2004 02:02:55 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit perhaps, but it may just be a desire to keep things "simple". for now, lets presume your four states. What else is a distingishing characteristic? I see these. the bogus lable is primarily driven by temporal events, e.g. routing anomolies, head space/timing syncronization, clocking errors, etc. secure/unsecure presume routing stability, accurate clocks and alert/aware operators. indeterminant is todays status quo. or do I have this wrong also? --bill > > I think you're heading down the wrong direction here. There are actually 4 > states. And bogus is definitely a different state than indeterminate and > can get handled quite differently by a resolver. > > > 1) Secure. I have a trust anchor, a chain of trust and I'm able to verify > the signatures on all the data. > > 2) Unsecure. I have a trust anchor, a chain of trust, and, at the > delegation point I have a signed proof of the non-existence of the DS > record which makes subsequent branches in the tree provably > unsecure. Resolver policy could also declare a portion of the tree > unsecure from a branch point. > > 3) Bogus. I have a trust anchor which is giving me an expectation that > subsidiary data will be signed (e.g. foo.com trust anchor implies that > bar.foo.com will be signed unless its explicitly unsecure as above), but > the data I'm handed fails to validate due to one or more of: missing > signatures, invalid signatures (both for expiration and for the sig > algorithm verification), missing data where the NXT (or what ever we're > call them) say there should be data, etc. > > 4) Indeterminate. I have no trust anchor which would indicate that a > specific portion of the tree is secure. This is the default case. > > Indeterminate and unsecure data should be handled more or less identically > - e.g. accepted at face value if the policy allows it. Secure data should > generally be accepted. Bogus data - well.... ideally this would depend on > what the application cares about, but in practice it will be whatever the > policy is at the caching/recursive resolver. > > > At 01:32 PM 2/3/2004, bill wrote: > > > changes sprinkled throughout, mainly changing "bogus" to > > "indeterminant", > > > > > > > In the DNSSEC architecture the security aware resolver determines if > > > DNS deta is in one of three states "unsecure", "validated" or > > > "bogus". The specification in these document set is designed to make > > > sure these 3 states can unambiguously be determined from the answers > > > that are returned from security aware servers. > > > > I'm unconvinced that the resolver makes this choice. > > a design we are working on/with has the validator as > > an independent module that the resolver talks to and > > it is the validator that determines the "state of the data" > > and tells the resolver. So, alternate text: > > > > In the DNSSEC architecture a security enabled resolver receives data > > in one of three states, "unsecure", "validated", or "indeterminant". > > The specification in this document set is designed to make sure these > > three states can unambigiously be determined from answers received > > from security aware and enabled servers or caches. > > > > > Validated: Data is "validated" if one of possibly multiple > > > authentication chains from a trust anchor to the data itself > > > can be established. Multiple authentication chains can exist > > > when there are multiple DS RRs at a delegation point or when > > > data is covered by multiple RRSIGs. A security aware resolver > > > may not have all possible authorization chains at its > > > disposal, either because an authorization chain is based on an > > > algorithm that has not been implemented or because there is no > > > trust anchor for a possible authenticatio chain available. > > > > > > > > > Unsecure: If no authentication chain can be established; either > > > because there is no appropriate trust anchor or the > > > authentication chain was broken because of the authenticated > > > absence of DS RRs that point to keys of algorithms the > > > resolver is able to use. > > > > > > If there are no trust anchors configured than all data is > > > marked insecure. > > > > > > > >Indeterminant: Data that is neither validated nor unsecure: Somewhere in the > > authentication chain, at the time when authentication was > > tried, there > > was an RRset for which all of the RRSIG RRs did not > > cryptographically i > > verify or were intended for a different time interval. > > Alternatively not > > all needed links in the authorization chain were available e.g. > > because > > network failures. > > > > Recovery or Retry, in an attempt to reach a validated state are > > out side the scope of this definition. > > > > > Once security aware resolvers have determined if data is 'secure', > > 'insecure' or 'indeterminant' their work is done. This specification > > does not > > > define a format for communicating why data was found to be bogus or > > > insecure. For the communication between a security aware recursive > > > servers and security aware stub resolvers this specification defines a > > > default policy for communicating the 3 states. The detailed > > > specification of a method for signaling advanced error codes and or > > > policy between a security aware stub resolver and security aware > > > recursive nameservers is subject to future work. > > > > > > </proposed intro text> > > > > > > > > If the security aware recursive nameserver validates data as "indeterminant" > > > it returns an answer with RCODE=SERVFAIL > > > > > > > > > -- > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 15:12:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28294 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 15:12:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao6o1-000EGD-Na for namedroppers-data@psg.com; Tue, 03 Feb 2004 20:05:57 +0000 Received: from [129.46.51.59] (helo=ithilien.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao6nm-000EDR-Oz for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 20:05:42 +0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13K5cvf005059; Tue, 3 Feb 2004 12:05:38 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13K5a1G005475; Tue, 3 Feb 2004 12:05:36 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: <p06020407bc45aed574bb@[129.46.227.161]> In-Reply-To: <6.0.1.1.2.20040203135043.0284cc28@localhost> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> Date: Tue, 3 Feb 2004 12:05:35 -0800 To: Mike StJohns <Mike.StJohns@nominum.comc.cnri.reston.va.us> From: Ted Hardie <hardie@qualcomm.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 2:02 PM -0500 02/03/2004, Mike StJohns wrote: >Bogus data - well.... ideally this would depend on what the >application cares about, but in practice it will be whatever the >policy is at the caching/recursive resolver. I think I'm confused here. What do you think the role of the application would be? Are you thinking that on getting an error message back from the DNS, it might engage in some activity (like throwing an error in a popup or syslog)? Or are you thinking an application policy might actually cause it to accept bogus data? regards, Ted Hardie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 15:43:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29754 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 15:43:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao7K5-000Hyp-1H for namedroppers-data@psg.com; Tue, 03 Feb 2004 20:39:05 +0000 Received: from [216.168.237.102] (helo=heron.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao7Jr-000Hwg-K1 for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 20:38:51 +0000 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id i13Kcfha023651; Tue, 3 Feb 2004 15:38:41 -0500 (EST) Received: from chinook.corppc.vrsn.com ([10.131.31.52]) by VSVAPOSTALGW1.vcorp.ad.vrsn.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1FXGXTML; Tue, 3 Feb 2004 15:38:40 -0500 Received: by chinook.corppc.vrsn.com (Postfix, from userid 500) id AAE889BB88; Tue, 3 Feb 2004 15:38:36 -0500 (EST) Date: Tue, 3 Feb 2004 15:38:36 -0500 From: Matt Larson <mlarson@verisign.com> To: Mike StJohns <Mike.StJohns@nominum.com> Cc: bill <bmanning@karoshi.com>, Olaf Kolkman <olaf@ripe.net>, namedroppers@ops.ietf.org Subject: Re: Q-28 Clarification of the scope of the document set. Message-ID: <20040203203836.GA18455@chinook.corppc.vrsn.com> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.1.1.2.20040203135043.0284cc28@localhost> User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mike, I think this is on the right track. A question and a comment: On Tue, 03 Feb 2004, Mike StJohns wrote: > I think you're heading down the wrong direction here. There are actually 4 > states. And bogus is definitely a different state than indeterminate and > can get handled quite differently by a resolver. > > > 1) Secure. I have a trust anchor, a chain of trust and I'm able to verify > the signatures on all the data. > > 2) Unsecure. I have a trust anchor, a chain of trust, and, at the > delegation point I have a signed proof of the non-existence of the DS > record which makes subsequent branches in the tree provably > unsecure. Resolver policy could also declare a portion of the tree > unsecure from a branch point. I'm assuming your "branch point" is a delegation point. By your last sentence, are you envisioning the ability to configure a resolver with the notion thay, say, "Always treat foo.com and its descendants as unsecure regardless of what security records you receive that might state otherwise"? I can see this being a handy feature when a zone is known to have something wrong DNSSEC-wise but one needs to communicate with it anyway. Realistically these scenarios are going to occur. > 3) Bogus. I have a trust anchor which is giving me an expectation that > subsidiary data will be signed (e.g. foo.com trust anchor implies that > bar.foo.com will be signed unless its explicitly unsecure as above), but > the data I'm handed fails to validate due to one or more of: missing > signatures, invalid signatures (both for expiration and for the sig > algorithm verification), missing data where the NXT (or what ever we're > call them) say there should be data, etc. > > 4) Indeterminate. I have no trust anchor which would indicate that a > specific portion of the tree is secure. This is the default case. > > Indeterminate and unsecure data should be handled more or less identically > - e.g. accepted at face value if the policy allows it. I'm having a hard time appreciating why anyone would ever care about the distinction between unsecure and indeterminate. Or to put it another way, what different action would be taken based on being in one of these states vs. the other? Unless I'm missing something, one only reaches an unsecure state by discovering a deliberate entry, i.e., an administrator has to make an entry in a secure zone declaring a child zone unsecure. So there's the subtle difference of "someone went out of their way to say this is unsecure" vs. "I just don't know its status". But my question is, is the difference too subtle to be worth calling out with a fourth state? Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 15:46:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00170 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 15:46:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao7Oh-000IjL-Hm for namedroppers-data@psg.com; Tue, 03 Feb 2004 20:43:51 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao7OU-000Ih0-HW for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 20:43:38 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id CF94F18DE for <namedroppers@ops.ietf.org>; Tue, 3 Feb 2004 15:43:36 -0500 (EST) Date: Tue, 03 Feb 2004 15:43:36 -0500 From: Rob Austein <sra+namedroppers@hactrn.net> To: namedroppers@ops.ietf.org Subject: Re: Q-28 Clarification of the scope of the document set. In-Reply-To: <p06020407bc45aed574bb@[129.46.227.161]> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> <p06020407bc45aed574bb@129.46.227.161> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040203204336.CF94F18DE@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 3 Feb 2004 12:05:35 -0800, Ted Hardie wrote: > > I think I'm confused here. What do you think the role of the > application would be? > Are you thinking that on getting an error message back from the DNS, it might > engage in some activity (like throwing an error in a popup or syslog)? Or > are you thinking an application policy might actually cause it to accept > bogus data? Given that only the application really knows what the application's "security" requirements are, final decision on how to handle the bad states pretty much has to be up to the application. All the nasty stuff with the AD bit, etc, is just an attempt to extend -some- protection to all the legacy DNS software that's already out there. As I've mumbled before, sig validation is an end-to-end thing between the DNS data producer (zone admin) and the DNS data consumer (app). And yeah, sure, an application might have a policy like "the admin of this zone is known to be an incompetent bozo, and I'm doing a strong authentication check with known keys at the app layer anyway, so I don't care whether the DNSSEC sigs check out or not". Shouldn't be the default policy, but you can bet that somebody's going to need to implement something like it sooner or later for some application. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 16:24:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04090 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 16:24:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao7uB-000MmQ-W6 for namedroppers-data@psg.com; Tue, 03 Feb 2004 21:16:23 +0000 Received: from [129.46.51.58] (helo=numenor.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao7ty-000Mkn-4X for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 21:16:10 +0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13LG1np001865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2004 13:16:02 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13LFx67014803; Tue, 3 Feb 2004 13:16:00 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: <p0602040abc45bc499c04@[129.46.227.161]> In-Reply-To: <20040203204336.CF94F18DE@thrintun.hactrn.net> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> <p06020407bc45aed574bb@129.46.227.161> <20040203204336.CF94F18DE@thrintun.hactrn.net> Date: Tue, 3 Feb 2004 13:15:58 -0800 To: Rob Austein <sra+namedroppers@hactrn.net>, namedroppers@ops.ietf.org From: Ted Hardie <hardie@qualcomm.com> Subject: Re: Q-28 Clarification of the scope of the document set. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 3:43 PM -0500 02/03/2004, Rob Austein wrote: >At Tue, 3 Feb 2004 12:05:35 -0800, Ted Hardie wrote: >> >> I think I'm confused here. What do you think the role of the >> application would be? >> Are you thinking that on getting an error message back from the >>DNS, it might >> engage in some activity (like throwing an error in a popup or syslog)? Or >> are you thinking an application policy might actually cause it to accept >> bogus data? > >Given that only the application really knows what the application's >"security" requirements are, final decision on how to handle the bad >states pretty much has to be up to the application. All the nasty >stuff with the AD bit, etc, is just an attempt to extend -some- >protection to all the legacy DNS software that's already out there. Assuming there are four states, and using Mike's names for them, I would say it makes sense to return the data from Secure, Unsecure, and Indeterminate results to the application layer, along with a marker as to which of those states the data came. Over time, with deployment increases, we would hope that more and more of the data would transition to Secure and out of Indeterminate. But Bogus strikes me differently. Here I would say that a normal DNSSec-aware call from an app to the DNS should return no data, but should throw an error saying that the data returned failed the DNSSEC checks. There may need to be another routine needed to allow an application to set the "ravish-me" bits, to use one of our colleague's colorful phrases, but it seems to me that we should be reaching for a day in which an application wanting to bypass those checks should have to do so explicitly. I don't see a way to do that if we start out with the default being an app receiving known-to-be bogus data and being asked to deal. A compromise might be to say that the error thrown by Bogus data should contain the bad data. Anyone reading the data out of the error and using it has pretty much got to know they're garbage fishing. Note that in the long term, I would expect this to be not so much a DNS protocol issue, but an API issue between the apps and the DNS. regards, Ted >As I've mumbled before, sig validation is an end-to-end thing between >the DNS data producer (zone admin) and the DNS data consumer (app). > >And yeah, sure, an application might have a policy like "the admin of >this zone is known to be an incompetent bozo, and I'm doing a strong >authentication check with known keys at the app layer anyway, so I >don't care whether the DNSSEC sigs check out or not". Shouldn't be >the default policy, but you can bet that somebody's going to need to >implement something like it sooner or later for some application. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 17:17:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08428 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 17:17:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao8mB-0002W4-LO for namedroppers-data@psg.com; Tue, 03 Feb 2004 22:12:11 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao8le-0002SQ-CU for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 22:11:38 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id DF97056838; Tue, 3 Feb 2004 14:11:36 -0800 (PST) Message-Id: <6.0.1.1.2.20040203170743.027b7d98@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 03 Feb 2004 17:12:10 -0500 To: Ted Hardie <hardie@qualcomm.com>, Mike StJohns <Mike.StJohns@nominum.comc.cnri.reston.va.us> From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: namedroppers@ops.ietf.org In-Reply-To: <p06020407bc45aed574bb@[129.46.227.161]> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> <p06020407bc45aed574bb@[129.46.227.161]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:05 PM 2/3/2004, Ted Hardie wrote: >At 2:02 PM -0500 02/03/2004, Mike StJohns wrote: >>Bogus data - well.... ideally this would depend on what the application >>cares about, but in practice it will be whatever the policy is at the >>caching/recursive resolver. > >I think I'm confused here. What do you think the role of the application >would be? >Are you thinking that on getting an error message back from the DNS, it might >engage in some activity (like throwing an error in a popup or syslog)? Or >are you thinking an application policy might actually cause it to accept >bogus data? > regards, > Ted Hardie I'm thinking that I might not care what the DNS is saying if the certificate handed to me by the SSL connection I'm initiating is the right one. The application may want to do the connection (or some other application specific thing based on various records such as NAPTR, MX, etc) regardless of whether or not DNS says the data is correct, IF (and maybe IFF) it has another way of verifying identity. Later, Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 17:32:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09765 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 17:32:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao906-0004EJ-QF for namedroppers-data@psg.com; Tue, 03 Feb 2004 22:26:34 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao8zk-00049y-Fx for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 22:26:13 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id C027E56842; Tue, 3 Feb 2004 14:26:09 -0800 (PST) Message-Id: <6.0.1.1.2.20040203171233.02cb0ec0@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 03 Feb 2004 17:26:43 -0500 To: Matt Larson <mlarson@verisign.com> From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: bill <bmanning@karoshi.com>, Olaf Kolkman <olaf@ripe.net>, namedroppers@ops.ietf.org In-Reply-To: <20040203203836.GA18455@chinook.corppc.vrsn.com> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> <20040203203836.GA18455@chinook.corppc.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:38 PM 2/3/2004, Matt Larson wrote: >Mike, > >I think this is on the right track. A question and a comment: > >On Tue, 03 Feb 2004, Mike StJohns wrote: > > I think you're heading down the wrong direction here. There are > actually 4 > > states. And bogus is definitely a different state than indeterminate and > > can get handled quite differently by a resolver. > > > > > > 1) Secure. I have a trust anchor, a chain of trust and I'm able to verify > > the signatures on all the data. > > > > 2) Unsecure. I have a trust anchor, a chain of trust, and, at the > > delegation point I have a signed proof of the non-existence of the DS > > record which makes subsequent branches in the tree provably > > unsecure. Resolver policy could also declare a portion of the tree > > unsecure from a branch point. > >I'm assuming your "branch point" is a delegation point. Mostly yes. Because the semantics of DS as a secure delegation indication is supposedly tied to delegation NS records. Its possible that we may also want to consider the case where the zone is foo.com, *.foo.com are secure records, but *.unsecure.foo.com are not and there isn't any actual delegation (e.g. its all still part of the zone). I'm not sure it makes sense to consider this case, but that's really what I meant by branch point. I can't think of a case where I'd want to do this, but that doesn't mean someone won't come up with a good reason. > By your last >sentence, are you envisioning the ability to configure a resolver with >the notion thay, say, "Always treat foo.com and its descendants as >unsecure regardless of what security records you receive that might >state otherwise"? I can see this being a handy feature when a zone is >known to have something wrong DNSSEC-wise but one needs to communicate >with it anyway. Realistically these scenarios are going to occur. Right. You can know that foo.com is secure, either because you've got a trust anchor for .com and .com says foo.com is secure, or you've got a direct trust anchor for foo.com. You may want to override what .com says about foo.com by declaring the zone unsecure. If you don't have a trust anchor for either foo.com or for .com, the zone is indeterminate. Its *possible* that what you want to do in this case is collect the top level keys the first time you do a query and then report future inconsistencies. Not saying this is a good idea, but its something you could do with indeterminate zones. > > 3) Bogus. I have a trust anchor which is giving me an expectation that > > subsidiary data will be signed (e.g. foo.com trust anchor implies that > > bar.foo.com will be signed unless its explicitly unsecure as above), but > > the data I'm handed fails to validate due to one or more of: missing > > signatures, invalid signatures (both for expiration and for the sig > > algorithm verification), missing data where the NXT (or what ever we're > > call them) say there should be data, etc. > > > > 4) Indeterminate. I have no trust anchor which would indicate that a > > specific portion of the tree is secure. This is the default case. > > > > Indeterminate and unsecure data should be handled more or less identically > > - e.g. accepted at face value if the policy allows it. > >I'm having a hard time appreciating why anyone would ever care about >the distinction between unsecure and indeterminate. Or to put it >another way, what different action would be taken based on being in >one of these states vs. the other? Unless I'm missing something, one >only reaches an unsecure state by discovering a deliberate entry, >i.e., an administrator has to make an entry in a secure zone declaring >a child zone unsecure. So there's the subtle difference of "someone >went out of their way to say this is unsecure" vs. "I just don't know >its status". But my question is, is the difference too subtle to be >worth calling out with a fourth state? I think its worth it because I can see the possibility of a policy that says "accept only data that's subsidiary to known trust anchors" secure, bogus and unsecure data are all subsidiary to known trust anchors by definition. This basically says, don't accept data from those who don't play in the DNSSEC sand box. Again, I may be over generalizing here, but given the rather limited discussion of resolver policy I'd rather do this now than trip over it later. >Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 17:33:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09844 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 17:33:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao94A-0004sz-R9 for namedroppers-data@psg.com; Tue, 03 Feb 2004 22:30:46 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao93v-0004nZ-Hy for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 22:30:31 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 8AEDB5684D; Tue, 3 Feb 2004 14:30:29 -0800 (PST) Message-Id: <6.0.1.1.2.20040203172754.0262dc00@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 03 Feb 2004 17:31:02 -0500 To: bill <bmanning@karoshi.com> From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: bmanning@karoshi.com (bill), olaf@ripe.net (Olaf Kolkman), namedroppers@ops.ietf.org In-Reply-To: <200402031915.i13JFB913059@karoshi.com> References: <6.0.1.1.2.20040203135043.0284cc28@localhost> <200402031915.i13JFB913059@karoshi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 02:15 PM 2/3/2004, bill wrote: > perhaps, but it may just be a desire to keep things "simple". > for now, lets presume your four states. What else is a distingishing > characteristic? I see these. > > the bogus lable is primarily driven by temporal events, e.g. > routing anomolies, head space/timing syncronization, clocking errors, Attacks. > etc. > > secure/unsecure presume routing stability, accurate clocks and > alert/aware operators. No - presume validatable signed data in the DNS that link back to known trust anchors. > indeterminant is todays status quo. > > or do I have this wrong also? No - I think you've got it mostly right, but see the above. The problem is one of relativity. All of these need to be relative to the querying entity. Its the one making the good-secure/good-unsecure/bad-bogus/indeterminate decision and then it needs to decide what to do with what it knows. >--bill > > > > > I think you're heading down the wrong direction here. There are > actually 4 > > states. And bogus is definitely a different state than indeterminate and > > can get handled quite differently by a resolver. > > > > > > 1) Secure. I have a trust anchor, a chain of trust and I'm able to verify > > the signatures on all the data. > > > > 2) Unsecure. I have a trust anchor, a chain of trust, and, at the > > delegation point I have a signed proof of the non-existence of the DS > > record which makes subsequent branches in the tree provably > > unsecure. Resolver policy could also declare a portion of the tree > > unsecure from a branch point. > > > > 3) Bogus. I have a trust anchor which is giving me an expectation that > > subsidiary data will be signed (e.g. foo.com trust anchor implies that > > bar.foo.com will be signed unless its explicitly unsecure as above), but > > the data I'm handed fails to validate due to one or more of: missing > > signatures, invalid signatures (both for expiration and for the sig > > algorithm verification), missing data where the NXT (or what ever we're > > call them) say there should be data, etc. > > > > 4) Indeterminate. I have no trust anchor which would indicate that a > > specific portion of the tree is secure. This is the default case. > > > > Indeterminate and unsecure data should be handled more or less identically > > - e.g. accepted at face value if the policy allows it. Secure data > should > > generally be accepted. Bogus data - well.... ideally this would depend on > > what the application cares about, but in practice it will be whatever the > > policy is at the caching/recursive resolver. > > > > > > At 01:32 PM 2/3/2004, bill wrote: > > > > > changes sprinkled throughout, mainly changing "bogus" to > > > "indeterminant", > > > > > > > > > > In the DNSSEC architecture the security aware resolver determines if > > > > DNS deta is in one of three states "unsecure", "validated" or > > > > "bogus". The specification in these document set is designed to make > > > > sure these 3 states can unambiguously be determined from the answers > > > > that are returned from security aware servers. > > > > > > I'm unconvinced that the resolver makes this choice. > > > a design we are working on/with has the validator as > > > an independent module that the resolver talks to and > > > it is the validator that determines the "state of the data" > > > and tells the resolver. So, alternate text: > > > > > > In the DNSSEC architecture a security enabled resolver receives data > > > in one of three states, "unsecure", "validated", or "indeterminant". > > > The specification in this document set is designed to make sure these > > > three states can unambigiously be determined from answers received > > > from security aware and enabled servers or caches. > > > > > > > Validated: Data is "validated" if one of possibly multiple > > > > authentication chains from a trust anchor to the data itself > > > > can be established. Multiple authentication chains can exist > > > > when there are multiple DS RRs at a delegation point or when > > > > data is covered by multiple RRSIGs. A security aware resolver > > > > may not have all possible authorization chains at its > > > > disposal, either because an authorization chain is based on an > > > > algorithm that has not been implemented or because there is no > > > > trust anchor for a possible authenticatio chain available. > > > > > > > > > > > > Unsecure: If no authentication chain can be established; either > > > > because there is no appropriate trust anchor or the > > > > authentication chain was broken because of the authenticated > > > > absence of DS RRs that point to keys of algorithms the > > > > resolver is able to use. > > > > > > > > If there are no trust anchors configured than all data is > > > > marked insecure. > > > > > > > > > > >Indeterminant: Data that is neither validated nor unsecure: Somewhere > in the > > > authentication chain, at the time when authentication was > > > tried, there > > > was an RRset for which all of the RRSIG RRs did not > > > cryptographically i > > > verify or were intended for a different time interval. > > > Alternatively not > > > all needed links in the authorization chain were available e.g. > > > because > > > network failures. > > > > > > Recovery or Retry, in an attempt to reach a validated state are > > > out side the scope of this definition. > > > > > > > Once security aware resolvers have determined if data is 'secure', > > > 'insecure' or 'indeterminant' their work is done. This specification > > > does not > > > > define a format for communicating why data was found to be bogus or > > > > insecure. For the communication between a security aware recursive > > > > servers and security aware stub resolvers this specification defines a > > > > default policy for communicating the 3 states. The detailed > > > > specification of a method for signaling advanced error codes and or > > > > policy between a security aware stub resolver and security aware > > > > recursive nameservers is subject to future work. > > > > > > > > </proposed intro text> > > > > > > > > > > > If the security aware recursive nameserver validates data as > "indeterminant" > > > > it returns an answer with RCODE=SERVFAIL > > > > > > > > > > > > -- > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > > > the word 'unsubscribe' in a single line as the message text body. > > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > > > > > >-- > > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > >the word 'unsubscribe' in a single line as the message text body. > > >archive: <http://ops.ietf.org/lists/namedroppers/> > > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 18:46:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13495 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 18:46:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AoA8K-000Bcc-Bi for namedroppers-data@psg.com; Tue, 03 Feb 2004 23:39:08 +0000 Received: from [129.46.51.59] (helo=ithilien.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AoA6R-000BTK-FV for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 23:37:11 +0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13Nb7vf019848; Tue, 3 Feb 2004 15:37:07 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13Nb4o5029932; Tue, 3 Feb 2004 15:37:05 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: <p0602040fbc45dea5a962@[129.46.227.161]> In-Reply-To: <6.0.1.1.2.20040203170743.027b7d98@localhost> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> <p06020407bc45aed574bb@[129.46.227.161]> <6.0.1.1.2.20040203170743.027b7d98@localhost> Date: Tue, 3 Feb 2004 15:37:04 -0800 To: Mike StJohns <Mike.StJohns@nominum.com> From: Ted Hardie <hardie@qualcomm.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:12 PM -0500 02/03/2004, Mike StJohns wrote: >At 03:05 PM 2/3/2004, Ted Hardie wrote: >>At 2:02 PM -0500 02/03/2004, Mike StJohns wrote: >>>Bogus data - well.... ideally this would depend on what the >>>application cares about, but in practice it will be whatever the >>>policy is at the caching/recursive resolver. >> >>I think I'm confused here. What do you think the role of the >>application would be? >>Are you thinking that on getting an error message back from the DNS, it might >>engage in some activity (like throwing an error in a popup or syslog)? Or >>are you thinking an application policy might actually cause it to accept >>bogus data? >> regards, >> Ted Hardie > >I'm thinking that I might not care what the DNS is saying if the >certificate handed to me by the SSL connection I'm initiating is the >right one. > >The application may want to do the connection (or some other >application specific thing based on various records such as NAPTR, >MX, etc) regardless of whether or not DNS says the data is correct, >IF (and maybe IFF) it has another way of verifying identity. The problem here is that the actions are serial. If I get Bogus data from the DNS and attempt a connection, I have given away some information about myself that may be going to an attacker. Even if my later check of the TLS cert prevents me from shoving my credit card number at the attacker, I'm still down on the game. I agree that there will be some conditions where an application needs to try a connection despite a DNSSEC result of Bogus data, but, as I said in my message to Rob, I think the app needs to work at it a bit. From an API perspective I think getting the result BOGUS_DATA to my "dnssec_dig AAAA goodguy.example.com" query is the right answer, even if I can go on to a "dnssec_dig -ravishme AAAA goodguy.example.com" to get the data anyway. Again, I think this is long term an API issue, not a protocol issue, but I want to make the point that at least one APPs guy would like to see Bogus data as an error to the APP unless the APP has specifically allowed it. Just my opinion, of course, regards, Ted Hardie is the r -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 09:07:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19032 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 09:07:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqYSd-00041e-U7 for namedroppers-data@psg.com; Tue, 10 Feb 2004 14:01:59 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqYSc-0003vd-ES for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 14:01:58 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1AE1NjO012836 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 09:01:23 -0500 (EST) Message-ID: <00f301c3efde$61b20260$b9370681@barnacle> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: trying to close Editor's Question Q-29 Date: Tue, 10 Feb 2004 09:01:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q-29 Resolver handling of expired RRSIGs So far, there doesn't seem to be a solid consensus on the following wording: > > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > checks were successful, depending on local policy". > > To replace the current text that states resolvers MUST reject out of date signatures. There is no time limit in the original question post, but the editors would like to see some resolution before the I-D cutoff date. Personally, I'd like it to be Fri. 13th if possible Please post your opinion if you haven't already. Or if you have further comments on the text, or substitute text. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 09:21:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19447 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 09:21:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqYiC-0006Ok-2h for namedroppers-data@psg.com; Tue, 10 Feb 2004 14:18:04 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqYi2-0006NN-TA for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 14:17:55 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AEHowQ000193 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 15:17:51 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AEIZek009313 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 15:18:35 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1AEIZoG009312 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:18:35 +0100 Date: Tue, 10 Feb 2004 15:18:35 +0100 From: Miek Gieben <miekg@atoom.net> To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 Message-ID: <20040210141835.GA9257@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <00f301c3efde$61b20260$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00f301c3efde$61b20260$b9370681@barnacle> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 10 Feb, @15:01, Scott wrote in "trying to close Editor's Quest ..."] > Q-29 Resolver handling of expired RRSIGs > > So far, there doesn't seem to be a solid consensus on the following wording: > > > > > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > > checks were successful, depending on local policy". > > > > > Please post your opinion if you haven't already. Or if you have further > comments on the text, or substitute text. I support the above text. A 'MUST' is way to strong. If one says MUST on this timing issue, what's next: MUST run ntp, MUST NOT fiddle with the local time? regards, Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 09:42:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20191 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 09:42:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZ2H-0009uI-E4 for namedroppers-data@psg.com; Tue, 10 Feb 2004 14:38:49 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZ2G-0009u6-ET for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 14:38:48 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AEcXwQ000374; Tue, 10 Feb 2004 15:38:34 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AEdIRm009781; Tue, 10 Feb 2004 15:39:18 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AEdHov009778; Tue, 10 Feb 2004 15:39:18 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 10 Feb 2004 15:39:17 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Scott Rose <scottr@nist.gov> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <00f301c3efde$61b20260$b9370681@barnacle> Message-ID: <Pine.LNX.4.58.0402101523510.9168@elektron.atoom.net> References: <00f301c3efde$61b20260$b9370681@barnacle> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 10 Feb 2004, Scott Rose wrote: > Q-29 Resolver handling of expired RRSIGs > > So far, there doesn't seem to be a solid consensus on the following wording: > > > > > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > > checks were successful, depending on local policy". > > > > > To replace the current text that states resolvers MUST reject out of date > signatures. There is no time limit in the original question post, but the > editors would like to see some resolution before the I-D cutoff date. > Personally, I'd like it to be Fri. 13th if possible > > Please post your opinion if you haven't already. Or if you have further > comments on the text, or substitute text. The issuer of the signature (signer) put a 'Only Use After/Before' stamp on the data.. The signer obviously wants the validator to consider the signature and data as valid within the specified time. That implicates that the signer wants an expired signature to be bogus (nee unsigned). I want validation to BREAK when it is way passed/before the expire/inception time. I really don't want users of my data, whereever they are, whatever the usage is, be replayed with expired signatures of a stolen key. If this is going to be degraded to SHOULD, the system is less secure. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 09:54:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20479 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 09:54:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZEB-000CRg-4X for namedroppers-data@psg.com; Tue, 10 Feb 2004 14:51:07 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZEA-000CRR-2d for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 14:51:06 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AEorwQ000644 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 15:50:53 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AEpcAC010045 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 15:51:38 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1AEpcKG010044 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:51:38 +0100 Date: Tue, 10 Feb 2004 15:51:38 +0100 From: Miek Gieben <miekg@atoom.net> To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 Message-ID: <20040210145138.GA10020@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <00f301c3efde$61b20260$b9370681@barnacle> <Pine.LNX.4.58.0402101523510.9168@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <Pine.LNX.4.58.0402101523510.9168@elektron.atoom.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 10 Feb, @15:39, roy wrote in "Re: trying to close Editor's Q ..."] > I want validation to BREAK when it is way passed/before the ^^^^^ making the issue local policy IMHO... grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:09:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21512 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:09:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZRl-000FRu-1O for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:05:09 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZRj-000FRU-8T for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:05:07 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1AF55HP006932 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 15:05:06 GMT To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: Message from Miek Gieben <miekg@atoom.net> of "Tue, 10 Feb 2004 15:18:35 +0100." <20040210141835.GA9257@atoom.net> Date: Tue, 10 Feb 2004 15:05:05 +0000 Message-ID: <6931.1076425505@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Miek" == Miek Gieben <miekg@atoom.net> writes: >> "SHOULD be rejected, but MAY use RRSIGs if other security >> checks were successful, depending on local policy. Miek> I support the above text. A 'MUST' is way to strong. If one Miek> says MUST on this timing issue, what's next: MUST run ntp, Miek> MUST NOT fiddle with the local time? I reluctantly support the text, but not Miek's justification for it. Correct synchronisation is vital for DNSSEC so saying the clocks MUST be aligned is not unreasonable. How that gets done is out of scope. The DNSSEC protocol shouldn't need to know or care how that synchronisation happens and so shouldn't say anything about that. However I worry that by only saying "SHOULD be rejected" for expired RRSIGs, this WG could be shooting itsefl in the foot again. The text seems to be saying that if DNSSEC validation fails but some other security check (like what?) works, it can be OK to use an answer that the resolver knows didn't validate properly. Or isn't valid any more. If that's really the case, why bother deploying DNSSEC or keeping keys and signatures up to date? After all some other unspecified security check can be used instead. And how can these hypothetical security checks be made to interwork? Do I tell my resolver to accept something on the say-so of Miek's server even though his server was unable to do DNSSEC validation of that data? How about the text below? .... SHOULD be rejected, but MAY use RRSIGs. In certain circumstances local policy MAY consider this to be acceptable behaviour, for example if other security checks on the data have been successful. The consequences of such a policy need to be carefully assessed. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:17:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22356 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:17:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZaR-000H1V-TK for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:14:07 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZaK-000GwF-AR for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:14:00 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1AFDtHP006974; Tue, 10 Feb 2004 15:13:55 GMT To: roy@dnss.ec cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: Message from roy@dnss.ec of "Tue, 10 Feb 2004 15:39:17 +0100." <Pine.LNX.4.58.0402101523510.9168@elektron.atoom.net> Date: Tue, 10 Feb 2004 15:13:55 +0000 Message-ID: <6973.1076426035@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "roy" == roy <roy@dnss.ec> writes: roy> I want validation to BREAK when it is way passed/before the roy> expire/inception time. I really don't want users of my data, roy> whereever they are, whatever the usage is, be replayed with roy> expired signatures of a stolen key. roy> If this is going to be degraded to SHOULD, the system is less roy> secure. I agree with this in principle. However there may be cases where data that doesn't validate might need to be used to bootstrap the validation process. Suppose your key gets compromised. You withdraw it immediately and re-sign your zone with a new key. So far, so good. Now my server is caching a SIG for your zone's NS RRset generated with the old key. Should my server query those NS records to try and get your new key or wait for them to expire from my cache? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:21:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22627 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:21:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZf4-000Hyb-M5 for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:18:54 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZf3-000HyC-HZ for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:18:53 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AFIewQ002015; Tue, 10 Feb 2004 16:18:40 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.10/8.12.10/Submit) id i1AFIeCe002014; Tue, 10 Feb 2004 16:18:40 +0100 (CET) (envelope-from ted) Message-Id: <200402101518.i1AFIeCe002014@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Tue, 10 Feb 2004 16:18:40 +0100 In-Reply-To: "Miek Gieben's message as of Feb 10, 16:01" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Miek Gieben <miekg@atoom.net>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Miek Gieben, on Feb 10, 16:01, in "Re: trying to close ..."] > [On 10 Feb, @15:39, roy wrote in "Re: trying to close Editor's Q ..."] > > I want validation to BREAK when it is way passed/before the > ^^^^^ > making the issue local policy IMHO... No, that is the local policy at the validator-side, Roy was talking about what he wants from the signers perspective. While I agree with Roy on "way passed/before" time difference, I also agree with the people at the workshop that argued that some slack is needed to cope with small clock variations and/or network delays. Perhaps we can settle this dispute with an addition like: > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > > checks were successful, depending on local policy, to cope with small clock variations or network delays". -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:23:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22715 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:23:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZgW-000IBv-Eb for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:20:24 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZgP-000IAs-33 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:20:17 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AFK6wQ002039 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 16:20:06 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AFKp6Q010563 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 16:20:51 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1AFKpNV010562 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 16:20:51 +0100 Date: Tue, 10 Feb 2004 16:20:51 +0100 From: Miek Gieben <miekg@atoom.net> To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 Message-ID: <20040210152051.GA10087@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <20040210141835.GA9257@atoom.net> <6931.1076425505@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6931.1076425505@gromit.rfc1035.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 10 Feb, @16:05, Jim wrote in "Re: trying to close Editor's Q ..."] > unspecified security check can be used instead. And how can these > hypothetical security checks be made to interwork? Do I tell my > resolver to accept something on the say-so of Miek's server even > though his server was unable to do DNSSEC validation of that data? If I were to browse the web and my resolver would tell my browser: "this data is bad, because the SIG expired 10 minutes ago" (suppose it can tell that to my browser), it would be pretty neat if I could still check out the (faked) website on the Internet. Or not? > How about the text below? > .... SHOULD be rejected, but MAY use RRSIGs. In certain > circumstances local policy MAY consider this to be > acceptable behaviour, for example if other security checks on > the data have been successful. The consequences of such a > policy need to be carefully assessed. anything without the MUST has my support, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:35:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23205 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:35:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZr8-000Kmq-Uj for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:31:22 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZqy-000Km4-65 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:31:12 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AFUswQ002469; Tue, 10 Feb 2004 16:30:54 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AFVdEE010846; Tue, 10 Feb 2004 16:31:39 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AFVdaL010843; Tue, 10 Feb 2004 16:31:39 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 10 Feb 2004 16:31:39 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Jim Reid <jim@rfc1035.com> cc: roy@dnss.ec, Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <6973.1076426035@gromit.rfc1035.com> Message-ID: <Pine.LNX.4.58.0402101616340.9168@elektron.atoom.net> References: <6973.1076426035@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 10 Feb 2004, Jim Reid wrote: > >>>>> "roy" == roy <roy@dnss.ec> writes: > > roy> I want validation to BREAK when it is way passed/before the > roy> expire/inception time. I really don't want users of my data, > roy> whereever they are, whatever the usage is, be replayed with > roy> expired signatures of a stolen key. > > roy> If this is going to be degraded to SHOULD, the system is less > roy> secure. > > I agree with this in principle. Okay. > However there may be cases where data that doesn't validate might need > to be used to bootstrap the validation process. OOB is the only way. > Suppose your key gets compromised. The whole system breaks at this point. > You withdraw it immediately and re-sign your zone with a new key. So > far, so good. Now my server is caching a SIG for your zone's NS RRset > generated with the old key. Should my server query those NS records to > try and get your new key or wait for them to expire from my cache? Wait for the expire time. Until then, all bets are off. There is no short-cut-local-uptimisation here. If your key is stolen by ScriptKiddy, he'll generate new keys/sigs and update caches for you. The only way caches are protected against replay is current time check. It is part of the crypto-layer. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:43:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23587 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:43:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZyz-000MUW-QK for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:39:29 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZyo-000MT8-VU for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:39:19 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AFd2wQ002663; Tue, 10 Feb 2004 16:39:04 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AFdmZB011005; Tue, 10 Feb 2004 16:39:48 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AFdmYI011002; Tue, 10 Feb 2004 16:39:48 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 10 Feb 2004 16:39:48 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ted Lindgreen <ted@NLnetLabs.nl> cc: Miek Gieben <miekg@atoom.net>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <200402101518.i1AFIeCe002014@open.nlnetlabs.nl> Message-ID: <Pine.LNX.4.58.0402101634020.9168@elektron.atoom.net> References: <200402101518.i1AFIeCe002014@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 10 Feb 2004, Ted Lindgreen wrote: > [Quoting Miek Gieben, on Feb 10, 16:01, in "Re: trying to close ..."] > > [On 10 Feb, @15:39, roy wrote in "Re: trying to close Editor's Q ..."] > > > I want validation to BREAK when it is way passed/before the > > ^^^^^ > > making the issue local policy IMHO... > > No, that is the local policy at the validator-side, Roy was talking > about what he wants from the signers perspective. Exactly. > While I agree with Roy on "way passed/before" time difference, I > also agree with the people at the workshop that argued that some > slack is needed to cope with small clock variations and/or > network delays. The delay/variation problem can be solved with overlapping keys/signatures. KEY1 : day 5 ... day 10 KEY2 : day 9 ... day 20 This way, there is a one day slack either way. This is the reason that there is no 'fudge' in the RRSIG record, like the TSIG record has. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 13:18:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00953 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 13:17:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqcOr-0001Aw-Pu for namedroppers-data@psg.com; Tue, 10 Feb 2004 18:14:21 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqcOl-0001A0-PC for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 18:14:15 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AIEBwQ003674 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:14:11 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AIEvUu013243 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:14:57 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AIEve5013240 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:14:57 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 10 Feb 2004 19:14:57 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: Re: Fingerprinting DNS implementations. In-Reply-To: <Pine.LNX.4.58.0312092248380.4290@elektron.atoom.net> Message-ID: <Pine.LNX.4.58.0402101914190.9168@elektron.atoom.net> References: <Pine.LNX.4.58.0312092248380.4290@elektron.atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 9 Dec 2003, Roy Arends wrote: > Hi, > > Jakob and I spent the past few weeks hacking up a DNS implementation > fingerprint tool (where implementation == anything responding to a query). > This mail introduces the methodology of fingerprinting DNS > implementations. Tool is available at http://www.rfc.se/fpdns Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 14:03:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00952 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 13:17:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqcMl-0000nH-4q for namedroppers-data@psg.com; Tue, 10 Feb 2004 18:12:11 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqcMh-0000my-07 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 18:12:07 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AIBjwQ003664 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:11:47 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AICWeY013183 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:12:32 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AICUnZ013180 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:12:31 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 10 Feb 2004 19:12:30 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: Re: Fingerprinting DNS implementations. In-Reply-To: <Pine.LNX.4.58.0312092248380.4290@elektron.atoom.net> Message-ID: <Pine.LNX.4.58.0402101911340.9168@elektron.atoom.net> References: <Pine.LNX.4.58.0312092248380.4290@elektron.atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 9 Dec 2003, Roy Arends wrote: > Hi, > > Jakob and I spent the past few weeks hacking up a DNS implementation > fingerprint tool (where implementation == anything responding to a query). > This mail introduces the methodology of fingerprinting DNS > implementations. Tool is available at http://www.rfc.se/fpdns Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 14:09:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03295 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 14:09:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqdDO-000A5B-8l for namedroppers-data@psg.com; Tue, 10 Feb 2004 19:06:34 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqdDL-000A4c-1f for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 19:06:31 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1AJ5tjO024464 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 14:05:55 -0500 (EST) Message-ID: <007001c3f008$d515dbd0$b9370681@campus.nist.gov> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <D6EDDF48-5194-11D8-AF3C-000393DA2D46@ripe.net> Subject: Re: Q-24 DNSKEY with flag 7=0 not to be used with DNSSEC. Date: Tue, 10 Feb 2004 14:05:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am not sure we need this text added. Later in the text, when discussing the authentication proceedure for data, it clearly states that any DNSKEY used to verify RRSIGs must have its zone bit flag set to one. We can add it again to section 2.1, but that statement is already made where it counts in the section dealing with response authentication. Scott ----- Original Message ----- From: "Olaf Kolkman" <olaf@ripe.net> > > The behavior for the flag bit (bit7) in the DNSKEY RR set to 0 is not > specified. We propose the following text to be added to section 2.1: > DNSKEY RRs MUST NOT be used for DNSSEC validation if bit 7 of the flag > field is set to 0. > > > --Olaf > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 18:48:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00600 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 18:48:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqhWq-000ONd-Hf for namedroppers-data@psg.com; Tue, 10 Feb 2004 23:42:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.psg.com with smtp (Exim 4.30; FreeBSD) id 1AqhWj-000OMq-5L for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 23:42:49 +0000 Received: (qmail 30649 invoked from network); 10 Feb 2004 23:58:25 -0000 Received: from h219-110-033-104.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.104) by necom830.hpcl.titech.ac.jp with SMTP; 10 Feb 2004 23:58:25 -0000 Message-ID: <40296CDC.1060107@necom830.hpcl.titech.ac.jp> Date: Wed, 11 Feb 2004 08:44:28 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Scott Rose <scottr@nist.gov> CC: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 References: <00f301c3efde$61b20260$b9370681@barnacle> In-Reply-To: <00f301c3efde$61b20260$b9370681@barnacle> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose wrote: > Q-29 Resolver handling of expired RRSIGs > > So far, there doesn't seem to be a solid consensus on the following wording: > > >>>"SHOULD be rejected, but MAY use RRSIGs if other security >>>checks were successful, depending on local policy". It effectively means that DNSSEC is unnecessary. So edit rest of the draft to make it empty. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 18:48:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00627 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 18:48:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqhZ8-000P8V-8i for namedroppers-data@psg.com; Tue, 10 Feb 2004 23:45:18 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqhZ7-000P7v-51 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 23:45:17 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1ANj1HP007696; Tue, 10 Feb 2004 23:45:03 GMT To: ted@NLnetLabs.nl (Ted Lindgreen) cc: Miek Gieben <miekg@atoom.net>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: Message from ted@NLnetLabs.nl (Ted Lindgreen) of "Tue, 10 Feb 2004 16:18:40 +0100." <200402101518.i1AFIeCe002014@open.nlnetlabs.nl> Date: Tue, 10 Feb 2004 23:45:01 +0000 Message-ID: <7695.1076456701@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ted" == Ted Lindgreen <ted@NLnetLabs.nl> writes: Ted> While I agree with Roy on "way passed/before" time Ted> difference, I also agree with the people at the workshop that Ted> argued that some slack is needed to cope with small clock Ted> variations and/or network delays. Ted> Perhaps we can settle this dispute with an addition like: >> > "SHOULD be rejected, but MAY use RRSIGs if other security >> > checks were successful, depending on local policy, to >> > cope with small clock variations or network delays". I think a definition of "small" will be needed. How about using the same fudge factor TSIG allows for skewed clocks? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 18:50:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00751 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 18:50:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqhc1-000PRv-MO for namedroppers-data@psg.com; Tue, 10 Feb 2004 23:48:17 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqhbz-000PRc-D1 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 23:48:15 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1ANm8HP007707; Tue, 10 Feb 2004 23:48:09 GMT To: roy@dnss.ec cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: Message from roy@dnss.ec of "Tue, 10 Feb 2004 16:31:39 +0100." <Pine.LNX.4.58.0402101616340.9168@elektron.atoom.net> Date: Tue, 10 Feb 2004 23:48:08 +0000 Message-ID: <7706.1076456888@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "roy" == roy <roy@dnss.ec> writes: >> However there may be cases where data that doesn't validate >> might need to be used to bootstrap the validation process. roy> OOB is the only way. Indeed. And that's what the original text was hinting at when it spoke about "other security checks". roy> The only way caches are protected against replay is current roy> time check. It is part of the crypto-layer. In that case, a MUST is needed, not a SHOULD. Oh how I *hate* DNSSEC... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 03:16:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21516 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 03:16:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqpSY-0009gc-Sy for namedroppers-data@psg.com; Wed, 11 Feb 2004 08:11:02 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqpSX-0009gQ-Rr for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 08:11:01 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i1B88f9L016814 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 03:08:41 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4yaGSG; Wed, 11 Feb 04 03:08:07 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i1B6YwkW004890 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 01:34:59 -0500 (EST) Date: Wed, 11 Feb 2004 01:34:58 -0500 (EST) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <7706.1076456888@gromit.rfc1035.com> Message-ID: <Pine.GSO.4.55.0402110127350.4412@filbert> References: <7706.1076456888@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Repeating what I said when I started this discussion on 15 January: I think SHOULD is perfectly correct. Scott suggests: > > "SHOULD be rejected, but MAY use RRSIGs if other security > > checks were successful, depending on local policy". Using the language of Q-28 (which may change slightly), I think five words are sufficient: "SHOULD be treated as bogus." The MAY is implicit. > roy> The only way caches are protected against replay is current > roy> time check. It is part of the crypto-layer. > Jim> In that case, a MUST is needed, not a SHOULD. Disagree. This is a 2119 "SHOULD" -- ignore at your own peril and only after due consideration (Really. We mean it.), but you're not hurting anyone other than yourself. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 04:01:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23153 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 04:01:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqqDR-000Ins-Vf for namedroppers-data@psg.com; Wed, 11 Feb 2004 08:59:29 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqqDG-000Ilo-Qd for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 08:59:18 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1B8wwwQ008720; Wed, 11 Feb 2004 09:58:59 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1B8xnwp023302; Wed, 11 Feb 2004 09:59:49 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1B8xmrm023299; Wed, 11 Feb 2004 09:59:49 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 11 Feb 2004 09:59:48 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Samuel Weiler <weiler@tislabs.com> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <Pine.GSO.4.55.0402110127350.4412@filbert> Message-ID: <Pine.LNX.4.58.0402110927050.22586@elektron.atoom.net> References: <7706.1076456888@gromit.rfc1035.com> <Pine.GSO.4.55.0402110127350.4412@filbert> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 11 Feb 2004, Samuel Weiler wrote: > Repeating what I said when I started this discussion on 15 January: Repetitive statements does not make your argument more true. > I think SHOULD is perfectly correct. You were wrong then, you are wrong now. You wrote: "To accomodate local policy, I think these should be SHOULD NOTs." in your january 15th mail. You are using "local policy" as magic paint to ram your view of the robustness principle into a validator. ANY policy that allows treating expired signatures as valid is BAD policy. The validator validates, checking the time stamp is part of the validation. It's as old at 2065 (6.4 Secure Time). Its in 2535 (6.4 Secure Time). Why change it now ? > Scott suggests: > > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > > checks were successful, depending on local policy". > > Using the language of Q-28 (which may change slightly), I think five > words are sufficient: "SHOULD be treated as bogus." The MAY is > implicit. Repetitive statement. Repetitive statement. > > roy> The only way caches are protected against replay is current > > roy> time check. It is part of the crypto-layer. > > > Jim> In that case, a MUST is needed, not a SHOULD. > > Disagree. This is a 2119 "SHOULD" -- ignore at your own peril and > only after due consideration (Really. We mean it.), but you're not > hurting anyone other than yourself. The exact meaning of MUST applies perfectly: MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. This is an absolute requirement. A dealbreaker. Protecting against replay. If this is a SHOULD the system is less secure. I can sign data with a Very Large Key and a Very Short Validity Period. If some implementation has a switch that allows end users to TRUST MY DATA while MY DATA IS BOGUS due to expiration, then that switch is illegal. If that switch is legal, all bets are off. Change local time as a workaround to have a system validate old signatures. Don't hack the spec to allow for this. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 04:30:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24007 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 04:29:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqqbm-000MwD-D8 for namedroppers-data@psg.com; Wed, 11 Feb 2004 09:24:38 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqqbb-000MvF-IL for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 09:24:27 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1B9O8wQ009019 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 10:24:08 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.10/8.12.10/Submit) id i1B9O8ub009018 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 10:24:08 +0100 (CET) (envelope-from ted) Message-Id: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 11 Feb 2004 10:24:08 +0100 In-Reply-To: "Jim Reid's message as of Feb 11, 0:45" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Jim Reid, on Feb 11, 0:45, in "Re: trying to close ..."] > >>>>> "Ted" == Ted Lindgreen <ted@NLnetLabs.nl> writes: > > Ted> While I agree with Roy on "way passed/before" time > Ted> difference, I also agree with the people at the workshop that > Ted> argued that some slack is needed to cope with small clock > Ted> variations and/or network delays. > > Ted> Perhaps we can settle this dispute with an addition like: > > >> > "SHOULD be rejected, but MAY use RRSIGs if other security > >> > checks were successful, depending on local policy, to > >> > cope with small clock variations or network delays". > > I think a definition of "small" will be needed. How about using the same > fudge factor TSIG allows for skewed clocks? Roy pointed out that there is no need for fudge, as (other than with TSIG) one can (and should) use overlapping periods. Therefore, I take back my comment and proposal above. It is clear that outside the validity periods a SIG is meant to be not valid. This is what the zone-administrator wanted and configured. Remains the question of wording what to do with such a SIG in the sense of RFC 2119. Reading RFC 2119 again, I think that what Sam wrote: [Quoting Samuel Weiler, on Feb 11, 9:19, in "Re: trying to close ..."] ..... > Repeating what I said when I started this discussion on 15 January: > > I think SHOULD is perfectly correct. is 100% correct. (Please read RFC 2119 first if you disagree). And I support Sam's suggestion that: "SHOULD be treated as bogus" is sufficient. IMHO: Adding anything else is unnecessary (it's already in RFC 2119) and only asking for trouble and endless discussions. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 05:28:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25833 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 05:28:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqrXU-0007QO-7o for namedroppers-data@psg.com; Wed, 11 Feb 2004 10:24:16 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqrXS-0007PJ-Th for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 10:24:15 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1BAO9HP008885; Wed, 11 Feb 2004 10:24:10 GMT To: ted@NLnetLabs.nl (Ted Lindgreen) cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: Message from ted@NLnetLabs.nl (Ted Lindgreen) of "Wed, 11 Feb 2004 10:24:08 +0100." <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> Date: Wed, 11 Feb 2004 10:24:09 +0000 Message-ID: <8884.1076495049@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ted" == Ted Lindgreen <ted@NLnetLabs.nl> writes: >> > checks were successful, depending on local policy, to >> > cope with small clock variations or network delays". >> >> I think a definition of "small" will be needed. How about using >> the same fudge factor TSIG allows for skewed clocks? Ted> Roy pointed out that there is no need for fudge, as (other Ted> than with TSIG) one can (and should) use overlapping periods. Ted> Therefore, I take back my comment and proposal above. I take back mine too. Thanks for helping to stop the discussion doing down that particular rathole. Ted> It is clear that outside the validity periods a SIG is meant Ted> to be not valid. This is what the zone-administrator wanted Ted> and configured. Indeed. I overlooked this basic truth. Ted> And I support Sam's suggestion that: "SHOULD be treated as Ted> bogus" is sufficient. This can't be right. Roy's given good technical reasons for that. And using a SHOULD makes validation optional. Logically, this is very bad as it provides a get-out. To repeat my earlier question, why bother with DNSSEC validation if failures can be disregarded and substituted by other (unspecified) security checks? It is beyond credibility that this WG could toil over DNSSEC for 7? 8? years now and come up with a spec with a gaping hole that's so big someone could drive a fleet of trucks through it. If the draft leaves enough wiggle room to make validation optional, why bother validating or signing anything? Suppose Microsoft (say) use this loophole to avoid implementing validation. [Remember they're good at finding ways to wiggle out of supporting useful stuff that isn't mandatory to implement.] After all their desktops would be free to use some other security check: that's what the spec currently says. This would mean 90-something% of the internet will not get any benefit from DNSSEC and that's a *massive* disincentive for deploying it. Speaking as a DNS administrator, there's no way I'd go through the pain of signing my zones or doing key rollover if nobody's going to be compelled to validate them. Ted> IMHO: Adding anything else is unnecessary (it's already in Ted> RFC 2119) and only asking for trouble and endless Ted> discussions. Isn't asking for trouble and endless discussions what DNSSEC is all about? :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 06:26:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27302 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 06:26:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqsT2-000IRf-Hs for namedroppers-data@psg.com; Wed, 11 Feb 2004 11:23:44 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqsT1-000IRP-Dq for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 11:23:43 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BBNOwQ010474 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 12:23:24 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BBOGNQ025402 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 12:24:16 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1BBOGF2025401 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 12:24:16 +0100 Date: Wed, 11 Feb 2004 12:24:16 +0100 From: Miek Gieben <miekg@atoom.net> To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 Message-ID: <20040211112416.GA25148@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <7706.1076456888@gromit.rfc1035.com> <Pine.GSO.4.55.0402110127350.4412@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <Pine.GSO.4.55.0402110127350.4412@filbert> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 11 Feb, @07:34, Samuel wrote in "Re: trying to close Editor's Q ..."] > Using the language of Q-28 (which may change slightly), I think five > words are sufficient: "SHOULD be treated as bogus." The MAY is > implicit. after reading 2119, I wholehearted agree that these 5 words are enough, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 06:56:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28137 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 06:56:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqswN-000OSX-OC for namedroppers-data@psg.com; Wed, 11 Feb 2004 11:54:03 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqswM-000OSL-Ol for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 11:54:02 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BBrhwQ010707; Wed, 11 Feb 2004 12:53:43 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BBsZje025757; Wed, 11 Feb 2004 12:54:35 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BBsZU8025754; Wed, 11 Feb 2004 12:54:35 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 11 Feb 2004 12:54:35 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ted Lindgreen <ted@NLnetLabs.nl> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> Message-ID: <Pine.LNX.4.58.0402111246230.25699@elektron.atoom.net> References: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 11 Feb 2004, Ted Lindgreen wrote: > [Quoting Samuel Weiler, on Feb 11, 9:19, in "Re: trying to close ..."] > ..... > > Repeating what I said when I started this discussion on 15 January: > > > > I think SHOULD is perfectly correct. > > is 100% correct. (Please read RFC 2119 first if you disagree). > > And I support Sam's suggestion that: > "SHOULD be treated as bogus" > is sufficient. > > IMHO: Adding anything else is unnecessary (it's already in RFC 2119) > and only asking for trouble and endless discussions. Ted, Miek, Sam, anyone Could you please state what those 'valid reasons' or 'particular circumstances' are that can not be satisfied outside the DNSSEC protocol to justify a change to SHOULD ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 08:23:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00052 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 08:23:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AquGf-000BXq-4j for namedroppers-data@psg.com; Wed, 11 Feb 2004 13:19:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AquGU-000BQk-AE for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 13:18:54 +0000 Received: (qmail 34478 invoked from network); 11 Feb 2004 13:34:40 -0000 Received: from h219-110-033-104.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.104) by necom830.hpcl.titech.ac.jp with SMTP; 11 Feb 2004 13:34:40 -0000 Message-ID: <402A2C21.7070606@necom830.hpcl.titech.ac.jp> Date: Wed, 11 Feb 2004 22:20:33 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: roy@dnss.ec CC: Ted Lindgreen <ted@NLnetLabs.nl>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 References: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111246230.25699@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0402111246230.25699@elektron.atoom.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit roy@dnss.ec wrote: > Ted, Miek, Sam, anyone > > Could you please state what those 'valid reasons' or 'particular > circumstances' are that can not be satisfied outside the DNSSEC > protocol to justify a change to SHOULD ? As you ask anyone else, there absolutely are no circumstances not satisfied by plain DNS. That is, DNSSEC is unnecessary. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 08:46:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00822 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 08:46:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqueL-000G8x-Mj for namedroppers-data@psg.com; Wed, 11 Feb 2004 13:43:33 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqueE-000G6g-C3 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 13:43:26 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BDhDwQ011939 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 14:43:13 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.10/8.12.10/Submit) id i1BDhDGj011938 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 14:43:13 +0100 (CET) (envelope-from ted) Message-Id: <200402111343.i1BDhDGj011938@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 11 Feb 2004 14:43:13 +0100 In-Reply-To: "roy@dnss.ec's message as of Feb 11, 12:54" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting roy@dnss.ec, on Feb 11, 12:54, in "Re: trying to close ..."] ... > Ted, Miek, Sam, anyone > > Could you please state what those 'valid reasons' or 'particular > circumstances' are that can not be satisfied outside the DNSSEC > protocol to justify a change to SHOULD ? I can think of several circumstances one still wants to see the returned info when the signatures fail, but the most clear one is probably: when debugging a lookup problem. This seems to me a typical example of what is meant by the wording in RFC 2119 for "SHOULD". In contrast, the wording of "MUST" in RFC 2119 makes debugging impossible, and that is not what we want, I think. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 09:08:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01359 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 09:08:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aquz0-000KdA-Sw for namedroppers-data@psg.com; Wed, 11 Feb 2004 14:04:54 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aquyz-000Kch-KV for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 14:04:53 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1BE4NjO027204 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 09:04:23 -0500 (EST) Message-ID: <002d01c3f0a7$dddb7e60$b9370681@campus.nist.gov> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <200402111343.i1BDhDGj011938@open.nlnetlabs.nl> Subject: Re: trying to close Editor's Question Q-29 Date: Wed, 11 Feb 2004 09:03:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If one is debugging DNSSEC, it would make more sense to turn on the CD bit for queries and not rely on whatever policy is in place at a recursive resolver. One wouldn't know if the recursive resolver is accepting out of date RRSIGs or not. Use of "SHOULD" might lead to unexpected behavior. Use of the CD bit overrides any local policy for "pass through" recursive resolvers for that query. Scott ----- Original Message ----- From: "Ted Lindgreen" <ted@NLnetLabs.nl> To: <namedroppers@ops.ietf.org> Sent: Wednesday, February 11, 2004 8:43 AM Subject: Re: trying to close Editor's Question Q-29 > [Quoting roy@dnss.ec, on Feb 11, 12:54, in "Re: trying to close ..."] > .... > > Ted, Miek, Sam, anyone > > > > Could you please state what those 'valid reasons' or 'particular > > circumstances' are that can not be satisfied outside the DNSSEC > > protocol to justify a change to SHOULD ? > > I can think of several circumstances one still wants to see the > returned info when the signatures fail, but the most clear one > is probably: when debugging a lookup problem. > > This seems to me a typical example of what is meant by the wording > in RFC 2119 for "SHOULD". > > In contrast, the wording of "MUST" in RFC 2119 makes debugging > impossible, and that is not what we want, I think. > > -- ted > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 09:14:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01649 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 09:14:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqv4p-000M1l-VC for namedroppers-data@psg.com; Wed, 11 Feb 2004 14:10:55 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqv4h-000M0g-Is for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 14:10:47 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BEAZwQ012339; Wed, 11 Feb 2004 15:10:35 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BEBSrr028068; Wed, 11 Feb 2004 15:11:28 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BEBSXs028065; Wed, 11 Feb 2004 15:11:28 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 11 Feb 2004 15:11:28 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ted Lindgreen <ted@NLnetLabs.nl> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <200402111343.i1BDhDGj011938@open.nlnetlabs.nl> Message-ID: <Pine.LNX.4.58.0402111454350.25699@elektron.atoom.net> References: <200402111343.i1BDhDGj011938@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 11 Feb 2004, Ted Lindgreen wrote: > [Quoting roy@dnss.ec, on Feb 11, 12:54, in "Re: trying to close ..."] > ... > > Ted, Miek, Sam, anyone > > > > Could you please state what those 'valid reasons' or 'particular > > circumstances' are that can not be satisfied outside the DNSSEC > > protocol to justify a change to SHOULD ? > > I can think of several circumstances one still wants to see the > returned info when the signatures fail, but the most clear one > is probably: when debugging a lookup problem. Debug with CD=1 Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 09:39:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02556 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 09:39:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqvRX-000030-SW for namedroppers-data@psg.com; Wed, 11 Feb 2004 14:34:23 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqvRW-00002n-Qh for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 14:34:22 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BEYHwQ025937; Wed, 11 Feb 2004 15:34:17 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.10/8.12.10/Submit) id i1BEYH81025936; Wed, 11 Feb 2004 15:34:17 +0100 (CET) (envelope-from ted) Message-Id: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 11 Feb 2004 15:34:17 +0100 In-Reply-To: ""Scott Rose"'s message as of Feb 11, 15:10" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Scott Rose" <scottr@nist.gov>, <namedroppers@ops.ietf.org> Subject: Re: trying to close Editor's Question Q-29 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting "Scott Rose", on Feb 11, 15:10, in "Re: trying to close ..."] > If one is debugging DNSSEC, it would make more sense to turn on the CD bit ... I'm not sure you have much experience with debugging or in general problemanalysis, but I have ( > 25 years ), and I know it one of the few things I'm actually good at: The very last thing one should do when analysing some strange problem is to flip a switch that changes the fundamental behaviour of the system you are analysing. The CD bit is such a switch. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 09:52:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03064 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 09:52:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqvfr-00033W-02 for namedroppers-data@psg.com; Wed, 11 Feb 2004 14:49:11 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqvfi-00030S-3o for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 14:49:02 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1BEmcjO024223 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 09:48:38 -0500 (EST) Message-ID: <006601c3f0ae$0bfaafe0$b9370681@campus.nist.gov> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> Subject: Re: trying to close Editor's Question Q-29 Date: Wed, 11 Feb 2004 09:48:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Ted Lindgreen" <ted@NLnetLabs.nl> > [Quoting "Scott Rose", on Feb 11, 15:10, in "Re: trying to close ..."] > > If one is debugging DNSSEC, it would make more sense to turn on the CD bit > .... > > I'm not sure you have much experience with debugging or in general > problemanalysis, but I have ( > 25 years ), and I know it one of the > few things I'm actually good at: > I do, surprisingly enough... At least enough not to resort to ad hominum attacks. But the CD bit is a useful bit - it returns all the security related data of the RRset without any middleboxes performing security operations. At least one could determine if a RRSIG was out of date if they have the actually RRSIG. The CD bit (if properly implemented) is like traditional DNS - no security. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 10:42:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05755 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 10:42:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqwQz-0009q1-Td for namedroppers-data@psg.com; Wed, 11 Feb 2004 15:37:53 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqwQo-0009pc-VZ for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 15:37:43 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BFbEwQ039759; Wed, 11 Feb 2004 16:37:15 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BFc8sC029411; Wed, 11 Feb 2004 16:38:08 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BFc4IK029407; Wed, 11 Feb 2004 16:38:07 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 11 Feb 2004 16:38:04 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ted Lindgreen <ted@NLnetLabs.nl> cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> Message-ID: <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 11 Feb 2004, Ted Lindgreen wrote: > The very last thing one should do when analysing some strange > problem is to flip a switch that changes the fundamental behaviour > of the system you are analysing. > > The CD bit is such a switch. The 'please-validate-expired-signature-anyway' configuration directive changes the fundamental behaviour of the system you are analysing as well. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 12:44:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11348 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 12:44:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqyKP-0002G5-92 for namedroppers-data@psg.com; Wed, 11 Feb 2004 17:39:13 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqyKO-0002Fl-D2 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 17:39:12 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i1BHb2k0013131 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 12:37:02 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAT1aqEz; Wed, 11 Feb 04 12:36:44 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i1BHbHSE016474 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 12:37:17 -0500 (EST) Date: Wed, 11 Feb 2004 12:37:17 -0500 (EST) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> Message-ID: <Pine.GSO.4.55.0402111226330.8809@filbert> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > The very last thing one should do when analysing some strange > > problem is to flip a switch that changes the fundamental behaviour > > of the system you are analysing. > > > > The CD bit is such a switch. > > The 'please-validate-expired-signature-anyway' configuration directive > changes the fundamental behaviour of the system you are analysing as well. Um, no. please-validate-... is a local directive that doesn't show up in the queries on the wire nor affect the behavior of the upstream servers EXCEPT to the extend that you might ask for different things. The CD bit can trigger vastly different upstream processing (see -protocol section 4.7), which is what Scott was suggesting (I think). -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 13:04:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11747 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 13:04:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqyeJ-0005q1-Cp for namedroppers-data@psg.com; Wed, 11 Feb 2004 17:59:47 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqye8-0005pP-CD for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 17:59:36 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BHxUwQ040408; Wed, 11 Feb 2004 18:59:32 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BI0O8h031322; Wed, 11 Feb 2004 19:00:24 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BI0NT2031319; Wed, 11 Feb 2004 19:00:24 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 11 Feb 2004 19:00:23 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Samuel Weiler <weiler@tislabs.com> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <Pine.GSO.4.55.0402111226330.8809@filbert> Message-ID: <Pine.LNX.4.58.0402111854330.25699@elektron.atoom.net> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> <Pine.GSO.4.55.0402111226330.8809@filbert> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 11 Feb 2004, Samuel Weiler wrote: > > > The very last thing one should do when analysing some strange > > > problem is to flip a switch that changes the fundamental behaviour > > > of the system you are analysing. > > > > > > The CD bit is such a switch. > > > > The 'please-validate-expired-signature-anyway' configuration directive > > changes the fundamental behaviour of the system you are analysing as well. > > Um, no. please-validate-... is a local directive that doesn't show up > in the queries on the wire nor affect the behavior of the upstream > servers EXCEPT to the extend that you might ask for different things. > The CD bit can trigger vastly different upstream processing (see > -protocol section 4.7), which is what Scott was suggesting (I think). Samuel, I did not argue that the changes in the fundamental behaviour of the system were exactly the same. I argued that using the local directive (flipping the boolean directive between TRUE/FALSE) changes the fundamental behaviour of the system as well. Concur ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 14:43:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16904 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 14:43:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar0CT-000JYZ-Ow for namedroppers-data@psg.com; Wed, 11 Feb 2004 19:39:09 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar0CC-000JXa-K8 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 19:38:52 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1BJcfjO018350 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 14:38:41 -0500 (EST) Message-ID: <007b01c3f0d6$908a34b0$b9370681@campus.nist.gov> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> <Pine.GSO.4.55.0402111226330.8809@filbert> Subject: Re: trying to close Editor's Question Q-29 Date: Wed, 11 Feb 2004 14:38:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Samuel Weiler" <weiler@tislabs.com> > > > The very last thing one should do when analysing some strange > > > problem is to flip a switch that changes the fundamental behaviour > > > of the system you are analysing. > > > > > > The CD bit is such a switch. > > > > The 'please-validate-expired-signature-anyway' configuration directive > > changes the fundamental behaviour of the system you are analysing as well. > > Um, no. please-validate-... is a local directive that doesn't show up > in the queries on the wire nor affect the behavior of the upstream > servers EXCEPT to the extend that you might ask for different things. > The CD bit can trigger vastly different upstream processing (see > -protocol section 4.7), which is what Scott was suggesting (I think). Yes, I may not have be clear enough. Turning on the CD bit does change processing behavior, but also helps isolate DNSSEC behavior. Similar to turning off DNSSEC (but not quite totally turning it off). Having a set default case (always rejecting out of date signatues) can be detected as a bug using queries with the CD bit set. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 17:42:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05279 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 17:42:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar30S-000FJY-1G for namedroppers-data@psg.com; Wed, 11 Feb 2004 22:38:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Ar30O-000FIp-Uj for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 22:38:53 +0000 Received: (qmail 37107 invoked from network); 11 Feb 2004 22:54:46 -0000 Received: from h219-110-033-104.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.104) by necom830.hpcl.titech.ac.jp with SMTP; 11 Feb 2004 22:54:46 -0000 Message-ID: <402AAF5F.70501@necom830.hpcl.titech.ac.jp> Date: Thu, 12 Feb 2004 07:40:31 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Ted Lindgreen <ted@NLnetLabs.nl> CC: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 References: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> In-Reply-To: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted Lindgreen wrote: >>I think a definition of "small" will be needed. How about using the same >>fudge factor TSIG allows for skewed clocks? > Roy pointed out that there is no need for fudge, as (other than > with TSIG) one can (and should) use overlapping periods. Wrong. There must be a system wide requirement on the minimum overlapping periods for rollover. The period is also applicable to make expiration of some data certain. That is, source of data must be aware that data is valid even after cryptographic expiration for the maximum allowable clock error of source and clients.. Another point related to expiration is that time source must be secure, that is, is locally reliable source or from remote reliable source with cryptographic security. While actual mechanism is variable, it is important to explicitly outlaw such behavior as just accepting GPS derived time. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 09:51:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25680 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 09:51:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArI4E-000JHF-Dv for namedroppers-data@psg.com; Thu, 12 Feb 2004 14:43:50 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArI4D-000JH3-0L for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 14:43:49 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1CEhjwQ064382 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 15:43:45 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1CEijqK018740 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 15:44:45 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1CEijeg018739 for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 15:44:45 +0100 Date: Thu, 12 Feb 2004 15:44:44 +0100 From: Miek Gieben <miekg@atoom.net> To: namedroppers <namedroppers@ops.ietf.org> Subject: draft: resolver-application interface Message-ID: <20040212144444.GA18697@atoom.net> Mail-Followup-To: namedroppers <namedroppers@ops.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, During the LCWS workshop of a few weeks ago the topic was also discussed: what does an application wants/needs to know from a secure aware resolver. I then said I was working on a draft trying to initiate and focus that discussion. During the last few days this topic has also (sort of) sprung up on the namedroppers ML. I'm not sure the draft is dnsop or dnsext material, but I'm posting it here as I feel we were already discussing these sort of things. It is still a *very rough* draft, but I didn't want it to delay any more than it already has. Authors: Gilles Guette, Olivier Courtay and Miek Gieben Abstract: This document describes an interface between a DNSSEC aware resolver and an application. This interface will define which kind of information a DNSSEC aware resolver is able to send back to an application. The basic question we want to answer is: "What does an application wants to know from a secure aware resolver?". In section Section 4 we define an error bit array. The secure aware resolver will set specific bits in the array. With the added information in this error array, the application can have extra control on what to do with bogus data. This document is written in the hope that it will lead to a discussion within the IETF on the resolver-application interaction(s). Where: http://www.nlnetlabs.nl/dnssec/draft-gieben-resolver.txt grtz Miek -- ...all white space is equivalent except in certain situations... - C99 Standard -- http://www.vmunix.com/~gabor/c/draft.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 10:36:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28588 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 10:36:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArIny-000Pye-V1 for namedroppers-data@psg.com; Thu, 12 Feb 2004 15:31:06 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArInq-000Py2-1k for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 15:30:58 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i1CFUgx26094; Thu, 12 Feb 2004 07:30:42 -0800 From: bill <bmanning@karoshi.com> Message-Id: <200402121530.i1CFUgx26094@karoshi.com> Subject: Re: draft: resolver-application interface To: miekg@atoom.net (Miek Gieben) Date: Thu, 12 Feb 2004 07:30:42 -0800 (PST) Cc: namedroppers@ops.ietf.org (namedroppers) In-Reply-To: <20040212144444.GA18697@atoom.net> from "Miek Gieben" at Feb 12, 2004 03:44:44 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit thanks. there was an old thread on this topic that Michael Richardson and myself (with some others) worked on last year. After the LCWS ws, i promised myself to dig it back up... looks like you beat me to it. :) > > Hello, > > During the LCWS workshop of a few weeks ago the topic was also discussed: what > does an application wants/needs to know from a secure aware resolver. I then > said I was working on a draft trying to initiate and focus that discussion. > > During the last few days this topic has also (sort of) sprung up on the > namedroppers ML. I'm not sure the draft is dnsop or dnsext material, but > I'm posting it here as I feel we were already discussing these sort of > things. > > It is still a *very rough* draft, but I didn't want it to delay any more > than it already has. > > Authors: > Gilles Guette, Olivier Courtay and Miek Gieben > > Abstract: > This document describes an interface between a DNSSEC aware resolver > and an application. This interface will define which kind of > information a DNSSEC aware resolver is able to send back to an > application. The basic question we want to answer is: "What does an > application wants to know from a secure aware resolver?". > > In section Section 4 we define an error bit array. The secure aware > resolver will set specific bits in the array. With the added > information in this error array, the application can have extra > control on what to do with bogus data. > > This document is written in the hope that it will lead to a > discussion within the IETF on the resolver-application > interaction(s). > > Where: > http://www.nlnetlabs.nl/dnssec/draft-gieben-resolver.txt > > > grtz > Miek > -- > ...all white space is equivalent except in certain situations... > - C99 Standard -- http://www.vmunix.com/~gabor/c/draft.html > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 11:37:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01594 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 11:37:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArJmK-0006g3-Pu for namedroppers-data@psg.com; Thu, 12 Feb 2004 16:33:28 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArJmJ-0006fq-PA for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 16:33:27 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 587C056871 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 08:33:26 -0800 (PST) Message-Id: <6.0.1.1.2.20040212105743.03479b10@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 12 Feb 2004 11:34:04 -0500 To: <namedroppers@ops.ietf.org> From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <007b01c3f0d6$908a34b0$b9370681@campus.nist.gov> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> <Pine.GSO.4.55.0402111226330.8809@filbert> <007b01c3f0d6$908a34b0$b9370681@campus.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Religion has intruded a bit on both sides of the question. Let me try and recast it a bit for further discussion. In the certificate system, a time limited signature (e.g. validAfter, validBefore in a certificate) means something like "I'm willing to own up to the use of this certificate during this time range. If you try and rely on signatures made by the owner of this certificate outside this time range you do so at your own risk and they might not stand up to third party validation". In the DNS system, there's a question as to what we mean by the time limits on the signature. If you get one (RRSIG) after its time by a substantial amount (e.g. 5 days) it probably means a replay, or maybe bad clock synchronization. If you get one after its time by a small amount (e.g. 5 minutes), it might mean the zone administrator is lazy, but its less likely that someone's trying to replay the data. I think a time limit signature on the data says that "This data is valid for the time specified. If you get an out of time signature, the data is no better (and no worse?) than if I hadn't signed it." Given that its local policy as to whether or not to accept unsigned data (e.g. bogus or indeterminate), its probably also local policy to make this determination based on what the clock says. Roy et al - I actually tend to agree with you, but more because I think there are way too many knobs here. If I had a more security aware stub resolver I think the right answer is that the application decides whether or not it requires signed data and whether or not it accepts bogus (see my specific definitions in previous email), unsecure or indeterminate data. In the final analysis, its the consumer who gets to decide what use to make of the data it receives. All that being said - let me trot out the language I provided previously slightly modified: A resolver [MAY | SHOULD NOT] be configurable as to whether to accept records that are invalid as to time. If configurable, the resolver SHOULD be configurable to as to the maximum out of date invalid records can be to be acceptable and MUST default to not accepting expired records. If the resolver is not configurable it MUST NOT accept expired records. If we use "SHOULD NOT" as opposed to "MAY" in the above, we can say " you can do this, but the WG generally thinks its a bad idea". There are some other clauses that could be added above: a) The resolver [SHOULD NOT | MUST NOT] accept records that are not yet valid (e.g. signature validity is in the future). b) The resolver [SHOULD NOT | MUST NOT] accept records that are more than [1 day] expired. My recommendations would be to use "SHOULD NOT" in the main clause, and add clause a) as a SHOULD NOT. Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 12:43:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04030 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 12:43:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArKon-000GD5-E7 for namedroppers-data@psg.com; Thu, 12 Feb 2004 17:40:05 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArKoh-000GBp-4A for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 17:39:59 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1CHdkwQ065364; Thu, 12 Feb 2004 18:39:48 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1CHel3p020998; Thu, 12 Feb 2004 18:40:47 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1CHekp8020995; Thu, 12 Feb 2004 18:40:47 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 12 Feb 2004 18:40:46 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Mike StJohns <Mike.StJohns@nominum.com> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <6.0.1.1.2.20040212105743.03479b10@localhost> Message-ID: <Pine.LNX.4.58.0402121747010.16845@elektron.atoom.net> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> <Pine.GSO.4.55.0402111226330.8809@filbert> <007b01c3f0d6$908a34b0$b9370681@campus.nist.gov> <6.0.1.1.2.20040212105743.03479b10@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mike, Thanks for your words, comments inline... On Thu, 12 Feb 2004, Mike StJohns wrote: > Religion has intruded a bit on both sides of the question. Let me try and > recast it a bit for further discussion. > > In the certificate system, a time limited signature (e.g. validAfter, > validBefore in a certificate) means something like "I'm willing to own up > to the use of this certificate during this time range. If you try and rely > on signatures made by the owner of this certificate outside this time range > you do so at your own risk and they might not stand up to third party > validation". > > In the DNS system, there's a question as to what we mean by the time limits > on the signature. If you get one (RRSIG) after its time by a substantial > amount (e.g. 5 days) it probably means a replay, or maybe bad clock > synchronization. If you get one after its time by a small amount (e.g. 5 > minutes), it might mean the zone administrator is lazy, but its less likely > that someone's trying to replay the data. I think a time limit signature > on the data says that "This data is valid for the time specified. If you > get an out of time signature, the data is no better (and no worse?) than if > I hadn't signed it." Given that its local policy as to whether or not to > accept unsigned data (e.g. bogus or indeterminate), its probably also local > policy to make this determination based on what the clock says. There is a small difference. We've documented very clear what unsigned/bogus/signed data is. One can base local policy on that distinction. Accepting expired data as 'signed&valid' under terms of local policy is not good practise, while accepting expired data as unsigned is introducing something new. Have to think about that one. As you said above about the certificate system, you're on your own when trusting an expired signature that validates. That decision is fine on an end to end system. In DNS however, the validator mostly resides on a middlebox. Is that bad ? One thing we're attending to in the threat model is cache poisoning. A cache is typically a module in a recursive resolver. The same resolver where the validator might reside. > Roy et al - I actually tend to agree with you, but more because I think > there are way too many knobs here. If I had a more security aware stub > resolver I think the right answer is that the application decides whether > or not it requires signed data and whether or not it accepts bogus (see my > specific definitions in previous email), unsecure or indeterminate > data. In the final analysis, its the consumer who gets to decide what > use to make of the data it receives. > > All that being said - let me trot out the language I provided previously > slightly modified: > > A resolver [MAY | SHOULD NOT] be configurable as to whether to accept > records that are invalid as to time. If configurable, the resolver SHOULD > be configurable to as to the maximum out of date invalid records can be to > be acceptable and MUST default to not accepting expired records. If the > resolver is not configurable it MUST NOT accept expired records. You've just introduced more knobs ;-) Anyway, I'll leave this subject for the WG to resolve. More from me will only polarise. Meanwhile we have a deadline :-/ Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 15:03:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10272 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 15:03:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArMzG-000GTB-JE for namedroppers-data@psg.com; Thu, 12 Feb 2004 19:59:02 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArMzD-000GSw-Jt for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 19:58:59 +0000 Received: from ENGILL.ogud.com (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1CJwGLO043251; Thu, 12 Feb 2004 14:58:16 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040212145139.024aad10@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 12 Feb 2004 14:58:43 -0500 To: "Scott Rose" <scottr@nist.gov>, <namedroppers@ops.ietf.org> From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <00f301c3efde$61b20260$b9370681@barnacle> References: <00f301c3efde$61b20260$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:01 2004-02-10, Scott Rose wrote: >Q-29 Resolver handling of expired RRSIGs > >So far, there doesn't seem to be a solid consensus on the following wording: > > > > > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > > checks were successful, depending on local policy". > > > > >To replace the current text that states resolvers MUST reject out of date >signatures. There is no time limit in the original question post, but the >editors would like to see some resolution before the I-D cutoff date. >Personally, I'd like it to be Fri. 13th if possible > >Please post your opinion if you haven't already. Or if you have further >comments on the text, or substitute text. Closure: At this point the chairs see a consensus for continued use of "MUST reject" wording. Olafur (acting WG dictator) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 17:15:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19369 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 17:15:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArP3B-000BJv-2X for namedroppers-data@psg.com; Thu, 12 Feb 2004 22:11:13 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArP39-000BJj-Gd for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 22:11:11 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i1CM93kP008932 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 17:09:03 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAgYaqzr; Thu, 12 Feb 04 17:08:55 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i1CM9jcp011168; Thu, 12 Feb 2004 17:09:45 -0500 (EST) Date: Thu, 12 Feb 2004 17:09:44 -0500 (EST) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <6.0.3.0.2.20040212145139.024aad10@localhost> Message-ID: <Pine.GSO.4.55.0402121705540.8069@filbert> References: <00f301c3efde$61b20260$b9370681@barnacle> <6.0.3.0.2.20040212145139.024aad10@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by filbert.tislabs.com id i1CM9jcp011168 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Thu, 12 Feb 2004, [iso-8859-1] =D3lafur Gudmundsson/DNSEXT co-chair wr= ote: > At this point the chairs see a consensus for continued use of > "MUST reject" wording. (A very rough consensus, perhaps?) Given the pending Q-28, I'm presuming that this will be "must treat as bogus" or somesuch, right? I'm surprised that those opposing this change aren't also objecting to the Q-28 proposal. The way I understand it, the Q-28 language assigns all validation results to one of several states and then suggests how the validator handle those by default. If 2119 language were in use, those suggestions would be SHOULDs. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 17:33:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20382 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 17:33:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArPMB-000EDm-Tg for namedroppers-data@psg.com; Thu, 12 Feb 2004 22:30:51 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1ArPMA-000EDa-PL for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 22:30:51 +0000 Received: (qmail 43148 invoked from network); 12 Feb 2004 22:47:02 -0000 Received: from h219-110-032-104.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.104) by necom830.hpcl.titech.ac.jp with SMTP; 12 Feb 2004 22:47:02 -0000 Message-ID: <402BFF01.5040707@necom830.hpcl.titech.ac.jp> Date: Fri, 13 Feb 2004 07:32:33 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: roy@dnss.ec CC: Mike StJohns <Mike.StJohns@nominum.com>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> <Pine.GSO.4.55.0402111226330.8809@filbert> <007b01c3f0d6$908a34b0$b9370681@campus.nist.gov> <6.0.1.1.2.20040212105743.03479b10@localhost> <Pine.LNX.4.58.0402121747010.16845@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0402121747010.16845@elektron.atoom.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit roy@dnss.ec wrote: >>I hadn't signed it." Given that its local policy as to whether or not to >>accept unsigned data (e.g. bogus or indeterminate), its probably also local >>policy to make this determination based on what the clock says. > There is a small difference. We've documented very clear what > unsigned/bogus/signed data is. One can base local policy on that > distinction. A problem is that "local" is not defined very clearly. Clock accuracy is a host local issue. Required strength for authentication is an application local issue. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 18:41:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24671 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 18:41:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArQO8-0001W6-Pw for namedroppers-data@psg.com; Thu, 12 Feb 2004 23:36:56 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArQO5-0001Vl-AS for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 23:36:53 +0000 Received: from sandelman.ottawa.on.ca (wlan237.sandelman.ca [205.150.200.237] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i1CNakw02597 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 18:36:52 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1CNak2r010060 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 18:36:46 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1CNahJe010056 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 18:36:46 -0500 To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-reply-to: Your message of "Thu, 12 Feb 2004 11:34:04 EST." <6.0.1.1.2.20040212105743.03479b10@localhost> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 12 Feb 2004 18:36:43 -0500 Message-ID: <10055.1076629003@marajade.sandelman.ottawa.on.ca> From: Michael Richardson <mcr@sandelman.ottawa.on.ca> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- {a big long thread on this, most of which I have ignored} >>>>> "Mike" == Mike StJohns <Mike.StJohns@nominum.com> writes: Mike> Roy et al - I actually tend to agree with you, but more because I Mike> think there are way too many knobs here. If I had a more security Mike> aware stub resolver I think the right answer is that the Mike> application decides whether or not it requires signed data and Mike> whether or not it accepts bogus (see my specific definitions in Mike> previous email), unsecure or indeterminate data. In the final Mike> analysis, its the consumer who gets to decide what use to make of Mike> the data it receives. Yes, the consumer of the data is key. Forget about whether or not the application knows how to make a decision. The application needs to be provided with the data such that it can at least, log/audit the decision that was made. *Any policy is okay*, so long as the reason for the failure is clearly explained. This is actually more critical than the other details - if the settings are wrong, or a resign is missed, or a replay is suspected, or whatever, then the human system gets feedback, and something gets fixed. Right now, we get SERVFAIL. That's why the decisions are so hard to discuss and get right. You can not fix this problem by more server policies. Miek's document is a nice start - but the view has to start with what information the application needs to *audit* requests which do *not* fail. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQCwOCoqHRg3pndX9AQHhxQP9GIS2BSVsCh7yqhjCct6cAZ06wmkWuZdT 4YpqtQCIE7VnW6x184mILQLEqCExLo5b9m/6ePPxfuEx8ubKFasVzKexrqj4LTdv xZTAIM862Hob0UtuEI5rDvQmR5lOQFHQxB6sJrlo8rZioRUzyTT0GctElAfnO0DS 4F2VLPIRDb4= =UzyC -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From xudpress_release@hotmail.com Thu Feb 12 19:11:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26722 for <dnsext-archive@ietf.org>; Thu, 12 Feb 2004 19:11:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQvA-0000Hm-00 for dnsext-archive@ietf.org; Thu, 12 Feb 2004 19:11:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQt9-0007Zi-00 for dnsext-archive@ietf.org; Thu, 12 Feb 2004 19:09:01 -0500 Received: from [218.12.34.234] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1ArQqm-0006dT-00; Thu, 12 Feb 2004 19:06:33 -0500 From: "Atualidade Brasileira . dql" <xudpress_release@hotmail.com> To: disman-archive@ietf.org Subject: Lindenberg e a "demoniza��o" da livre iniciativa ref.: aic X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: <E1ArQqm-0006dT-00@ietf-mx> Date: Thu, 12 Feb 2004 19:06:33 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.2 required=5.0 tests=AWL,FORGED_MUA_EUDORA, HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE,MAILTO_SUBJ_REMOVE, MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora * 0.0 AWL AWL: Auto-whitelist adjustment <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252"> <META NAME="Generator" CONTENT="Microsoft Word 97"> <META NAME="Template" CONTENT="C:\Arquivos de programas\Microsoft Office\Office\html.dot"> </HEAD> <BODY LINK="#0000ff" VLINK="#800080"> (xyf) <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:EnEspañol">Lindenberg:EnEspañol </A>- <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:InEnglish(LinkToFreeTranslator">English:LinkToFreeTranslator</A> Série Temas Patrulhados (3) Lindenberg e a "demonização" da livre iniciativa "Muito embora capitalismo, globalização, neoliberalismo, privatizações, propriedade privada etc. não se identifiquem necessáriamente, eles são vistos pelos herdeiros das idéias marxistas como as quatro bestas do Apocalipse" Viés * Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", onde denuncia uma política com viés esquerdista que visa censurar, marginalizar ou encobrir com um manto de silêncio, notícias, opiniões e livros "politicamente incorretos", não afinados com as assim denominadas "causas sociais" inspiradas na teologia da libertação e nos Fórums Sociais: os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados". "As quatro bestas do Apocalipse"? * Em artigo "Capitalismo, globalização, neoliberalismo, privatizações", da Série Temas Patrulhados, Lindenberg constata que muito embora capitalismo, globalização, neoliberalismo, privatizações, propriedade privada etc. não se identifiquem necessáriamente, têm, no entanto, um denominador comum: são vistos pelos progressistas e pelos herdeiros das idéias marxistas como "as quatro bestas do Apocalipse". Com efeito, essas pessoas, sem terem condições de apregoar as benesses do socialismo - por causa dos contrastes gritantes das economias livres versus economias estatizadas, e do fracasso estrondoso destas ultimas - denunciam de maneira generalizada as políticas de austeridade, as multinacionais e as privatizações dos serviços públicos, como sendo as responsáveis pelo crescimento dos bolsões de miséria, estagnação econômica e concentração da renda. Bom senso * Em seu artigo "Capitalismo, globalização, neoliberalismo, privatizações", Lindenberg usa o bom senso e uma linguagem acessível para recolocar as idéias em sua justa ordem. Seguem alguns temas abordados no artigo, que o leitor receberá gratuitamente por e-mail, na íntegra, simplesmente clicando em: <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:EsteArtigoGratuitamente(3) ">EsteArtigoGratuitamente(3)</A> . - Os ideais da livre empresa e da economia de mercado, e o direito de propriedade segundo os ensinamentos tradicionais da Igreja. - A ordem socioeconômica cristã personalizada e orgânica, isto é, uma ordem na qual a preeminência deve ser dada às famílias e às sociedades intermediárias, e não ao Estado. - As campanhas de descrédito contra a propriedade privada. - A verdade sobre o chamado "capitalismo selvagem". . Em que consiste o capitalismo popular ou democrático. . A viga mestre do progresso econômico cristão. . O contraste entre os padrões de vida e de assistência social dos países livres, e dos países com economias estatizantes. Links para receber e-Book e artigos gratuitos <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:e-BookGratuito">Lindenberg:e-BookGratuito</A> (em formato Word, com 11 artigos de Lindenberg) <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:EsteArtigoCompletoGratuitamente(No.3) ">EsteArtigoCompletoGratuitamente(No.3)</A> <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:LivroIntroduçãoGratuita">Lindenberg:LivroIntroduçãoGratuita</A> (em formato Word, Introdução do livro "Os católicos e a economia de mercado") Links de opinião Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, incluindo sua valiosa opinião: <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Concordo">Lindenberg:Concordo </A>- <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Discrepo">Lindenberg:Discrepo </A>- <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Opinião/Sugestão">Lindenberg:Opinião/Sugestão</A> <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:GratuitamenteEsteArtigo(3">Lindenberg:GratuitamenteEsteArtigo(3)</A> Link em espanhol <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:e-BookGratuito">Lindenberg:e-BookGratuitoEsp</A> (em formato Word, com 11 artigos de Lindenberg, em Espanhol) Outros links <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:DesejoAdquirirLivro">Lindenberg:DesejoAdquirirLivro</A> (receberá instruções sobre como poder adquirir o livro no Brasil e em Portugal) <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Subscrever">Lindenberg:Subscrever</A> (para receber, gratuitamente, os próximos artigos) <A HREF="mailto:construnews@yahoo.com.br?subject=ConstruNews:Remover">ConstruNews:Remover</A> (para ser retirado imediatamente de nosso Address Book). A difusão deste artigo, com a finalidade estritamente cívica e cultural de promover um debate respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. </BODY> </HTML> From owner-namedroppers@ops.ietf.org Thu Feb 12 23:27:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06839 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 23:27:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArUrM-000Hvi-9t for namedroppers-data@psg.com; Fri, 13 Feb 2004 04:23:24 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArUrL-000HvW-AB for namedroppers@ops.ietf.org; Fri, 13 Feb 2004 04:23:23 +0000 Received: from ENGILL.ogud.com (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1D4MZLO044649; Thu, 12 Feb 2004 23:22:36 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040212231103.02da4b80@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 12 Feb 2004 23:23:05 -0500 To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers. In-Reply-To: <20040128203233.08EE614C52@sa.vix.com> References: <20040128203233.08EE614C52@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 15:32 2004-01-28, Paul Vixie wrote: > > The proposed text therefore is: security aware resolvers MAY query for > > missing security RRs; implementations that choose to do so must be > > aware of the fact that the answers received may not be sufficient to > > perform validation. > >this gives no guideance to server implementors, and is therefore= inadequate. > >how about adding this text: > > security aware responders who receive queries for security RRs which > match the content of more than one zone, for example above and below > a delegation point, are encouraged to behave self-consistently, > which could mean: always return an error; always return > above-delegation records; always return below-delegation records; > always return no records; always return both above- and > below-delegation records; or always something else entirely > >in other words, driving home the point that requestor implementors ought= not >depend on the results of queries for security RRs is only part of the= story; >the document should also clearly state that there is no standard behaviour >for responders, and place a self-consistency requirement there instead. While attempting to summarize what the consensus of the working group is on this editors question and trying to interpret this block of text. Does self-consistently apply to a name or the holy Q-trinity? RFC103[45] specify NS is on both sides of delegation, and the lower one be returned to queries, does this imply NSEC should be handled the same way? For the record the affected RR types by this text are NS, NSEC, RRSIG. DS and DNSKEY are not affected as they can only be authoritative on one side of the delegation. Right now my read of the working group is that this text is an improvement over what Olaf put forth as the default result, but needs clarification on scope. =D3lafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 23:28:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06907 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 23:28:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArUv2-000Ixy-LT for namedroppers-data@psg.com; Fri, 13 Feb 2004 04:27:12 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArUv1-000Ixb-5Z for namedroppers@ops.ietf.org; Fri, 13 Feb 2004 04:27:11 +0000 Received: from ENGILL.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1D4QMLO044660; Thu, 12 Feb 2004 23:26:22 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040212232453.0287dec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 12 Feb 2004 23:26:49 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Q-24 DNSKEY with flag 7=0 not to be used with DNSSEC. Cc: Olaf Kolkman <olaf@ripe.net> In-Reply-To: <D6EDDF48-5194-11D8-AF3C-000393DA2D46@ripe.net> References: <D6EDDF48-5194-11D8-AF3C-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 08:21 2004-01-28, Olaf Kolkman wrote: >The behavior for the flag bit (bit7) in the DNSKEY RR set to 0 is not >specified. We propose the following text to be added to section 2.1: >DNSKEY RRs MUST NOT be used for DNSSEC validation if bit 7 of the flag >field is set to 0. This question is closed with the default action, Editors please add this text. =D3lafur=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 23:31:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07051 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 23:31:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArUxz-000JFs-Ch for namedroppers-data@psg.com; Fri, 13 Feb 2004 04:30:15 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArUxy-000JFE-13 for namedroppers@ops.ietf.org; Fri, 13 Feb 2004 04:30:14 +0000 Received: from ENGILL.ogud.com (ns.md.ogud.com [10.20.30.6] (may be forged)) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1D4TSLO044678; Thu, 12 Feb 2004 23:29:28 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040212232747.0289dec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 12 Feb 2004 23:29:38 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Q-25 Under specification of NSEC TTL. Cc: Olaf Kolkman <olaf@ripe.net>, dnssec-editors@east.isi.edu In-Reply-To: <F2C677D9-5194-11D8-AF3C-000393DA2D46@ripe.net> References: <F2C677D9-5194-11D8-AF3C-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 08:21 2004-01-28, Olaf Kolkman wrote: >The document does not specify the setting of the TTL on NSEC RRs. We >propose the following text to be added to 2.3 proto: In the spirit of >[RFC negative cache] the TTL of the NSEC RRset SHOULD match the TTL of >the zone SOA minimum field. There was no objection raised to this, the question is closed. Editors please add this text to protocol document. =D3lafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 23:35:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07156 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 23:35:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArV1e-000JcK-TP for namedroppers-data@psg.com; Fri, 13 Feb 2004 04:34:02 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArV1d-000Jc7-Tr for namedroppers@ops.ietf.org; Fri, 13 Feb 2004 04:34:02 +0000 Received: from ENGILL.ogud.com (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1D4XGLO044698; Thu, 12 Feb 2004 23:33:17 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040212233049.0285dec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 12 Feb 2004 23:33:47 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Q-26 Appearance of DS RRs. Cc: dnssec-editors@east.isi.edu In-Reply-To: <12F5C8A6-5195-11D8-AF3C-000393DA2D46@ripe.net> References: <12F5C8A6-5195-11D8-AF3C-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 08:22 2004-01-28, Olaf Kolkman wrote: >DS RR MUST NOT appear at non-delegation point has changed. The new >text says DS MUST NOT appear at apex (this is needed). silent on DS >appearing elsewhere. > >The reason for this change is that although it seems rather senseless >to have a DS anywhere else than with a delegation there seems no >reason to forbid the existence elsewhere This question is closed, no discussion default action is to go with new text (and overwrite RFC3658). =D3lafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 13 01:23:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10687 for <dnsext-archive@lists.ietf.org>; Fri, 13 Feb 2004 01:23:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArWgN-000FRB-0o for namedroppers-data@psg.com; Fri, 13 Feb 2004 06:20:11 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArWgC-000FPk-Bf for namedroppers@ops.ietf.org; Fri, 13 Feb 2004 06:20:00 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0CFF21396E for <namedroppers@ops.ietf.org>; Fri, 13 Feb 2004 06:20:00 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: nsec target restrictions X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 13 Feb 2004 06:20:00 +0000 Message-Id: <20040213062000.0CFF21396E@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk in the current -bis docset, nsec asserts a range of nonexistence beginning after its owner name and ending before its target name. implementors are thus free to syntax-check incoming nsec rr's requiring (target > owner). however, there appears to be no other restriction on the target ("ending") name. it doesn't have to be in-zone, or even in-ballywick. this doesn't harm the current validator in any way i can see, but it seems sloppy. if the nsec target name isn't in-ballywick for the nsec owner's zone apex, then it should be a syntax error and should cause failure to be signalled at zone loading time, and it should cause the nsec to be unusable for validation if some server decides to hand it out anyway. "ISC.ORG NSEC ... PBS.ORG" is unacceptable, unless ORG is the apex and both ISC and PBS are in-zone data for ORG. similarly "ISC.ORG NSEC ... ORG" or "ISC.ORG NSEC ... ." or "ISC.ORG NSEC ... VIX.COM". it is not possible to syntax-check the subzone case, for example if DV.ISC.ORG is a zone cut and "ISC.ORG NSEC ... WWW.DV.ISC.ORG" is seen -- simply because the existence of the DV.ISC.ORG zone cut doesn't have to be known if present, whereas the existence of an ISC.ORG zone cut does have to be known if present. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Feb 14 11:40:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23342 for <dnsext-archive@lists.ietf.org>; Sat, 14 Feb 2004 11:40:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1As2ju-000FOj-Kt for namedroppers-data@psg.com; Sat, 14 Feb 2004 16:33:58 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1As2jt-000FOO-52 for namedroppers@ops.ietf.org; Sat, 14 Feb 2004 16:33:57 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1EGX1LN054736 for <namedroppers@ops.ietf.org>; Sat, 14 Feb 2004 11:33:01 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1EGX0lY054735 for namedroppers@ops.ietf.org; Sat, 14 Feb 2004 11:33:00 -0500 (EST) Received: from [141.146.126.229] (helo=agminet02.oracle.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArOAC-0002fk-OL for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 21:14:24 +0000 Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by agminet02.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1CLAIcq019906 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 13:10:49 -0800 Received: from rgmgw6.us.oracle.com (localhost [127.0.0.1]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i1CLAI211390 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 14:10:18 -0700 (MST) Received: from oracle.com (dbrower-sun.us.oracle.com [130.35.180.64]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i1CLAH211341 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 14:10:17 -0700 (MST) Message-ID: <402BEBB8.3000700@oracle.com> Date: Thu, 12 Feb 2004 13:10:16 -0800 From: David Brower <David.Brower@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5a) Gecko/20030527 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: LLMNR and Rendezvous TTL disagreement, a modest proposal Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-White-List-Member: TRUE X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Not being religious, and only being a party that wishes to use things in this space to reduce configuration, interoperability between LLMNL and Rendezvous is important in reaching stability and critical mass. The first contentious issue seems to be the TTL field. There seem to be perfectly good arguments for each position, and I am not wise enough to say either is correct. Is it plausible to say "both are right" on this point? Have the standard say senders may set the field to either 1 or 255, and recipients should accept either value? Both seem just as good at detecting leaked packets. You may stone me now. thanks, David Brower Oracle Cluster Architecture -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Feb 14 17:34:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03275 for <dnsext-archive@lists.ietf.org>; Sat, 14 Feb 2004 17:34:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1As8Im-0004Eq-3E for namedroppers-data@psg.com; Sat, 14 Feb 2004 22:30:20 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1As8Ic-0004Cz-Od for namedroppers@ops.ietf.org; Sat, 14 Feb 2004 22:30:10 +0000 Received: (qmail 54277 invoked from network); 14 Feb 2004 22:46:58 -0000 Received: from h219-110-032-030.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.30) by necom830.hpcl.titech.ac.jp with SMTP; 14 Feb 2004 22:46:58 -0000 Message-ID: <402EA1DA.80704@necom830.hpcl.titech.ac.jp> Date: Sun, 15 Feb 2004 07:31:54 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: David Brower <David.Brower@oracle.com> CC: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <402BEBB8.3000700@oracle.com> In-Reply-To: <402BEBB8.3000700@oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Brower; > The first contentious issue seems to be the TTL field. There seem to > be perfectly good arguments for each position, and I am not wise > enough to say either is correct. Is it plausible to say "both are > right" on this point? No. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 05:34:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10119 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 05:34:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asg09-000EkF-69 for namedroppers-data@psg.com; Mon, 16 Feb 2004 10:29:21 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asg08-000Ejw-16 for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 10:29:20 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4150F18E3; Mon, 16 Feb 2004 05:29:19 -0500 (EST) Date: Mon, 16 Feb 2004 05:29:19 -0500 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: new versions of DNSSECbis drafts posted User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040216102919.4150F18E3@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Even though the DNSEXT WG will not be meeting in Seoul, the dnssec-editors just posted revised versions of the DNSSECbis drafts. Copies (and htmlwdiff output) are also available on the web at: http://www.hactrn.net/ietf/dns/dnssec-editors/ This editing cycle was a welcome change from previous go-rounds, in that, rather than receiving too little feedback, we received so much that we weren't able to integrate all of it in time for the I-D cutoff. A number of issues raised during the RIPE "last call workshop" are waiting for questions that the WG has not (quite) finished discussing. So these still aren't the final versions, but we thought it'd be useful to post what we had. Work will of course continue. Special thanks to Mark Andrews for helping us figure out the (somewhat cryptic) notes we got from the RIPE workshop. If anyone who was at the workshop and will also be in Seoul has time to sit down with the editors (or at least with me -- dunno if any of my fellow editors will be there) to help sort out remaining issues from the RIPE workshop notes, that'd be appreciated. Send mail to dnssec-editors if you're willing. Process note: workshop output has no special standing, it's just more input from WG participants as far as the editors are concerned. Any suggested protocol changes has to go the normal WG process. But most of the notes from the RIPE workshop were about editorial and document clarity issues, and on some of them we couldn't figure out whether it was us, our reviewers, or all of the above who were confused. :) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 06:18:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11696 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 06:18:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asgii-000LWb-NV for namedroppers-data@psg.com; Mon, 16 Feb 2004 11:15:24 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asgih-000LWG-RW for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 11:15:24 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 638F018DE for <namedroppers@ops.ietf.org>; Mon, 16 Feb 2004 06:15:23 -0500 (EST) Date: Mon, 16 Feb 2004 06:15:23 -0500 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: dns-threats, DNSSEC, and glue User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040216111523.638F018DE@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk <hat dnssec-editor=off just-another-bozo-on-this-bus=on> Two separate reviewers of draft-ietf-dnsext-dns-threats have raised essentially the same question over the following paragraph: DNSSEC signatures do not cover glue records, so there's still a possibility of a name-based attack involving glue, but with DNSSEC it is possible to detect the attack by temporarily accepting the glue in order to fetch the signed authoritative version of the same data, then checking the signatures on the authoritative version. Both reviewers asked, in essence, "does that mean that a security-aware resolver -will- use this defense?" The DNSSECbis drafts are silent on this issue. Should they say something about this? </hat> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 07:11:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13524 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 07:11:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AshYW-0003mr-VF for namedroppers-data@psg.com; Mon, 16 Feb 2004 12:08:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AshYT-0003ma-P4 for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 12:08:53 +0000 Received: (qmail 61906 invoked from network); 16 Feb 2004 12:26:10 -0000 Received: from h219-110-032-149.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.149) by necom830.hpcl.titech.ac.jp with SMTP; 16 Feb 2004 12:26:10 -0000 Message-ID: <4030B342.4020707@necom830.hpcl.titech.ac.jp> Date: Mon, 16 Feb 2004 21:10:42 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Rob Austein <sra@isc.org> CC: namedroppers@ops.ietf.org Subject: Re: dns-threats, DNSSEC, and glue References: <20040216111523.638F018DE@thrintun.hactrn.net> In-Reply-To: <20040216111523.638F018DE@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein wrote: > <hat dnssec-editor=off just-another-bozo-on-this-bus=on> > > Two separate reviewers of draft-ietf-dnsext-dns-threats have raised > essentially the same question over the following paragraph: > > DNSSEC signatures do not cover glue records, so there's still a > possibility of a name-based attack involving glue, but with DNSSEC it > is possible to detect the attack by temporarily accepting the glue in > order to fetch the signed authoritative version of the same data, > then checking the signatures on the authoritative version. > > Both reviewers asked, in essence, "does that mean that a > security-aware resolver -will- use this defense?" Sigh... The only defense is to use separate cache for each delegation, which has nothing to do with DNSSEC. Never use glue of some delegation or cache of it for other delegation. > The DNSSECbis drafts are silent on this issue. That's fine. > Should they say > something about this? No. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 08:31:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16270 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 08:31:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asinm-000F9r-8B for namedroppers-data@psg.com; Mon, 16 Feb 2004 13:28:46 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asink-000F9f-WB for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 13:28:45 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1GDRXLN062908 for <namedroppers@ops.ietf.org>; Mon, 16 Feb 2004 08:27:33 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1GDRX5H062907 for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 08:27:33 -0500 (EST) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsOWH-000FGx-Oz for namedroppers@ops.ietf.org; Sun, 15 Feb 2004 15:49:21 +0000 Received: from [10.0.1.3] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 48E641B205C; Sun, 15 Feb 2004 09:37:22 -0600 (CST) In-Reply-To: <402BEBB8.3000700@oracle.com> References: <402BEBB8.3000700@oracle.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7D97199C-5FCE-11D8-BF19-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sun, 15 Feb 2004 10:49:08 -0500 To: David Brower <David.Brower@oracle.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Feb 12, 2004, at 4:10 PM, David Brower wrote: > The first contentious issue seems to be the TTL field. There seem to > be perfectly good arguments for each position, and I am not wise > enough to say either is correct. Is it plausible to say "both are > right" on this point? Have the standard say senders may set the field > to either 1 or 255, and recipients should accept either value? Both > seem just as good at detecting leaked packets. The reason we can't just do this is that the standard that was agreed upon requires that if you get a packet with a TTL that's not 255, you have to drop it. This is the standard Rendezvous adopted, because the WG consensus at the time was that this was the right thing to do. Subsequently the consensus of the WG changed, and the current consensus is incompatible with the old consensus. At this point whenever this comes up, everybody clams up, with the exception of a swift rejoinder from the "can't change the meaning of TTL" crowd, and perhaps a quick (perhaps completely inaccurate!) explanation of the situation from me. I do not think that there is consensus that we should change the meaning of TTL in LLMNR packets to be compatible with Rendezvous, but there also isn't consensus that we should not. And so we all kind of act embarrassed when the question comes up, and I suspect that the end result will be a lack of interoperability, because the consensus seems to have been called already. :'} -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 12:07:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05891 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 12:07:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asm9z-000B1U-9z for namedroppers-data@psg.com; Mon, 16 Feb 2004 17:03:55 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asm9w-000B1C-Jr for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 17:03:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6B48D14C4E for <namedroppers@ops.ietf.org>; Mon, 16 Feb 2004 17:03:51 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: Message from Ted Lemon <mellon@fugue.com> of "Sun, 15 Feb 2004 10:49:08 EST." <7D97199C-5FCE-11D8-BF19-000A95D9C74C@fugue.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 16 Feb 2004 17:03:51 +0000 Message-Id: <20040216170351.6B48D14C4E@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [...] The reason we can't just do this is that the standard that was > agreed upon requires that if you get a packet with a TTL that's not > 255, you have to drop it. This is the standard Rendezvous adopted, > because the WG consensus at the time was that this was the right thing > to do. Subsequently the consensus of the WG changed, and the current > consensus is incompatible with the old consensus. [...] I think there are two topics on which consensus would be valuable and useful but which for the moment are impossible to gauge. Above, Ted makes reference to the old "1 vs 255" thing. Others here have shown that one choice assures correct behaviour by initiators, the other by responders, and that either choice is useful, perhaps equally so. At this point we could flip a coin to decide, and the consensus would surely be, "wow we sure are glad that some kind of decision got made." The second point on which consensus is unclear is actually much more important, and that's "should we allow Apple to legislate standards using the force of their installed base?" Apparently there's some concern that Apple is acting like a bully here. I've also heard of suspicions that Microsoft's big reason for pushing LLMNR is to wipe out Apple's early lead in this market. What we (as IETF "members") have to decide isn't "who should win this fight?" but rather "what's the best engineering solution?" In other words no arguments based on the existence of an installed base, whether for or against, should be taken into account. If the best solution happens to be what Apple did then we should write it that way. If the best solution happens to be what Apple didn't do then we should write it THAT way. But wait, I have a proposal. Given the following three facts... (1) 1 and 255 have about equal usefulness but protect different endpoints (2) apple only chose as they did because of apparent consensus "back then" (3) consensus since then seems to have drifted back into vagueness ...that we give Apple's solution the nod based simply on operational experience with a solution that has already been randomly chosen. -------- But there's still the larger question of "why LLMNR?" If the WG isn't going to advance LLMNR while it remains incompatible with Rendezvous, then why doesn't the WG just advance Rendezvous? Clearly, being early isn't always an advantage. But does it always have to be a disadvantage? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 15:38:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19424 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 15:38:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AspRK-000OZD-42 for namedroppers-data@psg.com; Mon, 16 Feb 2004 20:34:02 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AspRI-000OZ0-2p for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 20:34:00 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18534; Mon, 16 Feb 2004 15:33:57 -0500 (EST) Message-Id: <200402162033.PAA18534@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tkey-renewal-mode-04.txt Date: Mon, 16 Feb 2004 15:33:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : TKEY Secret Key Renewal Mode Author(s) : Y. Kamite, M. Nakayama Filename : draft-ietf-dnsext-tkey-renewal-mode-04.txt Pages : 22 Date : 2004-2-16 This document defines a new mode in TKEY [RFC2930] and proposes an atomic method for changing secret keys used for TSIG [RFC2845] periodically. Originally, TKEY provides methods of setting up shared secrets other than manual exchange, but it cannot control timing of key renewal very well though it can add or delete shared keys separately. This proposal is a systematical key renewal procedure intended for preventing signing DNS messages with old and non-safe keys permanently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-04.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-ietf-dnsext-tkey-renewal-mode-04.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-16121515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tkey-renewal-mode-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16121515.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 16:13:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25320 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 16:13:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asq0U-0003xz-7W for namedroppers-data@psg.com; Mon, 16 Feb 2004 21:10:22 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asq0S-0003xn-W0 for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 21:10:21 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i1GL8AA1013836 for <namedroppers@ops.ietf.org>; Mon, 16 Feb 2004 16:08:10 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXkaa_A; Mon, 16 Feb 04 16:07:59 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i1GL8nlJ012935; Mon, 16 Feb 2004 16:08:49 -0500 (EST) Date: Mon, 16 Feb 2004 16:08:49 -0500 (EST) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: Rob Austein <sra@isc.org> cc: namedroppers@ops.ietf.org Subject: Re: dns-threats, DNSSEC, and glue In-Reply-To: <20040216111523.638F018DE@thrintun.hactrn.net> Message-ID: <Pine.GSO.4.55.0402161550470.11768@filbert> References: <20040216111523.638F018DE@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > DNSSEC signatures do not cover glue records, so there's still a > possibility of a name-based attack involving glue, but with DNSSEC it > is possible to detect the attack by temporarily accepting the glue in > order to fetch the signed authoritative version of the same data, > then checking the signatures on the authoritative version. > > Both reviewers asked, in essence, "does that mean that a > security-aware resolver -will- use this defense?" > > The DNSSECbis drafts are silent on this issue. Should they say > something about this? No, DNSSECbis should neither mandate using this defense nor prohibit using it. Reasoning: 1) So long as the rest of the zone's data passes validation, the essential service provided by DNSSEC (data authentication) is intact. 2) If an attacker substitutes nameservers that don't answer, the resolver is left with no documented mechanism to find working nameservers. It doesn't make much sense to tell resolvers to do this check when they have no fallback. But such mechanisms are likely to be developed in the future, which is why we shouldn't prohibit this sort of checking, 3) Unless we care about query confidentiality. At attacker could redirect queries to itself, then answer with real signed zone data. The benefit? The attacker sees the queries. Without doing the check, resolvers don't know this is going on. If we claimed that DNSSEC offered any confidentiality protection, this might be worth looking at in more depth. (intro-08 reminds readers at least three times that DNSSEC does not provide confidentiality protection.) -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 18:50:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12576 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 18:50:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AssRP-000Ig9-2v for namedroppers-data@psg.com; Mon, 16 Feb 2004 23:46:19 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AssRN-000Ifw-UI for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 23:46:18 +0000 Received: (qmail 64227 invoked from network); 17 Feb 2004 00:03:43 -0000 Received: from h219-110-032-140.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.140) by necom830.hpcl.titech.ac.jp with SMTP; 17 Feb 2004 00:03:43 -0000 Message-ID: <403156B6.1020807@necom830.hpcl.titech.ac.jp> Date: Tue, 17 Feb 2004 08:48:06 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> CC: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <20040216170351.6B48D14C4E@sa.vix.com> In-Reply-To: <20040216170351.6B48D14C4E@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul; > (1) 1 and 255 have about equal usefulness but protect different endpoints IETF concern is to pretect the network, to which both Apple and Microsoft are indifferent. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 12:29:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19791 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 12:29:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1At8vo-000H9S-88 for namedroppers-data@psg.com; Tue, 17 Feb 2004 17:22:48 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1At8vj-000H96-6Q for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 17:22:43 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i1HHMd1o028837; Tue, 17 Feb 2004 12:22:39 -0500 To: Samuel Weiler <weiler@tislabs.com> Cc: Rob Austein <sra@isc.org>, namedroppers@ops.ietf.org Subject: Re: dns-threats, DNSSEC, and glue References: <20040216111523.638F018DE@thrintun.hactrn.net> <Pine.GSO.4.55.0402161550470.11768@filbert> From: Derek Atkins <derek@ihtfp.com> Date: Tue, 17 Feb 2004 12:22:39 -0500 In-Reply-To: <Pine.GSO.4.55.0402161550470.11768@filbert> (Samuel Weiler's message of "Mon, 16 Feb 2004 16:08:49 -0500 (EST)") Message-ID: <sjmbrnx39k0.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler <weiler@tislabs.com> writes: >> DNSSEC signatures do not cover glue records, so there's still a >> possibility of a name-based attack involving glue, but with DNSSEC it >> is possible to detect the attack by temporarily accepting the glue in >> order to fetch the signed authoritative version of the same data, >> then checking the signatures on the authoritative version. >> >> Both reviewers asked, in essence, "does that mean that a >> security-aware resolver -will- use this defense?" >> >> The DNSSECbis drafts are silent on this issue. Should they say >> something about this? > > No, DNSSECbis should neither mandate using this defense nor prohibit > using it. But should DNSSECbis _mention_ this defense as a potential means to thwart the attack? Sure, it doesn't have to mandate it, nor should it prohibit, but should it at least be mentioned? Or should we expect resolver implementers to have read the threats document as well as DNSSECbis? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 13:16:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23570 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 13:16:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1At9iw-000NFI-UG for namedroppers-data@psg.com; Tue, 17 Feb 2004 18:13:34 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1At9iu-000NF0-Me for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 18:13:32 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1HICujO029834 for <namedroppers@ops.ietf.org>; Tue, 17 Feb 2004 13:12:56 -0500 (EST) Message-ID: <024701c3f581$80f9b2a0$b9370681@campus.nist.gov> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <20040216111523.638F018DE@thrintun.hactrn.net><Pine.GSO.4.55.0402161550470.11768@filbert> <sjmbrnx39k0.fsf@dogbert.ihtfp.org> Subject: Re: dns-threats, DNSSEC, and glue Date: Tue, 17 Feb 2004 13:11:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Derek Atkins" <derek@ihtfp.com> > Samuel Weiler <weiler@tislabs.com> writes: > > >> DNSSEC signatures do not cover glue records, so there's still a > >> possibility of a name-based attack involving glue, but with DNSSEC it > >> is possible to detect the attack by temporarily accepting the glue in > >> order to fetch the signed authoritative version of the same data, > >> then checking the signatures on the authoritative version. > >> > >> Both reviewers asked, in essence, "does that mean that a > >> security-aware resolver -will- use this defense?" > >> > >> The DNSSECbis drafts are silent on this issue. Should they say > >> something about this? > > > > No, DNSSECbis should neither mandate using this defense nor prohibit > > using it. > > But should DNSSECbis _mention_ this defense as a potential means to > thwart the attack? Sure, it doesn't have to mandate it, nor should it > prohibit, but should it at least be mentioned? Or should we expect > resolver implementers to have read the threats document as well as > DNSSECbis? > Maybe drop the defense suggestion (to avoid it sounding like a mandate), and adding a more explicit reference to the threat document? Trying to reach a compromise - I agree that the DNSSECbis drafts shouldn't be making suggestions on things if they are not part of the spec. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 16:40:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07817 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 16:40:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtCtj-000LiX-6B for namedroppers-data@psg.com; Tue, 17 Feb 2004 21:36:55 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtCtd-000Li4-PA for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 21:36:49 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07414; Tue, 17 Feb 2004 16:36:47 -0500 (EST) Message-Id: <200402172136.QAA07414@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-05.txt Date: Tue, 17 Feb 2004 16:36:46 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends Filename : draft-ietf-dnsext-dnssec-protocol-05.txt Pages : 58 Date : 2004-2-17 This document is part of a family of documents which describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-05.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-ietf-dnsext-dnssec-protocol-05.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-17165300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17165300.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 16:40:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07852 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 16:40:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtCtk-000Lim-Sq for namedroppers-data@psg.com; Tue, 17 Feb 2004 21:36:56 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtCtj-000Lia-Qe for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 21:36:55 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07427; Tue, 17 Feb 2004 16:36:53 -0500 (EST) Message-Id: <200402172136.QAA07427@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-07.txt Date: Tue, 17 Feb 2004 16:36:53 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Resource Records for the DNS Security Extensions Author(s) : R. Arends Filename : draft-ietf-dnsext-dnssec-records-07.txt Pages : 37 Date : 2004-2-17 This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existance (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-07.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-ietf-dnsext-dnssec-records-07.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-07.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-17165325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17165325.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 17:07:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11015 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 17:07:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtDKD-000Pfx-L8 for namedroppers-data@psg.com; Tue, 17 Feb 2004 22:04:17 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtDK9-000PbS-2c for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 22:04:13 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1HM2oLN069223 for <namedroppers@ops.ietf.org>; Tue, 17 Feb 2004 17:02:50 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1HM2oYT069222 for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 17:02:50 -0500 (EST) Received: from [203.51.31.177] (helo=cuneata.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1At1E8-000N48-Ba for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 09:09:12 +0000 Received: (qmail 4144 invoked from network); 17 Feb 2004 17:11:38 -0000 Received: from pc-00216.cuneata.net (HELO rachel) (192.168.0.216) by squirt.cuneata.net (192.168.0.1) with ESMTP; 17 Feb 2004 17:11:38 -0000 From: Brad Hards <bradh@frogmouth.net> To: Paul Vixie <paul@vix.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 17 Feb 2004 20:09:02 +1100 User-Agent: KMail/1.6.51 Cc: namedroppers@ops.ietf.org References: <20040216170351.6B48D14C4E@sa.vix.com> In-Reply-To: <20040216170351.6B48D14C4E@sa.vix.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_yodMA6x9wCGOmTU"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402172009.06027.bradh@frogmouth.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] --Boundary-02=_yodMA6x9wCGOmTU Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 17 Feb 2004 04:03 am, Paul Vixie wrote: > But wait, I have a proposal. Given the following three facts... > > (1) 1 and 255 have about equal usefulness but protect different > endpoints (2) apple only chose as they did because of apparent consensus > "back then" (3) consensus since then seems to have drifted back into > vagueness > > ...that we give Apple's solution the nod based simply on operational > experience with a solution that has already been randomly chosen. I suggest that we make it "MUST (or SHOULD) send at 255, MAY bother to chec= k"=20 as the path to least gratuitous breakage. Brd --Boundary-02=_yodMA6x9wCGOmTU Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBAMdoyGwwszQ/PZzgRAtPcAKCc/3IT3eqZz4YkzFQcHpAv9xJN+gCfRO6a JrcjiJIFa8PTjZXsdMOwrGI= =rl1V -----END PGP SIGNATURE----- --Boundary-02=_yodMA6x9wCGOmTU-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 17:08:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11067 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 17:08:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtDK9-000Pdc-VZ for namedroppers-data@psg.com; Tue, 17 Feb 2004 22:04:13 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtDK5-000Pav-4j for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 22:04:09 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1HM2kLN069218 for <namedroppers@ops.ietf.org>; Tue, 17 Feb 2004 17:02:46 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1HM2ktm069217 for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 17:02:46 -0500 (EST) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsqEe-00057D-Fe for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 21:25:00 +0000 Received: from [192.168.3.123] (66-65-61-190.nyc.rr.com [66.65.61.190]) by toccata.fugue.com (Postfix) with ESMTP id A87F61B200B; Mon, 16 Feb 2004 15:12:51 -0600 (CST) In-Reply-To: <20040216170351.6B48D14C4E@sa.vix.com> References: <20040216170351.6B48D14C4E@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9260F83A-60C6-11D8-A8AF-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Mon, 16 Feb 2004 16:24:58 -0500 To: Paul Vixie <paul@vix.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Feb 16, 2004, at 12:03 PM, Paul Vixie wrote: > ...that we give Apple's solution the nod based simply on operational > experience with a solution that has already been randomly chosen. This is what I would like to see happen. > But there's still the larger question of "why LLMNR?" If the WG isn't > going to advance LLMNR while it remains incompatible with Rendezvous, > then why doesn't the WG just advance Rendezvous? Clearly, being early > isn't always an advantage. But does it always have to be a > disadvantage? Well, remember that LLMNR addresses one part of what Rendezvous addresses - name resolution. Also, as Bernard pointed out a couple of weeks ago, LLMNR and Rendezvous NR do have slightly different design goals (actually, he said more than slightly, but I think he was exaggerating :'). I think that it's worthwhile to compromise where we can, particularly in the 1v255 issue, and not try to standardize the whole Rendezvous suite as an IETF standard, because if we try to do this latter thing, I think we will just wind up back in the quagmire. The root cause for Rendezvous not happening here is not that it was too early, but that there is strong resistance among certain participants in the IETF against some of what Rendezvous does. I have tried to overcome this resistance, and my conclusion after having tried for some time is that it can't be overcome through any effort that I'm able to bring to bear. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 18 09:41:07 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14099 for <dnsext-archive@lists.ietf.org>; Wed, 18 Feb 2004 09:41:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtSmu-0007Ea-Li for namedroppers-data@psg.com; Wed, 18 Feb 2004 14:34:56 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtSmp-0007Ds-Sv for namedroppers@ops.ietf.org; Wed, 18 Feb 2004 14:34:51 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12818; Wed, 18 Feb 2004 09:34:49 -0500 (EST) Message-Id: <200402181434.JAA12818@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-06.txt Date: Wed, 18 Feb 2004 09:34:49 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Threat Analysis Of The Domain Name System Author(s) : D. Atkins, R. Austein Filename : draft-ietf-dnsext-dns-threats-06.txt Pages : 16 Date : 2004-2-18 Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-06.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-ietf-dnsext-dns-threats-06.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dns-threats-06.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18094650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-threats-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-threats-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18094650.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 18 09:41:15 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14134 for <dnsext-archive@lists.ietf.org>; Wed, 18 Feb 2004 09:41:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtSmk-0007DT-Lk for namedroppers-data@psg.com; Wed, 18 Feb 2004 14:34:46 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtSmi-0007D5-KM for namedroppers@ops.ietf.org; Wed, 18 Feb 2004 14:34:44 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12805; Wed, 18 Feb 2004 09:34:42 -0500 (EST) Message-Id: <200402181434.JAA12805@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-09.txt Date: Wed, 18 Feb 2004 09:34:42 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Introduction and Requirements Author(s) : R. Arends, R. Austein, D. Massey, M. Larson, S. Rose Filename : draft-ietf-dnsext-dnssec-intro-09.txt Pages : 25 Date : 2004-2-18 The Domain Name System Security Extensions (DNSSEC) adds data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-09.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-ietf-dnsext-dnssec-intro-09.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-09.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18094638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18094638.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 08:13:59 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17532 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 08:13:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtnvS-000CnI-5U for namedroppers-data@psg.com; Thu, 19 Feb 2004 13:09:10 +0000 Received: from [196.4.160.222] (helo=mercury.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtnvO-000Cmk-Ib for namedroppers@ops.ietf.org; Thu, 19 Feb 2004 13:09:06 +0000 Received: from hypatia.dns.net (c13-rba-5.dial-up.net [196.39.1.134]) by mercury.is.co.za (Postfix) with ESMTP id BE78FC034B; Thu, 19 Feb 2004 15:09:00 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i1J81Pm29836; Thu, 19 Feb 2004 10:01:25 +0200 Date: Thu, 19 Feb 2004 10:01:25 +0200 From: Andras Salamon <andras@dns.net> To: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Message-ID: <20040219080125.GA29778@dns.net> References: <20040216170351.6B48D14C4E@sa.vix.com> <200402172009.06027.bradh@frogmouth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402172009.06027.bradh@frogmouth.net> User-Agent: Mutt/1.5.5.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Feb 17, 2004 at 08:09:02PM +1100, Brad Hards wrote: > On Tue, 17 Feb 2004 04:03 am, Paul Vixie wrote: > > ...that we give Apple's solution the nod based simply on operational > > experience with a solution that has already been randomly chosen. > I suggest that we make it "MUST (or SHOULD) send at 255, MAY bother to check" > as the path to least gratuitous breakage. I support "MUST send with TTL=255, MAY reject if TTL<>255 on receipt", possibly with a paragraph emphasizing that routers SHOULD discard such packets if TTL<>255 (though this is perhaps broadening the ambit of the document too far). -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 11:02:16 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24942 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 11:02:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtqWa-000Cfm-MN for namedroppers-data@psg.com; Thu, 19 Feb 2004 15:55:40 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtqWZ-000CfZ-Qp for namedroppers@psg.com; Thu, 19 Feb 2004 15:55:39 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCPWRH>; Thu, 19 Feb 2004 10:55:39 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B641E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'namedroppers@psg.com'" <namedroppers@psg.com> Subject: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 10:55:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Please have a look at http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt Yeah, I know. Flame away. I think it's a pretty good idea anyway :) Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 12:26:30 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27965 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 12:26:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atrrw-000Pb4-JW for namedroppers-data@psg.com; Thu, 19 Feb 2004 17:21:48 +0000 Received: from [192.188.192.2] (helo=imail.akc.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atrrm-000PZZ-RJ for namedroppers@psg.com; Thu, 19 Feb 2004 17:21:38 +0000 Received: from upstairs [64.253.39.242] by imail.akc.com with ESMTP (SMTPD32-8.02) id A26F13D40078; Thu, 19 Feb 2004 12:29:19 -0500 Message-ID: <004501c3f70c$ad9383e0$6401a8c0@akc.com> From: "Al Costanzo" <al@akc.com> To: "Rosen, Brian" <Brian.Rosen@marconi.com>, <namedroppers@psg.com> References: <313680C9A886D511A06000204840E1CF070B641E@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 12:20:31 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0042_01C3F6E2.C492C260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.3 required=5.0 tests=DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C3F6E2.C492C260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear Brian & everyone on the namedroppers list, When I tell you I total agree that this information needs to be in the DNS for a number or reasons: 1.911 as you mentioned 2.Credit Card Verification Processing 3.New Anti-Spam Legislation To add just two more. After reading your draft, I disagree on how the information is to be inserted into the RR. The address needs to be listed in the RR as it was a postal address. The reason for this is ease of use. Everyone know their own address but not mank know thier geographic location. I welcome you and everone to help me come up with a solution in this matter. A document I just revised is attached to this email. Not sure if the list server allows such things. I am not a proud or I need it done my way or I want the glory for the RFC kinda guy. I see a problem that needs to be addressed, I think the solution I presented is the best solution, but if anyone thinks this idea can be tweaked or you want to co-author the work and work on this solution with me, please feel free to let me know. I however do not want the RR to use Log and Lat as reference points. The draft has been submitted as: draft-costanzo-dns-gl-06.txt but I am sure it is not listed in the I-D directory yet. ----- Original Message ----- From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: <namedroppers@psg.com> Sent: Thursday, February 19, 2004 10:55 AM Subject: New I-D on using DNS to support Emergency Calls > Please have a look at > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > Yeah, I know. Flame away. I think it's a pretty good idea anyway :) > > Brian > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > ------=_NextPart_000_0042_01C3F6E2.C492C260 Content-Type: text/plain; name="glnew.txt" Content-Disposition: attachment; filename="glnew.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT A. = Costanzo draft-costanzo-dns-gl-06.txt AKC Computer Services = Corp. Expires: August 2004 Feb = 2004 Definition of the DNS GL Resource Record used to encode Geographic Locations 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast, or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. 2. Abstract This document defines the format of a new Experimental Resource Record = (RR) namely GL for the Domain Naming System (DNS), and reserves a = corresponding DNS type mnemonic and numerical code <tba> (decimal). This definition = deals with associating geographical host location mappings to host names = within a domain within a geopolitical area (a country). =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Costanzo [Page = 1] EXPIRES IN SIX MONTHS Feb = 2004 3. Introduction [NOTE: This draft has been modified from its previous draft version=20 specifically for use with Internet Telepony applications and=20 specifically at the request of a number of people including = members of the working group & the RFC Editor - all of whom had a = number of=20 concerns with the previous version(s) of the draft. Whilst ALL = of the concerns have been addressed in version 5, it is the authors = hope that the draft may be reconsidered by the working group for = publication. The GL resource records usage has been simplified as well. The author welcomes all comments. = ] The ideal way to manage and maintain a database of information, such = as a geograpic location of an Internet host, is to delegate = responsibility to local domain administrators. This document resolves the problem of relating host information = within the DNS to geographical locations. This definition has been designed = to=20 be easy for the person who administrates DNS for a domain. NOT = requiring longitude, latitude and elevation information and merely being able = to=20 enter address information, as you would address a postal letter, will = mean broad acceptance and use of the GL resource record. By making = the=20 location geopolitical, the addressing mechinism should be received = well globally. There is a growing demand for postal address information to be listed = within a DNS record. Specifically, with the growing use of the public = Internet to complete Long Distance telephone calls, there is now a need to know = the physical locations of the hops with the final destinations locations position = most important to agencies such as police and fire departments for 911 information. The availability of geographical location information will = immediately be able to benefit applications in network management, which would = enhance and supplement various network tools which currently exist. The Domain Name System is ideally suited to provide geographic = location information. The information we desire to make available globally = needs to be maintained and updated locally (perfect for DNS). Although there are other location resourse records defined, that = attempt to allow location information on host to be stored and distributed, such = as LOC and GPOS, none have either gained acceptance on a wide scale or made = allowance for location information that is not within the confines of the = planet Earth. 4. The GL format GL has the following format: <owner> <ttl> <class> GL <Rdata> 4.1 Rdata Format Rdata has the following format: <string> <string> The format of the RDATA field is two varying length strings separated = by a space character. The first, the hierarchical locator, then an = address=20 string. Each is quoted (like all strings) only when it has spaces in = it, which will never be true for the first string, and almost always for = the second. Costanzo [Page = 2] EXPIRES IN SIX MONTHS Feb = 2004 4.1.1 The Hierarchical Locator The Hierarchical Locator contains the following components (each = separated by a period "."): =20 Country Code - (REQUIRED) The country code specifies the country the host computer = resides in, or in the case of an astronomical location other than "S3" = (Earth), the country which owns the device and/or machine. The code=20 is a two character fixed length string. These codes are = defined=20 in document ISO 3166-1. "US" for United States for example.=20 =20 =20 Postal Zone - (OPTIONAL) This rdata component supplies the postal code (Zip Code) for = the location the host computer resides. For countries that have a multi-segmented postal coding system, the segments should be separated by period(s) ".". This field may be omitted only if the country in which the = host machine resides does not use a postal coding system otherwise = the data MUST be supplied. When all three Hierarchical Locator components exist for an = DNS=20 entry, the position being defined is considered to be a = "precise=20 position". 4.2 The Visual Address String This string should be entered as you would enter an address on a postal letter within the country specified by the Hierarchical Locator. The country code information MUST NOT be included within the quoted string. This string is always required and must be present in the RDATA field. The visual address string may be used for both visual reference of=20 the physical address as well as by a software application to help determine a more precise location of the host machine (if the Hierarchical Locator lacks sufficient precision). Costanzo [Page = 3] EXPIRES IN SIX MONTHS Feb = 2004 The only instance in which any application should attempt to interpret the visual address string is in a case where the country code defines a country that does not use, or has not implemented a postal code system. No software or application should attempt to override a precise position defined by the Hierarchical Locator with information defined within the quoted string data. 5. Example(s) Example 1 (with a postal zone defined): donuts A 192.188.192.1 GL US.45420.1910 "1425 Arbor Avenue, Dayton OH" Example 2 (no postal zone): lorinda A 129.122.1.1 GL SR "Marthastrasse 64, Shawproject, Uitvlug, = Parimaribo" Example 3 ; Authoritative data for akc.net. ; ; note in this example: ; uspring, diana and martha (even though the complete postal code was ; not entered) are precisely defined ; ; lorinda, resides in the country of SURINAME, which has not = implemented ; a postal coding system. ; ; THIS IS ONLY AN EXAMPLE ; @ IN SOA forme.akc.net. postmaster.akc.net. ( 99071100 ; Serial (yymmddnn) 10800 ; Refresh (3 hours) 3600 ; Retry (1 hour) 3600000 ; Expire (1000 hours) 86400 ; Minimum (24 hours) ) IN NS ns.akc.net. uspring IN A 192.188.192.2 IN MX 5 mail IN HINFO Vax VMS IN GL US.45420.1910 "1425 Arbor Avenue, Dayton OH" ftp IN CNAME uspring Costanzo [Page = 4] EXPIRES IN SIX MONTHS Feb = 2004 diana IN A 192.188.192.3 IN MX 5 mail IN HINFO Vax VMS IN GL US.07204.1367 "808 Chestnut Street, Roselle Park, NJ" www IN CNAME diana martha IN A 192.188.192.4 IN MX 5 mail IN HINFO Vax VMS IN GL US.07204 "815 Chestnut Willis Place, Roselle Park, NJ" lorinda IN A 129.122.1.1 IN GL SR "Marthastrasse 64, Shawproject, Uitvlug, Parimaribo" 6. Why in in the DNS specifically? It serves no useful purpose! It has been mentioned to the Author over and over again for the need = of this=20 resource record for internet telephone applications and how the use of = other Internet Directory style services are not appropriate. DNS is = standardized and a required application for ISPs, other directory services are not. It has also been mentioned that since the there is a one-to-one = relationship between the host and the GL data it is appropriate for inclusion as a = DNS resource record. As already mentioned in the draft, the physical location of a computer = is becomming extremely important for government agencies such as police and fire. =20 7. Other possible uses for GL It has been mentioned to the Author over and over again for the need = of this=20 resource record for internet telephone applications and how the use of = other Internet Directory style services are not appropriate. The use of postal codes also is exactly what is needed for credit card = address authentication. Sites could (quietly) compare GL info provided on = entries from=20 ISPs to what someone enters for additional verification purposes. We also were told that this resource record would be helpful in = tracking down=20 hackers. (although the use of DHCP and dynamic addressing may limit = its usefulness if ISPs did not maintain the GL record properly. 8 Why GL and not TXT records? TXT records do not have a specific order to them. It would be = extremely unwise to=20 to entrust 911 emergency calls to TXT records. Other resource records such as LOC and GPOS are not appropriate for = use with emergency service units as police and fire departments 9. Security Consideration Since this resource record is not required in the DNS there are no = security consideration. If someone such as the Department of Defense did not want the = whereabouts of there computer system to be know, they would merely omit it. =20 Costanzo [Page = 6] EXPIRES IN SIX MONTHS Feb = 2004 10. Author's Address Al Costanzo AKC Computer Services Corp. P.O. Box 4031, Roselle Park, NJ 07204-0531 www.AKC.com Phone: +1 908 298 9000 Email: AL@AKC.COM Costanzo [Page = 7] ------=_NextPart_000_0042_01C3F6E2.C492C260-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From mwbnoticiaurgente@hotmail.com Thu Feb 19 12:45:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29372 for <dnsext-archive@ietf.org>; Thu, 19 Feb 2004 12:45:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtsF6-0003ly-00 for dnsext-archive@ietf.org; Thu, 19 Feb 2004 12:45:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtsE3-0003ey-00 for dnsext-archive@ietf.org; Thu, 19 Feb 2004 12:44:40 -0500 Received: from [219.93.203.189] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AtsDB-0003LP-00; Thu, 19 Feb 2004 12:43:47 -0500 From: "Mato Grosso: . xlf" <mwbnoticiaurgente@hotmail.com> To: disman-request@ietf.org Subject: Alertam sobre perigo de aftosa em fazendas invadidas por �ndios ref.: ibf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: <E1AtsDB-0003LP-00@ietf-mx> Date: Thu, 19 Feb 2004 12:43:47 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.1 required=5.0 tests=HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252"> <META NAME="Generator" CONTENT="Microsoft Word 97"> <META NAME="Template" CONTENT="C:\Arquivos de programas\Microsoft Office\Office\html.dot"> </HEAD> <BODY LINK="#0000ff" VLINK="#800080"> cod.: (ebz) <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=EnEspañol:TraductorGratuitoAutomático">EnEspañol:TraductorGratuitoAutomático</A> - <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=InEnglish:FreeAutomaticTranslator">InEnglish:FreeAutomaticTranslator</A> Mato Grosso do Sul: alertam sobre perigo de aftosa em fazendas invadidas por índios Conselho Indigenista Missionário (Cimi), Fundação Nacional do Índio (Funai) e ONGs são acusadas de "fabricar" conflitos entre índios e proprietários rurais, que já causaram numerosas vítimas, como um dirigente pecuarista recentemente assassinado em Santa Catarina CAMPO GRANDE, Fevr. 19, 2004 (AB) - "Há uma preocupação enorme com relação ao estado sanitário do rebanho bovino estimado em 9 mil cabeças, nas 14 fazendas invadidas por índios na região de Japorã, perto da fronteira com o Paraguai". "Mato Grosso do Sul é livre de aftosa, mediante vacinação, o Estado possui o 1o. rebanho bovino do Brasil, e um dos primeiros do mundo, com 24 milhões e 700 mil cabeças, contribuindo com uma porcentagem significativa das exportações de carne bovina. Qualquer brote de aftosa que venha a macular esse estado sanitário teria de imediato uma enorme repercussão econômica em nível local, nacional e internacional". O alerta foi dado ontem pelo engenheiro Josiel Quintino dos Santos, assessor de Meio Ambiente e Assuntos Indígenas da Federação da Agricultura e Pecuária de Mato Grosso do Sul (Famasul) (<A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino:DesejoContato">DrQuintino:DesejoContato</A> - <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino:DesejoContatoDeImprensa">DrQuintino:DesejoContatoDeImprensa</A>). A tensão e a violência na região fez com que a Agência Estadual de Defesa Sanitária Animal e Vegetal (Iagro) tenha suspendido o trabalho de vigilância e vacinação do rebanho das fazendas invadidas por índios guaranis, caiuás e ñandeva. Quintino acrescentou a preocupação existente no Estado "com os conflitos fabricados e incentivados pelo Conselho Indigenista Missionário (Cimi), e favorecidos pela Fundação Nacional do Índio, segundo já foi documentado no relatório da CPI do Funai, na Câmara dos Deputados". O assessor da Famasul informou que os índios, contrariamente ao informado por alguns meios de imprensa, "não abandonaram nenhuma das 14 fazendas invadidas, e até o momento não permitiram o trabalho de perícia judicial para avaliar a destruição causada". Brasília: deputado Zauith denúncia "manipulação" de índios Também ontem, em Brasília, o deputado sul-matogrossense Murilo Zauith (PFL) fez discurso na tribuna da Câmara para "denunciar os conflitos indígenas" que vem ocorrendo em todo o País, incentivados pela "atuação de determinadas organizações internacionais, que chegam a ameaçar a soberania nacional" e de "pessoas inescrupulosas" que "manipulam" e "incitam os índios a invadir as propriedades rurais". Zauith acrescentou que esse "cenário devastador" já vem causando "uma retração nos investimentos no agronegócio em Mato Grosso do Sul", atividade que "é o principal pilar da economia sul-matogrossense" (<A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DepZauith:DiscursoCompleto">DepZauith:DiscursoCompleto</A>). Santa Catarina: Cimi e Funai fomentam caos, diz Federação da Agricultura A Federação da Agricultura do Estado de Santa Catarina (Faesc), em nota de repúdio diante do assassinato do pecuarista Olisses Stefani, recentemente vitimado com um tiro de carabina na cabeça por indígenas que ameaçavam invadir propriedades rurais, afirma que sua morte "revela a dramática dimensão a que chegaram os conflitos entre índios e produtores no grande Oeste catarinense". E acrescenta que "determinadas organizações, motivadas por objetivos inconfessáveis, fomentam o embate e exasperam a crise, tentando criar um cenário de caos e desordem", sendo "notória, nesse aspecto, a ação do Conselho Indigenista Missionário (Cimi), cujos agentes imiscuem-se nas áreas indígenas para fomentar a discórdia". Enquanto a Fundação Nacional do Índio (Funai) oscila entre a inércia e a omissão, nada fazendo em favor da paz e da tranqüilidade", sendo sua atuação "marcada pela influência de ONGs" (<A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Faesc:TextoCompleto">Faesc:TextoCompleto</A>). 040219AB / Atualidade Brasileira LINKS: <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino/Famasul:DesejoContato">DrQuintino/Famasul:DesejoContato</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino/Famasul:DesejoContatoUrgente">DrQuintino/Famasul:DesejoContatoUrgente</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino/Famasul:DesejoContatoDeImprensa">DrQuintino/Famasul:DesejoContatoDeImprensa</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DepZauith:DiscursoCompleto">DepZauith:DiscursoCompleto</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Faesc:TextoCompleto">Faesc:TextoCompleto</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:MinhaOpinião">AtualidadeBrasileira:MinhaOpinião</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:Concordo">AtualidadeBrasileira:Concordo</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:Discordo">AtualidadeBrasileira:Discordo</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:DocumentaçãoUsada">AtualidadeBrasileira:DocumentaçãoUsada</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:Remover">AtualidadeBrasileira:Remover</A> A difusão deste comunicado, com uma finalidade exclusivamente informativa, é de responsabilidade da agência Atualidade Brasileira (Rio de Janeiro). O texto pode ser reproduzido parcial ou totalmente, sendo recomendável, mas não necessário, citar a fonte. </BODY> </HTML> From owner-namedroppers@ops.ietf.org Thu Feb 19 13:30:34 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01757 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 13:30:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atsr2-0009TY-3Z for namedroppers-data@psg.com; Thu, 19 Feb 2004 18:24:56 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atsqt-0009TC-R2 for namedroppers@psg.com; Thu, 19 Feb 2004 18:24:47 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCP69W>; Thu, 19 Feb 2004 13:24:47 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6423@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Al Costanzo'" <al@akc.com>, namedroppers@psg.com Subject: RE: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 13:24:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As a practical matter, you rarely type your location into a form to determine where you are. Rather, various service providers, enterprises and automated mechanisms determine your location from a variety of information sources. Therefore, the idea that the form of the entry has to exactly match a postal address is not true. Further, for emergency response, your postal address is often not your response address, for example when the post office that serves you is not the municipality where you are located. In my own case, I live in Pine Township, Allegheny County, but my postal address is Mars, PA 16046. Mars is a nearby town, in Butler County. For emergency dispatch, it is essential that the ERC serving Pine Township get the call, and that for dispatch, that the address is a Pine township address and not a Mars address. Also, the delegation properties of the DNS exactly match what is required to provide location to the precision of a room. Using the naming hierarchy to permit delegation of an address to a building owner, and thence to a suite owner, who enters room level data in his entry is particularly useful. And, the postal zone boundary does not align with the ERC boundaries, and does not align with municipal boundaries, which further complicates populating the database. For these reasons, I believe my suggestion is a better one. Brian > -----Original Message----- > From: Al Costanzo [mailto:al@akc.com] > Sent: Thursday, February 19, 2004 12:21 PM > To: Rosen, Brian; namedroppers@psg.com > Subject: Re: New I-D on using DNS to support Emergency Calls > > > Dear Brian & everyone on the namedroppers list, > > When I tell you I total agree that this information needs to > be in the DNS > for a number or reasons: > > 1.911 as you mentioned > 2.Credit Card Verification Processing > 3.New Anti-Spam Legislation > > To add just two more. > > After reading your draft, I disagree on how the information is to be > inserted into the RR. > > The address needs to be listed in the RR as it was a postal > address. The > reason for this is ease of use. Everyone know their own > address but not mank > know thier geographic location. > > I welcome you and everone to help me come up with a solution > in this matter. > A document I just revised is attached to this email. Not sure > if the list > server allows such things. > > I am not a proud or I need it done my way or I want the glory > for the RFC > kinda guy. > > I see a problem that needs to be addressed, I think the > solution I presented > is the best solution, but if anyone thinks this idea can be > tweaked or you > want to co-author the work and work on this solution with me, > please feel > free to let me know. I however do not want the RR to use Log > and Lat as > reference points. > > The draft has been submitted as: draft-costanzo-dns-gl-06.txt > but I am sure > it is not listed in the I-D directory yet. > > > > ----- Original Message ----- > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > To: <namedroppers@psg.com> > Sent: Thursday, February 19, 2004 10:55 AM > Subject: New I-D on using DNS to support Emergency Calls > > > > Please have a look at > > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > > > Yeah, I know. Flame away. I think it's a pretty good idea > anyway :) > > > > Brian > > > > -- > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 13:42:19 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06104 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 13:42:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Att4U-000BiK-1p for namedroppers-data@psg.com; Thu, 19 Feb 2004 18:38:50 +0000 Received: from [192.188.192.2] (helo=imail.akc.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Att4N-000BeS-BT for namedroppers@psg.com; Thu, 19 Feb 2004 18:38:43 +0000 Received: from upstairs [64.253.39.242] by imail.akc.com with ESMTP (SMTPD32-8.02) id A481FB100FE; Thu, 19 Feb 2004 13:46:25 -0500 Message-ID: <001e01c3f717$6962d8a0$6401a8c0@akc.com> From: "Al Costanzo" <al@akc.com> To: "Rosen, Brian" <Brian.Rosen@marconi.com>, <namedroppers@psg.com> References: <313680C9A886D511A06000204840E1CF070B6423@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 13:37:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Brian, A complete Zip+4 points to your exact location. There is no rule what address you use in the field, and there is a cmment area as well. My opinion is ased on the fact that hardly anyone uses the LOC RR and I think it is because it requires a Log & Lad indication as points of references. IMHO postal addresses solve this, but its only my opinion. Al ----- Original Message ----- From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> Sent: Thursday, February 19, 2004 1:24 PM Subject: RE: New I-D on using DNS to support Emergency Calls > As a practical matter, you rarely type your location into a form to > determine > where you are. Rather, various service providers, enterprises and automated > mechanisms determine your location from a variety of information sources. > Therefore, the idea that the form of the entry has to exactly match a postal > address is not true. Further, for emergency response, your postal address > is > often not your response address, for example when the post office that > serves > you is not the municipality where you are located. In my own case, I live > in > Pine Township, Allegheny County, but my postal address is Mars, PA 16046. > Mars is a nearby town, in Butler County. For emergency dispatch, it is > essential that the ERC serving Pine Township get the call, and that for > dispatch, that the address is a Pine township address and not a Mars > address. > > Also, the delegation properties of the DNS exactly match what is required to > provide location to the precision of a room. Using the naming hierarchy to > permit delegation of an address to a building owner, and thence to a suite > owner, who enters room level data in his entry is particularly useful. > > And, the postal zone boundary does not align with the ERC boundaries, and > does not align with municipal boundaries, which further complicates > populating the database. > > For these reasons, I believe my suggestion is a better one. > > Brian > > > -----Original Message----- > > From: Al Costanzo [mailto:al@akc.com] > > Sent: Thursday, February 19, 2004 12:21 PM > > To: Rosen, Brian; namedroppers@psg.com > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > Dear Brian & everyone on the namedroppers list, > > > > When I tell you I total agree that this information needs to > > be in the DNS > > for a number or reasons: > > > > 1.911 as you mentioned > > 2.Credit Card Verification Processing > > 3.New Anti-Spam Legislation > > > > To add just two more. > > > > After reading your draft, I disagree on how the information is to be > > inserted into the RR. > > > > The address needs to be listed in the RR as it was a postal > > address. The > > reason for this is ease of use. Everyone know their own > > address but not mank > > know thier geographic location. > > > > I welcome you and everone to help me come up with a solution > > in this matter. > > A document I just revised is attached to this email. Not sure > > if the list > > server allows such things. > > > > I am not a proud or I need it done my way or I want the glory > > for the RFC > > kinda guy. > > > > I see a problem that needs to be addressed, I think the > > solution I presented > > is the best solution, but if anyone thinks this idea can be > > tweaked or you > > want to co-author the work and work on this solution with me, > > please feel > > free to let me know. I however do not want the RR to use Log > > and Lat as > > reference points. > > > > The draft has been submitted as: draft-costanzo-dns-gl-06.txt > > but I am sure > > it is not listed in the I-D directory yet. > > > > > > > > ----- Original Message ----- > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > To: <namedroppers@psg.com> > > Sent: Thursday, February 19, 2004 10:55 AM > > Subject: New I-D on using DNS to support Emergency Calls > > > > > > > Please have a look at > > > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > > > > > Yeah, I know. Flame away. I think it's a pretty good idea > > anyway :) > > > > > > Brian > > > > > > -- > > > to unsubscribe send a message to > > namedroppers-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 13:45:36 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10182 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 13:45:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Att9I-000Cbv-0E for namedroppers-data@psg.com; Thu, 19 Feb 2004 18:43:48 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Att9B-000Cao-S5 for namedroppers@psg.com; Thu, 19 Feb 2004 18:43:41 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCP74F>; Thu, 19 Feb 2004 13:43:41 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6424@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Al Costanzo'" <al@akc.com>, namedroppers@psg.com Subject: RE: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 13:43:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Al A Zip+4 can cross a township boundary (mine does). It can cross an ERC response boundary (also true here), and it can cross a state boundary (rare, but true). Postal codes are for the post office, and they don't reflect anything other than convenience for the Post Office sorting and delivery people. In many countries, they don't even have postal codes. As such, I don't think they help anything but delivering snail mail. Brian > -----Original Message----- > From: Al Costanzo [mailto:al@akc.com] > Sent: Thursday, February 19, 2004 1:37 PM > To: Rosen, Brian; namedroppers@psg.com > Subject: Re: New I-D on using DNS to support Emergency Calls > > > Hi Brian, > > A complete Zip+4 points to your exact location. There is no rule what > address you use in the field, and there is a cmment area as well. > > My opinion is ased on the fact that hardly anyone uses the > LOC RR and I > think it is because it requires a Log & Lad indication as points of > references. > > IMHO postal addresses solve this, but its only my opinion. > > Al > ----- Original Message ----- > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> > Sent: Thursday, February 19, 2004 1:24 PM > Subject: RE: New I-D on using DNS to support Emergency Calls > > > > As a practical matter, you rarely type your location into a form to > > determine > > where you are. Rather, various service providers, enterprises and > automated > > mechanisms determine your location from a variety of > information sources. > > Therefore, the idea that the form of the entry has to > exactly match a > postal > > address is not true. Further, for emergency response, your > postal address > > is > > often not your response address, for example when the post > office that > > serves > > you is not the municipality where you are located. In my > own case, I live > > in > > Pine Township, Allegheny County, but my postal address is > Mars, PA 16046. > > Mars is a nearby town, in Butler County. For emergency > dispatch, it is > > essential that the ERC serving Pine Township get the call, > and that for > > dispatch, that the address is a Pine township address and not a Mars > > address. > > > > Also, the delegation properties of the DNS exactly match > what is required > to > > provide location to the precision of a room. Using the > naming hierarchy to > > permit delegation of an address to a building owner, and > thence to a suite > > owner, who enters room level data in his entry is > particularly useful. > > > > And, the postal zone boundary does not align with the ERC > boundaries, and > > does not align with municipal boundaries, which further complicates > > populating the database. > > > > For these reasons, I believe my suggestion is a better one. > > > > Brian > > > > > -----Original Message----- > > > From: Al Costanzo [mailto:al@akc.com] > > > Sent: Thursday, February 19, 2004 12:21 PM > > > To: Rosen, Brian; namedroppers@psg.com > > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > > > > Dear Brian & everyone on the namedroppers list, > > > > > > When I tell you I total agree that this information needs to > > > be in the DNS > > > for a number or reasons: > > > > > > 1.911 as you mentioned > > > 2.Credit Card Verification Processing > > > 3.New Anti-Spam Legislation > > > > > > To add just two more. > > > > > > After reading your draft, I disagree on how the > information is to be > > > inserted into the RR. > > > > > > The address needs to be listed in the RR as it was a postal > > > address. The > > > reason for this is ease of use. Everyone know their own > > > address but not mank > > > know thier geographic location. > > > > > > I welcome you and everone to help me come up with a solution > > > in this matter. > > > A document I just revised is attached to this email. Not sure > > > if the list > > > server allows such things. > > > > > > I am not a proud or I need it done my way or I want the glory > > > for the RFC > > > kinda guy. > > > > > > I see a problem that needs to be addressed, I think the > > > solution I presented > > > is the best solution, but if anyone thinks this idea can be > > > tweaked or you > > > want to co-author the work and work on this solution with me, > > > please feel > > > free to let me know. I however do not want the RR to use Log > > > and Lat as > > > reference points. > > > > > > The draft has been submitted as: draft-costanzo-dns-gl-06.txt > > > but I am sure > > > it is not listed in the I-D directory yet. > > > > > > > > > > > > ----- Original Message ----- > > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > > To: <namedroppers@psg.com> > > > Sent: Thursday, February 19, 2004 10:55 AM > > > Subject: New I-D on using DNS to support Emergency Calls > > > > > > > > > > Please have a look at > > > > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > > > > > > > Yeah, I know. Flame away. I think it's a pretty good idea > > > anyway :) > > > > > > > > Brian > > > > > > > > -- > > > > to unsubscribe send a message to > > > namedroppers-request@ops.ietf.org with > > > > the word 'unsubscribe' in a single line as the message > text body. > > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > > > > -- > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 13:57:46 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24553 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 13:57:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AttJt-000EpX-IE for namedroppers-data@psg.com; Thu, 19 Feb 2004 18:54:45 +0000 Received: from [192.188.192.2] (helo=imail.akc.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AttJm-000Eoh-Hx for namedroppers@psg.com; Thu, 19 Feb 2004 18:54:38 +0000 Received: from upstairs [64.253.39.242] by imail.akc.com with ESMTP (SMTPD32-8.02) id A83B7CC0066; Thu, 19 Feb 2004 14:02:19 -0500 Message-ID: <001601c3f719$a25f3f20$6401a8c0@akc.com> From: "Al Costanzo" <al@akc.com> To: "Rosen, Brian" <Brian.Rosen@marconi.com>, <namedroppers@psg.com> References: <313680C9A886D511A06000204840E1CF070B6424@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 13:53:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, Hmmm... In the case of 911 records my draft may not help then (if you feel you must put in your postal address and not the desired 911 location). But this draft helps the other two points that it actually was written for. To keep track of the physical address of the location of the machine that the A record is associated with. Or the location that the ISP would like to have it on record. The dradt was written to help prevent credit card fraud by having a fall back for non-mobile computers to help verify the address entered. Please note that the draft I submitted support precision so for example you could just enter the country or country & state, etc, for a less precise location for Privacy concern. Because this draft was written to help prevent SPAM as well as help with credit card processing, it may be that it cannot help you with your need. Unfortuantely, Lat & Log co-ordinates do not help me with the needs I am trying to address. Best Regards, Al ----- Original Message ----- From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> Sent: Thursday, February 19, 2004 1:43 PM Subject: RE: New I-D on using DNS to support Emergency Calls > Al > > A Zip+4 can cross a township boundary (mine does). It can cross an ERC > response boundary (also true here), and it can cross a state boundary (rare, > but true). Postal codes are for the post office, and they don't reflect > anything other than convenience for the Post Office sorting and delivery > people. In many countries, they don't even have postal codes. As such, > I don't think they help anything but delivering snail mail. > > Brian > > > -----Original Message----- > > From: Al Costanzo [mailto:al@akc.com] > > Sent: Thursday, February 19, 2004 1:37 PM > > To: Rosen, Brian; namedroppers@psg.com > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > Hi Brian, > > > > A complete Zip+4 points to your exact location. There is no rule what > > address you use in the field, and there is a cmment area as well. > > > > My opinion is ased on the fact that hardly anyone uses the > > LOC RR and I > > think it is because it requires a Log & Lad indication as points of > > references. > > > > IMHO postal addresses solve this, but its only my opinion. > > > > Al > > ----- Original Message ----- > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> > > Sent: Thursday, February 19, 2004 1:24 PM > > Subject: RE: New I-D on using DNS to support Emergency Calls > > > > > > > As a practical matter, you rarely type your location into a form to > > > determine > > > where you are. Rather, various service providers, enterprises and > > automated > > > mechanisms determine your location from a variety of > > information sources. > > > Therefore, the idea that the form of the entry has to > > exactly match a > > postal > > > address is not true. Further, for emergency response, your > > postal address > > > is > > > often not your response address, for example when the post > > office that > > > serves > > > you is not the municipality where you are located. In my > > own case, I live > > > in > > > Pine Township, Allegheny County, but my postal address is > > Mars, PA 16046. > > > Mars is a nearby town, in Butler County. For emergency > > dispatch, it is > > > essential that the ERC serving Pine Township get the call, > > and that for > > > dispatch, that the address is a Pine township address and not a Mars > > > address. > > > > > > Also, the delegation properties of the DNS exactly match > > what is required > > to > > > provide location to the precision of a room. Using the > > naming hierarchy to > > > permit delegation of an address to a building owner, and > > thence to a suite > > > owner, who enters room level data in his entry is > > particularly useful. > > > > > > And, the postal zone boundary does not align with the ERC > > boundaries, and > > > does not align with municipal boundaries, which further complicates > > > populating the database. > > > > > > For these reasons, I believe my suggestion is a better one. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Al Costanzo [mailto:al@akc.com] > > > > Sent: Thursday, February 19, 2004 12:21 PM > > > > To: Rosen, Brian; namedroppers@psg.com > > > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > > > > > > > Dear Brian & everyone on the namedroppers list, > > > > > > > > When I tell you I total agree that this information needs to > > > > be in the DNS > > > > for a number or reasons: > > > > > > > > 1.911 as you mentioned > > > > 2.Credit Card Verification Processing > > > > 3.New Anti-Spam Legislation > > > > > > > > To add just two more. > > > > > > > > After reading your draft, I disagree on how the > > information is to be > > > > inserted into the RR. > > > > > > > > The address needs to be listed in the RR as it was a postal > > > > address. The > > > > reason for this is ease of use. Everyone know their own > > > > address but not mank > > > > know thier geographic location. > > > > > > > > I welcome you and everone to help me come up with a solution > > > > in this matter. > > > > A document I just revised is attached to this email. Not sure > > > > if the list > > > > server allows such things. > > > > > > > > I am not a proud or I need it done my way or I want the glory > > > > for the RFC > > > > kinda guy. > > > > > > > > I see a problem that needs to be addressed, I think the > > > > solution I presented > > > > is the best solution, but if anyone thinks this idea can be > > > > tweaked or you > > > > want to co-author the work and work on this solution with me, > > > > please feel > > > > free to let me know. I however do not want the RR to use Log > > > > and Lat as > > > > reference points. > > > > > > > > The draft has been submitted as: draft-costanzo-dns-gl-06.txt > > > > but I am sure > > > > it is not listed in the I-D directory yet. > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > > > To: <namedroppers@psg.com> > > > > Sent: Thursday, February 19, 2004 10:55 AM > > > > Subject: New I-D on using DNS to support Emergency Calls > > > > > > > > > > > > > Please have a look at > > > > > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > > > > > > > > > Yeah, I know. Flame away. I think it's a pretty good idea > > > > anyway :) > > > > > > > > > > Brian > > > > > > > > > > -- > > > > > to unsubscribe send a message to > > > > namedroppers-request@ops.ietf.org with > > > > > the word 'unsubscribe' in a single line as the message > > text body. > > > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > > > > > > > > -- > > > to unsubscribe send a message to > > namedroppers-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 14:15:57 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14349 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 14:15:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Attb4-000HwI-4h for namedroppers-data@psg.com; Thu, 19 Feb 2004 19:12:30 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Attb3-000Hw4-0y for namedroppers@psg.com; Thu, 19 Feb 2004 19:12:29 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCP8XW>; Thu, 19 Feb 2004 14:12:28 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6425@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Al Costanzo'" <al@akc.com>, namedroppers@psg.com Subject: RE: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 14:12:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sorry, I did not understand your goal well enough. Then again, I don't think you can meet your goal with the DNS. The computer which you are sending or receiving email or entering credit card information probably does not have an externally available DNS entry, and the "nearest" (in the Internet sense) one that does is not very close to you (in the postal address sense) in almost every case. Brian > -----Original Message----- > From: Al Costanzo [mailto:al@akc.com] > Sent: Thursday, February 19, 2004 1:53 PM > To: Rosen, Brian; namedroppers@psg.com > Subject: Re: New I-D on using DNS to support Emergency Calls > > > Brian, > > Hmmm... In the case of 911 records my draft may not help > then (if you feel > you must put in your postal address and not the desired 911 location). > > But this draft helps the other two points that it actually > was written for. > To keep track of the physical address of the location of the > machine that > the A record is associated with. > > Or the location that the ISP would like to have it on record. > > The dradt was written to help prevent credit card fraud by > having a fall > back for non-mobile computers to help verify the address entered. > > Please note that the draft I submitted support precision so > for example you > could just enter the country or country & state, etc, for a > less precise > location for Privacy concern. > > Because this draft was written to help prevent SPAM as well > as help with > credit card processing, it may be that it cannot help you > with your need. > > Unfortuantely, Lat & Log co-ordinates do not help me with the > needs I am > trying to address. > > Best Regards, > > Al > ----- Original Message ----- > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> > Sent: Thursday, February 19, 2004 1:43 PM > Subject: RE: New I-D on using DNS to support Emergency Calls > > > > Al > > > > A Zip+4 can cross a township boundary (mine does). It can > cross an ERC > > response boundary (also true here), and it can cross a > state boundary > (rare, > > but true). Postal codes are for the post office, and they > don't reflect > > anything other than convenience for the Post Office sorting > and delivery > > people. In many countries, they don't even have postal > codes. As such, > > I don't think they help anything but delivering snail mail. > > > > Brian > > > > > -----Original Message----- > > > From: Al Costanzo [mailto:al@akc.com] > > > Sent: Thursday, February 19, 2004 1:37 PM > > > To: Rosen, Brian; namedroppers@psg.com > > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > > > > Hi Brian, > > > > > > A complete Zip+4 points to your exact location. There is > no rule what > > > address you use in the field, and there is a cmment area as well. > > > > > > My opinion is ased on the fact that hardly anyone uses the > > > LOC RR and I > > > think it is because it requires a Log & Lad indication as > points of > > > references. > > > > > > IMHO postal addresses solve this, but its only my opinion. > > > > > > Al > > > ----- Original Message ----- > > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > > To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> > > > Sent: Thursday, February 19, 2004 1:24 PM > > > Subject: RE: New I-D on using DNS to support Emergency Calls > > > > > > > > > > As a practical matter, you rarely type your location > into a form to > > > > determine > > > > where you are. Rather, various service providers, > enterprises and > > > automated > > > > mechanisms determine your location from a variety of > > > information sources. > > > > Therefore, the idea that the form of the entry has to > > > exactly match a > > > postal > > > > address is not true. Further, for emergency response, your > > > postal address > > > > is > > > > often not your response address, for example when the post > > > office that > > > > serves > > > > you is not the municipality where you are located. In my > > > own case, I live > > > > in > > > > Pine Township, Allegheny County, but my postal address is > > > Mars, PA 16046. > > > > Mars is a nearby town, in Butler County. For emergency > > > dispatch, it is > > > > essential that the ERC serving Pine Township get the call, > > > and that for > > > > dispatch, that the address is a Pine township address > and not a Mars > > > > address. > > > > > > > > Also, the delegation properties of the DNS exactly match > > > what is required > > > to > > > > provide location to the precision of a room. Using the > > > naming hierarchy to > > > > permit delegation of an address to a building owner, and > > > thence to a suite > > > > owner, who enters room level data in his entry is > > > particularly useful. > > > > > > > > And, the postal zone boundary does not align with the ERC > > > boundaries, and > > > > does not align with municipal boundaries, which further > complicates > > > > populating the database. > > > > > > > > For these reasons, I believe my suggestion is a better one. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Al Costanzo [mailto:al@akc.com] > > > > > Sent: Thursday, February 19, 2004 12:21 PM > > > > > To: Rosen, Brian; namedroppers@psg.com > > > > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > > > > > > > > > > Dear Brian & everyone on the namedroppers list, > > > > > > > > > > When I tell you I total agree that this information needs to > > > > > be in the DNS > > > > > for a number or reasons: > > > > > > > > > > 1.911 as you mentioned > > > > > 2.Credit Card Verification Processing > > > > > 3.New Anti-Spam Legislation > > > > > > > > > > To add just two more. > > > > > > > > > > After reading your draft, I disagree on how the > > > information is to be > > > > > inserted into the RR. > > > > > > > > > > The address needs to be listed in the RR as it was a postal > > > > > address. The > > > > > reason for this is ease of use. Everyone know their own > > > > > address but not mank > > > > > know thier geographic location. > > > > > > > > > > I welcome you and everone to help me come up with a solution > > > > > in this matter. > > > > > A document I just revised is attached to this email. Not sure > > > > > if the list > > > > > server allows such things. > > > > > > > > > > I am not a proud or I need it done my way or I want the glory > > > > > for the RFC > > > > > kinda guy. > > > > > > > > > > I see a problem that needs to be addressed, I think the > > > > > solution I presented > > > > > is the best solution, but if anyone thinks this idea can be > > > > > tweaked or you > > > > > want to co-author the work and work on this solution with me, > > > > > please feel > > > > > free to let me know. I however do not want the RR to use Log > > > > > and Lat as > > > > > reference points. > > > > > > > > > > The draft has been submitted as: draft-costanzo-dns-gl-06.txt > > > > > but I am sure > > > > > it is not listed in the I-D directory yet. > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > > > > To: <namedroppers@psg.com> > > > > > Sent: Thursday, February 19, 2004 10:55 AM > > > > > Subject: New I-D on using DNS to support Emergency Calls > > > > > > > > > > > > > > > > Please have a look at > > > > > > > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > > > > > > > > > > > Yeah, I know. Flame away. I think it's a pretty good idea > > > > > anyway :) > > > > > > > > > > > > Brian > > > > > > > > > > > > -- > > > > > > to unsubscribe send a message to > > > > > namedroppers-request@ops.ietf.org with > > > > > > the word 'unsubscribe' in a single line as the message > > > text body. > > > > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > > > > > > > > > > > > -- > > > > to unsubscribe send a message to > > > namedroppers-request@ops.ietf.org with > > > > the word 'unsubscribe' in a single line as the message > text body. > > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 14:33:38 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03762 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 14:33:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Attrt-000KKU-Ko for namedroppers-data@psg.com; Thu, 19 Feb 2004 19:29:53 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Attrs-000KKC-8q for namedroppers@psg.com; Thu, 19 Feb 2004 19:29:52 +0000 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by sj-iport-5.cisco.com with ESMTP; 19 Feb 2004 11:30:09 -0800 Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1JJTOFg001157; Thu, 19 Feb 2004 20:29:24 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Feb 2004 20:29:49 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Feb 2004 20:29:48 +0100 In-Reply-To: <001601c3f719$a25f3f20$6401a8c0@akc.com> References: <313680C9A886D511A06000204840E1CF070B6424@whq-msgusr-02.pit.comms.marconi.com> <001601c3f719$a25f3f20$6401a8c0@akc.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <FBFDD79C-6311-11D8-9580-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: <namedroppers@psg.com>, "Rosen, Brian" <Brian.Rosen@marconi.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com> Subject: Re: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 20:29:50 +0100 To: "Al Costanzo" <al@akc.com> X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 19 Feb 2004 19:29:48.0465 (UTC) FILETIME=[BCC59210:01C3F71E] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I see few problems with the draft: - It mixes the information you need to find the number to the correct ERC with information you need to send to the ERC. In Sweden for example, the resolution is on city boundary basis, but even if you pass the call to one such ERC, the destination E.164 you use is in reality only a hint to the "virtual ERC" which is covering Sweden where the call is coming from. So, it seems in the US (and this draft) you try to solve a problem which for example we in Sweden have solved by forcing the ERC's in the country to solve the problem among themselves? - What information is passed to the ERC is, I claim, by far more important than finding the right ERC. Yes, YMMV (see above). - Doing a width-first *search* in DNS is to be honest a plain bad idea. The operation doesn't exist (part from zone transfers of course), and I would suggest going to a specific protocol which can do this. - When you define a new RR type for this, why not "just" tag the URI to the data just like the corners of the polygon which is defining the area? - The overall problem for ERC dispatch services is as far as I know that the person/tool/whatever which issue the call don't know where he is. So, the "network" have to tell the ERC where the call is coming from, and _that_ is the real problem to solve. If you know this, I am sure the ERC can use whatever database needed to map to whatever coordinates they use this tuesday. - The database normally used for ERC coordination is extremely sensitive information, at least in Sweden. It can for example map the coordinate of E.164 numbers to geographical location, _including_ E.164 which are protected, used by people with protected (changed) identity etc. If this data get out on the street.... The database access must be extremely protected and only possible to access by very special access codes etc. Security implications are enormous. Yes, in Sweden a telco is required over the SS7 network to _always_ pass the caller id of the calling party to the ERC's. That's a very special function in Sweden and overrides whatever other rules there might be (like *NEVER*EVER* passing the caller ID of people with protected identities to third parties). Etc etc... So, there is a lot of work to do in the area of 911/112 calls, and I think very very few (if any) have to do with DNS. paf On 2004-02-19, at 19.53, Al Costanzo wrote: > Brian, > > Hmmm... In the case of 911 records my draft may not help then (if you > feel > you must put in your postal address and not the desired 911 location). > > But this draft helps the other two points that it actually was written > for. > To keep track of the physical address of the location of the machine > that > the A record is associated with. > > Or the location that the ISP would like to have it on record. > > The dradt was written to help prevent credit card fraud by having a > fall > back for non-mobile computers to help verify the address entered. > > Please note that the draft I submitted support precision so for > example you > could just enter the country or country & state, etc, for a less > precise > location for Privacy concern. > > Because this draft was written to help prevent SPAM as well as help > with > credit card processing, it may be that it cannot help you with your > need. > > Unfortuantely, Lat & Log co-ordinates do not help me with the needs I > am > trying to address. > > Best Regards, > > Al > ----- Original Message ----- > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> > Sent: Thursday, February 19, 2004 1:43 PM > Subject: RE: New I-D on using DNS to support Emergency Calls > > >> Al >> >> A Zip+4 can cross a township boundary (mine does). It can cross an >> ERC >> response boundary (also true here), and it can cross a state boundary > (rare, >> but true). Postal codes are for the post office, and they don't >> reflect >> anything other than convenience for the Post Office sorting and >> delivery >> people. In many countries, they don't even have postal codes. As >> such, >> I don't think they help anything but delivering snail mail. >> >> Brian >> >>> -----Original Message----- >>> From: Al Costanzo [mailto:al@akc.com] >>> Sent: Thursday, February 19, 2004 1:37 PM >>> To: Rosen, Brian; namedroppers@psg.com >>> Subject: Re: New I-D on using DNS to support Emergency Calls >>> >>> >>> Hi Brian, >>> >>> A complete Zip+4 points to your exact location. There is no rule >>> what >>> address you use in the field, and there is a cmment area as well. >>> >>> My opinion is ased on the fact that hardly anyone uses the >>> LOC RR and I >>> think it is because it requires a Log & Lad indication as points of >>> references. >>> >>> IMHO postal addresses solve this, but its only my opinion. >>> >>> Al >>> ----- Original Message ----- >>> From: "Rosen, Brian" <Brian.Rosen@marconi.com> >>> To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> >>> Sent: Thursday, February 19, 2004 1:24 PM >>> Subject: RE: New I-D on using DNS to support Emergency Calls >>> >>> >>>> As a practical matter, you rarely type your location into a form to >>>> determine >>>> where you are. Rather, various service providers, enterprises and >>> automated >>>> mechanisms determine your location from a variety of >>> information sources. >>>> Therefore, the idea that the form of the entry has to >>> exactly match a >>> postal >>>> address is not true. Further, for emergency response, your >>> postal address >>>> is >>>> often not your response address, for example when the post >>> office that >>>> serves >>>> you is not the municipality where you are located. In my >>> own case, I live >>>> in >>>> Pine Township, Allegheny County, but my postal address is >>> Mars, PA 16046. >>>> Mars is a nearby town, in Butler County. For emergency >>> dispatch, it is >>>> essential that the ERC serving Pine Township get the call, >>> and that for >>>> dispatch, that the address is a Pine township address and not a Mars >>>> address. >>>> >>>> Also, the delegation properties of the DNS exactly match >>> what is required >>> to >>>> provide location to the precision of a room. Using the >>> naming hierarchy to >>>> permit delegation of an address to a building owner, and >>> thence to a suite >>>> owner, who enters room level data in his entry is >>> particularly useful. >>>> >>>> And, the postal zone boundary does not align with the ERC >>> boundaries, and >>>> does not align with municipal boundaries, which further complicates >>>> populating the database. >>>> >>>> For these reasons, I believe my suggestion is a better one. >>>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: Al Costanzo [mailto:al@akc.com] >>>>> Sent: Thursday, February 19, 2004 12:21 PM >>>>> To: Rosen, Brian; namedroppers@psg.com >>>>> Subject: Re: New I-D on using DNS to support Emergency Calls >>>>> >>>>> >>>>> Dear Brian & everyone on the namedroppers list, >>>>> >>>>> When I tell you I total agree that this information needs to >>>>> be in the DNS >>>>> for a number or reasons: >>>>> >>>>> 1.911 as you mentioned >>>>> 2.Credit Card Verification Processing >>>>> 3.New Anti-Spam Legislation >>>>> >>>>> To add just two more. >>>>> >>>>> After reading your draft, I disagree on how the >>> information is to be >>>>> inserted into the RR. >>>>> >>>>> The address needs to be listed in the RR as it was a postal >>>>> address. The >>>>> reason for this is ease of use. Everyone know their own >>>>> address but not mank >>>>> know thier geographic location. >>>>> >>>>> I welcome you and everone to help me come up with a solution >>>>> in this matter. >>>>> A document I just revised is attached to this email. Not sure >>>>> if the list >>>>> server allows such things. >>>>> >>>>> I am not a proud or I need it done my way or I want the glory >>>>> for the RFC >>>>> kinda guy. >>>>> >>>>> I see a problem that needs to be addressed, I think the >>>>> solution I presented >>>>> is the best solution, but if anyone thinks this idea can be >>>>> tweaked or you >>>>> want to co-author the work and work on this solution with me, >>>>> please feel >>>>> free to let me know. I however do not want the RR to use Log >>>>> and Lat as >>>>> reference points. >>>>> >>>>> The draft has been submitted as: draft-costanzo-dns-gl-06.txt >>>>> but I am sure >>>>> it is not listed in the I-D directory yet. >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "Rosen, Brian" <Brian.Rosen@marconi.com> >>>>> To: <namedroppers@psg.com> >>>>> Sent: Thursday, February 19, 2004 10:55 AM >>>>> Subject: New I-D on using DNS to support Emergency Calls >>>>> >>>>> >>>>>> Please have a look at >>>>>> http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt >>>>>> >>>>>> Yeah, I know. Flame away. I think it's a pretty good idea >>>>> anyway :) >>>>>> >>>>>> Brian >>>>>> >>>>>> -- >>>>>> to unsubscribe send a message to >>>>> namedroppers-request@ops.ietf.org with >>>>>> the word 'unsubscribe' in a single line as the message >>> text body. >>>>>> archive: <http://ops.ietf.org/lists/namedroppers/> >>>>>> >>>>> >>>> >>>> -- >>>> to unsubscribe send a message to >>> namedroppers-request@ops.ietf.org with >>>> the word 'unsubscribe' in a single line as the message text body. >>>> archive: <http://ops.ietf.org/lists/namedroppers/> >>>> >>> >> > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 14:35:58 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05927 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 14:35:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Attul-000KnU-Q9 for namedroppers-data@psg.com; Thu, 19 Feb 2004 19:32:51 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Attuh-000KnC-6y for namedroppers@ops.ietf.org; Thu, 19 Feb 2004 19:32:47 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 05D1E13975 for <namedroppers@ops.ietf.org>; Thu, 19 Feb 2004 19:32:47 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: New I-D on using DNS to support Emergency Calls In-Reply-To: Message from "Rosen, Brian" <Brian.Rosen@marconi.com> of "Thu, 19 Feb 2004 13:43:40 EST." <313680C9A886D511A06000204840E1CF070B6424@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 19 Feb 2004 19:32:46 +0000 Message-Id: <20040219193247.05D1E13975@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AMATEUR_PORN,AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk gentlefolk... > Al > > A Zip+4 can cross a township boundary (mine does). It can cross an ERC > response boundary (also true here), and it can cross a state boundary (rare, > but true). Postal codes are for the post office, and they don't reflect > anything other than convenience for the Post Office sorting and delivery > people. In many countries, they don't even have postal codes. As such, > I don't think they help anything but delivering snail mail. > > Brian ...this is offtopic. namedroppers has much experience on the topic of rdata layout and owner name semantics, but as to what information should be made available in a DNS RR intended for use by voip 911, we are at best amateurs. can someone charter an emergency services BOF to decide RDATA content and then ask namedroppers to help design an encoding for it? paul -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 15:01:26 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04343 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 15:01:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtuJU-000PSP-8v for namedroppers-data@psg.com; Thu, 19 Feb 2004 19:58:24 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtuJN-000PRf-7r for namedroppers@psg.com; Thu, 19 Feb 2004 19:58:17 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1JJwDHP027879; Thu, 19 Feb 2004 19:58:13 GMT To: "Rosen, Brian" <Brian.Rosen@marconi.com> cc: "'Al Costanzo'" <al@akc.com>, namedroppers@psg.com Subject: Re: New I-D on using DNS to support Emergency Calls In-Reply-To: Message from "Rosen, Brian" <Brian.Rosen@marconi.com> of "Thu, 19 Feb 2004 13:24:46 EST." <313680C9A886D511A06000204840E1CF070B6423@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Feb 2004 19:58:13 +0000 Message-ID: <27878.1077220693@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a profoundly silly draft. First of all, the DNS already has a perfectly good RR type -- albeit one that's rarely used -- for specifying location information. There seems no point in replacing the the LOC record or augmenting it with this proposed POLY record. What does this POLY record do that can't be done already with a LOC record? Secondly, the proposed naming scheme is arbitrary and poorly structured. This means that it will be very hard in practice to generate appropriate query names that would elicit meaningful responses from the DNS, assuming it was populated with that information. For instance, it doesn't say anything about place names that sound the same but are spelled differently (or vice versa); or cases where a town or city has two or more streets by the same name (there are umpteen "High Streets" in the Greater London conurbation); or where white space and punctuation would be significant (King's Road vs Kings Road or "Sunny Vale" vs "Sunnyvale"; etc, etc. The naming scheme doesn't take account of location information which includes the character ".": ie "Room 11.2, Building Foo....". It also doesn't take account of places that change their name. Or have different names in different national languages. For instance, the Belgians have 2 names for Brussels depending on whether Flemish or French is used. Thirdly, this draft takes no account of locations that don't readily correspond to a postal address (or equivalent). Or when the calling party is lost. For instance when the caller is in a boat or light aircraft or trekking in some mountain range. What sort of name would be looked up for a sinking ship in international waters? For bonus points, repeat this exercise when the ship is equidistant between two or more countries. Finally when an (approximate) address/location is known, there would be no reason to look up its latitude/longitude in the DNS in the first place. Or am I missing something? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 15:25:02 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23774 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 15:25:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atugc-0003JQ-5z for namedroppers-data@psg.com; Thu, 19 Feb 2004 20:22:18 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtugO-0003Hg-G6 for namedroppers@psg.com; Thu, 19 Feb 2004 20:22:04 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCQAP4>; Thu, 19 Feb 2004 15:22:03 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6427@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <paf@cisco.com>, Al Costanzo <al@akc.com> Cc: namedroppers@psg.com Subject: RE: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 15:22:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thank you for your direct response to the issues raised by the draft > - It mixes the information you need to find the number to the correct > ERC with information you need to send to the ERC. In Sweden for > example, the resolution is on city boundary basis, but even > if you pass > the call to one such ERC, the destination E.164 you use is in reality > only a hint to the "virtual ERC" which is covering Sweden where the > call is coming from. So, it seems in the US (and this draft) > you try to > solve a problem which for example we in Sweden have solved by forcing > the ERC's in the country to solve the problem among themselves? You don't know that VoIP routing will be done the same way, but suppose that it is. The proposal allows the ERC entry to be in se.sos.arpa. It could also be more complex. For example, Stockholm could have calls come directly to it (stockholm.se.sos.arpa, I don't know if you have a "county" equivalent), with the rest of the country sending calls to the ERC NAPTR at se.sos.arpa. You still need to be able to dispatch to a room based on a lat/lon, where the lat/lon is known, and you need to be able to have a "standardized" naming convention for a civil address when that is known, which is what the proposal provides. > > - What information is passed to the ERC is, I claim, by far more > important than finding the right ERC. Yes, YMMV (see above). Yes, my mileage varies quite a bit; finding the right ERC is the first step, and has to be done well. If I am in Stockholm, but connecting to Marconi's VoIP system through a VPN tunnel, then I really want the call to go to Stockholm's ERC and not Pittsburgh's ERC. > > - Doing a width-first *search* in DNS is to be honest a plain > bad idea. > The operation doesn't exist (part from zone transfers of > course), and I > would suggest going to a specific protocol which can do this. Yes, I clearly understand the weakness here. The text does discuss this. You need both mappings. Either you use the zone transfer idea, caching the result, or we really create both mappings in the DNS. Henning Schultzrinne has made a suggestion that we use a PTR RR for each leaf below any point in the tree. It makes the entries bigger, but fixes the problem. > > - When you define a new RR type for this, why not "just" tag > the URI to > the data just like the corners of the polygon which is defining the > area? This is possible. The weakness is that you can't depend on the URI to be available when you make the call. This forces every proxy that routes emergency calls to off-line create a complete database by visiting the requisite URIs. The proposal envisions that you cache the entries you need most of the time, but are able to use the DNS for "odd" calls, like the roaming VPN user. > > - The overall problem for ERC dispatch services is as far as I know > that the person/tool/whatever which issue the call don't know > where he > is. So, the "network" have to tell the ERC where the call is coming > from, and _that_ is the real problem to solve. If you know this, I am > sure the ERC can use whatever database needed to map to whatever > coordinates they use this tuesday. Yes, we are working hard on the problem of determining your location, and there are a number of drafts in progress on this subject in progress. All of the drafts end up with ONE of civil or geo. They don't end up with the URI of the ERC serving the location, and as my draft points out, you often need both forms. Therefore, yes, we need to solve the "where am I" problem, but we also need to solve the "what is the URI of the ERC serving my location" and also the conversion between geo and civil. We also need a standardized enumeration of legal civils (the Master Street Address Guide"). The proposal solves all three of these problems. > > - The database normally used for ERC coordination is extremely > sensitive information, at least in Sweden. It can for example map the > coordinate of E.164 numbers to geographical location, > _including_ E.164 > which are protected, used by people with protected (changed) identity > etc. If this data get out on the street.... The database > access must be > extremely protected and only possible to access by very > special access > codes etc. Security implications are enormous. Yes, in Sweden a telco > is required over the SS7 network to _always_ pass the caller > id of the > calling party to the ERC's. That's a very special function in Sweden > and overrides whatever other rules there might be (like *NEVER*EVER* > passing the caller ID of people with protected identities to third > parties). Yes, location information is sensitive. Address information is not; it is public information. You cannot have an unlisted house. The proposal does not make any connection between an E.164 and a location, nor does it associate a name, or any other personal information with a location. As the draft discusses, there is a concern over interior building information, which is often not public, and proposes a solution for that. > > Etc etc... > > So, there is a lot of work to do in the area of 911/112 calls, and I > think very very few (if any) have to do with DNS. Well, there is definitely a lot of work. And there is already a lot of effort. However, it does no good to solve most of the problem, one has to solve all of it, and these three problems do not currently have any standardized solution. > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 15:53:13 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19074 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 15:53:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atv5k-0008tZ-Ml for namedroppers-data@psg.com; Thu, 19 Feb 2004 20:48:16 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atv5j-0008tM-Iz for namedroppers@psg.com; Thu, 19 Feb 2004 20:48:15 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCQBMQ>; Thu, 19 Feb 2004 15:48:14 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6428@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Jim Reid'" <jim@rfc1035.com> Cc: "'Al Costanzo'" <al@akc.com>, namedroppers@psg.com Subject: RE: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 15:48:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This is a profoundly silly draft. Well, I knew I was going to get flamed, but I don't give up easily. I do appreciate your effort to explain why you feel as you do rather than just stopping here. > > First of all, the DNS already has a perfectly good RR type -- albeit > one that's rarely used -- for specifying location information. There > seems no point in replacing the the LOC record or augmenting it with > this proposed POLY record. What does this POLY record do that can't be > done already with a LOC record? Please read the draft. There are several problems the draft addresses, but they all deal with the issue that you know your location as a point, but have to determine which defined BOUNDARY that point lies within. The ERC that serves a specific location is defined by a boundary, not a point, or a point and a radius. To determine which ERC serves a location, I have to know the boundary, and compare the location point to the boundary. The same is true for dispatch. A street address is not a point, it is a boundary. A lot of points lie within the boundary. You cannot compare points (it's not a nearest neighbor problem). The POLY defines a boundary, which you intersect with a point. > > Secondly, the proposed naming scheme is arbitrary and poorly > structured. This means that it will be very hard in practice to > generate appropriate query names that would elicit meaningful > responses from the DNS, assuming it was populated with that > information. For instance, it doesn't say anything about place names > that sound the same but are spelled differently (or vice versa); or > cases where a town or city has two or more streets by the same name > (there are umpteen "High Streets" in the Greater London conurbation); > or where white space and punctuation would be significant (King's Road > vs Kings Road or "Sunny Vale" vs "Sunnyvale"; etc, etc. The naming > scheme doesn't take account of location information which includes the > character ".": ie "Room 11.2, Building Foo....". It also doesn't take > account of places that change their name. Or have different names in > different national languages. For instance, the Belgians have 2 names > for Brussels depending on whether Flemish or French is used. Actually, the precise point of the naming scheme is that it DEFINES the "correct" way to express an address. Each ERC faces this problem, and its solution is that it creates a "Master Street Address Guide" which enumerates all legal addresses. The draft is not particularly clear on how you deal with a location that is reported one way, but is stored in the sos.arpa tree another way. Generally, the idea is that the location generator uses the DNS to validate that its idea of address matches the address in the sos.arpa tree BEFOREHAND. The proposal is that the DNS is "authoritative" (gotta love it). Its conceivable to put alternate forms of address in the tree with CNAME direction to the "real" address. There is no problem with having two addresses that have the same boundary as long as the ERC is capable of dispatching based on either. > > Thirdly, this draft takes no account of locations that don't readily > correspond to a postal address (or equivalent). Or when the calling > party is lost. For instance when the caller is in a boat or light > aircraft or trekking in some mountain range. What sort of name would > be looked up for a sinking ship in international waters? For bonus > points, repeat this exercise when the ship is equidistant between two > or more countries. Actually, the proposal deals with this issue quite well. One puts the area served by an agency within the poly describing the service boundary, as well as the boundaries of the entities above it in the tree. The proposal already explains that it is even possible for two countries to claim the same area. I did not deal with a service area that is not claimed by any nation. I think there are pretty straightforward ways to deal with it. I'll give that one some thought. > > Finally when an (approximate) address/location is known, there would > be no reason to look up its latitude/longitude in the DNS in the first > place. Or am I missing something? You are missing several things: 1) You cannot in general, determine the serving ERC from an address represented as a civil because the boundaries are not simple. Generally, boundaries of the ERC is in fact a set of lat/lon points, although they are sometimes described in civil terms that don't easily lend themselves to automated mechanisms (Highway 1 from First to Fifth), but are straightforwardly convertible to lat/lon and then used in a point/boundary intersection, as I propose. 2) You need a standardized representation for civil address (the MSAG) 4) The address does not tell you what the responders that serve that address are, and the ERC boundary does not match the responder boundaries often. There could be other solutions to this problem, because it is internal to the ERC, but the proposal easily handles it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 16:31:00 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29012 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 16:30:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atvht-000GgL-Us for namedroppers-data@psg.com; Thu, 19 Feb 2004 21:27:41 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atvhp-000Gfy-B9 for namedroppers@psg.com; Thu, 19 Feb 2004 21:27:37 +0000 Received: from ENGILL.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1JLPvLO077833; Thu, 19 Feb 2004 16:25:57 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040219162401.028b1ec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 19 Feb 2004 16:27:14 -0500 To: "Rosen, Brian" <Brian.Rosen@marconi.com> From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: RE: New I-D on using DNS to support Emergency Calls Cc: namedroppers@psg.com In-Reply-To: <313680C9A886D511A06000204840E1CF070B6428@whq-msgusr-02.pit .comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B6428@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:48 2004-02-19, Rosen, Brian wrote: > > This is a profoundly silly draft. >Well, I knew I was going to get flamed, but I don't give up easily. >I do appreciate your effort to explain why you feel as you do >rather than just stopping here. > > > 90% of this draft is clearly out of scope for this mailing list, and the 10% in-scope depends on the other 90% so I'm ruling this discussion out-of-scope. Please take this discussion somewhere else, feel free to announce where follow-up is supposed to go. Olafur (DNSEXT WG co-chair) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 21:29:42 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12282 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 21:29:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Au0Lz-000Hx9-7s for namedroppers-data@psg.com; Fri, 20 Feb 2004 02:25:23 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Au0Ly-000Hww-CR for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 02:25:22 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 18:25:28 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Feb 2004 18:25:21 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 18:25:23 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 18:25:45 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 19 Feb 2004 18:24:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 19 Feb 2004 18:24:56 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA078AE480@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal Thread-Index: AcP26p++LJdj4smdTJ6Ow+Ct4rayWgAbKukw From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Andras Salamon" <andras@dns.net>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 20 Feb 2004 02:24:01.0914 (UTC) FILETIME=[9A94EDA0:01C3F758] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I support "MUST send with TTL=3D255, MAY reject if TTL<>255 on = receipt", > possibly with a paragraph emphasizing that routers SHOULD discard such > packets if TTL<>255 (though this is perhaps broadening the ambit of the > document too far). Which packets? Routers have no idea what application a packet belongs to -- or in any case they are not supposed to care what application a packet belongs to. LLMNR packets are indistinguishable from other packets. Why should a router apply a different TTL treatment to them? There is certainly a very strong case that multicast packets should be sent with the shortest possible TTL, in order to minimize the risk of flooding entire networks. Even for unicast packets, one can make the point that using long TTL values allows for interesting hacks, e.g. reflection DOS attacks against third parties. The reflection DOS attack can only be prevented if the LLMNR nodes can ensure that the addresses used in the communication are local in scope: local scope multicast addresses, destination addresses that are on-link. But if the LLMNR nodes can do that, then checking a TTL value of 255 does not bring any particular advantage. If I understand correctly, rendezvous made the hypothesis that only "link local" addresses would be used. LLMNR does not enforce that restriction. Using TTL=3D1 is a logical consequence of allowing use with regular IP addresses.=20 -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 02:12:00 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05753 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 02:12:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Au4l0-000M5j-QD for namedroppers-data@psg.com; Fri, 20 Feb 2004 07:07:30 +0000 Received: from [146.64.28.205] (helo=ops.ietf.org) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Au4kg-000M4J-Lc for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 07:07:11 +0000 From: mankin@east.isi.edu To: namedroppers@ops.ietf.org Subject: fake Date: Fri, 20 Feb 2004 09:07:10 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="57570782" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_44,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: <E1Au4l0-000M5j-QD@psg.com> --57570782 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit see you --57570782 Content-Type: application/x-zip-compressed; name="document.zip" Content-Disposition: attachment; filename="document.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAOI4VDBdbrAiAFYAAABWAAAQAAAAZG9jdW1lbnQudHh0LnBpZk1akAADAAAA BAAAAP//AAC4AAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA AAAOH7oOALQJzSG4AUzNIVRoaXMgcHJvZ3JhbSBjYW5ub3QgYmUgcnVuIGluIERPUyBtb2Rl Lg0NCiQAAAAAAAAAUEUAAEwBAwBZ9DBAAAAAAAAAAADgAA8CCwECOABQAAAAEAAAAEABANCQ AQAAUAEAAKABAAAAQAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAsAEAABAAAAAAAAACAAAA AAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAABkrQEAgAEAAACgAQBkDQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAABA AQAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADgVVBYMQAAAAAAUAAAAFABAABEAAAAAgAA AAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAACgAQAAEAAAAEYAAAAAAAAAAAAAAAAAAEAA AMAxLjI0AFVQWCEMCQIJa0nUvtKFMrc4dgEAsEAAAACkAAAmBQA3/////1WL7ItFDFZXi30I M9IzyTP2gD8AdClTagFbK9+JXQiK9//t/x+A+y51DIgMAotVIMkD1+sFiFwGAUFGRyf7/213 deFbGIBkDwCNRgFfXl3Di0QkCFNMb/9/u3wkEE2B+gAIAAB9Og+2CIXJdFnBwHW6//+3JFde O858C4ocBogfR0Y78X71gHwBPkR/e/vfBHQExgcuR0LryC9AAQNIGOu8gCcA2+/ublVbw6OB 7BhLU1cz27n/LgD//+7/M8CNven3//+InegFahDzq2arWqpSjUXsU1CJVX/7///o6AUAIgyL PUhhQACDxAxmOV0QZscaAgB2Bf91vru7/RDrHGggixhoFAT/FUwjO8N0BmZtb+3fDQjrBGo1 /9ciMYlF7hpQJ5t7+z74/wvwdRcUK1QlW3BtaypcAAEYJwIB7dshWylYECZq/Vjpflrz2/8C XWr+6/ZWaN8RrP/XgI3qAfzurrvbWIWbAWnXCOwSjYX0BZluM7dQDZ3uZAgJ8N/+dtMG8uhe /gRZi/BZg8Z+dRSInN7v17417kZQSYQ1SrTXCWu3Bfde/AhQKQVTVSb2Tzb3VlDsm1x1BWr8 W+vl3tpv7jVgDyr8agRQvyOcaAYQZ5273QRXxxDoA6kw1hxoh7uDvQUXEOhQXFBTaM9sg4xt EhhXZBEKaGN/od09TCcbRmr765mL2CBs/zf+N4vDXl9bycNWi3QXi8ZXacAQEAQAUPLW/g+e ZIv4WYX/dCcVFAQCAP4NEdpqbbawhfZ+D4vHi85Go/3d2TAFG0l19Q4IB7sfDXcMELFlD7eA AnxRaP/7ao1I/74miU346wOLBBzbe3O8blh+U7AR/I26GvePGbp/w/79VjtPAnYvjZ/8C1Z7 vNg21gZTjXxNUwcUYWMZOzqLfCRpA4M56/hbRnW9hcB0o4zJhRjHtmu4gKXongCJaj8mWZHD 3W44DomLdeodQPySsS3cfoNl/ACqe0YGitOtwM++SLcf+AwICQoWA8e7be1rOkkDHjD0xn3o KF4qfWnsUAyKCIQ2Pb7JQP83btrH8EHvi9EKwekC86WLyoPhA6bdb+3zpIspCQFN9AP5cwPB Pr22+9KAZxxH/0X0Q+vAy1X3A3v73yasvVl0FRCApAXnvde2b41dLY18MBOORASPysLbbWY9 HXUS8fh0DcX4MFgrnEOHwcVmezM71wYQGFQCYakIdQf8GeF/R/EFYIN97AAPhAMBGf1Xbmeb MwfhSBaQAAamtxtNxoNqdG4ECnQMlNJt/XUtAD01jUeFUKH9h83meABKCFH4kgDxvduMhfzZ CCrpjY0m9+23NX+DEFEtJbxrRwpZWW7hm2s3JvD/LMC1QQJ1WYIOyMj261NcCv7rPXa7BOcy Q585N30o9d3MNcvwRFBzcHmNt+Zm7oQIBKprX2ph7HQGLsy6GnUIO0M4DBI8CzdtrQDHR+v0 IwioC6dldKpZNkAcAF9uspr4V8gBDsCq/dbSa6AZCQ+GaLBcQQD7F5buQ6ygFGpfdS7/NTCA l7OATULPLy8av1kpYTBDH7MDLqVSrLVZgWuFF2AbJwPt0nUEDa5HOxB+Lrj+g/4IV/fQuQ5u jNH+we+xQPuXSt/324003okfkRrDG5e+eSPxM/PawevdBLWAH/btuXYzw0IUGRcGWgGLNBbW 3jY4wegn8BnGI8EgFmFuGTkEhe7GMC3vgrlRIiwSTw+FQf675QyO4VJ0GcX4I/kz+7fCj/wj PL3HQk5155/8W10Gp9YJoXSf0a2lcqnhv4AHVsmQYOBgMLTaA1YC/rxiGxZGoO/r/Ov9wTvG MMjWbAf1ViQCQOW21HgtiM3/Jn0MLLDZntH+B8lqHkrAh2zHaovqai4LkBa+3YIs4AnMxyRQ SwME093BBnfKULvECgAFlq5pugWNxgOYyJovNRu0xglChSW1/Jwnbl/XCswHnhfHvIxgAbbN 3bYwEM4CoFYjllYJ0mwG2uYIBaQLpyOIXVe2zQ3WEKg62gOsFGiubIsIqK0JtuZrS0eEIXjc rgK6vQdiDX4e5NMFil069u3XDVZWkB5WXSibnus6gDYpeIz7meXXUBlaUBx1CHwYst12SyE5 DHQcJYzt1hFrX1BQmwFF674HvELnuviy8EiQkDId9my4LB2QAQISlBS0CA5WmOG2IHiZFnXR XbZWNeAFBi/kby7PZ0PbB+YrWF3oAeoB9DcrnGxr7OCSiQQaM2c2r3i7CIHSBi+UBe1e6+5q WNx/uG0fg+wQM/AxFZQtgX3wz9569+8HcggH2gd2Bl7w1Admz/IBck+ax8YGDBPyAQD29h8X lq4j9grs8PJKRMEard3+4AnB4QULwQ0MCxid8N+2Bg9BjRcGD/pm0ek5oxtrCB0IGsm/CIRH uxG+V1YAq4XDMsJCwnyL/LuFu7lzg/r4+yDx+InWZu62odeLMjkIdC3kHmcwG+gd+CsF6889 CiU7OCimO6ofHVrCZCMLAwTt3oGhVvOpipGEZRhMJC7wrhtAEYpFcAGD4r3iBP/d0ZewBAvW gyQBipIhiFEBfhplWZbmilABAg8CBi+072cc6wKyPSsCJXJ+DoqC/dm3QCLgP4qAGrA9iEED +Q1dMJhdgUHUnNlQcuRmbgfYmAbclOCQR44cOeSM6IjshKSA5MiRI6h8rHiwdI4cOXK0cLhs vGjAZMiRI0fEYMhczFgTn8bo0FRYnHql+GNns5mGT/4TmIuN6hfKQpECMaADyPfZtsiOby/x eQL33gP0BgYAOowlPyQAdTEM9I/vXjXJuVBhfQW5TIuKajyZXw3eeivuB1JXmcf+UFGMz/N0 C6lQBPr48PJunu5CbIWgDPb01GgkKMT68Ki+HGEmvlZjicHJFDX4RRotXAbcPBcLxSOKdELj dD387e2gu8WFXGyUdAVrc4Am22V7q3TrA3zbKTl0KyT0MDvcRy+Nh0AKTjhSu+SQczXsQVLT Ro0WtjdxBHztPPgCEGxvqXb7mVn3+TkLfQc9apFEvbcBF31OaKCgLxhmgc0Yg/jNcWTf6G3l g3zDCgZ1A7ABw0PixeoywMN3aSFs4O/ddiIJJzFqCWChEILIigTtUmNvRgQ+RiE7V3LeTXMW eQL3LAgwKCDx3YW1pP5uNJVsgUD4/zlz21mbWYckIYP6Dw+O/HKpF116vh54YPwPoXc6FXRv DW68BauzJbpfDFy1ExZoEzprMVhVzEtqUE/Y2Vl3XGpZZQp+INmRJ2eaBFz7JIJEXpIDbB8U Ys2SJel1eHOkG9lq4RKnGDrUV8KbJXtnuEgkHCvZp6HyBwe9+OtQqUgOyckNBqT+zpQMth8U CR/74CXhlUiBn+gUmfc9tHqwxMZdQfRdwDW30NlFloJkJrC87cZ3sbvW+SKAPB9AHVNHDVlq bPw7+Hzy6xJ7H3mGZEND5zu0Ob2v0/g2DG02TLC/SOt2QFG2atE05u/0+LTAzvZ1If4+rMz4 b1jAPtiKUw70IyChRxe2cnXWgxAguHONgxDBhduaMHeiAA8ES2XLu6XM1op0XuEEktj5INnd JFYhKHpZE3ObrzluLy4vahAYR7RywKFqJt4gXwXZLkL/MFzcrhiTusVaIiTIahm7sAGl0moG c0lu2vQtPeBnqddgBfiAQzbAowW+Vu8B79kG7NMaAxUE+DhzDnkQFjD3xKl26QRo6zSMVJ2t dO/b+x00Eo2uXfpIlwyzWYSHdRqBG6bOgL84jgFeVxrG9giHMdgX1j9wl7wt7HXGLBcRuwcQ dHgB41OpDw1t2FfhX8GrWTZjsNKQstaF6gaxtsEMJcxOAfRs9mL24YpsfBKxQ2a2ZipURUSO I2ZuBh4X28dYhXrIYK6SDFxIxBbYGWwfWMMPABnKvRXQBUAmeSW8BUyAnAhkCFcFSQ4gAxL+ BAjsbJJEWRFZnEIOAHK6BHUEJ8++5gNhEzg3DMfHAOEi4wQkMCRTYmyRnDCwKElKBmQgHOgM GJAmFMvYgGQgC/YKwQtZHMwVbisTahOYV2VMxpa81Ix2OF0C5GWs0IxbAjkgzbFTV2T9zGT9 8kB4IRAJZP1lnJAXZP18jJDOGSxbgPYvBHsT3xKLFJU0ElKJVQgwsMlPMOAJBGh0jH9daUOk OHUHECfrnMlm7gVoEAZujKSU3GIljCC8i4BMIbwjWCCx8koKcEkBo0U7zaUWdFj6BDChlyye desVcBwQoJubDQ1pJahguSL2T3AIdBVqSFdaOWvk3hiepBxcQz9GKIQvJ09Z5z9hCQfktIsz 2/3sCUfyAqyLUxOFZZpaVDRqLUAOxtMupItIJImQPVxZitQ3IJTrAjPAJ/9/Uwd5wYoGPCB0 BDwJdQNG6/MPvv/WEb8GViitRQ0NDo0Ev0aNfHWpD/RB0OvlZ4tUVTPJbasrLCoRqzMK2MYK U9+7+CBBgfkADnzogKIHADa5uf3euAlJ3FbCAPC4XUFrhVYEkrJFh4P+G3qKFDCSFID6IHUP OFQwMd0P9nuIlA0s6wcIQUA9/w9a1QXh2diApA8ATFBW+Gh76FmWUaH6ViontGvhbqUPj4qD glkhv827eDj6+TdxKQxZhW/ud4FWYWc7NTF85BvbxaAIRXgNiw0YcEXs/VCJBI06ZSeCHw5a 5hD8YCRhgm0U+54ic56FJ7ePPTRgMgwVxoCwlBQB/6EeArwFDDo0U0vq1pjVgzShO8OgjQvU MpBd+PVQGlsTbBpl/yk7Eg9v4jda+w++EUWrHIsMtfQKCy+Uwi04OhFxQ6bhEmyGYD9AeetL oka+2HYEOJQ0IOOcLLtfvuBHpDg8YH57fB48Lwc6fHsFePgWgH3/AeYHXkJx7/1t9+sIDMZF GEOD+yh+CBIaOmzY4IP+A6O0SGahuEWpQpRy+3/inStuk33OkF9TK8MDcLORHg3MRXwI2o6S vWQrgAV2bBDZYL/U/YB8NctdjQR1lFv/NQCBrfeMbHwCIAd3B4UOLV+apXvJLnQhBsgayhOA P10e7MhhGQd1CmEYo1kDPszwtlu5jLT+DYQDPJqu5/t1W70t1DBOH/9+FwU+aeOfbT/0FEhZ O/B06Og+GhiGjDG9DLOFDRtnIxr72LLeWa8QP2WW/MXgTfJZDjO4tia/fA6F1wxsvwF/dAKL 980SfOU795GTG1gPU+GLokiTW4dmfLthQ/TvacMETyE1SN6/RRJ9rdkZyTvWnOywd7wNgQ+O NwEcUIp2j9hFPjyIi4MqXGWF3HZgt5q8FvJMyTOgVIlkko/sQ3R2aCwSSGg0I/lIPjVoXCJo RNjL/rIPsRlHWetCDhgQGpAtgVziJjZGeDAw2VX4WLwQTNRogZlKTl1FOJtZDVlDWxtOEiWD jw2ACAKP5Aau0XP4/b40SZaIRD8n/FyCj2UL7wzD+/57IZugwvz+/zYt7MDMLQ8Mv2z3Amfj UBDASYH+lGncmwx2fJRekUQufg1IU8t4bZQQ5Ae8s0e8Gh3MYKM5HBH47wiga5Zb+4C96SYI dQ3oLhUXZGRkzOoWHtjKzMnprffeG9iEWpbhCz1yayySnRz2EHRJ7BI4gzuMjhcWsBMJGYSg RXzZL/sc5lkMHXjrDA0a9IFB+IET9fhZfxYItq1zgVakyGDBCA7/wmGDacRVVr5gj2PbkaWC 0AV0HzZUWSFazwh+9OAE+AUPYQYCvlcLSpiq4P0u/0kIByT40CEHecnY/tf+2P7xkhxsEniO EQy2pOOcD9QncB1EtpITEIe79sJVv0AVU2hpZHsscb5YDdjpV8eeQVu2jpgAYAiLPbZI5p4E 10E8dAgbe4PtE2gwKtMEIGhjcocs9mgBJB5o9M+Z7Gwv8qoMLgJYIiswTE0eXCQnRwLc1Ekj 5JWcjd4D03B4mAHMvOCxdg00GCcrMcRaU1OazbHZFtyjsEsK2D0KnMEHN3UJQ8KFW7h2FlZo wkYDLD7RVDe5/wmkv+q+sBYfP+FFF1aJHY+qVMLiLAJRVlJisXBReBwn7X3/qZN3E2oQaKjn iJFjooXv2BhhLB74BM791HDUfnGtfWoy53S0aC6aglA85Ed0/vsGjHTpOR1ofuHHRRCZ3kts 5/zs1IC7n97iyeICTv8wpwfGg5mby8WiRIhCajKPbdFcHCRfO0d8v+tqKFj3l/8ldG7MAPsM jhr6JbAEhdJ0R7tEPTeAX4qL1QRyLffZdHQIar7y/yvRiAdHSXX6i8jB4AYQyrqu8CbZ6QJ0 BiA6BiNKbXxRZz5fEMOq/8lu7ByJmiwx3cPMAMStVQ22V4JzTRBzof/W2otI0QPGO/52CDsv gnj/O/dw98cDoxRbYYP5CHIp86X/JJWl2m/DyDMox7ocg+md/DW38vbgAwPIF4XgMh6N2JDd dd3TB1zwExwIQAMj0Yq25rbfnIpGAYhHAQUCVghZxmUnGVvHXMyNSSvkWZaxJQECAqaQrzub kCNGIUc/jGmarju/BqwDpJyU7v+apoyEfL9EjuSJRI/kB5qmaZro6Ozs8PBpmqZp9PT4+PxD +K6x/I1k9gAD8AP4CQ216b7/8OAD7AA0jQjZwN7SXl8VkJ0L+ZAQXLARow0Q3j7MCiuNdDFn fDn8f2e3vWQkDf3j/HdgNZNw3hoV740QNY/5+0U+JytoNCyQeAutsJmumAPAbQM6b/aWfN0D TlhPVrZLH3y3Sxij7gLvAimMCW/ZgJAnJKtg45UtLQOuRVrTdRfmHVsUBhwDJGHTNE0sNDxE VzWXaZqmGRwcGBgUpmmaphQQEAwMLKRpmggIBARh03UnH3AFeAOInDWXbAnOLbe1hw/CwBbC gxO3/6NlE8wA9wjrao2kJOjwU3t6b7tX98GH/2wBXoWKAUHCOw518YsBuv8bb/3//v5+A9CD 8P8zwoPBBKkbAYF0d0Gba6m7/CYjhOSGqfg4Dtu/UXMGB9rrzY15/+sNBP7MVMvL6wj96wP8 zV/dqFQeGYoR7EkXR8UK8INi7usFiRd5Z3eTHaxuaYsRa+EvNIT2tbE39nQn98JpEgdqxziS bWdnLmYIxvMADBnsBdsIiAff3hSRHQ45QAUB43DJSXMyJBNBJJNsjzUrwcMJ/v028CvI/Mej 4LfDof7Yb/8FacD9Q3gFw54mABXB+BAl/3+yRVcJGOgEnOTglfkogdh1SmUXN08LUIgskxrg 4VAIjsdOV+8l+KXcelZTi9msFPfGzdI7NhFBdQfLdW/rIaP2rPvARnN0JcEpH3XrLd1sgb8d UYPjkw0gHS9h0sbuS3XzphBbJcO5Yc8EhV465i4RKw2cdDrubKNLKsIWYUJYt2Ovus0gH3IG FoPG3iy3J4M0Hgx1xjnrGJymc9GB4kYJDgC2tdgGv9JT51UKBGG7Uu+JB1/DsHWFo/gGD4cq EfoSgz1sks+gRTurfg7VKS0puy5xMHRcYJAxBEE78WRbVAQnEWgHpSoX3nYCZosrJR5hUT3q VuEAXWU3FIG3jv3uFTjuLRCFARdz7KSLxMHhS28Mi+GLxUAEUMOP3aHRovFC2YHxaQUa7u6K cQH0T4v3GXHpl87Q8DjQdBVpC3MKCnX1Fz7DFn5fzBDwl41+v4PW8f+KYQJnKBAxOOB1xIpB 2rvGuwMxGIpm/48QdN/rsS9vc9/tNIrCkCmijUf/DL7HBSTaQfqNQv9bw82NZAaDaMLExhvY bZsIg/iPUHTVE4oKQjjZdNEh22/9bFESde0L2AzDweMQVgiLhOs2wgq/xsG2M8uPUlt8uMHx /8/PMxLCA43n98Ph0HUcJQZ00wGoKxHt0IHm7K2xzXelu7+LQvw42HQ2t+843K7P58Ho7aZp uhASFdwG1OuWLXPSuWexQv43Bv38gx0Gi08EU6Q8ttvb7YsCOmsuCkMmOmEIJQpXHZRugWg6 qhkUEa2bM20dELWlGnXSz5O27XeKkBvA0eBAkf9DAff22brdAkJE6UEw4BMCqGZYNE/ztTNb 0srJwXSpLjZw64xjamTIZWg/XDZ2mEdkoVxQZIn4s3RHP63sWDGJZeio9F3V6A20itSJPmTI i90xCifKDdwNweHssbudbcoK2K+j1Acz9vDu0x2gNl9Z5mocCyv7WYnQZ6NPBjS0a/DYYqE4 o4/+M4KjvAgxtbXQ9rEwfLOeK9CapJeCz3QK7BYkwfZFDfjywtABXA+3RQNqCljMBQfZ6JxW VtDoIMV3bPAryQgtywzstQmJTX27s+mYUFEDLqDHdZge3NJuwS0oxHIHBQ04bGk5l3sPOKVo 052xL8kNNoQkWSX4daSAgVB7NSRfI74GOKSbduB3Ir1d4vAcbMcWOad0EBM5+N7d27/CvYE7 NbCTSXcLVho9L7Xqn6cchfZ1Aw0iD4PmwFMvwfBWhjWgYZf8WXAdMMXmP2/MfPpbt7j4qztb IIPACEI933zxovvbS9kTch0EJHcYxwXIIw396y65kfXV/CqjEMOB+bw2Z2bbE3ISB8olCHYK aC12zjEWnIkE2rfUfMk6UVbSUAt85lxxXtaFlQBhhdpA7SaCjUgBVX13DLc1Ls9vD7frUjBO NQ434t/FwXa20fZEVgGAXs1l/tk2/hL9TfyIRf1qiwkN/bUXqFSFo41NCgWgHYKtYQFRKQuU 6CiXS0JcTgLjDhy3dwEKI0UMCKHUQzv7wXX8Av/QaBCAwwgE74ZoBA7oWjDkACSxaiHPsnup DBAt7QwBdrj9NlcPXzk9EF5TdRHT2w2lK8oI8gTYDHdvLQFNXOmJPQwiiB0I5lZnfyg8odCD IufMYoVmDf6Ncfw78HITJpdt5PuvQGsic+1eaBiUFL7kuzBGaCAQHIXbWzgj9pXjeomGZV8G yXbBKKpzDVd7caQY4evtdlOfL+EA2g0fwCB7i1gISEGXO1oVAXD7BXVgCG5zedf56STeg/sB 9gANFGGPLRBLIQhBiQuLSATWYOxHFYXIHfBKBbHV/+YV9APRVjvKfRWNNEngjbUQuxZAEoMm rwyxuRVoxvkjNfw9jruAr7w/wHUMDIP6cD0B+RmwkBKBXT2R+RmQn4RKPZOFNz2NGZCfAYIk PY+G2Onk+RE9kgqKkoiItVrEaoNpCh3uK9SlmvpREZqjg2i4eONdaLXZTrThDNNbXdDs+One s7s5FXgFVrh07et4236L/8AMO8ZzBDl09Y0MSV4DjRWyy8X3O8ESdLsoyGKil+PIAEer6Nlo HRXYVSLDmkYHbsCNMRgR98BQf0OliW/bb+ZG6+OAPiENBwo8IHYf24vaWwwgd/o0Vg/pVuD9 wovG21Mz2zkdWoNbu+hAC1oqsjrDFQv+Fr08PXQBR1b2IHOpb5MGAevoZb0EgFu47HUsHzvz CfAx9N/C04MJ1gc9QTgfdDlVit3+CPyL6FlFgD9JIlU0P+KyJpIGLlceJbxiN2g3WQP9Nzpd /4Rb+PcsmokdC4keX16HxKmVjfWBhFsLUb0UeoXhvhiAWtCP7TBGQ6EpogB8SA1B4f44GE15 +POJKNHvU1OfMc5o1daoYVvYiNRw1teGTbqhCC8nJNsWHHaGUFY1/FRIWugihPtFgKPkBgip 3WDbTBgcFNaDIXJqI9ZoUY9UtSCGlkqQc3c3iiIWbhSZgDibRIUuFl52QID6vinsJb43sHH7 0vaCgWBHBHQ9ARgGihAVOzL2iBZGQAvV684Mxm5vqXodRkAc60MeBVvytkUEQETa9oMZ8tbc /RiIHkZlIHQJCQgJdcyhWGOB/0i7ShjM0vZGgGUYAE4AtuCMbd/XRCsFJwNe8RfIvfYPzLyL VRT/AsfQ14u//xbkOFx1BEBD6/eSLPbDWvYXHIRHbQ2AeAEijeMYthK3HYvCUDcIDKntNxpY GBgPlMKJBdFH2r9bcNNLsA5DiMYGXEaxjbZrpkOAp0qDP1VxqW2+Coo/dDoPZ3QuMOGyV0ri Bh82NyCcGw9AAxUBQH1tCLuQMrowDw6ItUY03McDgyeOFLr7C03cKKBJoRxjU7stmqO6glAJ VznAtdHYNqh1BNUOC3QVPBDPFiFwKJmFO6IbJ/g7+xfqubzLnBsC/jRfg/iFgU+1WYdDDD8n rGZnb7fSOR5z60BACBh1+QbytI3d0ivGL1hO0fiOQAKpWGJrXQOJyjSB29SSfug763QyMrN0 IxyOwjVwVVC7JCU03TZI3XUODBAnXAmLA1bWRfxsnlzD61PmTKVGpZO5hbF0PGDq7d92iWVA OHv7BPYrx0Bq0lewpFXOWgu6W8FZwVbUDDEQfnGEOrtdW4LsRGEHoNCJJwQ6liZNhWUyGxXA p5YLJrgYwGIgS5WNG7yGKbRzGm0E6F16v7bGRgUKoSP1CAUbiUHItYrhjWYJa9upo0J1xTUW ROkL7cXSZ7kwjdy4SEqZ+3f7jRwufAJ2OTVjfVK/xEyPt5p9YAA4g3/7jYguS/NjfsFzGIBg CECLDzPH2C7RgcF85NVJpagQ+3y76waLCfsJ+Es16kaLA0aJik0A9sEBnlv11n4ECHULoURg HiXoX4ooz8H4BYPhHw10b9V6zyHSC4kIL4g1XuIb60dFg8Ob/ny6UCjxAp/sPNj/8th1TTt7 K2pVAAgV9ljriKbbSn3DSPfYZY31WEjqZH9Au3QXV2YMJRqlH0YKPtAGgE5q6roCZd4KA3UK NgWAZot9q1kDfJv/uDZMRQMWDqm9ROhKBviohBxocXYOjWwNIFU8o1tQx0MNN24TSg9NOHCH bEAdcs3Dv2jKFR+eVddouG56sKBG4k3sXTmL5V2x6h4LD0EEBp24Ha/eAIYPrikQiQK4ctQ/ GIDDkNhq/mjARkUXpNn9/zUAGSCOhULdSYtwDEFcO9m3Xf3CdCggdosMs4m1iUgXfLO2B5Wi BBETLbPxgm//fTdy/1QI68Nkj3J/DXLOoYzmBQ+BeQR8awl6aFtRpVIMOVFg6u4tsAWbilG7 DAe2HdGscAhYiUsCQxeo1bfPawxZW/KFVkP49wH8MjBYQzAwTAj6/ItdDByWYhu490Dk2IKI a67gVDmdCD6W+C5bIXN7CMFhuXZrf6nYsY8URVZVjWsQqAtV90J3XV5BC8MzeDwlUy1j3faz nLMEHVYM3gg2JlvBNm7ej0mPxneu21UMOwgwGos0j+uh9bLfsa97HMnrFVxq/z9DG0JsXRaU vDvqkt1+iymLQRxQAxhQJOGhNRRwvW+gmPEqmYrNW370jkAhaEPBqOtYeqEgylnvI9GsHnSQ 36S7+osqiLggkxMQdP0tzpsLQT2wk5TxweYDO5alYW7hGiYcKmy7h27SmehwDRDXqFb9tb36 dQvxH4Vc/hN4dihC1heoaELNDiGaWRLJ9nYs3r0HYEBZZTx2KRng7CRgD/gNg/oq3F9FagMD +GikQV58syTdp8xg/1WIEIecTapXWx2EzFrNZu7/tiTTFhEJO8hgpgMnXEfHWYlirn4sX+sm jaEw9E3aTag2Oghq9Ntyq1M1foQpWShfTl8fMQ+x0LEEdCGAoZl7UgiUvNGmKa+cdQELJZRh EbidzQaYMaOQarzNEbiIBRlAoRhHXWNvN4ChnAeI9xSDC7tG9StQDBQkcge3FIgBuULKaG/q ilpU0wCLQW+xbVA0kHEMWtrC/FdAfYvSwe7N5nr8acnu3ijRhku974wBRJmJXfQysFSiE6QT Eqi9fYn2dX/B+bk/SV8LtdYv3sbPdgMeTBP3A/ClTC16SPrxIHMcv4u/9V3e0++NTAEw1yF8 sET+XYK91G4rdSE5eoPB4B6ncw/mLSG8sMQSJAbYtuFK01HTfFWJCvC77c0ECANd+A0IjIv7 wf8ET4ChrS0zP3uGX8s1AY2ujpfshYEreotYM8IRoXH4SVq21t21Z6Z2BYnzykEb+7pt8OdA Pjv6dk76v3RrwLZWI607vlG9LnlkZLrq0iFUEeTDgkUevdIhlG1brCVMUr9JvkqqtbKcCwQI EZFYQOEmt3UJOTMZdW/ItynwjQz5CyaJl61szS8OBQiXSmOKt+/+7UwHBO8giE0P/sGIC3Ml gH0PRg67yXY3eIiR0+t2CRkNjdi3ElqxCRjrKST+ENyz2E/gGSVZBA+dFm947IS3CTiLVEXw iRpUeCwL8BP8/6/6oXYW7gGeid+8jA264rbRzXDB4Q9LDFKAABcFWmSA/16970GYPR8yHAlQ CA7d7P1hOUAQg6SIbCQP/mi40dlIQwpIf3lDE4P0EseWq/4Rg3ixdWxT0L3WwBAoWhIJEBrw SFge9EwLhRIx8g6Sy8h4q4VjKCvIkhErjUgUgzDwiQJIXMyqbTXerw0vOwUiNSUUQKPTr5Y6 iQ1MqbKi8zPLrIk1ZL0rBWwUZi9oV408gsO08cksG0gXdvAXaoWXuqNJNH0Og6vT7oPtAxy3 ov/X6xAmGfcrulBb0+jm+KFpF94A8IvYO+dzGYtL4TsjuEWLbysj/gvPYDUUO/L9bteaGHLn B3V5i9o72CYV3N02EwXr5hl1WSRzEYPsXAEaLIUTN+vt5uwd8iYNGy/uB5vbhg4IQLB7hdt0 FEZuW9H2QWFZWxDiQ6g4/+vez6hUQKuJHaUUixZE30pt+sdKLYuMkMRsZw/7IpBEiDeLEnAR VV8wEK3dzQ5EC9aLQmWCbwt1F4uRhrXT/1a4HFuL/iM5C9d06YuXhzWrUMpjXFhNwRp0G3ZM V84qZrut/t1qIGRfhcl8BdHhR1+LIFT5gru6bkMKK3/xe8H+BG4FTbdtP374XgKEDaRNg1Qk YSB9KxHb0lIFUTic0/PsW+C4+yNciESJA/4Pdeqe7GixgfQhC+sxFyuVFVy7xaEyIRkpNpiT cxSCLIUiCsCbXi5iegTsla96CCWe21yQhJQ0qRQDSK1tQgylIsJkqXSzLAb+C30pxJnGNtdo CzARYr+wzm67ZJeMCTsKjwl8rusv70N6wCgNjU62CXsEsVyPdLG8rRa+7gk3alu6UYvcjgqJ A/yyw297l3l18APRIgESMvyf6PHbbYsOIY15Dz51Gjsd8kEjUldsSzukBkhv5IJrEdKNQgQI uCLzpAINiJ2mhVIbXXWVTVBy65CapVCQnFeXLBzMoNCqO2yInINfsBjAPQpoxL9toZnpCEUw +IEzUrHFkfyJRlwqahf04Ks8aLL6DKR/MBkMdRT/dhBX/HFrLW2t63xOJMWJfspUiy1KBWJB 56PWrNi0XzfpidHaYuNxyEG/28VYVaPZT+BDwzdlJSrG1lr7MIJoW0MX20AIAgTaSh77hcFD Ptut5995DIsQgABWk8lBd9EnQgVL23f1lwBwYPp3PI1Hd0jyg24rR4OIfvR4/AaBaAbzx0D8 8EIOI9TnvlHWBMeA6BAUBXfBDT4gSPCWdsdgTwwFda0wRdcmJom3l629rI1KDAiPQWSeREK8 nu+68Q/jikZDisgLhMB6iE5DdQcFxvgDCXgEuizLaH7RsFoBati0OHKBNHtoGKEsiw0ouIkV 7z69ulIXaOQLXlasM1ZbgJOtgCAE/R0b1hCP4lZjXCQZ1ftpI+zOpQJYo0Nw0N32nySTHEkF oUi2PapHZasIWL08m+AzI0OTlDldGM22grsZoVgqeI1TLC3RD7BBIBDgCECAGIjbU7U3KCTg VnRj0AAKtBpy69XuRbyeAyT8PsCL9BZAo0ofN8KgRIcO6wtIjW0JNprIg7z/wilJ55K12eBW XxxVUhGkq1pBFM8rIOEsmPiNZcx7Jg1I8hCoEQXZQ7apUQWAAO/DBuyCWxGEiHB1HLLQDdqC nw6MRWrFqgJshSMHdjfB8AyyjYpwaevbXAJtRYA1ZPl1M9maIZoiSKcJVpbLm/rSuMBiOTB0 cjBClKbBEXAKkxzc28cIQCQoQGNZv4CCAo+VtofoxlDzq6q4aerHzYQPhu8Vfe5mu8RPbf9N 74oRhNIMrnm2Qf8GxN4vMDvCD4eTJcdaDEtt2e5SSJNScb+w+6XYBKqNntCRgDt7y3QsilG0 UcWIAbA0+n27d7SUd0L8ipK4IAiQRkCBgYW/E3b1QUGAORjU+cjxUrB4CCoEcsGvh/eE2Kl8 SVCjrAtW3WapyjHEv3APpW2qq93fo7ul61VAef9MSK3izGBnQqEIrizWykVacDks1l572VTr BvoLwk1fwf02qwDrDTkdMAqbMP1Umbp2BEYmMAO7o+G1hjHnIVX+II3wIFtLMP8lOGr9Y4nI hRQYXg+3BhxbFhlJLaT21N/e4nQiUQR0FwQNdAxIdAPtbAXaaLgENQUSC9wGdZ4IEfBZqjdC sBNsqrQXo8U5UvW93MNfZBQFjAglouwR5wr/vgAGFs2+h4iEBex9/wVX+YLGcvSKRfLGhQ0g CWDrAvU3U6dV0KELNGgKJrV3HRoegHusvCpBuCAAl78joNCE3t2qQkKKQv92QC8AXtBfW/Ls +gh39hqDNY16UBJnbEKdmzgj/exmk30dVh5WNCNLkTPFlYz8aDsnf01LAV5cgo1yZosRzd9P +PbCAXQW+hCKlAVkiJCA68idk7ccGgJ0ECBbQ6PxNvKgHIE8ANhumHC/60kVJUFyGQRaJRod 1qpLyCV9k5e3sYhJHx1hchN6dw7obtibIOkg6+BMSr5eyUb98ZCGEmpGQ+dZzDkSzaCSSjRf SNFV/UJoBGmFZHXoIho1Z5oD+PY1VA6GJKMpdPr3w+/Z6BBo1AejONTWozwGcegGXqELeRb/ 0Kis6z27vKE8EAVTEYsYAyPEMzCMTQXrcqoE4vjMzN+oWd/I5wTAWLhZPAfQAIHYdRP8AyBZ 30IOgLyoWahZTdcNFj+fBowDhHyITdM0dGxkXFk+cwgQ36hZ8MBAArHpA8zgWd9HyEMOQFvw WkjErvudWiyQWAt4A6BaIZBXCN9AW26wUMhAW1v0f03TLLv8AwRbDBQcJCFAIDY3W9/YdN0J H1AFWANofFsJLQCB3zRFkyHkEGkc5EJvuuA9YHZ1RldXMVtTyUItVmoeN2wntPy2wB0j6yJT OVfpooMsaCIBO2ANNKE/OX0UfhAvYrUeejeiWbgUoR1VHQsIvdgWHLRPSHxGNjROTSHTfSAs NGuTIHMuTiRvwMmAIIsY5DvfQjvAbYWcNr4EG1KhD20XxEHcOusTS7c21g7/JhGLOGfcdMna rKFmrdxhIVfeWcx19E3sGqVsbbYl/pdxddg793Qy9kUNGEA+HM1uhtp4siLVfx7aIbO1kTJI 0o+NKBWE5Mgw5BeyHXOzNtyJXeAXK5BkEpWyfXOnrHvfdLRWZORndJyPs7dZi3Z1BAM9jCho IAfEvgeU1Vi/XIRSLgD/CHFSzUtFqAiLRFahXmht1P/nOH9ei/FJbqluoQXzDF4AKx5bDARu g8LDjzw01Ei9MpAeU6t2bOh0X3UheovQnsDBu39/igqA+UF8BFp/BYCgo3X8rWgaderrZ1Zk UwCYiRIuRmK9Nyy1g1sUK8QgYThXu61iGCmoKixXUCa5xCsnWUhfIIGaAeruDbYYT1DwKDcM QENRYYcqAACW/y3+/zAHdyxhDu66UQmZGcRtBxFqcDWlY+mjlf////9knjKI2w6kuNx5HunV 4IjZ0pcrTLYJvXyxfgctuOeRHf7///+/kGQQtx3yILBqSHG5895BvoR91Noa6+TdbVG11PTH ////BZGDVphsE8Coa2R6+WL97Mllik9cARTZbAb/G/z/Y2M9D/r1DQiNyCBuO15pTORBYNVy cWei/////9HkAzxH1ARL/YUN0mu1CqX6qLU1bJiyQtbJu9tA+bys/////+Ns2DJ1XN9Fzw3W 3Fk90ausMNkmOgDeUYBR18gWYdC//////7X0tCEjxLNWmZW6zw+lvbieuAIoCIgFX7LZDMYk 6Qux/////4d8by8RTGhYqx1hwT0tZraQQdx2BnHbAbwg0pgqENXv/////4mFsXEftbYGpeS/ nzPUuOiiyQd4NPkAD46oCZYYmA7h/////7sNan8tPW0Il2xkkQFcY+b0UWtrYmFsHNgwZYVO AGLy/////+2VBmx7pQEbwfQIglfED/XG2bBlUOm3Euq4vot8iLn8X/j//98d3WJJLdoV83zT jGVM1PtYYbJNziw6dAC8///2/6PiMLvUQaXfSteV2GHE0aT79NbTaulpQ/zZbjT/////Rohn rdC4YNpzLQRE5R0DM19MCqrJfA3dPHEFUKpBAif/////EBALvoYgDMkltWhXs4VvIAnUZrmf 5GHODvneXpjJ2Sn/////IpjQsLSo18cXPbNZgQ20LjtcvbetbLrAIIO47bazv5r/////DOK2 A5rSsXQ5R9Xqr3fSnRUm2wSDFtxzEgtj44Q7ZJT/////PmptDahaanoLzw7knf8JkyeuAAqx ngd9RJMP8NKjCIf/////aPIBHv7CBmldV2L3y2dlgHE2bBnnBmtudhvU/uAr04n/////Wnra EMxK3Wdv37n5+e++jkO+txfVjrBg6KPW1n6T0aH/////xMLYOFLy30/xZ7vRZ1e8pt0GtT9L NrJI2isN2EwbCq//////9koDNmB6BEHD72DfVd9nqO+ObjF5vmlGjLNhyxqDZrz/////oNJv JTbiaFKVdwzMA0cLu7kWAiIvJgVVvju6xSgLvbL/////klq0KwRqs1yn/9fCMc/QtYue2Swd rt5bsMJkmybyY+z/////nKNqdQqTbQKpBgmcPzYO64VnB3ITVwAFgkq/lRR6uOL/////riux ezgbtgybjtKSDb7V5bfv3Hwh39sL1NLThkLi1PHG////+LPdaG6D2h/NFr6BWya59uF3sG93 R7cY5lp9jf///3BqD//KOwZmXAsBEf+eZY9prmL40/9rYcT/////bBZ44gqg7tIN11SDBE7C swM5YSZnp/cWYNBNR2lJ23f/S/z/bj5KatGu3FrW2WYL30CC2DdTrrypxZ67/////95/z7JH 6f+1MBzyvb2KwrrKMJOzU6ajtCQFNtC6kwbX/f///80pV95Uv2fZIy56ZrO4SmHEAhtoXZQr byo3vgu0oSc2+htewxvfBVqN7y1LFvD//0FCQ0RFRkdISUpLTE1OT1BRUlNU2/////9YWVph YmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ejAxEpvu/zIzNDU2Nzg5Ky8AAP+7O9lb8f/dzwNy dW50aW1lIGVycm9yv1RH9azETE+3DQ0KxLL2A3ZJTkcOAERPTUESEbG83f5SNjAyOAgtIEdh Ymx0+3apvc5pbmlSZml6DWhlYXA3W9vONyc3mXQ9BHUtdNtvqCBzcGFjI2Z3bH9p5LLbgDhh Bm9uNzafgeQpc3RkNXB1W2uFt3IrdmlyCyEzpWPIF9t+IyBjDGwoXzRe225TXypleFwvWAYW drLX3OJfMTn3Cu7mFnJlWDFzbw+Ka5MB23NjKzhGJAZChFuBZWQZV9vtIfkjN211bKx0aL9h hTCSby9sb2NrF2tuG2w0ZLdhLgKi2reGWyFybQBwQGdyYW0g7IVQ2EptNi8wOU+NZmgpEEEq J1PI5xosLis4YfY8hO9yZ3Uoc18wMmbBLrZtu25uZ4JvBXQ6EUIrnLVk5n9NLWA5YPzD22YV VmlzqkMrKyBSnIe57/ZMaWK0cnknCi0WRWucbQ8OIRFQ1Dq+AHNt2GUuADzl4CUssSRMbWts nUPY+G75/1lTXQNHZXRMYUZBey8U6BZ2/MJ1cAATD4FvbTtXqWQ6m2Vzc2En8YUFeEJveEBz OTMyLmTG3PKsPkelXKkDU12gojBnAwAup7IPr1dAIwiL+IppmqbZA+DQuKygpmmappR8aFhA zbJpmiAUCPCJ2MQ0TdM0qJiAbFTTNE3TPCwoJCBN0zRNHBgUEAwIdG7TNAQA/IiPA/TTNE3T 8Ozo5OBN0zRN3NjU0MzENE3TNMC4sKig0zRN05yUjIR8TdM0TXRsZFxUTDRN0zREPDQsKKZz X9MgDI+HiwPkmqZpmtzUzMC8uGmapmmwqJyUiKRrmqaEfHRoQ2BpmqYbWANQQDgspmmapigg FAwETdM0y/yG9Ozk3NA0TdM0yMC4sKjTNF3ToJgvkIiATdM0TVxQSEA4MOYbpDv/fJTnhppm 2XQDCPyF6NC4aZqmabComIRssmmaplhELBT8hE3TNM3YwKyMfHA2TdM0ZFxQPCCE03Sm6WeE gwPUvE3TNE2omJCIeHCm6842ZIPLVAdAAyyov2yaIATwgnNvbWV0aCvURu2zaXPab/ITsVTf C2dvCHcZZ4/9Rv3veW91/WUgYmFkC3Ryefph31UXc3RlYWwfZmVlbLBGbaWeJHObE97K7Vse cm4gbURleRphdHPu9vfBUndoeT83dGFrL2l0J7XvdqpzA2JwbAhkW7GuOtY+PzMnc9xuH3Nt bGtdISxkYwNOE8CtVAt9XWR1aNTADgcX2JttXwFELGYfbT5YtfZrlSk/YWJpgQBctY2yAEFm TQMJbnZIF4YbIdrYsn8bdHVmZi3XZ3q9tz3XLyVzfWUXjyO8Ce7rQQtKT2WGExq2c6ZySGwT aZBVC85t72SmIAhjTtUF7HKNA3L/Fewv9kCFM2hvcF3XdhdegAh1ZZxraVXv7MLuuidp7iBv ZlYh28vmkiVjFlNJYVy40L12um5wn3N3GWQhC/ZOYgthvVgvTTjE3FbWYwgjOIP7l3dhlFQu 3CG97rFkJ1hhY2PsdCt7y76EF98/E84j0TW+w0NrbX4Kb62wfc4vgvVtLmTjiWTvMHtgJx76 62ht9swuLxTymO2H99cSE2knbaWuAG9rD91eob13cDSVWDhhbhHahM14BHkiIKMjjzz2LnBp Zgdjb21zY3Jlb8kCznhllwsjbiMF+5vubyN0BWVzI2sjeSMtB/KPrZsTsW2rY/9wYXJ0c2+Q Lg9vMu+sB9tcCfhvYmpAx5Brr6avldonGOrXbEISEKltemYPkFMZ5VOMxGNqb/sxw93CaQVk 32Vic7NTeAClGJ/IgGNSw8V1Bz6wDXwb7xFwI153Z3AIjdZ4u2lpVvR1hm3ScG8fd4GQcI5n NmJKd2IHita2gAgPO2MwJ8/WtoBsdKM7AG/JvUmHc3M/4xWUCYbDhhForQOir9Eatjty2nTP fSPh7XoArzdsa0PbeENomxNzQ+MTs642CRXPWwDfVyEhbXBu2wOXZo9lPHv7ouxDcwQwU0/P j4DDM7Qq43DrkU+OldIHc2hkYnh+b3LkdGJiYWSkF3dhMdrIQXNwdXdL8rHCyXJ0dpcHaHRt bDjrzghrbANoM3TP3ZtRP2ciB1tdLUDXbJt/C18tXC96OgN5eAdN0zRNd3Z1dHNyNE3TNHFw b25t0zRN02xramloTtM0TWdmZWRjdk16F+NtMtQE33gg9KdYwAMZBnJmYyAhWYTNHiRscxdT WQuIQKD1EhquCy2nCiBsyWbR6JYVlxV3LoRjFrCsvhH+ao5lW9d9c0lzG6LCsqUHk71jMO41 2kbXeLt5ziCxR0aLdO8ZFVctg2wIlhWCDEPspiDdC2lpzFhvLjcXI9hu7mVxAyAtpGms2Fpj V31wdYi/3DOGozlOBGP3/KloDIbVwHM0cg95NRqzw7VHMv1ztIEtCF+Kt9k/rslfV69w/Gpw Z3Psi7ka6KFfGm9UtbPNEcJUeAxw9N2BvanynHAgOSBUcyJwO2izpnD4chDgXV9iwuwZaLSr YlV39tsBO3hwjjIx8DUuMTAwA/in7sAAgr926FVEUAAlHGsFOqYl+gYFLjJ7zyVrUwQUBgMr twzER5ArT6kATi/d2PVvdgBPH1NlvkF1Nkp1bIVW2HAD9k2TD8wtW2tzBwNGjxNhU9q2aK3X C7azaERXc1uBVnkH8h9vFy9t702BSVFVSVQHAy5pW478BgAtLQAiQyZ0/WrdNrAtVBdzZrAt RW6X/dHRmCQ6JWU2NCJEao+uAll4aYEcc7/Xy247IJbyPSJTUFBwJSZ5VSZKHwsfw/fFL3gt elkt13Jks9Zci6Y4NDM1tNYYXRgXk2WRvbasKi+Tvzcvtu2BIS86Ybw7pGtsC7dyYnQ9ti3F Y5joEIR2Ijdi1Bc4ECGLE1dxHfg2Pk4vyni2Yu4I2x8zhO9NSU1FLVZPcxZu4Fr3MS4wP0S8 N3RTdUNs4UUKk28GpyKCfQUACTAA238ifj9BVEE3Q1BUIFRPHjz9JcJtCz4QVUwgRlJPTSv4 B+4RAMdIRUxP0849PsNME1yz7cn8f39jB2UTKi4qG1NPRlRXQVJFXGMFh0BIXL1zYjC3xVxD KXLiuFwMTI4FPVOwYdcZWKJjee1t4UtvMm1s3CBreUGLRe1sat/4/0ebQ0xTSURce0U2RkI1 RTIwGUUzNS0lttv/MTFDRi05Qzg3LdRBQQM1yMRbIP43RUR9XEluimNdZs03DCSbYXNrbXNu XsstwqN7STkbw5q9H64L+2XQgoEYiDivZBF6Io7JYmV+ZXu263sQF9tr03RABh/7WGu+O0Fk bVMPSmtsUyEDBmy5M78BusE2eOA9MQIXFgMCmmawQQMHBBgFaZqmaQ0GCQcMwQYZpAgJChv2 vReQC1c7Bw9XgnSDDRATEQMSkMEG+RchNQ9BwQYbZENQM1IXBhtssFMHV19Ze2ymabrBF22r IHAcBvtekHLHL4CzgRtksMEHgh+DhI8ZpGkGkSmeoWyQwQakb6e3n3IQBhvOH9cLGAfZe65q iQOVAQMgkxwoIEgMIBPJABCEEIEMyISBAQzIgAwQggKZmwyBEL8AadJdVQEHLl8M0g32wAsX HQsElsggzYCNCI4MyIAMj5CRgAzIgJKTslEM0gOvCjeMJC8LbwyjAAWTGela8GPTNGiDBwjP NMumCdxnCrg3mqZpuowHEVwSOBM0y6ZpDBjUZhms0zRN0xp0GzwcZdM0TRR4BHn0ZROVaZp6 5PwG2IfXvUcP+MBDAgTSzw723aQPYIJ5giGvpt8HoaXN8+8ngZ/g/C9AfoD8qMFy9gjjo9qj j4H+B0CDDIENtS9Btl8h/3dfz6LkohoA5aLoolt+of6y3+4+UQUD2l7aX1/aatoyL6lol7/T 2N7g+TF+OYNYACoKACoqCUEBVCCrAqhARgVQgYwKoAIZFEAFMmyGqGwDxBhQsU0UsAEgQ1AH x1pUbQZJMQpTdCkqR1SZSKJahqxXD0FNI6r/m1lCeXRlVG9XaWRlQ762UAFbFEgEUh2AbYuq NWMMVvuDRaijDVJ0bFVudz+133tsZEpPRU1vL0NyBDV2+6xFC0Rlc2NveSJGPdhrRBBremRI YarOSrc7bA1TCkNFAWOmQh1FC2HPks2jc1cXFrZkbVistsEURhTVCNuDZURRQLfdAUFkZCFz PUzuLApo4bxBDdmFzdpDTbMsDVf9pKhiL1lGGNhWVO1EFlVvPq0w7MJDGHNl1jZZbe0Xe/Lg CFBvMZtycOaqyrFrGmwwT8LNHgduQSBTaXqK6uxNQg8ZU+r2zf4DVGltegha2WVJbXvLqAoX zGOg3/u6ZyVfbEJkB2OUCG8v2fYKeiYHYsUL+ORvCM+KY3B5TW9ka287VkyATmFOQT4fMgyD bW5rmkZ5mEYBClSdxfIKTvK4rHXLGftyUcJEzm6D3Gp2ZVMUZXCxYQx7RdUjDPMwfm8rwwN4 MeVjaxJsILRGRjEPnjSchMNpIXRhnnC17jY7ERA5bW0fTInbrKiCIbkLReERIcZ4aQP/pAAK OOEFChdUqpfspHtlJlBsY9mBADn8aH+DO2xtZE8QcIOf35qlIYx8QZ7RANqCu3EbZ1ORe3Uo FnsE9+0PSEtleQzvs7dsbB9BEB4Osll6hk/KDPHedFFC4cJ2TgJ3SWtQCbMq4DTbcxrrGLPb GJAdAbFwjnRmoX08XfYgJEmXbj02tVcFHG5u27XZNsvN/yMCASz/cwIEZVmWZRAWEw8MlmVZ lgk3CzQXFLOWZVkVEW8Dpf9D/stQRUwBBABZ9DBA4AAPAgsBAjig6vcOCgMA5DrYWfdOVoAN KhAPBDO5Y98sBx8BDAPbm0s2sO8PJBAHBjeBy7McKGmMcGANaoXcBgJgHnwBF2zXcS7GdAeU TpDnINhc2ARFIC5yuvdsDgIjDmAUJ1Ruse5CQAIuJifc4m1KBmmAdMBPG5t9pXPFSg3ze5RP AP9+Kxswaw2SdAEAAAAAAAAAgAT/AAAAAAAAAAAAAABgvhVQQQCNvuu//v9Xg83/6xCQkJCQ kJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR23Pk McmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHbdQeL HoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj ////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5RAEAAIoHRyzoPAF394A/BXXyiweKXwRm wegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AcAEAiwcJwHRFi18EjYQwZJ0BAAHzUIPHCP+W 8J0BAJWKB0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+W9J0BAAnAdAeJA4PDBOvY/5b4nQEAYem3 qP7/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AwAAACAAAIAOAAAAYAAAgAAAAAAAAAAAAAAAAAAAAQABAAAAOAAAgAAAAAAAAAAAAAAAAAAA AQAHBAAAUAAAAKSgAQCoDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAZQAAAHgAAIAAAAAA AAAAAAAAAAAAAAEABwQAAJAAAABQrQEAFAAAAAAAAAAAAAAAoHABACgAAAAgAAAAQAAAAAEA GAAAAAAAgAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACAgID///////////////////////////////////////////////////// ///////////////////////////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA gID///////////////////////////////////////////////////////////////////// ///////////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////// //////////////////////////////////////////////////////////////////////// ///AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////// ///////////////////////AwMDAwMDAwMDAwMDAwMDAwMD////////////AwMAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////////////////// ///////////////////////////////////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACAgID////////////AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA wMDAwMDAwMDAwMD////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///// //////////////////////////////////////////////////////////////////////// ///////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID////////////AwMDAwMDA wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD////////////AwMAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////////// ///////////////////////////////////////////////////AwMAAAAD/AAAAAAD/AAAA AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAADAwMDAwMDAwMDAwMDAwMDA wMDAwMDAwMDAwMDAwMDAwMD////////////AwMAAAAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/ AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD///////////////////////////////////// ///////////////////AwMAAAAD/AAAAAAD///////////////////////////////////// ////////////AAAAAADAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD///////// ///AwMAAAAAAAAD/AAD/////AAAAAAD/AAD/////AAAAAAD/AAAAAAD///////////8AAAD/ AAD////////////////////////////////////////////////////////AwMAAAAD/AAAA AAD///8AAAD/AAAAAAD///8AAAD/AAAAAAD/AADAwMD/////////AAAAAADAwMDAwMDAwMDA wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD////////////AwMAAAAAAAAD/AAD/////AAAAAAD/ AAD/////AAAAAAD/AAAAAACAgID///////8AAAD/AAD///////////////////////////// ///////////////////////////AwMAAAAD/AAAAAAD///8AAAD/AAAAAAD/AAAAAAD/AAAA AAD/AAAAAAD/////////AAAAAADAwMDAwMD////////AwMDAwMDAwMDAwMDAwMDAwMDAwMD/ ///////////AwMAAAAAAAAD/AAD/////AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AADAwMD/ //8AAAD/AAD////////////////AwMDAwMDAwMD////AwMDAwMDAwMD////////////AwMAA AAD/AAAAAAD///8AAAD/AAD/////AAAAAAD/AAD/////AAAAAACAgID/////AAAAAADAwMDA wMD////////AwMDAwMD////////////////AwMD////////////AwMAAAAAAAAD/AAAAAAD/ AAAAAAD///8AAAD/AAAAAAD///8AAAD/AAAAAAD///8AAAD/AAD////////////////AwMDA wMDAwMD////////AwMDAwMD////////////AwMAAAAD/AAAAAAD/AAAAAAD/AAD/////AAAA AAD/AAD/////AAAAAAD/AAAAAAD/AAAAAADAwMDAwMD////////AwMD///////////////// ///AwMD////////////AwMAAAAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/ AAAAAAD/AAAAAAD/AAD////////////////AwMDAwMD///////+AgIAAAAAAAAAAAAAAAAAA AAAAAAAAAAD/AAAAAAD/////////////////////////////////////////////////AAAA AAD////////////////AwMDAwMDAwMDAwMCAgID////////////AwMCAgIAAAAAAAAAAAAD/ AAD///////////////////////////////////////////////8AAAD/AAD///////////// ///AwMDAwMDAwMDAwMCAgID////////AwMCAgIAAAAAAAAAAAAD/AAAAAAD/AAAAAAD/AAAA AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD///////////////////////////// //+AgID////AwMCAgIAAAAAAAAAAAAAAAAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/ AAAAAAD/AAAAAAD/AAAAAAD/AAD///////////////////////////////+AgIDAwMCAgIAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////// //////////////////////////////////////////+AgICAgIAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////////// //////////////////////////+AgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA gICAgICAgICAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD//////gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAA/gAAAP4A AAD+AAAA/gAAAP4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAAAwAAAAcAAAAP/gAAH/4AAD/+AAB//////0h9AQAAAAEAAQAgIAAA AQAYAKgMAAABAAAAAAAAAAAAAAAAACiuAQDwrQEAAAAAAAAAAAAAAAAANa4BAACuAQAAAAAA AAAAAAAAAABCrgEACK4BAAAAAAAAAAAAAAAAAE+uAQAQrgEAAAAAAAAAAAAAAAAAWq4BABiu AQAAAAAAAAAAAAAAAABmrgEAIK4BAAAAAAAAAAAAAAAAAAAAAAAAAAAAcK4BAH6uAQCOrgEA AAAAAJyuAQAAAAAAqq4BAAAAAAC8rgEAAAAAAMiuAQAAAAAAAwAAgAAAAABLRVJORUwzMi5E TEwAQURWQVBJMzIuZGxsAGlwaGxwYXBpLmRsbABVU0VSMzIuZGxsAFdJTklORVQuZGxsAFdT Ml8zMi5kbGwAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAA UmVnQ2xvc2VLZXkAAABHZXROZXR3b3JrUGFyYW1zAAB3c3ByaW50ZkEAAABJbnRlcm5ldEdl dENvbm5lY3RlZFN0YXRlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEsBAhQACgAAAAAA4jhUMF1usCIAVgAA AFYAABAAAAAAAAAAAAAgAAAAAAAAAGRvY3VtZW50LnR4dC5waWZQSwUGAAAAAAEAAQA+AAAA LlYAAAAA --57570782-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 04:03:02 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10678 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 04:03:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Au6Vj-000Iyw-O8 for namedroppers-data@psg.com; Fri, 20 Feb 2004 08:59:51 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Au6Vi-000Iyk-O0 for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 08:59:50 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i1K8xoiA014167 for <namedroppers@ops.ietf.org>; Fri, 20 Feb 2004 00:59:50 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id <T67dcd83b8e118064cc748@mailgate2.apple.com>; Fri, 20 Feb 2004 00:59:50 -0800 Received: from [17.219.197.152] ([17.219.197.152]) by relay2.apple.com (8.12.11/8.12.11) with SMTP id i1K8xjGl005317; Fri, 20 Feb 2004 08:59:46 GMT Message-Id: <200402200859.i1K8xjGl005317@relay2.apple.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 20 Feb 2004 00:59:45 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire <cheshire@apple.com> To: "Christian Huitema" <huitema@windows.microsoft.com>, <namedroppers@ops.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Christian Huitema wrote: >There is certainly a very strong case that multicast packets should be >sent with the shortest possible TTL, in order to minimize the risk of >flooding entire networks. Exactly what is the "risk of flooding entire networks" here? Just about every network printer bought by Microsoft or anyone else in the last year has Rendezvous in it, and sends multicast packets with TTL 255 to the link-local address 224.0.0.251. If there were any actual case of a defective router incorrectly forwarding these link-local multicast packets and "flooding entire networks", don't you think someone would have noticed by now? Stuart Cheshire <cheshire@apple.com> * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 07:56:18 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19754 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 07:56:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuA8D-000GxN-QZ for namedroppers-data@psg.com; Fri, 20 Feb 2004 12:51:49 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuA8A-000Gwo-96 for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 12:51:46 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i1KCpbW07667; Fri, 20 Feb 2004 19:51:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1KCn8e08864; Fri, 20 Feb 2004 19:49:12 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Stuart Cheshire <cheshire@apple.com> cc: "Christian Huitema" <huitema@windows.microsoft.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <200402200859.i1K8xjGl005317@relay2.apple.com> References: <200402200859.i1K8xjGl005317@relay2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Feb 2004 19:49:08 +0700 Message-ID: <26638.1077281348@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 20 Feb 2004 00:59:45 -0800 From: Stuart Cheshire <cheshire@apple.com> Message-ID: <200402200859.i1K8xjGl005317@relay2.apple.com> | Just about every network printer bought by Microsoft or anyone else in | the last year has Rendezvous in it, and sends multicast packets with TTL | 255 to the link-local address 224.0.0.251. If there were any actual case | of a defective router incorrectly forwarding these link-local multicast | packets and "flooding entire networks", don't you think someone would | have noticed by now? One of two things is being observed there - first, that the vast majority of routers installed don't forward multicast packets at all, currently anyway, so noticing that they're not forwarding particular multicast packets isn't providing much in the way of useful information. Second, assuming that none of the routers that do have multicast turned on is forwarding those packets (and that "not noticed by now" isn't just that there isn't yet enough of it for anyone to care), is telling us that routers handle link local multicast correctly, and don't forward link local multicast off the origin link. In fact, using TTL==255 is relying on routers doing that correctly, if there are routers with bugs that allow link local multicast to be forwarded, then Christian's "flooding the entire network" would be exactly what would happen, wouldn't it? So, let's assume that routers are correctly not forwarding link local multicast. In that case, what's the point of the TTL==255 stuff (for multicast packets anyway) ? The only rationale for using TTL 255, is to allow hosts to validate that the packets haven't been forwarded by a router. If the TTL arrives with a value of 255 we assume no router touched it (because TTL decrementing is something that experience has taught us that routers actually do correctly). But this is obviously unnecessary - we've already assumed that routers block link local multicast packets - if the routers are blocking (not forwarding) link local multicast packets, and we can assume that is correctly functioning, then there's no point at all in the host doing any kind of TTL==255 check, that is just a waste of time - and if the hosts aren't going to check it, there's also no point in sending TTL==255. Of course, there was that assumption, that routers are in fact going to block link local multicast. What happens if that proves to be incorrect? Well, in that case not doing the TTL==255 check at the recipient allows off net sourced packets to be received and processed, but now we have packets flooding the net. Which is those is the greater harm if not prevented? IMNSHO, the packet flooding is the greater harm, and it is that which needs to be prevented (at almost any cost). I'm not sure I see any enormous harm in LLMR packets being received from off link (certainly nothing worse than lots of other spoofed packets that might be received). So, once again, I'd require that all intended-to-be-link-local multicast packets be sent with a TTL of 1 - it just means that if there do happen to be any defective routers, which don't know what is special about 224.0.0.*/24 and forward the packets, then the TTL->0 when it is decremented will prevent forwarding. If there are no such defective routers the TTL==255 thing is a waste of time anyway. On the other hand, for unicast packets, wherever they are used in LLMR, the "flooding" argument is meaingless, and (aside from when they happen to be to or from an LL address) won't be being blocked by routers. They also do no real harm to the net when forwarded (even if they end up nowhere). There if there's any gain to be had from detecting off link sourced packets, I see no reason to lose it. So, sending any unicast packets with a TTL of 255 (and validating that they arrive with the TTL still being 255, if the host cares) seems reasonable to me. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 12:47:52 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03558 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 12:47:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuEf2-0006L8-TH for namedroppers-data@psg.com; Fri, 20 Feb 2004 17:42:00 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuEey-0006HP-CM for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 17:41:56 +0000 Received: from [10.255.207.98] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id 25FDE1B22A6; Fri, 20 Feb 2004 11:29:08 -0600 (CST) In-Reply-To: <26638.1077281348@munnari.OZ.AU> References: <200402200859.i1K8xjGl005317@relay2.apple.com> <26638.1077281348@munnari.OZ.AU> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13362B87-63CC-11D8-A3A6-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: Stuart Cheshire <cheshire@apple.com>, "Christian Huitema" <huitema@windows.microsoft.com>, namedroppers@ops.ietf.org From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 20 Feb 2004 12:41:55 -0500 To: Robert Elz <kre@munnari.OZ.AU> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Personally, I find it amazing when people build huge pyramids of logic on top of premises like "we can't depend on the routers to be correct." It's true that we can't depend on routers to be correct - don't get me wrong. But when routers are not correct, the solution is to fix the router, or throw it out, not to demand that all network protocols account for every possible way that a router can be broken. So what's the scenario where the router would do the wrong thing in this case? How likely is it that an implementation mistake would result in the wrong thing happening? Because I've thought about this, and to me it looks like you'd have to do a proactively bad implementation to get the behavior you're talking about - it wouldn't be enough to just forget to check something. Furthermore, in order for the doomsday scenario Christian described to come to pass, *every router on the internet* would have to be broken *in the same way*. Am I wrong here? Can you or Christian explain why it's so likely that this scenario could come to pass? Thanks! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 13:15:13 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04933 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 13:15:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuF8U-000F83-FR for namedroppers-data@psg.com; Fri, 20 Feb 2004 18:12:26 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuF8T-000F7f-9D for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 18:12:25 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i1KICOBv025091 for <namedroppers@ops.ietf.org>; Fri, 20 Feb 2004 10:12:25 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id <T67ded2221b118064cc748@mailgate2.apple.com>; Fri, 20 Feb 2004 10:12:24 -0800 Received: from [17.219.197.241] ([17.219.197.241]) by relay3.apple.com (8.12.11/8.12.11) with SMTP id i1KICMGo010517; Fri, 20 Feb 2004 18:12:23 GMT Message-Id: <200402201812.i1KICMGo010517@relay3.apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 20 Feb 2004 10:12:23 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire <cheshire@apple.com> To: "Robert Elz" <kre@munnari.OZ.AU> cc: "Christian Huitema" <huitema@windows.microsoft.com>, <namedroppers@ops.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >what's the point of the TTL==255 stuff (for multicast >packets anyway) ? The immediate value is primarily for unicast packets, and less so for multicast packets. When Rendezvous sends a multicast query, and the peers on the local link respond with unicast responses back to the querier, then checking TTL=255 on reception verifies that no off-net interloper has managed to slip a few remote unicast responses in with the legitimate local unicast responses. The value for multicast packets is an indirect code hygiene benefit: suppose a router vendor were to make a future multicast router that incorrectly forwards 224.0.0/24 packets. This could expose hosts to off-net attack. By setting and checking TTL=255, hosts are protected from this vulnerability, and because of the resultant traffic forwarding, the problem is detected and the router is fixed before it even gets through QA testing. Suppose we used TTL=1 instead: Now the router bug might go unnoticed for months or years, until the product is deployed in millions of homes around the world, and then some hacker finds it and exploits it. Stuart Cheshire <cheshire@apple.com> * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 15:18:07 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11674 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 15:18:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuH0C-0008sF-7z for namedroppers-data@psg.com; Fri, 20 Feb 2004 20:12:00 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuH08-0008s2-Ul for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 20:11:57 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i1KKAsmP016635; Sat, 21 Feb 2004 03:10:54 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1KK6LX21550; Sat, 21 Feb 2004 03:06:23 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Ted Lemon <mellon@nominum.com> cc: Stuart Cheshire <cheshire@apple.com>, "Christian Huitema" <huitema@windows.microsoft.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <13362B87-63CC-11D8-A3A6-000A95D9C74C@nominum.com> References: <13362B87-63CC-11D8-A3A6-000A95D9C74C@nominum.com> <200402200859.i1K8xjGl005317@relay2.apple.com> <26638.1077281348@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Feb 2004 03:06:21 +0700 Message-ID: <27314.1077307581@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 20 Feb 2004 12:41:55 -0500 From: Ted Lemon <mellon@nominum.com> Message-ID: <13362B87-63CC-11D8-A3A6-000A95D9C74C@nominum.com> | Personally, I find it amazing when people build huge pyramids of logic | on top of premises like "we can't depend on the routers to be correct." No, you missed the point - which was (and Stuart's reply that just followed yours confirms it) that for multicast, the TTL==255 check is meaningful only if you assume that the router bug exists. If there would be no such bug, the test is totally meaningless. | It's true that we can't depend on routers to be correct - don't get me | wrong. But when routers are not correct, the solution is to fix the | router, or throw it out, not to demand that all network protocols | account for every possible way that a router can be broken. Partly true - but we must also make the protocols resilient to plausible failure modes. After all, that's why we have the TTL in packets in the first place - if we could rely upon either correct routers, or the "fix whatever is broken" approach, we wouldn't need the TTL, as packets would always go to their destination, or be dropped, they'd never loop. But we simply aren't prepared to make either of those assumptions, the net has to keep working, even when parts of it are malfunctioning. | So what's the scenario where the router would do the wrong thing in | this case? How likely is it that an implementation mistake would | result in the wrong thing happening? Because I've thought about this, | and to me it looks like you'd have to do a proactively bad | implementation to get the behavior you're talking about - it wouldn't | be enough to just forget to check something. All that's needed is for the definition of what is a LL multicast to be entered incorrectly (say 224.0.0/25 instead of /24 - most simple tests wouldn't notice the problem, but the 224.0.0.251 addr would sure fall through it) | Furthermore, in order | for the doomsday scenario Christian described to come to pass, *every | router on the internet* would have to be broken *in the same way*. Is that really so hard to imagine? Can't you imagine a scenario where almost all of the internet is run using one vendor's routers, built out of one vendor's common code base? It isn't everything that has to be broken, just enough to cause lots of trouble. | Am I wrong here? Can you or Christian explain why it's so likely that | this scenario could come to pass? I don't think it is likely at all. But if the routers aren't going to be broken this way, and I don't think they are likely to be, then there's no point at all doing the TTL==255 check for multicast, as any packet that would fail it, will have already been dropped by the router. Stuart Cheshire <cheshire@apple.com> said: | The immediate value is primarily for unicast packets, and less so for | multicast packets. This is looking promising, as I think just about all of the arguments for TTL=1 rather than TTL=255 come from the multicast arguments. If we can get the "less so" down to "irrelevant for", then perhaps we have a compromise in the offing. | When Rendezvous sends a multicast query, and the peers on the local link | respond with unicast responses back to the querier, then checking TTL=255 | on reception verifies that no off-net interloper has managed to slip a few | remote unicast responses in with the legitimate local unicast responses. Fine, I have no problem with this (though the problem that is being solved still exists in the DNS without DNSSEC - once DNSSEC is done, a DNSSEC type approach to LLMR is likely to be a better, and much safer, way to solve this problem). | The value for multicast packets is an indirect code hygiene benefit: | suppose a router vendor were to make a future multicast router that | incorrectly forwards 224.0.0/24 packets. This could expose hosts to | off-net attack. Yes, but it would also cause the multicast queries (with TTL==255, and any other multicast replies) to get sent to places where they're not supposed to go. That would be a much more serious problem. And even if the TTL checks happen to protect LLMR (or Rendezvous) they're not going to protect other users of LL multicast addresses. That is, this would be a serious problem, and as Ted said, one that warrants getting the router fixed (we still need the network working while that is happening - but we can tolerate some security risk, after all, we can always filter out the packets that we don't want to receive). | By setting and checking TTL=255, hosts are protected from this | vulnerability, and because of the resultant traffic forwarding, the problem | is detected and the router is fixed before it even gets through QA testing. If someone is doing QA testing of this kind of thing in the router at all, I don't think they're going to be relying on LLMR/Rendezvous reporting that it is dropping packets because their TTL isn't 255.... | Suppose we used TTL=1 instead: Now the router bug might go unnoticed for | months or years, until the product is deployed in millions of homes around | the world, and then some hacker finds it and exploits it. If there is a vulnerability here that is so important, that we need this kind of mechanism to protect against this unlikely scenario, then the whole thing badly needs a re-think. If getting a packet through a router is all it takes to wreak havoc on a host or net (which this is suggesting), then there are lots of other methods, rather than imagining a broken router that happens to allow forwarding of LL multicast (and as Ted indicated, you'd actually need a whole chain of such things, between the hacker and the victim) and yet correctly decrements the TTL. Much more likely would be for the hacker to get a virus onto some system on the local net (we all know how easy that is to accomplish), where the virus sets up a tunnel end point which simply decapsulates packets and forwards them (any and all packets, with no TTL adjustments). This is far more likely to happen than the broken router scenario, and in this setup, the TTL==255 check is of no benefit whatever - the packets can have a 255 TTL if that is what is needed to get them accepted. If we now have a problem that makes LLMR too insecure to use, then we need to abandon LLMR (as it is now anyway), and think of something different - or at least some other fix that isn't depending upon anything so crude as the value of a field in the IP header. If this doesn't make LLMR unacceptable to one and all, then clearly the TTL test isn't achieving anything, and may as well be dropped (for multicast packets) - it is irrelevant. Once the check is dropped, then the multicast packets can be sent with TTL=1 and everyone will feel just that little bit happier about that very unlikely (but horrible should it occur) possibility of broken routers incorrectly forwarding the packets. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 17:56:15 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18908 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 17:56:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuJVS-00097m-A4 for namedroppers-data@psg.com; Fri, 20 Feb 2004 22:52:26 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AuJVQ-00097O-Js for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 22:52:24 +0000 Received: (qmail 83903 invoked from network); 20 Feb 2004 23:11:01 -0000 Received: from h219-110-032-209.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.209) by necom830.hpcl.titech.ac.jp with SMTP; 20 Feb 2004 23:11:01 -0000 Message-ID: <4036901B.6060501@necom830.hpcl.titech.ac.jp> Date: Sat, 21 Feb 2004 07:54:19 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Stuart Cheshire <cheshire@apple.com> CC: Robert Elz <kre@munnari.OZ.AU>, Christian Huitema <huitema@windows.microsoft.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <200402201812.i1KICMGo010517@relay3.apple.com> In-Reply-To: <200402201812.i1KICMGo010517@relay3.apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Stuart Cheshire; > When Rendezvous sends a multicast query, and the peers on the local link > respond with unicast responses back to the querier, then checking TTL=255 > on reception verifies that no off-net interloper has managed to slip a > few remote unicast responses in with the legitimate local unicast > responses. It is unwise to use not DNS but Rendesvous, when LAN is connected to the Internet. > The value for multicast packets is an indirect code hygiene benefit: > suppose a router vendor were to make a future multicast router that > incorrectly forwards 224.0.0/24 packets. This could expose hosts to > off-net attack. By setting and checking TTL=255, hosts are protected from > this vulnerability, and because of the resultant traffic forwarding, the > problem is detected and the router is fixed before it even gets through > QA testing. Suppose we used TTL=1 instead: Now the router bug might go > unnoticed for months or years, until the product is deployed in millions > of homes around the world, and then some hacker finds it and exploits it. Any protocol which relies LAN, which is connected to the Internet, is secure is insecure. Note that the LAN may be connected to other LAN with Ethernet over IP. Never bother to improve quality of illusion of security. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 21:38:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29100 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 21:38:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuMyJ-000GyR-CM for namedroppers-data@psg.com; Sat, 21 Feb 2004 02:34:27 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuMyH-000Gy8-F8 for namedroppers@ops.ietf.org; Sat, 21 Feb 2004 02:34:25 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1L2YHLN082877 for <namedroppers@ops.ietf.org>; Fri, 20 Feb 2004 21:34:17 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1L2YGFD082876 for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 21:34:16 -0500 (EST) Received: from [64.4.11.120] (helo=hotmail.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuE4R-000NEt-58 for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 17:04:11 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Feb 2004 09:04:10 -0800 Received: from 207.46.238.137 by by7fd.bay7.hotmail.msn.com with HTTP; Fri, 20 Feb 2004 17:04:09 GMT X-Originating-IP: [207.46.238.137] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" <bernard_aboba@hotmail.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 20 Feb 2004 09:04:09 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <BAY7-F120CSR9OgSNnB0007edc5@hotmail.com> X-OriginalArrivalTime: 20 Feb 2004 17:04:10.0254 (UTC) FILETIME=[8ECE22E0:01C3F7D3] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Robert Elz has made a convincing argument why TTL=1 should be set on multicast packets. It also makes sense to set TTL=1 on LLMNR packets sent via unicast TCP, since if this is done the TCP three way handshake will ensure that a connection will only be set up to a host on the same link. If TTL=255 were set on the TCP SYN, then an LLMNR connection could be set up to any host on the Internet. This doesn't make sense for linklocal name resolution. Then there is the issue of what the TTL should be on UDP unicast packets. There are two cases here: UDP unicast queries and UDP unicast responses. Unicast UDP queries will presumably be sent largely to resolve PTR RRs; this is not the recommended transport, but it can be used. Therefore I would make the same argument as for TCP queries, namely that TTL=1. There is no reason for a linklocal name resolution protocol to send queries all over the Internet. So we are left with the question of the TTL for UDP unicast response packets. Here we could set TTL=255 and (optionally) check on reception as Robert proposes, or we could set TTL=1. In thinking about the risks/benefits of this, it's important to keep in mind the risks of DoS attack. In the existing LLMNR specification, there is no support for "wildcard" queries. However, the DISCOVER Opcode specification, if run on top of LLMNR, would add this capability. Once "wildcard" queries are supported, we now have the possibility of an attacker sending a wildcard query from a spoofed address, and causing the victim to be deluged with responses. Even with TTL=1 on responses this attack exists, but can only be used to attack someone on the local network. With TTL=255 set on responses, it can be used to attack anyone on the Internet. To my mind, this was the argument that tipped the balance in favor of setting TTL=1 on UDP responses. Note that this deicision is not mandated by the IPv4 Linklocal TTL specification. In Section 2.7 of that specification, it is stated: A sensible default for applications which are sending from a Link- Local IPv4 address is to explicitly set the IPv4 TTL to 1. This is not appropriate in all cases as some applications may require that the IPv4 TTL be set to other values. LLMNR responses can be sent from any source address, so this text does not apply in many situations. Also, the above text leaves the decision to the application. So I think that this is purely an LLMNR decision. _________________________________________________________________ Take off on a romantic weekend or a family adventure to these great U.S. locations. http://special.msn.com/local/hotdestinations.armx -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Feb 21 00:34:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04033 for <dnsext-archive@lists.ietf.org>; Sat, 21 Feb 2004 00:34:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuPiW-000JAm-2Q for namedroppers-data@psg.com; Sat, 21 Feb 2004 05:30:20 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuPiF-000J82-0r for namedroppers@ops.ietf.org; Sat, 21 Feb 2004 05:30:03 +0000 Received: from [192.168.1.109] (66-65-58-35.nyc.rr.com [66.65.58.35]) by toccata.fugue.com (Postfix) with ESMTP id C943D1B2D14; Fri, 20 Feb 2004 23:17:09 -0600 (CST) In-Reply-To: <27314.1077307581@munnari.OZ.AU> References: <13362B87-63CC-11D8-A3A6-000A95D9C74C@nominum.com> <200402200859.i1K8xjGl005317@relay2.apple.com> <26638.1077281348@munnari.OZ.AU> <27314.1077307581@munnari.OZ.AU> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <FF98CA65-642E-11D8-9D00-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> From: Ted Lemon <Ted.Lemon@nominum.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sat, 21 Feb 2004 00:30:02 -0500 To: Robert Elz <kre@munnari.OZ.AU> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 20, 2004, at 3:06 PM, Robert Elz wrote: > | Am I wrong here? Can you or Christian explain why it's so likely > that > | this scenario could come to pass? > > I don't think it is likely at all. But if the routers aren't going to > be broken this way, and I don't think they are likely to be, then > there's > no point at all doing the TTL==255 check for multicast, as any packet > that > would fail it, will have already been dropped by the router. > > > Stuart Cheshire <cheshire@apple.com> said: > > | The immediate value is primarily for unicast packets, and less so > for > | multicast packets. > > This is looking promising, as I think just about all of the arguments > for > TTL=1 rather than TTL=255 come from the multicast arguments. If we > can > get the "less so" down to "irrelevant for", then perhaps we have a > compromise > in the offing. Okay, I'm happy. I don't really care about the multicast argument as long as it doesn't prevent forward progress. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 23 14:22:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13547 for <dnsext-archive@lists.ietf.org>; Mon, 23 Feb 2004 14:22:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvLZo-000NWS-Tw for namedroppers-data@psg.com; Mon, 23 Feb 2004 19:17:12 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvLZn-000NW5-FI for namedroppers@ops.ietf.org; Mon, 23 Feb 2004 19:17:11 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i1NJDhKa028280; Mon, 23 Feb 2004 14:13:43 -0500 (EST) Received: from unknown(158.69.80.188) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0iaio3; Mon, 23 Feb 04 14:13:41 -0500 Subject: Re: draft: resolver-application interface From: Suresh Krishnaswamy <suresh@tislabs.com> To: Miek Gieben <miekg@atoom.net> Cc: namedroppers <namedroppers@ops.ietf.org> In-Reply-To: <20040212144444.GA18697@atoom.net> References: <20040212144444.GA18697@atoom.net> Content-Type: text/plain Message-Id: <1077563670.1989.62.camel@spooky.columbia.sparta.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 23 Feb 2004 14:14:30 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Miek, I think this draft is a good start towards defining the interface between the resolver and the application for signalling error and status information. You've already covered some of the following error codes; I've tried to disambiguate (for my own reference mostly) the meaning associated with some of them. XX UNSECURE - No signatures are present, not required to be present either (provable non-existence of parent DS, no local trust anchor) XX INDETERMINATE - signatures present, DNSKEY record present, but no authentication chain could be found that would allow validation of the signatures (missing or different local trusted anchor, provable non-existence of parent DS, or parent DS does not cover the zone DNSKEY). Q. Is this same as bit field 9 -- delegation problem DS/KEY ? 00 NODNSKEY - signatures present, but no DNSKEY could be retrieved for the zone 05 BOGUS - some signature was required to be present (parent DS said so, or by local trusted anchor setting),the sig was present but it failed validation 01 NODS - DS should have been present in the parent (some NSEC told us so) but the DS record could not be retrieved. 02-03 only relevant to the signature verification operation directly -- so these error codes indicate the absence of NSECs, SIGs for the name being directly queried for (and not the absence of NSECs, SIGs that would otherwise tell us that the parent DS is missing for example). Is the above interpretation same as what you had envisioned? I also seemed to think that there was a need for the following additional status codes as well: XX NOCLRPATH - one or more intermediate name servers does not support DNSSEC XX LOCPOL - some local policy decision has contributed to the resultant set of RRs/flags An open question is whether the error/status codes should actually be defined as extended RCODEs as opposed to a bit array. Suresh On Thu, 2004-02-12 at 09:44, Miek Gieben wrote: > Hello, > > During the LCWS workshop of a few weeks ago the topic was also discussed: what > does an application wants/needs to know from a secure aware resolver. I then > said I was working on a draft trying to initiate and focus that discussion. > > During the last few days this topic has also (sort of) sprung up on the > namedroppers ML. I'm not sure the draft is dnsop or dnsext material, but > I'm posting it here as I feel we were already discussing these sort of > things. > > It is still a *very rough* draft, but I didn't want it to delay any more > than it already has. > > Authors: > Gilles Guette, Olivier Courtay and Miek Gieben > > Abstract: > This document describes an interface between a DNSSEC aware resolver > and an application. This interface will define which kind of > information a DNSSEC aware resolver is able to send back to an > application. The basic question we want to answer is: "What does an > application wants to know from a secure aware resolver?". > > In section Section 4 we define an error bit array. The secure aware > resolver will set specific bits in the array. With the added > information in this error array, the application can have extra > control on what to do with bogus data. > > This document is written in the hope that it will lead to a > discussion within the IETF on the resolver-application > interaction(s). > > Where: > http://www.nlnetlabs.nl/dnssec/draft-gieben-resolver.txt > > > grtz > Miek > -- > ...all white space is equivalent except in certain situations... > - C99 Standard -- http://www.vmunix.com/~gabor/c/draft.html > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 08:46:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19871 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 08:46:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avcjm-0003AH-85 for namedroppers-data@psg.com; Tue, 24 Feb 2004 13:36:38 +0000 Received: from [199.5.47.154] (helo=usvwoaahs35.abh.vw.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avcjl-0003A4-Ac for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 13:36:37 +0000 Received: by usvwoaahs35.abh.vw.com with Internet Mail Service (5.5.2657.72) id <1XW2MN2X>; Tue, 24 Feb 2004 08:36:36 -0500 Message-ID: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> From: "Burns, Mike" <Extern.Mike.Burns@gedas.com> To: "'Stuart Cheshire'" <cheshire@apple.com> Cc: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org>, "'Robert Elz'" <kre@munnari.OZ.AU>, "'Christian Huitema'" <huitema@windows.microsoft.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 24 Feb 2004 08:36:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 20 Feb 2004, Stuart Cheshire wrote: >then checking TTL=255 >on reception verifies that no off-net interloper has managed to slip a >few remote unicast responses in with the legitimate local unicast >responses. If you check for TTL>1 then the interloper could only come from 1 hop away, which in most cases is a router core network(ISP,Corp) with a limited number of hosts. >This could expose hosts to >off-net attack. By setting and checking TTL=255, hosts are protected from >this vulnerability Neither setting will protect the host since it could be bombarded by a DDOS. Regardless of the TTL, the packet will still have to be processed by the host. >Suppose we used TTL=1 instead: Now the router bug might go >unnoticed for months or years, until the product is deployed in millions >of homes around the world Check for TTL>1 if you insist. It seems much more likely that a large deployment of a virus could infect a number of hosts then send LLMNR packets to flood a victim when the TTL=255, than if the TTL=1. If the TTL=1, then the packet would have to be crafted, which is easily enough to do on a distributed basis, but is not common (crafting of packets with a virus). Most virus creators are lazy and use the existing OS functionalities. Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 12:37:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00639 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 12:37:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvgQe-00037s-Di for namedroppers-data@psg.com; Tue, 24 Feb 2004 17:33:08 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvgQb-00037e-V6 for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 17:33:06 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i1OHVSmP027573; Wed, 25 Feb 2004 00:31:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1OHSbQ11429; Wed, 25 Feb 2004 00:29:08 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: "Burns, Mike" <Extern.Mike.Burns@gedas.com> cc: "'Stuart Cheshire'" <cheshire@apple.com>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org>, "'Christian Huitema'" <huitema@windows.microsoft.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> References: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Feb 2004 00:28:36 +0700 Message-ID: <20558.1077643716@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 24 Feb 2004 08:36:35 -0500 From: "Burns, Mike" <Extern.Mike.Burns@gedas.com> Message-ID: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> | If you check for TTL>1 then the interloper could only come from 1 hop | away, This is nonsense. If one wants to check whether the sender is local, at the receiver, the only thing that works is to set TTL=255, and check that the TTL is still 255 when the packet arrives. Checking that the arriving TTL is 1 is an absolute waste of time. If you don't understand this, you most likely shouldn't be participating in this debate, as you're just confusing the issue. | Neither setting will protect the host since it could be bombarded by a | DDOS. Anyone can bombard the host with any packets at all. Neither LLMNR nor Rendezvous has anything whatever to do with that. Worrying about that happening is absurd (by which I mean, only worry about things that you can control, the uncontrollable will either happen, or not, whatever we do - or worry about). The TTL=1 argument provides nothing at all that helps avoid DoS attacks - what the specification says should be done is irrelevant to an attacker, if they want to bombard you, and they're 10 hops away, they'll set the TTL to 11 (or more) regardless of what the spec says it should be set to. Using TTL of 1 (for multicast packets) is to avoid the legitimate traffic, packets that are supposed to be there, from possibly escaping and being sent further than they should (a quite remote possibility, but one which would be bad if it happened). For unicast packets, being able to verify that the host is on link just may have some (small) benefit, stopping packets accidentally escaping has essentially none, so TTL of 255 there makes (some) sense. While Bernard is right, that for TCP, a TTL of 1 would also work, I don't think I really want that level of detail being checked, and would prefer if simply all unicast was treated the same. Eg: if instead of TCP, it is T/TCP (which avoids the 3 way handshake, often) does the argument still hold? What would we do if SCTP or HIP was ever being used? This is all just too much to worry about - the unicast vs multicast is a simple distinction, leave it at that. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 13:21:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02709 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 13:21:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avh8i-0007yg-A9 for namedroppers-data@psg.com; Tue, 24 Feb 2004 18:18:40 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avh8h-0007yN-3T for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 18:18:39 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 832817; Tue, 24 Feb 2004 12:18:37 -0600 Message-ID: <403B957C.8000809@ehsco.com> Date: Tue, 24 Feb 2004 12:18:36 -0600 From: "Eric A. Hall" <ehall@ehsco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz <kre@munnari.OZ.AU> CC: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> <20558.1077643716@munnari.OZ.AU> In-Reply-To: <20558.1077643716@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 2/24/2004 11:28 AM, Robert Elz wrote: > is all just too much to worry about - the unicast vs multicast is a > simple distinction, leave it at that. Is such a distinction even necessary, really? Is the actual threat harmful enough to impose even this cost on the nodes? I mean, if we think the threat is so small that we don't feel compelled to make the TTL check mandatory, then why are we even worrying about it? All messages MUST have TTL=1 gets the same 99.9999% protection at less cost. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 13:41:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03378 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 13:41:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvhSG-000AJc-M4 for namedroppers-data@psg.com; Tue, 24 Feb 2004 18:38:52 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvhSF-000AJP-Qn for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 18:38:51 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 10:38:30 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Feb 2004 10:38:48 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 10:38:49 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 10:38:50 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Feb 2004 10:39:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 24 Feb 2004 10:38:29 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA07994F50@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal Thread-Index: AcP6/DYoWEMsDtIHQ2uto2/8YoqqdAACLKwA From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Robert Elz" <kre@munnari.OZ.AU>, "Burns, Mike" <Extern.Mike.Burns@gedas.com> Cc: "Stuart Cheshire" <cheshire@apple.com>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 24 Feb 2004 18:39:10.0596 (UTC) FILETIME=[7E204C40:01C3FB05] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > The TTL=3D1 argument provides nothing at all that helps avoid DoS > attacks - what the specification says should be done is irrelevant > to an attacker, if they want to bombard you, and they're 10 hops > away, they'll set the TTL to 11 (or more) regardless of what the > spec says it should be set to. The difference is with reflection attacks. A worm sends an LLMNR request to the local network, spoofing the source address of a target. With TTL=3D255, the response to the request can bomb any site on the = Internet; with TTL=3D1, the response will only travel one hop. -- Christian Huitema=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 13:52:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03595 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 13:52:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvhdN-000Bhi-Fk for namedroppers-data@psg.com; Tue, 24 Feb 2004 18:50:21 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvhdM-000BhK-HE for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 18:50:20 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3913014C58 for <namedroppers@ops.ietf.org>; Tue, 24 Feb 2004 18:50:20 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: Message from "Christian Huitema" <huitema@windows.microsoft.com> of "Tue, 24 Feb 2004 10:38:29 PST." <DAC3FCB50E31C54987CD10797DA511BA07994F50@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 24 Feb 2004 18:50:20 +0000 Message-Id: <20040224185020.3913014C58@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > The TTL=1 argument provides nothing at all that helps avoid DoS > > attacks - what the specification says should be done is irrelevant > > to an attacker, if they want to bombard you, and they're 10 hops > > away, they'll set the TTL to 11 (or more) regardless of what the > > spec says it should be set to. > > The difference is with reflection attacks. A worm sends an LLMNR request > to the local network, spoofing the source address of a target. With > TTL=255, the response to the request can bomb any site on the Internet; > with TTL=1, the response will only travel one hop. once again we see that there are cogent arguments to be made for both ttl settings, but that consensus proves elusive. we can flipflop on this for many years to come, or we can find a compromise (which means "a solution which displeases everyone equally".) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 14:01:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04062 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 14:01:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avhll-000Com-WE for namedroppers-data@psg.com; Tue, 24 Feb 2004 18:59:01 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avhll-000CoP-5q for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 18:59:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 03B2314BBE for <namedroppers@ops.ietf.org>; Tue, 24 Feb 2004 18:59:01 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: today in dnssec, 10 years ago X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 24 Feb 2004 18:59:01 +0000 Message-Id: <20040224185901.03B2314BBE@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk on february 23 1994, the dns protocol community had completed about six months of private discussion and four months of public discussion, and donald eastlake (then at digital equipment corp., r.i.p.) forwarded his first draft of what he thought represented the best ideas put forward up to that point. > To: dns-security@tis.com > Cc: dee@lkg.dec.com > Subject: dns security drafts > Date: Wed, 23 Feb 94 13:54:00 -0500 > From: "Donald E. Eastlake 3rd (Beast)" <dee@skidrow.lkg.dec.com> > X-Mts: smtp > > Well, it took longer to get out than I thought and it could use work > but here it is. I'm also submitting it to internet-drafts. > > Donald > > --------------------------------------------------------------------------- > Donald E. Eastlake, III DTN: 226-6577(w) dee@lkg.dec.com > 550 King St, LKG2-1/BB3 1-508-486-6577(w) dee@ranger.enet.dec.com > Littleton, MA 01460 USA 1-508-486-7417(fax) 1-508-287-4877(h) > > INTERNET-DRAFT DNS Protocol Security Extensions > 23 February 1994 > Expires 22 August 1994 > > > > Domain Name System Protocol Security Extensions > ------ ---- ------ -------- -------- ---------- > Donald E. Eastlake 3rd & Charles W. Kaufman > ... often on such anniversaries, glasses are filled with bubbly and raised, and words are spoken of the form "and here's to another wonderful ten years to come!" but maybe this time not so much so. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 15:31:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09594 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 15:31:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avj99-000KuE-TJ for namedroppers-data@psg.com; Tue, 24 Feb 2004 20:27:15 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avj96-000Ktn-Mu for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 20:27:12 +0000 Received: from [10.255.215.22] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id 8B56C1B3D4A; Tue, 24 Feb 2004 14:13:42 -0600 (CST) In-Reply-To: <20040224185020.3913014C58@sa.vix.com> References: <20040224185020.3913014C58@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <D3F2ECC4-6707-11D8-A76A-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 24 Feb 2004 15:27:12 -0500 To: Paul Vixie <paul@vix.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 24, 2004, at 1:50 PM, Paul Vixie wrote: >> The difference is with reflection attacks. A worm sends an LLMNR >> request >> to the local network, spoofing the source address of a target. With >> TTL=255, the response to the request can bomb any site on the >> Internet; >> with TTL=1, the response will only travel one hop. > > once again we see that there are cogent arguments to be made for both > ttl settings, but that consensus proves elusive. we can flipflop on > this for many years to come, or we can find a compromise (which means > "a solution which displeases everyone equally".) I beg to differ. This is not a cogent argument, because the bombing scenario can't happen unless all the routers on the internet are very carefully broken. Furthermore, it's an irrelevant argument, because we've (at least, some of us have) agreed that we don't need the TTL=255 check for multicast anyway, and it's sufficient to have it just for unicast. I think we're very close to a compromise here, if the authors are willing to consider the proposed changes. I don't understand why Christian brought up the bomb argument again, or what it has to do with the ongoing discussion. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 16:17:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11585 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 16:17:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvjtQ-0001ie-UM for namedroppers-data@psg.com; Tue, 24 Feb 2004 21:15:04 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvjtM-0001fh-Qw for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 21:15:01 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i1OLD8mP004001; Wed, 25 Feb 2004 04:13:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1OL7QQ29018; Wed, 25 Feb 2004 04:07:29 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: "Christian Huitema" <huitema@windows.microsoft.com> cc: "Burns, Mike" <Extern.Mike.Burns@gedas.com>, "Stuart Cheshire" <cheshire@apple.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA07994F50@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> References: <DAC3FCB50E31C54987CD10797DA511BA07994F50@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Feb 2004 04:07:26 +0700 Message-ID: <2914.1077656846@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 24 Feb 2004 10:38:29 -0800 From: "Christian Huitema" <huitema@windows.microsoft.com> Message-ID: <DAC3FCB50E31C54987CD10797DA511BA07994F50@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> | The difference is with reflection attacks. A worm sends an LLMNR request | to the local network, spoofing the source address of a target. With | TTL=255, the response to the request can bomb any site on the Internet; | with TTL=1, the response will only travel one hop. This works only if the request is one that many nodes on the local link will answer. If only one (or a small number) reply, then the bomb is just 2 or 3 packets, which isn't much to be concerned about. If there is some request that lots of nodes will answer, which would make that an affective attack, then really what ought to be done is to fix things so that there aren't lots of answers - that's useful just for local genuine queries, which don't want a hundred answers either. Even with TTL=1, if there was an avenue for attack here, it would be a good way to neutralise a system on a link - just get everyone else on the link to bomb it. That we don't want - so preventing the mass replies is the better solution. kre ps: Ted, Christian's scenario here involves unicast replies aimed at a victim, this one isn't multicast. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 16:37:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12590 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 16:37:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvkCg-0003tq-1I for namedroppers-data@psg.com; Tue, 24 Feb 2004 21:34:58 +0000 Received: from [213.243.180.204] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvkCe-0003te-5u for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 21:34:56 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id i1OLZcbG008610; Tue, 24 Feb 2004 23:35:39 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id i1OLZXYv008609; Tue, 24 Feb 2004 23:35:33 +0200 Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal From: Mika Liljeberg <mika.liljeberg@welho.com> To: Ted Lemon <mellon@nominum.com> Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <D3F2ECC4-6707-11D8-A76A-000A95D9C74C@nominum.com> References: <20040224185020.3913014C58@sa.vix.com> <D3F2ECC4-6707-11D8-A76A-000A95D9C74C@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1077658533.891.22.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 24 Feb 2004 23:35:33 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2004-02-24 at 22:27, Ted Lemon wrote: > I beg to differ. This is not a cogent argument, because the bombing > scenario can't happen unless all the routers on the internet are very > carefully broken. Furthermore, it's an irrelevant argument, because > we've (at least, some of us have) agreed that we don't need the TTL=255 > check for multicast anyway, and it's sufficient to have it just for > unicast. Reflection attack is a possibility if the attacker sends a spoofed query to a multicast group of higher than link-local scope or to a broadcast address. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 18:27:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16895 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 18:27:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avluq-000F1f-V1 for namedroppers-data@psg.com; Tue, 24 Feb 2004 23:24:40 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avluq-000F1S-2U for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 23:24:40 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 24 Feb 2004 15:24:39 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Feb 2004 15:24:34 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 15:24:39 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Feb 2004 15:24:37 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Feb 2004 15:24:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 24 Feb 2004 15:24:16 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA07A0166B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal Thread-Index: AcP7H4fm0A1IJhlZQs2SBe+NTi9FjQADaz7Q From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Mika Liljeberg" <mika.liljeberg@welho.com>, "Ted Lemon" <mellon@nominum.com> Cc: "Paul Vixie" <paul@vix.com>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 24 Feb 2004 23:24:38.0278 (UTC) FILETIME=[5F052A60:01C3FB2D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > I beg to differ. This is not a cogent argument, because the bombing > > scenario can't happen unless all the routers on the internet are very > > carefully broken. Furthermore, it's an irrelevant argument, because > > we've (at least, some of us have) agreed that we don't need the TTL=3D255 > > check for multicast anyway, and it's sufficient to have it just for > > unicast. >=20 > Reflection attack is a possibility if the attacker sends a spoofed query > to a multicast group of higher than link-local scope or to a broadcast > address. Think of the ICMP "smurf" attack, only use LLMNR instead of ping. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 19:11:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18246 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 19:11:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvmcD-000KJT-Ly for namedroppers-data@psg.com; Wed, 25 Feb 2004 00:09:29 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvmcC-000KJC-OA for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 00:09:28 +0000 Received: from [10.255.204.233] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id 656F11B3EFA; Tue, 24 Feb 2004 17:55:57 -0600 (CST) In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA07A0166B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> References: <DAC3FCB50E31C54987CD10797DA511BA07A0166B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <E24647F6-6726-11D8-9AFF-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> From: Ted Lemon <Ted.Lemon@nominum.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 24 Feb 2004 19:09:31 -0500 To: "Christian Huitema" <huitema@windows.microsoft.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 24, 2004, at 6:24 PM, Christian Huitema wrote: > Think of the ICMP "smurf" attack, only use LLMNR instead of ping. Right, which argues for making sure that the recipient of an LLMNR packet that originated off-link never replies to it. Of course, you can argue that the right fix is to make sure that the packet sent by the recipient never makes it off the link (this is the require TTL==1 fix), but what if the attack is on a node that's *on* the link? In either scenario, brokenness is bad; it's just differently bad. The bottom line is that we have to trust that *somebody* is going to get their implementation right. You can get a smurf attack with either kind of bad implementation. So I think that arguing about smurf attacks and how they might happen, while important, is not relevant to the question of whether to use TTL=1 or TTL=255. Just as a reminder here, the smurf attack uses nodes that are compliant with the relevant ICMP and IP RFCs. Here, in order for the attack to work, nodes have to fail to comply with the RFC (assuming we ever get an RFC out of this process!). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 22:18:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24002 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 22:18:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvpVb-000Ffp-EF for namedroppers-data@psg.com; Wed, 25 Feb 2004 03:14:51 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvpVa-000FfS-2J for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 03:14:50 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i1P3Eh0d006405; Tue, 24 Feb 2004 22:14:43 -0500 To: Ted Lemon <Ted.Lemon@nominum.com> Cc: "Christian Huitema" <huitema@windows.microsoft.com>, namedroppers <namedroppers@ops.ietf.org> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <DAC3FCB50E31C54987CD10797DA511BA07A0166B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <E24647F6-6726-11D8-9AFF-000A95D9C74C@nominum.com> From: Derek Atkins <derek@ihtfp.com> Date: Tue, 24 Feb 2004 22:14:43 -0500 In-Reply-To: <E24647F6-6726-11D8-9AFF-000A95D9C74C@nominum.com> (Ted Lemon's message of "Tue, 24 Feb 2004 19:09:31 -0500") Message-ID: <sjmptc326l8.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It sounds like you want two things here, but it also sounds like all of them need to happen in the responder. The attacker could theoretically send packets of any type, with any TTL. So you can't trust anything you receive from the network. To this affect, I think: 1) We want the responder to try to determine that a request came from the local network. The best way to do this is for the responder to check that TTL=255 to make sure. If a TTL is less than 255 then it originiated off-net and can be dropped. 2) We want the responder to make sure response packets don't go off-net. In other words, we want the responder to respond with TTL=1, to make sure it can't smurf. So, to this affect: a) an LLMNR requestor should send requests with TTL=255 b) an LLMNR responder should verify requests have TTL=255 -- if it is not 255 then it should drop the packet. c) an LLMNR responder should respond with TTL=1 d) I dont' think an LLMNR requestor needs to check the response TTL. The only issue this doesn't directly solve is a requester being spoofed by an off-net attacker, but said attacker would need to guess the transaction id of the request in order to send a valid response, which is just as likely in LLMNR as it is in standard DNS, so it can probably be ignored. So, other than this issue, does this solve the issue? -derek Ted Lemon <Ted.Lemon@nominum.com> writes: > On Feb 24, 2004, at 6:24 PM, Christian Huitema wrote: >> Think of the ICMP "smurf" attack, only use LLMNR instead of ping. > > Right, which argues for making sure that the recipient of an LLMNR > packet that originated off-link never replies to it. Of course, you > can argue that the right fix is to make sure that the packet sent by > the recipient never makes it off the link (this is the require TTL==1 > fix), but what if the attack is on a node that's *on* the link? In > either scenario, brokenness is bad; it's just differently bad. > > The bottom line is that we have to trust that *somebody* is going to > get their implementation right. You can get a smurf attack with > either kind of bad implementation. So I think that arguing about > smurf attacks and how they might happen, while important, is not > relevant to the question of whether to use TTL=1 or TTL=255. > > Just as a reminder here, the smurf attack uses nodes that are > compliant with the relevant ICMP and IP RFCs. Here, in order for the > attack to work, nodes have to fail to comply with the RFC (assuming we > ever get an RFC out of this process!). > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 25 00:40:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28544 for <dnsext-archive@lists.ietf.org>; Wed, 25 Feb 2004 00:40:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvrjE-0003V4-V0 for namedroppers-data@psg.com; Wed, 25 Feb 2004 05:37:04 +0000 Received: from [213.243.180.204] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvrjD-0003Ur-NH for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 05:37:03 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id i1P5c2bG009855; Wed, 25 Feb 2004 07:38:03 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id i1P5c14g009854; Wed, 25 Feb 2004 07:38:01 +0200 Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal From: Mika Liljeberg <mika.liljeberg@welho.com> To: Ted Lemon <Ted.Lemon@nominum.com> Cc: Christian Huitema <huitema@windows.microsoft.com>, namedroppers <namedroppers@ops.ietf.org> In-Reply-To: <E24647F6-6726-11D8-9AFF-000A95D9C74C@nominum.com> References: <DAC3FCB50E31C54987CD10797DA511BA07A0166B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <E24647F6-6726-11D8-9AFF-000A95D9C74C@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1077687481.891.33.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 25 Feb 2004 07:38:01 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2004-02-25 at 02:09, Ted Lemon wrote: > On Feb 24, 2004, at 6:24 PM, Christian Huitema wrote: > > Think of the ICMP "smurf" attack, only use LLMNR instead of ping. > > Right, which argues for making sure that the recipient of an LLMNR > packet that originated off-link never replies to it. That would be ok but there's a practical problem. Many incarnations of the socket API do not allow for checking the destination address of an incoming packet, and you can't bind a socket to a multicast address. OTOH, setting the TTL is simple and works on most systems. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 25 03:39:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03447 for <dnsext-archive@lists.ietf.org>; Wed, 25 Feb 2004 03:39:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvuWL-000Mw4-2M for namedroppers-data@psg.com; Wed, 25 Feb 2004 08:35:57 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvuWJ-000MvZ-8t for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 08:35:55 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1P8ZnHP009536; Wed, 25 Feb 2004 08:35:53 GMT To: Paul Vixie <paul@vix.com> cc: namedroppers@ops.ietf.org Subject: Re: today in dnssec, 10 years ago In-Reply-To: Message from Paul Vixie <paul@vix.com> of "Tue, 24 Feb 2004 18:59:01 GMT." <20040224185901.03B2314BBE@sa.vix.com> Date: Wed, 25 Feb 2004 08:35:48 +0000 Message-ID: <9535.1077698148@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Paul" == Paul Vixie <paul@vix.com> writes: Paul> often on such anniversaries, glasses are filled with bubbly Paul> and raised, and words are spoken of the form "and here's to Paul> another wonderful ten years to come!" but maybe this time Paul> not so much so. Indeed. Sigh. In the 60s, NASA put men on the moon in under a decade and that was a far harder engineering challenge than DNSSEC. Now this isn't a fair comparison. Even so it shows what deliverables can be achieved in a decade. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 25 07:21:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12852 for <dnsext-archive@lists.ietf.org>; Wed, 25 Feb 2004 07:21:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvxyT-000Hrl-Ll for namedroppers-data@psg.com; Wed, 25 Feb 2004 12:17:13 +0000 Received: from [196.4.160.243] (helo=fedex.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvxyR-000HrQ-LA for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 12:17:11 +0000 Received: from hypatia.dns.net (c19-rba-33.dial-up.net [196.39.10.161]) by fedex.is.co.za (Postfix) with ESMTP id E3957BF8AD; Wed, 25 Feb 2004 14:16:49 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i1PBg0S03343; Wed, 25 Feb 2004 13:42:00 +0200 Date: Wed, 25 Feb 2004 13:42:00 +0200 From: Andras Salamon <andras@dns.net> To: namedroppers@ops.ietf.org Cc: Stuart Cheshire <cheshire@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Message-ID: <20040225114200.GA2408@dns.net> References: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> <20558.1077643716@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20558.1077643716@munnari.OZ.AU> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Feb 25, 2004 at 12:28:36AM +0700, Robert Elz wrote: > Using TTL of 1 (for multicast packets) is to avoid the legitimate traffic, > packets that are supposed to be there, from possibly escaping and > being sent further than they should (a quite remote possibility, but > one which would be bad if it happened). There is nothing inherently special about LLMNR as a multicast protocol, so if we are going to worry about LLMNR we also have to worry about each multicast protocol. Using this argument, _any_ multicast protocol will have to worry about the TTL to ensure multicast packets do not propagate further than "expected". This level of layer interdependency is clearly not appropriate, and I don't think this working group can mandate changes to every multicast protocol, past, present or future. The real issue here is that LLMNR is meant to have local scope, and we are trying to implement a "local scope" constraint using a TTL hack. As Masataka Ohta and others have pointed out, on a network that is connected to another potentially hostile network (ie. the Internet), TTLs can be made to take on any values that suit a remote attacker, and therefore cannot reliably be linked with the packet being local. The TTL hack simply doesn't work to 100% guarantee "local scope", no matter how much we try to make it so. It usually works fine, but not in the presence of hostile intent. Personally, I don't see a way to 100% reliably implement a "local scope" constraint in a higher layer protocol, without mucking around in the lower layer protocols. I think we need to pick an approach, document the failure scenarios, possibly make some recommendations for filtering packets at border routers, and move on. Summarising the previous discussion: First consider the case of hostile intent. If all routers are configured to drop LLMNR packets, then the protocol is only vulnerable to local injection by an attacker, and the TTL value is then irrelevant. However, if routers are not configured to drop LLMNR packets, then the TTL=255 case is more robust since it only fails in the case of local injection (in other cases the local server will not respond to the bogus request). In the TTL=1 case a hostile remote attacker could still elicit a response by the local server, by just setting the TTL to successive values of 1, 2, ..., n, where n is the diameter of the Internet (currently around 35-40). Now consider the case of non-hostile packets slipping out by mistake, due to broken routers mishandling the multicast address. If all routers are configured to block LLMNR packets, then the TTL value used is again irrelevant. If routers do not block LLMNR packets, then the TTL=1 case is more robust. Personally, I would rather see resistance to remote attack inherent in the protocol, than trying to ensure broken routers do not cause havoc. If we want to protect against routers incorrectly treating local multicast addresses then we may as well start campaigning for every multicast protocol to include TTL "protection" against such a "threat". Why single out LLMNR? There is already operational experience with the TTL=255 approach, and it reduces the security threat to the case where an attacker can actually inject packets onto the local network. We should just adopt this approach and move on. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 25 14:30:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07053 for <dnsext-archive@lists.ietf.org>; Wed, 25 Feb 2004 14:30:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aw4fS-000KMV-FN for namedroppers-data@psg.com; Wed, 25 Feb 2004 19:26:02 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw4fP-000KLy-6j for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 19:25:59 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1PJb1127726 for <namedroppers@ops.ietf.org>; Wed, 25 Feb 2004 11:37:01 -0800 Date: Wed, 25 Feb 2004 11:37:00 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: namedroppers@ops.ietf.org Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Message-ID: <Pine.LNX.4.56.0402251135201.26975@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz noted: "While Bernard is right, that for TCP, a TTL of 1 would also work, I don't think I really want that level of detail being checked, and would prefer if simply all unicast was treated the same." I'd argue that the distinction to make is between queries and responses, not between unicast and multicast. I believe that queries of any type need to have TTL=1 (no check implied); for responses, TTL=255 can be considered, along with an (optional) check. TTL=1 on queries is really about scaling and "fast fail", not security. Since LLMNR can be used to resolve *any* name where the DNS server does not respond or responds with RCODE=0 and no RRs or RCODE=3, it was important to scaling to ensure that LLMNR queries do not escape the local link. Otherwise, LLMNR could add signficantly to DNS traffic on bottleneck links. The primary use of unicast requests is for resolution of PTR RRs. For these queries we already know the IP address. Setting TTL=1 ensures not only that these queries don't escape the local link but also that queries for off-link addresses will fail more quickly than setting TTL=255 and then waiting for a response from anywhere on the Internet. In practice, PTR RR queries will comprise a signficant fraction of all LLMNR queries, so containing these queries and "fast fail" is important. This is distinct from what TTL is used in the response or whether the sender checks TTL on the response. For a TCP query, TTL=1 is set by the sender on the SYN. The three way handshake takes care of the rest, regardless of what TTL the receiver sets on his response. This works on SCTP as well. Christian Huitema noted: "Think of the ICMP "smurf" attack, only use LLMNR instead of ping." LLMNR does not support wildcard queries, so that I don't believe that this attack is possible against a properly functioning implementation. A host should only respond to queries for names for which it is authoritative. In the case of a cluster, you might have quite a few hosts responding to a query for the same name, but otherwise an LLMNR query will receive 0-1 responses. However, if DNS DISCOVER opcode were to be implemented on top of LLMNR such an attack would become possible, since that draft supports wildcard queries. So setting TTL=255 on a unicast UDP response and then checking has implications for the security of DNS DISCOVER opcode. Ted Lemon noted: "I think we're very close to a compromise here, if the authors are willing to consider the proposed changes." If you want to propose a change for this or any other purpose, please submit an issue in the format described here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html However, before doing that it might be helpful to be clear what the change is trying to accomplish. If the goal is to fix an issue with the LLMNR protocol, that's one thing; if the goal is to converge with Rendezvous, that is a much larger task that cannot be accomplished by a single change, particularly since it isn't even clear that the "compromise" being discussed meets Apple's requirements. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 25 16:15:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15010 for <dnsext-archive@lists.ietf.org>; Wed, 25 Feb 2004 16:15:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aw6Jk-000BLP-B0 for namedroppers-data@psg.com; Wed, 25 Feb 2004 21:11:44 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw6Jh-000BL2-GW for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 21:11:41 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2004 13:22:02 +0000 Received: from jschnizl-w2k.cisco.com (dhcp-171-71-119-186.cisco.com [171.71.119.186]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1PLBauB020020; Wed, 25 Feb 2004 13:11:39 -0800 (PST) Message-Id: <4.3.2.7.2.20040225160744.0216c7d0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Feb 2004 16:11:29 -0500 To: Andras Salamon <andras@dns.net> From: John Schnizlein <jschnizl@cisco.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Cc: namedroppers@ops.ietf.org In-Reply-To: <20040225114200.GA2408@dns.net> References: <20558.1077643716@munnari.OZ.AU> <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> <20558.1077643716@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 06:42 AM 2/25/2004, Andras Salamon wrote: >... > >Now consider the case of non-hostile packets slipping out by mistake, >due to broken routers mishandling the multicast address. If all routers >are configured to block LLMNR packets, then the TTL value used is again >irrelevant. If routers do not block LLMNR packets, then the TTL=1 case >is more robust. This is an important point that sometimes gets lost in the deeper analysis. There are very many installed routers that know nothing about LLMNR, or link-local IPv4 addresses for that matter. While these routers can be assumed to decrement TTL and drop to prevent looping traffic, it is not reasonable to demand that the introduction of new protocol features on hosts cause all the installed routers to be re-configured. John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 02:09:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20584 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 02:09:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwFXP-000FsE-6b for namedroppers-data@psg.com; Thu, 26 Feb 2004 07:02:27 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwFXJ-000Frm-QH for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 07:02:22 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i1Q71f212146; Thu, 26 Feb 2004 14:01:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1PFMPp17328; Wed, 25 Feb 2004 22:22:25 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Andras Salamon <andras@dns.net> cc: namedroppers@ops.ietf.org, Stuart Cheshire <cheshire@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <20040225114200.GA2408@dns.net> References: <20040225114200.GA2408@dns.net> <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> <20558.1077643716@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Feb 2004 22:22:25 +0700 Message-ID: <14690.1077722545@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 25 Feb 2004 13:42:00 +0200 From: Andras Salamon <andras@dns.net> Message-ID: <20040225114200.GA2408@dns.net> | There is nothing inherently special about LLMNR as a multicast protocol, No, there isn't. They're all different, and each has to make sure it has the proper mechanisms to sale properly. | so if we are going to worry about LLMNR we also have to worry about each | multicast protocol. That doesn't follow at all - each multicast protocol has to worry about itself. Including LLMR. | Using this argument, _any_ multicast protocol will | have to worry about the TTL to ensure multicast packets do not propagate | further than "expected". No, each multicast protocol has to make sure that it's properties allow it to be rationally deployed on the internet. How they do that is up to each protocol to determine. | As Masataka Ohta and others have pointed out, on a network that is | connected to another potentially hostile network (ie. the Internet), | TTLs can be made to take on any values that suit a remote attacker, We cannot depend upon any unverifiable TTL setting for security purposed (using the TTL for any kind of security is very weak), but we can specify what conforming applications should set it to. When we're concerned about scaling, rather than security, we can assume that the vast majority of the nodes that matter are obeying the specification, we don't need to imagine a million compromised nodes all trying to defeat us. | and therefore cannot reliably be linked with the packet being local. The 225 case can, as if the packet has been through a router, the TTL won't be 255 any longer, regardless of what the sender set it to. | The TTL hack simply doesn't work to 100% guarantee "local scope", no | matter how much we try to make it so. It usually works fine, but not | in the presence of hostile intent. This depends upon what we're trying to achieve. The intent of the TTL=1 isn't to prevent anyone else from doing something to us, it is to prevent our own packets from doing harm to others - and there we can rely upon the TTL being set correctly, as we're doing it ourselves. | Personally, I don't see a way to 100% reliably implement a "local scope" | constraint in a higher layer protocol, without mucking around in the | lower layer protocols. Of course, the scope needs to actually be implemented at the network layer, which is why it is done using network addresses, or the TTL, both of which are network layer concepts. | Summarising the previous discussion: You're only considering the security implications, which are important, but which are only a part of what needs to be considered. That seems to be a lot of the problem we have here - most participants are looking at just one issue, and seeing how they can handle that one, and ignoring everything else. | First consider the case of hostile intent. If all routers are configured | to drop LLMNR packets, That's never going to happen in general. Multicast packets perhaps, but not unicast. They're just random UDP (or perhaps TCP) packets. | In the TTL=1 case a hostile remote attacker could still elicit a response | by the local server, by just setting the TTL to successive values of 1, 2, | ..., n, where n is the diameter of the Internet (currently around 35-40). Yes, absolutely, though there's no need to do that expanding search, as no-one is going to check that the arriving TTL is 1, that's an utter waste of time - so simply sending a packet with a "bit enough" TTL would do. However, all this happens is cause the server to send a response, if all the TTLs were 1, then the response wouldn't get very far, would it? | Personally, I would rather see resistance to remote attack inherent in | the protocol, Which particular remote attack? The one you're concerned about isn't the same one Stuart is concerned with (he's concerned with bogus replies being injected - ie: one assumes (infers) that a query is being sent, and generates a reply to the assumed query). And you also need to look and see what the overall damage might be, and what other ways there are to mount a similar attach (no point doing anything to prevent an attack that it is trivial to succeed at using a different mechanism). | There is already operational experience with the TTL=255 approach, | and it reduces the security threat to the case where an attacker can | actually inject packets onto the local network. Actually, no, it doesn't - if the attacker can inject packets into the local net, then TTL=1 is better, as there at least replies (and queries) go nowhere. TTL=255 provides some protection from attackers who cannot inject packets into the local net, but who are able to determine enough about local activities to know when and how to generate a plausible fake reply. This is actually a very hard thing to do (knowing when a query might be made isn't too hard in some cases - the attacker can cause that, knowing enough about the query (its source port, ID, ...) to generate a reply that will be accepted, without being able to observe the query isn't nearly so easy. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 03:52:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28485 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 03:52:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwH9W-0001cp-Af for namedroppers-data@psg.com; Thu, 26 Feb 2004 08:45:54 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwH9V-0001cR-3A for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 08:45:53 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1Q8ukx11322; Thu, 26 Feb 2004 00:56:46 -0800 Date: Thu, 26 Feb 2004 00:56:46 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Robert Elz <kre@munnari.OZ.AU> cc: huitema@microsoft.com, Ted.Lemon@nominum.com, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <18511.1077781197@munnari.OZ.AU> Message-ID: <Pine.LNX.4.56.0402260033240.9880@internaut.com> References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Scaling yes, "fast fail" no - the TTL cannot cause anything to happen > faster than it otherwise would (well, the packet may get discarded in > the net quicker, but as you can't rely upon getting an ICMP back, this > is essentially invisible). You can't rely on getting an ICMP back, but if one is received then it can be treated as though a response was received with RCODE=0 and an empty answer section, assuming that the ICMP error payload can be verified. This is described in Section 2.4. > > | Setting TTL=1 ensures not only that these queries don't escape the local > | link > > Yes (though personally in this case I'm not sure that matters, in general > I think the in-addr.arpa (and in6.arpa) trees are a mistake, and if we want > to know someone's name, we should just ask them - wherever they are). The concern was that the volume of these queries could be substantial. Today's hosts do send PTR queries, and frequently (up to 30% of the time) do not receive an answer to them. Setting TTL=255 on unicast queries will cause bandwidth to be consumed on other links, which is hard to justify for a link-local protocol. > I certainly agree that TTL checking for security purposes (in the > "did this packet originate on the local link", for as much security > as that affords, which isn't much) is useful only when receiving > responses. Exactly. That's why this discussion should really be about responses, not queries. If there is to be a "compromise" I believe that it should be to set TTL=255 on responses and (optionally) check on the sender, while *always* setting TTL=1 on queries. > | However, if DNS DISCOVER opcode were to be implemented on top of LLMNR > > The DISCOVER opcode shouldn't be implemented anywhere - but again, that's > another discussion. If that's the WG consensus, then I believe that we can dismiss the DoS arguments against setting TTL=255 on Responses, since this really can't be used to do much harm with a conformant LLMNR implementation. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 09:48:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16239 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 09:48:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwMit-000FIF-Cm for namedroppers-data@psg.com; Thu, 26 Feb 2004 14:42:47 +0000 Received: from [196.4.160.243] (helo=fedex.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwMir-000FHb-Mv for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 14:42:46 +0000 Received: from hypatia.dns.net (c11-rba-104.dial-up.net [196.39.0.104]) by fedex.is.co.za (Postfix) with ESMTP id 6BEC6C028B; Thu, 26 Feb 2004 16:42:11 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i1QEgHR07178; Thu, 26 Feb 2004 16:42:17 +0200 Date: Thu, 26 Feb 2004 16:42:16 +0200 From: Andras Salamon <andras@dns.net> To: Bernard Aboba <aboba@internaut.com> Cc: huitema@microsoft.com, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Message-ID: <20040226144216.GA7166@dns.net> References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> <Pine.LNX.4.56.0402260033240.9880@internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <Pine.LNX.4.56.0402260033240.9880@internaut.com> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote: > If there is to be a "compromise" I believe that it should be > to set TTL=255 on responses and (optionally) check on the sender, while > *always* setting TTL=1 on queries. Sounds reasonable to me. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 12:58:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29592 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 12:58:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwPiD-000BTd-QF for namedroppers-data@psg.com; Thu, 26 Feb 2004 17:54:17 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwPiA-000BSk-Sp for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 17:54:14 +0000 Received: from [10.255.205.89] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id CDB671B2117; Thu, 26 Feb 2004 11:51:49 -0600 (CST) In-Reply-To: <Pine.LNX.4.56.0402260033240.9880@internaut.com> References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> <Pine.LNX.4.56.0402260033240.9880@internaut.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <CC32B900-6884-11D8-ACFB-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: Robert Elz <kre@munnari.OZ.AU>, huitema@microsoft.com, namedroppers@ops.ietf.org From: Ted Lemon <Ted.Lemon@nominum.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 26 Feb 2004 12:54:17 -0500 To: Bernard Aboba <aboba@internaut.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 26, 2004, at 3:56 AM, Bernard Aboba wrote: > The concern was that the volume of these queries could be substantial. > Today's hosts do send PTR queries, and frequently (up to 30% of the > time) > do not receive an answer to them. Setting TTL=255 on unicast queries > will > cause bandwidth to be consumed on other links, which is hard to justify > for a link-local protocol. Can you explain how this is going to happen, in the case of a unicast? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 14:47:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05051 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 14:47:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwRMZ-000Mxs-DB for namedroppers-data@psg.com; Thu, 26 Feb 2004 19:40:03 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwRMI-000Mvy-CS for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 19:39:46 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1QJcpLN021112 for <namedroppers@ops.ietf.org>; Thu, 26 Feb 2004 14:38:51 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1QJcoL4021102 for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 14:38:50 -0500 (EST) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw8Y4-0005VT-RY for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 23:34:40 +0000 Received: from [10.255.204.225] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id 6CCF61B26EC; Wed, 25 Feb 2004 17:32:20 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040225160744.0216c7d0@wells.cisco.com> References: <20558.1077643716@munnari.OZ.AU> <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> <20558.1077643716@munnari.OZ.AU> <4.3.2.7.2.20040225160744.0216c7d0@wells.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <305A1A99-67EB-11D8-B23B-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Wed, 25 Feb 2004 18:34:43 -0500 To: John Schnizlein <jschnizl@cisco.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Feb 25, 2004, at 4:11 PM, John Schnizlein wrote: > There are very many installed routers that know nothing about LLMNR, or > link-local IPv4 addresses for that matter. While these routers can be > assumed to decrement TTL and drop to prevent looping traffic, it is not > reasonable to demand that the introduction of new protocol features on > hosts cause all the installed routers to be re-configured. AFAIK the whole reason for this discussion is that we are trying to come up with a protocol that will work and not create packet storms in the absence of any modified routers. :') -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 14:51:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05312 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 14:51:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwRUo-000O7G-UH for namedroppers-data@psg.com; Thu, 26 Feb 2004 19:48:34 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwRUd-000O6J-5C for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 19:48:23 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1QJxEw19571; Thu, 26 Feb 2004 11:59:14 -0800 Date: Thu, 26 Feb 2004 11:59:13 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Ted Lemon <Ted.Lemon@nominum.com> cc: Robert Elz <kre@munnari.OZ.AU>, huitema@microsoft.com, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <CC32B900-6884-11D8-ACFB-000A95D9C74C@nominum.com> Message-ID: <Pine.LNX.4.56.0402261157260.19445@internaut.com> References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> <Pine.LNX.4.56.0402260033240.9880@internaut.com> <CC32B900-6884-11D8-ACFB-000A95D9C74C@nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> cause bandwidth to be consumed on other links, which is hard to justify >> for a link-local protocol. > > Can you explain how this is going to happen, in the case of a unicast? In normal operation, hosts send DNS PTR RR queries, and can either receive no response, or can receive a response with RCODE=3 (NXDOMAIN). Studies show that this can occur with as much as 30% of all PTR RR queries, since very often administrators neglect to configure these RRs. In these circumstances, (see Section 2) an LLMNR PTR RR query will be sent via unicast, as described in Section 2.4. Since the destination might not be resident on the local link, if the query has TTL=255, then it could be sent to any destination on the Internet and will traverse links other than the local one to reach that destination. By setting TTL=1 on unicast queries, this problem is avoided. If there is a default route, the gateway will typically send an ICMP "Time Exceeded" message if the destination is non-local. If the host is attached to an adhoc network, then it will ARP for the destination, and if there is no response, an error will be returned. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 17:05:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12031 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 17:05:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwTYO-000C6R-IX for namedroppers-data@psg.com; Thu, 26 Feb 2004 22:00:24 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwTY1-000C1Z-GB for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 22:00:01 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 14:00:02 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Feb 2004 14:00:01 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 14:00:58 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Feb 2004 14:00:00 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Feb 2004 14:00:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 26 Feb 2004 13:59:38 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA07ACEA9E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal Thread-Index: AcP8dufKdWJLbpq7RNOQ82EjeKAYYQAPIawA From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Andras Salamon" <andras@dns.net>, "Bernard Aboba" <aboba@internaut.com> Cc: <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 26 Feb 2004 22:00:00.0575 (UTC) FILETIME=[E14CACF0:01C3FCB3] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote: > > If there is to be a "compromise" I believe that it should be > > to set TTL=3D255 on responses and (optionally) check on the sender, while > > *always* setting TTL=3D1 on queries. >=20 > Sounds reasonable to me. I would qualify that by setting the TTL=3D255 only when the response is sent to a link local address, either IPv6 link local or IPv4 169.254/16. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 18:08:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15699 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 18:08:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwUWy-000IM2-7k for namedroppers-data@psg.com; Thu, 26 Feb 2004 23:03:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AwUWu-000IKj-Qh for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 23:02:57 +0000 Received: (qmail 19540 invoked from network); 26 Feb 2004 23:00:56 -0000 Received: from h219-110-034-038.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.34.38) by necom830.hpcl.titech.ac.jp with SMTP; 26 Feb 2004 23:00:56 -0000 Message-ID: <403E7B9B.1040707@necom830.hpcl.titech.ac.jp> Date: Fri, 27 Feb 2004 08:04:59 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Christian Huitema <huitema@windows.microsoft.com> CC: Andras Salamon <andras@dns.net>, Bernard Aboba <aboba@internaut.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <DAC3FCB50E31C54987CD10797DA511BA07ACEA9E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA07ACEA9E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian; >>>If there is to be a "compromise" I believe that it should be >>>to set TTL=255 on responses and (optionally) check on the sender, > > while > >>>*always* setting TTL=1 on queries. >> >>Sounds reasonable to me. > I would qualify that by setting the TTL=255 only when the response is > sent to a link local address, either IPv6 link local or IPv4 169.254/16. To stop packets flooding out, it should also be required that a site administrator is sure that all the local routers recognize link local addresses, which involves site dependent configuration. However, when all the local routers regognize link local addresses, there are no reason (even invalid reasons as there are no valid reasons from the beginning) to set TTL 255. With TTL of 1, the configuration becomes unnecessary. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Feb 28 13:07:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26046 for <dnsext-archive@lists.ietf.org>; Sat, 28 Feb 2004 13:07:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ax8lS-000DP9-QK for namedroppers-data@psg.com; Sat, 28 Feb 2004 18:00:38 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ax8lP-000DOs-S8 for namedroppers@ops.ietf.org; Sat, 28 Feb 2004 18:00:36 +0000 Received: from ENGILL.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1SHxPLO048274 for <namedroppers@ops.ietf.org>; Sat, 28 Feb 2004 12:59:25 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040228124513.02f35bc8@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Sat, 28 Feb 2004 13:00:06 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Advancing RFC3597 Unknown Type support --> to Draft Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This RFC was published about 6 months ago so it is now a candidate to advance through he standards track. In order to do that we need evidence of implementation, interoperabilty test and report. This message is to address the first issue, and solicit feedback on the specification from an implementations. We also would like to solicit a volunteer to coordinate the second. Please send the implementation reports to namedroppers or the chairs by March 15'th. thanks Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>

From owner-namedroppers@ops.ietf.org Sun Feb 1 03:00:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12776 for ; Sun, 1 Feb 2004 03:00:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AnCLZ-000KCJ-HF for namedroppers-data@psg.com; Sun, 01 Feb 2004 07:48:49 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnC8F-000ILt-2Z for namedroppers@ops.ietf.org; Sun, 01 Feb 2004 07:35:03 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 76F124FDB8; Sun, 1 Feb 2004 08:35:02 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 98A244FD90 for ; Sun, 1 Feb 2004 08:35:01 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i117Z10G001926 for ; Sun, 1 Feb 2004 08:35:01 +0100 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id i117Z1kS012193 for namedroppers@ops.ietf.org; Sun, 1 Feb 2004 08:35:01 +0100 Date: Sun, 1 Feb 2004 08:35:01 +0100 From: Olaf Kolkman Message-Id: <200402010735.i117Z1kS012193@x50.ripe.net> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy X-RIPE-Spam-Status: N 0.499468 X-RIPE-Signature: 8df05af8b63c4e4e6c35053813a9c004 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 08:18:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07723 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 08:18:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao0HV-000B6C-Hy for namedroppers-data@psg.com; Tue, 03 Feb 2004 13:07:57 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao0Gy-000B4M-08 for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 13:07:24 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 084FF1E88C5 for <namedroppers@ops.ietf.org>; Tue, 3 Feb 2004 14:07:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Olaf Kolkman <olaf@ripe.net> Subject: Q-28 Clarification of the scope of the document set. Date: Tue, 3 Feb 2004 14:07:21 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q-28 Clarification of the scope of the document set. This is not a protocol issue, but also more than an editorial nit, hence a question to the WG. It is about language to be added to several parts of the document set; During recent discussions it has became clear that some of the architectural considerations where too implicit. This is a first go at a draft of text that is to be added to the intro document. It needs some work on the details. It has been sitting on my disk for a bit but I have not been able to concentrate on it for the last few days (the reason is on www.geerthe,org :-) ). Note that I think that definitions of new RCODEs or EDNS0 extensions or other solutions to 'solve' the last mile communications is out of scope. --Olaf <proposed intro text> In the DNSSEC architecture the security aware resolver determines if DNS deta is in one of three states "unsecure", "validated" or "bogus". The specification in these document set is designed to make sure these 3 states can unambiguously be determined from the answers that are returned from security aware servers. Validated: Data is "validated" if one of possibly multiple authentication chains from a trust anchor to the data itself can be established. Multiple authentication chains can exist when there are multiple DS RRs at a delegation point or when data is covered by multiple RRSIGs. A security aware resolver may not have all possible authorization chains at its disposal, either because an authorization chain is based on an algorithm that has not been implemented or because there is no trust anchor for a possible authenticatio chain available. Unsecure: If no authentication chain can be established; either because there is no appropriate trust anchor or the authentication chain was broken because of the authenticated absence of DS RRs that point to keys of algorithms the resolver is able to use. If there are no trust anchors configured than all data is marked insecure. Bogus: Data that is neither validated nor unsecure: Somewhere in the authentication chain there was an RRset for which all of the RRSIG RRs did not cryptographicly verify or were intended for a different time interval. Alternatively not all needed links in the authorization chain are available e.g. because network failures. Once security aware resolvers have determined if data is 'secure', 'insecure' or 'bogus' their work is done. This specification does not define a format for communicating why data was found to be bogus or insecure. For the communication between a security aware recursive servers and security aware stub resolvers this specification defines a default policy for communicating the 3 states. The detailed specification of a method for signaling advanced error codes and or policy between a security aware stub resolver and security aware recursive nameservers is subject to future work. </proposed intro text> In addition to this text there is language to be added to the protocol document that defines the behavior for security aware recursive nameservers. Roughly (because the CD bit behavior is ignored for now) like: If the security aware recursive nameserver validates data as "unsecure" it forwards data to the the security aware stub resolver without the ad bit set. If the security aware recursive nameserver validates data as "secure" it forwards data to the the security aware stub resolver with the ad bit set. If the security aware recursive nameserver validates data as "bogus" it returns an answer with RCODE=SERVFAIL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 12:57:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21512 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 12:57:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao4eD-000Lg7-Ov for namedroppers-data@psg.com; Tue, 03 Feb 2004 17:47:41 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao4e0-000LeG-E0 for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 17:47:28 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i13HkxjO028293 for <namedroppers@ops.ietf.org>; Tue, 3 Feb 2004 12:47:00 -0500 (EST) Message-ID: <013b01c3ea7d$ba8a8e40$b9370681@barnacle> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: Q-29: Resolver Handling of expired RRSIGs Date: Tue, 3 Feb 2004 12:47:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q-29 Resolver handling of expired RRSIGs From an earlier thread and individual comments: What, if any, should be the default resolver behavior when expired RRSIGs are contained in a response? For example, The one or more RRSIGs covering a RRset in the answer section has an expiration date in the past. Currently, the text in the Records and Protocol document state that they MUST be rejected (they are to be considered "bogus", using the newly defined terminology). Some have suggested that is too harsh, and the default should be something similar to the following: "SHOULD be rejected, but MAY use RRSIGs if other security checks were successful, depending on local policy". That way, a resolver may be able to pass on success, and the data could be marked "unsecure" and passed back to a security aware stub resolver, or passed up to the application. However, if the application or stub resolvers are not security aware, this could lead to a vulnerability. Is there consensus to relax the "MUST reject expired RRSIGs" and make it less restrictive? Please suggest text if the above is not sufficient. This formal question is mainly for closure on a discussion thread that has died down. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 13:22:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22959 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 13:22:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao56l-000Prx-5k for namedroppers-data@psg.com; Tue, 03 Feb 2004 18:17:11 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao56T-000Pq8-8M for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 18:16:53 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i13IGpK12499; Tue, 3 Feb 2004 10:16:51 -0800 From: bill <bmanning@karoshi.com> Message-Id: <200402031816.i13IGpK12499@karoshi.com> Subject: Re: Q-29: Resolver Handling of expired RRSIGs To: scottr@nist.gov (Scott Rose) Date: Tue, 3 Feb 2004 10:16:51 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <013b01c3ea7d$ba8a8e40$b9370681@barnacle> from "Scott Rose" at Feb 03, 2004 12:47:01 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Q-29 Resolver handling of expired RRSIGs > > >From an earlier thread and individual comments: > > suggested that is too harsh, and the default should be something > similar to the following: > > "SHOULD be rejected, but MAY use RRSIGs if other security > checks were successful, depending on local policy". better language, imho. > Is there consensus to relax the "MUST reject expired RRSIGs" and > make it less restrictive? Please suggest text if the above is > not sufficient. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 13:37:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23567 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 13:37:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao5Lc-0001qw-GM for namedroppers-data@psg.com; Tue, 03 Feb 2004 18:32:32 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao5LP-0001oM-1c for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 18:32:19 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i13IWGG12658; Tue, 3 Feb 2004 10:32:16 -0800 From: bill <bmanning@karoshi.com> Message-Id: <200402031832.i13IWGG12658@karoshi.com> Subject: Re: Q-28 Clarification of the scope of the document set. To: olaf@ripe.net (Olaf Kolkman) Date: Tue, 3 Feb 2004 10:32:16 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> from "Olaf Kolkman" at Feb 03, 2004 02:07:21 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit changes sprinkled throughout, mainly changing "bogus" to "indeterminant", > In the DNSSEC architecture the security aware resolver determines if > DNS deta is in one of three states "unsecure", "validated" or > "bogus". The specification in these document set is designed to make > sure these 3 states can unambiguously be determined from the answers > that are returned from security aware servers. I'm unconvinced that the resolver makes this choice. a design we are working on/with has the validator as an independent module that the resolver talks to and it is the validator that determines the "state of the data" and tells the resolver. So, alternate text: In the DNSSEC architecture a security enabled resolver receives data in one of three states, "unsecure", "validated", or "indeterminant". The specification in this document set is designed to make sure these three states can unambigiously be determined from answers received from security aware and enabled servers or caches. > Validated: Data is "validated" if one of possibly multiple > authentication chains from a trust anchor to the data itself > can be established. Multiple authentication chains can exist > when there are multiple DS RRs at a delegation point or when > data is covered by multiple RRSIGs. A security aware resolver > may not have all possible authorization chains at its > disposal, either because an authorization chain is based on an > algorithm that has not been implemented or because there is no > trust anchor for a possible authenticatio chain available. > > > Unsecure: If no authentication chain can be established; either > because there is no appropriate trust anchor or the > authentication chain was broken because of the authenticated > absence of DS RRs that point to keys of algorithms the > resolver is able to use. > > If there are no trust anchors configured than all data is > marked insecure. > > Indeterminant: Data that is neither validated nor unsecure: Somewhere in the authentication chain, at the time when authentication was tried, there was an RRset for which all of the RRSIG RRs did not cryptographically i verify or were intended for a different time interval. Alternatively not all needed links in the authorization chain were available e.g. because network failures. Recovery or Retry, in an attempt to reach a validated state are out side the scope of this definition. > Once security aware resolvers have determined if data is 'secure', 'insecure' or 'indeterminant' their work is done. This specification does not > define a format for communicating why data was found to be bogus or > insecure. For the communication between a security aware recursive > servers and security aware stub resolvers this specification defines a > default policy for communicating the 3 states. The detailed > specification of a method for signaling advanced error codes and or > policy between a security aware stub resolver and security aware > recursive nameservers is subject to future work. > > </proposed intro text> > > If the security aware recursive nameserver validates data as "indeterminant" > it returns an answer with RCODE=SERVFAIL > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 14:08:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25003 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 14:08:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao5op-0006XX-Ac for namedroppers-data@psg.com; Tue, 03 Feb 2004 19:02:43 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao5oW-0006V5-Kt for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 19:02:24 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 5EECF56852; Tue, 3 Feb 2004 11:02:21 -0800 (PST) Message-Id: <6.0.1.1.2.20040203135043.0284cc28@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 03 Feb 2004 14:02:55 -0500 To: bill <bmanning@karoshi.com>, olaf@ripe.net (Olaf Kolkman) From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: namedroppers@ops.ietf.org In-Reply-To: <200402031832.i13IWGG12658@karoshi.com> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think you're heading down the wrong direction here. There are actually 4 states. And bogus is definitely a different state than indeterminate and can get handled quite differently by a resolver. 1) Secure. I have a trust anchor, a chain of trust and I'm able to verify the signatures on all the data. 2) Unsecure. I have a trust anchor, a chain of trust, and, at the delegation point I have a signed proof of the non-existence of the DS record which makes subsequent branches in the tree provably unsecure. Resolver policy could also declare a portion of the tree unsecure from a branch point. 3) Bogus. I have a trust anchor which is giving me an expectation that subsidiary data will be signed (e.g. foo.com trust anchor implies that bar.foo.com will be signed unless its explicitly unsecure as above), but the data I'm handed fails to validate due to one or more of: missing signatures, invalid signatures (both for expiration and for the sig algorithm verification), missing data where the NXT (or what ever we're call them) say there should be data, etc. 4) Indeterminate. I have no trust anchor which would indicate that a specific portion of the tree is secure. This is the default case. Indeterminate and unsecure data should be handled more or less identically - e.g. accepted at face value if the policy allows it. Secure data should generally be accepted. Bogus data - well.... ideally this would depend on what the application cares about, but in practice it will be whatever the policy is at the caching/recursive resolver. At 01:32 PM 2/3/2004, bill wrote: > changes sprinkled throughout, mainly changing "bogus" to > "indeterminant", > > > > In the DNSSEC architecture the security aware resolver determines if > > DNS deta is in one of three states "unsecure", "validated" or > > "bogus". The specification in these document set is designed to make > > sure these 3 states can unambiguously be determined from the answers > > that are returned from security aware servers. > > I'm unconvinced that the resolver makes this choice. > a design we are working on/with has the validator as > an independent module that the resolver talks to and > it is the validator that determines the "state of the data" > and tells the resolver. So, alternate text: > > In the DNSSEC architecture a security enabled resolver receives data > in one of three states, "unsecure", "validated", or "indeterminant". > The specification in this document set is designed to make sure these > three states can unambigiously be determined from answers received > from security aware and enabled servers or caches. > > > Validated: Data is "validated" if one of possibly multiple > > authentication chains from a trust anchor to the data itself > > can be established. Multiple authentication chains can exist > > when there are multiple DS RRs at a delegation point or when > > data is covered by multiple RRSIGs. A security aware resolver > > may not have all possible authorization chains at its > > disposal, either because an authorization chain is based on an > > algorithm that has not been implemented or because there is no > > trust anchor for a possible authenticatio chain available. > > > > > > Unsecure: If no authentication chain can be established; either > > because there is no appropriate trust anchor or the > > authentication chain was broken because of the authenticated > > absence of DS RRs that point to keys of algorithms the > > resolver is able to use. > > > > If there are no trust anchors configured than all data is > > marked insecure. > > > > >Indeterminant: Data that is neither validated nor unsecure: Somewhere in the > authentication chain, at the time when authentication was > tried, there > was an RRset for which all of the RRSIG RRs did not > cryptographically i > verify or were intended for a different time interval. > Alternatively not > all needed links in the authorization chain were available e.g. > because > network failures. > > Recovery or Retry, in an attempt to reach a validated state are > out side the scope of this definition. > > > Once security aware resolvers have determined if data is 'secure', > 'insecure' or 'indeterminant' their work is done. This specification > does not > > define a format for communicating why data was found to be bogus or > > insecure. For the communication between a security aware recursive > > servers and security aware stub resolvers this specification defines a > > default policy for communicating the 3 states. The detailed > > specification of a method for signaling advanced error codes and or > > policy between a security aware stub resolver and security aware > > recursive nameservers is subject to future work. > > > > </proposed intro text> > > > > > If the security aware recursive nameserver validates data as "indeterminant" > > it returns an answer with RCODE=SERVFAIL > > > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 14:19:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25423 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 14:19:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao61D-0007pl-Iu for namedroppers-data@psg.com; Tue, 03 Feb 2004 19:15:31 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao60z-0007nS-1Y for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 19:15:17 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i13JFB913059; Tue, 3 Feb 2004 11:15:11 -0800 From: bill <bmanning@karoshi.com> Message-Id: <200402031915.i13JFB913059@karoshi.com> Subject: Re: Q-28 Clarification of the scope of the document set. To: Mike.StJohns@nominum.com (Mike StJohns) Date: Tue, 3 Feb 2004 11:15:11 -0800 (PST) Cc: bmanning@karoshi.com (bill), olaf@ripe.net (Olaf Kolkman), namedroppers@ops.ietf.org In-Reply-To: <6.0.1.1.2.20040203135043.0284cc28@localhost> from "Mike StJohns" at Feb 03, 2004 02:02:55 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit perhaps, but it may just be a desire to keep things "simple". for now, lets presume your four states. What else is a distingishing characteristic? I see these. the bogus lable is primarily driven by temporal events, e.g. routing anomolies, head space/timing syncronization, clocking errors, etc. secure/unsecure presume routing stability, accurate clocks and alert/aware operators. indeterminant is todays status quo. or do I have this wrong also? --bill > > I think you're heading down the wrong direction here. There are actually 4 > states. And bogus is definitely a different state than indeterminate and > can get handled quite differently by a resolver. > > > 1) Secure. I have a trust anchor, a chain of trust and I'm able to verify > the signatures on all the data. > > 2) Unsecure. I have a trust anchor, a chain of trust, and, at the > delegation point I have a signed proof of the non-existence of the DS > record which makes subsequent branches in the tree provably > unsecure. Resolver policy could also declare a portion of the tree > unsecure from a branch point. > > 3) Bogus. I have a trust anchor which is giving me an expectation that > subsidiary data will be signed (e.g. foo.com trust anchor implies that > bar.foo.com will be signed unless its explicitly unsecure as above), but > the data I'm handed fails to validate due to one or more of: missing > signatures, invalid signatures (both for expiration and for the sig > algorithm verification), missing data where the NXT (or what ever we're > call them) say there should be data, etc. > > 4) Indeterminate. I have no trust anchor which would indicate that a > specific portion of the tree is secure. This is the default case. > > Indeterminate and unsecure data should be handled more or less identically > - e.g. accepted at face value if the policy allows it. Secure data should > generally be accepted. Bogus data - well.... ideally this would depend on > what the application cares about, but in practice it will be whatever the > policy is at the caching/recursive resolver. > > > At 01:32 PM 2/3/2004, bill wrote: > > > changes sprinkled throughout, mainly changing "bogus" to > > "indeterminant", > > > > > > > In the DNSSEC architecture the security aware resolver determines if > > > DNS deta is in one of three states "unsecure", "validated" or > > > "bogus". The specification in these document set is designed to make > > > sure these 3 states can unambiguously be determined from the answers > > > that are returned from security aware servers. > > > > I'm unconvinced that the resolver makes this choice. > > a design we are working on/with has the validator as > > an independent module that the resolver talks to and > > it is the validator that determines the "state of the data" > > and tells the resolver. So, alternate text: > > > > In the DNSSEC architecture a security enabled resolver receives data > > in one of three states, "unsecure", "validated", or "indeterminant". > > The specification in this document set is designed to make sure these > > three states can unambigiously be determined from answers received > > from security aware and enabled servers or caches. > > > > > Validated: Data is "validated" if one of possibly multiple > > > authentication chains from a trust anchor to the data itself > > > can be established. Multiple authentication chains can exist > > > when there are multiple DS RRs at a delegation point or when > > > data is covered by multiple RRSIGs. A security aware resolver > > > may not have all possible authorization chains at its > > > disposal, either because an authorization chain is based on an > > > algorithm that has not been implemented or because there is no > > > trust anchor for a possible authenticatio chain available. > > > > > > > > > Unsecure: If no authentication chain can be established; either > > > because there is no appropriate trust anchor or the > > > authentication chain was broken because of the authenticated > > > absence of DS RRs that point to keys of algorithms the > > > resolver is able to use. > > > > > > If there are no trust anchors configured than all data is > > > marked insecure. > > > > > > > >Indeterminant: Data that is neither validated nor unsecure: Somewhere in the > > authentication chain, at the time when authentication was > > tried, there > > was an RRset for which all of the RRSIG RRs did not > > cryptographically i > > verify or were intended for a different time interval. > > Alternatively not > > all needed links in the authorization chain were available e.g. > > because > > network failures. > > > > Recovery or Retry, in an attempt to reach a validated state are > > out side the scope of this definition. > > > > > Once security aware resolvers have determined if data is 'secure', > > 'insecure' or 'indeterminant' their work is done. This specification > > does not > > > define a format for communicating why data was found to be bogus or > > > insecure. For the communication between a security aware recursive > > > servers and security aware stub resolvers this specification defines a > > > default policy for communicating the 3 states. The detailed > > > specification of a method for signaling advanced error codes and or > > > policy between a security aware stub resolver and security aware > > > recursive nameservers is subject to future work. > > > > > > </proposed intro text> > > > > > > > > If the security aware recursive nameserver validates data as "indeterminant" > > > it returns an answer with RCODE=SERVFAIL > > > > > > > > > -- > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 15:12:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28294 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 15:12:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao6o1-000EGD-Na for namedroppers-data@psg.com; Tue, 03 Feb 2004 20:05:57 +0000 Received: from [129.46.51.59] (helo=ithilien.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao6nm-000EDR-Oz for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 20:05:42 +0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13K5cvf005059; Tue, 3 Feb 2004 12:05:38 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13K5a1G005475; Tue, 3 Feb 2004 12:05:36 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: <p06020407bc45aed574bb@[129.46.227.161]> In-Reply-To: <6.0.1.1.2.20040203135043.0284cc28@localhost> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> Date: Tue, 3 Feb 2004 12:05:35 -0800 To: Mike StJohns <Mike.StJohns@nominum.comc.cnri.reston.va.us> From: Ted Hardie <hardie@qualcomm.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 2:02 PM -0500 02/03/2004, Mike StJohns wrote: >Bogus data - well.... ideally this would depend on what the >application cares about, but in practice it will be whatever the >policy is at the caching/recursive resolver. I think I'm confused here. What do you think the role of the application would be? Are you thinking that on getting an error message back from the DNS, it might engage in some activity (like throwing an error in a popup or syslog)? Or are you thinking an application policy might actually cause it to accept bogus data? regards, Ted Hardie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 15:43:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29754 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 15:43:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao7K5-000Hyp-1H for namedroppers-data@psg.com; Tue, 03 Feb 2004 20:39:05 +0000 Received: from [216.168.237.102] (helo=heron.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao7Jr-000Hwg-K1 for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 20:38:51 +0000 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id i13Kcfha023651; Tue, 3 Feb 2004 15:38:41 -0500 (EST) Received: from chinook.corppc.vrsn.com ([10.131.31.52]) by VSVAPOSTALGW1.vcorp.ad.vrsn.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1FXGXTML; Tue, 3 Feb 2004 15:38:40 -0500 Received: by chinook.corppc.vrsn.com (Postfix, from userid 500) id AAE889BB88; Tue, 3 Feb 2004 15:38:36 -0500 (EST) Date: Tue, 3 Feb 2004 15:38:36 -0500 From: Matt Larson <mlarson@verisign.com> To: Mike StJohns <Mike.StJohns@nominum.com> Cc: bill <bmanning@karoshi.com>, Olaf Kolkman <olaf@ripe.net>, namedroppers@ops.ietf.org Subject: Re: Q-28 Clarification of the scope of the document set. Message-ID: <20040203203836.GA18455@chinook.corppc.vrsn.com> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.1.1.2.20040203135043.0284cc28@localhost> User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mike, I think this is on the right track. A question and a comment: On Tue, 03 Feb 2004, Mike StJohns wrote: > I think you're heading down the wrong direction here. There are actually 4 > states. And bogus is definitely a different state than indeterminate and > can get handled quite differently by a resolver. > > > 1) Secure. I have a trust anchor, a chain of trust and I'm able to verify > the signatures on all the data. > > 2) Unsecure. I have a trust anchor, a chain of trust, and, at the > delegation point I have a signed proof of the non-existence of the DS > record which makes subsequent branches in the tree provably > unsecure. Resolver policy could also declare a portion of the tree > unsecure from a branch point. I'm assuming your "branch point" is a delegation point. By your last sentence, are you envisioning the ability to configure a resolver with the notion thay, say, "Always treat foo.com and its descendants as unsecure regardless of what security records you receive that might state otherwise"? I can see this being a handy feature when a zone is known to have something wrong DNSSEC-wise but one needs to communicate with it anyway. Realistically these scenarios are going to occur. > 3) Bogus. I have a trust anchor which is giving me an expectation that > subsidiary data will be signed (e.g. foo.com trust anchor implies that > bar.foo.com will be signed unless its explicitly unsecure as above), but > the data I'm handed fails to validate due to one or more of: missing > signatures, invalid signatures (both for expiration and for the sig > algorithm verification), missing data where the NXT (or what ever we're > call them) say there should be data, etc. > > 4) Indeterminate. I have no trust anchor which would indicate that a > specific portion of the tree is secure. This is the default case. > > Indeterminate and unsecure data should be handled more or less identically > - e.g. accepted at face value if the policy allows it. I'm having a hard time appreciating why anyone would ever care about the distinction between unsecure and indeterminate. Or to put it another way, what different action would be taken based on being in one of these states vs. the other? Unless I'm missing something, one only reaches an unsecure state by discovering a deliberate entry, i.e., an administrator has to make an entry in a secure zone declaring a child zone unsecure. So there's the subtle difference of "someone went out of their way to say this is unsecure" vs. "I just don't know its status". But my question is, is the difference too subtle to be worth calling out with a fourth state? Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 15:46:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00170 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 15:46:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao7Oh-000IjL-Hm for namedroppers-data@psg.com; Tue, 03 Feb 2004 20:43:51 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao7OU-000Ih0-HW for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 20:43:38 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id CF94F18DE for <namedroppers@ops.ietf.org>; Tue, 3 Feb 2004 15:43:36 -0500 (EST) Date: Tue, 03 Feb 2004 15:43:36 -0500 From: Rob Austein <sra+namedroppers@hactrn.net> To: namedroppers@ops.ietf.org Subject: Re: Q-28 Clarification of the scope of the document set. In-Reply-To: <p06020407bc45aed574bb@[129.46.227.161]> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> <p06020407bc45aed574bb@129.46.227.161> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040203204336.CF94F18DE@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 3 Feb 2004 12:05:35 -0800, Ted Hardie wrote: > > I think I'm confused here. What do you think the role of the > application would be? > Are you thinking that on getting an error message back from the DNS, it might > engage in some activity (like throwing an error in a popup or syslog)? Or > are you thinking an application policy might actually cause it to accept > bogus data? Given that only the application really knows what the application's "security" requirements are, final decision on how to handle the bad states pretty much has to be up to the application. All the nasty stuff with the AD bit, etc, is just an attempt to extend -some- protection to all the legacy DNS software that's already out there. As I've mumbled before, sig validation is an end-to-end thing between the DNS data producer (zone admin) and the DNS data consumer (app). And yeah, sure, an application might have a policy like "the admin of this zone is known to be an incompetent bozo, and I'm doing a strong authentication check with known keys at the app layer anyway, so I don't care whether the DNSSEC sigs check out or not". Shouldn't be the default policy, but you can bet that somebody's going to need to implement something like it sooner or later for some application. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 16:24:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04090 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 16:24:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao7uB-000MmQ-W6 for namedroppers-data@psg.com; Tue, 03 Feb 2004 21:16:23 +0000 Received: from [129.46.51.58] (helo=numenor.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao7ty-000Mkn-4X for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 21:16:10 +0000 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13LG1np001865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2004 13:16:02 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13LFx67014803; Tue, 3 Feb 2004 13:16:00 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: <p0602040abc45bc499c04@[129.46.227.161]> In-Reply-To: <20040203204336.CF94F18DE@thrintun.hactrn.net> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> <p06020407bc45aed574bb@129.46.227.161> <20040203204336.CF94F18DE@thrintun.hactrn.net> Date: Tue, 3 Feb 2004 13:15:58 -0800 To: Rob Austein <sra+namedroppers@hactrn.net>, namedroppers@ops.ietf.org From: Ted Hardie <hardie@qualcomm.com> Subject: Re: Q-28 Clarification of the scope of the document set. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 3:43 PM -0500 02/03/2004, Rob Austein wrote: >At Tue, 3 Feb 2004 12:05:35 -0800, Ted Hardie wrote: >> >> I think I'm confused here. What do you think the role of the >> application would be? >> Are you thinking that on getting an error message back from the >>DNS, it might >> engage in some activity (like throwing an error in a popup or syslog)? Or >> are you thinking an application policy might actually cause it to accept >> bogus data? > >Given that only the application really knows what the application's >"security" requirements are, final decision on how to handle the bad >states pretty much has to be up to the application. All the nasty >stuff with the AD bit, etc, is just an attempt to extend -some- >protection to all the legacy DNS software that's already out there. Assuming there are four states, and using Mike's names for them, I would say it makes sense to return the data from Secure, Unsecure, and Indeterminate results to the application layer, along with a marker as to which of those states the data came. Over time, with deployment increases, we would hope that more and more of the data would transition to Secure and out of Indeterminate. But Bogus strikes me differently. Here I would say that a normal DNSSec-aware call from an app to the DNS should return no data, but should throw an error saying that the data returned failed the DNSSEC checks. There may need to be another routine needed to allow an application to set the "ravish-me" bits, to use one of our colleague's colorful phrases, but it seems to me that we should be reaching for a day in which an application wanting to bypass those checks should have to do so explicitly. I don't see a way to do that if we start out with the default being an app receiving known-to-be bogus data and being asked to deal. A compromise might be to say that the error thrown by Bogus data should contain the bad data. Anyone reading the data out of the error and using it has pretty much got to know they're garbage fishing. Note that in the long term, I would expect this to be not so much a DNS protocol issue, but an API issue between the apps and the DNS. regards, Ted >As I've mumbled before, sig validation is an end-to-end thing between >the DNS data producer (zone admin) and the DNS data consumer (app). > >And yeah, sure, an application might have a policy like "the admin of >this zone is known to be an incompetent bozo, and I'm doing a strong >authentication check with known keys at the app layer anyway, so I >don't care whether the DNSSEC sigs check out or not". Shouldn't be >the default policy, but you can bet that somebody's going to need to >implement something like it sooner or later for some application. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 17:17:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08428 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 17:17:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao8mB-0002W4-LO for namedroppers-data@psg.com; Tue, 03 Feb 2004 22:12:11 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao8le-0002SQ-CU for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 22:11:38 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id DF97056838; Tue, 3 Feb 2004 14:11:36 -0800 (PST) Message-Id: <6.0.1.1.2.20040203170743.027b7d98@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 03 Feb 2004 17:12:10 -0500 To: Ted Hardie <hardie@qualcomm.com>, Mike StJohns <Mike.StJohns@nominum.comc.cnri.reston.va.us> From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: namedroppers@ops.ietf.org In-Reply-To: <p06020407bc45aed574bb@[129.46.227.161]> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> <p06020407bc45aed574bb@[129.46.227.161]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:05 PM 2/3/2004, Ted Hardie wrote: >At 2:02 PM -0500 02/03/2004, Mike StJohns wrote: >>Bogus data - well.... ideally this would depend on what the application >>cares about, but in practice it will be whatever the policy is at the >>caching/recursive resolver. > >I think I'm confused here. What do you think the role of the application >would be? >Are you thinking that on getting an error message back from the DNS, it might >engage in some activity (like throwing an error in a popup or syslog)? Or >are you thinking an application policy might actually cause it to accept >bogus data? > regards, > Ted Hardie I'm thinking that I might not care what the DNS is saying if the certificate handed to me by the SSL connection I'm initiating is the right one. The application may want to do the connection (or some other application specific thing based on various records such as NAPTR, MX, etc) regardless of whether or not DNS says the data is correct, IF (and maybe IFF) it has another way of verifying identity. Later, Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 17:32:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09765 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 17:32:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao906-0004EJ-QF for namedroppers-data@psg.com; Tue, 03 Feb 2004 22:26:34 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao8zk-00049y-Fx for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 22:26:13 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id C027E56842; Tue, 3 Feb 2004 14:26:09 -0800 (PST) Message-Id: <6.0.1.1.2.20040203171233.02cb0ec0@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 03 Feb 2004 17:26:43 -0500 To: Matt Larson <mlarson@verisign.com> From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: bill <bmanning@karoshi.com>, Olaf Kolkman <olaf@ripe.net>, namedroppers@ops.ietf.org In-Reply-To: <20040203203836.GA18455@chinook.corppc.vrsn.com> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> <20040203203836.GA18455@chinook.corppc.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:38 PM 2/3/2004, Matt Larson wrote: >Mike, > >I think this is on the right track. A question and a comment: > >On Tue, 03 Feb 2004, Mike StJohns wrote: > > I think you're heading down the wrong direction here. There are > actually 4 > > states. And bogus is definitely a different state than indeterminate and > > can get handled quite differently by a resolver. > > > > > > 1) Secure. I have a trust anchor, a chain of trust and I'm able to verify > > the signatures on all the data. > > > > 2) Unsecure. I have a trust anchor, a chain of trust, and, at the > > delegation point I have a signed proof of the non-existence of the DS > > record which makes subsequent branches in the tree provably > > unsecure. Resolver policy could also declare a portion of the tree > > unsecure from a branch point. > >I'm assuming your "branch point" is a delegation point. Mostly yes. Because the semantics of DS as a secure delegation indication is supposedly tied to delegation NS records. Its possible that we may also want to consider the case where the zone is foo.com, *.foo.com are secure records, but *.unsecure.foo.com are not and there isn't any actual delegation (e.g. its all still part of the zone). I'm not sure it makes sense to consider this case, but that's really what I meant by branch point. I can't think of a case where I'd want to do this, but that doesn't mean someone won't come up with a good reason. > By your last >sentence, are you envisioning the ability to configure a resolver with >the notion thay, say, "Always treat foo.com and its descendants as >unsecure regardless of what security records you receive that might >state otherwise"? I can see this being a handy feature when a zone is >known to have something wrong DNSSEC-wise but one needs to communicate >with it anyway. Realistically these scenarios are going to occur. Right. You can know that foo.com is secure, either because you've got a trust anchor for .com and .com says foo.com is secure, or you've got a direct trust anchor for foo.com. You may want to override what .com says about foo.com by declaring the zone unsecure. If you don't have a trust anchor for either foo.com or for .com, the zone is indeterminate. Its *possible* that what you want to do in this case is collect the top level keys the first time you do a query and then report future inconsistencies. Not saying this is a good idea, but its something you could do with indeterminate zones. > > 3) Bogus. I have a trust anchor which is giving me an expectation that > > subsidiary data will be signed (e.g. foo.com trust anchor implies that > > bar.foo.com will be signed unless its explicitly unsecure as above), but > > the data I'm handed fails to validate due to one or more of: missing > > signatures, invalid signatures (both for expiration and for the sig > > algorithm verification), missing data where the NXT (or what ever we're > > call them) say there should be data, etc. > > > > 4) Indeterminate. I have no trust anchor which would indicate that a > > specific portion of the tree is secure. This is the default case. > > > > Indeterminate and unsecure data should be handled more or less identically > > - e.g. accepted at face value if the policy allows it. > >I'm having a hard time appreciating why anyone would ever care about >the distinction between unsecure and indeterminate. Or to put it >another way, what different action would be taken based on being in >one of these states vs. the other? Unless I'm missing something, one >only reaches an unsecure state by discovering a deliberate entry, >i.e., an administrator has to make an entry in a secure zone declaring >a child zone unsecure. So there's the subtle difference of "someone >went out of their way to say this is unsecure" vs. "I just don't know >its status". But my question is, is the difference too subtle to be >worth calling out with a fourth state? I think its worth it because I can see the possibility of a policy that says "accept only data that's subsidiary to known trust anchors" secure, bogus and unsecure data are all subsidiary to known trust anchors by definition. This basically says, don't accept data from those who don't play in the DNSSEC sand box. Again, I may be over generalizing here, but given the rather limited discussion of resolver policy I'd rather do this now than trip over it later. >Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 17:33:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09844 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 17:33:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao94A-0004sz-R9 for namedroppers-data@psg.com; Tue, 03 Feb 2004 22:30:46 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao93v-0004nZ-Hy for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 22:30:31 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 8AEDB5684D; Tue, 3 Feb 2004 14:30:29 -0800 (PST) Message-Id: <6.0.1.1.2.20040203172754.0262dc00@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 03 Feb 2004 17:31:02 -0500 To: bill <bmanning@karoshi.com> From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: bmanning@karoshi.com (bill), olaf@ripe.net (Olaf Kolkman), namedroppers@ops.ietf.org In-Reply-To: <200402031915.i13JFB913059@karoshi.com> References: <6.0.1.1.2.20040203135043.0284cc28@localhost> <200402031915.i13JFB913059@karoshi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 02:15 PM 2/3/2004, bill wrote: > perhaps, but it may just be a desire to keep things "simple". > for now, lets presume your four states. What else is a distingishing > characteristic? I see these. > > the bogus lable is primarily driven by temporal events, e.g. > routing anomolies, head space/timing syncronization, clocking errors, Attacks. > etc. > > secure/unsecure presume routing stability, accurate clocks and > alert/aware operators. No - presume validatable signed data in the DNS that link back to known trust anchors. > indeterminant is todays status quo. > > or do I have this wrong also? No - I think you've got it mostly right, but see the above. The problem is one of relativity. All of these need to be relative to the querying entity. Its the one making the good-secure/good-unsecure/bad-bogus/indeterminate decision and then it needs to decide what to do with what it knows. >--bill > > > > > I think you're heading down the wrong direction here. There are > actually 4 > > states. And bogus is definitely a different state than indeterminate and > > can get handled quite differently by a resolver. > > > > > > 1) Secure. I have a trust anchor, a chain of trust and I'm able to verify > > the signatures on all the data. > > > > 2) Unsecure. I have a trust anchor, a chain of trust, and, at the > > delegation point I have a signed proof of the non-existence of the DS > > record which makes subsequent branches in the tree provably > > unsecure. Resolver policy could also declare a portion of the tree > > unsecure from a branch point. > > > > 3) Bogus. I have a trust anchor which is giving me an expectation that > > subsidiary data will be signed (e.g. foo.com trust anchor implies that > > bar.foo.com will be signed unless its explicitly unsecure as above), but > > the data I'm handed fails to validate due to one or more of: missing > > signatures, invalid signatures (both for expiration and for the sig > > algorithm verification), missing data where the NXT (or what ever we're > > call them) say there should be data, etc. > > > > 4) Indeterminate. I have no trust anchor which would indicate that a > > specific portion of the tree is secure. This is the default case. > > > > Indeterminate and unsecure data should be handled more or less identically > > - e.g. accepted at face value if the policy allows it. Secure data > should > > generally be accepted. Bogus data - well.... ideally this would depend on > > what the application cares about, but in practice it will be whatever the > > policy is at the caching/recursive resolver. > > > > > > At 01:32 PM 2/3/2004, bill wrote: > > > > > changes sprinkled throughout, mainly changing "bogus" to > > > "indeterminant", > > > > > > > > > > In the DNSSEC architecture the security aware resolver determines if > > > > DNS deta is in one of three states "unsecure", "validated" or > > > > "bogus". The specification in these document set is designed to make > > > > sure these 3 states can unambiguously be determined from the answers > > > > that are returned from security aware servers. > > > > > > I'm unconvinced that the resolver makes this choice. > > > a design we are working on/with has the validator as > > > an independent module that the resolver talks to and > > > it is the validator that determines the "state of the data" > > > and tells the resolver. So, alternate text: > > > > > > In the DNSSEC architecture a security enabled resolver receives data > > > in one of three states, "unsecure", "validated", or "indeterminant". > > > The specification in this document set is designed to make sure these > > > three states can unambigiously be determined from answers received > > > from security aware and enabled servers or caches. > > > > > > > Validated: Data is "validated" if one of possibly multiple > > > > authentication chains from a trust anchor to the data itself > > > > can be established. Multiple authentication chains can exist > > > > when there are multiple DS RRs at a delegation point or when > > > > data is covered by multiple RRSIGs. A security aware resolver > > > > may not have all possible authorization chains at its > > > > disposal, either because an authorization chain is based on an > > > > algorithm that has not been implemented or because there is no > > > > trust anchor for a possible authenticatio chain available. > > > > > > > > > > > > Unsecure: If no authentication chain can be established; either > > > > because there is no appropriate trust anchor or the > > > > authentication chain was broken because of the authenticated > > > > absence of DS RRs that point to keys of algorithms the > > > > resolver is able to use. > > > > > > > > If there are no trust anchors configured than all data is > > > > marked insecure. > > > > > > > > > > >Indeterminant: Data that is neither validated nor unsecure: Somewhere > in the > > > authentication chain, at the time when authentication was > > > tried, there > > > was an RRset for which all of the RRSIG RRs did not > > > cryptographically i > > > verify or were intended for a different time interval. > > > Alternatively not > > > all needed links in the authorization chain were available e.g. > > > because > > > network failures. > > > > > > Recovery or Retry, in an attempt to reach a validated state are > > > out side the scope of this definition. > > > > > > > Once security aware resolvers have determined if data is 'secure', > > > 'insecure' or 'indeterminant' their work is done. This specification > > > does not > > > > define a format for communicating why data was found to be bogus or > > > > insecure. For the communication between a security aware recursive > > > > servers and security aware stub resolvers this specification defines a > > > > default policy for communicating the 3 states. The detailed > > > > specification of a method for signaling advanced error codes and or > > > > policy between a security aware stub resolver and security aware > > > > recursive nameservers is subject to future work. > > > > > > > > </proposed intro text> > > > > > > > > > > > If the security aware recursive nameserver validates data as > "indeterminant" > > > > it returns an answer with RCODE=SERVFAIL > > > > > > > > > > > > -- > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > > > the word 'unsubscribe' in a single line as the message text body. > > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > > > > > >-- > > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > >the word 'unsubscribe' in a single line as the message text body. > > >archive: <http://ops.ietf.org/lists/namedroppers/> > > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 3 18:46:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13495 for <dnsext-archive@lists.ietf.org>; Tue, 3 Feb 2004 18:46:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AoA8K-000Bcc-Bi for namedroppers-data@psg.com; Tue, 03 Feb 2004 23:39:08 +0000 Received: from [129.46.51.59] (helo=ithilien.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AoA6R-000BTK-FV for namedroppers@ops.ietf.org; Tue, 03 Feb 2004 23:37:11 +0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13Nb7vf019848; Tue, 3 Feb 2004 15:37:07 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i13Nb4o5029932; Tue, 3 Feb 2004 15:37:05 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: <p0602040fbc45dea5a962@[129.46.227.161]> In-Reply-To: <6.0.1.1.2.20040203170743.027b7d98@localhost> References: <E6C90792-5649-11D8-A219-000393DA2D46@ripe.net> <200402031832.i13IWGG12658@karoshi.com> <6.0.1.1.2.20040203135043.0284cc28@localhost> <p06020407bc45aed574bb@[129.46.227.161]> <6.0.1.1.2.20040203170743.027b7d98@localhost> Date: Tue, 3 Feb 2004 15:37:04 -0800 To: Mike StJohns <Mike.StJohns@nominum.com> From: Ted Hardie <hardie@qualcomm.com> Subject: Re: Q-28 Clarification of the scope of the document set. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:12 PM -0500 02/03/2004, Mike StJohns wrote: >At 03:05 PM 2/3/2004, Ted Hardie wrote: >>At 2:02 PM -0500 02/03/2004, Mike StJohns wrote: >>>Bogus data - well.... ideally this would depend on what the >>>application cares about, but in practice it will be whatever the >>>policy is at the caching/recursive resolver. >> >>I think I'm confused here. What do you think the role of the >>application would be? >>Are you thinking that on getting an error message back from the DNS, it might >>engage in some activity (like throwing an error in a popup or syslog)? Or >>are you thinking an application policy might actually cause it to accept >>bogus data? >> regards, >> Ted Hardie > >I'm thinking that I might not care what the DNS is saying if the >certificate handed to me by the SSL connection I'm initiating is the >right one. > >The application may want to do the connection (or some other >application specific thing based on various records such as NAPTR, >MX, etc) regardless of whether or not DNS says the data is correct, >IF (and maybe IFF) it has another way of verifying identity. The problem here is that the actions are serial. If I get Bogus data from the DNS and attempt a connection, I have given away some information about myself that may be going to an attacker. Even if my later check of the TLS cert prevents me from shoving my credit card number at the attacker, I'm still down on the game. I agree that there will be some conditions where an application needs to try a connection despite a DNSSEC result of Bogus data, but, as I said in my message to Rob, I think the app needs to work at it a bit. From an API perspective I think getting the result BOGUS_DATA to my "dnssec_dig AAAA goodguy.example.com" query is the right answer, even if I can go on to a "dnssec_dig -ravishme AAAA goodguy.example.com" to get the data anyway. Again, I think this is long term an API issue, not a protocol issue, but I want to make the point that at least one APPs guy would like to see Bogus data as an error to the APP unless the APP has specifically allowed it. Just my opinion, of course, regards, Ted Hardie is the r -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 09:07:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19032 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 09:07:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqYSd-00041e-U7 for namedroppers-data@psg.com; Tue, 10 Feb 2004 14:01:59 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqYSc-0003vd-ES for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 14:01:58 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1AE1NjO012836 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 09:01:23 -0500 (EST) Message-ID: <00f301c3efde$61b20260$b9370681@barnacle> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: trying to close Editor's Question Q-29 Date: Tue, 10 Feb 2004 09:01:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q-29 Resolver handling of expired RRSIGs So far, there doesn't seem to be a solid consensus on the following wording: > > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > checks were successful, depending on local policy". > > To replace the current text that states resolvers MUST reject out of date signatures. There is no time limit in the original question post, but the editors would like to see some resolution before the I-D cutoff date. Personally, I'd like it to be Fri. 13th if possible Please post your opinion if you haven't already. Or if you have further comments on the text, or substitute text. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 09:21:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19447 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 09:21:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqYiC-0006Ok-2h for namedroppers-data@psg.com; Tue, 10 Feb 2004 14:18:04 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqYi2-0006NN-TA for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 14:17:55 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AEHowQ000193 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 15:17:51 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AEIZek009313 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 15:18:35 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1AEIZoG009312 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:18:35 +0100 Date: Tue, 10 Feb 2004 15:18:35 +0100 From: Miek Gieben <miekg@atoom.net> To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 Message-ID: <20040210141835.GA9257@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <00f301c3efde$61b20260$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00f301c3efde$61b20260$b9370681@barnacle> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 10 Feb, @15:01, Scott wrote in "trying to close Editor's Quest ..."] > Q-29 Resolver handling of expired RRSIGs > > So far, there doesn't seem to be a solid consensus on the following wording: > > > > > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > > checks were successful, depending on local policy". > > > > > Please post your opinion if you haven't already. Or if you have further > comments on the text, or substitute text. I support the above text. A 'MUST' is way to strong. If one says MUST on this timing issue, what's next: MUST run ntp, MUST NOT fiddle with the local time? regards, Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 09:42:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20191 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 09:42:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZ2H-0009uI-E4 for namedroppers-data@psg.com; Tue, 10 Feb 2004 14:38:49 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZ2G-0009u6-ET for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 14:38:48 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AEcXwQ000374; Tue, 10 Feb 2004 15:38:34 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AEdIRm009781; Tue, 10 Feb 2004 15:39:18 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AEdHov009778; Tue, 10 Feb 2004 15:39:18 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 10 Feb 2004 15:39:17 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Scott Rose <scottr@nist.gov> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <00f301c3efde$61b20260$b9370681@barnacle> Message-ID: <Pine.LNX.4.58.0402101523510.9168@elektron.atoom.net> References: <00f301c3efde$61b20260$b9370681@barnacle> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 10 Feb 2004, Scott Rose wrote: > Q-29 Resolver handling of expired RRSIGs > > So far, there doesn't seem to be a solid consensus on the following wording: > > > > > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > > checks were successful, depending on local policy". > > > > > To replace the current text that states resolvers MUST reject out of date > signatures. There is no time limit in the original question post, but the > editors would like to see some resolution before the I-D cutoff date. > Personally, I'd like it to be Fri. 13th if possible > > Please post your opinion if you haven't already. Or if you have further > comments on the text, or substitute text. The issuer of the signature (signer) put a 'Only Use After/Before' stamp on the data.. The signer obviously wants the validator to consider the signature and data as valid within the specified time. That implicates that the signer wants an expired signature to be bogus (nee unsigned). I want validation to BREAK when it is way passed/before the expire/inception time. I really don't want users of my data, whereever they are, whatever the usage is, be replayed with expired signatures of a stolen key. If this is going to be degraded to SHOULD, the system is less secure. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 09:54:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20479 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 09:54:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZEB-000CRg-4X for namedroppers-data@psg.com; Tue, 10 Feb 2004 14:51:07 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZEA-000CRR-2d for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 14:51:06 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AEorwQ000644 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 15:50:53 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AEpcAC010045 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 15:51:38 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1AEpcKG010044 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:51:38 +0100 Date: Tue, 10 Feb 2004 15:51:38 +0100 From: Miek Gieben <miekg@atoom.net> To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 Message-ID: <20040210145138.GA10020@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <00f301c3efde$61b20260$b9370681@barnacle> <Pine.LNX.4.58.0402101523510.9168@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <Pine.LNX.4.58.0402101523510.9168@elektron.atoom.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 10 Feb, @15:39, roy wrote in "Re: trying to close Editor's Q ..."] > I want validation to BREAK when it is way passed/before the ^^^^^ making the issue local policy IMHO... grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:09:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21512 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:09:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZRl-000FRu-1O for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:05:09 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZRj-000FRU-8T for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:05:07 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1AF55HP006932 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 15:05:06 GMT To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: Message from Miek Gieben <miekg@atoom.net> of "Tue, 10 Feb 2004 15:18:35 +0100." <20040210141835.GA9257@atoom.net> Date: Tue, 10 Feb 2004 15:05:05 +0000 Message-ID: <6931.1076425505@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Miek" == Miek Gieben <miekg@atoom.net> writes: >> "SHOULD be rejected, but MAY use RRSIGs if other security >> checks were successful, depending on local policy. Miek> I support the above text. A 'MUST' is way to strong. If one Miek> says MUST on this timing issue, what's next: MUST run ntp, Miek> MUST NOT fiddle with the local time? I reluctantly support the text, but not Miek's justification for it. Correct synchronisation is vital for DNSSEC so saying the clocks MUST be aligned is not unreasonable. How that gets done is out of scope. The DNSSEC protocol shouldn't need to know or care how that synchronisation happens and so shouldn't say anything about that. However I worry that by only saying "SHOULD be rejected" for expired RRSIGs, this WG could be shooting itsefl in the foot again. The text seems to be saying that if DNSSEC validation fails but some other security check (like what?) works, it can be OK to use an answer that the resolver knows didn't validate properly. Or isn't valid any more. If that's really the case, why bother deploying DNSSEC or keeping keys and signatures up to date? After all some other unspecified security check can be used instead. And how can these hypothetical security checks be made to interwork? Do I tell my resolver to accept something on the say-so of Miek's server even though his server was unable to do DNSSEC validation of that data? How about the text below? .... SHOULD be rejected, but MAY use RRSIGs. In certain circumstances local policy MAY consider this to be acceptable behaviour, for example if other security checks on the data have been successful. The consequences of such a policy need to be carefully assessed. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:17:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22356 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:17:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZaR-000H1V-TK for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:14:07 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZaK-000GwF-AR for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:14:00 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1AFDtHP006974; Tue, 10 Feb 2004 15:13:55 GMT To: roy@dnss.ec cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: Message from roy@dnss.ec of "Tue, 10 Feb 2004 15:39:17 +0100." <Pine.LNX.4.58.0402101523510.9168@elektron.atoom.net> Date: Tue, 10 Feb 2004 15:13:55 +0000 Message-ID: <6973.1076426035@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "roy" == roy <roy@dnss.ec> writes: roy> I want validation to BREAK when it is way passed/before the roy> expire/inception time. I really don't want users of my data, roy> whereever they are, whatever the usage is, be replayed with roy> expired signatures of a stolen key. roy> If this is going to be degraded to SHOULD, the system is less roy> secure. I agree with this in principle. However there may be cases where data that doesn't validate might need to be used to bootstrap the validation process. Suppose your key gets compromised. You withdraw it immediately and re-sign your zone with a new key. So far, so good. Now my server is caching a SIG for your zone's NS RRset generated with the old key. Should my server query those NS records to try and get your new key or wait for them to expire from my cache? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:21:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22627 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:21:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZf4-000Hyb-M5 for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:18:54 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZf3-000HyC-HZ for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:18:53 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AFIewQ002015; Tue, 10 Feb 2004 16:18:40 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.10/8.12.10/Submit) id i1AFIeCe002014; Tue, 10 Feb 2004 16:18:40 +0100 (CET) (envelope-from ted) Message-Id: <200402101518.i1AFIeCe002014@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Tue, 10 Feb 2004 16:18:40 +0100 In-Reply-To: "Miek Gieben's message as of Feb 10, 16:01" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Miek Gieben <miekg@atoom.net>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Miek Gieben, on Feb 10, 16:01, in "Re: trying to close ..."] > [On 10 Feb, @15:39, roy wrote in "Re: trying to close Editor's Q ..."] > > I want validation to BREAK when it is way passed/before the > ^^^^^ > making the issue local policy IMHO... No, that is the local policy at the validator-side, Roy was talking about what he wants from the signers perspective. While I agree with Roy on "way passed/before" time difference, I also agree with the people at the workshop that argued that some slack is needed to cope with small clock variations and/or network delays. Perhaps we can settle this dispute with an addition like: > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > > checks were successful, depending on local policy, to cope with small clock variations or network delays". -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:23:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22715 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:23:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZgW-000IBv-Eb for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:20:24 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZgP-000IAs-33 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:20:17 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AFK6wQ002039 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 16:20:06 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AFKp6Q010563 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 16:20:51 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1AFKpNV010562 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 16:20:51 +0100 Date: Tue, 10 Feb 2004 16:20:51 +0100 From: Miek Gieben <miekg@atoom.net> To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 Message-ID: <20040210152051.GA10087@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <20040210141835.GA9257@atoom.net> <6931.1076425505@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6931.1076425505@gromit.rfc1035.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 10 Feb, @16:05, Jim wrote in "Re: trying to close Editor's Q ..."] > unspecified security check can be used instead. And how can these > hypothetical security checks be made to interwork? Do I tell my > resolver to accept something on the say-so of Miek's server even > though his server was unable to do DNSSEC validation of that data? If I were to browse the web and my resolver would tell my browser: "this data is bad, because the SIG expired 10 minutes ago" (suppose it can tell that to my browser), it would be pretty neat if I could still check out the (faked) website on the Internet. Or not? > How about the text below? > .... SHOULD be rejected, but MAY use RRSIGs. In certain > circumstances local policy MAY consider this to be > acceptable behaviour, for example if other security checks on > the data have been successful. The consequences of such a > policy need to be carefully assessed. anything without the MUST has my support, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:35:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23205 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:35:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZr8-000Kmq-Uj for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:31:22 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZqy-000Km4-65 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:31:12 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AFUswQ002469; Tue, 10 Feb 2004 16:30:54 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AFVdEE010846; Tue, 10 Feb 2004 16:31:39 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AFVdaL010843; Tue, 10 Feb 2004 16:31:39 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 10 Feb 2004 16:31:39 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Jim Reid <jim@rfc1035.com> cc: roy@dnss.ec, Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <6973.1076426035@gromit.rfc1035.com> Message-ID: <Pine.LNX.4.58.0402101616340.9168@elektron.atoom.net> References: <6973.1076426035@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 10 Feb 2004, Jim Reid wrote: > >>>>> "roy" == roy <roy@dnss.ec> writes: > > roy> I want validation to BREAK when it is way passed/before the > roy> expire/inception time. I really don't want users of my data, > roy> whereever they are, whatever the usage is, be replayed with > roy> expired signatures of a stolen key. > > roy> If this is going to be degraded to SHOULD, the system is less > roy> secure. > > I agree with this in principle. Okay. > However there may be cases where data that doesn't validate might need > to be used to bootstrap the validation process. OOB is the only way. > Suppose your key gets compromised. The whole system breaks at this point. > You withdraw it immediately and re-sign your zone with a new key. So > far, so good. Now my server is caching a SIG for your zone's NS RRset > generated with the old key. Should my server query those NS records to > try and get your new key or wait for them to expire from my cache? Wait for the expire time. Until then, all bets are off. There is no short-cut-local-uptimisation here. If your key is stolen by ScriptKiddy, he'll generate new keys/sigs and update caches for you. The only way caches are protected against replay is current time check. It is part of the crypto-layer. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 10:43:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23587 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 10:43:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqZyz-000MUW-QK for namedroppers-data@psg.com; Tue, 10 Feb 2004 15:39:29 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqZyo-000MT8-VU for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 15:39:19 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AFd2wQ002663; Tue, 10 Feb 2004 16:39:04 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AFdmZB011005; Tue, 10 Feb 2004 16:39:48 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AFdmYI011002; Tue, 10 Feb 2004 16:39:48 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 10 Feb 2004 16:39:48 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ted Lindgreen <ted@NLnetLabs.nl> cc: Miek Gieben <miekg@atoom.net>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <200402101518.i1AFIeCe002014@open.nlnetlabs.nl> Message-ID: <Pine.LNX.4.58.0402101634020.9168@elektron.atoom.net> References: <200402101518.i1AFIeCe002014@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 10 Feb 2004, Ted Lindgreen wrote: > [Quoting Miek Gieben, on Feb 10, 16:01, in "Re: trying to close ..."] > > [On 10 Feb, @15:39, roy wrote in "Re: trying to close Editor's Q ..."] > > > I want validation to BREAK when it is way passed/before the > > ^^^^^ > > making the issue local policy IMHO... > > No, that is the local policy at the validator-side, Roy was talking > about what he wants from the signers perspective. Exactly. > While I agree with Roy on "way passed/before" time difference, I > also agree with the people at the workshop that argued that some > slack is needed to cope with small clock variations and/or > network delays. The delay/variation problem can be solved with overlapping keys/signatures. KEY1 : day 5 ... day 10 KEY2 : day 9 ... day 20 This way, there is a one day slack either way. This is the reason that there is no 'fudge' in the RRSIG record, like the TSIG record has. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 13:18:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00953 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 13:17:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqcOr-0001Aw-Pu for namedroppers-data@psg.com; Tue, 10 Feb 2004 18:14:21 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqcOl-0001A0-PC for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 18:14:15 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AIEBwQ003674 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:14:11 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AIEvUu013243 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:14:57 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AIEve5013240 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:14:57 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 10 Feb 2004 19:14:57 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: Re: Fingerprinting DNS implementations. In-Reply-To: <Pine.LNX.4.58.0312092248380.4290@elektron.atoom.net> Message-ID: <Pine.LNX.4.58.0402101914190.9168@elektron.atoom.net> References: <Pine.LNX.4.58.0312092248380.4290@elektron.atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 9 Dec 2003, Roy Arends wrote: > Hi, > > Jakob and I spent the past few weeks hacking up a DNS implementation > fingerprint tool (where implementation == anything responding to a query). > This mail introduces the methodology of fingerprinting DNS > implementations. Tool is available at http://www.rfc.se/fpdns Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 14:03:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00952 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 13:17:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqcMl-0000nH-4q for namedroppers-data@psg.com; Tue, 10 Feb 2004 18:12:11 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqcMh-0000my-07 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 18:12:07 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1AIBjwQ003664 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:11:47 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AICWeY013183 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:12:32 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1AICUnZ013180 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 19:12:31 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 10 Feb 2004 19:12:30 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: Re: Fingerprinting DNS implementations. In-Reply-To: <Pine.LNX.4.58.0312092248380.4290@elektron.atoom.net> Message-ID: <Pine.LNX.4.58.0402101911340.9168@elektron.atoom.net> References: <Pine.LNX.4.58.0312092248380.4290@elektron.atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 9 Dec 2003, Roy Arends wrote: > Hi, > > Jakob and I spent the past few weeks hacking up a DNS implementation > fingerprint tool (where implementation == anything responding to a query). > This mail introduces the methodology of fingerprinting DNS > implementations. Tool is available at http://www.rfc.se/fpdns Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 14:09:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03295 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 14:09:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqdDO-000A5B-8l for namedroppers-data@psg.com; Tue, 10 Feb 2004 19:06:34 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqdDL-000A4c-1f for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 19:06:31 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1AJ5tjO024464 for <namedroppers@ops.ietf.org>; Tue, 10 Feb 2004 14:05:55 -0500 (EST) Message-ID: <007001c3f008$d515dbd0$b9370681@campus.nist.gov> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <D6EDDF48-5194-11D8-AF3C-000393DA2D46@ripe.net> Subject: Re: Q-24 DNSKEY with flag 7=0 not to be used with DNSSEC. Date: Tue, 10 Feb 2004 14:05:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am not sure we need this text added. Later in the text, when discussing the authentication proceedure for data, it clearly states that any DNSKEY used to verify RRSIGs must have its zone bit flag set to one. We can add it again to section 2.1, but that statement is already made where it counts in the section dealing with response authentication. Scott ----- Original Message ----- From: "Olaf Kolkman" <olaf@ripe.net> > > The behavior for the flag bit (bit7) in the DNSKEY RR set to 0 is not > specified. We propose the following text to be added to section 2.1: > DNSKEY RRs MUST NOT be used for DNSSEC validation if bit 7 of the flag > field is set to 0. > > > --Olaf > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 18:48:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00600 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 18:48:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqhWq-000ONd-Hf for namedroppers-data@psg.com; Tue, 10 Feb 2004 23:42:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.psg.com with smtp (Exim 4.30; FreeBSD) id 1AqhWj-000OMq-5L for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 23:42:49 +0000 Received: (qmail 30649 invoked from network); 10 Feb 2004 23:58:25 -0000 Received: from h219-110-033-104.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.104) by necom830.hpcl.titech.ac.jp with SMTP; 10 Feb 2004 23:58:25 -0000 Message-ID: <40296CDC.1060107@necom830.hpcl.titech.ac.jp> Date: Wed, 11 Feb 2004 08:44:28 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Scott Rose <scottr@nist.gov> CC: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 References: <00f301c3efde$61b20260$b9370681@barnacle> In-Reply-To: <00f301c3efde$61b20260$b9370681@barnacle> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose wrote: > Q-29 Resolver handling of expired RRSIGs > > So far, there doesn't seem to be a solid consensus on the following wording: > > >>>"SHOULD be rejected, but MAY use RRSIGs if other security >>>checks were successful, depending on local policy". It effectively means that DNSSEC is unnecessary. So edit rest of the draft to make it empty. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 18:48:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00627 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 18:48:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqhZ8-000P8V-8i for namedroppers-data@psg.com; Tue, 10 Feb 2004 23:45:18 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqhZ7-000P7v-51 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 23:45:17 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1ANj1HP007696; Tue, 10 Feb 2004 23:45:03 GMT To: ted@NLnetLabs.nl (Ted Lindgreen) cc: Miek Gieben <miekg@atoom.net>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: Message from ted@NLnetLabs.nl (Ted Lindgreen) of "Tue, 10 Feb 2004 16:18:40 +0100." <200402101518.i1AFIeCe002014@open.nlnetlabs.nl> Date: Tue, 10 Feb 2004 23:45:01 +0000 Message-ID: <7695.1076456701@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ted" == Ted Lindgreen <ted@NLnetLabs.nl> writes: Ted> While I agree with Roy on "way passed/before" time Ted> difference, I also agree with the people at the workshop that Ted> argued that some slack is needed to cope with small clock Ted> variations and/or network delays. Ted> Perhaps we can settle this dispute with an addition like: >> > "SHOULD be rejected, but MAY use RRSIGs if other security >> > checks were successful, depending on local policy, to >> > cope with small clock variations or network delays". I think a definition of "small" will be needed. How about using the same fudge factor TSIG allows for skewed clocks? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 10 18:50:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00751 for <dnsext-archive@lists.ietf.org>; Tue, 10 Feb 2004 18:50:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqhc1-000PRv-MO for namedroppers-data@psg.com; Tue, 10 Feb 2004 23:48:17 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqhbz-000PRc-D1 for namedroppers@ops.ietf.org; Tue, 10 Feb 2004 23:48:15 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1ANm8HP007707; Tue, 10 Feb 2004 23:48:09 GMT To: roy@dnss.ec cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: Message from roy@dnss.ec of "Tue, 10 Feb 2004 16:31:39 +0100." <Pine.LNX.4.58.0402101616340.9168@elektron.atoom.net> Date: Tue, 10 Feb 2004 23:48:08 +0000 Message-ID: <7706.1076456888@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "roy" == roy <roy@dnss.ec> writes: >> However there may be cases where data that doesn't validate >> might need to be used to bootstrap the validation process. roy> OOB is the only way. Indeed. And that's what the original text was hinting at when it spoke about "other security checks". roy> The only way caches are protected against replay is current roy> time check. It is part of the crypto-layer. In that case, a MUST is needed, not a SHOULD. Oh how I *hate* DNSSEC... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 03:16:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21516 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 03:16:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqpSY-0009gc-Sy for namedroppers-data@psg.com; Wed, 11 Feb 2004 08:11:02 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqpSX-0009gQ-Rr for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 08:11:01 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i1B88f9L016814 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 03:08:41 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4yaGSG; Wed, 11 Feb 04 03:08:07 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i1B6YwkW004890 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 01:34:59 -0500 (EST) Date: Wed, 11 Feb 2004 01:34:58 -0500 (EST) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <7706.1076456888@gromit.rfc1035.com> Message-ID: <Pine.GSO.4.55.0402110127350.4412@filbert> References: <7706.1076456888@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Repeating what I said when I started this discussion on 15 January: I think SHOULD is perfectly correct. Scott suggests: > > "SHOULD be rejected, but MAY use RRSIGs if other security > > checks were successful, depending on local policy". Using the language of Q-28 (which may change slightly), I think five words are sufficient: "SHOULD be treated as bogus." The MAY is implicit. > roy> The only way caches are protected against replay is current > roy> time check. It is part of the crypto-layer. > Jim> In that case, a MUST is needed, not a SHOULD. Disagree. This is a 2119 "SHOULD" -- ignore at your own peril and only after due consideration (Really. We mean it.), but you're not hurting anyone other than yourself. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 04:01:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23153 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 04:01:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqqDR-000Ins-Vf for namedroppers-data@psg.com; Wed, 11 Feb 2004 08:59:29 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqqDG-000Ilo-Qd for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 08:59:18 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1B8wwwQ008720; Wed, 11 Feb 2004 09:58:59 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1B8xnwp023302; Wed, 11 Feb 2004 09:59:49 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1B8xmrm023299; Wed, 11 Feb 2004 09:59:49 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 11 Feb 2004 09:59:48 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Samuel Weiler <weiler@tislabs.com> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <Pine.GSO.4.55.0402110127350.4412@filbert> Message-ID: <Pine.LNX.4.58.0402110927050.22586@elektron.atoom.net> References: <7706.1076456888@gromit.rfc1035.com> <Pine.GSO.4.55.0402110127350.4412@filbert> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.4 required=5.0 tests=NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 11 Feb 2004, Samuel Weiler wrote: > Repeating what I said when I started this discussion on 15 January: Repetitive statements does not make your argument more true. > I think SHOULD is perfectly correct. You were wrong then, you are wrong now. You wrote: "To accomodate local policy, I think these should be SHOULD NOTs." in your january 15th mail. You are using "local policy" as magic paint to ram your view of the robustness principle into a validator. ANY policy that allows treating expired signatures as valid is BAD policy. The validator validates, checking the time stamp is part of the validation. It's as old at 2065 (6.4 Secure Time). Its in 2535 (6.4 Secure Time). Why change it now ? > Scott suggests: > > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > > checks were successful, depending on local policy". > > Using the language of Q-28 (which may change slightly), I think five > words are sufficient: "SHOULD be treated as bogus." The MAY is > implicit. Repetitive statement. Repetitive statement. > > roy> The only way caches are protected against replay is current > > roy> time check. It is part of the crypto-layer. > > > Jim> In that case, a MUST is needed, not a SHOULD. > > Disagree. This is a 2119 "SHOULD" -- ignore at your own peril and > only after due consideration (Really. We mean it.), but you're not > hurting anyone other than yourself. The exact meaning of MUST applies perfectly: MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. This is an absolute requirement. A dealbreaker. Protecting against replay. If this is a SHOULD the system is less secure. I can sign data with a Very Large Key and a Very Short Validity Period. If some implementation has a switch that allows end users to TRUST MY DATA while MY DATA IS BOGUS due to expiration, then that switch is illegal. If that switch is legal, all bets are off. Change local time as a workaround to have a system validate old signatures. Don't hack the spec to allow for this. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 04:30:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24007 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 04:29:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqqbm-000MwD-D8 for namedroppers-data@psg.com; Wed, 11 Feb 2004 09:24:38 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqqbb-000MvF-IL for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 09:24:27 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1B9O8wQ009019 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 10:24:08 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.10/8.12.10/Submit) id i1B9O8ub009018 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 10:24:08 +0100 (CET) (envelope-from ted) Message-Id: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 11 Feb 2004 10:24:08 +0100 In-Reply-To: "Jim Reid's message as of Feb 11, 0:45" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Jim Reid, on Feb 11, 0:45, in "Re: trying to close ..."] > >>>>> "Ted" == Ted Lindgreen <ted@NLnetLabs.nl> writes: > > Ted> While I agree with Roy on "way passed/before" time > Ted> difference, I also agree with the people at the workshop that > Ted> argued that some slack is needed to cope with small clock > Ted> variations and/or network delays. > > Ted> Perhaps we can settle this dispute with an addition like: > > >> > "SHOULD be rejected, but MAY use RRSIGs if other security > >> > checks were successful, depending on local policy, to > >> > cope with small clock variations or network delays". > > I think a definition of "small" will be needed. How about using the same > fudge factor TSIG allows for skewed clocks? Roy pointed out that there is no need for fudge, as (other than with TSIG) one can (and should) use overlapping periods. Therefore, I take back my comment and proposal above. It is clear that outside the validity periods a SIG is meant to be not valid. This is what the zone-administrator wanted and configured. Remains the question of wording what to do with such a SIG in the sense of RFC 2119. Reading RFC 2119 again, I think that what Sam wrote: [Quoting Samuel Weiler, on Feb 11, 9:19, in "Re: trying to close ..."] ..... > Repeating what I said when I started this discussion on 15 January: > > I think SHOULD is perfectly correct. is 100% correct. (Please read RFC 2119 first if you disagree). And I support Sam's suggestion that: "SHOULD be treated as bogus" is sufficient. IMHO: Adding anything else is unnecessary (it's already in RFC 2119) and only asking for trouble and endless discussions. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 05:28:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25833 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 05:28:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqrXU-0007QO-7o for namedroppers-data@psg.com; Wed, 11 Feb 2004 10:24:16 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqrXS-0007PJ-Th for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 10:24:15 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1BAO9HP008885; Wed, 11 Feb 2004 10:24:10 GMT To: ted@NLnetLabs.nl (Ted Lindgreen) cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: Message from ted@NLnetLabs.nl (Ted Lindgreen) of "Wed, 11 Feb 2004 10:24:08 +0100." <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> Date: Wed, 11 Feb 2004 10:24:09 +0000 Message-ID: <8884.1076495049@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ted" == Ted Lindgreen <ted@NLnetLabs.nl> writes: >> > checks were successful, depending on local policy, to >> > cope with small clock variations or network delays". >> >> I think a definition of "small" will be needed. How about using >> the same fudge factor TSIG allows for skewed clocks? Ted> Roy pointed out that there is no need for fudge, as (other Ted> than with TSIG) one can (and should) use overlapping periods. Ted> Therefore, I take back my comment and proposal above. I take back mine too. Thanks for helping to stop the discussion doing down that particular rathole. Ted> It is clear that outside the validity periods a SIG is meant Ted> to be not valid. This is what the zone-administrator wanted Ted> and configured. Indeed. I overlooked this basic truth. Ted> And I support Sam's suggestion that: "SHOULD be treated as Ted> bogus" is sufficient. This can't be right. Roy's given good technical reasons for that. And using a SHOULD makes validation optional. Logically, this is very bad as it provides a get-out. To repeat my earlier question, why bother with DNSSEC validation if failures can be disregarded and substituted by other (unspecified) security checks? It is beyond credibility that this WG could toil over DNSSEC for 7? 8? years now and come up with a spec with a gaping hole that's so big someone could drive a fleet of trucks through it. If the draft leaves enough wiggle room to make validation optional, why bother validating or signing anything? Suppose Microsoft (say) use this loophole to avoid implementing validation. [Remember they're good at finding ways to wiggle out of supporting useful stuff that isn't mandatory to implement.] After all their desktops would be free to use some other security check: that's what the spec currently says. This would mean 90-something% of the internet will not get any benefit from DNSSEC and that's a *massive* disincentive for deploying it. Speaking as a DNS administrator, there's no way I'd go through the pain of signing my zones or doing key rollover if nobody's going to be compelled to validate them. Ted> IMHO: Adding anything else is unnecessary (it's already in Ted> RFC 2119) and only asking for trouble and endless Ted> discussions. Isn't asking for trouble and endless discussions what DNSSEC is all about? :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 06:26:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27302 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 06:26:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqsT2-000IRf-Hs for namedroppers-data@psg.com; Wed, 11 Feb 2004 11:23:44 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqsT1-000IRP-Dq for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 11:23:43 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BBNOwQ010474 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 12:23:24 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BBOGNQ025402 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 12:24:16 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1BBOGF2025401 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 12:24:16 +0100 Date: Wed, 11 Feb 2004 12:24:16 +0100 From: Miek Gieben <miekg@atoom.net> To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 Message-ID: <20040211112416.GA25148@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <7706.1076456888@gromit.rfc1035.com> <Pine.GSO.4.55.0402110127350.4412@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <Pine.GSO.4.55.0402110127350.4412@filbert> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 11 Feb, @07:34, Samuel wrote in "Re: trying to close Editor's Q ..."] > Using the language of Q-28 (which may change slightly), I think five > words are sufficient: "SHOULD be treated as bogus." The MAY is > implicit. after reading 2119, I wholehearted agree that these 5 words are enough, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 06:56:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28137 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 06:56:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqswN-000OSX-OC for namedroppers-data@psg.com; Wed, 11 Feb 2004 11:54:03 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqswM-000OSL-Ol for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 11:54:02 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BBrhwQ010707; Wed, 11 Feb 2004 12:53:43 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BBsZje025757; Wed, 11 Feb 2004 12:54:35 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BBsZU8025754; Wed, 11 Feb 2004 12:54:35 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 11 Feb 2004 12:54:35 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ted Lindgreen <ted@NLnetLabs.nl> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> Message-ID: <Pine.LNX.4.58.0402111246230.25699@elektron.atoom.net> References: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 11 Feb 2004, Ted Lindgreen wrote: > [Quoting Samuel Weiler, on Feb 11, 9:19, in "Re: trying to close ..."] > ..... > > Repeating what I said when I started this discussion on 15 January: > > > > I think SHOULD is perfectly correct. > > is 100% correct. (Please read RFC 2119 first if you disagree). > > And I support Sam's suggestion that: > "SHOULD be treated as bogus" > is sufficient. > > IMHO: Adding anything else is unnecessary (it's already in RFC 2119) > and only asking for trouble and endless discussions. Ted, Miek, Sam, anyone Could you please state what those 'valid reasons' or 'particular circumstances' are that can not be satisfied outside the DNSSEC protocol to justify a change to SHOULD ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 08:23:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00052 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 08:23:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AquGf-000BXq-4j for namedroppers-data@psg.com; Wed, 11 Feb 2004 13:19:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AquGU-000BQk-AE for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 13:18:54 +0000 Received: (qmail 34478 invoked from network); 11 Feb 2004 13:34:40 -0000 Received: from h219-110-033-104.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.104) by necom830.hpcl.titech.ac.jp with SMTP; 11 Feb 2004 13:34:40 -0000 Message-ID: <402A2C21.7070606@necom830.hpcl.titech.ac.jp> Date: Wed, 11 Feb 2004 22:20:33 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: roy@dnss.ec CC: Ted Lindgreen <ted@NLnetLabs.nl>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 References: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111246230.25699@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0402111246230.25699@elektron.atoom.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit roy@dnss.ec wrote: > Ted, Miek, Sam, anyone > > Could you please state what those 'valid reasons' or 'particular > circumstances' are that can not be satisfied outside the DNSSEC > protocol to justify a change to SHOULD ? As you ask anyone else, there absolutely are no circumstances not satisfied by plain DNS. That is, DNSSEC is unnecessary. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 08:46:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00822 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 08:46:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqueL-000G8x-Mj for namedroppers-data@psg.com; Wed, 11 Feb 2004 13:43:33 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqueE-000G6g-C3 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 13:43:26 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BDhDwQ011939 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 14:43:13 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.10/8.12.10/Submit) id i1BDhDGj011938 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 14:43:13 +0100 (CET) (envelope-from ted) Message-Id: <200402111343.i1BDhDGj011938@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 11 Feb 2004 14:43:13 +0100 In-Reply-To: "roy@dnss.ec's message as of Feb 11, 12:54" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting roy@dnss.ec, on Feb 11, 12:54, in "Re: trying to close ..."] ... > Ted, Miek, Sam, anyone > > Could you please state what those 'valid reasons' or 'particular > circumstances' are that can not be satisfied outside the DNSSEC > protocol to justify a change to SHOULD ? I can think of several circumstances one still wants to see the returned info when the signatures fail, but the most clear one is probably: when debugging a lookup problem. This seems to me a typical example of what is meant by the wording in RFC 2119 for "SHOULD". In contrast, the wording of "MUST" in RFC 2119 makes debugging impossible, and that is not what we want, I think. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 09:08:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01359 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 09:08:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aquz0-000KdA-Sw for namedroppers-data@psg.com; Wed, 11 Feb 2004 14:04:54 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aquyz-000Kch-KV for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 14:04:53 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1BE4NjO027204 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 09:04:23 -0500 (EST) Message-ID: <002d01c3f0a7$dddb7e60$b9370681@campus.nist.gov> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <200402111343.i1BDhDGj011938@open.nlnetlabs.nl> Subject: Re: trying to close Editor's Question Q-29 Date: Wed, 11 Feb 2004 09:03:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If one is debugging DNSSEC, it would make more sense to turn on the CD bit for queries and not rely on whatever policy is in place at a recursive resolver. One wouldn't know if the recursive resolver is accepting out of date RRSIGs or not. Use of "SHOULD" might lead to unexpected behavior. Use of the CD bit overrides any local policy for "pass through" recursive resolvers for that query. Scott ----- Original Message ----- From: "Ted Lindgreen" <ted@NLnetLabs.nl> To: <namedroppers@ops.ietf.org> Sent: Wednesday, February 11, 2004 8:43 AM Subject: Re: trying to close Editor's Question Q-29 > [Quoting roy@dnss.ec, on Feb 11, 12:54, in "Re: trying to close ..."] > .... > > Ted, Miek, Sam, anyone > > > > Could you please state what those 'valid reasons' or 'particular > > circumstances' are that can not be satisfied outside the DNSSEC > > protocol to justify a change to SHOULD ? > > I can think of several circumstances one still wants to see the > returned info when the signatures fail, but the most clear one > is probably: when debugging a lookup problem. > > This seems to me a typical example of what is meant by the wording > in RFC 2119 for "SHOULD". > > In contrast, the wording of "MUST" in RFC 2119 makes debugging > impossible, and that is not what we want, I think. > > -- ted > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 09:14:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01649 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 09:14:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqv4p-000M1l-VC for namedroppers-data@psg.com; Wed, 11 Feb 2004 14:10:55 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqv4h-000M0g-Is for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 14:10:47 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BEAZwQ012339; Wed, 11 Feb 2004 15:10:35 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BEBSrr028068; Wed, 11 Feb 2004 15:11:28 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BEBSXs028065; Wed, 11 Feb 2004 15:11:28 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 11 Feb 2004 15:11:28 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ted Lindgreen <ted@NLnetLabs.nl> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <200402111343.i1BDhDGj011938@open.nlnetlabs.nl> Message-ID: <Pine.LNX.4.58.0402111454350.25699@elektron.atoom.net> References: <200402111343.i1BDhDGj011938@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 11 Feb 2004, Ted Lindgreen wrote: > [Quoting roy@dnss.ec, on Feb 11, 12:54, in "Re: trying to close ..."] > ... > > Ted, Miek, Sam, anyone > > > > Could you please state what those 'valid reasons' or 'particular > > circumstances' are that can not be satisfied outside the DNSSEC > > protocol to justify a change to SHOULD ? > > I can think of several circumstances one still wants to see the > returned info when the signatures fail, but the most clear one > is probably: when debugging a lookup problem. Debug with CD=1 Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 09:39:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02556 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 09:39:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqvRX-000030-SW for namedroppers-data@psg.com; Wed, 11 Feb 2004 14:34:23 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqvRW-00002n-Qh for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 14:34:22 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BEYHwQ025937; Wed, 11 Feb 2004 15:34:17 +0100 (CET) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.10/8.12.10/Submit) id i1BEYH81025936; Wed, 11 Feb 2004 15:34:17 +0100 (CET) (envelope-from ted) Message-Id: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 11 Feb 2004 15:34:17 +0100 In-Reply-To: ""Scott Rose"'s message as of Feb 11, 15:10" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Scott Rose" <scottr@nist.gov>, <namedroppers@ops.ietf.org> Subject: Re: trying to close Editor's Question Q-29 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting "Scott Rose", on Feb 11, 15:10, in "Re: trying to close ..."] > If one is debugging DNSSEC, it would make more sense to turn on the CD bit ... I'm not sure you have much experience with debugging or in general problemanalysis, but I have ( > 25 years ), and I know it one of the few things I'm actually good at: The very last thing one should do when analysing some strange problem is to flip a switch that changes the fundamental behaviour of the system you are analysing. The CD bit is such a switch. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 09:52:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03064 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 09:52:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqvfr-00033W-02 for namedroppers-data@psg.com; Wed, 11 Feb 2004 14:49:11 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqvfi-00030S-3o for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 14:49:02 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1BEmcjO024223 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 09:48:38 -0500 (EST) Message-ID: <006601c3f0ae$0bfaafe0$b9370681@campus.nist.gov> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> Subject: Re: trying to close Editor's Question Q-29 Date: Wed, 11 Feb 2004 09:48:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Ted Lindgreen" <ted@NLnetLabs.nl> > [Quoting "Scott Rose", on Feb 11, 15:10, in "Re: trying to close ..."] > > If one is debugging DNSSEC, it would make more sense to turn on the CD bit > .... > > I'm not sure you have much experience with debugging or in general > problemanalysis, but I have ( > 25 years ), and I know it one of the > few things I'm actually good at: > I do, surprisingly enough... At least enough not to resort to ad hominum attacks. But the CD bit is a useful bit - it returns all the security related data of the RRset without any middleboxes performing security operations. At least one could determine if a RRSIG was out of date if they have the actually RRSIG. The CD bit (if properly implemented) is like traditional DNS - no security. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 10:42:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05755 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 10:42:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqwQz-0009q1-Td for namedroppers-data@psg.com; Wed, 11 Feb 2004 15:37:53 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqwQo-0009pc-VZ for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 15:37:43 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BFbEwQ039759; Wed, 11 Feb 2004 16:37:15 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BFc8sC029411; Wed, 11 Feb 2004 16:38:08 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BFc4IK029407; Wed, 11 Feb 2004 16:38:07 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 11 Feb 2004 16:38:04 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ted Lindgreen <ted@NLnetLabs.nl> cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> Message-ID: <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 11 Feb 2004, Ted Lindgreen wrote: > The very last thing one should do when analysing some strange > problem is to flip a switch that changes the fundamental behaviour > of the system you are analysing. > > The CD bit is such a switch. The 'please-validate-expired-signature-anyway' configuration directive changes the fundamental behaviour of the system you are analysing as well. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 12:44:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11348 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 12:44:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqyKP-0002G5-92 for namedroppers-data@psg.com; Wed, 11 Feb 2004 17:39:13 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqyKO-0002Fl-D2 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 17:39:12 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i1BHb2k0013131 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 12:37:02 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAT1aqEz; Wed, 11 Feb 04 12:36:44 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i1BHbHSE016474 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 12:37:17 -0500 (EST) Date: Wed, 11 Feb 2004 12:37:17 -0500 (EST) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> Message-ID: <Pine.GSO.4.55.0402111226330.8809@filbert> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > The very last thing one should do when analysing some strange > > problem is to flip a switch that changes the fundamental behaviour > > of the system you are analysing. > > > > The CD bit is such a switch. > > The 'please-validate-expired-signature-anyway' configuration directive > changes the fundamental behaviour of the system you are analysing as well. Um, no. please-validate-... is a local directive that doesn't show up in the queries on the wire nor affect the behavior of the upstream servers EXCEPT to the extend that you might ask for different things. The CD bit can trigger vastly different upstream processing (see -protocol section 4.7), which is what Scott was suggesting (I think). -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 13:04:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11747 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 13:04:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqyeJ-0005q1-Cp for namedroppers-data@psg.com; Wed, 11 Feb 2004 17:59:47 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqye8-0005pP-CD for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 17:59:36 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1BHxUwQ040408; Wed, 11 Feb 2004 18:59:32 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BI0O8h031322; Wed, 11 Feb 2004 19:00:24 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1BI0NT2031319; Wed, 11 Feb 2004 19:00:24 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 11 Feb 2004 19:00:23 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Samuel Weiler <weiler@tislabs.com> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <Pine.GSO.4.55.0402111226330.8809@filbert> Message-ID: <Pine.LNX.4.58.0402111854330.25699@elektron.atoom.net> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> <Pine.GSO.4.55.0402111226330.8809@filbert> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 11 Feb 2004, Samuel Weiler wrote: > > > The very last thing one should do when analysing some strange > > > problem is to flip a switch that changes the fundamental behaviour > > > of the system you are analysing. > > > > > > The CD bit is such a switch. > > > > The 'please-validate-expired-signature-anyway' configuration directive > > changes the fundamental behaviour of the system you are analysing as well. > > Um, no. please-validate-... is a local directive that doesn't show up > in the queries on the wire nor affect the behavior of the upstream > servers EXCEPT to the extend that you might ask for different things. > The CD bit can trigger vastly different upstream processing (see > -protocol section 4.7), which is what Scott was suggesting (I think). Samuel, I did not argue that the changes in the fundamental behaviour of the system were exactly the same. I argued that using the local directive (flipping the boolean directive between TRUE/FALSE) changes the fundamental behaviour of the system as well. Concur ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 14:43:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16904 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 14:43:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar0CT-000JYZ-Ow for namedroppers-data@psg.com; Wed, 11 Feb 2004 19:39:09 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar0CC-000JXa-K8 for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 19:38:52 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1BJcfjO018350 for <namedroppers@ops.ietf.org>; Wed, 11 Feb 2004 14:38:41 -0500 (EST) Message-ID: <007b01c3f0d6$908a34b0$b9370681@campus.nist.gov> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> <Pine.GSO.4.55.0402111226330.8809@filbert> Subject: Re: trying to close Editor's Question Q-29 Date: Wed, 11 Feb 2004 14:38:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Samuel Weiler" <weiler@tislabs.com> > > > The very last thing one should do when analysing some strange > > > problem is to flip a switch that changes the fundamental behaviour > > > of the system you are analysing. > > > > > > The CD bit is such a switch. > > > > The 'please-validate-expired-signature-anyway' configuration directive > > changes the fundamental behaviour of the system you are analysing as well. > > Um, no. please-validate-... is a local directive that doesn't show up > in the queries on the wire nor affect the behavior of the upstream > servers EXCEPT to the extend that you might ask for different things. > The CD bit can trigger vastly different upstream processing (see > -protocol section 4.7), which is what Scott was suggesting (I think). Yes, I may not have be clear enough. Turning on the CD bit does change processing behavior, but also helps isolate DNSSEC behavior. Similar to turning off DNSSEC (but not quite totally turning it off). Having a set default case (always rejecting out of date signatues) can be detected as a bug using queries with the CD bit set. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 11 17:42:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05279 for <dnsext-archive@lists.ietf.org>; Wed, 11 Feb 2004 17:42:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar30S-000FJY-1G for namedroppers-data@psg.com; Wed, 11 Feb 2004 22:38:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Ar30O-000FIp-Uj for namedroppers@ops.ietf.org; Wed, 11 Feb 2004 22:38:53 +0000 Received: (qmail 37107 invoked from network); 11 Feb 2004 22:54:46 -0000 Received: from h219-110-033-104.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.104) by necom830.hpcl.titech.ac.jp with SMTP; 11 Feb 2004 22:54:46 -0000 Message-ID: <402AAF5F.70501@necom830.hpcl.titech.ac.jp> Date: Thu, 12 Feb 2004 07:40:31 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Ted Lindgreen <ted@NLnetLabs.nl> CC: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 References: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> In-Reply-To: <200402110924.i1B9O8ub009018@open.nlnetlabs.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted Lindgreen wrote: >>I think a definition of "small" will be needed. How about using the same >>fudge factor TSIG allows for skewed clocks? > Roy pointed out that there is no need for fudge, as (other than > with TSIG) one can (and should) use overlapping periods. Wrong. There must be a system wide requirement on the minimum overlapping periods for rollover. The period is also applicable to make expiration of some data certain. That is, source of data must be aware that data is valid even after cryptographic expiration for the maximum allowable clock error of source and clients.. Another point related to expiration is that time source must be secure, that is, is locally reliable source or from remote reliable source with cryptographic security. While actual mechanism is variable, it is important to explicitly outlaw such behavior as just accepting GPS derived time. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 09:51:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25680 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 09:51:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArI4E-000JHF-Dv for namedroppers-data@psg.com; Thu, 12 Feb 2004 14:43:50 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArI4D-000JH3-0L for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 14:43:49 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1CEhjwQ064382 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 15:43:45 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1CEijqK018740 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 15:44:45 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1CEijeg018739 for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 15:44:45 +0100 Date: Thu, 12 Feb 2004 15:44:44 +0100 From: Miek Gieben <miekg@atoom.net> To: namedroppers <namedroppers@ops.ietf.org> Subject: draft: resolver-application interface Message-ID: <20040212144444.GA18697@atoom.net> Mail-Followup-To: namedroppers <namedroppers@ops.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, During the LCWS workshop of a few weeks ago the topic was also discussed: what does an application wants/needs to know from a secure aware resolver. I then said I was working on a draft trying to initiate and focus that discussion. During the last few days this topic has also (sort of) sprung up on the namedroppers ML. I'm not sure the draft is dnsop or dnsext material, but I'm posting it here as I feel we were already discussing these sort of things. It is still a *very rough* draft, but I didn't want it to delay any more than it already has. Authors: Gilles Guette, Olivier Courtay and Miek Gieben Abstract: This document describes an interface between a DNSSEC aware resolver and an application. This interface will define which kind of information a DNSSEC aware resolver is able to send back to an application. The basic question we want to answer is: "What does an application wants to know from a secure aware resolver?". In section Section 4 we define an error bit array. The secure aware resolver will set specific bits in the array. With the added information in this error array, the application can have extra control on what to do with bogus data. This document is written in the hope that it will lead to a discussion within the IETF on the resolver-application interaction(s). Where: http://www.nlnetlabs.nl/dnssec/draft-gieben-resolver.txt grtz Miek -- ...all white space is equivalent except in certain situations... - C99 Standard -- http://www.vmunix.com/~gabor/c/draft.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 10:36:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28588 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 10:36:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArIny-000Pye-V1 for namedroppers-data@psg.com; Thu, 12 Feb 2004 15:31:06 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArInq-000Py2-1k for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 15:30:58 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i1CFUgx26094; Thu, 12 Feb 2004 07:30:42 -0800 From: bill <bmanning@karoshi.com> Message-Id: <200402121530.i1CFUgx26094@karoshi.com> Subject: Re: draft: resolver-application interface To: miekg@atoom.net (Miek Gieben) Date: Thu, 12 Feb 2004 07:30:42 -0800 (PST) Cc: namedroppers@ops.ietf.org (namedroppers) In-Reply-To: <20040212144444.GA18697@atoom.net> from "Miek Gieben" at Feb 12, 2004 03:44:44 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit thanks. there was an old thread on this topic that Michael Richardson and myself (with some others) worked on last year. After the LCWS ws, i promised myself to dig it back up... looks like you beat me to it. :) > > Hello, > > During the LCWS workshop of a few weeks ago the topic was also discussed: what > does an application wants/needs to know from a secure aware resolver. I then > said I was working on a draft trying to initiate and focus that discussion. > > During the last few days this topic has also (sort of) sprung up on the > namedroppers ML. I'm not sure the draft is dnsop or dnsext material, but > I'm posting it here as I feel we were already discussing these sort of > things. > > It is still a *very rough* draft, but I didn't want it to delay any more > than it already has. > > Authors: > Gilles Guette, Olivier Courtay and Miek Gieben > > Abstract: > This document describes an interface between a DNSSEC aware resolver > and an application. This interface will define which kind of > information a DNSSEC aware resolver is able to send back to an > application. The basic question we want to answer is: "What does an > application wants to know from a secure aware resolver?". > > In section Section 4 we define an error bit array. The secure aware > resolver will set specific bits in the array. With the added > information in this error array, the application can have extra > control on what to do with bogus data. > > This document is written in the hope that it will lead to a > discussion within the IETF on the resolver-application > interaction(s). > > Where: > http://www.nlnetlabs.nl/dnssec/draft-gieben-resolver.txt > > > grtz > Miek > -- > ...all white space is equivalent except in certain situations... > - C99 Standard -- http://www.vmunix.com/~gabor/c/draft.html > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 11:37:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01594 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 11:37:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArJmK-0006g3-Pu for namedroppers-data@psg.com; Thu, 12 Feb 2004 16:33:28 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArJmJ-0006fq-PA for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 16:33:27 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 587C056871 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 08:33:26 -0800 (PST) Message-Id: <6.0.1.1.2.20040212105743.03479b10@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 12 Feb 2004 11:34:04 -0500 To: <namedroppers@ops.ietf.org> From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <007b01c3f0d6$908a34b0$b9370681@campus.nist.gov> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> <Pine.GSO.4.55.0402111226330.8809@filbert> <007b01c3f0d6$908a34b0$b9370681@campus.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Religion has intruded a bit on both sides of the question. Let me try and recast it a bit for further discussion. In the certificate system, a time limited signature (e.g. validAfter, validBefore in a certificate) means something like "I'm willing to own up to the use of this certificate during this time range. If you try and rely on signatures made by the owner of this certificate outside this time range you do so at your own risk and they might not stand up to third party validation". In the DNS system, there's a question as to what we mean by the time limits on the signature. If you get one (RRSIG) after its time by a substantial amount (e.g. 5 days) it probably means a replay, or maybe bad clock synchronization. If you get one after its time by a small amount (e.g. 5 minutes), it might mean the zone administrator is lazy, but its less likely that someone's trying to replay the data. I think a time limit signature on the data says that "This data is valid for the time specified. If you get an out of time signature, the data is no better (and no worse?) than if I hadn't signed it." Given that its local policy as to whether or not to accept unsigned data (e.g. bogus or indeterminate), its probably also local policy to make this determination based on what the clock says. Roy et al - I actually tend to agree with you, but more because I think there are way too many knobs here. If I had a more security aware stub resolver I think the right answer is that the application decides whether or not it requires signed data and whether or not it accepts bogus (see my specific definitions in previous email), unsecure or indeterminate data. In the final analysis, its the consumer who gets to decide what use to make of the data it receives. All that being said - let me trot out the language I provided previously slightly modified: A resolver [MAY | SHOULD NOT] be configurable as to whether to accept records that are invalid as to time. If configurable, the resolver SHOULD be configurable to as to the maximum out of date invalid records can be to be acceptable and MUST default to not accepting expired records. If the resolver is not configurable it MUST NOT accept expired records. If we use "SHOULD NOT" as opposed to "MAY" in the above, we can say " you can do this, but the WG generally thinks its a bad idea". There are some other clauses that could be added above: a) The resolver [SHOULD NOT | MUST NOT] accept records that are not yet valid (e.g. signature validity is in the future). b) The resolver [SHOULD NOT | MUST NOT] accept records that are more than [1 day] expired. My recommendations would be to use "SHOULD NOT" in the main clause, and add clause a) as a SHOULD NOT. Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 12:43:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04030 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 12:43:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArKon-000GD5-E7 for namedroppers-data@psg.com; Thu, 12 Feb 2004 17:40:05 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArKoh-000GBp-4A for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 17:39:59 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i1CHdkwQ065364; Thu, 12 Feb 2004 18:39:48 +0100 (CET) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1CHel3p020998; Thu, 12 Feb 2004 18:40:47 +0100 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1CHekp8020995; Thu, 12 Feb 2004 18:40:47 +0100 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 12 Feb 2004 18:40:46 +0100 (CET) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Mike StJohns <Mike.StJohns@nominum.com> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <6.0.1.1.2.20040212105743.03479b10@localhost> Message-ID: <Pine.LNX.4.58.0402121747010.16845@elektron.atoom.net> References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> <Pine.GSO.4.55.0402111226330.8809@filbert> <007b01c3f0d6$908a34b0$b9370681@campus.nist.gov> <6.0.1.1.2.20040212105743.03479b10@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mike, Thanks for your words, comments inline... On Thu, 12 Feb 2004, Mike StJohns wrote: > Religion has intruded a bit on both sides of the question. Let me try and > recast it a bit for further discussion. > > In the certificate system, a time limited signature (e.g. validAfter, > validBefore in a certificate) means something like "I'm willing to own up > to the use of this certificate during this time range. If you try and rely > on signatures made by the owner of this certificate outside this time range > you do so at your own risk and they might not stand up to third party > validation". > > In the DNS system, there's a question as to what we mean by the time limits > on the signature. If you get one (RRSIG) after its time by a substantial > amount (e.g. 5 days) it probably means a replay, or maybe bad clock > synchronization. If you get one after its time by a small amount (e.g. 5 > minutes), it might mean the zone administrator is lazy, but its less likely > that someone's trying to replay the data. I think a time limit signature > on the data says that "This data is valid for the time specified. If you > get an out of time signature, the data is no better (and no worse?) than if > I hadn't signed it." Given that its local policy as to whether or not to > accept unsigned data (e.g. bogus or indeterminate), its probably also local > policy to make this determination based on what the clock says. There is a small difference. We've documented very clear what unsigned/bogus/signed data is. One can base local policy on that distinction. Accepting expired data as 'signed&valid' under terms of local policy is not good practise, while accepting expired data as unsigned is introducing something new. Have to think about that one. As you said above about the certificate system, you're on your own when trusting an expired signature that validates. That decision is fine on an end to end system. In DNS however, the validator mostly resides on a middlebox. Is that bad ? One thing we're attending to in the threat model is cache poisoning. A cache is typically a module in a recursive resolver. The same resolver where the validator might reside. > Roy et al - I actually tend to agree with you, but more because I think > there are way too many knobs here. If I had a more security aware stub > resolver I think the right answer is that the application decides whether > or not it requires signed data and whether or not it accepts bogus (see my > specific definitions in previous email), unsecure or indeterminate > data. In the final analysis, its the consumer who gets to decide what > use to make of the data it receives. > > All that being said - let me trot out the language I provided previously > slightly modified: > > A resolver [MAY | SHOULD NOT] be configurable as to whether to accept > records that are invalid as to time. If configurable, the resolver SHOULD > be configurable to as to the maximum out of date invalid records can be to > be acceptable and MUST default to not accepting expired records. If the > resolver is not configurable it MUST NOT accept expired records. You've just introduced more knobs ;-) Anyway, I'll leave this subject for the WG to resolve. More from me will only polarise. Meanwhile we have a deadline :-/ Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 15:03:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10272 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 15:03:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArMzG-000GTB-JE for namedroppers-data@psg.com; Thu, 12 Feb 2004 19:59:02 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArMzD-000GSw-Jt for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 19:58:59 +0000 Received: from ENGILL.ogud.com (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1CJwGLO043251; Thu, 12 Feb 2004 14:58:16 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040212145139.024aad10@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 12 Feb 2004 14:58:43 -0500 To: "Scott Rose" <scottr@nist.gov>, <namedroppers@ops.ietf.org> From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <00f301c3efde$61b20260$b9370681@barnacle> References: <00f301c3efde$61b20260$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:01 2004-02-10, Scott Rose wrote: >Q-29 Resolver handling of expired RRSIGs > >So far, there doesn't seem to be a solid consensus on the following wording: > > > > > > > "SHOULD be rejected, but MAY use RRSIGs if other security > > > checks were successful, depending on local policy". > > > > >To replace the current text that states resolvers MUST reject out of date >signatures. There is no time limit in the original question post, but the >editors would like to see some resolution before the I-D cutoff date. >Personally, I'd like it to be Fri. 13th if possible > >Please post your opinion if you haven't already. Or if you have further >comments on the text, or substitute text. Closure: At this point the chairs see a consensus for continued use of "MUST reject" wording. Olafur (acting WG dictator) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 17:15:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19369 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 17:15:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArP3B-000BJv-2X for namedroppers-data@psg.com; Thu, 12 Feb 2004 22:11:13 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArP39-000BJj-Gd for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 22:11:11 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i1CM93kP008932 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 17:09:03 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAgYaqzr; Thu, 12 Feb 04 17:08:55 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i1CM9jcp011168; Thu, 12 Feb 2004 17:09:45 -0500 (EST) Date: Thu, 12 Feb 2004 17:09:44 -0500 (EST) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> cc: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-Reply-To: <6.0.3.0.2.20040212145139.024aad10@localhost> Message-ID: <Pine.GSO.4.55.0402121705540.8069@filbert> References: <00f301c3efde$61b20260$b9370681@barnacle> <6.0.3.0.2.20040212145139.024aad10@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by filbert.tislabs.com id i1CM9jcp011168 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Thu, 12 Feb 2004, [iso-8859-1] =D3lafur Gudmundsson/DNSEXT co-chair wr= ote: > At this point the chairs see a consensus for continued use of > "MUST reject" wording. (A very rough consensus, perhaps?) Given the pending Q-28, I'm presuming that this will be "must treat as bogus" or somesuch, right? I'm surprised that those opposing this change aren't also objecting to the Q-28 proposal. The way I understand it, the Q-28 language assigns all validation results to one of several states and then suggests how the validator handle those by default. If 2119 language were in use, those suggestions would be SHOULDs. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 17:33:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20382 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 17:33:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArPMB-000EDm-Tg for namedroppers-data@psg.com; Thu, 12 Feb 2004 22:30:51 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1ArPMA-000EDa-PL for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 22:30:51 +0000 Received: (qmail 43148 invoked from network); 12 Feb 2004 22:47:02 -0000 Received: from h219-110-032-104.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.104) by necom830.hpcl.titech.ac.jp with SMTP; 12 Feb 2004 22:47:02 -0000 Message-ID: <402BFF01.5040707@necom830.hpcl.titech.ac.jp> Date: Fri, 13 Feb 2004 07:32:33 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: roy@dnss.ec CC: Mike StJohns <Mike.StJohns@nominum.com>, namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 References: <200402111434.i1BEYH81025936@open.nlnetlabs.nl> <Pine.LNX.4.58.0402111615210.25699@elektron.atoom.net> <Pine.GSO.4.55.0402111226330.8809@filbert> <007b01c3f0d6$908a34b0$b9370681@campus.nist.gov> <6.0.1.1.2.20040212105743.03479b10@localhost> <Pine.LNX.4.58.0402121747010.16845@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0402121747010.16845@elektron.atoom.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit roy@dnss.ec wrote: >>I hadn't signed it." Given that its local policy as to whether or not to >>accept unsigned data (e.g. bogus or indeterminate), its probably also local >>policy to make this determination based on what the clock says. > There is a small difference. We've documented very clear what > unsigned/bogus/signed data is. One can base local policy on that > distinction. A problem is that "local" is not defined very clearly. Clock accuracy is a host local issue. Required strength for authentication is an application local issue. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 18:41:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24671 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 18:41:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArQO8-0001W6-Pw for namedroppers-data@psg.com; Thu, 12 Feb 2004 23:36:56 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArQO5-0001Vl-AS for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 23:36:53 +0000 Received: from sandelman.ottawa.on.ca (wlan237.sandelman.ca [205.150.200.237] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i1CNakw02597 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 18:36:52 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1CNak2r010060 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 18:36:46 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1CNahJe010056 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 18:36:46 -0500 To: namedroppers@ops.ietf.org Subject: Re: trying to close Editor's Question Q-29 In-reply-to: Your message of "Thu, 12 Feb 2004 11:34:04 EST." <6.0.1.1.2.20040212105743.03479b10@localhost> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 12 Feb 2004 18:36:43 -0500 Message-ID: <10055.1076629003@marajade.sandelman.ottawa.on.ca> From: Michael Richardson <mcr@sandelman.ottawa.on.ca> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- {a big long thread on this, most of which I have ignored} >>>>> "Mike" == Mike StJohns <Mike.StJohns@nominum.com> writes: Mike> Roy et al - I actually tend to agree with you, but more because I Mike> think there are way too many knobs here. If I had a more security Mike> aware stub resolver I think the right answer is that the Mike> application decides whether or not it requires signed data and Mike> whether or not it accepts bogus (see my specific definitions in Mike> previous email), unsecure or indeterminate data. In the final Mike> analysis, its the consumer who gets to decide what use to make of Mike> the data it receives. Yes, the consumer of the data is key. Forget about whether or not the application knows how to make a decision. The application needs to be provided with the data such that it can at least, log/audit the decision that was made. *Any policy is okay*, so long as the reason for the failure is clearly explained. This is actually more critical than the other details - if the settings are wrong, or a resign is missed, or a replay is suspected, or whatever, then the human system gets feedback, and something gets fixed. Right now, we get SERVFAIL. That's why the decisions are so hard to discuss and get right. You can not fix this problem by more server policies. Miek's document is a nice start - but the view has to start with what information the application needs to *audit* requests which do *not* fail. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQCwOCoqHRg3pndX9AQHhxQP9GIS2BSVsCh7yqhjCct6cAZ06wmkWuZdT 4YpqtQCIE7VnW6x184mILQLEqCExLo5b9m/6ePPxfuEx8ubKFasVzKexrqj4LTdv xZTAIM862Hob0UtuEI5rDvQmR5lOQFHQxB6sJrlo8rZioRUzyTT0GctElAfnO0DS 4F2VLPIRDb4= =UzyC -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From xudpress_release@hotmail.com Thu Feb 12 19:11:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26722 for <dnsext-archive@ietf.org>; Thu, 12 Feb 2004 19:11:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQvA-0000Hm-00 for dnsext-archive@ietf.org; Thu, 12 Feb 2004 19:11:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQt9-0007Zi-00 for dnsext-archive@ietf.org; Thu, 12 Feb 2004 19:09:01 -0500 Received: from [218.12.34.234] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1ArQqm-0006dT-00; Thu, 12 Feb 2004 19:06:33 -0500 From: "Atualidade Brasileira . dql" <xudpress_release@hotmail.com> To: disman-archive@ietf.org Subject: Lindenberg e a "demoniza��o" da livre iniciativa ref.: aic X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: <E1ArQqm-0006dT-00@ietf-mx> Date: Thu, 12 Feb 2004 19:06:33 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.2 required=5.0 tests=AWL,FORGED_MUA_EUDORA, HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE,MAILTO_SUBJ_REMOVE, MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora * 0.0 AWL AWL: Auto-whitelist adjustment <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252"> <META NAME="Generator" CONTENT="Microsoft Word 97"> <META NAME="Template" CONTENT="C:\Arquivos de programas\Microsoft Office\Office\html.dot"> </HEAD> <BODY LINK="#0000ff" VLINK="#800080"> (xyf) <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:EnEspañol">Lindenberg:EnEspañol </A>- <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:InEnglish(LinkToFreeTranslator">English:LinkToFreeTranslator</A> Série Temas Patrulhados (3) Lindenberg e a "demonização" da livre iniciativa "Muito embora capitalismo, globalização, neoliberalismo, privatizações, propriedade privada etc. não se identifiquem necessáriamente, eles são vistos pelos herdeiros das idéias marxistas como as quatro bestas do Apocalipse" Viés * Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", onde denuncia uma política com viés esquerdista que visa censurar, marginalizar ou encobrir com um manto de silêncio, notícias, opiniões e livros "politicamente incorretos", não afinados com as assim denominadas "causas sociais" inspiradas na teologia da libertação e nos Fórums Sociais: os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados". "As quatro bestas do Apocalipse"? * Em artigo "Capitalismo, globalização, neoliberalismo, privatizações", da Série Temas Patrulhados, Lindenberg constata que muito embora capitalismo, globalização, neoliberalismo, privatizações, propriedade privada etc. não se identifiquem necessáriamente, têm, no entanto, um denominador comum: são vistos pelos progressistas e pelos herdeiros das idéias marxistas como "as quatro bestas do Apocalipse". Com efeito, essas pessoas, sem terem condições de apregoar as benesses do socialismo - por causa dos contrastes gritantes das economias livres versus economias estatizadas, e do fracasso estrondoso destas ultimas - denunciam de maneira generalizada as políticas de austeridade, as multinacionais e as privatizações dos serviços públicos, como sendo as responsáveis pelo crescimento dos bolsões de miséria, estagnação econômica e concentração da renda. Bom senso * Em seu artigo "Capitalismo, globalização, neoliberalismo, privatizações", Lindenberg usa o bom senso e uma linguagem acessível para recolocar as idéias em sua justa ordem. Seguem alguns temas abordados no artigo, que o leitor receberá gratuitamente por e-mail, na íntegra, simplesmente clicando em: <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:EsteArtigoGratuitamente(3) ">EsteArtigoGratuitamente(3)</A> . - Os ideais da livre empresa e da economia de mercado, e o direito de propriedade segundo os ensinamentos tradicionais da Igreja. - A ordem socioeconômica cristã personalizada e orgânica, isto é, uma ordem na qual a preeminência deve ser dada às famílias e às sociedades intermediárias, e não ao Estado. - As campanhas de descrédito contra a propriedade privada. - A verdade sobre o chamado "capitalismo selvagem". . Em que consiste o capitalismo popular ou democrático. . A viga mestre do progresso econômico cristão. . O contraste entre os padrões de vida e de assistência social dos países livres, e dos países com economias estatizantes. Links para receber e-Book e artigos gratuitos <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:e-BookGratuito">Lindenberg:e-BookGratuito</A> (em formato Word, com 11 artigos de Lindenberg) <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:EsteArtigoCompletoGratuitamente(No.3) ">EsteArtigoCompletoGratuitamente(No.3)</A> <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:LivroIntroduçãoGratuita">Lindenberg:LivroIntroduçãoGratuita</A> (em formato Word, Introdução do livro "Os católicos e a economia de mercado") Links de opinião Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, incluindo sua valiosa opinião: <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Concordo">Lindenberg:Concordo </A>- <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Discrepo">Lindenberg:Discrepo </A>- <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Opinião/Sugestão">Lindenberg:Opinião/Sugestão</A> <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:GratuitamenteEsteArtigo(3">Lindenberg:GratuitamenteEsteArtigo(3)</A> Link em espanhol <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:e-BookGratuito">Lindenberg:e-BookGratuitoEsp</A> (em formato Word, com 11 artigos de Lindenberg, em Espanhol) Outros links <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:DesejoAdquirirLivro">Lindenberg:DesejoAdquirirLivro</A> (receberá instruções sobre como poder adquirir o livro no Brasil e em Portugal) <A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Subscrever">Lindenberg:Subscrever</A> (para receber, gratuitamente, os próximos artigos) <A HREF="mailto:construnews@yahoo.com.br?subject=ConstruNews:Remover">ConstruNews:Remover</A> (para ser retirado imediatamente de nosso Address Book). A difusão deste artigo, com a finalidade estritamente cívica e cultural de promover um debate respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. </BODY> </HTML> From owner-namedroppers@ops.ietf.org Thu Feb 12 23:27:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06839 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 23:27:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArUrM-000Hvi-9t for namedroppers-data@psg.com; Fri, 13 Feb 2004 04:23:24 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArUrL-000HvW-AB for namedroppers@ops.ietf.org; Fri, 13 Feb 2004 04:23:23 +0000 Received: from ENGILL.ogud.com (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1D4MZLO044649; Thu, 12 Feb 2004 23:22:36 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040212231103.02da4b80@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 12 Feb 2004 23:23:05 -0500 To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers. In-Reply-To: <20040128203233.08EE614C52@sa.vix.com> References: <20040128203233.08EE614C52@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 15:32 2004-01-28, Paul Vixie wrote: > > The proposed text therefore is: security aware resolvers MAY query for > > missing security RRs; implementations that choose to do so must be > > aware of the fact that the answers received may not be sufficient to > > perform validation. > >this gives no guideance to server implementors, and is therefore= inadequate. > >how about adding this text: > > security aware responders who receive queries for security RRs which > match the content of more than one zone, for example above and below > a delegation point, are encouraged to behave self-consistently, > which could mean: always return an error; always return > above-delegation records; always return below-delegation records; > always return no records; always return both above- and > below-delegation records; or always something else entirely > >in other words, driving home the point that requestor implementors ought= not >depend on the results of queries for security RRs is only part of the= story; >the document should also clearly state that there is no standard behaviour >for responders, and place a self-consistency requirement there instead. While attempting to summarize what the consensus of the working group is on this editors question and trying to interpret this block of text. Does self-consistently apply to a name or the holy Q-trinity? RFC103[45] specify NS is on both sides of delegation, and the lower one be returned to queries, does this imply NSEC should be handled the same way? For the record the affected RR types by this text are NS, NSEC, RRSIG. DS and DNSKEY are not affected as they can only be authoritative on one side of the delegation. Right now my read of the working group is that this text is an improvement over what Olaf put forth as the default result, but needs clarification on scope. =D3lafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 23:28:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06907 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 23:28:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArUv2-000Ixy-LT for namedroppers-data@psg.com; Fri, 13 Feb 2004 04:27:12 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArUv1-000Ixb-5Z for namedroppers@ops.ietf.org; Fri, 13 Feb 2004 04:27:11 +0000 Received: from ENGILL.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1D4QMLO044660; Thu, 12 Feb 2004 23:26:22 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040212232453.0287dec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 12 Feb 2004 23:26:49 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Q-24 DNSKEY with flag 7=0 not to be used with DNSSEC. Cc: Olaf Kolkman <olaf@ripe.net> In-Reply-To: <D6EDDF48-5194-11D8-AF3C-000393DA2D46@ripe.net> References: <D6EDDF48-5194-11D8-AF3C-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 08:21 2004-01-28, Olaf Kolkman wrote: >The behavior for the flag bit (bit7) in the DNSKEY RR set to 0 is not >specified. We propose the following text to be added to section 2.1: >DNSKEY RRs MUST NOT be used for DNSSEC validation if bit 7 of the flag >field is set to 0. This question is closed with the default action, Editors please add this text. =D3lafur=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 23:31:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07051 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 23:31:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArUxz-000JFs-Ch for namedroppers-data@psg.com; Fri, 13 Feb 2004 04:30:15 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArUxy-000JFE-13 for namedroppers@ops.ietf.org; Fri, 13 Feb 2004 04:30:14 +0000 Received: from ENGILL.ogud.com (ns.md.ogud.com [10.20.30.6] (may be forged)) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1D4TSLO044678; Thu, 12 Feb 2004 23:29:28 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040212232747.0289dec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 12 Feb 2004 23:29:38 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Q-25 Under specification of NSEC TTL. Cc: Olaf Kolkman <olaf@ripe.net>, dnssec-editors@east.isi.edu In-Reply-To: <F2C677D9-5194-11D8-AF3C-000393DA2D46@ripe.net> References: <F2C677D9-5194-11D8-AF3C-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 08:21 2004-01-28, Olaf Kolkman wrote: >The document does not specify the setting of the TTL on NSEC RRs. We >propose the following text to be added to 2.3 proto: In the spirit of >[RFC negative cache] the TTL of the NSEC RRset SHOULD match the TTL of >the zone SOA minimum field. There was no objection raised to this, the question is closed. Editors please add this text to protocol document. =D3lafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 12 23:35:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07156 for <dnsext-archive@lists.ietf.org>; Thu, 12 Feb 2004 23:35:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArV1e-000JcK-TP for namedroppers-data@psg.com; Fri, 13 Feb 2004 04:34:02 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArV1d-000Jc7-Tr for namedroppers@ops.ietf.org; Fri, 13 Feb 2004 04:34:02 +0000 Received: from ENGILL.ogud.com (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1D4XGLO044698; Thu, 12 Feb 2004 23:33:17 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040212233049.0285dec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 12 Feb 2004 23:33:47 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Q-26 Appearance of DS RRs. Cc: dnssec-editors@east.isi.edu In-Reply-To: <12F5C8A6-5195-11D8-AF3C-000393DA2D46@ripe.net> References: <12F5C8A6-5195-11D8-AF3C-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 08:22 2004-01-28, Olaf Kolkman wrote: >DS RR MUST NOT appear at non-delegation point has changed. The new >text says DS MUST NOT appear at apex (this is needed). silent on DS >appearing elsewhere. > >The reason for this change is that although it seems rather senseless >to have a DS anywhere else than with a delegation there seems no >reason to forbid the existence elsewhere This question is closed, no discussion default action is to go with new text (and overwrite RFC3658). =D3lafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 13 01:23:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10687 for <dnsext-archive@lists.ietf.org>; Fri, 13 Feb 2004 01:23:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArWgN-000FRB-0o for namedroppers-data@psg.com; Fri, 13 Feb 2004 06:20:11 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArWgC-000FPk-Bf for namedroppers@ops.ietf.org; Fri, 13 Feb 2004 06:20:00 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0CFF21396E for <namedroppers@ops.ietf.org>; Fri, 13 Feb 2004 06:20:00 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: nsec target restrictions X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 13 Feb 2004 06:20:00 +0000 Message-Id: <20040213062000.0CFF21396E@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk in the current -bis docset, nsec asserts a range of nonexistence beginning after its owner name and ending before its target name. implementors are thus free to syntax-check incoming nsec rr's requiring (target > owner). however, there appears to be no other restriction on the target ("ending") name. it doesn't have to be in-zone, or even in-ballywick. this doesn't harm the current validator in any way i can see, but it seems sloppy. if the nsec target name isn't in-ballywick for the nsec owner's zone apex, then it should be a syntax error and should cause failure to be signalled at zone loading time, and it should cause the nsec to be unusable for validation if some server decides to hand it out anyway. "ISC.ORG NSEC ... PBS.ORG" is unacceptable, unless ORG is the apex and both ISC and PBS are in-zone data for ORG. similarly "ISC.ORG NSEC ... ORG" or "ISC.ORG NSEC ... ." or "ISC.ORG NSEC ... VIX.COM". it is not possible to syntax-check the subzone case, for example if DV.ISC.ORG is a zone cut and "ISC.ORG NSEC ... WWW.DV.ISC.ORG" is seen -- simply because the existence of the DV.ISC.ORG zone cut doesn't have to be known if present, whereas the existence of an ISC.ORG zone cut does have to be known if present. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Feb 14 11:40:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23342 for <dnsext-archive@lists.ietf.org>; Sat, 14 Feb 2004 11:40:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1As2ju-000FOj-Kt for namedroppers-data@psg.com; Sat, 14 Feb 2004 16:33:58 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1As2jt-000FOO-52 for namedroppers@ops.ietf.org; Sat, 14 Feb 2004 16:33:57 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1EGX1LN054736 for <namedroppers@ops.ietf.org>; Sat, 14 Feb 2004 11:33:01 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1EGX0lY054735 for namedroppers@ops.ietf.org; Sat, 14 Feb 2004 11:33:00 -0500 (EST) Received: from [141.146.126.229] (helo=agminet02.oracle.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArOAC-0002fk-OL for namedroppers@ops.ietf.org; Thu, 12 Feb 2004 21:14:24 +0000 Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by agminet02.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1CLAIcq019906 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 13:10:49 -0800 Received: from rgmgw6.us.oracle.com (localhost [127.0.0.1]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i1CLAI211390 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 14:10:18 -0700 (MST) Received: from oracle.com (dbrower-sun.us.oracle.com [130.35.180.64]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i1CLAH211341 for <namedroppers@ops.ietf.org>; Thu, 12 Feb 2004 14:10:17 -0700 (MST) Message-ID: <402BEBB8.3000700@oracle.com> Date: Thu, 12 Feb 2004 13:10:16 -0800 From: David Brower <David.Brower@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5a) Gecko/20030527 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: LLMNR and Rendezvous TTL disagreement, a modest proposal Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-White-List-Member: TRUE X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Not being religious, and only being a party that wishes to use things in this space to reduce configuration, interoperability between LLMNL and Rendezvous is important in reaching stability and critical mass. The first contentious issue seems to be the TTL field. There seem to be perfectly good arguments for each position, and I am not wise enough to say either is correct. Is it plausible to say "both are right" on this point? Have the standard say senders may set the field to either 1 or 255, and recipients should accept either value? Both seem just as good at detecting leaked packets. You may stone me now. thanks, David Brower Oracle Cluster Architecture -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Feb 14 17:34:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03275 for <dnsext-archive@lists.ietf.org>; Sat, 14 Feb 2004 17:34:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1As8Im-0004Eq-3E for namedroppers-data@psg.com; Sat, 14 Feb 2004 22:30:20 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1As8Ic-0004Cz-Od for namedroppers@ops.ietf.org; Sat, 14 Feb 2004 22:30:10 +0000 Received: (qmail 54277 invoked from network); 14 Feb 2004 22:46:58 -0000 Received: from h219-110-032-030.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.30) by necom830.hpcl.titech.ac.jp with SMTP; 14 Feb 2004 22:46:58 -0000 Message-ID: <402EA1DA.80704@necom830.hpcl.titech.ac.jp> Date: Sun, 15 Feb 2004 07:31:54 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: David Brower <David.Brower@oracle.com> CC: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <402BEBB8.3000700@oracle.com> In-Reply-To: <402BEBB8.3000700@oracle.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David Brower; > The first contentious issue seems to be the TTL field. There seem to > be perfectly good arguments for each position, and I am not wise > enough to say either is correct. Is it plausible to say "both are > right" on this point? No. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 05:34:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10119 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 05:34:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asg09-000EkF-69 for namedroppers-data@psg.com; Mon, 16 Feb 2004 10:29:21 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asg08-000Ejw-16 for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 10:29:20 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4150F18E3; Mon, 16 Feb 2004 05:29:19 -0500 (EST) Date: Mon, 16 Feb 2004 05:29:19 -0500 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: new versions of DNSSECbis drafts posted User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040216102919.4150F18E3@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Even though the DNSEXT WG will not be meeting in Seoul, the dnssec-editors just posted revised versions of the DNSSECbis drafts. Copies (and htmlwdiff output) are also available on the web at: http://www.hactrn.net/ietf/dns/dnssec-editors/ This editing cycle was a welcome change from previous go-rounds, in that, rather than receiving too little feedback, we received so much that we weren't able to integrate all of it in time for the I-D cutoff. A number of issues raised during the RIPE "last call workshop" are waiting for questions that the WG has not (quite) finished discussing. So these still aren't the final versions, but we thought it'd be useful to post what we had. Work will of course continue. Special thanks to Mark Andrews for helping us figure out the (somewhat cryptic) notes we got from the RIPE workshop. If anyone who was at the workshop and will also be in Seoul has time to sit down with the editors (or at least with me -- dunno if any of my fellow editors will be there) to help sort out remaining issues from the RIPE workshop notes, that'd be appreciated. Send mail to dnssec-editors if you're willing. Process note: workshop output has no special standing, it's just more input from WG participants as far as the editors are concerned. Any suggested protocol changes has to go the normal WG process. But most of the notes from the RIPE workshop were about editorial and document clarity issues, and on some of them we couldn't figure out whether it was us, our reviewers, or all of the above who were confused. :) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 06:18:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11696 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 06:18:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asgii-000LWb-NV for namedroppers-data@psg.com; Mon, 16 Feb 2004 11:15:24 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asgih-000LWG-RW for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 11:15:24 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 638F018DE for <namedroppers@ops.ietf.org>; Mon, 16 Feb 2004 06:15:23 -0500 (EST) Date: Mon, 16 Feb 2004 06:15:23 -0500 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: dns-threats, DNSSEC, and glue User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040216111523.638F018DE@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk <hat dnssec-editor=off just-another-bozo-on-this-bus=on> Two separate reviewers of draft-ietf-dnsext-dns-threats have raised essentially the same question over the following paragraph: DNSSEC signatures do not cover glue records, so there's still a possibility of a name-based attack involving glue, but with DNSSEC it is possible to detect the attack by temporarily accepting the glue in order to fetch the signed authoritative version of the same data, then checking the signatures on the authoritative version. Both reviewers asked, in essence, "does that mean that a security-aware resolver -will- use this defense?" The DNSSECbis drafts are silent on this issue. Should they say something about this? </hat> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 07:11:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13524 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 07:11:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AshYW-0003mr-VF for namedroppers-data@psg.com; Mon, 16 Feb 2004 12:08:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AshYT-0003ma-P4 for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 12:08:53 +0000 Received: (qmail 61906 invoked from network); 16 Feb 2004 12:26:10 -0000 Received: from h219-110-032-149.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.149) by necom830.hpcl.titech.ac.jp with SMTP; 16 Feb 2004 12:26:10 -0000 Message-ID: <4030B342.4020707@necom830.hpcl.titech.ac.jp> Date: Mon, 16 Feb 2004 21:10:42 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Rob Austein <sra@isc.org> CC: namedroppers@ops.ietf.org Subject: Re: dns-threats, DNSSEC, and glue References: <20040216111523.638F018DE@thrintun.hactrn.net> In-Reply-To: <20040216111523.638F018DE@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein wrote: > <hat dnssec-editor=off just-another-bozo-on-this-bus=on> > > Two separate reviewers of draft-ietf-dnsext-dns-threats have raised > essentially the same question over the following paragraph: > > DNSSEC signatures do not cover glue records, so there's still a > possibility of a name-based attack involving glue, but with DNSSEC it > is possible to detect the attack by temporarily accepting the glue in > order to fetch the signed authoritative version of the same data, > then checking the signatures on the authoritative version. > > Both reviewers asked, in essence, "does that mean that a > security-aware resolver -will- use this defense?" Sigh... The only defense is to use separate cache for each delegation, which has nothing to do with DNSSEC. Never use glue of some delegation or cache of it for other delegation. > The DNSSECbis drafts are silent on this issue. That's fine. > Should they say > something about this? No. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 08:31:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16270 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 08:31:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asinm-000F9r-8B for namedroppers-data@psg.com; Mon, 16 Feb 2004 13:28:46 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asink-000F9f-WB for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 13:28:45 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1GDRXLN062908 for <namedroppers@ops.ietf.org>; Mon, 16 Feb 2004 08:27:33 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1GDRX5H062907 for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 08:27:33 -0500 (EST) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsOWH-000FGx-Oz for namedroppers@ops.ietf.org; Sun, 15 Feb 2004 15:49:21 +0000 Received: from [10.0.1.3] (dpc6935208055.direcpc.com [69.35.208.55]) by toccata.fugue.com (Postfix) with ESMTP id 48E641B205C; Sun, 15 Feb 2004 09:37:22 -0600 (CST) In-Reply-To: <402BEBB8.3000700@oracle.com> References: <402BEBB8.3000700@oracle.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7D97199C-5FCE-11D8-BF19-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sun, 15 Feb 2004 10:49:08 -0500 To: David Brower <David.Brower@oracle.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Feb 12, 2004, at 4:10 PM, David Brower wrote: > The first contentious issue seems to be the TTL field. There seem to > be perfectly good arguments for each position, and I am not wise > enough to say either is correct. Is it plausible to say "both are > right" on this point? Have the standard say senders may set the field > to either 1 or 255, and recipients should accept either value? Both > seem just as good at detecting leaked packets. The reason we can't just do this is that the standard that was agreed upon requires that if you get a packet with a TTL that's not 255, you have to drop it. This is the standard Rendezvous adopted, because the WG consensus at the time was that this was the right thing to do. Subsequently the consensus of the WG changed, and the current consensus is incompatible with the old consensus. At this point whenever this comes up, everybody clams up, with the exception of a swift rejoinder from the "can't change the meaning of TTL" crowd, and perhaps a quick (perhaps completely inaccurate!) explanation of the situation from me. I do not think that there is consensus that we should change the meaning of TTL in LLMNR packets to be compatible with Rendezvous, but there also isn't consensus that we should not. And so we all kind of act embarrassed when the question comes up, and I suspect that the end result will be a lack of interoperability, because the consensus seems to have been called already. :'} -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 12:07:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05891 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 12:07:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asm9z-000B1U-9z for namedroppers-data@psg.com; Mon, 16 Feb 2004 17:03:55 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asm9w-000B1C-Jr for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 17:03:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6B48D14C4E for <namedroppers@ops.ietf.org>; Mon, 16 Feb 2004 17:03:51 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: Message from Ted Lemon <mellon@fugue.com> of "Sun, 15 Feb 2004 10:49:08 EST." <7D97199C-5FCE-11D8-BF19-000A95D9C74C@fugue.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 16 Feb 2004 17:03:51 +0000 Message-Id: <20040216170351.6B48D14C4E@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [...] The reason we can't just do this is that the standard that was > agreed upon requires that if you get a packet with a TTL that's not > 255, you have to drop it. This is the standard Rendezvous adopted, > because the WG consensus at the time was that this was the right thing > to do. Subsequently the consensus of the WG changed, and the current > consensus is incompatible with the old consensus. [...] I think there are two topics on which consensus would be valuable and useful but which for the moment are impossible to gauge. Above, Ted makes reference to the old "1 vs 255" thing. Others here have shown that one choice assures correct behaviour by initiators, the other by responders, and that either choice is useful, perhaps equally so. At this point we could flip a coin to decide, and the consensus would surely be, "wow we sure are glad that some kind of decision got made." The second point on which consensus is unclear is actually much more important, and that's "should we allow Apple to legislate standards using the force of their installed base?" Apparently there's some concern that Apple is acting like a bully here. I've also heard of suspicions that Microsoft's big reason for pushing LLMNR is to wipe out Apple's early lead in this market. What we (as IETF "members") have to decide isn't "who should win this fight?" but rather "what's the best engineering solution?" In other words no arguments based on the existence of an installed base, whether for or against, should be taken into account. If the best solution happens to be what Apple did then we should write it that way. If the best solution happens to be what Apple didn't do then we should write it THAT way. But wait, I have a proposal. Given the following three facts... (1) 1 and 255 have about equal usefulness but protect different endpoints (2) apple only chose as they did because of apparent consensus "back then" (3) consensus since then seems to have drifted back into vagueness ...that we give Apple's solution the nod based simply on operational experience with a solution that has already been randomly chosen. -------- But there's still the larger question of "why LLMNR?" If the WG isn't going to advance LLMNR while it remains incompatible with Rendezvous, then why doesn't the WG just advance Rendezvous? Clearly, being early isn't always an advantage. But does it always have to be a disadvantage? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 15:38:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19424 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 15:38:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AspRK-000OZD-42 for namedroppers-data@psg.com; Mon, 16 Feb 2004 20:34:02 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AspRI-000OZ0-2p for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 20:34:00 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18534; Mon, 16 Feb 2004 15:33:57 -0500 (EST) Message-Id: <200402162033.PAA18534@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tkey-renewal-mode-04.txt Date: Mon, 16 Feb 2004 15:33:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : TKEY Secret Key Renewal Mode Author(s) : Y. Kamite, M. Nakayama Filename : draft-ietf-dnsext-tkey-renewal-mode-04.txt Pages : 22 Date : 2004-2-16 This document defines a new mode in TKEY [RFC2930] and proposes an atomic method for changing secret keys used for TSIG [RFC2845] periodically. Originally, TKEY provides methods of setting up shared secrets other than manual exchange, but it cannot control timing of key renewal very well though it can add or delete shared keys separately. This proposal is a systematical key renewal procedure intended for preventing signing DNS messages with old and non-safe keys permanently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-04.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-ietf-dnsext-tkey-renewal-mode-04.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-16121515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tkey-renewal-mode-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16121515.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 16:13:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25320 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 16:13:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asq0U-0003xz-7W for namedroppers-data@psg.com; Mon, 16 Feb 2004 21:10:22 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asq0S-0003xn-W0 for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 21:10:21 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i1GL8AA1013836 for <namedroppers@ops.ietf.org>; Mon, 16 Feb 2004 16:08:10 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXkaa_A; Mon, 16 Feb 04 16:07:59 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i1GL8nlJ012935; Mon, 16 Feb 2004 16:08:49 -0500 (EST) Date: Mon, 16 Feb 2004 16:08:49 -0500 (EST) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: Rob Austein <sra@isc.org> cc: namedroppers@ops.ietf.org Subject: Re: dns-threats, DNSSEC, and glue In-Reply-To: <20040216111523.638F018DE@thrintun.hactrn.net> Message-ID: <Pine.GSO.4.55.0402161550470.11768@filbert> References: <20040216111523.638F018DE@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > DNSSEC signatures do not cover glue records, so there's still a > possibility of a name-based attack involving glue, but with DNSSEC it > is possible to detect the attack by temporarily accepting the glue in > order to fetch the signed authoritative version of the same data, > then checking the signatures on the authoritative version. > > Both reviewers asked, in essence, "does that mean that a > security-aware resolver -will- use this defense?" > > The DNSSECbis drafts are silent on this issue. Should they say > something about this? No, DNSSECbis should neither mandate using this defense nor prohibit using it. Reasoning: 1) So long as the rest of the zone's data passes validation, the essential service provided by DNSSEC (data authentication) is intact. 2) If an attacker substitutes nameservers that don't answer, the resolver is left with no documented mechanism to find working nameservers. It doesn't make much sense to tell resolvers to do this check when they have no fallback. But such mechanisms are likely to be developed in the future, which is why we shouldn't prohibit this sort of checking, 3) Unless we care about query confidentiality. At attacker could redirect queries to itself, then answer with real signed zone data. The benefit? The attacker sees the queries. Without doing the check, resolvers don't know this is going on. If we claimed that DNSSEC offered any confidentiality protection, this might be worth looking at in more depth. (intro-08 reminds readers at least three times that DNSSEC does not provide confidentiality protection.) -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 16 18:50:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12576 for <dnsext-archive@lists.ietf.org>; Mon, 16 Feb 2004 18:50:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AssRP-000Ig9-2v for namedroppers-data@psg.com; Mon, 16 Feb 2004 23:46:19 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AssRN-000Ifw-UI for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 23:46:18 +0000 Received: (qmail 64227 invoked from network); 17 Feb 2004 00:03:43 -0000 Received: from h219-110-032-140.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.140) by necom830.hpcl.titech.ac.jp with SMTP; 17 Feb 2004 00:03:43 -0000 Message-ID: <403156B6.1020807@necom830.hpcl.titech.ac.jp> Date: Tue, 17 Feb 2004 08:48:06 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> CC: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <20040216170351.6B48D14C4E@sa.vix.com> In-Reply-To: <20040216170351.6B48D14C4E@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul; > (1) 1 and 255 have about equal usefulness but protect different endpoints IETF concern is to pretect the network, to which both Apple and Microsoft are indifferent. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 12:29:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19791 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 12:29:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1At8vo-000H9S-88 for namedroppers-data@psg.com; Tue, 17 Feb 2004 17:22:48 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1At8vj-000H96-6Q for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 17:22:43 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i1HHMd1o028837; Tue, 17 Feb 2004 12:22:39 -0500 To: Samuel Weiler <weiler@tislabs.com> Cc: Rob Austein <sra@isc.org>, namedroppers@ops.ietf.org Subject: Re: dns-threats, DNSSEC, and glue References: <20040216111523.638F018DE@thrintun.hactrn.net> <Pine.GSO.4.55.0402161550470.11768@filbert> From: Derek Atkins <derek@ihtfp.com> Date: Tue, 17 Feb 2004 12:22:39 -0500 In-Reply-To: <Pine.GSO.4.55.0402161550470.11768@filbert> (Samuel Weiler's message of "Mon, 16 Feb 2004 16:08:49 -0500 (EST)") Message-ID: <sjmbrnx39k0.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Samuel Weiler <weiler@tislabs.com> writes: >> DNSSEC signatures do not cover glue records, so there's still a >> possibility of a name-based attack involving glue, but with DNSSEC it >> is possible to detect the attack by temporarily accepting the glue in >> order to fetch the signed authoritative version of the same data, >> then checking the signatures on the authoritative version. >> >> Both reviewers asked, in essence, "does that mean that a >> security-aware resolver -will- use this defense?" >> >> The DNSSECbis drafts are silent on this issue. Should they say >> something about this? > > No, DNSSECbis should neither mandate using this defense nor prohibit > using it. But should DNSSECbis _mention_ this defense as a potential means to thwart the attack? Sure, it doesn't have to mandate it, nor should it prohibit, but should it at least be mentioned? Or should we expect resolver implementers to have read the threats document as well as DNSSECbis? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 13:16:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23570 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 13:16:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1At9iw-000NFI-UG for namedroppers-data@psg.com; Tue, 17 Feb 2004 18:13:34 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1At9iu-000NF0-Me for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 18:13:32 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i1HICujO029834 for <namedroppers@ops.ietf.org>; Tue, 17 Feb 2004 13:12:56 -0500 (EST) Message-ID: <024701c3f581$80f9b2a0$b9370681@campus.nist.gov> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <20040216111523.638F018DE@thrintun.hactrn.net><Pine.GSO.4.55.0402161550470.11768@filbert> <sjmbrnx39k0.fsf@dogbert.ihtfp.org> Subject: Re: dns-threats, DNSSEC, and glue Date: Tue, 17 Feb 2004 13:11:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Derek Atkins" <derek@ihtfp.com> > Samuel Weiler <weiler@tislabs.com> writes: > > >> DNSSEC signatures do not cover glue records, so there's still a > >> possibility of a name-based attack involving glue, but with DNSSEC it > >> is possible to detect the attack by temporarily accepting the glue in > >> order to fetch the signed authoritative version of the same data, > >> then checking the signatures on the authoritative version. > >> > >> Both reviewers asked, in essence, "does that mean that a > >> security-aware resolver -will- use this defense?" > >> > >> The DNSSECbis drafts are silent on this issue. Should they say > >> something about this? > > > > No, DNSSECbis should neither mandate using this defense nor prohibit > > using it. > > But should DNSSECbis _mention_ this defense as a potential means to > thwart the attack? Sure, it doesn't have to mandate it, nor should it > prohibit, but should it at least be mentioned? Or should we expect > resolver implementers to have read the threats document as well as > DNSSECbis? > Maybe drop the defense suggestion (to avoid it sounding like a mandate), and adding a more explicit reference to the threat document? Trying to reach a compromise - I agree that the DNSSECbis drafts shouldn't be making suggestions on things if they are not part of the spec. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 16:40:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07817 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 16:40:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtCtj-000LiX-6B for namedroppers-data@psg.com; Tue, 17 Feb 2004 21:36:55 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtCtd-000Li4-PA for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 21:36:49 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07414; Tue, 17 Feb 2004 16:36:47 -0500 (EST) Message-Id: <200402172136.QAA07414@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-05.txt Date: Tue, 17 Feb 2004 16:36:46 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends Filename : draft-ietf-dnsext-dnssec-protocol-05.txt Pages : 58 Date : 2004-2-17 This document is part of a family of documents which describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-05.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-ietf-dnsext-dnssec-protocol-05.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-17165300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17165300.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 16:40:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07852 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 16:40:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtCtk-000Lim-Sq for namedroppers-data@psg.com; Tue, 17 Feb 2004 21:36:56 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtCtj-000Lia-Qe for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 21:36:55 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07427; Tue, 17 Feb 2004 16:36:53 -0500 (EST) Message-Id: <200402172136.QAA07427@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-07.txt Date: Tue, 17 Feb 2004 16:36:53 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Resource Records for the DNS Security Extensions Author(s) : R. Arends Filename : draft-ietf-dnsext-dnssec-records-07.txt Pages : 37 Date : 2004-2-17 This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existance (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-07.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-ietf-dnsext-dnssec-records-07.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-07.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-17165325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17165325.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 17:07:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11015 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 17:07:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtDKD-000Pfx-L8 for namedroppers-data@psg.com; Tue, 17 Feb 2004 22:04:17 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtDK9-000PbS-2c for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 22:04:13 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1HM2oLN069223 for <namedroppers@ops.ietf.org>; Tue, 17 Feb 2004 17:02:50 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1HM2oYT069222 for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 17:02:50 -0500 (EST) Received: from [203.51.31.177] (helo=cuneata.net) by psg.com with smtp (Exim 4.30; FreeBSD) id 1At1E8-000N48-Ba for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 09:09:12 +0000 Received: (qmail 4144 invoked from network); 17 Feb 2004 17:11:38 -0000 Received: from pc-00216.cuneata.net (HELO rachel) (192.168.0.216) by squirt.cuneata.net (192.168.0.1) with ESMTP; 17 Feb 2004 17:11:38 -0000 From: Brad Hards <bradh@frogmouth.net> To: Paul Vixie <paul@vix.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 17 Feb 2004 20:09:02 +1100 User-Agent: KMail/1.6.51 Cc: namedroppers@ops.ietf.org References: <20040216170351.6B48D14C4E@sa.vix.com> In-Reply-To: <20040216170351.6B48D14C4E@sa.vix.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_yodMA6x9wCGOmTU"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402172009.06027.bradh@frogmouth.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] --Boundary-02=_yodMA6x9wCGOmTU Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 17 Feb 2004 04:03 am, Paul Vixie wrote: > But wait, I have a proposal. Given the following three facts... > > (1) 1 and 255 have about equal usefulness but protect different > endpoints (2) apple only chose as they did because of apparent consensus > "back then" (3) consensus since then seems to have drifted back into > vagueness > > ...that we give Apple's solution the nod based simply on operational > experience with a solution that has already been randomly chosen. I suggest that we make it "MUST (or SHOULD) send at 255, MAY bother to chec= k"=20 as the path to least gratuitous breakage. Brd --Boundary-02=_yodMA6x9wCGOmTU Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBAMdoyGwwszQ/PZzgRAtPcAKCc/3IT3eqZz4YkzFQcHpAv9xJN+gCfRO6a JrcjiJIFa8PTjZXsdMOwrGI= =rl1V -----END PGP SIGNATURE----- --Boundary-02=_yodMA6x9wCGOmTU-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 17 17:08:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11067 for <dnsext-archive@lists.ietf.org>; Tue, 17 Feb 2004 17:08:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtDK9-000Pdc-VZ for namedroppers-data@psg.com; Tue, 17 Feb 2004 22:04:13 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtDK5-000Pav-4j for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 22:04:09 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1HM2kLN069218 for <namedroppers@ops.ietf.org>; Tue, 17 Feb 2004 17:02:46 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1HM2ktm069217 for namedroppers@ops.ietf.org; Tue, 17 Feb 2004 17:02:46 -0500 (EST) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsqEe-00057D-Fe for namedroppers@ops.ietf.org; Mon, 16 Feb 2004 21:25:00 +0000 Received: from [192.168.3.123] (66-65-61-190.nyc.rr.com [66.65.61.190]) by toccata.fugue.com (Postfix) with ESMTP id A87F61B200B; Mon, 16 Feb 2004 15:12:51 -0600 (CST) In-Reply-To: <20040216170351.6B48D14C4E@sa.vix.com> References: <20040216170351.6B48D14C4E@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9260F83A-60C6-11D8-A8AF-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Mon, 16 Feb 2004 16:24:58 -0500 To: Paul Vixie <paul@vix.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Feb 16, 2004, at 12:03 PM, Paul Vixie wrote: > ...that we give Apple's solution the nod based simply on operational > experience with a solution that has already been randomly chosen. This is what I would like to see happen. > But there's still the larger question of "why LLMNR?" If the WG isn't > going to advance LLMNR while it remains incompatible with Rendezvous, > then why doesn't the WG just advance Rendezvous? Clearly, being early > isn't always an advantage. But does it always have to be a > disadvantage? Well, remember that LLMNR addresses one part of what Rendezvous addresses - name resolution. Also, as Bernard pointed out a couple of weeks ago, LLMNR and Rendezvous NR do have slightly different design goals (actually, he said more than slightly, but I think he was exaggerating :'). I think that it's worthwhile to compromise where we can, particularly in the 1v255 issue, and not try to standardize the whole Rendezvous suite as an IETF standard, because if we try to do this latter thing, I think we will just wind up back in the quagmire. The root cause for Rendezvous not happening here is not that it was too early, but that there is strong resistance among certain participants in the IETF against some of what Rendezvous does. I have tried to overcome this resistance, and my conclusion after having tried for some time is that it can't be overcome through any effort that I'm able to bring to bear. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 18 09:41:07 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14099 for <dnsext-archive@lists.ietf.org>; Wed, 18 Feb 2004 09:41:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtSmu-0007Ea-Li for namedroppers-data@psg.com; Wed, 18 Feb 2004 14:34:56 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtSmp-0007Ds-Sv for namedroppers@ops.ietf.org; Wed, 18 Feb 2004 14:34:51 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12818; Wed, 18 Feb 2004 09:34:49 -0500 (EST) Message-Id: <200402181434.JAA12818@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dns-threats-06.txt Date: Wed, 18 Feb 2004 09:34:49 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Threat Analysis Of The Domain Name System Author(s) : D. Atkins, R. Austein Filename : draft-ietf-dnsext-dns-threats-06.txt Pages : 16 Date : 2004-2-18 Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-06.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-ietf-dnsext-dns-threats-06.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dns-threats-06.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18094650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-threats-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-threats-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18094650.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 18 09:41:15 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14134 for <dnsext-archive@lists.ietf.org>; Wed, 18 Feb 2004 09:41:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtSmk-0007DT-Lk for namedroppers-data@psg.com; Wed, 18 Feb 2004 14:34:46 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtSmi-0007D5-KM for namedroppers@ops.ietf.org; Wed, 18 Feb 2004 14:34:44 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12805; Wed, 18 Feb 2004 09:34:42 -0500 (EST) Message-Id: <200402181434.JAA12805@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-09.txt Date: Wed, 18 Feb 2004 09:34:42 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Introduction and Requirements Author(s) : R. Arends, R. Austein, D. Massey, M. Larson, S. Rose Filename : draft-ietf-dnsext-dnssec-intro-09.txt Pages : 25 Date : 2004-2-18 The Domain Name System Security Extensions (DNSSEC) adds data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-09.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-ietf-dnsext-dnssec-intro-09.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-09.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18094638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18094638.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 08:13:59 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17532 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 08:13:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtnvS-000CnI-5U for namedroppers-data@psg.com; Thu, 19 Feb 2004 13:09:10 +0000 Received: from [196.4.160.222] (helo=mercury.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtnvO-000Cmk-Ib for namedroppers@ops.ietf.org; Thu, 19 Feb 2004 13:09:06 +0000 Received: from hypatia.dns.net (c13-rba-5.dial-up.net [196.39.1.134]) by mercury.is.co.za (Postfix) with ESMTP id BE78FC034B; Thu, 19 Feb 2004 15:09:00 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i1J81Pm29836; Thu, 19 Feb 2004 10:01:25 +0200 Date: Thu, 19 Feb 2004 10:01:25 +0200 From: Andras Salamon <andras@dns.net> To: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Message-ID: <20040219080125.GA29778@dns.net> References: <20040216170351.6B48D14C4E@sa.vix.com> <200402172009.06027.bradh@frogmouth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402172009.06027.bradh@frogmouth.net> User-Agent: Mutt/1.5.5.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Feb 17, 2004 at 08:09:02PM +1100, Brad Hards wrote: > On Tue, 17 Feb 2004 04:03 am, Paul Vixie wrote: > > ...that we give Apple's solution the nod based simply on operational > > experience with a solution that has already been randomly chosen. > I suggest that we make it "MUST (or SHOULD) send at 255, MAY bother to check" > as the path to least gratuitous breakage. I support "MUST send with TTL=255, MAY reject if TTL<>255 on receipt", possibly with a paragraph emphasizing that routers SHOULD discard such packets if TTL<>255 (though this is perhaps broadening the ambit of the document too far). -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 11:02:16 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24942 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 11:02:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtqWa-000Cfm-MN for namedroppers-data@psg.com; Thu, 19 Feb 2004 15:55:40 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtqWZ-000CfZ-Qp for namedroppers@psg.com; Thu, 19 Feb 2004 15:55:39 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCPWRH>; Thu, 19 Feb 2004 10:55:39 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B641E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'namedroppers@psg.com'" <namedroppers@psg.com> Subject: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 10:55:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Please have a look at http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt Yeah, I know. Flame away. I think it's a pretty good idea anyway :) Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 12:26:30 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27965 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 12:26:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atrrw-000Pb4-JW for namedroppers-data@psg.com; Thu, 19 Feb 2004 17:21:48 +0000 Received: from [192.188.192.2] (helo=imail.akc.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atrrm-000PZZ-RJ for namedroppers@psg.com; Thu, 19 Feb 2004 17:21:38 +0000 Received: from upstairs [64.253.39.242] by imail.akc.com with ESMTP (SMTPD32-8.02) id A26F13D40078; Thu, 19 Feb 2004 12:29:19 -0500 Message-ID: <004501c3f70c$ad9383e0$6401a8c0@akc.com> From: "Al Costanzo" <al@akc.com> To: "Rosen, Brian" <Brian.Rosen@marconi.com>, <namedroppers@psg.com> References: <313680C9A886D511A06000204840E1CF070B641E@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 12:20:31 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0042_01C3F6E2.C492C260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.3 required=5.0 tests=DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C3F6E2.C492C260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear Brian & everyone on the namedroppers list, When I tell you I total agree that this information needs to be in the DNS for a number or reasons: 1.911 as you mentioned 2.Credit Card Verification Processing 3.New Anti-Spam Legislation To add just two more. After reading your draft, I disagree on how the information is to be inserted into the RR. The address needs to be listed in the RR as it was a postal address. The reason for this is ease of use. Everyone know their own address but not mank know thier geographic location. I welcome you and everone to help me come up with a solution in this matter. A document I just revised is attached to this email. Not sure if the list server allows such things. I am not a proud or I need it done my way or I want the glory for the RFC kinda guy. I see a problem that needs to be addressed, I think the solution I presented is the best solution, but if anyone thinks this idea can be tweaked or you want to co-author the work and work on this solution with me, please feel free to let me know. I however do not want the RR to use Log and Lat as reference points. The draft has been submitted as: draft-costanzo-dns-gl-06.txt but I am sure it is not listed in the I-D directory yet. ----- Original Message ----- From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: <namedroppers@psg.com> Sent: Thursday, February 19, 2004 10:55 AM Subject: New I-D on using DNS to support Emergency Calls > Please have a look at > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > Yeah, I know. Flame away. I think it's a pretty good idea anyway :) > > Brian > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > ------=_NextPart_000_0042_01C3F6E2.C492C260 Content-Type: text/plain; name="glnew.txt" Content-Disposition: attachment; filename="glnew.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT A. = Costanzo draft-costanzo-dns-gl-06.txt AKC Computer Services = Corp. Expires: August 2004 Feb = 2004 Definition of the DNS GL Resource Record used to encode Geographic Locations 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast, or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. 2. Abstract This document defines the format of a new Experimental Resource Record = (RR) namely GL for the Domain Naming System (DNS), and reserves a = corresponding DNS type mnemonic and numerical code <tba> (decimal). This definition = deals with associating geographical host location mappings to host names = within a domain within a geopolitical area (a country). =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Costanzo [Page = 1] EXPIRES IN SIX MONTHS Feb = 2004 3. Introduction [NOTE: This draft has been modified from its previous draft version=20 specifically for use with Internet Telepony applications and=20 specifically at the request of a number of people including = members of the working group & the RFC Editor - all of whom had a = number of=20 concerns with the previous version(s) of the draft. Whilst ALL = of the concerns have been addressed in version 5, it is the authors = hope that the draft may be reconsidered by the working group for = publication. The GL resource records usage has been simplified as well. The author welcomes all comments. = ] The ideal way to manage and maintain a database of information, such = as a geograpic location of an Internet host, is to delegate = responsibility to local domain administrators. This document resolves the problem of relating host information = within the DNS to geographical locations. This definition has been designed = to=20 be easy for the person who administrates DNS for a domain. NOT = requiring longitude, latitude and elevation information and merely being able = to=20 enter address information, as you would address a postal letter, will = mean broad acceptance and use of the GL resource record. By making = the=20 location geopolitical, the addressing mechinism should be received = well globally. There is a growing demand for postal address information to be listed = within a DNS record. Specifically, with the growing use of the public = Internet to complete Long Distance telephone calls, there is now a need to know = the physical locations of the hops with the final destinations locations position = most important to agencies such as police and fire departments for 911 information. The availability of geographical location information will = immediately be able to benefit applications in network management, which would = enhance and supplement various network tools which currently exist. The Domain Name System is ideally suited to provide geographic = location information. The information we desire to make available globally = needs to be maintained and updated locally (perfect for DNS). Although there are other location resourse records defined, that = attempt to allow location information on host to be stored and distributed, such = as LOC and GPOS, none have either gained acceptance on a wide scale or made = allowance for location information that is not within the confines of the = planet Earth. 4. The GL format GL has the following format: <owner> <ttl> <class> GL <Rdata> 4.1 Rdata Format Rdata has the following format: <string> <string> The format of the RDATA field is two varying length strings separated = by a space character. The first, the hierarchical locator, then an = address=20 string. Each is quoted (like all strings) only when it has spaces in = it, which will never be true for the first string, and almost always for = the second. Costanzo [Page = 2] EXPIRES IN SIX MONTHS Feb = 2004 4.1.1 The Hierarchical Locator The Hierarchical Locator contains the following components (each = separated by a period "."): =20 Country Code - (REQUIRED) The country code specifies the country the host computer = resides in, or in the case of an astronomical location other than "S3" = (Earth), the country which owns the device and/or machine. The code=20 is a two character fixed length string. These codes are = defined=20 in document ISO 3166-1. "US" for United States for example.=20 =20 =20 Postal Zone - (OPTIONAL) This rdata component supplies the postal code (Zip Code) for = the location the host computer resides. For countries that have a multi-segmented postal coding system, the segments should be separated by period(s) ".". This field may be omitted only if the country in which the = host machine resides does not use a postal coding system otherwise = the data MUST be supplied. When all three Hierarchical Locator components exist for an = DNS=20 entry, the position being defined is considered to be a = "precise=20 position". 4.2 The Visual Address String This string should be entered as you would enter an address on a postal letter within the country specified by the Hierarchical Locator. The country code information MUST NOT be included within the quoted string. This string is always required and must be present in the RDATA field. The visual address string may be used for both visual reference of=20 the physical address as well as by a software application to help determine a more precise location of the host machine (if the Hierarchical Locator lacks sufficient precision). Costanzo [Page = 3] EXPIRES IN SIX MONTHS Feb = 2004 The only instance in which any application should attempt to interpret the visual address string is in a case where the country code defines a country that does not use, or has not implemented a postal code system. No software or application should attempt to override a precise position defined by the Hierarchical Locator with information defined within the quoted string data. 5. Example(s) Example 1 (with a postal zone defined): donuts A 192.188.192.1 GL US.45420.1910 "1425 Arbor Avenue, Dayton OH" Example 2 (no postal zone): lorinda A 129.122.1.1 GL SR "Marthastrasse 64, Shawproject, Uitvlug, = Parimaribo" Example 3 ; Authoritative data for akc.net. ; ; note in this example: ; uspring, diana and martha (even though the complete postal code was ; not entered) are precisely defined ; ; lorinda, resides in the country of SURINAME, which has not = implemented ; a postal coding system. ; ; THIS IS ONLY AN EXAMPLE ; @ IN SOA forme.akc.net. postmaster.akc.net. ( 99071100 ; Serial (yymmddnn) 10800 ; Refresh (3 hours) 3600 ; Retry (1 hour) 3600000 ; Expire (1000 hours) 86400 ; Minimum (24 hours) ) IN NS ns.akc.net. uspring IN A 192.188.192.2 IN MX 5 mail IN HINFO Vax VMS IN GL US.45420.1910 "1425 Arbor Avenue, Dayton OH" ftp IN CNAME uspring Costanzo [Page = 4] EXPIRES IN SIX MONTHS Feb = 2004 diana IN A 192.188.192.3 IN MX 5 mail IN HINFO Vax VMS IN GL US.07204.1367 "808 Chestnut Street, Roselle Park, NJ" www IN CNAME diana martha IN A 192.188.192.4 IN MX 5 mail IN HINFO Vax VMS IN GL US.07204 "815 Chestnut Willis Place, Roselle Park, NJ" lorinda IN A 129.122.1.1 IN GL SR "Marthastrasse 64, Shawproject, Uitvlug, Parimaribo" 6. Why in in the DNS specifically? It serves no useful purpose! It has been mentioned to the Author over and over again for the need = of this=20 resource record for internet telephone applications and how the use of = other Internet Directory style services are not appropriate. DNS is = standardized and a required application for ISPs, other directory services are not. It has also been mentioned that since the there is a one-to-one = relationship between the host and the GL data it is appropriate for inclusion as a = DNS resource record. As already mentioned in the draft, the physical location of a computer = is becomming extremely important for government agencies such as police and fire. =20 7. Other possible uses for GL It has been mentioned to the Author over and over again for the need = of this=20 resource record for internet telephone applications and how the use of = other Internet Directory style services are not appropriate. The use of postal codes also is exactly what is needed for credit card = address authentication. Sites could (quietly) compare GL info provided on = entries from=20 ISPs to what someone enters for additional verification purposes. We also were told that this resource record would be helpful in = tracking down=20 hackers. (although the use of DHCP and dynamic addressing may limit = its usefulness if ISPs did not maintain the GL record properly. 8 Why GL and not TXT records? TXT records do not have a specific order to them. It would be = extremely unwise to=20 to entrust 911 emergency calls to TXT records. Other resource records such as LOC and GPOS are not appropriate for = use with emergency service units as police and fire departments 9. Security Consideration Since this resource record is not required in the DNS there are no = security consideration. If someone such as the Department of Defense did not want the = whereabouts of there computer system to be know, they would merely omit it. =20 Costanzo [Page = 6] EXPIRES IN SIX MONTHS Feb = 2004 10. Author's Address Al Costanzo AKC Computer Services Corp. P.O. Box 4031, Roselle Park, NJ 07204-0531 www.AKC.com Phone: +1 908 298 9000 Email: AL@AKC.COM Costanzo [Page = 7] ------=_NextPart_000_0042_01C3F6E2.C492C260-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From mwbnoticiaurgente@hotmail.com Thu Feb 19 12:45:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29372 for <dnsext-archive@ietf.org>; Thu, 19 Feb 2004 12:45:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtsF6-0003ly-00 for dnsext-archive@ietf.org; Thu, 19 Feb 2004 12:45:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtsE3-0003ey-00 for dnsext-archive@ietf.org; Thu, 19 Feb 2004 12:44:40 -0500 Received: from [219.93.203.189] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AtsDB-0003LP-00; Thu, 19 Feb 2004 12:43:47 -0500 From: "Mato Grosso: . xlf" <mwbnoticiaurgente@hotmail.com> To: disman-request@ietf.org Subject: Alertam sobre perigo de aftosa em fazendas invadidas por �ndios ref.: ibf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: <E1AtsDB-0003LP-00@ietf-mx> Date: Thu, 19 Feb 2004 12:43:47 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.1 required=5.0 tests=HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252"> <META NAME="Generator" CONTENT="Microsoft Word 97"> <META NAME="Template" CONTENT="C:\Arquivos de programas\Microsoft Office\Office\html.dot"> </HEAD> <BODY LINK="#0000ff" VLINK="#800080"> cod.: (ebz) <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=EnEspañol:TraductorGratuitoAutomático">EnEspañol:TraductorGratuitoAutomático</A> - <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=InEnglish:FreeAutomaticTranslator">InEnglish:FreeAutomaticTranslator</A> Mato Grosso do Sul: alertam sobre perigo de aftosa em fazendas invadidas por índios Conselho Indigenista Missionário (Cimi), Fundação Nacional do Índio (Funai) e ONGs são acusadas de "fabricar" conflitos entre índios e proprietários rurais, que já causaram numerosas vítimas, como um dirigente pecuarista recentemente assassinado em Santa Catarina CAMPO GRANDE, Fevr. 19, 2004 (AB) - "Há uma preocupação enorme com relação ao estado sanitário do rebanho bovino estimado em 9 mil cabeças, nas 14 fazendas invadidas por índios na região de Japorã, perto da fronteira com o Paraguai". "Mato Grosso do Sul é livre de aftosa, mediante vacinação, o Estado possui o 1o. rebanho bovino do Brasil, e um dos primeiros do mundo, com 24 milhões e 700 mil cabeças, contribuindo com uma porcentagem significativa das exportações de carne bovina. Qualquer brote de aftosa que venha a macular esse estado sanitário teria de imediato uma enorme repercussão econômica em nível local, nacional e internacional". O alerta foi dado ontem pelo engenheiro Josiel Quintino dos Santos, assessor de Meio Ambiente e Assuntos Indígenas da Federação da Agricultura e Pecuária de Mato Grosso do Sul (Famasul) (<A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino:DesejoContato">DrQuintino:DesejoContato</A> - <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino:DesejoContatoDeImprensa">DrQuintino:DesejoContatoDeImprensa</A>). A tensão e a violência na região fez com que a Agência Estadual de Defesa Sanitária Animal e Vegetal (Iagro) tenha suspendido o trabalho de vigilância e vacinação do rebanho das fazendas invadidas por índios guaranis, caiuás e ñandeva. Quintino acrescentou a preocupação existente no Estado "com os conflitos fabricados e incentivados pelo Conselho Indigenista Missionário (Cimi), e favorecidos pela Fundação Nacional do Índio, segundo já foi documentado no relatório da CPI do Funai, na Câmara dos Deputados". O assessor da Famasul informou que os índios, contrariamente ao informado por alguns meios de imprensa, "não abandonaram nenhuma das 14 fazendas invadidas, e até o momento não permitiram o trabalho de perícia judicial para avaliar a destruição causada". Brasília: deputado Zauith denúncia "manipulação" de índios Também ontem, em Brasília, o deputado sul-matogrossense Murilo Zauith (PFL) fez discurso na tribuna da Câmara para "denunciar os conflitos indígenas" que vem ocorrendo em todo o País, incentivados pela "atuação de determinadas organizações internacionais, que chegam a ameaçar a soberania nacional" e de "pessoas inescrupulosas" que "manipulam" e "incitam os índios a invadir as propriedades rurais". Zauith acrescentou que esse "cenário devastador" já vem causando "uma retração nos investimentos no agronegócio em Mato Grosso do Sul", atividade que "é o principal pilar da economia sul-matogrossense" (<A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DepZauith:DiscursoCompleto">DepZauith:DiscursoCompleto</A>). Santa Catarina: Cimi e Funai fomentam caos, diz Federação da Agricultura A Federação da Agricultura do Estado de Santa Catarina (Faesc), em nota de repúdio diante do assassinato do pecuarista Olisses Stefani, recentemente vitimado com um tiro de carabina na cabeça por indígenas que ameaçavam invadir propriedades rurais, afirma que sua morte "revela a dramática dimensão a que chegaram os conflitos entre índios e produtores no grande Oeste catarinense". E acrescenta que "determinadas organizações, motivadas por objetivos inconfessáveis, fomentam o embate e exasperam a crise, tentando criar um cenário de caos e desordem", sendo "notória, nesse aspecto, a ação do Conselho Indigenista Missionário (Cimi), cujos agentes imiscuem-se nas áreas indígenas para fomentar a discórdia". Enquanto a Fundação Nacional do Índio (Funai) oscila entre a inércia e a omissão, nada fazendo em favor da paz e da tranqüilidade", sendo sua atuação "marcada pela influência de ONGs" (<A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Faesc:TextoCompleto">Faesc:TextoCompleto</A>). 040219AB / Atualidade Brasileira LINKS: <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino/Famasul:DesejoContato">DrQuintino/Famasul:DesejoContato</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino/Famasul:DesejoContatoUrgente">DrQuintino/Famasul:DesejoContatoUrgente</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino/Famasul:DesejoContatoDeImprensa">DrQuintino/Famasul:DesejoContatoDeImprensa</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DepZauith:DiscursoCompleto">DepZauith:DiscursoCompleto</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Faesc:TextoCompleto">Faesc:TextoCompleto</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:MinhaOpinião">AtualidadeBrasileira:MinhaOpinião</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:Concordo">AtualidadeBrasileira:Concordo</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:Discordo">AtualidadeBrasileira:Discordo</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:DocumentaçãoUsada">AtualidadeBrasileira:DocumentaçãoUsada</A> <A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:Remover">AtualidadeBrasileira:Remover</A> A difusão deste comunicado, com uma finalidade exclusivamente informativa, é de responsabilidade da agência Atualidade Brasileira (Rio de Janeiro). O texto pode ser reproduzido parcial ou totalmente, sendo recomendável, mas não necessário, citar a fonte. </BODY> </HTML> From owner-namedroppers@ops.ietf.org Thu Feb 19 13:30:34 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01757 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 13:30:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atsr2-0009TY-3Z for namedroppers-data@psg.com; Thu, 19 Feb 2004 18:24:56 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atsqt-0009TC-R2 for namedroppers@psg.com; Thu, 19 Feb 2004 18:24:47 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCP69W>; Thu, 19 Feb 2004 13:24:47 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6423@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Al Costanzo'" <al@akc.com>, namedroppers@psg.com Subject: RE: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 13:24:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As a practical matter, you rarely type your location into a form to determine where you are. Rather, various service providers, enterprises and automated mechanisms determine your location from a variety of information sources. Therefore, the idea that the form of the entry has to exactly match a postal address is not true. Further, for emergency response, your postal address is often not your response address, for example when the post office that serves you is not the municipality where you are located. In my own case, I live in Pine Township, Allegheny County, but my postal address is Mars, PA 16046. Mars is a nearby town, in Butler County. For emergency dispatch, it is essential that the ERC serving Pine Township get the call, and that for dispatch, that the address is a Pine township address and not a Mars address. Also, the delegation properties of the DNS exactly match what is required to provide location to the precision of a room. Using the naming hierarchy to permit delegation of an address to a building owner, and thence to a suite owner, who enters room level data in his entry is particularly useful. And, the postal zone boundary does not align with the ERC boundaries, and does not align with municipal boundaries, which further complicates populating the database. For these reasons, I believe my suggestion is a better one. Brian > -----Original Message----- > From: Al Costanzo [mailto:al@akc.com] > Sent: Thursday, February 19, 2004 12:21 PM > To: Rosen, Brian; namedroppers@psg.com > Subject: Re: New I-D on using DNS to support Emergency Calls > > > Dear Brian & everyone on the namedroppers list, > > When I tell you I total agree that this information needs to > be in the DNS > for a number or reasons: > > 1.911 as you mentioned > 2.Credit Card Verification Processing > 3.New Anti-Spam Legislation > > To add just two more. > > After reading your draft, I disagree on how the information is to be > inserted into the RR. > > The address needs to be listed in the RR as it was a postal > address. The > reason for this is ease of use. Everyone know their own > address but not mank > know thier geographic location. > > I welcome you and everone to help me come up with a solution > in this matter. > A document I just revised is attached to this email. Not sure > if the list > server allows such things. > > I am not a proud or I need it done my way or I want the glory > for the RFC > kinda guy. > > I see a problem that needs to be addressed, I think the > solution I presented > is the best solution, but if anyone thinks this idea can be > tweaked or you > want to co-author the work and work on this solution with me, > please feel > free to let me know. I however do not want the RR to use Log > and Lat as > reference points. > > The draft has been submitted as: draft-costanzo-dns-gl-06.txt > but I am sure > it is not listed in the I-D directory yet. > > > > ----- Original Message ----- > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > To: <namedroppers@psg.com> > Sent: Thursday, February 19, 2004 10:55 AM > Subject: New I-D on using DNS to support Emergency Calls > > > > Please have a look at > > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > > > Yeah, I know. Flame away. I think it's a pretty good idea > anyway :) > > > > Brian > > > > -- > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 13:42:19 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06104 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 13:42:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Att4U-000BiK-1p for namedroppers-data@psg.com; Thu, 19 Feb 2004 18:38:50 +0000 Received: from [192.188.192.2] (helo=imail.akc.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Att4N-000BeS-BT for namedroppers@psg.com; Thu, 19 Feb 2004 18:38:43 +0000 Received: from upstairs [64.253.39.242] by imail.akc.com with ESMTP (SMTPD32-8.02) id A481FB100FE; Thu, 19 Feb 2004 13:46:25 -0500 Message-ID: <001e01c3f717$6962d8a0$6401a8c0@akc.com> From: "Al Costanzo" <al@akc.com> To: "Rosen, Brian" <Brian.Rosen@marconi.com>, <namedroppers@psg.com> References: <313680C9A886D511A06000204840E1CF070B6423@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 13:37:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Brian, A complete Zip+4 points to your exact location. There is no rule what address you use in the field, and there is a cmment area as well. My opinion is ased on the fact that hardly anyone uses the LOC RR and I think it is because it requires a Log & Lad indication as points of references. IMHO postal addresses solve this, but its only my opinion. Al ----- Original Message ----- From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> Sent: Thursday, February 19, 2004 1:24 PM Subject: RE: New I-D on using DNS to support Emergency Calls > As a practical matter, you rarely type your location into a form to > determine > where you are. Rather, various service providers, enterprises and automated > mechanisms determine your location from a variety of information sources. > Therefore, the idea that the form of the entry has to exactly match a postal > address is not true. Further, for emergency response, your postal address > is > often not your response address, for example when the post office that > serves > you is not the municipality where you are located. In my own case, I live > in > Pine Township, Allegheny County, but my postal address is Mars, PA 16046. > Mars is a nearby town, in Butler County. For emergency dispatch, it is > essential that the ERC serving Pine Township get the call, and that for > dispatch, that the address is a Pine township address and not a Mars > address. > > Also, the delegation properties of the DNS exactly match what is required to > provide location to the precision of a room. Using the naming hierarchy to > permit delegation of an address to a building owner, and thence to a suite > owner, who enters room level data in his entry is particularly useful. > > And, the postal zone boundary does not align with the ERC boundaries, and > does not align with municipal boundaries, which further complicates > populating the database. > > For these reasons, I believe my suggestion is a better one. > > Brian > > > -----Original Message----- > > From: Al Costanzo [mailto:al@akc.com] > > Sent: Thursday, February 19, 2004 12:21 PM > > To: Rosen, Brian; namedroppers@psg.com > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > Dear Brian & everyone on the namedroppers list, > > > > When I tell you I total agree that this information needs to > > be in the DNS > > for a number or reasons: > > > > 1.911 as you mentioned > > 2.Credit Card Verification Processing > > 3.New Anti-Spam Legislation > > > > To add just two more. > > > > After reading your draft, I disagree on how the information is to be > > inserted into the RR. > > > > The address needs to be listed in the RR as it was a postal > > address. The > > reason for this is ease of use. Everyone know their own > > address but not mank > > know thier geographic location. > > > > I welcome you and everone to help me come up with a solution > > in this matter. > > A document I just revised is attached to this email. Not sure > > if the list > > server allows such things. > > > > I am not a proud or I need it done my way or I want the glory > > for the RFC > > kinda guy. > > > > I see a problem that needs to be addressed, I think the > > solution I presented > > is the best solution, but if anyone thinks this idea can be > > tweaked or you > > want to co-author the work and work on this solution with me, > > please feel > > free to let me know. I however do not want the RR to use Log > > and Lat as > > reference points. > > > > The draft has been submitted as: draft-costanzo-dns-gl-06.txt > > but I am sure > > it is not listed in the I-D directory yet. > > > > > > > > ----- Original Message ----- > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > To: <namedroppers@psg.com> > > Sent: Thursday, February 19, 2004 10:55 AM > > Subject: New I-D on using DNS to support Emergency Calls > > > > > > > Please have a look at > > > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > > > > > Yeah, I know. Flame away. I think it's a pretty good idea > > anyway :) > > > > > > Brian > > > > > > -- > > > to unsubscribe send a message to > > namedroppers-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 13:45:36 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10182 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 13:45:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Att9I-000Cbv-0E for namedroppers-data@psg.com; Thu, 19 Feb 2004 18:43:48 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Att9B-000Cao-S5 for namedroppers@psg.com; Thu, 19 Feb 2004 18:43:41 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCP74F>; Thu, 19 Feb 2004 13:43:41 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6424@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Al Costanzo'" <al@akc.com>, namedroppers@psg.com Subject: RE: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 13:43:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Al A Zip+4 can cross a township boundary (mine does). It can cross an ERC response boundary (also true here), and it can cross a state boundary (rare, but true). Postal codes are for the post office, and they don't reflect anything other than convenience for the Post Office sorting and delivery people. In many countries, they don't even have postal codes. As such, I don't think they help anything but delivering snail mail. Brian > -----Original Message----- > From: Al Costanzo [mailto:al@akc.com] > Sent: Thursday, February 19, 2004 1:37 PM > To: Rosen, Brian; namedroppers@psg.com > Subject: Re: New I-D on using DNS to support Emergency Calls > > > Hi Brian, > > A complete Zip+4 points to your exact location. There is no rule what > address you use in the field, and there is a cmment area as well. > > My opinion is ased on the fact that hardly anyone uses the > LOC RR and I > think it is because it requires a Log & Lad indication as points of > references. > > IMHO postal addresses solve this, but its only my opinion. > > Al > ----- Original Message ----- > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> > Sent: Thursday, February 19, 2004 1:24 PM > Subject: RE: New I-D on using DNS to support Emergency Calls > > > > As a practical matter, you rarely type your location into a form to > > determine > > where you are. Rather, various service providers, enterprises and > automated > > mechanisms determine your location from a variety of > information sources. > > Therefore, the idea that the form of the entry has to > exactly match a > postal > > address is not true. Further, for emergency response, your > postal address > > is > > often not your response address, for example when the post > office that > > serves > > you is not the municipality where you are located. In my > own case, I live > > in > > Pine Township, Allegheny County, but my postal address is > Mars, PA 16046. > > Mars is a nearby town, in Butler County. For emergency > dispatch, it is > > essential that the ERC serving Pine Township get the call, > and that for > > dispatch, that the address is a Pine township address and not a Mars > > address. > > > > Also, the delegation properties of the DNS exactly match > what is required > to > > provide location to the precision of a room. Using the > naming hierarchy to > > permit delegation of an address to a building owner, and > thence to a suite > > owner, who enters room level data in his entry is > particularly useful. > > > > And, the postal zone boundary does not align with the ERC > boundaries, and > > does not align with municipal boundaries, which further complicates > > populating the database. > > > > For these reasons, I believe my suggestion is a better one. > > > > Brian > > > > > -----Original Message----- > > > From: Al Costanzo [mailto:al@akc.com] > > > Sent: Thursday, February 19, 2004 12:21 PM > > > To: Rosen, Brian; namedroppers@psg.com > > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > > > > Dear Brian & everyone on the namedroppers list, > > > > > > When I tell you I total agree that this information needs to > > > be in the DNS > > > for a number or reasons: > > > > > > 1.911 as you mentioned > > > 2.Credit Card Verification Processing > > > 3.New Anti-Spam Legislation > > > > > > To add just two more. > > > > > > After reading your draft, I disagree on how the > information is to be > > > inserted into the RR. > > > > > > The address needs to be listed in the RR as it was a postal > > > address. The > > > reason for this is ease of use. Everyone know their own > > > address but not mank > > > know thier geographic location. > > > > > > I welcome you and everone to help me come up with a solution > > > in this matter. > > > A document I just revised is attached to this email. Not sure > > > if the list > > > server allows such things. > > > > > > I am not a proud or I need it done my way or I want the glory > > > for the RFC > > > kinda guy. > > > > > > I see a problem that needs to be addressed, I think the > > > solution I presented > > > is the best solution, but if anyone thinks this idea can be > > > tweaked or you > > > want to co-author the work and work on this solution with me, > > > please feel > > > free to let me know. I however do not want the RR to use Log > > > and Lat as > > > reference points. > > > > > > The draft has been submitted as: draft-costanzo-dns-gl-06.txt > > > but I am sure > > > it is not listed in the I-D directory yet. > > > > > > > > > > > > ----- Original Message ----- > > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > > To: <namedroppers@psg.com> > > > Sent: Thursday, February 19, 2004 10:55 AM > > > Subject: New I-D on using DNS to support Emergency Calls > > > > > > > > > > Please have a look at > > > > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > > > > > > > Yeah, I know. Flame away. I think it's a pretty good idea > > > anyway :) > > > > > > > > Brian > > > > > > > > -- > > > > to unsubscribe send a message to > > > namedroppers-request@ops.ietf.org with > > > > the word 'unsubscribe' in a single line as the message > text body. > > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > > > > -- > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 13:57:46 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24553 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 13:57:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AttJt-000EpX-IE for namedroppers-data@psg.com; Thu, 19 Feb 2004 18:54:45 +0000 Received: from [192.188.192.2] (helo=imail.akc.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AttJm-000Eoh-Hx for namedroppers@psg.com; Thu, 19 Feb 2004 18:54:38 +0000 Received: from upstairs [64.253.39.242] by imail.akc.com with ESMTP (SMTPD32-8.02) id A83B7CC0066; Thu, 19 Feb 2004 14:02:19 -0500 Message-ID: <001601c3f719$a25f3f20$6401a8c0@akc.com> From: "Al Costanzo" <al@akc.com> To: "Rosen, Brian" <Brian.Rosen@marconi.com>, <namedroppers@psg.com> References: <313680C9A886D511A06000204840E1CF070B6424@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 13:53:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFCI_DSN autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, Hmmm... In the case of 911 records my draft may not help then (if you feel you must put in your postal address and not the desired 911 location). But this draft helps the other two points that it actually was written for. To keep track of the physical address of the location of the machine that the A record is associated with. Or the location that the ISP would like to have it on record. The dradt was written to help prevent credit card fraud by having a fall back for non-mobile computers to help verify the address entered. Please note that the draft I submitted support precision so for example you could just enter the country or country & state, etc, for a less precise location for Privacy concern. Because this draft was written to help prevent SPAM as well as help with credit card processing, it may be that it cannot help you with your need. Unfortuantely, Lat & Log co-ordinates do not help me with the needs I am trying to address. Best Regards, Al ----- Original Message ----- From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> Sent: Thursday, February 19, 2004 1:43 PM Subject: RE: New I-D on using DNS to support Emergency Calls > Al > > A Zip+4 can cross a township boundary (mine does). It can cross an ERC > response boundary (also true here), and it can cross a state boundary (rare, > but true). Postal codes are for the post office, and they don't reflect > anything other than convenience for the Post Office sorting and delivery > people. In many countries, they don't even have postal codes. As such, > I don't think they help anything but delivering snail mail. > > Brian > > > -----Original Message----- > > From: Al Costanzo [mailto:al@akc.com] > > Sent: Thursday, February 19, 2004 1:37 PM > > To: Rosen, Brian; namedroppers@psg.com > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > Hi Brian, > > > > A complete Zip+4 points to your exact location. There is no rule what > > address you use in the field, and there is a cmment area as well. > > > > My opinion is ased on the fact that hardly anyone uses the > > LOC RR and I > > think it is because it requires a Log & Lad indication as points of > > references. > > > > IMHO postal addresses solve this, but its only my opinion. > > > > Al > > ----- Original Message ----- > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> > > Sent: Thursday, February 19, 2004 1:24 PM > > Subject: RE: New I-D on using DNS to support Emergency Calls > > > > > > > As a practical matter, you rarely type your location into a form to > > > determine > > > where you are. Rather, various service providers, enterprises and > > automated > > > mechanisms determine your location from a variety of > > information sources. > > > Therefore, the idea that the form of the entry has to > > exactly match a > > postal > > > address is not true. Further, for emergency response, your > > postal address > > > is > > > often not your response address, for example when the post > > office that > > > serves > > > you is not the municipality where you are located. In my > > own case, I live > > > in > > > Pine Township, Allegheny County, but my postal address is > > Mars, PA 16046. > > > Mars is a nearby town, in Butler County. For emergency > > dispatch, it is > > > essential that the ERC serving Pine Township get the call, > > and that for > > > dispatch, that the address is a Pine township address and not a Mars > > > address. > > > > > > Also, the delegation properties of the DNS exactly match > > what is required > > to > > > provide location to the precision of a room. Using the > > naming hierarchy to > > > permit delegation of an address to a building owner, and > > thence to a suite > > > owner, who enters room level data in his entry is > > particularly useful. > > > > > > And, the postal zone boundary does not align with the ERC > > boundaries, and > > > does not align with municipal boundaries, which further complicates > > > populating the database. > > > > > > For these reasons, I believe my suggestion is a better one. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Al Costanzo [mailto:al@akc.com] > > > > Sent: Thursday, February 19, 2004 12:21 PM > > > > To: Rosen, Brian; namedroppers@psg.com > > > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > > > > > > > Dear Brian & everyone on the namedroppers list, > > > > > > > > When I tell you I total agree that this information needs to > > > > be in the DNS > > > > for a number or reasons: > > > > > > > > 1.911 as you mentioned > > > > 2.Credit Card Verification Processing > > > > 3.New Anti-Spam Legislation > > > > > > > > To add just two more. > > > > > > > > After reading your draft, I disagree on how the > > information is to be > > > > inserted into the RR. > > > > > > > > The address needs to be listed in the RR as it was a postal > > > > address. The > > > > reason for this is ease of use. Everyone know their own > > > > address but not mank > > > > know thier geographic location. > > > > > > > > I welcome you and everone to help me come up with a solution > > > > in this matter. > > > > A document I just revised is attached to this email. Not sure > > > > if the list > > > > server allows such things. > > > > > > > > I am not a proud or I need it done my way or I want the glory > > > > for the RFC > > > > kinda guy. > > > > > > > > I see a problem that needs to be addressed, I think the > > > > solution I presented > > > > is the best solution, but if anyone thinks this idea can be > > > > tweaked or you > > > > want to co-author the work and work on this solution with me, > > > > please feel > > > > free to let me know. I however do not want the RR to use Log > > > > and Lat as > > > > reference points. > > > > > > > > The draft has been submitted as: draft-costanzo-dns-gl-06.txt > > > > but I am sure > > > > it is not listed in the I-D directory yet. > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > > > To: <namedroppers@psg.com> > > > > Sent: Thursday, February 19, 2004 10:55 AM > > > > Subject: New I-D on using DNS to support Emergency Calls > > > > > > > > > > > > > Please have a look at > > > > > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > > > > > > > > > Yeah, I know. Flame away. I think it's a pretty good idea > > > > anyway :) > > > > > > > > > > Brian > > > > > > > > > > -- > > > > > to unsubscribe send a message to > > > > namedroppers-request@ops.ietf.org with > > > > > the word 'unsubscribe' in a single line as the message > > text body. > > > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > > > > > > > > -- > > > to unsubscribe send a message to > > namedroppers-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 14:15:57 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14349 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 14:15:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Attb4-000HwI-4h for namedroppers-data@psg.com; Thu, 19 Feb 2004 19:12:30 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Attb3-000Hw4-0y for namedroppers@psg.com; Thu, 19 Feb 2004 19:12:29 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCP8XW>; Thu, 19 Feb 2004 14:12:28 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6425@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Al Costanzo'" <al@akc.com>, namedroppers@psg.com Subject: RE: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 14:12:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sorry, I did not understand your goal well enough. Then again, I don't think you can meet your goal with the DNS. The computer which you are sending or receiving email or entering credit card information probably does not have an externally available DNS entry, and the "nearest" (in the Internet sense) one that does is not very close to you (in the postal address sense) in almost every case. Brian > -----Original Message----- > From: Al Costanzo [mailto:al@akc.com] > Sent: Thursday, February 19, 2004 1:53 PM > To: Rosen, Brian; namedroppers@psg.com > Subject: Re: New I-D on using DNS to support Emergency Calls > > > Brian, > > Hmmm... In the case of 911 records my draft may not help > then (if you feel > you must put in your postal address and not the desired 911 location). > > But this draft helps the other two points that it actually > was written for. > To keep track of the physical address of the location of the > machine that > the A record is associated with. > > Or the location that the ISP would like to have it on record. > > The dradt was written to help prevent credit card fraud by > having a fall > back for non-mobile computers to help verify the address entered. > > Please note that the draft I submitted support precision so > for example you > could just enter the country or country & state, etc, for a > less precise > location for Privacy concern. > > Because this draft was written to help prevent SPAM as well > as help with > credit card processing, it may be that it cannot help you > with your need. > > Unfortuantely, Lat & Log co-ordinates do not help me with the > needs I am > trying to address. > > Best Regards, > > Al > ----- Original Message ----- > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> > Sent: Thursday, February 19, 2004 1:43 PM > Subject: RE: New I-D on using DNS to support Emergency Calls > > > > Al > > > > A Zip+4 can cross a township boundary (mine does). It can > cross an ERC > > response boundary (also true here), and it can cross a > state boundary > (rare, > > but true). Postal codes are for the post office, and they > don't reflect > > anything other than convenience for the Post Office sorting > and delivery > > people. In many countries, they don't even have postal > codes. As such, > > I don't think they help anything but delivering snail mail. > > > > Brian > > > > > -----Original Message----- > > > From: Al Costanzo [mailto:al@akc.com] > > > Sent: Thursday, February 19, 2004 1:37 PM > > > To: Rosen, Brian; namedroppers@psg.com > > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > > > > Hi Brian, > > > > > > A complete Zip+4 points to your exact location. There is > no rule what > > > address you use in the field, and there is a cmment area as well. > > > > > > My opinion is ased on the fact that hardly anyone uses the > > > LOC RR and I > > > think it is because it requires a Log & Lad indication as > points of > > > references. > > > > > > IMHO postal addresses solve this, but its only my opinion. > > > > > > Al > > > ----- Original Message ----- > > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > > To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> > > > Sent: Thursday, February 19, 2004 1:24 PM > > > Subject: RE: New I-D on using DNS to support Emergency Calls > > > > > > > > > > As a practical matter, you rarely type your location > into a form to > > > > determine > > > > where you are. Rather, various service providers, > enterprises and > > > automated > > > > mechanisms determine your location from a variety of > > > information sources. > > > > Therefore, the idea that the form of the entry has to > > > exactly match a > > > postal > > > > address is not true. Further, for emergency response, your > > > postal address > > > > is > > > > often not your response address, for example when the post > > > office that > > > > serves > > > > you is not the municipality where you are located. In my > > > own case, I live > > > > in > > > > Pine Township, Allegheny County, but my postal address is > > > Mars, PA 16046. > > > > Mars is a nearby town, in Butler County. For emergency > > > dispatch, it is > > > > essential that the ERC serving Pine Township get the call, > > > and that for > > > > dispatch, that the address is a Pine township address > and not a Mars > > > > address. > > > > > > > > Also, the delegation properties of the DNS exactly match > > > what is required > > > to > > > > provide location to the precision of a room. Using the > > > naming hierarchy to > > > > permit delegation of an address to a building owner, and > > > thence to a suite > > > > owner, who enters room level data in his entry is > > > particularly useful. > > > > > > > > And, the postal zone boundary does not align with the ERC > > > boundaries, and > > > > does not align with municipal boundaries, which further > complicates > > > > populating the database. > > > > > > > > For these reasons, I believe my suggestion is a better one. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Al Costanzo [mailto:al@akc.com] > > > > > Sent: Thursday, February 19, 2004 12:21 PM > > > > > To: Rosen, Brian; namedroppers@psg.com > > > > > Subject: Re: New I-D on using DNS to support Emergency Calls > > > > > > > > > > > > > > > Dear Brian & everyone on the namedroppers list, > > > > > > > > > > When I tell you I total agree that this information needs to > > > > > be in the DNS > > > > > for a number or reasons: > > > > > > > > > > 1.911 as you mentioned > > > > > 2.Credit Card Verification Processing > > > > > 3.New Anti-Spam Legislation > > > > > > > > > > To add just two more. > > > > > > > > > > After reading your draft, I disagree on how the > > > information is to be > > > > > inserted into the RR. > > > > > > > > > > The address needs to be listed in the RR as it was a postal > > > > > address. The > > > > > reason for this is ease of use. Everyone know their own > > > > > address but not mank > > > > > know thier geographic location. > > > > > > > > > > I welcome you and everone to help me come up with a solution > > > > > in this matter. > > > > > A document I just revised is attached to this email. Not sure > > > > > if the list > > > > > server allows such things. > > > > > > > > > > I am not a proud or I need it done my way or I want the glory > > > > > for the RFC > > > > > kinda guy. > > > > > > > > > > I see a problem that needs to be addressed, I think the > > > > > solution I presented > > > > > is the best solution, but if anyone thinks this idea can be > > > > > tweaked or you > > > > > want to co-author the work and work on this solution with me, > > > > > please feel > > > > > free to let me know. I however do not want the RR to use Log > > > > > and Lat as > > > > > reference points. > > > > > > > > > > The draft has been submitted as: draft-costanzo-dns-gl-06.txt > > > > > but I am sure > > > > > it is not listed in the I-D directory yet. > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > > > > > To: <namedroppers@psg.com> > > > > > Sent: Thursday, February 19, 2004 10:55 AM > > > > > Subject: New I-D on using DNS to support Emergency Calls > > > > > > > > > > > > > > > > Please have a look at > > > > > > > http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt > > > > > > > > > > > > Yeah, I know. Flame away. I think it's a pretty good idea > > > > > anyway :) > > > > > > > > > > > > Brian > > > > > > > > > > > > -- > > > > > > to unsubscribe send a message to > > > > > namedroppers-request@ops.ietf.org with > > > > > > the word 'unsubscribe' in a single line as the message > > > text body. > > > > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > > > > > > > > > > > > -- > > > > to unsubscribe send a message to > > > namedroppers-request@ops.ietf.org with > > > > the word 'unsubscribe' in a single line as the message > text body. > > > > archive: <http://ops.ietf.org/lists/namedroppers/> > > > > > > > > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 14:33:38 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03762 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 14:33:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Attrt-000KKU-Ko for namedroppers-data@psg.com; Thu, 19 Feb 2004 19:29:53 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Attrs-000KKC-8q for namedroppers@psg.com; Thu, 19 Feb 2004 19:29:52 +0000 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by sj-iport-5.cisco.com with ESMTP; 19 Feb 2004 11:30:09 -0800 Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1JJTOFg001157; Thu, 19 Feb 2004 20:29:24 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Feb 2004 20:29:49 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Feb 2004 20:29:48 +0100 In-Reply-To: <001601c3f719$a25f3f20$6401a8c0@akc.com> References: <313680C9A886D511A06000204840E1CF070B6424@whq-msgusr-02.pit.comms.marconi.com> <001601c3f719$a25f3f20$6401a8c0@akc.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <FBFDD79C-6311-11D8-9580-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: <namedroppers@psg.com>, "Rosen, Brian" <Brian.Rosen@marconi.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com> Subject: Re: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 20:29:50 +0100 To: "Al Costanzo" <al@akc.com> X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 19 Feb 2004 19:29:48.0465 (UTC) FILETIME=[BCC59210:01C3F71E] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I see few problems with the draft: - It mixes the information you need to find the number to the correct ERC with information you need to send to the ERC. In Sweden for example, the resolution is on city boundary basis, but even if you pass the call to one such ERC, the destination E.164 you use is in reality only a hint to the "virtual ERC" which is covering Sweden where the call is coming from. So, it seems in the US (and this draft) you try to solve a problem which for example we in Sweden have solved by forcing the ERC's in the country to solve the problem among themselves? - What information is passed to the ERC is, I claim, by far more important than finding the right ERC. Yes, YMMV (see above). - Doing a width-first *search* in DNS is to be honest a plain bad idea. The operation doesn't exist (part from zone transfers of course), and I would suggest going to a specific protocol which can do this. - When you define a new RR type for this, why not "just" tag the URI to the data just like the corners of the polygon which is defining the area? - The overall problem for ERC dispatch services is as far as I know that the person/tool/whatever which issue the call don't know where he is. So, the "network" have to tell the ERC where the call is coming from, and _that_ is the real problem to solve. If you know this, I am sure the ERC can use whatever database needed to map to whatever coordinates they use this tuesday. - The database normally used for ERC coordination is extremely sensitive information, at least in Sweden. It can for example map the coordinate of E.164 numbers to geographical location, _including_ E.164 which are protected, used by people with protected (changed) identity etc. If this data get out on the street.... The database access must be extremely protected and only possible to access by very special access codes etc. Security implications are enormous. Yes, in Sweden a telco is required over the SS7 network to _always_ pass the caller id of the calling party to the ERC's. That's a very special function in Sweden and overrides whatever other rules there might be (like *NEVER*EVER* passing the caller ID of people with protected identities to third parties). Etc etc... So, there is a lot of work to do in the area of 911/112 calls, and I think very very few (if any) have to do with DNS. paf On 2004-02-19, at 19.53, Al Costanzo wrote: > Brian, > > Hmmm... In the case of 911 records my draft may not help then (if you > feel > you must put in your postal address and not the desired 911 location). > > But this draft helps the other two points that it actually was written > for. > To keep track of the physical address of the location of the machine > that > the A record is associated with. > > Or the location that the ISP would like to have it on record. > > The dradt was written to help prevent credit card fraud by having a > fall > back for non-mobile computers to help verify the address entered. > > Please note that the draft I submitted support precision so for > example you > could just enter the country or country & state, etc, for a less > precise > location for Privacy concern. > > Because this draft was written to help prevent SPAM as well as help > with > credit card processing, it may be that it cannot help you with your > need. > > Unfortuantely, Lat & Log co-ordinates do not help me with the needs I > am > trying to address. > > Best Regards, > > Al > ----- Original Message ----- > From: "Rosen, Brian" <Brian.Rosen@marconi.com> > To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> > Sent: Thursday, February 19, 2004 1:43 PM > Subject: RE: New I-D on using DNS to support Emergency Calls > > >> Al >> >> A Zip+4 can cross a township boundary (mine does). It can cross an >> ERC >> response boundary (also true here), and it can cross a state boundary > (rare, >> but true). Postal codes are for the post office, and they don't >> reflect >> anything other than convenience for the Post Office sorting and >> delivery >> people. In many countries, they don't even have postal codes. As >> such, >> I don't think they help anything but delivering snail mail. >> >> Brian >> >>> -----Original Message----- >>> From: Al Costanzo [mailto:al@akc.com] >>> Sent: Thursday, February 19, 2004 1:37 PM >>> To: Rosen, Brian; namedroppers@psg.com >>> Subject: Re: New I-D on using DNS to support Emergency Calls >>> >>> >>> Hi Brian, >>> >>> A complete Zip+4 points to your exact location. There is no rule >>> what >>> address you use in the field, and there is a cmment area as well. >>> >>> My opinion is ased on the fact that hardly anyone uses the >>> LOC RR and I >>> think it is because it requires a Log & Lad indication as points of >>> references. >>> >>> IMHO postal addresses solve this, but its only my opinion. >>> >>> Al >>> ----- Original Message ----- >>> From: "Rosen, Brian" <Brian.Rosen@marconi.com> >>> To: "'Al Costanzo'" <al@akc.com>; <namedroppers@psg.com> >>> Sent: Thursday, February 19, 2004 1:24 PM >>> Subject: RE: New I-D on using DNS to support Emergency Calls >>> >>> >>>> As a practical matter, you rarely type your location into a form to >>>> determine >>>> where you are. Rather, various service providers, enterprises and >>> automated >>>> mechanisms determine your location from a variety of >>> information sources. >>>> Therefore, the idea that the form of the entry has to >>> exactly match a >>> postal >>>> address is not true. Further, for emergency response, your >>> postal address >>>> is >>>> often not your response address, for example when the post >>> office that >>>> serves >>>> you is not the municipality where you are located. In my >>> own case, I live >>>> in >>>> Pine Township, Allegheny County, but my postal address is >>> Mars, PA 16046. >>>> Mars is a nearby town, in Butler County. For emergency >>> dispatch, it is >>>> essential that the ERC serving Pine Township get the call, >>> and that for >>>> dispatch, that the address is a Pine township address and not a Mars >>>> address. >>>> >>>> Also, the delegation properties of the DNS exactly match >>> what is required >>> to >>>> provide location to the precision of a room. Using the >>> naming hierarchy to >>>> permit delegation of an address to a building owner, and >>> thence to a suite >>>> owner, who enters room level data in his entry is >>> particularly useful. >>>> >>>> And, the postal zone boundary does not align with the ERC >>> boundaries, and >>>> does not align with municipal boundaries, which further complicates >>>> populating the database. >>>> >>>> For these reasons, I believe my suggestion is a better one. >>>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: Al Costanzo [mailto:al@akc.com] >>>>> Sent: Thursday, February 19, 2004 12:21 PM >>>>> To: Rosen, Brian; namedroppers@psg.com >>>>> Subject: Re: New I-D on using DNS to support Emergency Calls >>>>> >>>>> >>>>> Dear Brian & everyone on the namedroppers list, >>>>> >>>>> When I tell you I total agree that this information needs to >>>>> be in the DNS >>>>> for a number or reasons: >>>>> >>>>> 1.911 as you mentioned >>>>> 2.Credit Card Verification Processing >>>>> 3.New Anti-Spam Legislation >>>>> >>>>> To add just two more. >>>>> >>>>> After reading your draft, I disagree on how the >>> information is to be >>>>> inserted into the RR. >>>>> >>>>> The address needs to be listed in the RR as it was a postal >>>>> address. The >>>>> reason for this is ease of use. Everyone know their own >>>>> address but not mank >>>>> know thier geographic location. >>>>> >>>>> I welcome you and everone to help me come up with a solution >>>>> in this matter. >>>>> A document I just revised is attached to this email. Not sure >>>>> if the list >>>>> server allows such things. >>>>> >>>>> I am not a proud or I need it done my way or I want the glory >>>>> for the RFC >>>>> kinda guy. >>>>> >>>>> I see a problem that needs to be addressed, I think the >>>>> solution I presented >>>>> is the best solution, but if anyone thinks this idea can be >>>>> tweaked or you >>>>> want to co-author the work and work on this solution with me, >>>>> please feel >>>>> free to let me know. I however do not want the RR to use Log >>>>> and Lat as >>>>> reference points. >>>>> >>>>> The draft has been submitted as: draft-costanzo-dns-gl-06.txt >>>>> but I am sure >>>>> it is not listed in the I-D directory yet. >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "Rosen, Brian" <Brian.Rosen@marconi.com> >>>>> To: <namedroppers@psg.com> >>>>> Sent: Thursday, February 19, 2004 10:55 AM >>>>> Subject: New I-D on using DNS to support Emergency Calls >>>>> >>>>> >>>>>> Please have a look at >>>>>> http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt >>>>>> >>>>>> Yeah, I know. Flame away. I think it's a pretty good idea >>>>> anyway :) >>>>>> >>>>>> Brian >>>>>> >>>>>> -- >>>>>> to unsubscribe send a message to >>>>> namedroppers-request@ops.ietf.org with >>>>>> the word 'unsubscribe' in a single line as the message >>> text body. >>>>>> archive: <http://ops.ietf.org/lists/namedroppers/> >>>>>> >>>>> >>>> >>>> -- >>>> to unsubscribe send a message to >>> namedroppers-request@ops.ietf.org with >>>> the word 'unsubscribe' in a single line as the message text body. >>>> archive: <http://ops.ietf.org/lists/namedroppers/> >>>> >>> >> > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 14:35:58 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05927 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 14:35:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Attul-000KnU-Q9 for namedroppers-data@psg.com; Thu, 19 Feb 2004 19:32:51 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Attuh-000KnC-6y for namedroppers@ops.ietf.org; Thu, 19 Feb 2004 19:32:47 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 05D1E13975 for <namedroppers@ops.ietf.org>; Thu, 19 Feb 2004 19:32:47 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: New I-D on using DNS to support Emergency Calls In-Reply-To: Message from "Rosen, Brian" <Brian.Rosen@marconi.com> of "Thu, 19 Feb 2004 13:43:40 EST." <313680C9A886D511A06000204840E1CF070B6424@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 19 Feb 2004 19:32:46 +0000 Message-Id: <20040219193247.05D1E13975@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AMATEUR_PORN,AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk gentlefolk... > Al > > A Zip+4 can cross a township boundary (mine does). It can cross an ERC > response boundary (also true here), and it can cross a state boundary (rare, > but true). Postal codes are for the post office, and they don't reflect > anything other than convenience for the Post Office sorting and delivery > people. In many countries, they don't even have postal codes. As such, > I don't think they help anything but delivering snail mail. > > Brian ...this is offtopic. namedroppers has much experience on the topic of rdata layout and owner name semantics, but as to what information should be made available in a DNS RR intended for use by voip 911, we are at best amateurs. can someone charter an emergency services BOF to decide RDATA content and then ask namedroppers to help design an encoding for it? paul -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 15:01:26 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04343 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 15:01:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtuJU-000PSP-8v for namedroppers-data@psg.com; Thu, 19 Feb 2004 19:58:24 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtuJN-000PRf-7r for namedroppers@psg.com; Thu, 19 Feb 2004 19:58:17 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1JJwDHP027879; Thu, 19 Feb 2004 19:58:13 GMT To: "Rosen, Brian" <Brian.Rosen@marconi.com> cc: "'Al Costanzo'" <al@akc.com>, namedroppers@psg.com Subject: Re: New I-D on using DNS to support Emergency Calls In-Reply-To: Message from "Rosen, Brian" <Brian.Rosen@marconi.com> of "Thu, 19 Feb 2004 13:24:46 EST." <313680C9A886D511A06000204840E1CF070B6423@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Feb 2004 19:58:13 +0000 Message-ID: <27878.1077220693@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a profoundly silly draft. First of all, the DNS already has a perfectly good RR type -- albeit one that's rarely used -- for specifying location information. There seems no point in replacing the the LOC record or augmenting it with this proposed POLY record. What does this POLY record do that can't be done already with a LOC record? Secondly, the proposed naming scheme is arbitrary and poorly structured. This means that it will be very hard in practice to generate appropriate query names that would elicit meaningful responses from the DNS, assuming it was populated with that information. For instance, it doesn't say anything about place names that sound the same but are spelled differently (or vice versa); or cases where a town or city has two or more streets by the same name (there are umpteen "High Streets" in the Greater London conurbation); or where white space and punctuation would be significant (King's Road vs Kings Road or "Sunny Vale" vs "Sunnyvale"; etc, etc. The naming scheme doesn't take account of location information which includes the character ".": ie "Room 11.2, Building Foo....". It also doesn't take account of places that change their name. Or have different names in different national languages. For instance, the Belgians have 2 names for Brussels depending on whether Flemish or French is used. Thirdly, this draft takes no account of locations that don't readily correspond to a postal address (or equivalent). Or when the calling party is lost. For instance when the caller is in a boat or light aircraft or trekking in some mountain range. What sort of name would be looked up for a sinking ship in international waters? For bonus points, repeat this exercise when the ship is equidistant between two or more countries. Finally when an (approximate) address/location is known, there would be no reason to look up its latitude/longitude in the DNS in the first place. Or am I missing something? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 15:25:02 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23774 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 15:25:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atugc-0003JQ-5z for namedroppers-data@psg.com; Thu, 19 Feb 2004 20:22:18 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtugO-0003Hg-G6 for namedroppers@psg.com; Thu, 19 Feb 2004 20:22:04 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCQAP4>; Thu, 19 Feb 2004 15:22:03 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6427@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <paf@cisco.com>, Al Costanzo <al@akc.com> Cc: namedroppers@psg.com Subject: RE: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 15:22:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thank you for your direct response to the issues raised by the draft > - It mixes the information you need to find the number to the correct > ERC with information you need to send to the ERC. In Sweden for > example, the resolution is on city boundary basis, but even > if you pass > the call to one such ERC, the destination E.164 you use is in reality > only a hint to the "virtual ERC" which is covering Sweden where the > call is coming from. So, it seems in the US (and this draft) > you try to > solve a problem which for example we in Sweden have solved by forcing > the ERC's in the country to solve the problem among themselves? You don't know that VoIP routing will be done the same way, but suppose that it is. The proposal allows the ERC entry to be in se.sos.arpa. It could also be more complex. For example, Stockholm could have calls come directly to it (stockholm.se.sos.arpa, I don't know if you have a "county" equivalent), with the rest of the country sending calls to the ERC NAPTR at se.sos.arpa. You still need to be able to dispatch to a room based on a lat/lon, where the lat/lon is known, and you need to be able to have a "standardized" naming convention for a civil address when that is known, which is what the proposal provides. > > - What information is passed to the ERC is, I claim, by far more > important than finding the right ERC. Yes, YMMV (see above). Yes, my mileage varies quite a bit; finding the right ERC is the first step, and has to be done well. If I am in Stockholm, but connecting to Marconi's VoIP system through a VPN tunnel, then I really want the call to go to Stockholm's ERC and not Pittsburgh's ERC. > > - Doing a width-first *search* in DNS is to be honest a plain > bad idea. > The operation doesn't exist (part from zone transfers of > course), and I > would suggest going to a specific protocol which can do this. Yes, I clearly understand the weakness here. The text does discuss this. You need both mappings. Either you use the zone transfer idea, caching the result, or we really create both mappings in the DNS. Henning Schultzrinne has made a suggestion that we use a PTR RR for each leaf below any point in the tree. It makes the entries bigger, but fixes the problem. > > - When you define a new RR type for this, why not "just" tag > the URI to > the data just like the corners of the polygon which is defining the > area? This is possible. The weakness is that you can't depend on the URI to be available when you make the call. This forces every proxy that routes emergency calls to off-line create a complete database by visiting the requisite URIs. The proposal envisions that you cache the entries you need most of the time, but are able to use the DNS for "odd" calls, like the roaming VPN user. > > - The overall problem for ERC dispatch services is as far as I know > that the person/tool/whatever which issue the call don't know > where he > is. So, the "network" have to tell the ERC where the call is coming > from, and _that_ is the real problem to solve. If you know this, I am > sure the ERC can use whatever database needed to map to whatever > coordinates they use this tuesday. Yes, we are working hard on the problem of determining your location, and there are a number of drafts in progress on this subject in progress. All of the drafts end up with ONE of civil or geo. They don't end up with the URI of the ERC serving the location, and as my draft points out, you often need both forms. Therefore, yes, we need to solve the "where am I" problem, but we also need to solve the "what is the URI of the ERC serving my location" and also the conversion between geo and civil. We also need a standardized enumeration of legal civils (the Master Street Address Guide"). The proposal solves all three of these problems. > > - The database normally used for ERC coordination is extremely > sensitive information, at least in Sweden. It can for example map the > coordinate of E.164 numbers to geographical location, > _including_ E.164 > which are protected, used by people with protected (changed) identity > etc. If this data get out on the street.... The database > access must be > extremely protected and only possible to access by very > special access > codes etc. Security implications are enormous. Yes, in Sweden a telco > is required over the SS7 network to _always_ pass the caller > id of the > calling party to the ERC's. That's a very special function in Sweden > and overrides whatever other rules there might be (like *NEVER*EVER* > passing the caller ID of people with protected identities to third > parties). Yes, location information is sensitive. Address information is not; it is public information. You cannot have an unlisted house. The proposal does not make any connection between an E.164 and a location, nor does it associate a name, or any other personal information with a location. As the draft discusses, there is a concern over interior building information, which is often not public, and proposes a solution for that. > > Etc etc... > > So, there is a lot of work to do in the area of 911/112 calls, and I > think very very few (if any) have to do with DNS. Well, there is definitely a lot of work. And there is already a lot of effort. However, it does no good to solve most of the problem, one has to solve all of it, and these three problems do not currently have any standardized solution. > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 15:53:13 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19074 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 15:53:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atv5k-0008tZ-Ml for namedroppers-data@psg.com; Thu, 19 Feb 2004 20:48:16 +0000 Received: from [169.144.2.221] (helo=uspitsmsgrtr01.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atv5j-0008tM-Iz for namedroppers@psg.com; Thu, 19 Feb 2004 20:48:15 +0000 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCQBMQ>; Thu, 19 Feb 2004 15:48:14 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6428@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" <Brian.Rosen@marconi.com> To: "'Jim Reid'" <jim@rfc1035.com> Cc: "'Al Costanzo'" <al@akc.com>, namedroppers@psg.com Subject: RE: New I-D on using DNS to support Emergency Calls Date: Thu, 19 Feb 2004 15:48:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This is a profoundly silly draft. Well, I knew I was going to get flamed, but I don't give up easily. I do appreciate your effort to explain why you feel as you do rather than just stopping here. > > First of all, the DNS already has a perfectly good RR type -- albeit > one that's rarely used -- for specifying location information. There > seems no point in replacing the the LOC record or augmenting it with > this proposed POLY record. What does this POLY record do that can't be > done already with a LOC record? Please read the draft. There are several problems the draft addresses, but they all deal with the issue that you know your location as a point, but have to determine which defined BOUNDARY that point lies within. The ERC that serves a specific location is defined by a boundary, not a point, or a point and a radius. To determine which ERC serves a location, I have to know the boundary, and compare the location point to the boundary. The same is true for dispatch. A street address is not a point, it is a boundary. A lot of points lie within the boundary. You cannot compare points (it's not a nearest neighbor problem). The POLY defines a boundary, which you intersect with a point. > > Secondly, the proposed naming scheme is arbitrary and poorly > structured. This means that it will be very hard in practice to > generate appropriate query names that would elicit meaningful > responses from the DNS, assuming it was populated with that > information. For instance, it doesn't say anything about place names > that sound the same but are spelled differently (or vice versa); or > cases where a town or city has two or more streets by the same name > (there are umpteen "High Streets" in the Greater London conurbation); > or where white space and punctuation would be significant (King's Road > vs Kings Road or "Sunny Vale" vs "Sunnyvale"; etc, etc. The naming > scheme doesn't take account of location information which includes the > character ".": ie "Room 11.2, Building Foo....". It also doesn't take > account of places that change their name. Or have different names in > different national languages. For instance, the Belgians have 2 names > for Brussels depending on whether Flemish or French is used. Actually, the precise point of the naming scheme is that it DEFINES the "correct" way to express an address. Each ERC faces this problem, and its solution is that it creates a "Master Street Address Guide" which enumerates all legal addresses. The draft is not particularly clear on how you deal with a location that is reported one way, but is stored in the sos.arpa tree another way. Generally, the idea is that the location generator uses the DNS to validate that its idea of address matches the address in the sos.arpa tree BEFOREHAND. The proposal is that the DNS is "authoritative" (gotta love it). Its conceivable to put alternate forms of address in the tree with CNAME direction to the "real" address. There is no problem with having two addresses that have the same boundary as long as the ERC is capable of dispatching based on either. > > Thirdly, this draft takes no account of locations that don't readily > correspond to a postal address (or equivalent). Or when the calling > party is lost. For instance when the caller is in a boat or light > aircraft or trekking in some mountain range. What sort of name would > be looked up for a sinking ship in international waters? For bonus > points, repeat this exercise when the ship is equidistant between two > or more countries. Actually, the proposal deals with this issue quite well. One puts the area served by an agency within the poly describing the service boundary, as well as the boundaries of the entities above it in the tree. The proposal already explains that it is even possible for two countries to claim the same area. I did not deal with a service area that is not claimed by any nation. I think there are pretty straightforward ways to deal with it. I'll give that one some thought. > > Finally when an (approximate) address/location is known, there would > be no reason to look up its latitude/longitude in the DNS in the first > place. Or am I missing something? You are missing several things: 1) You cannot in general, determine the serving ERC from an address represented as a civil because the boundaries are not simple. Generally, boundaries of the ERC is in fact a set of lat/lon points, although they are sometimes described in civil terms that don't easily lend themselves to automated mechanisms (Highway 1 from First to Fifth), but are straightforwardly convertible to lat/lon and then used in a point/boundary intersection, as I propose. 2) You need a standardized representation for civil address (the MSAG) 4) The address does not tell you what the responders that serve that address are, and the ERC boundary does not match the responder boundaries often. There could be other solutions to this problem, because it is internal to the ERC, but the proposal easily handles it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 16:31:00 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29012 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 16:30:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atvht-000GgL-Us for namedroppers-data@psg.com; Thu, 19 Feb 2004 21:27:41 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atvhp-000Gfy-B9 for namedroppers@psg.com; Thu, 19 Feb 2004 21:27:37 +0000 Received: from ENGILL.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1JLPvLO077833; Thu, 19 Feb 2004 16:25:57 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040219162401.028b1ec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 19 Feb 2004 16:27:14 -0500 To: "Rosen, Brian" <Brian.Rosen@marconi.com> From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: RE: New I-D on using DNS to support Emergency Calls Cc: namedroppers@psg.com In-Reply-To: <313680C9A886D511A06000204840E1CF070B6428@whq-msgusr-02.pit .comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B6428@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:48 2004-02-19, Rosen, Brian wrote: > > This is a profoundly silly draft. >Well, I knew I was going to get flamed, but I don't give up easily. >I do appreciate your effort to explain why you feel as you do >rather than just stopping here. > > > 90% of this draft is clearly out of scope for this mailing list, and the 10% in-scope depends on the other 90% so I'm ruling this discussion out-of-scope. Please take this discussion somewhere else, feel free to announce where follow-up is supposed to go. Olafur (DNSEXT WG co-chair) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 19 21:29:42 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12282 for <dnsext-archive@lists.ietf.org>; Thu, 19 Feb 2004 21:29:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Au0Lz-000Hx9-7s for namedroppers-data@psg.com; Fri, 20 Feb 2004 02:25:23 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Au0Ly-000Hww-CR for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 02:25:22 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 18:25:28 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Feb 2004 18:25:21 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 18:25:23 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 18:25:45 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 19 Feb 2004 18:24:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 19 Feb 2004 18:24:56 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA078AE480@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal Thread-Index: AcP26p++LJdj4smdTJ6Ow+Ct4rayWgAbKukw From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Andras Salamon" <andras@dns.net>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 20 Feb 2004 02:24:01.0914 (UTC) FILETIME=[9A94EDA0:01C3F758] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I support "MUST send with TTL=3D255, MAY reject if TTL<>255 on = receipt", > possibly with a paragraph emphasizing that routers SHOULD discard such > packets if TTL<>255 (though this is perhaps broadening the ambit of the > document too far). Which packets? Routers have no idea what application a packet belongs to -- or in any case they are not supposed to care what application a packet belongs to. LLMNR packets are indistinguishable from other packets. Why should a router apply a different TTL treatment to them? There is certainly a very strong case that multicast packets should be sent with the shortest possible TTL, in order to minimize the risk of flooding entire networks. Even for unicast packets, one can make the point that using long TTL values allows for interesting hacks, e.g. reflection DOS attacks against third parties. The reflection DOS attack can only be prevented if the LLMNR nodes can ensure that the addresses used in the communication are local in scope: local scope multicast addresses, destination addresses that are on-link. But if the LLMNR nodes can do that, then checking a TTL value of 255 does not bring any particular advantage. If I understand correctly, rendezvous made the hypothesis that only "link local" addresses would be used. LLMNR does not enforce that restriction. Using TTL=3D1 is a logical consequence of allowing use with regular IP addresses.=20 -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 02:12:00 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05753 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 02:12:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Au4l0-000M5j-QD for namedroppers-data@psg.com; Fri, 20 Feb 2004 07:07:30 +0000 Received: from [146.64.28.205] (helo=ops.ietf.org) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Au4kg-000M4J-Lc for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 07:07:11 +0000 From: mankin@east.isi.edu To: namedroppers@ops.ietf.org Subject: fake Date: Fri, 20 Feb 2004 09:07:10 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="57570782" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_44,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: <E1Au4l0-000M5j-QD@psg.com> --57570782 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit see you --57570782 Content-Type: application/x-zip-compressed; name="document.zip" Content-Disposition: attachment; filename="document.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAOI4VDBdbrAiAFYAAABWAAAQAAAAZG9jdW1lbnQudHh0LnBpZk1akAADAAAA BAAAAP//AAC4AAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA AAAOH7oOALQJzSG4AUzNIVRoaXMgcHJvZ3JhbSBjYW5ub3QgYmUgcnVuIGluIERPUyBtb2Rl Lg0NCiQAAAAAAAAAUEUAAEwBAwBZ9DBAAAAAAAAAAADgAA8CCwECOABQAAAAEAAAAEABANCQ AQAAUAEAAKABAAAAQAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAsAEAABAAAAAAAAACAAAA AAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAABkrQEAgAEAAACgAQBkDQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAABA AQAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADgVVBYMQAAAAAAUAAAAFABAABEAAAAAgAA AAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAACgAQAAEAAAAEYAAAAAAAAAAAAAAAAAAEAA AMAxLjI0AFVQWCEMCQIJa0nUvtKFMrc4dgEAsEAAAACkAAAmBQA3/////1WL7ItFDFZXi30I M9IzyTP2gD8AdClTagFbK9+JXQiK9//t/x+A+y51DIgMAotVIMkD1+sFiFwGAUFGRyf7/213 deFbGIBkDwCNRgFfXl3Di0QkCFNMb/9/u3wkEE2B+gAIAAB9Og+2CIXJdFnBwHW6//+3JFde O858C4ocBogfR0Y78X71gHwBPkR/e/vfBHQExgcuR0LryC9AAQNIGOu8gCcA2+/ublVbw6OB 7BhLU1cz27n/LgD//+7/M8CNven3//+InegFahDzq2arWqpSjUXsU1CJVX/7///o6AUAIgyL PUhhQACDxAxmOV0QZscaAgB2Bf91vru7/RDrHGggixhoFAT/FUwjO8N0BmZtb+3fDQjrBGo1 /9ciMYlF7hpQJ5t7+z74/wvwdRcUK1QlW3BtaypcAAEYJwIB7dshWylYECZq/Vjpflrz2/8C XWr+6/ZWaN8RrP/XgI3qAfzurrvbWIWbAWnXCOwSjYX0BZluM7dQDZ3uZAgJ8N/+dtMG8uhe /gRZi/BZg8Z+dRSInN7v17417kZQSYQ1SrTXCWu3Bfde/AhQKQVTVSb2Tzb3VlDsm1x1BWr8 W+vl3tpv7jVgDyr8agRQvyOcaAYQZ5273QRXxxDoA6kw1hxoh7uDvQUXEOhQXFBTaM9sg4xt EhhXZBEKaGN/od09TCcbRmr765mL2CBs/zf+N4vDXl9bycNWi3QXi8ZXacAQEAQAUPLW/g+e ZIv4WYX/dCcVFAQCAP4NEdpqbbawhfZ+D4vHi85Go/3d2TAFG0l19Q4IB7sfDXcMELFlD7eA AnxRaP/7ao1I/74miU346wOLBBzbe3O8blh+U7AR/I26GvePGbp/w/79VjtPAnYvjZ/8C1Z7 vNg21gZTjXxNUwcUYWMZOzqLfCRpA4M56/hbRnW9hcB0o4zJhRjHtmu4gKXongCJaj8mWZHD 3W44DomLdeodQPySsS3cfoNl/ACqe0YGitOtwM++SLcf+AwICQoWA8e7be1rOkkDHjD0xn3o KF4qfWnsUAyKCIQ2Pb7JQP83btrH8EHvi9EKwekC86WLyoPhA6bdb+3zpIspCQFN9AP5cwPB Pr22+9KAZxxH/0X0Q+vAy1X3A3v73yasvVl0FRCApAXnvde2b41dLY18MBOORASPysLbbWY9 HXUS8fh0DcX4MFgrnEOHwcVmezM71wYQGFQCYakIdQf8GeF/R/EFYIN97AAPhAMBGf1Xbmeb MwfhSBaQAAamtxtNxoNqdG4ECnQMlNJt/XUtAD01jUeFUKH9h83meABKCFH4kgDxvduMhfzZ CCrpjY0m9+23NX+DEFEtJbxrRwpZWW7hm2s3JvD/LMC1QQJ1WYIOyMj261NcCv7rPXa7BOcy Q585N30o9d3MNcvwRFBzcHmNt+Zm7oQIBKprX2ph7HQGLsy6GnUIO0M4DBI8CzdtrQDHR+v0 IwioC6dldKpZNkAcAF9uspr4V8gBDsCq/dbSa6AZCQ+GaLBcQQD7F5buQ6ygFGpfdS7/NTCA l7OATULPLy8av1kpYTBDH7MDLqVSrLVZgWuFF2AbJwPt0nUEDa5HOxB+Lrj+g/4IV/fQuQ5u jNH+we+xQPuXSt/324003okfkRrDG5e+eSPxM/PawevdBLWAH/btuXYzw0IUGRcGWgGLNBbW 3jY4wegn8BnGI8EgFmFuGTkEhe7GMC3vgrlRIiwSTw+FQf675QyO4VJ0GcX4I/kz+7fCj/wj PL3HQk5155/8W10Gp9YJoXSf0a2lcqnhv4AHVsmQYOBgMLTaA1YC/rxiGxZGoO/r/Ov9wTvG MMjWbAf1ViQCQOW21HgtiM3/Jn0MLLDZntH+B8lqHkrAh2zHaovqai4LkBa+3YIs4AnMxyRQ SwME093BBnfKULvECgAFlq5pugWNxgOYyJovNRu0xglChSW1/Jwnbl/XCswHnhfHvIxgAbbN 3bYwEM4CoFYjllYJ0mwG2uYIBaQLpyOIXVe2zQ3WEKg62gOsFGiubIsIqK0JtuZrS0eEIXjc rgK6vQdiDX4e5NMFil069u3XDVZWkB5WXSibnus6gDYpeIz7meXXUBlaUBx1CHwYst12SyE5 DHQcJYzt1hFrX1BQmwFF674HvELnuviy8EiQkDId9my4LB2QAQISlBS0CA5WmOG2IHiZFnXR XbZWNeAFBi/kby7PZ0PbB+YrWF3oAeoB9DcrnGxr7OCSiQQaM2c2r3i7CIHSBi+UBe1e6+5q WNx/uG0fg+wQM/AxFZQtgX3wz9569+8HcggH2gd2Bl7w1Admz/IBck+ax8YGDBPyAQD29h8X lq4j9grs8PJKRMEard3+4AnB4QULwQ0MCxid8N+2Bg9BjRcGD/pm0ek5oxtrCB0IGsm/CIRH uxG+V1YAq4XDMsJCwnyL/LuFu7lzg/r4+yDx+InWZu62odeLMjkIdC3kHmcwG+gd+CsF6889 CiU7OCimO6ofHVrCZCMLAwTt3oGhVvOpipGEZRhMJC7wrhtAEYpFcAGD4r3iBP/d0ZewBAvW gyQBipIhiFEBfhplWZbmilABAg8CBi+072cc6wKyPSsCJXJ+DoqC/dm3QCLgP4qAGrA9iEED +Q1dMJhdgUHUnNlQcuRmbgfYmAbclOCQR44cOeSM6IjshKSA5MiRI6h8rHiwdI4cOXK0cLhs vGjAZMiRI0fEYMhczFgTn8bo0FRYnHql+GNns5mGT/4TmIuN6hfKQpECMaADyPfZtsiOby/x eQL33gP0BgYAOowlPyQAdTEM9I/vXjXJuVBhfQW5TIuKajyZXw3eeivuB1JXmcf+UFGMz/N0 C6lQBPr48PJunu5CbIWgDPb01GgkKMT68Ki+HGEmvlZjicHJFDX4RRotXAbcPBcLxSOKdELj dD387e2gu8WFXGyUdAVrc4Am22V7q3TrA3zbKTl0KyT0MDvcRy+Nh0AKTjhSu+SQczXsQVLT Ro0WtjdxBHztPPgCEGxvqXb7mVn3+TkLfQc9apFEvbcBF31OaKCgLxhmgc0Yg/jNcWTf6G3l g3zDCgZ1A7ABw0PixeoywMN3aSFs4O/ddiIJJzFqCWChEILIigTtUmNvRgQ+RiE7V3LeTXMW eQL3LAgwKCDx3YW1pP5uNJVsgUD4/zlz21mbWYckIYP6Dw+O/HKpF116vh54YPwPoXc6FXRv DW68BauzJbpfDFy1ExZoEzprMVhVzEtqUE/Y2Vl3XGpZZQp+INmRJ2eaBFz7JIJEXpIDbB8U Ys2SJel1eHOkG9lq4RKnGDrUV8KbJXtnuEgkHCvZp6HyBwe9+OtQqUgOyckNBqT+zpQMth8U CR/74CXhlUiBn+gUmfc9tHqwxMZdQfRdwDW30NlFloJkJrC87cZ3sbvW+SKAPB9AHVNHDVlq bPw7+Hzy6xJ7H3mGZEND5zu0Ob2v0/g2DG02TLC/SOt2QFG2atE05u/0+LTAzvZ1If4+rMz4 b1jAPtiKUw70IyChRxe2cnXWgxAguHONgxDBhduaMHeiAA8ES2XLu6XM1op0XuEEktj5INnd JFYhKHpZE3ObrzluLy4vahAYR7RywKFqJt4gXwXZLkL/MFzcrhiTusVaIiTIahm7sAGl0moG c0lu2vQtPeBnqddgBfiAQzbAowW+Vu8B79kG7NMaAxUE+DhzDnkQFjD3xKl26QRo6zSMVJ2t dO/b+x00Eo2uXfpIlwyzWYSHdRqBG6bOgL84jgFeVxrG9giHMdgX1j9wl7wt7HXGLBcRuwcQ dHgB41OpDw1t2FfhX8GrWTZjsNKQstaF6gaxtsEMJcxOAfRs9mL24YpsfBKxQ2a2ZipURUSO I2ZuBh4X28dYhXrIYK6SDFxIxBbYGWwfWMMPABnKvRXQBUAmeSW8BUyAnAhkCFcFSQ4gAxL+ BAjsbJJEWRFZnEIOAHK6BHUEJ8++5gNhEzg3DMfHAOEi4wQkMCRTYmyRnDCwKElKBmQgHOgM GJAmFMvYgGQgC/YKwQtZHMwVbisTahOYV2VMxpa81Ix2OF0C5GWs0IxbAjkgzbFTV2T9zGT9 8kB4IRAJZP1lnJAXZP18jJDOGSxbgPYvBHsT3xKLFJU0ElKJVQgwsMlPMOAJBGh0jH9daUOk OHUHECfrnMlm7gVoEAZujKSU3GIljCC8i4BMIbwjWCCx8koKcEkBo0U7zaUWdFj6BDChlyye desVcBwQoJubDQ1pJahguSL2T3AIdBVqSFdaOWvk3hiepBxcQz9GKIQvJ09Z5z9hCQfktIsz 2/3sCUfyAqyLUxOFZZpaVDRqLUAOxtMupItIJImQPVxZitQ3IJTrAjPAJ/9/Uwd5wYoGPCB0 BDwJdQNG6/MPvv/WEb8GViitRQ0NDo0Ev0aNfHWpD/RB0OvlZ4tUVTPJbasrLCoRqzMK2MYK U9+7+CBBgfkADnzogKIHADa5uf3euAlJ3FbCAPC4XUFrhVYEkrJFh4P+G3qKFDCSFID6IHUP OFQwMd0P9nuIlA0s6wcIQUA9/w9a1QXh2diApA8ATFBW+Gh76FmWUaH6ViontGvhbqUPj4qD glkhv827eDj6+TdxKQxZhW/ud4FWYWc7NTF85BvbxaAIRXgNiw0YcEXs/VCJBI06ZSeCHw5a 5hD8YCRhgm0U+54ic56FJ7ePPTRgMgwVxoCwlBQB/6EeArwFDDo0U0vq1pjVgzShO8OgjQvU MpBd+PVQGlsTbBpl/yk7Eg9v4jda+w++EUWrHIsMtfQKCy+Uwi04OhFxQ6bhEmyGYD9AeetL oka+2HYEOJQ0IOOcLLtfvuBHpDg8YH57fB48Lwc6fHsFePgWgH3/AeYHXkJx7/1t9+sIDMZF GEOD+yh+CBIaOmzY4IP+A6O0SGahuEWpQpRy+3/inStuk33OkF9TK8MDcLORHg3MRXwI2o6S vWQrgAV2bBDZYL/U/YB8NctdjQR1lFv/NQCBrfeMbHwCIAd3B4UOLV+apXvJLnQhBsgayhOA P10e7MhhGQd1CmEYo1kDPszwtlu5jLT+DYQDPJqu5/t1W70t1DBOH/9+FwU+aeOfbT/0FEhZ O/B06Og+GhiGjDG9DLOFDRtnIxr72LLeWa8QP2WW/MXgTfJZDjO4tia/fA6F1wxsvwF/dAKL 980SfOU795GTG1gPU+GLokiTW4dmfLthQ/TvacMETyE1SN6/RRJ9rdkZyTvWnOywd7wNgQ+O NwEcUIp2j9hFPjyIi4MqXGWF3HZgt5q8FvJMyTOgVIlkko/sQ3R2aCwSSGg0I/lIPjVoXCJo RNjL/rIPsRlHWetCDhgQGpAtgVziJjZGeDAw2VX4WLwQTNRogZlKTl1FOJtZDVlDWxtOEiWD jw2ACAKP5Aau0XP4/b40SZaIRD8n/FyCj2UL7wzD+/57IZugwvz+/zYt7MDMLQ8Mv2z3Amfj UBDASYH+lGncmwx2fJRekUQufg1IU8t4bZQQ5Ae8s0e8Gh3MYKM5HBH47wiga5Zb+4C96SYI dQ3oLhUXZGRkzOoWHtjKzMnprffeG9iEWpbhCz1yayySnRz2EHRJ7BI4gzuMjhcWsBMJGYSg RXzZL/sc5lkMHXjrDA0a9IFB+IET9fhZfxYItq1zgVakyGDBCA7/wmGDacRVVr5gj2PbkaWC 0AV0HzZUWSFazwh+9OAE+AUPYQYCvlcLSpiq4P0u/0kIByT40CEHecnY/tf+2P7xkhxsEniO EQy2pOOcD9QncB1EtpITEIe79sJVv0AVU2hpZHsscb5YDdjpV8eeQVu2jpgAYAiLPbZI5p4E 10E8dAgbe4PtE2gwKtMEIGhjcocs9mgBJB5o9M+Z7Gwv8qoMLgJYIiswTE0eXCQnRwLc1Ekj 5JWcjd4D03B4mAHMvOCxdg00GCcrMcRaU1OazbHZFtyjsEsK2D0KnMEHN3UJQ8KFW7h2FlZo wkYDLD7RVDe5/wmkv+q+sBYfP+FFF1aJHY+qVMLiLAJRVlJisXBReBwn7X3/qZN3E2oQaKjn iJFjooXv2BhhLB74BM791HDUfnGtfWoy53S0aC6aglA85Ed0/vsGjHTpOR1ofuHHRRCZ3kts 5/zs1IC7n97iyeICTv8wpwfGg5mby8WiRIhCajKPbdFcHCRfO0d8v+tqKFj3l/8ldG7MAPsM jhr6JbAEhdJ0R7tEPTeAX4qL1QRyLffZdHQIar7y/yvRiAdHSXX6i8jB4AYQyrqu8CbZ6QJ0 BiA6BiNKbXxRZz5fEMOq/8lu7ByJmiwx3cPMAMStVQ22V4JzTRBzof/W2otI0QPGO/52CDsv gnj/O/dw98cDoxRbYYP5CHIp86X/JJWl2m/DyDMox7ocg+md/DW38vbgAwPIF4XgMh6N2JDd dd3TB1zwExwIQAMj0Yq25rbfnIpGAYhHAQUCVghZxmUnGVvHXMyNSSvkWZaxJQECAqaQrzub kCNGIUc/jGmarju/BqwDpJyU7v+apoyEfL9EjuSJRI/kB5qmaZro6Ozs8PBpmqZp9PT4+PxD +K6x/I1k9gAD8AP4CQ216b7/8OAD7AA0jQjZwN7SXl8VkJ0L+ZAQXLARow0Q3j7MCiuNdDFn fDn8f2e3vWQkDf3j/HdgNZNw3hoV740QNY/5+0U+JytoNCyQeAutsJmumAPAbQM6b/aWfN0D TlhPVrZLH3y3Sxij7gLvAimMCW/ZgJAnJKtg45UtLQOuRVrTdRfmHVsUBhwDJGHTNE0sNDxE VzWXaZqmGRwcGBgUpmmaphQQEAwMLKRpmggIBARh03UnH3AFeAOInDWXbAnOLbe1hw/CwBbC gxO3/6NlE8wA9wjrao2kJOjwU3t6b7tX98GH/2wBXoWKAUHCOw518YsBuv8bb/3//v5+A9CD 8P8zwoPBBKkbAYF0d0Gba6m7/CYjhOSGqfg4Dtu/UXMGB9rrzY15/+sNBP7MVMvL6wj96wP8 zV/dqFQeGYoR7EkXR8UK8INi7usFiRd5Z3eTHaxuaYsRa+EvNIT2tbE39nQn98JpEgdqxziS bWdnLmYIxvMADBnsBdsIiAff3hSRHQ45QAUB43DJSXMyJBNBJJNsjzUrwcMJ/v028CvI/Mej 4LfDof7Yb/8FacD9Q3gFw54mABXB+BAl/3+yRVcJGOgEnOTglfkogdh1SmUXN08LUIgskxrg 4VAIjsdOV+8l+KXcelZTi9msFPfGzdI7NhFBdQfLdW/rIaP2rPvARnN0JcEpH3XrLd1sgb8d UYPjkw0gHS9h0sbuS3XzphBbJcO5Yc8EhV465i4RKw2cdDrubKNLKsIWYUJYt2Ovus0gH3IG FoPG3iy3J4M0Hgx1xjnrGJymc9GB4kYJDgC2tdgGv9JT51UKBGG7Uu+JB1/DsHWFo/gGD4cq EfoSgz1sks+gRTurfg7VKS0puy5xMHRcYJAxBEE78WRbVAQnEWgHpSoX3nYCZosrJR5hUT3q VuEAXWU3FIG3jv3uFTjuLRCFARdz7KSLxMHhS28Mi+GLxUAEUMOP3aHRovFC2YHxaQUa7u6K cQH0T4v3GXHpl87Q8DjQdBVpC3MKCnX1Fz7DFn5fzBDwl41+v4PW8f+KYQJnKBAxOOB1xIpB 2rvGuwMxGIpm/48QdN/rsS9vc9/tNIrCkCmijUf/DL7HBSTaQfqNQv9bw82NZAaDaMLExhvY bZsIg/iPUHTVE4oKQjjZdNEh22/9bFESde0L2AzDweMQVgiLhOs2wgq/xsG2M8uPUlt8uMHx /8/PMxLCA43n98Ph0HUcJQZ00wGoKxHt0IHm7K2xzXelu7+LQvw42HQ2t+843K7P58Ho7aZp uhASFdwG1OuWLXPSuWexQv43Bv38gx0Gi08EU6Q8ttvb7YsCOmsuCkMmOmEIJQpXHZRugWg6 qhkUEa2bM20dELWlGnXSz5O27XeKkBvA0eBAkf9DAff22brdAkJE6UEw4BMCqGZYNE/ztTNb 0srJwXSpLjZw64xjamTIZWg/XDZ2mEdkoVxQZIn4s3RHP63sWDGJZeio9F3V6A20itSJPmTI i90xCifKDdwNweHssbudbcoK2K+j1Acz9vDu0x2gNl9Z5mocCyv7WYnQZ6NPBjS0a/DYYqE4 o4/+M4KjvAgxtbXQ9rEwfLOeK9CapJeCz3QK7BYkwfZFDfjywtABXA+3RQNqCljMBQfZ6JxW VtDoIMV3bPAryQgtywzstQmJTX27s+mYUFEDLqDHdZge3NJuwS0oxHIHBQ04bGk5l3sPOKVo 052xL8kNNoQkWSX4daSAgVB7NSRfI74GOKSbduB3Ir1d4vAcbMcWOad0EBM5+N7d27/CvYE7 NbCTSXcLVho9L7Xqn6cchfZ1Aw0iD4PmwFMvwfBWhjWgYZf8WXAdMMXmP2/MfPpbt7j4qztb IIPACEI933zxovvbS9kTch0EJHcYxwXIIw396y65kfXV/CqjEMOB+bw2Z2bbE3ISB8olCHYK aC12zjEWnIkE2rfUfMk6UVbSUAt85lxxXtaFlQBhhdpA7SaCjUgBVX13DLc1Ls9vD7frUjBO NQ434t/FwXa20fZEVgGAXs1l/tk2/hL9TfyIRf1qiwkN/bUXqFSFo41NCgWgHYKtYQFRKQuU 6CiXS0JcTgLjDhy3dwEKI0UMCKHUQzv7wXX8Av/QaBCAwwgE74ZoBA7oWjDkACSxaiHPsnup DBAt7QwBdrj9NlcPXzk9EF5TdRHT2w2lK8oI8gTYDHdvLQFNXOmJPQwiiB0I5lZnfyg8odCD IufMYoVmDf6Ncfw78HITJpdt5PuvQGsic+1eaBiUFL7kuzBGaCAQHIXbWzgj9pXjeomGZV8G yXbBKKpzDVd7caQY4evtdlOfL+EA2g0fwCB7i1gISEGXO1oVAXD7BXVgCG5zedf56STeg/sB 9gANFGGPLRBLIQhBiQuLSATWYOxHFYXIHfBKBbHV/+YV9APRVjvKfRWNNEngjbUQuxZAEoMm rwyxuRVoxvkjNfw9jruAr7w/wHUMDIP6cD0B+RmwkBKBXT2R+RmQn4RKPZOFNz2NGZCfAYIk PY+G2Onk+RE9kgqKkoiItVrEaoNpCh3uK9SlmvpREZqjg2i4eONdaLXZTrThDNNbXdDs+One s7s5FXgFVrh07et4236L/8AMO8ZzBDl09Y0MSV4DjRWyy8X3O8ESdLsoyGKil+PIAEer6Nlo HRXYVSLDmkYHbsCNMRgR98BQf0OliW/bb+ZG6+OAPiENBwo8IHYf24vaWwwgd/o0Vg/pVuD9 wovG21Mz2zkdWoNbu+hAC1oqsjrDFQv+Fr08PXQBR1b2IHOpb5MGAevoZb0EgFu47HUsHzvz CfAx9N/C04MJ1gc9QTgfdDlVit3+CPyL6FlFgD9JIlU0P+KyJpIGLlceJbxiN2g3WQP9Nzpd /4Rb+PcsmokdC4keX16HxKmVjfWBhFsLUb0UeoXhvhiAWtCP7TBGQ6EpogB8SA1B4f44GE15 +POJKNHvU1OfMc5o1daoYVvYiNRw1teGTbqhCC8nJNsWHHaGUFY1/FRIWugihPtFgKPkBgip 3WDbTBgcFNaDIXJqI9ZoUY9UtSCGlkqQc3c3iiIWbhSZgDibRIUuFl52QID6vinsJb43sHH7 0vaCgWBHBHQ9ARgGihAVOzL2iBZGQAvV684Mxm5vqXodRkAc60MeBVvytkUEQETa9oMZ8tbc /RiIHkZlIHQJCQgJdcyhWGOB/0i7ShjM0vZGgGUYAE4AtuCMbd/XRCsFJwNe8RfIvfYPzLyL VRT/AsfQ14u//xbkOFx1BEBD6/eSLPbDWvYXHIRHbQ2AeAEijeMYthK3HYvCUDcIDKntNxpY GBgPlMKJBdFH2r9bcNNLsA5DiMYGXEaxjbZrpkOAp0qDP1VxqW2+Coo/dDoPZ3QuMOGyV0ri Bh82NyCcGw9AAxUBQH1tCLuQMrowDw6ItUY03McDgyeOFLr7C03cKKBJoRxjU7stmqO6glAJ VznAtdHYNqh1BNUOC3QVPBDPFiFwKJmFO6IbJ/g7+xfqubzLnBsC/jRfg/iFgU+1WYdDDD8n rGZnb7fSOR5z60BACBh1+QbytI3d0ivGL1hO0fiOQAKpWGJrXQOJyjSB29SSfug763QyMrN0 IxyOwjVwVVC7JCU03TZI3XUODBAnXAmLA1bWRfxsnlzD61PmTKVGpZO5hbF0PGDq7d92iWVA OHv7BPYrx0Bq0lewpFXOWgu6W8FZwVbUDDEQfnGEOrtdW4LsRGEHoNCJJwQ6liZNhWUyGxXA p5YLJrgYwGIgS5WNG7yGKbRzGm0E6F16v7bGRgUKoSP1CAUbiUHItYrhjWYJa9upo0J1xTUW ROkL7cXSZ7kwjdy4SEqZ+3f7jRwufAJ2OTVjfVK/xEyPt5p9YAA4g3/7jYguS/NjfsFzGIBg CECLDzPH2C7RgcF85NVJpagQ+3y76waLCfsJ+Es16kaLA0aJik0A9sEBnlv11n4ECHULoURg HiXoX4ooz8H4BYPhHw10b9V6zyHSC4kIL4g1XuIb60dFg8Ob/ny6UCjxAp/sPNj/8th1TTt7 K2pVAAgV9ljriKbbSn3DSPfYZY31WEjqZH9Au3QXV2YMJRqlH0YKPtAGgE5q6roCZd4KA3UK NgWAZot9q1kDfJv/uDZMRQMWDqm9ROhKBviohBxocXYOjWwNIFU8o1tQx0MNN24TSg9NOHCH bEAdcs3Dv2jKFR+eVddouG56sKBG4k3sXTmL5V2x6h4LD0EEBp24Ha/eAIYPrikQiQK4ctQ/ GIDDkNhq/mjARkUXpNn9/zUAGSCOhULdSYtwDEFcO9m3Xf3CdCggdosMs4m1iUgXfLO2B5Wi BBETLbPxgm//fTdy/1QI68Nkj3J/DXLOoYzmBQ+BeQR8awl6aFtRpVIMOVFg6u4tsAWbilG7 DAe2HdGscAhYiUsCQxeo1bfPawxZW/KFVkP49wH8MjBYQzAwTAj6/ItdDByWYhu490Dk2IKI a67gVDmdCD6W+C5bIXN7CMFhuXZrf6nYsY8URVZVjWsQqAtV90J3XV5BC8MzeDwlUy1j3faz nLMEHVYM3gg2JlvBNm7ej0mPxneu21UMOwgwGos0j+uh9bLfsa97HMnrFVxq/z9DG0JsXRaU vDvqkt1+iymLQRxQAxhQJOGhNRRwvW+gmPEqmYrNW370jkAhaEPBqOtYeqEgylnvI9GsHnSQ 36S7+osqiLggkxMQdP0tzpsLQT2wk5TxweYDO5alYW7hGiYcKmy7h27SmehwDRDXqFb9tb36 dQvxH4Vc/hN4dihC1heoaELNDiGaWRLJ9nYs3r0HYEBZZTx2KRng7CRgD/gNg/oq3F9FagMD +GikQV58syTdp8xg/1WIEIecTapXWx2EzFrNZu7/tiTTFhEJO8hgpgMnXEfHWYlirn4sX+sm jaEw9E3aTag2Oghq9Ntyq1M1foQpWShfTl8fMQ+x0LEEdCGAoZl7UgiUvNGmKa+cdQELJZRh EbidzQaYMaOQarzNEbiIBRlAoRhHXWNvN4ChnAeI9xSDC7tG9StQDBQkcge3FIgBuULKaG/q ilpU0wCLQW+xbVA0kHEMWtrC/FdAfYvSwe7N5nr8acnu3ijRhku974wBRJmJXfQysFSiE6QT Eqi9fYn2dX/B+bk/SV8LtdYv3sbPdgMeTBP3A/ClTC16SPrxIHMcv4u/9V3e0++NTAEw1yF8 sET+XYK91G4rdSE5eoPB4B6ncw/mLSG8sMQSJAbYtuFK01HTfFWJCvC77c0ECANd+A0IjIv7 wf8ET4ChrS0zP3uGX8s1AY2ujpfshYEreotYM8IRoXH4SVq21t21Z6Z2BYnzykEb+7pt8OdA Pjv6dk76v3RrwLZWI607vlG9LnlkZLrq0iFUEeTDgkUevdIhlG1brCVMUr9JvkqqtbKcCwQI EZFYQOEmt3UJOTMZdW/ItynwjQz5CyaJl61szS8OBQiXSmOKt+/+7UwHBO8giE0P/sGIC3Ml gH0PRg67yXY3eIiR0+t2CRkNjdi3ElqxCRjrKST+ENyz2E/gGSVZBA+dFm947IS3CTiLVEXw iRpUeCwL8BP8/6/6oXYW7gGeid+8jA264rbRzXDB4Q9LDFKAABcFWmSA/16970GYPR8yHAlQ CA7d7P1hOUAQg6SIbCQP/mi40dlIQwpIf3lDE4P0EseWq/4Rg3ixdWxT0L3WwBAoWhIJEBrw SFge9EwLhRIx8g6Sy8h4q4VjKCvIkhErjUgUgzDwiQJIXMyqbTXerw0vOwUiNSUUQKPTr5Y6 iQ1MqbKi8zPLrIk1ZL0rBWwUZi9oV408gsO08cksG0gXdvAXaoWXuqNJNH0Og6vT7oPtAxy3 ov/X6xAmGfcrulBb0+jm+KFpF94A8IvYO+dzGYtL4TsjuEWLbysj/gvPYDUUO/L9bteaGHLn B3V5i9o72CYV3N02EwXr5hl1WSRzEYPsXAEaLIUTN+vt5uwd8iYNGy/uB5vbhg4IQLB7hdt0 FEZuW9H2QWFZWxDiQ6g4/+vez6hUQKuJHaUUixZE30pt+sdKLYuMkMRsZw/7IpBEiDeLEnAR VV8wEK3dzQ5EC9aLQmWCbwt1F4uRhrXT/1a4HFuL/iM5C9d06YuXhzWrUMpjXFhNwRp0G3ZM V84qZrut/t1qIGRfhcl8BdHhR1+LIFT5gru6bkMKK3/xe8H+BG4FTbdtP374XgKEDaRNg1Qk YSB9KxHb0lIFUTic0/PsW+C4+yNciESJA/4Pdeqe7GixgfQhC+sxFyuVFVy7xaEyIRkpNpiT cxSCLIUiCsCbXi5iegTsla96CCWe21yQhJQ0qRQDSK1tQgylIsJkqXSzLAb+C30pxJnGNtdo CzARYr+wzm67ZJeMCTsKjwl8rusv70N6wCgNjU62CXsEsVyPdLG8rRa+7gk3alu6UYvcjgqJ A/yyw297l3l18APRIgESMvyf6PHbbYsOIY15Dz51Gjsd8kEjUldsSzukBkhv5IJrEdKNQgQI uCLzpAINiJ2mhVIbXXWVTVBy65CapVCQnFeXLBzMoNCqO2yInINfsBjAPQpoxL9toZnpCEUw +IEzUrHFkfyJRlwqahf04Ks8aLL6DKR/MBkMdRT/dhBX/HFrLW2t63xOJMWJfspUiy1KBWJB 56PWrNi0XzfpidHaYuNxyEG/28VYVaPZT+BDwzdlJSrG1lr7MIJoW0MX20AIAgTaSh77hcFD Ptut5995DIsQgABWk8lBd9EnQgVL23f1lwBwYPp3PI1Hd0jyg24rR4OIfvR4/AaBaAbzx0D8 8EIOI9TnvlHWBMeA6BAUBXfBDT4gSPCWdsdgTwwFda0wRdcmJom3l629rI1KDAiPQWSeREK8 nu+68Q/jikZDisgLhMB6iE5DdQcFxvgDCXgEuizLaH7RsFoBati0OHKBNHtoGKEsiw0ouIkV 7z69ulIXaOQLXlasM1ZbgJOtgCAE/R0b1hCP4lZjXCQZ1ftpI+zOpQJYo0Nw0N32nySTHEkF oUi2PapHZasIWL08m+AzI0OTlDldGM22grsZoVgqeI1TLC3RD7BBIBDgCECAGIjbU7U3KCTg VnRj0AAKtBpy69XuRbyeAyT8PsCL9BZAo0ofN8KgRIcO6wtIjW0JNprIg7z/wilJ55K12eBW XxxVUhGkq1pBFM8rIOEsmPiNZcx7Jg1I8hCoEQXZQ7apUQWAAO/DBuyCWxGEiHB1HLLQDdqC nw6MRWrFqgJshSMHdjfB8AyyjYpwaevbXAJtRYA1ZPl1M9maIZoiSKcJVpbLm/rSuMBiOTB0 cjBClKbBEXAKkxzc28cIQCQoQGNZv4CCAo+VtofoxlDzq6q4aerHzYQPhu8Vfe5mu8RPbf9N 74oRhNIMrnm2Qf8GxN4vMDvCD4eTJcdaDEtt2e5SSJNScb+w+6XYBKqNntCRgDt7y3QsilG0 UcWIAbA0+n27d7SUd0L8ipK4IAiQRkCBgYW/E3b1QUGAORjU+cjxUrB4CCoEcsGvh/eE2Kl8 SVCjrAtW3WapyjHEv3APpW2qq93fo7ul61VAef9MSK3izGBnQqEIrizWykVacDks1l572VTr BvoLwk1fwf02qwDrDTkdMAqbMP1Umbp2BEYmMAO7o+G1hjHnIVX+II3wIFtLMP8lOGr9Y4nI hRQYXg+3BhxbFhlJLaT21N/e4nQiUQR0FwQNdAxIdAPtbAXaaLgENQUSC9wGdZ4IEfBZqjdC sBNsqrQXo8U5UvW93MNfZBQFjAglouwR5wr/vgAGFs2+h4iEBex9/wVX+YLGcvSKRfLGhQ0g CWDrAvU3U6dV0KELNGgKJrV3HRoegHusvCpBuCAAl78joNCE3t2qQkKKQv92QC8AXtBfW/Ls +gh39hqDNY16UBJnbEKdmzgj/exmk30dVh5WNCNLkTPFlYz8aDsnf01LAV5cgo1yZosRzd9P +PbCAXQW+hCKlAVkiJCA68idk7ccGgJ0ECBbQ6PxNvKgHIE8ANhumHC/60kVJUFyGQRaJRod 1qpLyCV9k5e3sYhJHx1hchN6dw7obtibIOkg6+BMSr5eyUb98ZCGEmpGQ+dZzDkSzaCSSjRf SNFV/UJoBGmFZHXoIho1Z5oD+PY1VA6GJKMpdPr3w+/Z6BBo1AejONTWozwGcegGXqELeRb/ 0Kis6z27vKE8EAVTEYsYAyPEMzCMTQXrcqoE4vjMzN+oWd/I5wTAWLhZPAfQAIHYdRP8AyBZ 30IOgLyoWahZTdcNFj+fBowDhHyITdM0dGxkXFk+cwgQ36hZ8MBAArHpA8zgWd9HyEMOQFvw WkjErvudWiyQWAt4A6BaIZBXCN9AW26wUMhAW1v0f03TLLv8AwRbDBQcJCFAIDY3W9/YdN0J H1AFWANofFsJLQCB3zRFkyHkEGkc5EJvuuA9YHZ1RldXMVtTyUItVmoeN2wntPy2wB0j6yJT OVfpooMsaCIBO2ANNKE/OX0UfhAvYrUeejeiWbgUoR1VHQsIvdgWHLRPSHxGNjROTSHTfSAs NGuTIHMuTiRvwMmAIIsY5DvfQjvAbYWcNr4EG1KhD20XxEHcOusTS7c21g7/JhGLOGfcdMna rKFmrdxhIVfeWcx19E3sGqVsbbYl/pdxddg793Qy9kUNGEA+HM1uhtp4siLVfx7aIbO1kTJI 0o+NKBWE5Mgw5BeyHXOzNtyJXeAXK5BkEpWyfXOnrHvfdLRWZORndJyPs7dZi3Z1BAM9jCho IAfEvgeU1Vi/XIRSLgD/CHFSzUtFqAiLRFahXmht1P/nOH9ei/FJbqluoQXzDF4AKx5bDARu g8LDjzw01Ei9MpAeU6t2bOh0X3UheovQnsDBu39/igqA+UF8BFp/BYCgo3X8rWgaderrZ1Zk UwCYiRIuRmK9Nyy1g1sUK8QgYThXu61iGCmoKixXUCa5xCsnWUhfIIGaAeruDbYYT1DwKDcM QENRYYcqAACW/y3+/zAHdyxhDu66UQmZGcRtBxFqcDWlY+mjlf////9knjKI2w6kuNx5HunV 4IjZ0pcrTLYJvXyxfgctuOeRHf7///+/kGQQtx3yILBqSHG5895BvoR91Noa6+TdbVG11PTH ////BZGDVphsE8Coa2R6+WL97Mllik9cARTZbAb/G/z/Y2M9D/r1DQiNyCBuO15pTORBYNVy cWei/////9HkAzxH1ARL/YUN0mu1CqX6qLU1bJiyQtbJu9tA+bys/////+Ns2DJ1XN9Fzw3W 3Fk90ausMNkmOgDeUYBR18gWYdC//////7X0tCEjxLNWmZW6zw+lvbieuAIoCIgFX7LZDMYk 6Qux/////4d8by8RTGhYqx1hwT0tZraQQdx2BnHbAbwg0pgqENXv/////4mFsXEftbYGpeS/ nzPUuOiiyQd4NPkAD46oCZYYmA7h/////7sNan8tPW0Il2xkkQFcY+b0UWtrYmFsHNgwZYVO AGLy/////+2VBmx7pQEbwfQIglfED/XG2bBlUOm3Euq4vot8iLn8X/j//98d3WJJLdoV83zT jGVM1PtYYbJNziw6dAC8///2/6PiMLvUQaXfSteV2GHE0aT79NbTaulpQ/zZbjT/////Rohn rdC4YNpzLQRE5R0DM19MCqrJfA3dPHEFUKpBAif/////EBALvoYgDMkltWhXs4VvIAnUZrmf 5GHODvneXpjJ2Sn/////IpjQsLSo18cXPbNZgQ20LjtcvbetbLrAIIO47bazv5r/////DOK2 A5rSsXQ5R9Xqr3fSnRUm2wSDFtxzEgtj44Q7ZJT/////PmptDahaanoLzw7knf8JkyeuAAqx ngd9RJMP8NKjCIf/////aPIBHv7CBmldV2L3y2dlgHE2bBnnBmtudhvU/uAr04n/////Wnra EMxK3Wdv37n5+e++jkO+txfVjrBg6KPW1n6T0aH/////xMLYOFLy30/xZ7vRZ1e8pt0GtT9L NrJI2isN2EwbCq//////9koDNmB6BEHD72DfVd9nqO+ObjF5vmlGjLNhyxqDZrz/////oNJv JTbiaFKVdwzMA0cLu7kWAiIvJgVVvju6xSgLvbL/////klq0KwRqs1yn/9fCMc/QtYue2Swd rt5bsMJkmybyY+z/////nKNqdQqTbQKpBgmcPzYO64VnB3ITVwAFgkq/lRR6uOL/////riux ezgbtgybjtKSDb7V5bfv3Hwh39sL1NLThkLi1PHG////+LPdaG6D2h/NFr6BWya59uF3sG93 R7cY5lp9jf///3BqD//KOwZmXAsBEf+eZY9prmL40/9rYcT/////bBZ44gqg7tIN11SDBE7C swM5YSZnp/cWYNBNR2lJ23f/S/z/bj5KatGu3FrW2WYL30CC2DdTrrypxZ67/////95/z7JH 6f+1MBzyvb2KwrrKMJOzU6ajtCQFNtC6kwbX/f///80pV95Uv2fZIy56ZrO4SmHEAhtoXZQr byo3vgu0oSc2+htewxvfBVqN7y1LFvD//0FCQ0RFRkdISUpLTE1OT1BRUlNU2/////9YWVph YmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ejAxEpvu/zIzNDU2Nzg5Ky8AAP+7O9lb8f/dzwNy dW50aW1lIGVycm9yv1RH9azETE+3DQ0KxLL2A3ZJTkcOAERPTUESEbG83f5SNjAyOAgtIEdh Ymx0+3apvc5pbmlSZml6DWhlYXA3W9vONyc3mXQ9BHUtdNtvqCBzcGFjI2Z3bH9p5LLbgDhh Bm9uNzafgeQpc3RkNXB1W2uFt3IrdmlyCyEzpWPIF9t+IyBjDGwoXzRe225TXypleFwvWAYW drLX3OJfMTn3Cu7mFnJlWDFzbw+Ka5MB23NjKzhGJAZChFuBZWQZV9vtIfkjN211bKx0aL9h hTCSby9sb2NrF2tuG2w0ZLdhLgKi2reGWyFybQBwQGdyYW0g7IVQ2EptNi8wOU+NZmgpEEEq J1PI5xosLis4YfY8hO9yZ3Uoc18wMmbBLrZtu25uZ4JvBXQ6EUIrnLVk5n9NLWA5YPzD22YV VmlzqkMrKyBSnIe57/ZMaWK0cnknCi0WRWucbQ8OIRFQ1Dq+AHNt2GUuADzl4CUssSRMbWts nUPY+G75/1lTXQNHZXRMYUZBey8U6BZ2/MJ1cAATD4FvbTtXqWQ6m2Vzc2En8YUFeEJveEBz OTMyLmTG3PKsPkelXKkDU12gojBnAwAup7IPr1dAIwiL+IppmqbZA+DQuKygpmmappR8aFhA zbJpmiAUCPCJ2MQ0TdM0qJiAbFTTNE3TPCwoJCBN0zRNHBgUEAwIdG7TNAQA/IiPA/TTNE3T 8Ozo5OBN0zRN3NjU0MzENE3TNMC4sKig0zRN05yUjIR8TdM0TXRsZFxUTDRN0zREPDQsKKZz X9MgDI+HiwPkmqZpmtzUzMC8uGmapmmwqJyUiKRrmqaEfHRoQ2BpmqYbWANQQDgspmmapigg FAwETdM0y/yG9Ozk3NA0TdM0yMC4sKjTNF3ToJgvkIiATdM0TVxQSEA4MOYbpDv/fJTnhppm 2XQDCPyF6NC4aZqmabComIRssmmaplhELBT8hE3TNM3YwKyMfHA2TdM0ZFxQPCCE03Sm6WeE gwPUvE3TNE2omJCIeHCm6842ZIPLVAdAAyyov2yaIATwgnNvbWV0aCvURu2zaXPab/ITsVTf C2dvCHcZZ4/9Rv3veW91/WUgYmFkC3Ryefph31UXc3RlYWwfZmVlbLBGbaWeJHObE97K7Vse cm4gbURleRphdHPu9vfBUndoeT83dGFrL2l0J7XvdqpzA2JwbAhkW7GuOtY+PzMnc9xuH3Nt bGtdISxkYwNOE8CtVAt9XWR1aNTADgcX2JttXwFELGYfbT5YtfZrlSk/YWJpgQBctY2yAEFm TQMJbnZIF4YbIdrYsn8bdHVmZi3XZ3q9tz3XLyVzfWUXjyO8Ce7rQQtKT2WGExq2c6ZySGwT aZBVC85t72SmIAhjTtUF7HKNA3L/Fewv9kCFM2hvcF3XdhdegAh1ZZxraVXv7MLuuidp7iBv ZlYh28vmkiVjFlNJYVy40L12um5wn3N3GWQhC/ZOYgthvVgvTTjE3FbWYwgjOIP7l3dhlFQu 3CG97rFkJ1hhY2PsdCt7y76EF98/E84j0TW+w0NrbX4Kb62wfc4vgvVtLmTjiWTvMHtgJx76 62ht9swuLxTymO2H99cSE2knbaWuAG9rD91eob13cDSVWDhhbhHahM14BHkiIKMjjzz2LnBp Zgdjb21zY3Jlb8kCznhllwsjbiMF+5vubyN0BWVzI2sjeSMtB/KPrZsTsW2rY/9wYXJ0c2+Q Lg9vMu+sB9tcCfhvYmpAx5Brr6avldonGOrXbEISEKltemYPkFMZ5VOMxGNqb/sxw93CaQVk 32Vic7NTeAClGJ/IgGNSw8V1Bz6wDXwb7xFwI153Z3AIjdZ4u2lpVvR1hm3ScG8fd4GQcI5n NmJKd2IHita2gAgPO2MwJ8/WtoBsdKM7AG/JvUmHc3M/4xWUCYbDhhForQOir9Eatjty2nTP fSPh7XoArzdsa0PbeENomxNzQ+MTs642CRXPWwDfVyEhbXBu2wOXZo9lPHv7ouxDcwQwU0/P j4DDM7Qq43DrkU+OldIHc2hkYnh+b3LkdGJiYWSkF3dhMdrIQXNwdXdL8rHCyXJ0dpcHaHRt bDjrzghrbANoM3TP3ZtRP2ciB1tdLUDXbJt/C18tXC96OgN5eAdN0zRNd3Z1dHNyNE3TNHFw b25t0zRN02xramloTtM0TWdmZWRjdk16F+NtMtQE33gg9KdYwAMZBnJmYyAhWYTNHiRscxdT WQuIQKD1EhquCy2nCiBsyWbR6JYVlxV3LoRjFrCsvhH+ao5lW9d9c0lzG6LCsqUHk71jMO41 2kbXeLt5ziCxR0aLdO8ZFVctg2wIlhWCDEPspiDdC2lpzFhvLjcXI9hu7mVxAyAtpGms2Fpj V31wdYi/3DOGozlOBGP3/KloDIbVwHM0cg95NRqzw7VHMv1ztIEtCF+Kt9k/rslfV69w/Gpw Z3Psi7ka6KFfGm9UtbPNEcJUeAxw9N2BvanynHAgOSBUcyJwO2izpnD4chDgXV9iwuwZaLSr YlV39tsBO3hwjjIx8DUuMTAwA/in7sAAgr926FVEUAAlHGsFOqYl+gYFLjJ7zyVrUwQUBgMr twzER5ArT6kATi/d2PVvdgBPH1NlvkF1Nkp1bIVW2HAD9k2TD8wtW2tzBwNGjxNhU9q2aK3X C7azaERXc1uBVnkH8h9vFy9t702BSVFVSVQHAy5pW478BgAtLQAiQyZ0/WrdNrAtVBdzZrAt RW6X/dHRmCQ6JWU2NCJEao+uAll4aYEcc7/Xy247IJbyPSJTUFBwJSZ5VSZKHwsfw/fFL3gt elkt13Jks9Zci6Y4NDM1tNYYXRgXk2WRvbasKi+Tvzcvtu2BIS86Ybw7pGtsC7dyYnQ9ti3F Y5joEIR2Ijdi1Bc4ECGLE1dxHfg2Pk4vyni2Yu4I2x8zhO9NSU1FLVZPcxZu4Fr3MS4wP0S8 N3RTdUNs4UUKk28GpyKCfQUACTAA238ifj9BVEE3Q1BUIFRPHjz9JcJtCz4QVUwgRlJPTSv4 B+4RAMdIRUxP0849PsNME1yz7cn8f39jB2UTKi4qG1NPRlRXQVJFXGMFh0BIXL1zYjC3xVxD KXLiuFwMTI4FPVOwYdcZWKJjee1t4UtvMm1s3CBreUGLRe1sat/4/0ebQ0xTSURce0U2RkI1 RTIwGUUzNS0lttv/MTFDRi05Qzg3LdRBQQM1yMRbIP43RUR9XEluimNdZs03DCSbYXNrbXNu XsstwqN7STkbw5q9H64L+2XQgoEYiDivZBF6Io7JYmV+ZXu263sQF9tr03RABh/7WGu+O0Fk bVMPSmtsUyEDBmy5M78BusE2eOA9MQIXFgMCmmawQQMHBBgFaZqmaQ0GCQcMwQYZpAgJChv2 vReQC1c7Bw9XgnSDDRATEQMSkMEG+RchNQ9BwQYbZENQM1IXBhtssFMHV19Ze2ymabrBF22r IHAcBvtekHLHL4CzgRtksMEHgh+DhI8ZpGkGkSmeoWyQwQakb6e3n3IQBhvOH9cLGAfZe65q iQOVAQMgkxwoIEgMIBPJABCEEIEMyISBAQzIgAwQggKZmwyBEL8AadJdVQEHLl8M0g32wAsX HQsElsggzYCNCI4MyIAMj5CRgAzIgJKTslEM0gOvCjeMJC8LbwyjAAWTGela8GPTNGiDBwjP NMumCdxnCrg3mqZpuowHEVwSOBM0y6ZpDBjUZhms0zRN0xp0GzwcZdM0TRR4BHn0ZROVaZp6 5PwG2IfXvUcP+MBDAgTSzw723aQPYIJ5giGvpt8HoaXN8+8ngZ/g/C9AfoD8qMFy9gjjo9qj j4H+B0CDDIENtS9Btl8h/3dfz6LkohoA5aLoolt+of6y3+4+UQUD2l7aX1/aatoyL6lol7/T 2N7g+TF+OYNYACoKACoqCUEBVCCrAqhARgVQgYwKoAIZFEAFMmyGqGwDxBhQsU0UsAEgQ1AH x1pUbQZJMQpTdCkqR1SZSKJahqxXD0FNI6r/m1lCeXRlVG9XaWRlQ762UAFbFEgEUh2AbYuq NWMMVvuDRaijDVJ0bFVudz+133tsZEpPRU1vL0NyBDV2+6xFC0Rlc2NveSJGPdhrRBBremRI YarOSrc7bA1TCkNFAWOmQh1FC2HPks2jc1cXFrZkbVistsEURhTVCNuDZURRQLfdAUFkZCFz PUzuLApo4bxBDdmFzdpDTbMsDVf9pKhiL1lGGNhWVO1EFlVvPq0w7MJDGHNl1jZZbe0Xe/Lg CFBvMZtycOaqyrFrGmwwT8LNHgduQSBTaXqK6uxNQg8ZU+r2zf4DVGltegha2WVJbXvLqAoX zGOg3/u6ZyVfbEJkB2OUCG8v2fYKeiYHYsUL+ORvCM+KY3B5TW9ka287VkyATmFOQT4fMgyD bW5rmkZ5mEYBClSdxfIKTvK4rHXLGftyUcJEzm6D3Gp2ZVMUZXCxYQx7RdUjDPMwfm8rwwN4 MeVjaxJsILRGRjEPnjSchMNpIXRhnnC17jY7ERA5bW0fTInbrKiCIbkLReERIcZ4aQP/pAAK OOEFChdUqpfspHtlJlBsY9mBADn8aH+DO2xtZE8QcIOf35qlIYx8QZ7RANqCu3EbZ1ORe3Uo FnsE9+0PSEtleQzvs7dsbB9BEB4Osll6hk/KDPHedFFC4cJ2TgJ3SWtQCbMq4DTbcxrrGLPb GJAdAbFwjnRmoX08XfYgJEmXbj02tVcFHG5u27XZNsvN/yMCASz/cwIEZVmWZRAWEw8MlmVZ lgk3CzQXFLOWZVkVEW8Dpf9D/stQRUwBBABZ9DBA4AAPAgsBAjig6vcOCgMA5DrYWfdOVoAN KhAPBDO5Y98sBx8BDAPbm0s2sO8PJBAHBjeBy7McKGmMcGANaoXcBgJgHnwBF2zXcS7GdAeU TpDnINhc2ARFIC5yuvdsDgIjDmAUJ1Ruse5CQAIuJifc4m1KBmmAdMBPG5t9pXPFSg3ze5RP AP9+Kxswaw2SdAEAAAAAAAAAgAT/AAAAAAAAAAAAAABgvhVQQQCNvuu//v9Xg83/6xCQkJCQ kJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR23Pk McmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHbdQeL HoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj ////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5RAEAAIoHRyzoPAF394A/BXXyiweKXwRm wegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AcAEAiwcJwHRFi18EjYQwZJ0BAAHzUIPHCP+W 8J0BAJWKB0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+W9J0BAAnAdAeJA4PDBOvY/5b4nQEAYem3 qP7/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AwAAACAAAIAOAAAAYAAAgAAAAAAAAAAAAAAAAAAAAQABAAAAOAAAgAAAAAAAAAAAAAAAAAAA AQAHBAAAUAAAAKSgAQCoDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAZQAAAHgAAIAAAAAA AAAAAAAAAAAAAAEABwQAAJAAAABQrQEAFAAAAAAAAAAAAAAAoHABACgAAAAgAAAAQAAAAAEA GAAAAAAAgAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACAgID///////////////////////////////////////////////////// ///////////////////////////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA gID///////////////////////////////////////////////////////////////////// ///////////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////// //////////////////////////////////////////////////////////////////////// ///AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////// ///////////////////////AwMDAwMDAwMDAwMDAwMDAwMD////////////AwMAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////////////////// ///////////////////////////////////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACAgID////////////AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA wMDAwMDAwMDAwMD////////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///// //////////////////////////////////////////////////////////////////////// ///////////AwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID////////////AwMDAwMDA wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD////////////AwMAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////////// ///////////////////////////////////////////////////AwMAAAAD/AAAAAAD/AAAA AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAADAwMDAwMDAwMDAwMDAwMDA wMDAwMDAwMDAwMDAwMDAwMD////////////AwMAAAAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/ AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD///////////////////////////////////// ///////////////////AwMAAAAD/AAAAAAD///////////////////////////////////// ////////////AAAAAADAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD///////// ///AwMAAAAAAAAD/AAD/////AAAAAAD/AAD/////AAAAAAD/AAAAAAD///////////8AAAD/ AAD////////////////////////////////////////////////////////AwMAAAAD/AAAA AAD///8AAAD/AAAAAAD///8AAAD/AAAAAAD/AADAwMD/////////AAAAAADAwMDAwMDAwMDA wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD////////////AwMAAAAAAAAD/AAD/////AAAAAAD/ AAD/////AAAAAAD/AAAAAACAgID///////8AAAD/AAD///////////////////////////// ///////////////////////////AwMAAAAD/AAAAAAD///8AAAD/AAAAAAD/AAAAAAD/AAAA AAD/AAAAAAD/////////AAAAAADAwMDAwMD////////AwMDAwMDAwMDAwMDAwMDAwMDAwMD/ ///////////AwMAAAAAAAAD/AAD/////AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AADAwMD/ //8AAAD/AAD////////////////AwMDAwMDAwMD////AwMDAwMDAwMD////////////AwMAA AAD/AAAAAAD///8AAAD/AAD/////AAAAAAD/AAD/////AAAAAACAgID/////AAAAAADAwMDA wMD////////AwMDAwMD////////////////AwMD////////////AwMAAAAAAAAD/AAAAAAD/ AAAAAAD///8AAAD/AAAAAAD///8AAAD/AAAAAAD///8AAAD/AAD////////////////AwMDA wMDAwMD////////AwMDAwMD////////////AwMAAAAD/AAAAAAD/AAAAAAD/AAD/////AAAA AAD/AAD/////AAAAAAD/AAAAAAD/AAAAAADAwMDAwMD////////AwMD///////////////// ///AwMD////////////AwMAAAAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/ AAAAAAD/AAAAAAD/AAD////////////////AwMDAwMD///////+AgIAAAAAAAAAAAAAAAAAA AAAAAAAAAAD/AAAAAAD/////////////////////////////////////////////////AAAA AAD////////////////AwMDAwMDAwMDAwMCAgID////////////AwMCAgIAAAAAAAAAAAAD/ AAD///////////////////////////////////////////////8AAAD/AAD///////////// ///AwMDAwMDAwMDAwMCAgID////////AwMCAgIAAAAAAAAAAAAD/AAAAAAD/AAAAAAD/AAAA AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD///////////////////////////// //+AgID////AwMCAgIAAAAAAAAAAAAAAAAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/ AAAAAAD/AAAAAAD/AAAAAAD/AAD///////////////////////////////+AgIDAwMCAgIAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////// //////////////////////////////////////////+AgICAgIAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgID///////////////////////////////////// //////////////////////////+AgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA gICAgICAgICAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD//////gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAA/gAAAP4A AAD+AAAA/gAAAP4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAAAwAAAAcAAAAP/gAAH/4AAD/+AAB//////0h9AQAAAAEAAQAgIAAA AQAYAKgMAAABAAAAAAAAAAAAAAAAACiuAQDwrQEAAAAAAAAAAAAAAAAANa4BAACuAQAAAAAA AAAAAAAAAABCrgEACK4BAAAAAAAAAAAAAAAAAE+uAQAQrgEAAAAAAAAAAAAAAAAAWq4BABiu AQAAAAAAAAAAAAAAAABmrgEAIK4BAAAAAAAAAAAAAAAAAAAAAAAAAAAAcK4BAH6uAQCOrgEA AAAAAJyuAQAAAAAAqq4BAAAAAAC8rgEAAAAAAMiuAQAAAAAAAwAAgAAAAABLRVJORUwzMi5E TEwAQURWQVBJMzIuZGxsAGlwaGxwYXBpLmRsbABVU0VSMzIuZGxsAFdJTklORVQuZGxsAFdT Ml8zMi5kbGwAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAA UmVnQ2xvc2VLZXkAAABHZXROZXR3b3JrUGFyYW1zAAB3c3ByaW50ZkEAAABJbnRlcm5ldEdl dENvbm5lY3RlZFN0YXRlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEsBAhQACgAAAAAA4jhUMF1usCIAVgAA AFYAABAAAAAAAAAAAAAgAAAAAAAAAGRvY3VtZW50LnR4dC5waWZQSwUGAAAAAAEAAQA+AAAA LlYAAAAA --57570782-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 04:03:02 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10678 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 04:03:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Au6Vj-000Iyw-O8 for namedroppers-data@psg.com; Fri, 20 Feb 2004 08:59:51 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Au6Vi-000Iyk-O0 for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 08:59:50 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i1K8xoiA014167 for <namedroppers@ops.ietf.org>; Fri, 20 Feb 2004 00:59:50 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id <T67dcd83b8e118064cc748@mailgate2.apple.com>; Fri, 20 Feb 2004 00:59:50 -0800 Received: from [17.219.197.152] ([17.219.197.152]) by relay2.apple.com (8.12.11/8.12.11) with SMTP id i1K8xjGl005317; Fri, 20 Feb 2004 08:59:46 GMT Message-Id: <200402200859.i1K8xjGl005317@relay2.apple.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 20 Feb 2004 00:59:45 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire <cheshire@apple.com> To: "Christian Huitema" <huitema@windows.microsoft.com>, <namedroppers@ops.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Christian Huitema wrote: >There is certainly a very strong case that multicast packets should be >sent with the shortest possible TTL, in order to minimize the risk of >flooding entire networks. Exactly what is the "risk of flooding entire networks" here? Just about every network printer bought by Microsoft or anyone else in the last year has Rendezvous in it, and sends multicast packets with TTL 255 to the link-local address 224.0.0.251. If there were any actual case of a defective router incorrectly forwarding these link-local multicast packets and "flooding entire networks", don't you think someone would have noticed by now? Stuart Cheshire <cheshire@apple.com> * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 07:56:18 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19754 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 07:56:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuA8D-000GxN-QZ for namedroppers-data@psg.com; Fri, 20 Feb 2004 12:51:49 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuA8A-000Gwo-96 for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 12:51:46 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i1KCpbW07667; Fri, 20 Feb 2004 19:51:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1KCn8e08864; Fri, 20 Feb 2004 19:49:12 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Stuart Cheshire <cheshire@apple.com> cc: "Christian Huitema" <huitema@windows.microsoft.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <200402200859.i1K8xjGl005317@relay2.apple.com> References: <200402200859.i1K8xjGl005317@relay2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Feb 2004 19:49:08 +0700 Message-ID: <26638.1077281348@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 20 Feb 2004 00:59:45 -0800 From: Stuart Cheshire <cheshire@apple.com> Message-ID: <200402200859.i1K8xjGl005317@relay2.apple.com> | Just about every network printer bought by Microsoft or anyone else in | the last year has Rendezvous in it, and sends multicast packets with TTL | 255 to the link-local address 224.0.0.251. If there were any actual case | of a defective router incorrectly forwarding these link-local multicast | packets and "flooding entire networks", don't you think someone would | have noticed by now? One of two things is being observed there - first, that the vast majority of routers installed don't forward multicast packets at all, currently anyway, so noticing that they're not forwarding particular multicast packets isn't providing much in the way of useful information. Second, assuming that none of the routers that do have multicast turned on is forwarding those packets (and that "not noticed by now" isn't just that there isn't yet enough of it for anyone to care), is telling us that routers handle link local multicast correctly, and don't forward link local multicast off the origin link. In fact, using TTL==255 is relying on routers doing that correctly, if there are routers with bugs that allow link local multicast to be forwarded, then Christian's "flooding the entire network" would be exactly what would happen, wouldn't it? So, let's assume that routers are correctly not forwarding link local multicast. In that case, what's the point of the TTL==255 stuff (for multicast packets anyway) ? The only rationale for using TTL 255, is to allow hosts to validate that the packets haven't been forwarded by a router. If the TTL arrives with a value of 255 we assume no router touched it (because TTL decrementing is something that experience has taught us that routers actually do correctly). But this is obviously unnecessary - we've already assumed that routers block link local multicast packets - if the routers are blocking (not forwarding) link local multicast packets, and we can assume that is correctly functioning, then there's no point at all in the host doing any kind of TTL==255 check, that is just a waste of time - and if the hosts aren't going to check it, there's also no point in sending TTL==255. Of course, there was that assumption, that routers are in fact going to block link local multicast. What happens if that proves to be incorrect? Well, in that case not doing the TTL==255 check at the recipient allows off net sourced packets to be received and processed, but now we have packets flooding the net. Which is those is the greater harm if not prevented? IMNSHO, the packet flooding is the greater harm, and it is that which needs to be prevented (at almost any cost). I'm not sure I see any enormous harm in LLMR packets being received from off link (certainly nothing worse than lots of other spoofed packets that might be received). So, once again, I'd require that all intended-to-be-link-local multicast packets be sent with a TTL of 1 - it just means that if there do happen to be any defective routers, which don't know what is special about 224.0.0.*/24 and forward the packets, then the TTL->0 when it is decremented will prevent forwarding. If there are no such defective routers the TTL==255 thing is a waste of time anyway. On the other hand, for unicast packets, wherever they are used in LLMR, the "flooding" argument is meaingless, and (aside from when they happen to be to or from an LL address) won't be being blocked by routers. They also do no real harm to the net when forwarded (even if they end up nowhere). There if there's any gain to be had from detecting off link sourced packets, I see no reason to lose it. So, sending any unicast packets with a TTL of 255 (and validating that they arrive with the TTL still being 255, if the host cares) seems reasonable to me. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 12:47:52 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03558 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 12:47:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuEf2-0006L8-TH for namedroppers-data@psg.com; Fri, 20 Feb 2004 17:42:00 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuEey-0006HP-CM for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 17:41:56 +0000 Received: from [10.255.207.98] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id 25FDE1B22A6; Fri, 20 Feb 2004 11:29:08 -0600 (CST) In-Reply-To: <26638.1077281348@munnari.OZ.AU> References: <200402200859.i1K8xjGl005317@relay2.apple.com> <26638.1077281348@munnari.OZ.AU> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13362B87-63CC-11D8-A3A6-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: Stuart Cheshire <cheshire@apple.com>, "Christian Huitema" <huitema@windows.microsoft.com>, namedroppers@ops.ietf.org From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 20 Feb 2004 12:41:55 -0500 To: Robert Elz <kre@munnari.OZ.AU> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Personally, I find it amazing when people build huge pyramids of logic on top of premises like "we can't depend on the routers to be correct." It's true that we can't depend on routers to be correct - don't get me wrong. But when routers are not correct, the solution is to fix the router, or throw it out, not to demand that all network protocols account for every possible way that a router can be broken. So what's the scenario where the router would do the wrong thing in this case? How likely is it that an implementation mistake would result in the wrong thing happening? Because I've thought about this, and to me it looks like you'd have to do a proactively bad implementation to get the behavior you're talking about - it wouldn't be enough to just forget to check something. Furthermore, in order for the doomsday scenario Christian described to come to pass, *every router on the internet* would have to be broken *in the same way*. Am I wrong here? Can you or Christian explain why it's so likely that this scenario could come to pass? Thanks! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 13:15:13 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04933 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 13:15:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuF8U-000F83-FR for namedroppers-data@psg.com; Fri, 20 Feb 2004 18:12:26 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuF8T-000F7f-9D for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 18:12:25 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i1KICOBv025091 for <namedroppers@ops.ietf.org>; Fri, 20 Feb 2004 10:12:25 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id <T67ded2221b118064cc748@mailgate2.apple.com>; Fri, 20 Feb 2004 10:12:24 -0800 Received: from [17.219.197.241] ([17.219.197.241]) by relay3.apple.com (8.12.11/8.12.11) with SMTP id i1KICMGo010517; Fri, 20 Feb 2004 18:12:23 GMT Message-Id: <200402201812.i1KICMGo010517@relay3.apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 20 Feb 2004 10:12:23 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire <cheshire@apple.com> To: "Robert Elz" <kre@munnari.OZ.AU> cc: "Christian Huitema" <huitema@windows.microsoft.com>, <namedroppers@ops.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >what's the point of the TTL==255 stuff (for multicast >packets anyway) ? The immediate value is primarily for unicast packets, and less so for multicast packets. When Rendezvous sends a multicast query, and the peers on the local link respond with unicast responses back to the querier, then checking TTL=255 on reception verifies that no off-net interloper has managed to slip a few remote unicast responses in with the legitimate local unicast responses. The value for multicast packets is an indirect code hygiene benefit: suppose a router vendor were to make a future multicast router that incorrectly forwards 224.0.0/24 packets. This could expose hosts to off-net attack. By setting and checking TTL=255, hosts are protected from this vulnerability, and because of the resultant traffic forwarding, the problem is detected and the router is fixed before it even gets through QA testing. Suppose we used TTL=1 instead: Now the router bug might go unnoticed for months or years, until the product is deployed in millions of homes around the world, and then some hacker finds it and exploits it. Stuart Cheshire <cheshire@apple.com> * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 15:18:07 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11674 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 15:18:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuH0C-0008sF-7z for namedroppers-data@psg.com; Fri, 20 Feb 2004 20:12:00 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuH08-0008s2-Ul for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 20:11:57 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i1KKAsmP016635; Sat, 21 Feb 2004 03:10:54 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1KK6LX21550; Sat, 21 Feb 2004 03:06:23 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Ted Lemon <mellon@nominum.com> cc: Stuart Cheshire <cheshire@apple.com>, "Christian Huitema" <huitema@windows.microsoft.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <13362B87-63CC-11D8-A3A6-000A95D9C74C@nominum.com> References: <13362B87-63CC-11D8-A3A6-000A95D9C74C@nominum.com> <200402200859.i1K8xjGl005317@relay2.apple.com> <26638.1077281348@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Feb 2004 03:06:21 +0700 Message-ID: <27314.1077307581@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 20 Feb 2004 12:41:55 -0500 From: Ted Lemon <mellon@nominum.com> Message-ID: <13362B87-63CC-11D8-A3A6-000A95D9C74C@nominum.com> | Personally, I find it amazing when people build huge pyramids of logic | on top of premises like "we can't depend on the routers to be correct." No, you missed the point - which was (and Stuart's reply that just followed yours confirms it) that for multicast, the TTL==255 check is meaningful only if you assume that the router bug exists. If there would be no such bug, the test is totally meaningless. | It's true that we can't depend on routers to be correct - don't get me | wrong. But when routers are not correct, the solution is to fix the | router, or throw it out, not to demand that all network protocols | account for every possible way that a router can be broken. Partly true - but we must also make the protocols resilient to plausible failure modes. After all, that's why we have the TTL in packets in the first place - if we could rely upon either correct routers, or the "fix whatever is broken" approach, we wouldn't need the TTL, as packets would always go to their destination, or be dropped, they'd never loop. But we simply aren't prepared to make either of those assumptions, the net has to keep working, even when parts of it are malfunctioning. | So what's the scenario where the router would do the wrong thing in | this case? How likely is it that an implementation mistake would | result in the wrong thing happening? Because I've thought about this, | and to me it looks like you'd have to do a proactively bad | implementation to get the behavior you're talking about - it wouldn't | be enough to just forget to check something. All that's needed is for the definition of what is a LL multicast to be entered incorrectly (say 224.0.0/25 instead of /24 - most simple tests wouldn't notice the problem, but the 224.0.0.251 addr would sure fall through it) | Furthermore, in order | for the doomsday scenario Christian described to come to pass, *every | router on the internet* would have to be broken *in the same way*. Is that really so hard to imagine? Can't you imagine a scenario where almost all of the internet is run using one vendor's routers, built out of one vendor's common code base? It isn't everything that has to be broken, just enough to cause lots of trouble. | Am I wrong here? Can you or Christian explain why it's so likely that | this scenario could come to pass? I don't think it is likely at all. But if the routers aren't going to be broken this way, and I don't think they are likely to be, then there's no point at all doing the TTL==255 check for multicast, as any packet that would fail it, will have already been dropped by the router. Stuart Cheshire <cheshire@apple.com> said: | The immediate value is primarily for unicast packets, and less so for | multicast packets. This is looking promising, as I think just about all of the arguments for TTL=1 rather than TTL=255 come from the multicast arguments. If we can get the "less so" down to "irrelevant for", then perhaps we have a compromise in the offing. | When Rendezvous sends a multicast query, and the peers on the local link | respond with unicast responses back to the querier, then checking TTL=255 | on reception verifies that no off-net interloper has managed to slip a few | remote unicast responses in with the legitimate local unicast responses. Fine, I have no problem with this (though the problem that is being solved still exists in the DNS without DNSSEC - once DNSSEC is done, a DNSSEC type approach to LLMR is likely to be a better, and much safer, way to solve this problem). | The value for multicast packets is an indirect code hygiene benefit: | suppose a router vendor were to make a future multicast router that | incorrectly forwards 224.0.0/24 packets. This could expose hosts to | off-net attack. Yes, but it would also cause the multicast queries (with TTL==255, and any other multicast replies) to get sent to places where they're not supposed to go. That would be a much more serious problem. And even if the TTL checks happen to protect LLMR (or Rendezvous) they're not going to protect other users of LL multicast addresses. That is, this would be a serious problem, and as Ted said, one that warrants getting the router fixed (we still need the network working while that is happening - but we can tolerate some security risk, after all, we can always filter out the packets that we don't want to receive). | By setting and checking TTL=255, hosts are protected from this | vulnerability, and because of the resultant traffic forwarding, the problem | is detected and the router is fixed before it even gets through QA testing. If someone is doing QA testing of this kind of thing in the router at all, I don't think they're going to be relying on LLMR/Rendezvous reporting that it is dropping packets because their TTL isn't 255.... | Suppose we used TTL=1 instead: Now the router bug might go unnoticed for | months or years, until the product is deployed in millions of homes around | the world, and then some hacker finds it and exploits it. If there is a vulnerability here that is so important, that we need this kind of mechanism to protect against this unlikely scenario, then the whole thing badly needs a re-think. If getting a packet through a router is all it takes to wreak havoc on a host or net (which this is suggesting), then there are lots of other methods, rather than imagining a broken router that happens to allow forwarding of LL multicast (and as Ted indicated, you'd actually need a whole chain of such things, between the hacker and the victim) and yet correctly decrements the TTL. Much more likely would be for the hacker to get a virus onto some system on the local net (we all know how easy that is to accomplish), where the virus sets up a tunnel end point which simply decapsulates packets and forwards them (any and all packets, with no TTL adjustments). This is far more likely to happen than the broken router scenario, and in this setup, the TTL==255 check is of no benefit whatever - the packets can have a 255 TTL if that is what is needed to get them accepted. If we now have a problem that makes LLMR too insecure to use, then we need to abandon LLMR (as it is now anyway), and think of something different - or at least some other fix that isn't depending upon anything so crude as the value of a field in the IP header. If this doesn't make LLMR unacceptable to one and all, then clearly the TTL test isn't achieving anything, and may as well be dropped (for multicast packets) - it is irrelevant. Once the check is dropped, then the multicast packets can be sent with TTL=1 and everyone will feel just that little bit happier about that very unlikely (but horrible should it occur) possibility of broken routers incorrectly forwarding the packets. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 17:56:15 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18908 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 17:56:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuJVS-00097m-A4 for namedroppers-data@psg.com; Fri, 20 Feb 2004 22:52:26 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AuJVQ-00097O-Js for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 22:52:24 +0000 Received: (qmail 83903 invoked from network); 20 Feb 2004 23:11:01 -0000 Received: from h219-110-032-209.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.209) by necom830.hpcl.titech.ac.jp with SMTP; 20 Feb 2004 23:11:01 -0000 Message-ID: <4036901B.6060501@necom830.hpcl.titech.ac.jp> Date: Sat, 21 Feb 2004 07:54:19 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Stuart Cheshire <cheshire@apple.com> CC: Robert Elz <kre@munnari.OZ.AU>, Christian Huitema <huitema@windows.microsoft.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <200402201812.i1KICMGo010517@relay3.apple.com> In-Reply-To: <200402201812.i1KICMGo010517@relay3.apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Stuart Cheshire; > When Rendezvous sends a multicast query, and the peers on the local link > respond with unicast responses back to the querier, then checking TTL=255 > on reception verifies that no off-net interloper has managed to slip a > few remote unicast responses in with the legitimate local unicast > responses. It is unwise to use not DNS but Rendesvous, when LAN is connected to the Internet. > The value for multicast packets is an indirect code hygiene benefit: > suppose a router vendor were to make a future multicast router that > incorrectly forwards 224.0.0/24 packets. This could expose hosts to > off-net attack. By setting and checking TTL=255, hosts are protected from > this vulnerability, and because of the resultant traffic forwarding, the > problem is detected and the router is fixed before it even gets through > QA testing. Suppose we used TTL=1 instead: Now the router bug might go > unnoticed for months or years, until the product is deployed in millions > of homes around the world, and then some hacker finds it and exploits it. Any protocol which relies LAN, which is connected to the Internet, is secure is insecure. Note that the LAN may be connected to other LAN with Ethernet over IP. Never bother to improve quality of illusion of security. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Feb 20 21:38:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29100 for <dnsext-archive@lists.ietf.org>; Fri, 20 Feb 2004 21:38:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuMyJ-000GyR-CM for namedroppers-data@psg.com; Sat, 21 Feb 2004 02:34:27 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuMyH-000Gy8-F8 for namedroppers@ops.ietf.org; Sat, 21 Feb 2004 02:34:25 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1L2YHLN082877 for <namedroppers@ops.ietf.org>; Fri, 20 Feb 2004 21:34:17 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1L2YGFD082876 for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 21:34:16 -0500 (EST) Received: from [64.4.11.120] (helo=hotmail.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuE4R-000NEt-58 for namedroppers@ops.ietf.org; Fri, 20 Feb 2004 17:04:11 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Feb 2004 09:04:10 -0800 Received: from 207.46.238.137 by by7fd.bay7.hotmail.msn.com with HTTP; Fri, 20 Feb 2004 17:04:09 GMT X-Originating-IP: [207.46.238.137] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" <bernard_aboba@hotmail.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 20 Feb 2004 09:04:09 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <BAY7-F120CSR9OgSNnB0007edc5@hotmail.com> X-OriginalArrivalTime: 20 Feb 2004 17:04:10.0254 (UTC) FILETIME=[8ECE22E0:01C3F7D3] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Robert Elz has made a convincing argument why TTL=1 should be set on multicast packets. It also makes sense to set TTL=1 on LLMNR packets sent via unicast TCP, since if this is done the TCP three way handshake will ensure that a connection will only be set up to a host on the same link. If TTL=255 were set on the TCP SYN, then an LLMNR connection could be set up to any host on the Internet. This doesn't make sense for linklocal name resolution. Then there is the issue of what the TTL should be on UDP unicast packets. There are two cases here: UDP unicast queries and UDP unicast responses. Unicast UDP queries will presumably be sent largely to resolve PTR RRs; this is not the recommended transport, but it can be used. Therefore I would make the same argument as for TCP queries, namely that TTL=1. There is no reason for a linklocal name resolution protocol to send queries all over the Internet. So we are left with the question of the TTL for UDP unicast response packets. Here we could set TTL=255 and (optionally) check on reception as Robert proposes, or we could set TTL=1. In thinking about the risks/benefits of this, it's important to keep in mind the risks of DoS attack. In the existing LLMNR specification, there is no support for "wildcard" queries. However, the DISCOVER Opcode specification, if run on top of LLMNR, would add this capability. Once "wildcard" queries are supported, we now have the possibility of an attacker sending a wildcard query from a spoofed address, and causing the victim to be deluged with responses. Even with TTL=1 on responses this attack exists, but can only be used to attack someone on the local network. With TTL=255 set on responses, it can be used to attack anyone on the Internet. To my mind, this was the argument that tipped the balance in favor of setting TTL=1 on UDP responses. Note that this deicision is not mandated by the IPv4 Linklocal TTL specification. In Section 2.7 of that specification, it is stated: A sensible default for applications which are sending from a Link- Local IPv4 address is to explicitly set the IPv4 TTL to 1. This is not appropriate in all cases as some applications may require that the IPv4 TTL be set to other values. LLMNR responses can be sent from any source address, so this text does not apply in many situations. Also, the above text leaves the decision to the application. So I think that this is purely an LLMNR decision. _________________________________________________________________ Take off on a romantic weekend or a family adventure to these great U.S. locations. http://special.msn.com/local/hotdestinations.armx -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Feb 21 00:34:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04033 for <dnsext-archive@lists.ietf.org>; Sat, 21 Feb 2004 00:34:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuPiW-000JAm-2Q for namedroppers-data@psg.com; Sat, 21 Feb 2004 05:30:20 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuPiF-000J82-0r for namedroppers@ops.ietf.org; Sat, 21 Feb 2004 05:30:03 +0000 Received: from [192.168.1.109] (66-65-58-35.nyc.rr.com [66.65.58.35]) by toccata.fugue.com (Postfix) with ESMTP id C943D1B2D14; Fri, 20 Feb 2004 23:17:09 -0600 (CST) In-Reply-To: <27314.1077307581@munnari.OZ.AU> References: <13362B87-63CC-11D8-A3A6-000A95D9C74C@nominum.com> <200402200859.i1K8xjGl005317@relay2.apple.com> <26638.1077281348@munnari.OZ.AU> <27314.1077307581@munnari.OZ.AU> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <FF98CA65-642E-11D8-9D00-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> From: Ted Lemon <Ted.Lemon@nominum.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sat, 21 Feb 2004 00:30:02 -0500 To: Robert Elz <kre@munnari.OZ.AU> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 20, 2004, at 3:06 PM, Robert Elz wrote: > | Am I wrong here? Can you or Christian explain why it's so likely > that > | this scenario could come to pass? > > I don't think it is likely at all. But if the routers aren't going to > be broken this way, and I don't think they are likely to be, then > there's > no point at all doing the TTL==255 check for multicast, as any packet > that > would fail it, will have already been dropped by the router. > > > Stuart Cheshire <cheshire@apple.com> said: > > | The immediate value is primarily for unicast packets, and less so > for > | multicast packets. > > This is looking promising, as I think just about all of the arguments > for > TTL=1 rather than TTL=255 come from the multicast arguments. If we > can > get the "less so" down to "irrelevant for", then perhaps we have a > compromise > in the offing. Okay, I'm happy. I don't really care about the multicast argument as long as it doesn't prevent forward progress. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Feb 23 14:22:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13547 for <dnsext-archive@lists.ietf.org>; Mon, 23 Feb 2004 14:22:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvLZo-000NWS-Tw for namedroppers-data@psg.com; Mon, 23 Feb 2004 19:17:12 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvLZn-000NW5-FI for namedroppers@ops.ietf.org; Mon, 23 Feb 2004 19:17:11 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i1NJDhKa028280; Mon, 23 Feb 2004 14:13:43 -0500 (EST) Received: from unknown(158.69.80.188) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0iaio3; Mon, 23 Feb 04 14:13:41 -0500 Subject: Re: draft: resolver-application interface From: Suresh Krishnaswamy <suresh@tislabs.com> To: Miek Gieben <miekg@atoom.net> Cc: namedroppers <namedroppers@ops.ietf.org> In-Reply-To: <20040212144444.GA18697@atoom.net> References: <20040212144444.GA18697@atoom.net> Content-Type: text/plain Message-Id: <1077563670.1989.62.camel@spooky.columbia.sparta.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 23 Feb 2004 14:14:30 -0500 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Miek, I think this draft is a good start towards defining the interface between the resolver and the application for signalling error and status information. You've already covered some of the following error codes; I've tried to disambiguate (for my own reference mostly) the meaning associated with some of them. XX UNSECURE - No signatures are present, not required to be present either (provable non-existence of parent DS, no local trust anchor) XX INDETERMINATE - signatures present, DNSKEY record present, but no authentication chain could be found that would allow validation of the signatures (missing or different local trusted anchor, provable non-existence of parent DS, or parent DS does not cover the zone DNSKEY). Q. Is this same as bit field 9 -- delegation problem DS/KEY ? 00 NODNSKEY - signatures present, but no DNSKEY could be retrieved for the zone 05 BOGUS - some signature was required to be present (parent DS said so, or by local trusted anchor setting),the sig was present but it failed validation 01 NODS - DS should have been present in the parent (some NSEC told us so) but the DS record could not be retrieved. 02-03 only relevant to the signature verification operation directly -- so these error codes indicate the absence of NSECs, SIGs for the name being directly queried for (and not the absence of NSECs, SIGs that would otherwise tell us that the parent DS is missing for example). Is the above interpretation same as what you had envisioned? I also seemed to think that there was a need for the following additional status codes as well: XX NOCLRPATH - one or more intermediate name servers does not support DNSSEC XX LOCPOL - some local policy decision has contributed to the resultant set of RRs/flags An open question is whether the error/status codes should actually be defined as extended RCODEs as opposed to a bit array. Suresh On Thu, 2004-02-12 at 09:44, Miek Gieben wrote: > Hello, > > During the LCWS workshop of a few weeks ago the topic was also discussed: what > does an application wants/needs to know from a secure aware resolver. I then > said I was working on a draft trying to initiate and focus that discussion. > > During the last few days this topic has also (sort of) sprung up on the > namedroppers ML. I'm not sure the draft is dnsop or dnsext material, but > I'm posting it here as I feel we were already discussing these sort of > things. > > It is still a *very rough* draft, but I didn't want it to delay any more > than it already has. > > Authors: > Gilles Guette, Olivier Courtay and Miek Gieben > > Abstract: > This document describes an interface between a DNSSEC aware resolver > and an application. This interface will define which kind of > information a DNSSEC aware resolver is able to send back to an > application. The basic question we want to answer is: "What does an > application wants to know from a secure aware resolver?". > > In section Section 4 we define an error bit array. The secure aware > resolver will set specific bits in the array. With the added > information in this error array, the application can have extra > control on what to do with bogus data. > > This document is written in the hope that it will lead to a > discussion within the IETF on the resolver-application > interaction(s). > > Where: > http://www.nlnetlabs.nl/dnssec/draft-gieben-resolver.txt > > > grtz > Miek > -- > ...all white space is equivalent except in certain situations... > - C99 Standard -- http://www.vmunix.com/~gabor/c/draft.html > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 08:46:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19871 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 08:46:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avcjm-0003AH-85 for namedroppers-data@psg.com; Tue, 24 Feb 2004 13:36:38 +0000 Received: from [199.5.47.154] (helo=usvwoaahs35.abh.vw.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avcjl-0003A4-Ac for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 13:36:37 +0000 Received: by usvwoaahs35.abh.vw.com with Internet Mail Service (5.5.2657.72) id <1XW2MN2X>; Tue, 24 Feb 2004 08:36:36 -0500 Message-ID: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> From: "Burns, Mike" <Extern.Mike.Burns@gedas.com> To: "'Stuart Cheshire'" <cheshire@apple.com> Cc: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org>, "'Robert Elz'" <kre@munnari.OZ.AU>, "'Christian Huitema'" <huitema@windows.microsoft.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 24 Feb 2004 08:36:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 20 Feb 2004, Stuart Cheshire wrote: >then checking TTL=255 >on reception verifies that no off-net interloper has managed to slip a >few remote unicast responses in with the legitimate local unicast >responses. If you check for TTL>1 then the interloper could only come from 1 hop away, which in most cases is a router core network(ISP,Corp) with a limited number of hosts. >This could expose hosts to >off-net attack. By setting and checking TTL=255, hosts are protected from >this vulnerability Neither setting will protect the host since it could be bombarded by a DDOS. Regardless of the TTL, the packet will still have to be processed by the host. >Suppose we used TTL=1 instead: Now the router bug might go >unnoticed for months or years, until the product is deployed in millions >of homes around the world Check for TTL>1 if you insist. It seems much more likely that a large deployment of a virus could infect a number of hosts then send LLMNR packets to flood a victim when the TTL=255, than if the TTL=1. If the TTL=1, then the packet would have to be crafted, which is easily enough to do on a distributed basis, but is not common (crafting of packets with a virus). Most virus creators are lazy and use the existing OS functionalities. Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 12:37:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00639 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 12:37:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvgQe-00037s-Di for namedroppers-data@psg.com; Tue, 24 Feb 2004 17:33:08 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvgQb-00037e-V6 for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 17:33:06 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i1OHVSmP027573; Wed, 25 Feb 2004 00:31:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1OHSbQ11429; Wed, 25 Feb 2004 00:29:08 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: "Burns, Mike" <Extern.Mike.Burns@gedas.com> cc: "'Stuart Cheshire'" <cheshire@apple.com>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org>, "'Christian Huitema'" <huitema@windows.microsoft.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> References: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Feb 2004 00:28:36 +0700 Message-ID: <20558.1077643716@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 24 Feb 2004 08:36:35 -0500 From: "Burns, Mike" <Extern.Mike.Burns@gedas.com> Message-ID: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> | If you check for TTL>1 then the interloper could only come from 1 hop | away, This is nonsense. If one wants to check whether the sender is local, at the receiver, the only thing that works is to set TTL=255, and check that the TTL is still 255 when the packet arrives. Checking that the arriving TTL is 1 is an absolute waste of time. If you don't understand this, you most likely shouldn't be participating in this debate, as you're just confusing the issue. | Neither setting will protect the host since it could be bombarded by a | DDOS. Anyone can bombard the host with any packets at all. Neither LLMNR nor Rendezvous has anything whatever to do with that. Worrying about that happening is absurd (by which I mean, only worry about things that you can control, the uncontrollable will either happen, or not, whatever we do - or worry about). The TTL=1 argument provides nothing at all that helps avoid DoS attacks - what the specification says should be done is irrelevant to an attacker, if they want to bombard you, and they're 10 hops away, they'll set the TTL to 11 (or more) regardless of what the spec says it should be set to. Using TTL of 1 (for multicast packets) is to avoid the legitimate traffic, packets that are supposed to be there, from possibly escaping and being sent further than they should (a quite remote possibility, but one which would be bad if it happened). For unicast packets, being able to verify that the host is on link just may have some (small) benefit, stopping packets accidentally escaping has essentially none, so TTL of 255 there makes (some) sense. While Bernard is right, that for TCP, a TTL of 1 would also work, I don't think I really want that level of detail being checked, and would prefer if simply all unicast was treated the same. Eg: if instead of TCP, it is T/TCP (which avoids the 3 way handshake, often) does the argument still hold? What would we do if SCTP or HIP was ever being used? This is all just too much to worry about - the unicast vs multicast is a simple distinction, leave it at that. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 13:21:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02709 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 13:21:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avh8i-0007yg-A9 for namedroppers-data@psg.com; Tue, 24 Feb 2004 18:18:40 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avh8h-0007yN-3T for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 18:18:39 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 832817; Tue, 24 Feb 2004 12:18:37 -0600 Message-ID: <403B957C.8000809@ehsco.com> Date: Tue, 24 Feb 2004 12:18:36 -0600 From: "Eric A. Hall" <ehall@ehsco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz <kre@munnari.OZ.AU> CC: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> <20558.1077643716@munnari.OZ.AU> In-Reply-To: <20558.1077643716@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 2/24/2004 11:28 AM, Robert Elz wrote: > is all just too much to worry about - the unicast vs multicast is a > simple distinction, leave it at that. Is such a distinction even necessary, really? Is the actual threat harmful enough to impose even this cost on the nodes? I mean, if we think the threat is so small that we don't feel compelled to make the TTL check mandatory, then why are we even worrying about it? All messages MUST have TTL=1 gets the same 99.9999% protection at less cost. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 13:41:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03378 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 13:41:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvhSG-000AJc-M4 for namedroppers-data@psg.com; Tue, 24 Feb 2004 18:38:52 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvhSF-000AJP-Qn for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 18:38:51 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 10:38:30 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Feb 2004 10:38:48 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 10:38:49 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 10:38:50 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Feb 2004 10:39:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 24 Feb 2004 10:38:29 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA07994F50@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal Thread-Index: AcP6/DYoWEMsDtIHQ2uto2/8YoqqdAACLKwA From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Robert Elz" <kre@munnari.OZ.AU>, "Burns, Mike" <Extern.Mike.Burns@gedas.com> Cc: "Stuart Cheshire" <cheshire@apple.com>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 24 Feb 2004 18:39:10.0596 (UTC) FILETIME=[7E204C40:01C3FB05] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > The TTL=3D1 argument provides nothing at all that helps avoid DoS > attacks - what the specification says should be done is irrelevant > to an attacker, if they want to bombard you, and they're 10 hops > away, they'll set the TTL to 11 (or more) regardless of what the > spec says it should be set to. The difference is with reflection attacks. A worm sends an LLMNR request to the local network, spoofing the source address of a target. With TTL=3D255, the response to the request can bomb any site on the = Internet; with TTL=3D1, the response will only travel one hop. -- Christian Huitema=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 13:52:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03595 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 13:52:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvhdN-000Bhi-Fk for namedroppers-data@psg.com; Tue, 24 Feb 2004 18:50:21 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvhdM-000BhK-HE for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 18:50:20 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3913014C58 for <namedroppers@ops.ietf.org>; Tue, 24 Feb 2004 18:50:20 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: Message from "Christian Huitema" <huitema@windows.microsoft.com> of "Tue, 24 Feb 2004 10:38:29 PST." <DAC3FCB50E31C54987CD10797DA511BA07994F50@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 24 Feb 2004 18:50:20 +0000 Message-Id: <20040224185020.3913014C58@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > The TTL=1 argument provides nothing at all that helps avoid DoS > > attacks - what the specification says should be done is irrelevant > > to an attacker, if they want to bombard you, and they're 10 hops > > away, they'll set the TTL to 11 (or more) regardless of what the > > spec says it should be set to. > > The difference is with reflection attacks. A worm sends an LLMNR request > to the local network, spoofing the source address of a target. With > TTL=255, the response to the request can bomb any site on the Internet; > with TTL=1, the response will only travel one hop. once again we see that there are cogent arguments to be made for both ttl settings, but that consensus proves elusive. we can flipflop on this for many years to come, or we can find a compromise (which means "a solution which displeases everyone equally".) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 14:01:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04062 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 14:01:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avhll-000Com-WE for namedroppers-data@psg.com; Tue, 24 Feb 2004 18:59:01 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avhll-000CoP-5q for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 18:59:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 03B2314BBE for <namedroppers@ops.ietf.org>; Tue, 24 Feb 2004 18:59:01 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: today in dnssec, 10 years ago X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 24 Feb 2004 18:59:01 +0000 Message-Id: <20040224185901.03B2314BBE@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk on february 23 1994, the dns protocol community had completed about six months of private discussion and four months of public discussion, and donald eastlake (then at digital equipment corp., r.i.p.) forwarded his first draft of what he thought represented the best ideas put forward up to that point. > To: dns-security@tis.com > Cc: dee@lkg.dec.com > Subject: dns security drafts > Date: Wed, 23 Feb 94 13:54:00 -0500 > From: "Donald E. Eastlake 3rd (Beast)" <dee@skidrow.lkg.dec.com> > X-Mts: smtp > > Well, it took longer to get out than I thought and it could use work > but here it is. I'm also submitting it to internet-drafts. > > Donald > > --------------------------------------------------------------------------- > Donald E. Eastlake, III DTN: 226-6577(w) dee@lkg.dec.com > 550 King St, LKG2-1/BB3 1-508-486-6577(w) dee@ranger.enet.dec.com > Littleton, MA 01460 USA 1-508-486-7417(fax) 1-508-287-4877(h) > > INTERNET-DRAFT DNS Protocol Security Extensions > 23 February 1994 > Expires 22 August 1994 > > > > Domain Name System Protocol Security Extensions > ------ ---- ------ -------- -------- ---------- > Donald E. Eastlake 3rd & Charles W. Kaufman > ... often on such anniversaries, glasses are filled with bubbly and raised, and words are spoken of the form "and here's to another wonderful ten years to come!" but maybe this time not so much so. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 15:31:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09594 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 15:31:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avj99-000KuE-TJ for namedroppers-data@psg.com; Tue, 24 Feb 2004 20:27:15 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avj96-000Ktn-Mu for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 20:27:12 +0000 Received: from [10.255.215.22] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id 8B56C1B3D4A; Tue, 24 Feb 2004 14:13:42 -0600 (CST) In-Reply-To: <20040224185020.3913014C58@sa.vix.com> References: <20040224185020.3913014C58@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <D3F2ECC4-6707-11D8-A76A-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 24 Feb 2004 15:27:12 -0500 To: Paul Vixie <paul@vix.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 24, 2004, at 1:50 PM, Paul Vixie wrote: >> The difference is with reflection attacks. A worm sends an LLMNR >> request >> to the local network, spoofing the source address of a target. With >> TTL=255, the response to the request can bomb any site on the >> Internet; >> with TTL=1, the response will only travel one hop. > > once again we see that there are cogent arguments to be made for both > ttl settings, but that consensus proves elusive. we can flipflop on > this for many years to come, or we can find a compromise (which means > "a solution which displeases everyone equally".) I beg to differ. This is not a cogent argument, because the bombing scenario can't happen unless all the routers on the internet are very carefully broken. Furthermore, it's an irrelevant argument, because we've (at least, some of us have) agreed that we don't need the TTL=255 check for multicast anyway, and it's sufficient to have it just for unicast. I think we're very close to a compromise here, if the authors are willing to consider the proposed changes. I don't understand why Christian brought up the bomb argument again, or what it has to do with the ongoing discussion. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 16:17:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11585 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 16:17:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvjtQ-0001ie-UM for namedroppers-data@psg.com; Tue, 24 Feb 2004 21:15:04 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvjtM-0001fh-Qw for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 21:15:01 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i1OLD8mP004001; Wed, 25 Feb 2004 04:13:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1OL7QQ29018; Wed, 25 Feb 2004 04:07:29 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: "Christian Huitema" <huitema@windows.microsoft.com> cc: "Burns, Mike" <Extern.Mike.Burns@gedas.com>, "Stuart Cheshire" <cheshire@apple.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA07994F50@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> References: <DAC3FCB50E31C54987CD10797DA511BA07994F50@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Feb 2004 04:07:26 +0700 Message-ID: <2914.1077656846@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 24 Feb 2004 10:38:29 -0800 From: "Christian Huitema" <huitema@windows.microsoft.com> Message-ID: <DAC3FCB50E31C54987CD10797DA511BA07994F50@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> | The difference is with reflection attacks. A worm sends an LLMNR request | to the local network, spoofing the source address of a target. With | TTL=255, the response to the request can bomb any site on the Internet; | with TTL=1, the response will only travel one hop. This works only if the request is one that many nodes on the local link will answer. If only one (or a small number) reply, then the bomb is just 2 or 3 packets, which isn't much to be concerned about. If there is some request that lots of nodes will answer, which would make that an affective attack, then really what ought to be done is to fix things so that there aren't lots of answers - that's useful just for local genuine queries, which don't want a hundred answers either. Even with TTL=1, if there was an avenue for attack here, it would be a good way to neutralise a system on a link - just get everyone else on the link to bomb it. That we don't want - so preventing the mass replies is the better solution. kre ps: Ted, Christian's scenario here involves unicast replies aimed at a victim, this one isn't multicast. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 16:37:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12590 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 16:37:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvkCg-0003tq-1I for namedroppers-data@psg.com; Tue, 24 Feb 2004 21:34:58 +0000 Received: from [213.243.180.204] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvkCe-0003te-5u for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 21:34:56 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id i1OLZcbG008610; Tue, 24 Feb 2004 23:35:39 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id i1OLZXYv008609; Tue, 24 Feb 2004 23:35:33 +0200 Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal From: Mika Liljeberg <mika.liljeberg@welho.com> To: Ted Lemon <mellon@nominum.com> Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <D3F2ECC4-6707-11D8-A76A-000A95D9C74C@nominum.com> References: <20040224185020.3913014C58@sa.vix.com> <D3F2ECC4-6707-11D8-A76A-000A95D9C74C@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1077658533.891.22.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 24 Feb 2004 23:35:33 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2004-02-24 at 22:27, Ted Lemon wrote: > I beg to differ. This is not a cogent argument, because the bombing > scenario can't happen unless all the routers on the internet are very > carefully broken. Furthermore, it's an irrelevant argument, because > we've (at least, some of us have) agreed that we don't need the TTL=255 > check for multicast anyway, and it's sufficient to have it just for > unicast. Reflection attack is a possibility if the attacker sends a spoofed query to a multicast group of higher than link-local scope or to a broadcast address. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 18:27:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16895 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 18:27:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avluq-000F1f-V1 for namedroppers-data@psg.com; Tue, 24 Feb 2004 23:24:40 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avluq-000F1S-2U for namedroppers@ops.ietf.org; Tue, 24 Feb 2004 23:24:40 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 24 Feb 2004 15:24:39 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Feb 2004 15:24:34 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Feb 2004 15:24:39 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Feb 2004 15:24:37 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 24 Feb 2004 15:24:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 24 Feb 2004 15:24:16 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA07A0166B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal Thread-Index: AcP7H4fm0A1IJhlZQs2SBe+NTi9FjQADaz7Q From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Mika Liljeberg" <mika.liljeberg@welho.com>, "Ted Lemon" <mellon@nominum.com> Cc: "Paul Vixie" <paul@vix.com>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 24 Feb 2004 23:24:38.0278 (UTC) FILETIME=[5F052A60:01C3FB2D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > I beg to differ. This is not a cogent argument, because the bombing > > scenario can't happen unless all the routers on the internet are very > > carefully broken. Furthermore, it's an irrelevant argument, because > > we've (at least, some of us have) agreed that we don't need the TTL=3D255 > > check for multicast anyway, and it's sufficient to have it just for > > unicast. >=20 > Reflection attack is a possibility if the attacker sends a spoofed query > to a multicast group of higher than link-local scope or to a broadcast > address. Think of the ICMP "smurf" attack, only use LLMNR instead of ping. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 19:11:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18246 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 19:11:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvmcD-000KJT-Ly for namedroppers-data@psg.com; Wed, 25 Feb 2004 00:09:29 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvmcC-000KJC-OA for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 00:09:28 +0000 Received: from [10.255.204.233] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id 656F11B3EFA; Tue, 24 Feb 2004 17:55:57 -0600 (CST) In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA07A0166B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> References: <DAC3FCB50E31C54987CD10797DA511BA07A0166B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <E24647F6-6726-11D8-9AFF-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> From: Ted Lemon <Ted.Lemon@nominum.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 24 Feb 2004 19:09:31 -0500 To: "Christian Huitema" <huitema@windows.microsoft.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 24, 2004, at 6:24 PM, Christian Huitema wrote: > Think of the ICMP "smurf" attack, only use LLMNR instead of ping. Right, which argues for making sure that the recipient of an LLMNR packet that originated off-link never replies to it. Of course, you can argue that the right fix is to make sure that the packet sent by the recipient never makes it off the link (this is the require TTL==1 fix), but what if the attack is on a node that's *on* the link? In either scenario, brokenness is bad; it's just differently bad. The bottom line is that we have to trust that *somebody* is going to get their implementation right. You can get a smurf attack with either kind of bad implementation. So I think that arguing about smurf attacks and how they might happen, while important, is not relevant to the question of whether to use TTL=1 or TTL=255. Just as a reminder here, the smurf attack uses nodes that are compliant with the relevant ICMP and IP RFCs. Here, in order for the attack to work, nodes have to fail to comply with the RFC (assuming we ever get an RFC out of this process!). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Feb 24 22:18:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24002 for <dnsext-archive@lists.ietf.org>; Tue, 24 Feb 2004 22:18:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvpVb-000Ffp-EF for namedroppers-data@psg.com; Wed, 25 Feb 2004 03:14:51 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvpVa-000FfS-2J for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 03:14:50 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i1P3Eh0d006405; Tue, 24 Feb 2004 22:14:43 -0500 To: Ted Lemon <Ted.Lemon@nominum.com> Cc: "Christian Huitema" <huitema@windows.microsoft.com>, namedroppers <namedroppers@ops.ietf.org> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <DAC3FCB50E31C54987CD10797DA511BA07A0166B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <E24647F6-6726-11D8-9AFF-000A95D9C74C@nominum.com> From: Derek Atkins <derek@ihtfp.com> Date: Tue, 24 Feb 2004 22:14:43 -0500 In-Reply-To: <E24647F6-6726-11D8-9AFF-000A95D9C74C@nominum.com> (Ted Lemon's message of "Tue, 24 Feb 2004 19:09:31 -0500") Message-ID: <sjmptc326l8.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It sounds like you want two things here, but it also sounds like all of them need to happen in the responder. The attacker could theoretically send packets of any type, with any TTL. So you can't trust anything you receive from the network. To this affect, I think: 1) We want the responder to try to determine that a request came from the local network. The best way to do this is for the responder to check that TTL=255 to make sure. If a TTL is less than 255 then it originiated off-net and can be dropped. 2) We want the responder to make sure response packets don't go off-net. In other words, we want the responder to respond with TTL=1, to make sure it can't smurf. So, to this affect: a) an LLMNR requestor should send requests with TTL=255 b) an LLMNR responder should verify requests have TTL=255 -- if it is not 255 then it should drop the packet. c) an LLMNR responder should respond with TTL=1 d) I dont' think an LLMNR requestor needs to check the response TTL. The only issue this doesn't directly solve is a requester being spoofed by an off-net attacker, but said attacker would need to guess the transaction id of the request in order to send a valid response, which is just as likely in LLMNR as it is in standard DNS, so it can probably be ignored. So, other than this issue, does this solve the issue? -derek Ted Lemon <Ted.Lemon@nominum.com> writes: > On Feb 24, 2004, at 6:24 PM, Christian Huitema wrote: >> Think of the ICMP "smurf" attack, only use LLMNR instead of ping. > > Right, which argues for making sure that the recipient of an LLMNR > packet that originated off-link never replies to it. Of course, you > can argue that the right fix is to make sure that the packet sent by > the recipient never makes it off the link (this is the require TTL==1 > fix), but what if the attack is on a node that's *on* the link? In > either scenario, brokenness is bad; it's just differently bad. > > The bottom line is that we have to trust that *somebody* is going to > get their implementation right. You can get a smurf attack with > either kind of bad implementation. So I think that arguing about > smurf attacks and how they might happen, while important, is not > relevant to the question of whether to use TTL=1 or TTL=255. > > Just as a reminder here, the smurf attack uses nodes that are > compliant with the relevant ICMP and IP RFCs. Here, in order for the > attack to work, nodes have to fail to comply with the RFC (assuming we > ever get an RFC out of this process!). > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 25 00:40:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28544 for <dnsext-archive@lists.ietf.org>; Wed, 25 Feb 2004 00:40:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvrjE-0003V4-V0 for namedroppers-data@psg.com; Wed, 25 Feb 2004 05:37:04 +0000 Received: from [213.243.180.204] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvrjD-0003Ur-NH for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 05:37:03 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id i1P5c2bG009855; Wed, 25 Feb 2004 07:38:03 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id i1P5c14g009854; Wed, 25 Feb 2004 07:38:01 +0200 Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal From: Mika Liljeberg <mika.liljeberg@welho.com> To: Ted Lemon <Ted.Lemon@nominum.com> Cc: Christian Huitema <huitema@windows.microsoft.com>, namedroppers <namedroppers@ops.ietf.org> In-Reply-To: <E24647F6-6726-11D8-9AFF-000A95D9C74C@nominum.com> References: <DAC3FCB50E31C54987CD10797DA511BA07A0166B@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <E24647F6-6726-11D8-9AFF-000A95D9C74C@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1077687481.891.33.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 25 Feb 2004 07:38:01 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2004-02-25 at 02:09, Ted Lemon wrote: > On Feb 24, 2004, at 6:24 PM, Christian Huitema wrote: > > Think of the ICMP "smurf" attack, only use LLMNR instead of ping. > > Right, which argues for making sure that the recipient of an LLMNR > packet that originated off-link never replies to it. That would be ok but there's a practical problem. Many incarnations of the socket API do not allow for checking the destination address of an incoming packet, and you can't bind a socket to a multicast address. OTOH, setting the TTL is simple and works on most systems. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 25 03:39:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03447 for <dnsext-archive@lists.ietf.org>; Wed, 25 Feb 2004 03:39:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvuWL-000Mw4-2M for namedroppers-data@psg.com; Wed, 25 Feb 2004 08:35:57 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvuWJ-000MvZ-8t for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 08:35:55 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i1P8ZnHP009536; Wed, 25 Feb 2004 08:35:53 GMT To: Paul Vixie <paul@vix.com> cc: namedroppers@ops.ietf.org Subject: Re: today in dnssec, 10 years ago In-Reply-To: Message from Paul Vixie <paul@vix.com> of "Tue, 24 Feb 2004 18:59:01 GMT." <20040224185901.03B2314BBE@sa.vix.com> Date: Wed, 25 Feb 2004 08:35:48 +0000 Message-ID: <9535.1077698148@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Paul" == Paul Vixie <paul@vix.com> writes: Paul> often on such anniversaries, glasses are filled with bubbly Paul> and raised, and words are spoken of the form "and here's to Paul> another wonderful ten years to come!" but maybe this time Paul> not so much so. Indeed. Sigh. In the 60s, NASA put men on the moon in under a decade and that was a far harder engineering challenge than DNSSEC. Now this isn't a fair comparison. Even so it shows what deliverables can be achieved in a decade. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 25 07:21:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12852 for <dnsext-archive@lists.ietf.org>; Wed, 25 Feb 2004 07:21:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvxyT-000Hrl-Ll for namedroppers-data@psg.com; Wed, 25 Feb 2004 12:17:13 +0000 Received: from [196.4.160.243] (helo=fedex.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvxyR-000HrQ-LA for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 12:17:11 +0000 Received: from hypatia.dns.net (c19-rba-33.dial-up.net [196.39.10.161]) by fedex.is.co.za (Postfix) with ESMTP id E3957BF8AD; Wed, 25 Feb 2004 14:16:49 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i1PBg0S03343; Wed, 25 Feb 2004 13:42:00 +0200 Date: Wed, 25 Feb 2004 13:42:00 +0200 From: Andras Salamon <andras@dns.net> To: namedroppers@ops.ietf.org Cc: Stuart Cheshire <cheshire@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Message-ID: <20040225114200.GA2408@dns.net> References: <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> <20558.1077643716@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20558.1077643716@munnari.OZ.AU> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Feb 25, 2004 at 12:28:36AM +0700, Robert Elz wrote: > Using TTL of 1 (for multicast packets) is to avoid the legitimate traffic, > packets that are supposed to be there, from possibly escaping and > being sent further than they should (a quite remote possibility, but > one which would be bad if it happened). There is nothing inherently special about LLMNR as a multicast protocol, so if we are going to worry about LLMNR we also have to worry about each multicast protocol. Using this argument, _any_ multicast protocol will have to worry about the TTL to ensure multicast packets do not propagate further than "expected". This level of layer interdependency is clearly not appropriate, and I don't think this working group can mandate changes to every multicast protocol, past, present or future. The real issue here is that LLMNR is meant to have local scope, and we are trying to implement a "local scope" constraint using a TTL hack. As Masataka Ohta and others have pointed out, on a network that is connected to another potentially hostile network (ie. the Internet), TTLs can be made to take on any values that suit a remote attacker, and therefore cannot reliably be linked with the packet being local. The TTL hack simply doesn't work to 100% guarantee "local scope", no matter how much we try to make it so. It usually works fine, but not in the presence of hostile intent. Personally, I don't see a way to 100% reliably implement a "local scope" constraint in a higher layer protocol, without mucking around in the lower layer protocols. I think we need to pick an approach, document the failure scenarios, possibly make some recommendations for filtering packets at border routers, and move on. Summarising the previous discussion: First consider the case of hostile intent. If all routers are configured to drop LLMNR packets, then the protocol is only vulnerable to local injection by an attacker, and the TTL value is then irrelevant. However, if routers are not configured to drop LLMNR packets, then the TTL=255 case is more robust since it only fails in the case of local injection (in other cases the local server will not respond to the bogus request). In the TTL=1 case a hostile remote attacker could still elicit a response by the local server, by just setting the TTL to successive values of 1, 2, ..., n, where n is the diameter of the Internet (currently around 35-40). Now consider the case of non-hostile packets slipping out by mistake, due to broken routers mishandling the multicast address. If all routers are configured to block LLMNR packets, then the TTL value used is again irrelevant. If routers do not block LLMNR packets, then the TTL=1 case is more robust. Personally, I would rather see resistance to remote attack inherent in the protocol, than trying to ensure broken routers do not cause havoc. If we want to protect against routers incorrectly treating local multicast addresses then we may as well start campaigning for every multicast protocol to include TTL "protection" against such a "threat". Why single out LLMNR? There is already operational experience with the TTL=255 approach, and it reduces the security threat to the case where an attacker can actually inject packets onto the local network. We should just adopt this approach and move on. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 25 14:30:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07053 for <dnsext-archive@lists.ietf.org>; Wed, 25 Feb 2004 14:30:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aw4fS-000KMV-FN for namedroppers-data@psg.com; Wed, 25 Feb 2004 19:26:02 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw4fP-000KLy-6j for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 19:25:59 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1PJb1127726 for <namedroppers@ops.ietf.org>; Wed, 25 Feb 2004 11:37:01 -0800 Date: Wed, 25 Feb 2004 11:37:00 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: namedroppers@ops.ietf.org Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Message-ID: <Pine.LNX.4.56.0402251135201.26975@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz noted: "While Bernard is right, that for TCP, a TTL of 1 would also work, I don't think I really want that level of detail being checked, and would prefer if simply all unicast was treated the same." I'd argue that the distinction to make is between queries and responses, not between unicast and multicast. I believe that queries of any type need to have TTL=1 (no check implied); for responses, TTL=255 can be considered, along with an (optional) check. TTL=1 on queries is really about scaling and "fast fail", not security. Since LLMNR can be used to resolve *any* name where the DNS server does not respond or responds with RCODE=0 and no RRs or RCODE=3, it was important to scaling to ensure that LLMNR queries do not escape the local link. Otherwise, LLMNR could add signficantly to DNS traffic on bottleneck links. The primary use of unicast requests is for resolution of PTR RRs. For these queries we already know the IP address. Setting TTL=1 ensures not only that these queries don't escape the local link but also that queries for off-link addresses will fail more quickly than setting TTL=255 and then waiting for a response from anywhere on the Internet. In practice, PTR RR queries will comprise a signficant fraction of all LLMNR queries, so containing these queries and "fast fail" is important. This is distinct from what TTL is used in the response or whether the sender checks TTL on the response. For a TCP query, TTL=1 is set by the sender on the SYN. The three way handshake takes care of the rest, regardless of what TTL the receiver sets on his response. This works on SCTP as well. Christian Huitema noted: "Think of the ICMP "smurf" attack, only use LLMNR instead of ping." LLMNR does not support wildcard queries, so that I don't believe that this attack is possible against a properly functioning implementation. A host should only respond to queries for names for which it is authoritative. In the case of a cluster, you might have quite a few hosts responding to a query for the same name, but otherwise an LLMNR query will receive 0-1 responses. However, if DNS DISCOVER opcode were to be implemented on top of LLMNR such an attack would become possible, since that draft supports wildcard queries. So setting TTL=255 on a unicast UDP response and then checking has implications for the security of DNS DISCOVER opcode. Ted Lemon noted: "I think we're very close to a compromise here, if the authors are willing to consider the proposed changes." If you want to propose a change for this or any other purpose, please submit an issue in the format described here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html However, before doing that it might be helpful to be clear what the change is trying to accomplish. If the goal is to fix an issue with the LLMNR protocol, that's one thing; if the goal is to converge with Rendezvous, that is a much larger task that cannot be accomplished by a single change, particularly since it isn't even clear that the "compromise" being discussed meets Apple's requirements. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Feb 25 16:15:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15010 for <dnsext-archive@lists.ietf.org>; Wed, 25 Feb 2004 16:15:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aw6Jk-000BLP-B0 for namedroppers-data@psg.com; Wed, 25 Feb 2004 21:11:44 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw6Jh-000BL2-GW for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 21:11:41 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2004 13:22:02 +0000 Received: from jschnizl-w2k.cisco.com (dhcp-171-71-119-186.cisco.com [171.71.119.186]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i1PLBauB020020; Wed, 25 Feb 2004 13:11:39 -0800 (PST) Message-Id: <4.3.2.7.2.20040225160744.0216c7d0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Feb 2004 16:11:29 -0500 To: Andras Salamon <andras@dns.net> From: John Schnizlein <jschnizl@cisco.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Cc: namedroppers@ops.ietf.org In-Reply-To: <20040225114200.GA2408@dns.net> References: <20558.1077643716@munnari.OZ.AU> <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> <20558.1077643716@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 06:42 AM 2/25/2004, Andras Salamon wrote: >... > >Now consider the case of non-hostile packets slipping out by mistake, >due to broken routers mishandling the multicast address. If all routers >are configured to block LLMNR packets, then the TTL value used is again >irrelevant. If routers do not block LLMNR packets, then the TTL=1 case >is more robust. This is an important point that sometimes gets lost in the deeper analysis. There are very many installed routers that know nothing about LLMNR, or link-local IPv4 addresses for that matter. While these routers can be assumed to decrement TTL and drop to prevent looping traffic, it is not reasonable to demand that the introduction of new protocol features on hosts cause all the installed routers to be re-configured. John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 02:09:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20584 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 02:09:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwFXP-000FsE-6b for namedroppers-data@psg.com; Thu, 26 Feb 2004 07:02:27 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwFXJ-000Frm-QH for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 07:02:22 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i1Q71f212146; Thu, 26 Feb 2004 14:01:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i1PFMPp17328; Wed, 25 Feb 2004 22:22:25 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Andras Salamon <andras@dns.net> cc: namedroppers@ops.ietf.org, Stuart Cheshire <cheshire@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <20040225114200.GA2408@dns.net> References: <20040225114200.GA2408@dns.net> <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> <20558.1077643716@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Feb 2004 22:22:25 +0700 Message-ID: <14690.1077722545@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 25 Feb 2004 13:42:00 +0200 From: Andras Salamon <andras@dns.net> Message-ID: <20040225114200.GA2408@dns.net> | There is nothing inherently special about LLMNR as a multicast protocol, No, there isn't. They're all different, and each has to make sure it has the proper mechanisms to sale properly. | so if we are going to worry about LLMNR we also have to worry about each | multicast protocol. That doesn't follow at all - each multicast protocol has to worry about itself. Including LLMR. | Using this argument, _any_ multicast protocol will | have to worry about the TTL to ensure multicast packets do not propagate | further than "expected". No, each multicast protocol has to make sure that it's properties allow it to be rationally deployed on the internet. How they do that is up to each protocol to determine. | As Masataka Ohta and others have pointed out, on a network that is | connected to another potentially hostile network (ie. the Internet), | TTLs can be made to take on any values that suit a remote attacker, We cannot depend upon any unverifiable TTL setting for security purposed (using the TTL for any kind of security is very weak), but we can specify what conforming applications should set it to. When we're concerned about scaling, rather than security, we can assume that the vast majority of the nodes that matter are obeying the specification, we don't need to imagine a million compromised nodes all trying to defeat us. | and therefore cannot reliably be linked with the packet being local. The 225 case can, as if the packet has been through a router, the TTL won't be 255 any longer, regardless of what the sender set it to. | The TTL hack simply doesn't work to 100% guarantee "local scope", no | matter how much we try to make it so. It usually works fine, but not | in the presence of hostile intent. This depends upon what we're trying to achieve. The intent of the TTL=1 isn't to prevent anyone else from doing something to us, it is to prevent our own packets from doing harm to others - and there we can rely upon the TTL being set correctly, as we're doing it ourselves. | Personally, I don't see a way to 100% reliably implement a "local scope" | constraint in a higher layer protocol, without mucking around in the | lower layer protocols. Of course, the scope needs to actually be implemented at the network layer, which is why it is done using network addresses, or the TTL, both of which are network layer concepts. | Summarising the previous discussion: You're only considering the security implications, which are important, but which are only a part of what needs to be considered. That seems to be a lot of the problem we have here - most participants are looking at just one issue, and seeing how they can handle that one, and ignoring everything else. | First consider the case of hostile intent. If all routers are configured | to drop LLMNR packets, That's never going to happen in general. Multicast packets perhaps, but not unicast. They're just random UDP (or perhaps TCP) packets. | In the TTL=1 case a hostile remote attacker could still elicit a response | by the local server, by just setting the TTL to successive values of 1, 2, | ..., n, where n is the diameter of the Internet (currently around 35-40). Yes, absolutely, though there's no need to do that expanding search, as no-one is going to check that the arriving TTL is 1, that's an utter waste of time - so simply sending a packet with a "bit enough" TTL would do. However, all this happens is cause the server to send a response, if all the TTLs were 1, then the response wouldn't get very far, would it? | Personally, I would rather see resistance to remote attack inherent in | the protocol, Which particular remote attack? The one you're concerned about isn't the same one Stuart is concerned with (he's concerned with bogus replies being injected - ie: one assumes (infers) that a query is being sent, and generates a reply to the assumed query). And you also need to look and see what the overall damage might be, and what other ways there are to mount a similar attach (no point doing anything to prevent an attack that it is trivial to succeed at using a different mechanism). | There is already operational experience with the TTL=255 approach, | and it reduces the security threat to the case where an attacker can | actually inject packets onto the local network. Actually, no, it doesn't - if the attacker can inject packets into the local net, then TTL=1 is better, as there at least replies (and queries) go nowhere. TTL=255 provides some protection from attackers who cannot inject packets into the local net, but who are able to determine enough about local activities to know when and how to generate a plausible fake reply. This is actually a very hard thing to do (knowing when a query might be made isn't too hard in some cases - the attacker can cause that, knowing enough about the query (its source port, ID, ...) to generate a reply that will be accepted, without being able to observe the query isn't nearly so easy. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 03:52:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28485 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 03:52:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwH9W-0001cp-Af for namedroppers-data@psg.com; Thu, 26 Feb 2004 08:45:54 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwH9V-0001cR-3A for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 08:45:53 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1Q8ukx11322; Thu, 26 Feb 2004 00:56:46 -0800 Date: Thu, 26 Feb 2004 00:56:46 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Robert Elz <kre@munnari.OZ.AU> cc: huitema@microsoft.com, Ted.Lemon@nominum.com, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <18511.1077781197@munnari.OZ.AU> Message-ID: <Pine.LNX.4.56.0402260033240.9880@internaut.com> References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Scaling yes, "fast fail" no - the TTL cannot cause anything to happen > faster than it otherwise would (well, the packet may get discarded in > the net quicker, but as you can't rely upon getting an ICMP back, this > is essentially invisible). You can't rely on getting an ICMP back, but if one is received then it can be treated as though a response was received with RCODE=0 and an empty answer section, assuming that the ICMP error payload can be verified. This is described in Section 2.4. > > | Setting TTL=1 ensures not only that these queries don't escape the local > | link > > Yes (though personally in this case I'm not sure that matters, in general > I think the in-addr.arpa (and in6.arpa) trees are a mistake, and if we want > to know someone's name, we should just ask them - wherever they are). The concern was that the volume of these queries could be substantial. Today's hosts do send PTR queries, and frequently (up to 30% of the time) do not receive an answer to them. Setting TTL=255 on unicast queries will cause bandwidth to be consumed on other links, which is hard to justify for a link-local protocol. > I certainly agree that TTL checking for security purposes (in the > "did this packet originate on the local link", for as much security > as that affords, which isn't much) is useful only when receiving > responses. Exactly. That's why this discussion should really be about responses, not queries. If there is to be a "compromise" I believe that it should be to set TTL=255 on responses and (optionally) check on the sender, while *always* setting TTL=1 on queries. > | However, if DNS DISCOVER opcode were to be implemented on top of LLMNR > > The DISCOVER opcode shouldn't be implemented anywhere - but again, that's > another discussion. If that's the WG consensus, then I believe that we can dismiss the DoS arguments against setting TTL=255 on Responses, since this really can't be used to do much harm with a conformant LLMNR implementation. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 09:48:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16239 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 09:48:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwMit-000FIF-Cm for namedroppers-data@psg.com; Thu, 26 Feb 2004 14:42:47 +0000 Received: from [196.4.160.243] (helo=fedex.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwMir-000FHb-Mv for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 14:42:46 +0000 Received: from hypatia.dns.net (c11-rba-104.dial-up.net [196.39.0.104]) by fedex.is.co.za (Postfix) with ESMTP id 6BEC6C028B; Thu, 26 Feb 2004 16:42:11 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i1QEgHR07178; Thu, 26 Feb 2004 16:42:17 +0200 Date: Thu, 26 Feb 2004 16:42:16 +0200 From: Andras Salamon <andras@dns.net> To: Bernard Aboba <aboba@internaut.com> Cc: huitema@microsoft.com, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Message-ID: <20040226144216.GA7166@dns.net> References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> <Pine.LNX.4.56.0402260033240.9880@internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <Pine.LNX.4.56.0402260033240.9880@internaut.com> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote: > If there is to be a "compromise" I believe that it should be > to set TTL=255 on responses and (optionally) check on the sender, while > *always* setting TTL=1 on queries. Sounds reasonable to me. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 12:58:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29592 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 12:58:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwPiD-000BTd-QF for namedroppers-data@psg.com; Thu, 26 Feb 2004 17:54:17 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwPiA-000BSk-Sp for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 17:54:14 +0000 Received: from [10.255.205.89] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id CDB671B2117; Thu, 26 Feb 2004 11:51:49 -0600 (CST) In-Reply-To: <Pine.LNX.4.56.0402260033240.9880@internaut.com> References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> <Pine.LNX.4.56.0402260033240.9880@internaut.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <CC32B900-6884-11D8-ACFB-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: Robert Elz <kre@munnari.OZ.AU>, huitema@microsoft.com, namedroppers@ops.ietf.org From: Ted Lemon <Ted.Lemon@nominum.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 26 Feb 2004 12:54:17 -0500 To: Bernard Aboba <aboba@internaut.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Feb 26, 2004, at 3:56 AM, Bernard Aboba wrote: > The concern was that the volume of these queries could be substantial. > Today's hosts do send PTR queries, and frequently (up to 30% of the > time) > do not receive an answer to them. Setting TTL=255 on unicast queries > will > cause bandwidth to be consumed on other links, which is hard to justify > for a link-local protocol. Can you explain how this is going to happen, in the case of a unicast? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 14:47:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05051 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 14:47:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwRMZ-000Mxs-DB for namedroppers-data@psg.com; Thu, 26 Feb 2004 19:40:03 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwRMI-000Mvy-CS for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 19:39:46 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1QJcpLN021112 for <namedroppers@ops.ietf.org>; Thu, 26 Feb 2004 14:38:51 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i1QJcoL4021102 for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 14:38:50 -0500 (EST) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw8Y4-0005VT-RY for namedroppers@ops.ietf.org; Wed, 25 Feb 2004 23:34:40 +0000 Received: from [10.255.204.225] (m6a8d36d0.tmodns.net [208.54.141.106]) by toccata.fugue.com (Postfix) with ESMTP id 6CCF61B26EC; Wed, 25 Feb 2004 17:32:20 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040225160744.0216c7d0@wells.cisco.com> References: <20558.1077643716@munnari.OZ.AU> <175A93E62F431C4CBB3798EF8320D6B80895628A@usvwoaahn03.abh.vw.com> <20558.1077643716@munnari.OZ.AU> <4.3.2.7.2.20040225160744.0216c7d0@wells.cisco.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <305A1A99-67EB-11D8-B23B-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Wed, 25 Feb 2004 18:34:43 -0500 To: John Schnizlein <jschnizl@cisco.com> X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Feb 25, 2004, at 4:11 PM, John Schnizlein wrote: > There are very many installed routers that know nothing about LLMNR, or > link-local IPv4 addresses for that matter. While these routers can be > assumed to decrement TTL and drop to prevent looping traffic, it is not > reasonable to demand that the introduction of new protocol features on > hosts cause all the installed routers to be re-configured. AFAIK the whole reason for this discussion is that we are trying to come up with a protocol that will work and not create packet storms in the absence of any modified routers. :') -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 14:51:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05312 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 14:51:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwRUo-000O7G-UH for namedroppers-data@psg.com; Thu, 26 Feb 2004 19:48:34 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwRUd-000O6J-5C for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 19:48:23 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i1QJxEw19571; Thu, 26 Feb 2004 11:59:14 -0800 Date: Thu, 26 Feb 2004 11:59:13 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: Ted Lemon <Ted.Lemon@nominum.com> cc: Robert Elz <kre@munnari.OZ.AU>, huitema@microsoft.com, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: <CC32B900-6884-11D8-ACFB-000A95D9C74C@nominum.com> Message-ID: <Pine.LNX.4.56.0402261157260.19445@internaut.com> References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> <Pine.LNX.4.56.0402260033240.9880@internaut.com> <CC32B900-6884-11D8-ACFB-000A95D9C74C@nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> cause bandwidth to be consumed on other links, which is hard to justify >> for a link-local protocol. > > Can you explain how this is going to happen, in the case of a unicast? In normal operation, hosts send DNS PTR RR queries, and can either receive no response, or can receive a response with RCODE=3 (NXDOMAIN). Studies show that this can occur with as much as 30% of all PTR RR queries, since very often administrators neglect to configure these RRs. In these circumstances, (see Section 2) an LLMNR PTR RR query will be sent via unicast, as described in Section 2.4. Since the destination might not be resident on the local link, if the query has TTL=255, then it could be sent to any destination on the Internet and will traverse links other than the local one to reach that destination. By setting TTL=1 on unicast queries, this problem is avoided. If there is a default route, the gateway will typically send an ICMP "Time Exceeded" message if the destination is non-local. If the host is attached to an adhoc network, then it will ARP for the destination, and if there is no response, an error will be returned. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 17:05:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12031 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 17:05:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwTYO-000C6R-IX for namedroppers-data@psg.com; Thu, 26 Feb 2004 22:00:24 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwTY1-000C1Z-GB for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 22:00:01 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 14:00:02 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Feb 2004 14:00:01 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Feb 2004 14:00:58 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Feb 2004 14:00:00 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 26 Feb 2004 14:00:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 26 Feb 2004 13:59:38 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA07ACEA9E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal Thread-Index: AcP8dufKdWJLbpq7RNOQ82EjeKAYYQAPIawA From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Andras Salamon" <andras@dns.net>, "Bernard Aboba" <aboba@internaut.com> Cc: <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 26 Feb 2004 22:00:00.0575 (UTC) FILETIME=[E14CACF0:01C3FCB3] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote: > > If there is to be a "compromise" I believe that it should be > > to set TTL=3D255 on responses and (optionally) check on the sender, while > > *always* setting TTL=3D1 on queries. >=20 > Sounds reasonable to me. I would qualify that by setting the TTL=3D255 only when the response is sent to a link local address, either IPv6 link local or IPv4 169.254/16. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Feb 26 18:08:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15699 for <dnsext-archive@lists.ietf.org>; Thu, 26 Feb 2004 18:08:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwUWy-000IM2-7k for namedroppers-data@psg.com; Thu, 26 Feb 2004 23:03:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AwUWu-000IKj-Qh for namedroppers@ops.ietf.org; Thu, 26 Feb 2004 23:02:57 +0000 Received: (qmail 19540 invoked from network); 26 Feb 2004 23:00:56 -0000 Received: from h219-110-034-038.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.34.38) by necom830.hpcl.titech.ac.jp with SMTP; 26 Feb 2004 23:00:56 -0000 Message-ID: <403E7B9B.1040707@necom830.hpcl.titech.ac.jp> Date: Fri, 27 Feb 2004 08:04:59 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Christian Huitema <huitema@windows.microsoft.com> CC: Andras Salamon <andras@dns.net>, Bernard Aboba <aboba@internaut.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <DAC3FCB50E31C54987CD10797DA511BA07ACEA9E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA07ACEA9E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian; >>>If there is to be a "compromise" I believe that it should be >>>to set TTL=255 on responses and (optionally) check on the sender, > > while > >>>*always* setting TTL=1 on queries. >> >>Sounds reasonable to me. > I would qualify that by setting the TTL=255 only when the response is > sent to a link local address, either IPv6 link local or IPv4 169.254/16. To stop packets flooding out, it should also be required that a site administrator is sure that all the local routers recognize link local addresses, which involves site dependent configuration. However, when all the local routers regognize link local addresses, there are no reason (even invalid reasons as there are no valid reasons from the beginning) to set TTL 255. With TTL of 1, the configuration becomes unnecessary. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Feb 28 13:07:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26046 for <dnsext-archive@lists.ietf.org>; Sat, 28 Feb 2004 13:07:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ax8lS-000DP9-QK for namedroppers-data@psg.com; Sat, 28 Feb 2004 18:00:38 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ax8lP-000DOs-S8 for namedroppers@ops.ietf.org; Sat, 28 Feb 2004 18:00:36 +0000 Received: from ENGILL.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i1SHxPLO048274 for <namedroppers@ops.ietf.org>; Sat, 28 Feb 2004 12:59:25 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040228124513.02f35bc8@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Sat, 28 Feb 2004 13:00:06 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Advancing RFC3597 Unknown Type support --> to Draft Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This RFC was published about 6 months ago so it is now a candidate to advance through he standards track. In order to do that we need evidence of implementation, interoperabilty test and report. This message is to address the first issue, and solicit feedback on the specification from an implementations. We also would like to solicit a volunteer to coordinate the second. Please send the implementation reports to namedroppers or the chairs by March 15'th. thanks Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>