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 <dnsext-archive@lists.ietf.org>; 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 <namedroppers@ops.ietf.org>; 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 <namedroppers@ops.ietf.org>; 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 <olaf@ripe.net>
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 <http://www.ietf.org/html.charters/dnsext-charter.html> 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
  <http://www.ietf.org/html.charters/dnsop-charter.html>. 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

  <NAME> ISSUE: <title>

  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">

<P ALIGN="CENTER"><!-- Please, follow the links:
http://www.hotmail.com
http://www.spamcop.net
mailto:abernardico@yahoo.com?subject=Remove
andrediniz@nonaarte.com.br
andredogon@simbolo.com.br
mailto:andredogon@simbolo.coml.sys.intranet?subject=Subscribir
braulinojr@bol.com.br
mailto:camera3@mail.telepac.pt?subject=IAgree
caparroz@wanadoo.es
mailto:carlospi@adinet.com.uy?subject=Adquirir
DADEAN1@aol.com
df01a8c0@xdata1.com.uy
mailto:efigge@arnet.com.ar?subject=Unsubscribe
elrey@123.com
emancipacordoba@hotmail.com
mailto:FabianF@exo.com.ar?subject=MyOpinion
fuckspam@attbi.com
gcv2000@adinet.com.uy
gindre@indecs.org.br
grupeiro@uol.com.br
gsya@arnet.com.ar
igge@arnet.com.ar
iica@reuna.cl
iranzo@fa.upc.es
itiro@openlink.c
itiro@openlink.com.br
jaabril@comcast.net
jaabril@mail.comcast.net
jbarloccod@medynet.com
jerez@adinet.com.uy
--><FONT FACE="Garamond">(xyf) </FONT><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:EnEspa&ntilde;ol">Lindenberg:EnEspa&ntilde;ol </A><FONT FACE="Garamond">- </FONT><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:InEnglish(LinkToFreeTranslator">English:LinkToFreeTranslator</A> 
<B><FONT FACE="Garamond" SIZE=4><P>S&eacute;rie Temas Patrulhados (3)</P>
</FONT><FONT FACE="Garamond" SIZE=5><P ALIGN="CENTER">Lindenberg e a "demoniza&ccedil;&atilde;o" da livre iniciativa</P>
</FONT><I><FONT FACE="Garamond" SIZE=4><P ALIGN="CENTER">"Muito embora capitalismo, globaliza&ccedil;&atilde;o, neoliberalismo, privatiza&ccedil;&otilde;es, propriedade privada etc. n&atilde;o se identifiquem necess&aacute;riamente, eles s&atilde;o vistos pelos herdeiros das id&eacute;ias marxistas como as quatro bestas do Apocalipse"</P>
</I><P>Vi&eacute;s </P>
</B><P>* Adolpho Lindenberg &eacute; autor do livro <B>"Os cat&oacute;licos e a economia de mercado"</B>, onde denuncia uma pol&iacute;tica com vi&eacute;s esquerdista que visa censurar, marginalizar ou encobrir com um manto de sil&ecirc;ncio, not&iacute;cias, opini&otilde;es e livros "politicamente incorretos", n&atilde;o afinados com as assim denominadas "causas sociais" inspiradas na teologia da liberta&ccedil;&atilde;o e nos F&oacute;rums Sociais: os meios de comunica&ccedil;&atilde;o, e a pr&oacute;pria sociedade brasileira, est&atilde;o sendo "patrulhados".</P>
<B><P>"As quatro bestas do Apocalipse"?</P>
</B><P>&#9;* Em artigo "Capitalismo, globaliza&ccedil;&atilde;o, neoliberalismo, privatiza&ccedil;&otilde;es", da S&eacute;rie Temas Patrulhados, Lindenberg constata que muito embora capitalismo, globaliza&ccedil;&atilde;o, neoliberalismo, privatiza&ccedil;&otilde;es, propriedade privada etc. n&atilde;o se identifiquem necess&aacute;riamente, t&ecirc;m, no entanto, um denominador comum: s&atilde;o vistos pelos progressistas e pelos herdeiros das id&eacute;ias marxistas como "as quatro bestas do Apocalipse". </P>
<P>Com efeito, essas pessoas, sem terem condi&ccedil;&otilde;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&iacute;ticas de austeridade, as multinacionais e as privatiza&ccedil;&otilde;es dos servi&ccedil;os p&uacute;blicos, como sendo as respons&aacute;veis pelo crescimento dos bols&otilde;es de mis&eacute;ria, estagna&ccedil;&atilde;o econ&ocirc;mica e concentra&ccedil;&atilde;o da renda.</P>
<B><P>Bom senso</P>
</B><P>&#9;* Em seu artigo "Capitalismo, globaliza&ccedil;&atilde;o, neoliberalismo, privatiza&ccedil;&otilde;es", Lindenberg usa o bom senso e uma linguagem acess&iacute;vel para recolocar as id&eacute;ias em sua justa ordem. Seguem alguns temas abordados no artigo, que o leitor receber&aacute; gratuitamente por e-mail, na &iacute;ntegra, simplesmente clicando em: </FONT><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:EsteArtigoGratuitamente(3) ">EsteArtigoGratuitamente(3)</A><FONT FACE="Garamond" SIZE=4> .</P>
<P>- Os ideais da livre empresa e da economia de mercado, e o direito de propriedade segundo os ensinamentos tradicionais da Igreja.</P>
<P>- A ordem socioecon&ocirc;mica crist&atilde; personalizada e org&acirc;nica, isto &eacute;, uma ordem na qual a preemin&ecirc;ncia deve ser dada &agrave;s fam&iacute;lias e &agrave;s sociedades intermedi&aacute;rias, e n&atilde;o ao Estado. </P>
<P>- As campanhas de descr&eacute;dito contra a propriedade privada.</P>
<P>- A verdade sobre o chamado "capitalismo selvagem".</P>
<P>&#9;. Em que consiste o capitalismo popular ou democr&aacute;tico.&#9;</P>
<P>&#9;. A viga mestre do progresso econ&ocirc;mico crist&atilde;o.</P>
<B><P>&#9;</B>. O contraste entre os padr&otilde;es de vida e de assist&ecirc;ncia social dos pa&iacute;ses livres, e dos pa&iacute;ses com economias estatizantes.</P>
<B><P>Links para receber e-Book e artigos gratuitos </P>
</B></FONT><P><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:e-BookGratuito">Lindenberg:e-BookGratuito</A><FONT FACE="Garamond" SIZE=4> (em formato Word, com 11 artigos de Lindenberg)</P>
</FONT><P><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:EsteArtigoCompletoGratuitamente(No.3) ">EsteArtigoCompletoGratuitamente(No.3)</A></P>
<P><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:LivroIntrodu&ccedil;&atilde;oGratuita">Lindenberg:LivroIntrodu&ccedil;&atilde;oGratuita</A><FONT FACE="Garamond" SIZE=4> (em formato Word, Introdu&ccedil;&atilde;o do livro "Os cat&oacute;licos e a economia de mercado")</P>
<B><P>Links de opini&atilde;o</P>
<P>&#9;</B>Gostariamos muito de receber seu seu voto eletr&ocirc;nico sobre a tem&aacute;tica abordada neste e-mail e, se poss&iacute;vel, incluindo sua valiosa opini&atilde;o:</P>
</FONT><P><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Concordo">Lindenberg:Concordo </A><FONT FACE="Garamond" SIZE=4>- </FONT><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Discrepo">Lindenberg:Discrepo </A><FONT FACE="Garamond" SIZE=4>- </FONT><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Opini&atilde;o/Sugest&atilde;o">Lindenberg:Opini&atilde;o/Sugest&atilde;o</A></P>
<P><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:GratuitamenteEsteArtigo(3">Lindenberg:GratuitamenteEsteArtigo(3)</A></P>
<B><FONT FACE="Garamond" SIZE=4><P>Link em espanhol</P>
</B></FONT><P><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:e-BookGratuito">Lindenberg:e-BookGratuitoEsp</A><FONT FACE="Garamond" SIZE=4> (em formato Word, com 11 artigos de Lindenberg, em Espanhol)</P>
<B><P>Outros links</P>
</B></FONT><P><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:DesejoAdquirirLivro">Lindenberg:DesejoAdquirirLivro</A><FONT FACE="Garamond" SIZE=4> (receber&aacute; instru&ccedil;&otilde;es sobre como poder adquirir o livro no Brasil e em Portugal)</P>
</FONT><P><A HREF="mailto:construnews@yahoo.com.br?subject=Lindenberg:Subscrever">Lindenberg:Subscrever</A><FONT FACE="Garamond" SIZE=4> (para receber, gratuitamente, os pr&oacute;ximos artigos)</P>
</FONT><P><A HREF="mailto:construnews@yahoo.com.br?subject=ConstruNews:Remover">ConstruNews:Remover</A><FONT FACE="Garamond" SIZE=4> (para ser retirado imediatamente de nosso Address Book).</P>
</FONT><B><FONT FACE="Garamond"><P ALIGN="CENTER">&nbsp;</P>
<P ALIGN="CENTER">A difus&atilde;o deste artigo, com a finalidade estritamente c&iacute;vica e cultural de promover um debate respeitoso de id&eacute;ias, &eacute; de exclusiva responsabilidade da ConstruNews.</P>
</B></FONT><FONT FACE="Garamond" SIZE=4><P>&nbsp;</P>
</FONT><P>&nbsp;</P></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">

<FONT SIZE=2><P ALIGN="CENTER">cod.: (ebz) <!-- Please, follow the links:
http://www.hotmail.com
http://www.spamcop.net
mailto:abernardico@yahoo.com?subject=Remove
andrediniz@nonaarte.com.br
andredogon@simbolo.com.br
mailto:andredogon@simbolo.coml.sys.intranet?subject=Subscribir
braulinojr@bol.com.br
mailto:camera3@mail.telepac.pt?subject=IAgree
caparroz@wanadoo.es
mailto:carlospi@adinet.com.uy?subject=Adquirir
DADEAN1@aol.com
df01a8c0@xdata1.com.uy
mailto:efigge@arnet.com.ar?subject=Unsubscribe
elrey@123.com
emancipacordoba@hotmail.com
mailto:FabianF@exo.com.ar?subject=MyOpinion
fuckspam@attbi.com
gcv2000@adinet.com.uy
gindre@indecs.org.br
grupeiro@uol.com.br
gsya@arnet.com.ar
igge@arnet.com.ar
iica@reuna.cl
iranzo@fa.upc.es
itiro@openlink.c
itiro@openlink.com.br
jaabril@comcast.net
jaabril@mail.comcast.net
jbarloccod@medynet.com
jerez@adinet.com.uy
--></FONT><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=EnEspa&ntilde;ol:TraductorGratuitoAutom&aacute;tico"><FONT SIZE=2>EnEspa&ntilde;ol:TraductorGratuitoAutom&aacute;tico</FONT></A><FONT SIZE=2> - </FONT><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=InEnglish:FreeAutomaticTranslator"><FONT SIZE=2>InEnglish:FreeAutomaticTranslator</FONT></A> 
<B><FONT SIZE=5><P>Mato Grosso do Sul: alertam sobre perigo de aftosa em fazendas invadidas por &iacute;ndios</P>
</B></FONT><I><P ALIGN="CENTER">Conselho Indigenista Mission&aacute;rio (Cimi), Funda&ccedil;&atilde;o Nacional do &Iacute;ndio (Funai) e ONGs s&atilde;o acusadas de "fabricar" conflitos entre &iacute;ndios e propriet&aacute;rios rurais, que j&aacute; causaram numerosas v&iacute;timas, como um dirigente pecuarista recentemente assassinado em Santa Catarina </P>
</I><P>CAMPO GRANDE, Fevr. 19, 2004 (AB) - "H&aacute; uma preocupa&ccedil;&atilde;o enorme com rela&ccedil;&atilde;o ao estado sanit&aacute;rio do rebanho bovino estimado em 9 mil cabe&ccedil;as, nas 14 fazendas invadidas por &iacute;ndios na regi&atilde;o de Japor&atilde;, perto da fronteira com o Paraguai". "Mato Grosso do Sul &eacute; livre de aftosa, mediante vacina&ccedil;&atilde;o, o Estado possui o 1<SUP>o</SUP>. rebanho bovino do Brasil, e um dos primeiros do mundo, com 24 milh&otilde;es e 700 mil cabe&ccedil;as, contribuindo com uma porcentagem significativa das exporta&ccedil;&otilde;es de carne bovina. Qualquer brote de aftosa que venha a macular esse estado sanit&aacute;rio teria de imediato uma enorme repercuss&atilde;o econ&ocirc;mica em n&iacute;vel local, nacional e internacional". O alerta foi dado ontem pelo engenheiro Josiel Quintino dos Santos, assessor de Meio Ambiente e Assuntos Ind&iacute;genas da Federa&ccedil;&atilde;o da Agricultura e Pecu&aacute;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&atilde;o e a viol&ecirc;ncia na regi&atilde;o fez com que a Ag&ecirc;ncia Estadual de Defesa Sanit&aacute;ria Animal e Vegetal (Iagro) tenha suspendido o trabalho de vigil&acirc;ncia e vacina&ccedil;&atilde;o do rebanho das fazendas invadidas por &iacute;ndios guaranis, caiu&aacute;s e &ntilde;andeva. </P>
<P>Quintino acrescentou a preocupa&ccedil;&atilde;o existente no Estado "com os conflitos fabricados e incentivados pelo Conselho Indigenista Mission&aacute;rio (Cimi), e favorecidos pela Funda&ccedil;&atilde;o Nacional do &Iacute;ndio, segundo j&aacute; foi documentado no relat&oacute;rio da CPI do Funai, na C&acirc;mara dos Deputados". O assessor da Famasul informou que os &iacute;ndios, contrariamente ao informado por alguns meios de imprensa, "n&atilde;o abandonaram nenhuma das 14 fazendas invadidas, e at&eacute; o momento n&atilde;o permitiram o trabalho de per&iacute;cia judicial para avaliar a destrui&ccedil;&atilde;o causada". </P>
<B><P>Bras&iacute;lia: deputado Zauith den&uacute;ncia "manipula&ccedil;&atilde;o" de &iacute;ndios</P>
</B><P>Tamb&eacute;m ontem, em Bras&iacute;lia, o deputado sul-matogrossense Murilo Zauith (PFL) fez discurso na tribuna da C&acirc;mara para "denunciar os conflitos ind&iacute;genas" que vem ocorrendo em todo o Pa&iacute;s, incentivados pela "atua&ccedil;&atilde;o de determinadas organiza&ccedil;&otilde;es internacionais, que chegam a amea&ccedil;ar a soberania nacional" e de "pessoas inescrupulosas" que "manipulam" e "incitam os &iacute;ndios a invadir as propriedades rurais". Zauith acrescentou que esse "cen&aacute;rio devastador" j&aacute; vem causando "uma retra&ccedil;&atilde;o nos investimentos no agroneg&oacute;cio em Mato Grosso do Sul", atividade que "&eacute; o principal pilar da economia sul-matogrossense" (<A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DepZauith:DiscursoCompleto">DepZauith:DiscursoCompleto</A>).</P>
<B><P>Santa Catarina: Cimi e Funai fomentam caos, diz Federa&ccedil;&atilde;o da Agricultura </P>
</B><P>A Federa&ccedil;&atilde;o da Agricultura do Estado de Santa Catarina (Faesc), em nota de rep&uacute;dio diante do assassinato do pecuarista Olisses Stefani, recentemente vitimado com um tiro de carabina na cabe&ccedil;a por ind&iacute;genas que amea&ccedil;avam invadir propriedades rurais, afirma que sua morte "revela a dram&aacute;tica dimens&atilde;o a que chegaram os conflitos entre &iacute;ndios e produtores no grande Oeste catarinense". E acrescenta que "determinadas organiza&ccedil;&otilde;es, motivadas por objetivos inconfess&aacute;veis, fomentam o embate e exasperam a crise, tentando criar um cen&aacute;rio de caos e desordem", sendo "not&oacute;ria, nesse aspecto, a a&ccedil;&atilde;o do Conselho Indigenista Mission&aacute;rio (Cimi), cujos agentes imiscuem-se nas &aacute;reas ind&iacute;genas para fomentar a disc&oacute;rdia". Enquanto a Funda&ccedil;&atilde;o Nacional do &Iacute;ndio (Funai) oscila entre a in&eacute;rcia e a omiss&atilde;o, nada fazendo em favor da paz e da tranq&uuml;ilidade", sendo sua atua&ccedil;&atilde;o "marcada pela influ&ecirc;ncia de ONGs" (<A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Faesc:TextoCompleto">Faesc:TextoCompleto</A>).</P>
<P>040219AB / Atualidade Brasileira</P>
<P>&nbsp;LINKS:</P>
<P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino/Famasul:DesejoContato">DrQuintino/Famasul:DesejoContato</A></P>
<P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino/Famasul:DesejoContatoUrgente">DrQuintino/Famasul:DesejoContatoUrgente</A></P>
<P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DrQuintino/Famasul:DesejoContatoDeImprensa">DrQuintino/Famasul:DesejoContatoDeImprensa</A></P>
<P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DepZauith:DiscursoCompleto">DepZauith:DiscursoCompleto</A></P>
<P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Faesc:TextoCompleto">Faesc:TextoCompleto</A></P>
<P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:MinhaOpini&atilde;o">AtualidadeBrasileira:MinhaOpini&atilde;o</A></P>
<P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:Concordo">AtualidadeBrasileira:Concordo</A></P>
<P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:Discordo">AtualidadeBrasileira:Discordo</A></P>
<P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:Documenta&ccedil;&atilde;oUsada">AtualidadeBrasileira:Documenta&ccedil;&atilde;oUsada</A></P>
<P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=AtualidadeBrasileira:Remover">AtualidadeBrasileira:Remover</A></P>
<B><FONT SIZE=2><P ALIGN="CENTER">A difus&atilde;o deste comunicado, com uma finalidade exclusivamente informativa, &eacute; de responsabilidade da ag&ecirc;ncia Atualidade Brasileira (Rio de Janeiro). O texto pode ser reproduzido parcial ou totalmente, sendo recomend&aacute;vel, mas n&atilde;o necess&aacute;rio, citar a fonte.</P>
</B></FONT><P ALIGN="CENTER">&nbsp;</P>
<P>&nbsp;</P></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/>