From enum-bounces@ietf.org Mon Dec 03 12:41:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFHh-0003X7-Kq; Mon, 03 Dec 2007 12:40:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFHg-0003Ws-00 for enum@ietf.org; Mon, 03 Dec 2007 12:40:44 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzFHf-0005AO-Jm for enum@ietf.org; Mon, 03 Dec 2007 12:40:43 -0500 Received: from rshockeyPC (dhcp-15f8.ietf70.org [130.129.21.248]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lB3HduDF014534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2007 09:40:11 -0800 From: "Richard Shockey" To: "'IETF ENUM WG'" Date: Mon, 3 Dec 2007 12:39:23 -0500 Message-ID: <007a01c835d3$7e99f650$7bcde2f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: Acg102XcGvyKm3owRlKWQNA5yv1h6Q== x-cr-hashedpuzzle: VO8= BI8m CiED E0Am Gn6Q GtWa HZUW IXjs IzDm LRYS NzpG Pizg TO+T UABl Wqxn XP5a; 2; YQBsAGUAeABhAG4AZABlAHIALgBtAGEAeQByAGgAbwBmAGUAcgBAAG4AaQBjAC4AYQB0ADsAZQBuAHUAbQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {0B31ED00-82B9-4263-ACF9-CE0E3331CF2F}; cgBpAGMAaABhAHIAZABAAHMAaABvAGMAawBlAHkALgB1AHMA; Mon, 03 Dec 2007 17:39:06 GMT; cgBlAG0AaQBuAGQAZQByACAALgAuAC4AcgBlAG0AaQBuAGQAZQByACAAZwBlAHQAIAB5AG8AdQByACAAcAByAGUAcwBlAG4AdABhAHQAaQBvAG4AIABmAGkAbABlAHMA x-cr-puzzleid: {0B31ED00-82B9-4263-ACF9-CE0E3331CF2F} X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'Alexander Mayrhofer' Subject: [Enum] reminder ...reminder get your presentation files X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org For tommrrow to Alex ASAP Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Dec 03 15:15:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHhX-0003HU-7C; Mon, 03 Dec 2007 15:15:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHhW-0003Gn-0g; Mon, 03 Dec 2007 15:15:34 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzHhT-0004Zm-R0; Mon, 03 Dec 2007 15:15:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B5B302AC65; Mon, 3 Dec 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IzHgz-0003rx-GS; Mon, 03 Dec 2007 15:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 03 Dec 2007 15:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-infrastructure-07.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM Author(s) : J. Livingood, et al. Filename : draft-ietf-enum-infrastructure-07.txt Pages : 6 Date : 2007-12-3 This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa" as defined in RFC3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-enum-infrastructure-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-enum-infrastructure-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: <2007-12-3143612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-infrastructure-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-infrastructure-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-3143612.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Tue Dec 11 17:44:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Dpw-0000U0-Gy; Tue, 11 Dec 2007 17:44:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Dpv-0000Qe-DY for enum@ietf.org; Tue, 11 Dec 2007 17:44:23 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Dpu-0002yC-TS for enum@ietf.org; Tue, 11 Dec 2007 17:44:23 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Tue, 11 Dec 2007 17:44:22 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 11 Dec 2007 17:44:22 -0500 From: Hadriel Kaplan To: "enum@ietf.org" Date: Tue, 11 Dec 2007 17:43:38 -0500 Thread-Topic: New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Index: Acg8R0U9Sku/xSICRd2Dsl6gIwNeYA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: "Robert H. Walter" , "Creighton, Tom" , Raja Gopal Subject: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1180524740==" Errors-To: enum-bounces@ietf.org --===============1180524740== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC30273A60D76mailacmepacke_" --_000_E6C2E8958BA59A4FB960963D475F7AC30273A60D76mailacmepacke_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Howdy, We just submitted an I-D for a mechanism to include the source URI informat= ion in ENUM queries, primarily targeted at including the From/PAI SIP/Tel U= RI of the SIP Request which triggered the ENUM lookup, so the ENUM server c= an provide a response based on that. This is useful for performing source-= based ENUM routing and filtering. The I-D is available at: http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt We plan on presenting this in Philadelphia, but given the winding down of t= he ENUM WG we'd like to get comments now and see if there is interest in pr= ogressing this. Thanks! -hadriel --_000_E6C2E8958BA59A4FB960963D475F7AC30273A60D76mailacmepacke_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Howdy,

We just submitted an I-D for a mechanism to include the source URI information in ENUM queries, primarily targeted at including the From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM lookup, so the ENUM server can provide a response based on that.  This is useful for perfo= rming source-based ENUM routing and filtering.

 

The I-D is available at:

http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00= .txt

 

We plan on presenting this in Philadelphia, but given the winding down of the ENUM WG we'd like to get comments now and= see if there is interest in progressing this.

Thanks!

 

-hadriel

 

--_000_E6C2E8958BA59A4FB960963D475F7AC30273A60D76mailacmepacke_-- --===============1180524740== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1180524740==-- From enum-bounces@ietf.org Tue Dec 11 20:20:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2GGl-0005Mb-La; Tue, 11 Dec 2007 20:20:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2GGk-0005MV-IH for enum@ietf.org; Tue, 11 Dec 2007 20:20:14 -0500 Received: from mail.aus-biz.com ([65.23.153.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2GGj-00076J-Sl for enum@ietf.org; Tue, 11 Dec 2007 20:20:14 -0500 Received: from [192.168.1.2] (220-245-82-41.static.tpgi.com.au [220.245.82.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTP id E5143122659; Wed, 12 Dec 2007 12:20:09 +1100 (EST) Message-ID: <475F3745.1020107@e164.org> Date: Wed, 12 Dec 2007 12:20:05 +1100 From: Duane User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hadriel Kaplan wrote: > Howdy, > > We just submitted an I-D for a mechanism to include the source URI > information in ENUM queries, primarily targeted at including the > From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM lookup, > so the ENUM server can provide a response based on that. This is useful > for performing source-based ENUM routing and filtering. > > http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt While you have focused on the implemtation in your draft, I feel there is a number of privacy implications and you don't seemed to have covered this subject or anything like it in your current draft. Currently NAPTR/DNS requests, regardless if the informations is privately or publicly accessible, has the potential for the source IP and requested destination to be tracked in varying degrees. Source IP in most cases will be a shared server such as an upstream provider and depending on the time to live of DNS information may be requested by multiple people but only having one internet request which limits the ability for third parties to be able to identify the requester or requesters. This draft appears to make it trivial for a number of parties, such as most governments and numerous commercial entities which are actively researching ways to determine the caller. This proposal appears to make identifying and tracking callers when they wouldn't normally be in the call path or otherwise have access to such information. Most if not all methods in use at present, to limit or at least reduce unnecessary leaking of personal and organisational privacy, would fail if source URI was included. Such measures include, but aren't limited to, how DNS requests are sent - via provider and other upstream server(s) or requested directly via a local cache or using a public dns service, the number of users sharing the same caching name server or name server path if IP links are being monitored, the use of IP masquerading, the use of TOR or similar anonymising services to hide the requesters public IP, the use of encryption on VoIP packets but DNS requests/replies may not be using the same path and as a result may not be encrypted, IP link in terms of static or dynamic IP allocation. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 11 20:47:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ggm-0001UV-T2; Tue, 11 Dec 2007 20:47:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ggl-0001UE-89 for enum@ietf.org; Tue, 11 Dec 2007 20:47:07 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Ggk-0007uv-Ia for enum@ietf.org; Tue, 11 Dec 2007 20:47:07 -0500 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lBC1jilJ013537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Dec 2007 17:45:46 -0800 From: "Richard Shockey" To: "'Duane'" , "'Hadriel Kaplan'" References: <475F3745.1020107@e164.org> In-Reply-To: <475F3745.1020107@e164.org> Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Date: Tue, 11 Dec 2007 20:45:53 -0500 Message-ID: <00b201c83c60$c0822220$41866660$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg8XRh0FeIHws/hTO+t6fzwjnTTLAAAXW0Q Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: enum@ietf.org, 'Cullen Jennings' , "'Creighton, Tom'" , 'Raja Gopal' , "'Peterson, Jon'" , "'Robert H. Walter'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The privacy issues here are central as you correctly point out. But I would not assume that these queries are going to be used in the context of the single root DNS. There have always been split views of the DNS and there always will be. The authors need to be very clear under what circumstances this class of query is used and under what network elements actually use the query and what are the security aspects that these queries are used in. Is this private ENUM implementation issue? That said the larger issue is this document a ENUM WG or an DNSEXT document. Upper IETF Management needs to address this issue ASAP. However it is manifestly self evident the direction we have been going in the ENUM WG is what is the use of RFC 3761 "technology" for a variety SIP session related routing/signaling issues outside the general scope of e164.arpa. That decision has already been made with our ongoing drafts on LNP, CNAM and trunk group data. IMHO the document is clearly "in scope" the only issue is what WG scope is it in. > -----Original Message----- > From: Duane [mailto:duane@e164.org] > Sent: Tuesday, December 11, 2007 8:20 PM > To: Hadriel Kaplan > Cc: enum@ietf.org; Robert H. Walter; Creighton, Tom; Raja Gopal > Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt > > Hadriel Kaplan wrote: > > Howdy, > > > > We just submitted an I-D for a mechanism to include the source URI > > information in ENUM queries, primarily targeted at including the > > From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM > lookup, > > so the ENUM server can provide a response based on that. This is > useful > > for performing source-based ENUM routing and filtering. > > > > http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri- > 00.txt > > While you have focused on the implemtation in your draft, I feel there > is a number of privacy implications and you don't seemed to have > covered > this subject or anything like it in your current draft. > > Currently NAPTR/DNS requests, regardless if the informations is > privately or publicly accessible, has the potential for the source IP > and requested destination to be tracked in varying degrees. Source IP > in > most cases will be a shared server such as an upstream provider and > depending on the time to live of DNS information may be requested by > multiple people but only having one internet request which limits the > ability for third parties to be able to identify the requester or > requesters. > > This draft appears to make it trivial for a number of parties, such as > most governments and numerous commercial entities which are actively > researching ways to determine the caller. This proposal appears to > make > identifying and tracking callers when they wouldn't normally be in the > call path or otherwise have access to such information. > > Most if not all methods in use at present, to limit or at least reduce > unnecessary leaking of personal and organisational privacy, would fail > if source URI was included. > > Such measures include, but aren't limited to, how DNS requests are > sent > - via provider and other upstream server(s) or requested directly via > a > local cache or using a public dns service, the number of users sharing > the same caching name server or name server path if IP links are being > monitored, the use of IP masquerading, the use of TOR or similar > anonymising services to hide the requesters public IP, the use of > encryption on VoIP packets but DNS requests/replies may not be using > the > same path and as a result may not be encrypted, IP link in terms of > static or dynamic IP allocation. > > -- > > Best regards, > Duane > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 11 22:04:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2HtA-0001VB-Ha; Tue, 11 Dec 2007 22:04:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ht9-0001QV-9E for enum@ietf.org; Tue, 11 Dec 2007 22:03:59 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Ht8-0002PL-PP for enum@ietf.org; Tue, 11 Dec 2007 22:03:59 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Tue, 11 Dec 2007 22:03:58 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 11 Dec 2007 22:03:58 -0500 From: Hadriel Kaplan To: Duane Date: Tue, 11 Dec 2007 22:01:56 -0500 Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Index: Acg8XSZkRgze7LxTT9GnXmQ3WoOk6QAC60pA Message-ID: References: <475F3745.1020107@e164.org> In-Reply-To: <475F3745.1020107@e164.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Yup, you're right, I should make that issue very explicit in the draft. Th= e purpose of this draft's extension is strictly for non-public ENUM use, an= d I should have said that (d'oh). The requester can decide if it wants to include the extension or not, and w= hether to provide an anonymous URI or not. If a device "in the network" wa= nts to issue such a request, and has the source URI info with which to do s= o, then I'm afraid the government can already get that information - direct= ly from that device. In fact, without this extension, to perform routing f= or certain types of application messages, such as SIP, would instead requir= e using SIP and sending the entire SIP request (bodies and all) to the rout= ing service and it would get far more information than just the source URI. -hadriel > -----Original Message----- > From: Duane [mailto:duane@e164.org] > Sent: Tuesday, December 11, 2007 8:20 PM > To: Hadriel Kaplan > Cc: enum@ietf.org; Robert H. Walter; Creighton, Tom; Raja Gopal > Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt > > Hadriel Kaplan wrote: > > Howdy, > > > > We just submitted an I-D for a mechanism to include the source URI > > information in ENUM queries, primarily targeted at including the > > From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM lookup= , > > so the ENUM server can provide a response based on that. This is usefu= l > > for performing source-based ENUM routing and filtering. > > > > http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt > > While you have focused on the implemtation in your draft, I feel there > is a number of privacy implications and you don't seemed to have covered > this subject or anything like it in your current draft. > > Currently NAPTR/DNS requests, regardless if the informations is > privately or publicly accessible, has the potential for the source IP > and requested destination to be tracked in varying degrees. Source IP in > most cases will be a shared server such as an upstream provider and > depending on the time to live of DNS information may be requested by > multiple people but only having one internet request which limits the > ability for third parties to be able to identify the requester or > requesters. > > This draft appears to make it trivial for a number of parties, such as > most governments and numerous commercial entities which are actively > researching ways to determine the caller. This proposal appears to make > identifying and tracking callers when they wouldn't normally be in the > call path or otherwise have access to such information. > > Most if not all methods in use at present, to limit or at least reduce > unnecessary leaking of personal and organisational privacy, would fail > if source URI was included. > > Such measures include, but aren't limited to, how DNS requests are sent > - via provider and other upstream server(s) or requested directly via a > local cache or using a public dns service, the number of users sharing > the same caching name server or name server path if IP links are being > monitored, the use of IP masquerading, the use of TOR or similar > anonymising services to hide the requesters public IP, the use of > encryption on VoIP packets but DNS requests/replies may not be using the > same path and as a result may not be encrypted, IP link in terms of > static or dynamic IP allocation. > > -- > > Best regards, > Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 11 22:21:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2I9j-0000sx-VH; Tue, 11 Dec 2007 22:21:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2I9h-0000rU-4Y for enum@ietf.org; Tue, 11 Dec 2007 22:21:06 -0500 Received: from mail.aus-biz.com ([65.23.153.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2I9f-0002nI-JH for enum@ietf.org; Tue, 11 Dec 2007 22:21:05 -0500 Received: from [192.168.1.2] (220-245-82-41.static.tpgi.com.au [220.245.82.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTP id 2976F122659; Wed, 12 Dec 2007 14:20:59 +1100 (EST) Message-ID: <475F5399.7040804@e164.org> Date: Wed, 12 Dec 2007 14:20:57 +1100 From: Duane User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: <475F3745.1020107@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hadriel Kaplan wrote: > Yup, you're right, I should make that issue very explicit in the > draft. The purpose of this draft's extension is strictly for > non-public ENUM use, and I should have said that (d'oh). I acknowledged this was the case, however even for non-public only enum use I feel privacy issues should still be mentioned, as I can almost garentee some peers somewhere at some point in time will end up, for what ever reasons, using the public internet to locate routing information. Perhaps you could go so far as forbidding this explicitly and suggesting VPN or private links or what not. > The requester can decide if it wants to include the extension or not, > and whether to provide an anonymous URI or not. If a device "in the > network" wants to issue such a request, and has the source URI info > with which to do so, then I'm afraid the government can already get > that information - directly from that device. In fact, without this > extension, to perform routing for certain types of application > messages, such as SIP, would instead require using SIP and sending > the entire SIP request (bodies and all) to the routing service and it > would get far more information than just the source URI. Actually the implications aren't limited to your own government now, all it takes is a few misconfigurations and suddenly DNS requests are hitting root and other name servers and sending all kinds of call meta information to any number of providers, countries, who knows. In any case, my primary concern is that this subject wasn't mentioned or was brushed over as being "There are no specific security issues for this mechanism, beyond those already applicable to DNS and ENUM." which isn't accurate and extra care should be taken if/when using lookups and sending more information then current/most NAPTR requests contain. -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 11 22:54:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2IgK-0002av-IV; Tue, 11 Dec 2007 22:54:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2IgJ-0002al-4B for enum@ietf.org; Tue, 11 Dec 2007 22:54:47 -0500 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2IgI-0002mn-M1 for enum@ietf.org; Tue, 11 Dec 2007 22:54:46 -0500 Received: from [10.1.1.228] (dhcp228.dhcp.erkkila.org [::ffff:10.1.1.228]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Wed, 12 Dec 2007 03:53:15 +0000 id 00208123.475F5B2B.00001C2D Message-ID: <475F5B2A.9040003@erkkila.org> Date: Tue, 11 Dec 2007 22:53:14 -0500 From: Paul Erkkila User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I think this is interesting work in the process of rolling more SCP functionality using ENUM as a building block.Implementations would certainly ease the transition off of current routing methods and move us closer to a "unified dip" model for routing. I definitely support it. The first issue I can think of is that it _seems_ primarily targeted towards the carrier ENUM/private peering space and might not see much use in the open spaces. The second issue is that I think some discussions with DNS folk about securing the query information (and validation). At note should at least be made of the possibility of using enumeration of the URI space to gain access to different response data. (similar to domain/space walking). -pee Hadriel Kaplan wrote: > Howdy, > > We just submitted an I-D for a mechanism to include the source URI > information in ENUM queries, primarily targeted at including the > From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM lookup, > so the ENUM server can provide a response based on that. This is useful > for performing source-based ENUM routing and filtering. > > > > The I-D is available at: > > http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt > > > > We plan on presenting this in Philadelphia, but given the winding down > of the ENUM WG we'd like to get comments now and see if there is > interest in progressing this. > > Thanks! > > > > -hadriel > > > > !DSPAM:475f12da304357515877532! > > > ------------------------------------------------------------------------ > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > !DSPAM:475f12da304357515877532! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 11 22:54:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2IgL-0002bC-RK; Tue, 11 Dec 2007 22:54:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2IgK-0002aq-2R for enum@ietf.org; Tue, 11 Dec 2007 22:54:48 -0500 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2IgI-0003Pf-JY for enum@ietf.org; Tue, 11 Dec 2007 22:54:48 -0500 Received: from [10.1.1.228] (dhcp228.dhcp.erkkila.org [::ffff:10.1.1.228]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Wed, 12 Dec 2007 03:54:36 +0000 id 00208125.475F5B7C.00001C60 Message-ID: <475F5B7C.3030606@erkkila.org> Date: Tue, 11 Dec 2007 22:54:36 -0500 From: Paul Erkkila User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I think this is interesting work in the process of rolling more SCP functionality using ENUM as a building block.Implementations would certainly ease the transition off of current routing methods and move us closer to a "unified dip" model for routing. I definitely support it. The first issue I can think of is that it _seems_ primarily targeted towards the carrier ENUM/private peering space and might not see much use in the open spaces. The second issue is that I think some discussions with DNS folk about securing the query information (and validation). At note should at least be made of the possibility of using enumeration of the URI space to gain access to different response data. (similar to domain/space walking). -pee Hadriel Kaplan wrote: > Howdy, > > We just submitted an I-D for a mechanism to include the source URI > information in ENUM queries, primarily targeted at including the > From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM lookup, > so the ENUM server can provide a response based on that. This is useful > for performing source-based ENUM routing and filtering. > > > > The I-D is available at: > > http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt > > > > We plan on presenting this in Philadelphia, but given the winding down > of the ENUM WG we'd like to get comments now and see if there is > interest in progressing this. > > Thanks! > > > > -hadriel > > > > !DSPAM:475f12da304357515877532! > > > ------------------------------------------------------------------------ > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > !DSPAM:475f12da304357515877532! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 11 22:54:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2IgK-0002av-IV; Tue, 11 Dec 2007 22:54:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2IgJ-0002al-4B for enum@ietf.org; Tue, 11 Dec 2007 22:54:47 -0500 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2IgI-0002mn-M1 for enum@ietf.org; Tue, 11 Dec 2007 22:54:46 -0500 Received: from [10.1.1.228] (dhcp228.dhcp.erkkila.org [::ffff:10.1.1.228]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Wed, 12 Dec 2007 03:53:15 +0000 id 00208123.475F5B2B.00001C2D Message-ID: <475F5B2A.9040003@erkkila.org> Date: Tue, 11 Dec 2007 22:53:14 -0500 From: Paul Erkkila User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I think this is interesting work in the process of rolling more SCP functionality using ENUM as a building block.Implementations would certainly ease the transition off of current routing methods and move us closer to a "unified dip" model for routing. I definitely support it. The first issue I can think of is that it _seems_ primarily targeted towards the carrier ENUM/private peering space and might not see much use in the open spaces. The second issue is that I think some discussions with DNS folk about securing the query information (and validation). At note should at least be made of the possibility of using enumeration of the URI space to gain access to different response data. (similar to domain/space walking). -pee Hadriel Kaplan wrote: > Howdy, > > We just submitted an I-D for a mechanism to include the source URI > information in ENUM queries, primarily targeted at including the > From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM lookup, > so the ENUM server can provide a response based on that. This is useful > for performing source-based ENUM routing and filtering. > > > > The I-D is available at: > > http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt > > > > We plan on presenting this in Philadelphia, but given the winding down > of the ENUM WG we'd like to get comments now and see if there is > interest in progressing this. > > Thanks! > > > > -hadriel > > > > !DSPAM:475f12da304357515877532! > > > ------------------------------------------------------------------------ > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > !DSPAM:475f12da304357515877532! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 11 22:54:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2IgL-0002bC-RK; Tue, 11 Dec 2007 22:54:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2IgK-0002aq-2R for enum@ietf.org; Tue, 11 Dec 2007 22:54:48 -0500 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2IgI-0003Pf-JY for enum@ietf.org; Tue, 11 Dec 2007 22:54:48 -0500 Received: from [10.1.1.228] (dhcp228.dhcp.erkkila.org [::ffff:10.1.1.228]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Wed, 12 Dec 2007 03:54:36 +0000 id 00208125.475F5B7C.00001C60 Message-ID: <475F5B7C.3030606@erkkila.org> Date: Tue, 11 Dec 2007 22:54:36 -0500 From: Paul Erkkila User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I think this is interesting work in the process of rolling more SCP functionality using ENUM as a building block.Implementations would certainly ease the transition off of current routing methods and move us closer to a "unified dip" model for routing. I definitely support it. The first issue I can think of is that it _seems_ primarily targeted towards the carrier ENUM/private peering space and might not see much use in the open spaces. The second issue is that I think some discussions with DNS folk about securing the query information (and validation). At note should at least be made of the possibility of using enumeration of the URI space to gain access to different response data. (similar to domain/space walking). -pee Hadriel Kaplan wrote: > Howdy, > > We just submitted an I-D for a mechanism to include the source URI > information in ENUM queries, primarily targeted at including the > From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM lookup, > so the ENUM server can provide a response based on that. This is useful > for performing source-based ENUM routing and filtering. > > > > The I-D is available at: > > http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt > > > > We plan on presenting this in Philadelphia, but given the winding down > of the ENUM WG we'd like to get comments now and see if there is > interest in progressing this. > > Thanks! > > > > -hadriel > > > > !DSPAM:475f12da304357515877532! > > > ------------------------------------------------------------------------ > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > > > !DSPAM:475f12da304357515877532! _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 03:57:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2NP1-0002js-KB; Wed, 12 Dec 2007 03:57:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2NP0-0002jf-5R for enum@ietf.org; Wed, 12 Dec 2007 03:57:14 -0500 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2NOz-0000oJ-TS for enum@ietf.org; Wed, 12 Dec 2007 03:57:14 -0500 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id lBC8mnFq032180; Wed, 12 Dec 2007 03:48:49 -0500 Received: from DUL1DUSER-L1.verisign.com ([10.169.64.103]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Dec 2007 08:55:09 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Dec 2007 09:56:33 +0100 To: Duane , Hadriel Kaplan From: Tony Rutkowski Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt In-Reply-To: <475F3745.1020107@e164.org> References: <475F3745.1020107@e164.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Dec 2007 08:55:09.0678 (UTC) FILETIME=[B30FC8E0:01C83C9C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >This draft appears to make it trivial for a number of parties, such as >most governments and numerous commercial entities which are actively >researching ways to determine the caller. This proposal appears to make >identifying and tracking callers when they wouldn't normally be in the >call path or otherwise have access to such information. Capturing this information is required by the EU Data Retention Directive and its clones in many other countries for VoIP use. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 09:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2SjN-0000sl-Eh; Wed, 12 Dec 2007 09:38:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2SjM-0000km-9u for enum@ietf.org; Wed, 12 Dec 2007 09:38:36 -0500 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2SjK-0005Wi-5m for enum@ietf.org; Wed, 12 Dec 2007 09:38:36 -0500 Received: from [10.1.1.228] (dhcp228.dhcp.erkkila.org [::ffff:10.1.1.228]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Wed, 12 Dec 2007 14:38:33 +0000 id 0023863F.475FF269.0000630D Message-ID: <475FF269.9090002@erkkila.org> Date: Wed, 12 Dec 2007 09:38:33 -0500 From: Paul Erkkila User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Tony Rutkowski Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: <475F3745.1020107@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "enum@ietf.org" , "Creighton, Tom" , Raja Gopal , Hadriel Kaplan , "Robert H. Walter" , Duane X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Tony Rutkowski wrote: > >> This draft appears to make it trivial for a number of parties, such as >> most governments and numerous commercial entities which are actively >> researching ways to determine the caller. This proposal appears to make >> identifying and tracking callers when they wouldn't normally be in the >> call path or otherwise have access to such information. > > Capturing this information is required by the EU > Data Retention Directive and its clones in many > other countries for VoIP use. > > --tony That doesn't really hold true for non licensed/corporate communications in most instances (as much as some people would like that to be the case). Taken into a public ENUM context (country sanctioned or not) the concerns seem valid to me. Lets say I have a border/gateway appliance in my Internet connected cave and and my friend has one in his. Both have a DNS implementation running on them capable of understanding this type of query, and both have a chunk of an ENUM tree delegated to them. Shouldn't we be able to make use of this same extra query data to make decisions and enforce policy, while still maintaining privacy? (Use crypto/IPSEC is probably a valid counter argument) -pee _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 09:48:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2SsZ-0001od-7s; Wed, 12 Dec 2007 09:48:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2SsY-0001oW-23 for enum@ietf.org; Wed, 12 Dec 2007 09:48:06 -0500 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2SsX-00066a-Nj for enum@ietf.org; Wed, 12 Dec 2007 09:48:05 -0500 Received: from [10.1.1.228] (dhcp228.dhcp.erkkila.org [::ffff:10.1.1.228]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Wed, 12 Dec 2007 14:48:05 +0000 id 0023863F.475FF4A5.00006462 Message-ID: <475FF4A4.5090500@erkkila.org> Date: Wed, 12 Dec 2007 09:48:04 -0500 From: Paul Erkkila User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hadriel Kaplan wrote: > Howdy, > > We just submitted an I-D for a mechanism to include the source URI > information in ENUM queries, primarily targeted at including the > From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM lookup, > so the ENUM server can provide a response based on that. This is useful > for performing source-based ENUM routing and filtering. > Just to add another topic into this thread, do we think the DNS is the appropriate place for this type of decision to be made? There is certainly precedence if this is taken as an extension of the DNS "views" concept. However the argument can be made that this is better handled by not doing it in DNS, but instead handling it at the endpoint that pops out at the end of DDDS processing. If we ignore re-targeting and evilbox manhandling of the messaging we need to transmit the same information anyway correct? I'm in the DNS camp for what it's worth, since the protocol is to my knowledge lighter/faster and generally more efficient for these types of stateless queries. However since this would add URI parsing and possibly crypto elements into the mix I reserve the right to change that opinion ;). -pee _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 10:01:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2T5e-0001sd-CC; Wed, 12 Dec 2007 10:01:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2T5d-0001sS-Cy for enum@ietf.org; Wed, 12 Dec 2007 10:01:37 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2T5b-00067K-Jt for enum@ietf.org; Wed, 12 Dec 2007 10:01:37 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1J2T5W-0003fM-00; Wed, 12 Dec 2007 16:01:30 +0100 Date: Wed, 12 Dec 2007 16:01:30 +0100 From: Otmar Lendl To: Hadriel Kaplan Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Message-ID: <20071212150130.GA14079@nic.at> Mail-Followup-To: Otmar Lendl , Hadriel Kaplan , "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2007/12/11 23:12, Hadriel Kaplan wrote: > Howdy, > > We just submitted an I-D for a mechanism to include the source URI > information in ENUM queries, primarily targeted at including the > From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM > lookup, so the ENUM server can provide a response based on that. This > is useful for performing source-based ENUM routing and filtering. I can see the motivation. As others have stated, this is not appropriate for the public e164.arpa tree. The DNS protocol makes some assumptions about the environment it operates in. Caching, idempotent queries, public queries, ... We have already layered a few additions on the base protocol, from DNS views (different answers for different clients), TSIG (authentication of clients) to private roots. With this proposal, the basic premise of DNS lookups (FQDN + RRTYPE => RRSET) is extended once more. DNS is thus used as an almost generic lookup protocol. Yes, the incremental change ist not that big. The question remains: Have we now reached the point where we should stop fiddling with the DNS protocol and should instead look for a directory lookup protocol which was designed from the beginning to support authenticated and complex queries returning structured data? As this is not for e164.arpa, but private trees instead, do you actually need the sub-tree delegation feature of DNS/ENUM? Or is ENUM just used as a simple query protocol into a single database? /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 10:01:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2T5v-00029Z-S9; Wed, 12 Dec 2007 10:01:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2T5u-00029Q-Kd for enum@ietf.org; Wed, 12 Dec 2007 10:01:54 -0500 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2T5t-00067y-WE for enum@ietf.org; Wed, 12 Dec 2007 10:01:54 -0500 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id lBCEsBZW029610; Wed, 12 Dec 2007 09:54:11 -0500 Received: from DUL1DUSER-L1.verisign.com ([10.169.64.103]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Dec 2007 10:01:39 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Dec 2007 16:01:37 +0100 To: Paul Erkkila From: Tony Rutkowski Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt In-Reply-To: <475FF269.9090002@erkkila.org> References: <475F3745.1020107@e164.org> <475FF269.9090002@erkkila.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Dec 2007 15:01:39.0743 (UTC) FILETIME=[E6296AF0:01C83CCF] X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "enum@ietf.org" , "Creighton, Tom" , Raja Gopal , Hadriel Kaplan , "Robert H. Walter" , Duane X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Paul, >That doesn't really hold true for non licensed/corporate communications >in most instances (as much as some people would like that to be the >case). Taken into a public ENUM context (country sanctioned or not) the >concerns seem valid to me. Article 1 of the Directive establishes the obligations of all "...providers of publicly available electronic communications services or of public communications networks." Public availability rather than licensing is the operative delimitation. E.164 numbers by definition apply to public telecommunication networks. I suppose you could escape the requirements by using your own numbering scheme within networks not available to the public. --tony _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 10:25:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2TT4-0004PC-NI; Wed, 12 Dec 2007 10:25:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2TT3-0004Km-TY for enum@ietf.org; Wed, 12 Dec 2007 10:25:49 -0500 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2TT3-0007pb-JT for enum@ietf.org; Wed, 12 Dec 2007 10:25:49 -0500 Received: from [10.1.1.228] (dhcp228.dhcp.erkkila.org [::ffff:10.1.1.228]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Wed, 12 Dec 2007 15:25:49 +0000 id 00237FD3.475FFD7D.0000699B Message-ID: <475FFD7C.80907@erkkila.org> Date: Wed, 12 Dec 2007 10:25:48 -0500 From: Paul Erkkila User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Otmar Lendl , Hadriel Kaplan , "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: <20071212150130.GA14079@nic.at> In-Reply-To: <20071212150130.GA14079@nic.at> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Otmar Lendl wrote: > > > Yes, the incremental change ist not that big. The question remains: > > Have we now reached the point where we should stop fiddling with the > DNS protocol and should instead look for a directory lookup protocol > which was designed from the beginning to support authenticated and > complex queries returning structured data? LDAP? > > As this is not for e164.arpa, but private trees instead, do you actually > need the sub-tree delegation feature of DNS/ENUM? Or is ENUM just used > as a simple query protocol into a single database? Not to discount the vast deployment of DNS, but i think delegation is one of the key draws for many implementations. Even data controlled by a single entity can benefit from the hierarchy and scaling opportunities that build from it. > > /ol -pee _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 10:28:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2TVI-0006s9-7A; Wed, 12 Dec 2007 10:28:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2TVG-0006s1-BS for enum@ietf.org; Wed, 12 Dec 2007 10:28:06 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2TVF-0007vH-Te for enum@ietf.org; Wed, 12 Dec 2007 10:28:06 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1J2TVC-0003fm-00 for ; Wed, 12 Dec 2007 16:28:02 +0100 Date: Wed, 12 Dec 2007 16:28:02 +0100 From: Otmar Lendl To: enum@ietf.org Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Message-ID: <20071212152802.GB14079@nic.at> Mail-Followup-To: Otmar Lendl , enum@ietf.org References: <475F3745.1020107@e164.org> <475FF269.9090002@erkkila.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2007/12/12 16:12, Tony Rutkowski wrote: > Hi Paul, > > >That doesn't really hold true for non licensed/corporate communications > >in most instances (as much as some people would like that to be the > >case). Taken into a public ENUM context (country sanctioned or not) the > >concerns seem valid to me. > > Article 1 of the Directive establishes the obligations of all > "...providers of publicly available electronic communications > services or of public communications networks." > > Public availability rather than licensing is the operative > delimitation. E.164 numbers by definition apply to public > telecommunication networks. I suppose you could escape > the requirements by using your own numbering scheme > within networks not available to the public. That's not the interpretation that is operational in Austria. (at least for similar laws; Austria has not yet implemented that directive, and hopefully never will.) Here, all these regulations apply only to services which are offered to the public, in the sense of "anyone can buy service from that provider or network". They are not seen as applicable to PBXs (and mail-servers) run by corporations (or private persons) for the own use. This has nothing to do with E.164 numbers (for calls) and RFC822 addresses (for mail). /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 10:45:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Tlr-00012s-7k; Wed, 12 Dec 2007 10:45:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Tlp-00012E-4H for enum@ietf.org; Wed, 12 Dec 2007 10:45:13 -0500 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Tlo-0000GH-Nd for enum@ietf.org; Wed, 12 Dec 2007 10:45:13 -0500 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1J2Tlf-0003fz-00; Wed, 12 Dec 2007 16:45:03 +0100 Date: Wed, 12 Dec 2007 16:45:03 +0100 From: Otmar Lendl To: Paul Erkkila Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Message-ID: <20071212154502.GC14079@nic.at> Mail-Followup-To: Otmar Lendl , Paul Erkkila , Hadriel Kaplan , "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal References: <20071212150130.GA14079@nic.at> <475FFD7C.80907@erkkila.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475FFD7C.80907@erkkila.org> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal , Hadriel Kaplan X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On 2007/12/12 16:12, Paul Erkkila wrote: > Otmar Lendl wrote: > > > > > > Yes, the incremental change ist not that big. The question remains: > > > > Have we now reached the point where we should stop fiddling with the > > DNS protocol and should instead look for a directory lookup protocol > > which was designed from the beginning to support authenticated and > > complex queries returning structured data? > > LDAP? Hold your horses. All I want here is to step back and re-evaluate whether DNS is still the appropriate baseline protocol on top of which you want to build your application. We're piling extension upon extension here. At some point, the foundations will crack and we can't patch over the limitations (or better, assumptions) of the initial design any longer. I'm not claiming (nor ruling out) we're there yet. I did not suggest alternative protocol. We just need to think this through. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 10:54:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2TuP-0000Kd-Ox; Wed, 12 Dec 2007 10:54:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2TuO-0000GK-EC for enum@ietf.org; Wed, 12 Dec 2007 10:54:04 -0500 Received: from services.erkkila.org ([24.97.94.217] helo=erkkila.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2TuO-0000ZD-3c for enum@ietf.org; Wed, 12 Dec 2007 10:54:04 -0500 Received: from [10.1.1.228] (dhcp228.dhcp.erkkila.org [::ffff:10.1.1.228]) (AUTH: PLAIN pee@erkkila.org, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by erkkila.org with esmtp; Wed, 12 Dec 2007 15:54:03 +0000 id 0023864E.4760041B.00006E18 Message-ID: <4760041B.502@erkkila.org> Date: Wed, 12 Dec 2007 10:54:03 -0500 From: Paul Erkkila User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Otmar Lendl , Paul Erkkila , Hadriel Kaplan , "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: <20071212150130.GA14079@nic.at> <475FFD7C.80907@erkkila.org> <20071212154502.GC14079@nic.at> In-Reply-To: <20071212154502.GC14079@nic.at> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Otmar Lendl wrote: > On 2007/12/12 16:12, Paul Erkkila wrote: >> Otmar Lendl wrote: >>> >>> Yes, the incremental change ist not that big. The question remains: >>> >>> Have we now reached the point where we should stop fiddling with the >>> DNS protocol and should instead look for a directory lookup protocol >>> which was designed from the beginning to support authenticated and >>> complex queries returning structured data? >> LDAP? > > Hold your horses. > > All I want here is to step back and re-evaluate whether DNS is still > the appropriate baseline protocol on top of which you want to build > your application. We're piling extension upon extension here. At some > point, the foundations will crack and we can't patch over the > limitations (or better, assumptions) of the initial design any longer. > > I'm not claiming (nor ruling out) we're there yet. I did not suggest alternative protocol. > > We just need to think this through. > > /ol Was just pointing out your query protocol already exists, not suggesting we use it ;). I completely agree that re-evaluation is needed here as we use the DNS in unique ways. -pee _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 10:56:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Tww-0006wX-OU; Wed, 12 Dec 2007 10:56:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Twu-0006wJ-P5 for enum@ietf.org; Wed, 12 Dec 2007 10:56:40 -0500 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Twr-0000U1-Ps for enum@ietf.org; Wed, 12 Dec 2007 10:56:40 -0500 Received: from [193.0.2.27] (account jim [193.0.2.27] verified) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 208632; Wed, 12 Dec 2007 15:56:36 +0000 In-Reply-To: <20071212150130.GA14079@nic.at> References: <20071212150130.GA14079@nic.at> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <79F4FD70-837A-4E3D-ABB7-54C8BD0BD691@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Date: Wed, 12 Dec 2007 15:55:33 +0000 To: Otmar Lendl X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal , Hadriel Kaplan Subject: [Enum] Re: DNS protocol religion X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Dec 12, 2007, at 15:01, Otmar Lendl wrote: > Have we now reached the point where we should stop fiddling with the > DNS protocol Yes. The dnsext WG has gone to sleep and may never wake up. So, for the moment at least, it's time to stop fiddling with the DNS protocol. > and should instead look for a directory lookup protocol > which was designed from the beginning to support authenticated and > complex queries returning structured data? No. There are plenty of these already: LDAP, X.500, etc, etc. Why add another one? It'll only be as successful as its predecessors. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 11:41:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Udn-0005fI-Ox; Wed, 12 Dec 2007 11:40:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Udm-0005fB-0R for enum@ietf.org; Wed, 12 Dec 2007 11:40:58 -0500 Received: from smtp.denic.de ([81.91.161.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Udl-0001xo-Hl for enum@ietf.org; Wed, 12 Dec 2007 11:40:57 -0500 Received: from mail-int1.denic.de (mail-int1.denic.de [192.168.0.45]) by smtp.denic.de with esmtp id 1J2Udk-0003Bw-Nf; Wed, 12 Dec 2007 17:40:56 +0100 Received: from localhost by mail-int1.denic.de with local id 1J2Udk-0003Dr-00; Wed, 12 Dec 2007 17:40:56 +0100 Date: Wed, 12 Dec 2007 17:40:56 +0100 From: Peter Koch To: enum@ietf.org Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Message-ID: <20071212164056.GG11923@denics7.denic.de> Mail-Followup-To: enum@ietf.org References: <475F3745.1020107@e164.org> <00b201c83c60$c0822220$41866660$@us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b201c83c60$c0822220$41866660$@us> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Tue, Dec 11, 2007 at 08:45:53PM -0500, Richard Shockey wrote: > That said the larger issue is this document a ENUM WG or an DNSEXT document. on a more abstract level this is the counterpart to the NSID EDNS option that now would enable the client to identify itself. The extension is that the server would be allowed to change the response based on this identity. First, this would be a massive paradigm shift (I know that "views" and src-addr based "tricks" exist, but they live ouside the architecture), which should, if at all, be discussed in the main WG responsible for protocol maintenance. Second, this "identity" transported by EDNS is hop-by-hop, where what is obviously intended here is end-to-end. Intermediates cannot be expected to either transparently transmit or unpack and repack this option code. This addition to (QNAME,QTYPE,QCLASS) also does not seem to interact too well with DNSSEC. > The ENUM client MUST NOT cache responses for such queries, and > instead MUST treat the TTL value as zero. Otherwise the local cache > would be used for subsequent queries, even if the originating info > changed, which would lead to false results. Clearly this could be This, albeit an obvious restriction, would have negative side effects. And apart from the privacy issues raised by others, > There are no specific security issues for this mechanism, beyond > those already applicable to DNS and ENUM. also would need to discuss how the "URI" (or in general: the option payload) would be authenticated and/or authorized and what the security model behind the different "views" is. It appears to me that not only are the saddlebags about to kill the animal , but in fact adding more protocol elements to ENUM (or DNS, for that matter) only for use in "private infrastructure ENUM" scenarios urgently suggests to revisit the applicability of the underlying infrastructure for this use case. Maybe it's time to replace the "ENUM" in "Infrastructure ENUM" with another term. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 12:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Uz9-0000ka-RL; Wed, 12 Dec 2007 12:03:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Uz8-0000kN-RG for enum@ietf.org; Wed, 12 Dec 2007 12:03:02 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Uz8-0002an-ET for enum@ietf.org; Wed, 12 Dec 2007 12:03:02 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Wed, 12 Dec 2007 12:03:01 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 12 Dec 2007 12:02:59 -0500 From: Hadriel Kaplan To: Otmar Lendl Date: Wed, 12 Dec 2007 12:00:41 -0500 Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Index: Acg8z+QTaFUTx6rmSDGosvG1PPBqUQACsGvg Message-ID: References: <20071212150130.GA14079@nic.at> In-Reply-To: <20071212150130.GA14079@nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Otmar Lendl [mailto:lendl@labs.nic.at] On Behalf Of Otmar Lendl > Sent: Wednesday, December 12, 2007 10:02 AM > > The DNS protocol makes some assumptions about the environment it > operates in. Caching, idempotent queries, public queries, ... > We have already layered a few additions on the base protocol, from DNS > views > (different answers for different clients), TSIG (authentication of > clients) > to private roots. DNS views are not an extensions to the protocol, AFAIK. They're purely int= ernal to the DNS server, based on who asked it a query, no? In some ways t= his draft is making a view explicitly signaled. ;) > Yes, the incremental change ist not that big. The question remains: > > Have we now reached the point where we should stop fiddling with the > DNS protocol and should instead look for a directory lookup protocol > which was designed from the beginning to support authenticated and > complex queries returning structured data? Nope. Several such protocols already exist and are available, if people wa= nt to use them. DNS as a protocol still has advantages over the others. You also make it sound like we "fiddle" with the DNS protocol constantly or= consistently. AFAIK, that hasn't been the case with respect to ENUM. Unl= ess you're saying new service types are extensions to the protocol itself. > As this is not for e164.arpa, but private trees instead, do you actually > need the sub-tree delegation feature of DNS/ENUM? Or is ENUM just used > as a simple query protocol into a single database? Both. The sub-tree model is incredibly useful for scaling in bigger networ= ks or handling federations/registries, and it's also the case that it somet= imes is just a simple query protocol to a single DB. -hadriel _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 13:05:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Vxs-0000mm-FX; Wed, 12 Dec 2007 13:05:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Vxp-0000mh-IJ for enum@ietf.org; Wed, 12 Dec 2007 13:05:45 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Vxp-00072c-1l for enum@ietf.org; Wed, 12 Dec 2007 13:05:45 -0500 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lBCI4wok013908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Dec 2007 10:05:04 -0800 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Otmar Lendl'" References: <20071212150130.GA14079@nic.at> In-Reply-To: Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Date: Wed, 12 Dec 2007 13:05:06 -0500 Message-ID: <0d8701c83ce9$8fac0100$af040300$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg8z+QTaFUTx6rmSDGosvG1PPBqUQACsGvgAAMRP3A= Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: enum@ietf.org, "'Robert H. Walter'" , "'Creighton, Tom'" , 'Raja Gopal' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Chair hat off.. It is worth noting again that this is NOT intended for e164.arpa or probably any domain within the single root DNS. Adding a new protocol for this function would guarantee it would not be used...ever. The DNS protocols have been "fiddeled" with so long they are barely recognizable as it is. I don't see what the problem is. The issue of identifying where the query is coming from was an issue in my CNAM draft. Though it did not require identification and authentication it just as easily could have. The issue in using 3761 for CNAM queries was much more practical. No vendor at this stage of ENUM deployments is ever going to put another protocol stack in the softswitches or SMB's for this type of number translation function. In order to deploy a working protocol to deal with a specific use case like this you deal with the cards your dealt and in this case again that is 3761. Obviously people using SIP redirect for number translations don't have this problem but we all know what the issues with SIP redirect are, for one you get a 10X performance hit on query-response time. The first order issue to resolve is, does this proposal identify a practical problem in ENUM deployments that needs to get fixed, and IMHO the answer to that is unquestionably YES. > > > As this is not for e164.arpa, but private trees instead, do you > actually > > need the sub-tree delegation feature of DNS/ENUM? Or is ENUM just > used > > as a simple query protocol into a single database? > > Both. The sub-tree model is incredibly useful for scaling in bigger > networks or handling federations/registries, and it's also the case > that it sometimes is just a simple query protocol to a single DB. > > -hadriel > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 14:20:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2X7f-0007C6-GI; Wed, 12 Dec 2007 14:19:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2X7e-0007Bz-4P for enum@ietf.org; Wed, 12 Dec 2007 14:19:58 -0500 Received: from omzesmtp01.mci.com ([199.249.17.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2X7d-0000sy-9d for enum@ietf.org; Wed, 12 Dec 2007 14:19:57 -0500 Received: from dgismtp02.mcilink.com ([166.38.58.142]) by firewall.verizonbusiness.com (Iplanet MTA 5.2) with ESMTP id <0JSY0098BANVEQ@firewall.verizonbusiness.com> for enum@ietf.org; Wed, 12 Dec 2007 19:11:55 +0000 (GMT) Received: from dgismtp02.mcilink.com ([127.0.0.1]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JSY00J21ANUJ7@dgismtp02.mcilink.com> for enum@ietf.org; Wed, 12 Dec 2007 19:11:54 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([153.39.68.167]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JSY00IDBANUSC@dgismtp02.mcilink.com> for enum@ietf.org; Wed, 12 Dec 2007 19:11:54 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.2]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 19:11:54 +0000 Date: Wed, 12 Dec 2007 19:11:48 +0000 From: "Dwight, Timothy M (Tim)" Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt In-reply-to: <0d8701c83ce9$8fac0100$af040300$@us> To: enum@ietf.org Message-id: <092B2658AAB56A4D80836399A4C4703101FE8E22@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-index: Acg8z+QTaFUTx6rmSDGosvG1PPBqUQACsGvgAAMRP3AAAXcVQA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20071212150130.GA14079@nic.at> <0d8701c83ce9$8fac0100$af040300$@us> X-OriginalArrivalTime: 12 Dec 2007 19:11:54.0080 (UTC) FILETIME=[DB676E00:01C83CF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I agree with Richard as to the need. There are many cases in which the response to the ENUM query needs to be different, depending on "where the query came from". The latter phrase sometimes refers to the caller's telephone number (e.g., in the case of selecting a PSTN gateway to which to terminate the call, you need to determine whether calling and called party are in the same rate center and if so, select an ingress point to the appropriate class 5 exchange; otherwise select an ingress point to the long distance network) and sometimes to the "administrative entity" from which you received the call (carriers may have business arrangements that they need to honor, e.g., a special set of ingress points for business partners). Today there are products that can vary the ENUM query response based on information not present in a standard DNS/ENUM query. Usually they combine an application server that supports both PSTN routing and SIP redirect, and an ENUM server. Sorta like this: +--------------+ | PSTN routing | | logic & DB | +--------------+ | | (augmented?) +------------+ INVITE +--------+ ENUM query +--------+ | Call | --------> | SIP | --------------> | ENUM | | Processing | | app | | server | | Device | <-------- | server | <-------------- | | +------------+ 302 +--------+ ENUM response +--------+ I suppose there must be a proprietary interface between the two; which Hadriel's proposal might standardize. That seems useful. I agree that SIP redirect overhead is much higher than that of a DNS/ENUM query. As diagrammed above this wouldn't go away, because the "dumb" call processing device still needs to talk to the "smart" app server, and SIP redirect is typically the only way to do so. However obviously there are "smart" call processing devices that implement, or can implement, PSTN routing logic. In that case performance might improve substantially. Whether this has to be done by enhancing the DNS/ENUM query as the draft suggests, I'm not close enough to the implementation to say. Tim > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us]=20 > Sent: Wednesday, December 12, 2007 12:05 PM > To: 'Hadriel Kaplan'; 'Otmar Lendl' > Cc: enum@ietf.org; 'Robert H. Walter'; 'Creighton, Tom'; 'Raja Gopal' > Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt >=20 >=20 > Chair hat off.. >=20 > It is worth noting again that this is NOT intended for=20 > e164.arpa or probably > any domain within the single root DNS.=20 >=20 > Adding a new protocol for this function would guarantee it=20 > would not be > used...ever. >=20 > The DNS protocols have been "fiddeled" with so long they are barely > recognizable as it is. I don't see what the problem is. >=20 > The issue of identifying where the query is coming from was=20 > an issue in my > CNAM draft. Though it did not require identification and=20 > authentication it > just as easily could have. The issue in using 3761 for CNAM=20 > queries was much > more practical.=20 >=20 > No vendor at this stage of ENUM deployments is ever going to=20 > put another > protocol stack in the softswitches or SMB's for this type of number > translation function. In order to deploy a working protocol=20 > to deal with a > specific use case like this you deal with the cards your=20 > dealt and in this > case again that is 3761. >=20 > Obviously people using SIP redirect for number translations=20 > don't have this > problem but we all know what the issues with SIP redirect=20 > are, for one you > get a 10X performance hit on query-response time. >=20 > The first order issue to resolve is, does this proposal identify a > practical problem in ENUM deployments that needs to get=20 > fixed, and IMHO the > answer to that is unquestionably YES. > =20 > > =20 > > > As this is not for e164.arpa, but private trees instead, do you > > actually > > > need the sub-tree delegation feature of DNS/ENUM? Or is ENUM just > > used > > > as a simple query protocol into a single database? > > =20 > > Both. The sub-tree model is incredibly useful for scaling=20 > in bigger > > networks or handling federations/registries, and it's also the case > > that it sometimes is just a simple query protocol to a single DB. > > =20 > > -hadriel > > =20 > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum >=20 >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 15:43:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2YQE-0007W2-8j; Wed, 12 Dec 2007 15:43:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2YQC-0007Vw-Oq for enum@ietf.org; Wed, 12 Dec 2007 15:43:12 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2YQ8-0001BL-Ei for enum@ietf.org; Wed, 12 Dec 2007 15:43:12 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 9167569D57; Wed, 12 Dec 2007 20:43:07 +0000 (GMT) In-Reply-To: <20071212164056.GG11923@denics7.denic.de> References: <475F3745.1020107@e164.org> <00b201c83c60$c0822220$41866660$@us> <20071212164056.GG11923@denics7.denic.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F671CD4-F447-487B-8C16-BA874EA9A763@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Date: Wed, 12 Dec 2007 20:42:58 +0000 To: Peter Koch X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Peter, folks, I agree with all of Peter's comments. Also... Forget ENUM. First, there is no such thing as an ENUM server - only a DNS server that acts authoritatively for domains associated (via ENUM) with E. 164 telephone numbers. Second, the fact that a modified ENUM client happens to be the source of these DNS queries is not significant to the DNS query itself, nor is it to the kind of response it receives. This draft describes a general mechanism for carrying option data within a DNS query that MAY identify the source of that query. The intended reaction of a DNS server that supported this extension would be to select from its data based on this source identity data as well as the QNAME, QCLASS and QTYPE. It seems that the client is associated with a DNS recursive resolver, and it appears that this resolver partitions any local cache space cache space depending on the source identifying data as well as the QNAME, QCLASS and QTYPE. This seems to require (very) special treatment for the DNS responses, and this special treatment seems to be orthogonal to the QTYPE or QTYPE. However, it's a DNS issue, not an issue for a group that specifies the ENUM protocol/algorithm, Enumservices and the guidelines for development of Enumservices. Considering process issues: This draft proposes a DNS extension and requests an EDNS option code to be assigned for this purpose. Looking at the extension registration process in RFC 2671, it seems that an Informational RFC is all that is required for an EDNS option code to be allocated. However, I guess that as an extension to DNS, this would be "of interest" to the DNSEXT group or maybe DNSOPTS, if DNSEXT sleeps with the fishes. Opinions requested - Peter? Who's calling? Vying as my biggest concern with this draft is authentication of the option data. How does one know whether the DNS user has any association with this data value? Authentication is not covered in the draft, and seems to be a REALLY REALLY hard problem using DNS. Up there with this is the way that the draft discards name space partitioning as "proprietary" and requiring collusion of every involved party. AFAICT, this draft needs the collusion of every involved party plus every intermediary DNS entity. ISTM that "in the privacy of your own home", using a technique similar to ENUM but combining (say) the source number with the destination number would seem to require no changes to anything. There would seem to be little or no standardisation required, as this is merely a provisioning issue and so appropriate for other fora (maybe PEPPERMINT, possibly SPEERMINT for the use case, but agreeing a choice on the name space partitioning is something for other folk). Please not in the ENUM WG - we have enough trouble using the DNS architecture as it is, without rewiring it (with special treatment) like this. all the best, Lawrence On 12 Dec 2007, at 16:40, Peter Koch wrote: > On Tue, Dec 11, 2007 at 08:45:53PM -0500, Richard Shockey wrote: > >> That said the larger issue is this document a ENUM WG or an DNSEXT >> document. > > on a more abstract level this is the counterpart to the NSID EDNS > option > that now would enable the client to identify itself. The extension > is that > the server would be allowed to change the response based on this > identity. > First, this would be a massive paradigm shift (I know that "views" and > src-addr based "tricks" exist, but they live ouside the architecture), > which should, if at all, be discussed in the main WG responsible > for protocol > maintenance. > > Second, this "identity" transported by EDNS is hop-by-hop, where > what is > obviously intended here is end-to-end. Intermediates cannot be > expected > to either transparently transmit or unpack and repack this option > code. > > This addition to (QNAME,QTYPE,QCLASS) also does not seem to > interact too > well with DNSSEC. > >> The ENUM client MUST NOT cache responses for such queries, and >> instead MUST treat the TTL value as zero. Otherwise the local cache >> would be used for subsequent queries, even if the originating info >> changed, which would lead to false results. Clearly this could be > > This, albeit an obvious restriction, would have negative side effects. > > And apart from the privacy issues raised by others, > >> There are no specific security issues for this mechanism, beyond >> those already applicable to DNS and ENUM. > > also would need to discuss how the "URI" (or in general: the option > payload) > would be authenticated and/or authorized and what the security > model behind > the different "views" is. > > It appears to me that not only are the saddlebags about to kill the > animal index.html>, > but in fact adding more protocol elements to ENUM (or DNS, for that > matter) > only for use in "private infrastructure ENUM" scenarios urgently > suggests > to revisit the applicability of the underlying infrastructure for this > use case. Maybe it's time to replace the "ENUM" in "Infrastructure > ENUM" > with another term. > > -Peter > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 15:53:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2YZu-0001Rf-9n; Wed, 12 Dec 2007 15:53:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2YZs-0001RY-9Y for enum@ietf.org; Wed, 12 Dec 2007 15:53:12 -0500 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2YZr-0001S0-TH for enum@ietf.org; Wed, 12 Dec 2007 15:53:12 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 5A08F69D68; Wed, 12 Dec 2007 20:53:11 +0000 (GMT) In-Reply-To: <0d8701c83ce9$8fac0100$af040300$@us> References: <20071212150130.GA14079@nic.at> <0d8701c83ce9$8fac0100$af040300$@us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Date: Wed, 12 Dec 2007 20:53:10 +0000 To: Richard Shockey X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: enum@ietf.org, "'Creighton, Tom'" , 'Otmar Lendl' , 'Raja Gopal' , 'Hadriel Kaplan' , "'Robert H. Walter'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Richard-without-WG-chair-hat-on, folks, Forgive me, but in the immortal words of Mandy Rice Davies: "well he would [say that], wouldn't he"? I believe that a fair number of these units DO have LDAP interfaces - they will sure need something to deal with authentication of querying user. Certainly a number of IMS components do have (and use) LDAP. Whether that's wise I will leave to others, but they do. However, with number portability, whatever cards you're dealt, this could mean different answers for every single calling number, and each of those sets of answers could be large. Is the RFID registry not enough for people? all the best, Lawrence On 12 Dec 2007, at 18:05, Richard Shockey wrote: > No vendor at this stage of ENUM deployments is ever going to put > another > protocol stack in the softswitches or SMB's for this type of number > translation function. In order to deploy a working protocol to deal > with a > specific use case like this you deal with the cards your dealt and > in this > case again that is 3761. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 16:41:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2ZKo-0006nP-TS; Wed, 12 Dec 2007 16:41:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2ZKn-0006mt-AT for enum@ietf.org; Wed, 12 Dec 2007 16:41:41 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2ZKm-0004u1-T2 for enum@ietf.org; Wed, 12 Dec 2007 16:41:41 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Wed, 12 Dec 2007 16:41:40 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 12 Dec 2007 16:41:40 -0500 From: Hadriel Kaplan To: lconroy , Richard Shockey Date: Wed, 12 Dec 2007 16:39:27 -0500 Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Index: Acg9AQLlo+rI4YqqS8qTMbwCF4/eegABFjPA Message-ID: References: <20071212150130.GA14079@nic.at> <0d8701c83ce9$8fac0100$af040300$@us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "enum@ietf.org" , "'Robert H. Walter'" , "'Creighton, Tom'" , 'Otmar Lendl' , 'Raja Gopal' X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: lconroy [mailto:lconroy@insensate.co.uk] > Sent: Wednesday, December 12, 2007 3:53 PM > > I believe that a fair number of these units DO have LDAP interfaces - > they will sure need > something to deal with authentication of querying user. Certainly a > number of IMS components > do have (and use) LDAP. Whether that's wise I will leave to others, > but they do. Yes, I know that some devices have LDAP interfaces (including mine for that= matter). But no, not many IMS components do - more have DIAMETER and that= 's what they would use if not ENUM. Whether that's wise I will leave to ot= hers. :) But pretty much any device has ENUM, because all of them have DNS. Regardless, authentication of a client querying DNS doesn't happen. They g= et around it through other means, whether by having private or unadvertised= DNS server IP addresses, or limiting who the requesters can be by IP, or w= hatever. That's a problem they have to deal with for everyday ENUM use any= way. Most service providers don't want to let just any random client query= their ENUM DB's, even without this draft extension. -hadriel _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 16:58:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Zay-0005sW-PQ; Wed, 12 Dec 2007 16:58:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Zax-0005sP-Sn for enum@ietf.org; Wed, 12 Dec 2007 16:58:23 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Zax-0003kl-Ho for enum@ietf.org; Wed, 12 Dec 2007 16:58:23 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Wed, 12 Dec 2007 16:58:23 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 12 Dec 2007 16:58:23 -0500 From: Hadriel Kaplan To: lconroy , Peter Koch Date: Wed, 12 Dec 2007 16:56:04 -0500 Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Index: Acg8/7JV+ML2xsHGR+2fD57hbnYoHAAB8ypw Message-ID: References: <475F3745.1020107@e164.org> <00b201c83c60$c0822220$41866660$@us> <20071212164056.GG11923@denics7.denic.de> <5F671CD4-F447-487B-8C16-BA874EA9A763@insensate.co.uk> In-Reply-To: <5F671CD4-F447-487B-8C16-BA874EA9A763@insensate.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "enum@ietf.org" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hey Lawrence, Inline... > -----Original Message----- > From: lconroy [mailto:lconroy@insensate.co.uk] > Sent: Wednesday, December 12, 2007 3:43 PM > To: Peter Koch > Cc: enum@ietf.org > Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt > > Hi Peter, folks, > I agree with all of Peter's comments. > Also... > Forget ENUM. > First, there is no such thing as an ENUM server - only a DNS server > that acts authoritatively for domains associated (via ENUM) with E. > 164 telephone numbers. Ummm... you just defined the ENUM server: "a DNS server that acts authorita= tively for domains associated (via ENUM) with E.164 telephone numbers". Ar= e you saying such devices don't exist? I'm confused. > Second, the fact that a modified ENUM client happens to be the source > of these DNS queries is not significant to the DNS query itself, nor > is it to the kind of response it receives. I think what you mean by this is it could be generalized to any/all DNS req= uests - but I think we're all in vehement agreement it doesn't make sense f= or the general use of DNS. Ergo, I pointed it at ENUM (and private ENUM at= that). > However, it's a DNS issue, not an issue for a group that > specifies the ENUM protocol/algorithm, Enumservices and the > guidelines for development of Enumservices. Granted, it could be generalized, but I pointed it to the ENUM WG because i= t's trying to solve a problem found due to a specific use-case for DNS: nam= ely ENUM. I don't disagree it probably belongs better in DNSEXT/DNSOPTS. = The ENUM WG chair is waiting to hear back from the AD's if that's the case,= I believe. -hadriel _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 17:06:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ziz-0005y6-Kh; Wed, 12 Dec 2007 17:06:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ziy-0005xo-B2 for enum@ietf.org; Wed, 12 Dec 2007 17:06:40 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Zix-00049Q-2w for enum@ietf.org; Wed, 12 Dec 2007 17:06:40 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Wed, 12 Dec 2007 17:06:38 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Wed, 12 Dec 2007 17:06:38 -0500 From: Hadriel Kaplan To: "Dwight, Timothy M (Tim)" , "enum@ietf.org" Date: Wed, 12 Dec 2007 17:04:24 -0500 Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Index: Acg8z+QTaFUTx6rmSDGosvG1PPBqUQACsGvgAAMRP3AAAXcVQAAHa3qQ Message-ID: References: <20071212150130.GA14079@nic.at> <0d8701c83ce9$8fac0100$af040300$@us> <092B2658AAB56A4D80836399A4C4703101FE8E22@ASHEVS002.mcilink.com> In-Reply-To: <092B2658AAB56A4D80836399A4C4703101FE8E22@ASHEVS002.mcilink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Yes exactly - it lets you do this: +--------------+ | PSTN routing | | logic & DB | +--------------+ | | +------------+ INVITE +--------+ ENUM+EDNS query +--------+ | Call | --------> | SIP | --------------> | ENUM | | Processing | | app | | server | | Device | <-------- | server | <-------------- | | +------------+ 302 +--------+ ENUM response +--------+ OR, this: +--------------+ | PSTN routing | | logic & DB | +--------------+ | | +------------+ ENUM+EDNS +--------+ | Call | --------> | ENUM | | Processing | | server | | Device | <-------- | | +------------+ ENUM resp +--------+ -hadriel > -----Original Message----- > From: Dwight, Timothy M (Tim) [mailto:timothy.dwight@verizonbusiness.com] > Sent: Wednesday, December 12, 2007 2:12 PM > To: enum@ietf.org > Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt > > I agree with Richard as to the need. There are many cases in which the > response to the ENUM query needs to be different, depending on "where > the query came from". The latter phrase sometimes refers to the > caller's telephone number (e.g., in the case of selecting a PSTN gateway > to which to terminate the call, you need to determine whether calling > and called party are in the same rate center and if so, select an > ingress point to the appropriate class 5 exchange; otherwise select an > ingress point to the long distance network) and sometimes to the > "administrative entity" from which you received the call (carriers may > have business arrangements that they need to honor, e.g., a special set > of ingress points for business partners). > > Today there are products that can vary the ENUM query response based on > information not present in a standard DNS/ENUM query. Usually they > combine an application server that supports both PSTN routing and SIP > redirect, and an ENUM server. Sorta like this: > > +--------------+ > | PSTN routing | > | logic & DB | > +--------------+ > | > | (augmented?) > +------------+ INVITE +--------+ ENUM query +--------+ > | Call | --------> | SIP | --------------> | ENUM | > | Processing | | app | | server | > | Device | <-------- | server | <-------------- | | > +------------+ 302 +--------+ ENUM response +--------+ > > > I suppose there must be a proprietary interface between the two; which > Hadriel's proposal might standardize. That seems useful. > > I agree that SIP redirect overhead is much higher than that of a > DNS/ENUM query. As diagrammed above this wouldn't go away, because the > "dumb" call processing device still needs to talk to the "smart" app > server, and SIP redirect is typically the only way to do so. However > obviously there are "smart" call processing devices that implement, or > can implement, PSTN routing logic. In that case performance might > improve substantially. > > Whether this has to be done by enhancing the DNS/ENUM query as the draft > suggests, I'm not close enough to the implementation to say. > > Tim > > > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > Sent: Wednesday, December 12, 2007 12:05 PM > > To: 'Hadriel Kaplan'; 'Otmar Lendl' > > Cc: enum@ietf.org; 'Robert H. Walter'; 'Creighton, Tom'; 'Raja Gopal' > > Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt > > > > > > Chair hat off.. > > > > It is worth noting again that this is NOT intended for > > e164.arpa or probably > > any domain within the single root DNS. > > > > Adding a new protocol for this function would guarantee it > > would not be > > used...ever. > > > > The DNS protocols have been "fiddeled" with so long they are barely > > recognizable as it is. I don't see what the problem is. > > > > The issue of identifying where the query is coming from was > > an issue in my > > CNAM draft. Though it did not require identification and > > authentication it > > just as easily could have. The issue in using 3761 for CNAM > > queries was much > > more practical. > > > > No vendor at this stage of ENUM deployments is ever going to > > put another > > protocol stack in the softswitches or SMB's for this type of number > > translation function. In order to deploy a working protocol > > to deal with a > > specific use case like this you deal with the cards your > > dealt and in this > > case again that is 3761. > > > > Obviously people using SIP redirect for number translations > > don't have this > > problem but we all know what the issues with SIP redirect > > are, for one you > > get a 10X performance hit on query-response time. > > > > The first order issue to resolve is, does this proposal identify a > > practical problem in ENUM deployments that needs to get > > fixed, and IMHO the > > answer to that is unquestionably YES. > > > > > > > > > As this is not for e164.arpa, but private trees instead, do you > > > actually > > > > need the sub-tree delegation feature of DNS/ENUM? Or is ENUM just > > > used > > > > as a simple query protocol into a single database? > > > > > > Both. The sub-tree model is incredibly useful for scaling > > in bigger > > > networks or handling federations/registries, and it's also the case > > > that it sometimes is just a simple query protocol to a single DB. > > > > > > -hadriel > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 17:26:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2a2J-0001DR-3p; Wed, 12 Dec 2007 17:26:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2a2I-0001DL-NL for enum@ietf.org; Wed, 12 Dec 2007 17:26:38 -0500 Received: from qmta05.westchester.pa.mail.comcast.net ([76.96.62.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2a2I-0004re-GJ for enum@ietf.org; Wed, 12 Dec 2007 17:26:38 -0500 Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA05.westchester.pa.mail.comcast.net with comcast id Pqix1Y0051HzFnQ050uW00; Wed, 12 Dec 2007 22:26:38 +0000 Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA14.westchester.pa.mail.comcast.net with comcast id PySe1Y0010umElk3a00000; Wed, 12 Dec 2007 22:26:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=DCekgU9FisBdZRsSoxUA:9 a=llOPMWyWNoFMrHrnFawA:7 a=-vciZ_Fp27Y4qn1nZfwJ4uj3rPwA:4 a=uL3qOuNcMWcA:10 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id lBCMQbPC011213 for ; Wed, 12 Dec 2007 17:26:37 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id lBCMQbZq011209; Wed, 12 Dec 2007 17:26:37 -0500 Date: Wed, 12 Dec 2007 17:26:37 -0500 Message-Id: <200712122226.lBCMQbZq011209@dragon.ariadne.com> From: Dale.Worley@comcast.net To: enum@ietf.org In-reply-to: (HKaplan@acmepacket.com) Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org How about a technical question? I see in section 9: "The URI field is null-terminated, ASCII representation of the URI." Why is there a zero byte to mark the end of the URI field? Its length is already encoded in the OPTION-LENGTH field of the RDATA name/value pair. IIRC (and I may not), DNS generally uses length-data format for variable length data, not an end-marker format. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Dec 12 18:05:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2adf-0003qq-0j; Wed, 12 Dec 2007 18:05:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2adc-0003qf-Og; Wed, 12 Dec 2007 18:05:12 -0500 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2adc-0007tu-9d; Wed, 12 Dec 2007 18:05:12 -0500 Received: by bosco.isi.edu (Postfix, from userid 70) id 06DBBFF1FF; Wed, 12 Dec 2007 15:05:12 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071212230512.06DBBFF1FF@bosco.isi.edu> Date: Wed, 12 Dec 2007 15:05:12 -0800 (PST) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: enum@ietf.org, rfc-editor@rfc-editor.org Subject: [Enum] RFC 5076 on ENUM Validation Information Mapping for the Extensible Provisioning Protocol X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5076 Title: ENUM Validation Information Mapping for the Extensible Provisioning Protocol Author: B. Hoeneisen Status: Standards Track Date: December 2007 Mailbox: hoeneisen@switch.ch Pages: 24 Characters: 44679 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-validation-epp-06.txt URL: http://www.rfc-editor.org/rfc/rfc5076.txt This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names. [STANDARDS TRACK] This document is a product of the Telephone Number Mapping Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 13 10:27:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pyZ-0001ho-Up; Thu, 13 Dec 2007 10:27:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pyY-0001hh-FH for enum@ietf.org; Thu, 13 Dec 2007 10:27:50 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2pyX-0007hj-FH for enum@ietf.org; Thu, 13 Dec 2007 10:27:50 -0500 Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lBDFRM0P005910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2007 07:27:23 -0800 From: "Richard Shockey" To: References: <20071212150130.GA14079@nic.at> <0d8701c83ce9$8fac0100$af040300$@us> <092B2658AAB56A4D80836399A4C4703101FE8E22@ASHEVS002.mcilink.com> In-Reply-To: Date: Thu, 13 Dec 2007 10:27:23 -0500 Message-ID: <0a4701c83d9c$a9bb3530$fd319f90$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg8z+QTaFUTx6rmSDGosvG1PPBqUQACsGvgAAMRP3AAAXcVQAAHa3qQACRVgeA= Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: 'Cullen Jennings' , "'Peterson, Jon'" Subject: [Enum] RE I-D:draft-kaplan-enum-source-uri-00.txt - Next Steps. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Chair hat on ... There has clearly been a fast and furious discussion of this draft so what I'd like to get a sense of is two things. A. Is the problem statement contained in this Document well understood by the WG? Does it need more clarification? B. Is this a problem that needs to be worked on? I'm assuming that the authors will be incorporating some of the recent comments into a new version. Clearly the chairs are going to have to seek some guidance from the AD's on how to address this document and where it properly belongs. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Wednesday, December 12, 2007 5:04 PM > To: Dwight, Timothy M (Tim); enum@ietf.org > Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt > > Yes exactly - it lets you do this: > > +--------------+ > | PSTN routing | > | logic & DB | > +--------------+ > | > | > +------------+ INVITE +--------+ ENUM+EDNS query +--------+ > | Call | --------> | SIP | --------------> | ENUM | > | Processing | | app | | server | > | Device | <-------- | server | <-------------- | | > +------------+ 302 +--------+ ENUM response +--------+ > > > OR, this: > > +--------------+ > | PSTN routing | > | logic & DB | > +--------------+ > | > | > +------------+ ENUM+EDNS +--------+ > | Call | --------> | ENUM | > | Processing | | server | > | Device | <-------- | | > +------------+ ENUM resp +--------+ > > -hadriel > > > > -----Original Message----- > > From: Dwight, Timothy M (Tim) > [mailto:timothy.dwight@verizonbusiness.com] > > Sent: Wednesday, December 12, 2007 2:12 PM > > To: enum@ietf.org > > Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt > > > > I agree with Richard as to the need. There are many cases in which > the > > response to the ENUM query needs to be different, depending on > "where > > the query came from". The latter phrase sometimes refers to the > > caller's telephone number (e.g., in the case of selecting a PSTN > gateway > > to which to terminate the call, you need to determine whether > calling > > and called party are in the same rate center and if so, select an > > ingress point to the appropriate class 5 exchange; otherwise select > an > > ingress point to the long distance network) and sometimes to the > > "administrative entity" from which you received the call (carriers > may > > have business arrangements that they need to honor, e.g., a special > set > > of ingress points for business partners). > > > > Today there are products that can vary the ENUM query response based > on > > information not present in a standard DNS/ENUM query. Usually they > > combine an application server that supports both PSTN routing and > SIP > > redirect, and an ENUM server. Sorta like this: > > > > +--------------+ > > | PSTN routing | > > | logic & DB | > > +--------------+ > > | > > | (augmented?) > > +------------+ INVITE +--------+ ENUM query +--------+ > > | Call | --------> | SIP | --------------> | ENUM | > > | Processing | | app | | server | > > | Device | <-------- | server | <-------------- | | > > +------------+ 302 +--------+ ENUM response +--------+ > > > > > > I suppose there must be a proprietary interface between the two; > which > > Hadriel's proposal might standardize. That seems useful. > > > > I agree that SIP redirect overhead is much higher than that of a > > DNS/ENUM query. As diagrammed above this wouldn't go away, because > the > > "dumb" call processing device still needs to talk to the "smart" app > > server, and SIP redirect is typically the only way to do so. > However > > obviously there are "smart" call processing devices that implement, > or > > can implement, PSTN routing logic. In that case performance might > > improve substantially. > > > > Whether this has to be done by enhancing the DNS/ENUM query as the > draft > > suggests, I'm not close enough to the implementation to say. > > > > Tim > > > > > > > -----Original Message----- > > > From: Richard Shockey [mailto:richard@shockey.us] > > > Sent: Wednesday, December 12, 2007 12:05 PM > > > To: 'Hadriel Kaplan'; 'Otmar Lendl' > > > Cc: enum@ietf.org; 'Robert H. Walter'; 'Creighton, Tom'; 'Raja > Gopal' > > > Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt > > > > > > > > > Chair hat off.. > > > > > > It is worth noting again that this is NOT intended for > > > e164.arpa or probably > > > any domain within the single root DNS. > > > > > > Adding a new protocol for this function would guarantee it > > > would not be > > > used...ever. > > > > > > The DNS protocols have been "fiddeled" with so long they are > barely > > > recognizable as it is. I don't see what the problem is. > > > > > > The issue of identifying where the query is coming from was > > > an issue in my > > > CNAM draft. Though it did not require identification and > > > authentication it > > > just as easily could have. The issue in using 3761 for CNAM > > > queries was much > > > more practical. > > > > > > No vendor at this stage of ENUM deployments is ever going to > > > put another > > > protocol stack in the softswitches or SMB's for this type of > number > > > translation function. In order to deploy a working protocol > > > to deal with a > > > specific use case like this you deal with the cards your > > > dealt and in this > > > case again that is 3761. > > > > > > Obviously people using SIP redirect for number translations > > > don't have this > > > problem but we all know what the issues with SIP redirect > > > are, for one you > > > get a 10X performance hit on query-response time. > > > > > > The first order issue to resolve is, does this proposal identify > a > > > practical problem in ENUM deployments that needs to get > > > fixed, and IMHO the > > > answer to that is unquestionably YES. > > > > > > > > > > > > As this is not for e164.arpa, but private trees instead, do > you > > > > actually > > > > > need the sub-tree delegation feature of DNS/ENUM? Or is ENUM > just > > > > used > > > > > as a simple query protocol into a single database? > > > > > > > > Both. The sub-tree model is incredibly useful for scaling > > > in bigger > > > > networks or handling federations/registries, and it's also the > case > > > > that it sometimes is just a simple query protocol to a single > DB. > > > > > > > > -hadriel > > > > > > > > _______________________________________________ > > > > enum mailing list > > > > enum@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > > > _______________________________________________ > > > enum mailing list > > > enum@ietf.org > > > https://www1.ietf.org/mailman/listinfo/enum > > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 13 10:29:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pzl-0002By-LY; Thu, 13 Dec 2007 10:29:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2pzk-0002Bm-6Z for enum@ietf.org; Thu, 13 Dec 2007 10:29:04 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2pzj-0007jZ-NF for enum@ietf.org; Thu, 13 Dec 2007 10:29:04 -0500 Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lBDFSbdN006267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 13 Dec 2007 07:28:38 -0800 From: "Richard Shockey" To: Date: Thu, 13 Dec 2007 10:28:38 -0500 Message-ID: <0a4801c83d9c$d64afbd0$82e0f370$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg9nNVP+8IEzRDTQquk908itvzn4w== Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Enum] Status of Softswitch document. X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org There was some discussion in Vancouver on whether this document is essentially finished. I'd like to ask folks to reread the document once again and if possible comment on whether it is ready for WGLC. Title : ENUM-based Softswitch Requirement Author(s) : J. Lim, et al. Filename : draft-ietf-enum-softswitch-req-01.txt Pages : 17 Date : 2007-10-24 This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean VoIP carriers, gained during the ENUM pre- commercial trial hosted by National Internet Development Agency of Korea (NIDA) in 2006. These experiences show that an interim solution can maintain the stability of on-going commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-softswitch-req-01.txt Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 13 10:32:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2q2v-0004Aq-DP; Thu, 13 Dec 2007 10:32:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2q2t-0004Aj-D8 for enum@ietf.org; Thu, 13 Dec 2007 10:32:19 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2q2t-0007o7-33 for enum@ietf.org; Thu, 13 Dec 2007 10:32:19 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Thu, 13 Dec 2007 10:32:16 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 13 Dec 2007 10:32:16 -0500 From: Hadriel Kaplan To: "Dale.Worley@comcast.net" , "enum@ietf.org" Date: Thu, 13 Dec 2007 10:29:27 -0500 Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Index: Acg9DhZsZe9Zo9aoRHqvMCmBVfDpEAACYYpQ Message-ID: References: <200712122226.lBCMQbZq011209@dragon.ariadne.com> In-Reply-To: <200712122226.lBCMQbZq011209@dragon.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hmm. Yeah, that was from an earlier (not-published) version of the draft wh= ich talked about how one could possibly extend this thing in the future wit= hout breaking backwards compatibility, and used that zero byte as a backwar= ds compatible delimiter. But I forgot to fix that back when we removed tha= t (ugly) idea. We'll remove that going forward. Thanks! -hadriel > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Wednesday, December 12, 2007 5:27 PM > To: enum@ietf.org > Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt > > How about a technical question? > > I see in section 9: "The URI field is null-terminated, ASCII > representation of the URI." Why is there a zero byte to mark the end > of the URI field? Its length is already encoded in the OPTION-LENGTH > field of the RDATA name/value pair. IIRC (and I may not), DNS > generally uses length-data format for variable length data, not an > end-marker format. > > Dale > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Dec 13 15:29:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2ug2-000488-TE; Thu, 13 Dec 2007 15:29:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2ug1-00047o-9A for enum@ietf.org; Thu, 13 Dec 2007 15:29:01 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2ug0-0000IN-2x for enum@ietf.org; Thu, 13 Dec 2007 15:29:01 -0500 Received: from [10.31.32.123] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id lBDKSjDD061439; Thu, 13 Dec 2007 15:28:46 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 13 Dec 2007 15:28:36 -0500 To: Hadriel Kaplan From: Edward Lewis Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt X-Scanned-By: MIMEDefang 2.63 on 66.92.146.160 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0488770395==" Errors-To: enum-bounces@ietf.org --===============0488770395== Content-Type: multipart/alternative; boundary="============_-1014544765==_ma============" --============_-1014544765==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 17:43 -0500 12/11/07, Hadriel Kaplan wrote: http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt Having read the draft and the thread that ensued I have two concerns. One is using EDNS (Extended DNS) for what's described as an application-specific need. The other is the already mentioned security of the data question. I like this idea though. The idea that it promotes is not alien to the operations of DNS although it is alien to the IETF architected version of DNS. "Views" mentioned elsewhere is an implementation-specific feature of ISC's BIND but is one that is widely understood. The notion of selecting an answer based on IP address of the querier or a signature has been floated and put into use. Akamaization is a verb that has been used at times. What might be more appropriate for an identifying mark in the EDNS field is a domain name[1]. DNS, when it does, can differentiate queriers by either an IP address, the source address, or the TSIG key name, which is syntactically (but not semantically) a domain name. I think it is important that the identifying mark not be used as a domain name, I think it would be unwise to have recursive servers try to initiate lookups based on the identifying mark. I am worried about a performance (and DoS?) hit. A generic-to-DNS querier ID would be more acceptable in the DNS extended field than something specific to an application. As far as securing the mark, I don't see any way to ever do that. TSIG doesn't cover the contents of the OPT record (it can't, TSIG is in there too) and it was the last hope. A second OPT RR in the additional is not going to happen anytime soon. But I bet that environments that will rely on the contents of this field will have other security mechanisms in place. [1] When I had someone look over the message, he asked why I suggested this and the explanation is worthy of being included here. I got the idea of using domain name syntax from the engineering behind TSIG [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt]. The (secret, symmetric) key shared among two communicating parties - a client and server - is not present in the DNS data space yet is identified by a string that conforms to a domain name. Until TSIG keys, there were no names assigned to clients in DNS although source IP addresses were used in ACLs. Today, BIND's views can match on IP ACLs and/or TSIG key names. Let me stress that I mention BIND as an example of a DNS implementation, not as a protocol reference. The significance of the name looking like a domain name but not being one (in the semantic sense) is meant to prevent an authoritative server from having to launch queries in support of answering a question. Authoritative servers should never learn from the network as that opens a vulnerability in terms of learning poisoned data as well as participation in traffic abuses (like DDoS). We don't want authoritative servers launching traffic for their sake and our sake. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. --============_-1014544765==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
At 17:43 -0500 12/11/07, Hadriel Kaplan wrote:
http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt

Having read the draft and the thread that ensued I have two concerns.

One is using EDNS (Extended DNS) for what's described as an application-specific need.  The other is the already mentioned security of the data question.

I like this idea though.  The idea that it promotes is not alien to the operations of DNS although it is alien to the IETF architected version of DNS.  "Views" mentioned elsewhere is an implementation-specific feature of ISC's BIND but is one that is widely understood.  The notion of selecting an answer based on IP address of the querier or a signature has been floated and put into use.  Akamaization is a verb that has been used at times.

What might be more appropriate for an identifying mark in the EDNS field is a domain name[1].  DNS, when it does, can differentiate queriers by either an IP address, the source address, or the TSIG key name, which is syntactically (but not semantically) a domain name.  I think it is important that the identifying mark not be used as a domain name, I think it would be unwise to have recursive servers try to initiate lookups based on the identifying mark.  I am worried about a performance (and DoS?) hit.

A generic-to-DNS querier ID would be more acceptable in the DNS extended field than something specific to an application.

As far as securing the mark, I don't see any way to ever do that.  TSIG doesn't cover the contents of the OPT record (it can't, TSIG is in there too) and it was the last hope.  A second OPT RR in the additional is not going to happen anytime soon.  But I bet that environments that will rely on the contents of this field will have other security mechanisms in place.

[1] When I had someone look over the message, he asked why I suggested this and the explanation is worthy of being included here.

I got the idea of using domain name syntax from the engineering behind TSIG [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt].  The (secret, symmetric) key shared among two communicating parties - a client and server - is not present in the DNS data space yet is identified by a string that conforms to a domain name.

Until TSIG keys, there were no names assigned to clients in DNS although source  IP addresses were used in ACLs.  Today, BIND's views can match on IP ACLs and/or TSIG key names.  Let me stress that I mention BIND as an example of a DNS implementation, not as a protocol reference.

The significance of the name looking like a domain name but not being one (in the semantic sense) is meant to prevent an authoritative server from having to launch queries in support of answering a question.  Authoritative servers should never learn from the network as that opens a vulnerability in terms of learning poisoned data as well as participation in traffic abuses (like DDoS).  We don't want authoritative servers launching traffic for their sake and our sake.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.
--============_-1014544765==_ma============-- --===============0488770395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0488770395==-- From enum-bounces@ietf.org Thu Dec 13 18:43:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2xiN-0007e1-MC; Thu, 13 Dec 2007 18:43:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2xiM-0007VN-Rs for enum@ietf.org; Thu, 13 Dec 2007 18:43:38 -0500 Received: from mail203.messagelabs.com ([216.82.254.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2xiL-0005m9-KS for enum@ietf.org; Thu, 13 Dec 2007 18:43:38 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-12.tower-203.messagelabs.com!1197589415!785427!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 14210 invoked from network); 13 Dec 2007 23:43:36 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-12.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 13 Dec 2007 23:43:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id lBDNhZPx025251 for ; Thu, 13 Dec 2007 18:43:35 -0500 Received: from ACCLUST02EVS1.ugd.att.com (acst03.ugd.att.com [135.37.16.8]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id lBDNhPD2025196 for ; Thu, 13 Dec 2007 18:43:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Date: Thu, 13 Dec 2007 18:43:24 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A11507C60@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt thread-index: Acg9xwBONq5PqbxCQxS7YF6uqis0UQAGi3WQ References: From: "PFAUTZ, PENN L, ATTCORP" To: "Edward Lewis" , "Hadriel Kaplan" X-Spam-Score: -4.0 (----) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: enum@ietf.org, "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1501215167==" Errors-To: enum-bounces@ietf.org This is a multi-part message in MIME format. --===============1501215167== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83DE1.F454F435" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83DE1.F454F435 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is an interesting concept. I tend to agree that a domain name might be a better key but for different reasons. In the kind of usage I'm thinking of for infrastructure applications a specific URI (equivalent to a calling number) is too molecular. I wouldn't want to code to respond on what is essentially a per-calling number basis. =20 Penn Pfautz AT&T National Access Management +1-732-420-4962 =20 ________________________________ From: Edward Lewis [mailto:Ed.Lewis@neustar.biz]=20 Sent: Thursday, December 13, 2007 3:29 PM To: Hadriel Kaplan Cc: enum@ietf.org; Robert H. Walter; Creighton, Tom; Raja Gopal Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt At 17:43 -0500 12/11/07, Hadriel Kaplan wrote: http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt Having read the draft and the thread that ensued I have two concerns. One is using EDNS (Extended DNS) for what's described as an application-specific need. The other is the already mentioned security of the data question. I like this idea though. The idea that it promotes is not alien to the operations of DNS although it is alien to the IETF architected version of DNS. "Views" mentioned elsewhere is an implementation-specific feature of ISC's BIND but is one that is widely understood. The notion of selecting an answer based on IP address of the querier or a signature has been floated and put into use. Akamaization is a verb that has been used at times. What might be more appropriate for an identifying mark in the EDNS field is a domain name[1]. DNS, when it does, can differentiate queriers by either an IP address, the source address, or the TSIG key name, which is syntactically (but not semantically) a domain name. I think it is important that the identifying mark not be used as a domain name, I think it would be unwise to have recursive servers try to initiate lookups based on the identifying mark. I am worried about a performance (and DoS?) hit. A generic-to-DNS querier ID would be more acceptable in the DNS extended field than something specific to an application. As far as securing the mark, I don't see any way to ever do that. TSIG doesn't cover the contents of the OPT record (it can't, TSIG is in there too) and it was the last hope. A second OPT RR in the additional is not going to happen anytime soon. But I bet that environments that will rely on the contents of this field will have other security mechanisms in place. [1] When I had someone look over the message, he asked why I suggested this and the explanation is worthy of being included here. I got the idea of using domain name syntax from the engineering behind TSIG [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt]. The (secret, symmetric) key shared among two communicating parties - a client and server - is not present in the DNS data space yet is identified by a string that conforms to a domain name. Until TSIG keys, there were no names assigned to clients in DNS although source IP addresses were used in ACLs. Today, BIND's views can match on IP ACLs and/or TSIG key names. Let me stress that I mention BIND as an example of a DNS implementation, not as a protocol reference. The significance of the name looking like a domain name but not being one (in the semantic sense) is meant to prevent an authoritative server from having to launch queries in support of answering a question. Authoritative servers should never learn from the network as that opens a vulnerability in terms of learning poisoned data as well as participation in traffic abuses (like DDoS). We don't want authoritative servers launching traffic for their sake and our sake. --=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D -=3D- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. ------_=_NextPart_001_01C83DE1.F454F435 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Enum] New = I-D:draft-kaplan-enum-source-uri-00.txt
This is an interesting concept. I tend to agree = that a=20 domain name  might be a better  key but for different reasons. = In the=20 kind of usage I'm thinking of for infrastructure applications a specific = URI=20 (equivalent to a calling number) is too molecular. I wouldn't want to = code to=20 respond on what is essentially a per-calling number = basis.
 
Penn Pfautz
AT&T National Access=20 Management
+1-732-420-4962
 

From: Edward Lewis = [mailto:Ed.Lewis@neustar.biz]=20
Sent: Thursday, December 13, 2007 3:29 PM
To: = Hadriel=20 Kaplan
Cc: enum@ietf.org; Robert H. Walter; Creighton, Tom; = Raja=20 Gopal
Subject: Re: [Enum] New=20 I-D:draft-kaplan-enum-source-uri-00.txt

At 17:43 -0500 12/11/07, Hadriel Kaplan wrote:
http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.= txt

Having read the draft and the thread that ensued I have two = concerns.

One is using EDNS (Extended DNS) for what's described as an=20 application-specific need.  The other is the already mentioned = security of=20 the data question.

I like this idea though.  The idea that it promotes is not = alien to=20 the operations of DNS although it is alien to the IETF architected = version of=20 DNS.  "Views" mentioned elsewhere is an implementation-specific = feature of=20 ISC's BIND but is one that is widely understood.  The notion of = selecting=20 an answer based on IP address of the querier or a signature has been = floated and=20 put into use.  Akamaization is a verb that has been used at = times.

What might be more appropriate for an identifying mark in the EDNS = field is=20 a domain name[1].  DNS, when it does, can differentiate queriers by = either=20 an IP address, the source address, or the TSIG key name, which is = syntactically=20 (but not semantically) a domain name.  I think it is important that = the=20 identifying mark not be used as a domain name, I think it would be = unwise to=20 have recursive servers try to initiate lookups based on the identifying=20 mark.  I am worried about a performance (and DoS?) hit.

A generic-to-DNS querier ID would be more acceptable in the DNS = extended=20 field than something specific to an application.

As far as securing the mark, I don't see any way to ever do = that. =20 TSIG doesn't cover the contents of the OPT record (it can't, TSIG is in = there=20 too) and it was the last hope.  A second OPT RR in the additional = is not=20 going to happen anytime soon.  But I bet that environments that = will rely=20 on the contents of this field will have other security mechanisms in=20 place.

[1] When I had someone look over the message, he asked why I = suggested this=20 and the explanation is worthy of being included here.

I got the idea of using domain name syntax from the engineering = behind TSIG=20 [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt].  The (secret, = symmetric)=20 key shared among two communicating parties - a client and server - is = not=20 present in the DNS data space yet is identified by a string that = conforms to a=20 domain name.

Until TSIG keys, there were no names assigned to clients in DNS = although=20 source  IP addresses were used in ACLs.  Today, BIND's views = can match=20 on IP ACLs and/or TSIG key names.  Let me stress that I mention = BIND as an=20 example of a DNS implementation, not as a protocol reference.

The significance of the name looking like a domain name but not = being one=20 (in the semantic sense) is meant to prevent an authoritative server from = having=20 to launch queries in support of answering a question.  = Authoritative=20 servers should never learn from the network as that opens a = vulnerability in=20 terms of learning poisoned data as well as participation in traffic = abuses (like=20 DDoS).  We don't want authoritative servers launching traffic for = their=20 sake and our sake.
--=20
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
Edward=20 Lewis                               &n= bsp;         &n= bsp;     =20 +1-571-434-5468
NeuStar

Think glocally.  Act confused.
------_=_NextPart_001_01C83DE1.F454F435-- --===============1501215167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1501215167==-- From enum-bounces@ietf.org Fri Dec 14 10:54:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3CrT-0000jR-3r; Fri, 14 Dec 2007 10:54:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3CrQ-0000j9-Mm for enum@ietf.org; Fri, 14 Dec 2007 10:54:00 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3CrP-00017H-F0 for enum@ietf.org; Fri, 14 Dec 2007 10:54:00 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Fri, 14 Dec 2007 10:53:58 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 14 Dec 2007 10:53:58 -0500 From: Hadriel Kaplan To: Edward Lewis Date: Fri, 14 Dec 2007 10:49:14 -0500 Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Index: Acg9xsn8vgKj3HmNTRKYT5jI3Yj4nAAoNqew Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7c7a0f28a102b9cb6317697abf1cf76 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0199414249==" Errors-To: enum-bounces@ietf.org --===============0199414249== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC30273AB7400mailacmepacke_" --_000_E6C2E8958BA59A4FB960963D475F7AC30273AB7400mailacmepacke_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Interesting idea. I assume you realize such a format could be used for cal= ling number source info as well, simply by formatting the calling number in= the ENUM notation: 2.1.2.1.5.5.5.1.8.7.1.e164.mydomain Or some such. But the idea of the source-URI info was not to limit it to domains only. T= he ENUM server could well look at only the domain portion of the URI, or it= could look at the username, or the scheme, or a uri-parameter, or whatever= . The client is merely giving it extra information (of its choosing), whic= h the server can ignore or not. Clearly that makes it a very private (clos= ed environment) concept, for it to really work. -hadriel ________________________________ From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Thursday, December 13, 2007 3:29 PM To: Hadriel Kaplan Cc: enum@ietf.org; Robert H. Walter; Creighton,Tom; Raja Gopal Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt At 17:43 -0500 12/11/07, Hadriel Kaplan wrote: http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt Having read the draft and the thread that ensued I have two concerns. One is using EDNS (Extended DNS) for what's described as an application-spe= cific need. The other is the already mentioned security of the data questi= on. I like this idea though. The idea that it promotes is not alien to the ope= rations of DNS although it is alien to the IETF architected version of DNS.= "Views" mentioned elsewhere is an implementation-specific feature of ISC'= s BIND but is one that is widely understood. The notion of selecting an an= swer based on IP address of the querier or a signature has been floated and= put into use. Akamaization is a verb that has been used at times. What might be more appropriate for an identifying mark in the EDNS field is= a domain name[1]. DNS, when it does, can differentiate queriers by either= an IP address, the source address, or the TSIG key name, which is syntacti= cally (but not semantically) a domain name. I think it is important that t= he identifying mark not be used as a domain name, I think it would be unwis= e to have recursive servers try to initiate lookups based on the identifyin= g mark. I am worried about a performance (and DoS?) hit. A generic-to-DNS querier ID would be more acceptable in the DNS extended fi= eld than something specific to an application. As far as securing the mark, I don't see any way to ever do that. TSIG doe= sn't cover the contents of the OPT record (it can't, TSIG is in there too) = and it was the last hope. A second OPT RR in the additional is not going t= o happen anytime soon. But I bet that environments that will rely on the c= ontents of this field will have other security mechanisms in place. [1] When I had someone look over the message, he asked why I suggested this= and the explanation is worthy of being included here. I got the idea of using domain name syntax from the engineering behind TSIG= [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt]. The (secret, symmetric) = key shared among two communicating parties - a client and server - is not p= resent in the DNS data space yet is identified by a string that conforms to= a domain name. Until TSIG keys, there were no names assigned to clients in DNS although so= urce IP addresses were used in ACLs. Today, BIND's views can match on IP = ACLs and/or TSIG key names. Let me stress that I mention BIND as an exampl= e of a DNS implementation, not as a protocol reference. The significance of the name looking like a domain name but not being one (= in the semantic sense) is meant to prevent an authoritative server from hav= ing to launch queries in support of answering a question. Authoritative se= rvers should never learn from the network as that opens a vulnerability in = terms of learning poisoned data as well as participation in traffic abuses = (like DDoS). We don't want authoritative servers launching traffic for the= ir sake and our sake. -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= - Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. --_000_E6C2E8958BA59A4FB960963D475F7AC30273AB7400mailacmepacke_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

Interesting idea.  I assume you realize such a format could be used for calling number source info as well, simply by formatting the calling number in the ENUM notation:

2.1.2.1.5.5.5.1.8.7.1.e164.mydomain

Or some such.=

 

But the idea of the source-URI info wa= s not to limit it to domains only.  The ENUM server could well look at o= nly the domain portion of the URI, or it could look at the username, or the sch= eme, or a uri-parameter, or whatever.  The client is merely giving it extra information (of its choosing), which the server can ignore or not.  Cl= early that makes it a very private (closed environment) concept, for it to really work.  

 

-hadriel

 

 

From: Edward L= ewis [mailto:Ed.Lewis@neustar.biz]
Sent: Thursday, December 13,= 2007 3:29 PM
To: Hadriel Kaplan
Cc: enum@ietf.org; Robert H. Walter; Creighton,Tom; Raja Gopal
Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

 

At 17:43 -0500 12/11/07, Hadriel Kaplan wrote:

http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00= .txt

 

Having read the draft and the thread that ensued I have two concern= s.

 

One is using EDNS (Extended DNS) for what's described as an application-specific need.  The other is the already mentioned securit= y of the data question.

 

I like this idea though.  The idea that it promotes is not ali= en to the operations of DNS although it is alien to the IETF architected versi= on of DNS.  "Views" mentioned elsewhere is an implementation-sp= ecific feature of ISC's BIND but is one that is widely understood.  The notio= n of selecting an answer based on IP address of the querier or a signature has b= een floated and put into use.  Akamaization is a verb that has been used a= t times.

 

What might be more appropriate for an identifying mark in the EDNS field is a domain name[1].  DNS, when it does, can differentiate queri= ers by either an IP address, the source address, or the TSIG key name, which is syntactically (but not semantically) a domain name.  I think it is important that the identifying mark not be used as a domain name, I think i= t would be unwise to have recursive servers try to initiate lookups based on = the identifying mark.  I am worried about a performance (and DoS?) hit.

 

A generic-to-DNS querier ID would be more acceptable in the DNS extended field than something specific to an application.=

 

As far as securing the mark, I don't see any way to ever do that.&n= bsp; TSIG doesn't cover the contents of the OPT record (it can't, TSIG is in the= re too) and it was the last hope.  A second OPT RR in the additional is n= ot going to happen anytime soon.  But I bet that environments that will r= ely on the contents of this field will have other security mechanisms in place.=

 

[1] When I had someone look over the message, he asked why I sugges= ted this and the explanation is worthy of being included here.

 

I got the idea of using domain name syntax from the engineering beh= ind TSIG [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt].  The (secret, sy= mmetric) key shared among two communicating parties - a client and server - is not present in the DNS data space yet is identified by a string that conforms t= o a domain name.

 

Until TSIG keys, there were no names assigned to clients in DNS although source  IP addresses were used in ACLs.  Today, BIND's v= iews can match on IP ACLs and/or TSIG key names.  Let me stress that I ment= ion BIND as an example of a DNS implementation, not as a protocol reference.

 

The significance of the name looking like a domain name but not bei= ng one (in the semantic sense) is meant to prevent an authoritative server fro= m having to launch queries in support of answering a question.  Authoritative servers should never learn from the network as that opens a vulnerability in terms of learning poisoned data as well as participation i= n traffic abuses (like DDoS).  We don't want authoritative servers launc= hing traffic for their sake and our sake.

<=
x-sigsep>--

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-
Edward Lewis          &nb= sp;            =             &nb= sp;            +1-571-434-5468
NeuStar

 

Think glocally.  Act confused.

--_000_E6C2E8958BA59A4FB960963D475F7AC30273AB7400mailacmepacke_-- --===============0199414249== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0199414249==-- From enum-bounces@ietf.org Fri Dec 14 10:59:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Cwz-0001EC-7D; Fri, 14 Dec 2007 10:59:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Cwx-0001E1-LM for enum@ietf.org; Fri, 14 Dec 2007 10:59:43 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Cww-0000tI-55 for enum@ietf.org; Fri, 14 Dec 2007 10:59:43 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Fri, 14 Dec 2007 10:59:41 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 14 Dec 2007 10:59:41 -0500 From: Hadriel Kaplan To: "PFAUTZ, PENN L, ATTCORP" , Edward Lewis Date: Fri, 14 Dec 2007 10:54:40 -0500 Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Index: Acg9xwBONq5PqbxCQxS7YF6uqis0UQAGi3WQACHs+2A= Message-ID: References: <34DA635B184A644DA4588E260EC0A25A11507C60@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A11507C60@ACCLUST02EVS1.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 559439f19b20fd64c5cd872aef84c6f3 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1589399385==" Errors-To: enum-bounces@ietf.org --===============1589399385== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC30273AB7430mailacmepacke_" --_000_E6C2E8958BA59A4FB960963D475F7AC30273AB7430mailacmepacke_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a URI, it typically has a domain in it and you could always choose to lo= ok at that part only on the ENUM server, or look at it and only a portion o= f the username, or whatever you want. So your server-side coding would onl= y look at what you/it wants to look at. -hadriel ________________________________ From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] Sent: Thursday, December 13, 2007 6:43 PM To: Edward Lewis; Hadriel Kaplan Cc: enum@ietf.org; Robert H. Walter; Creighton, Tom; Raja Gopal Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt This is an interesting concept. I tend to agree that a domain name might b= e a better key but for different reasons. In the kind of usage I'm thinkin= g of for infrastructure applications a specific URI (equivalent to a callin= g number) is too molecular. I wouldn't want to code to respond on what is e= ssentially a per-calling number basis. Penn Pfautz AT&T National Access Management +1-732-420-4962 ________________________________ From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Thursday, December 13, 2007 3:29 PM To: Hadriel Kaplan Cc: enum@ietf.org; Robert H. Walter; Creighton, Tom; Raja Gopal Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt At 17:43 -0500 12/11/07, Hadriel Kaplan wrote: http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt Having read the draft and the thread that ensued I have two concerns. One is using EDNS (Extended DNS) for what's described as an application-spe= cific need. The other is the already mentioned security of the data questi= on. I like this idea though. The idea that it promotes is not alien to the ope= rations of DNS although it is alien to the IETF architected version of DNS.= "Views" mentioned elsewhere is an implementation-specific feature of ISC'= s BIND but is one that is widely understood. The notion of selecting an an= swer based on IP address of the querier or a signature has been floated and= put into use. Akamaization is a verb that has been used at times. What might be more appropriate for an identifying mark in the EDNS field is= a domain name[1]. DNS, when it does, can differentiate queriers by either= an IP address, the source address, or the TSIG key name, which is syntacti= cally (but not semantically) a domain name. I think it is important that t= he identifying mark not be used as a domain name, I think it would be unwis= e to have recursive servers try to initiate lookups based on the identifyin= g mark. I am worried about a performance (and DoS?) hit. A generic-to-DNS querier ID would be more acceptable in the DNS extended fi= eld than something specific to an application. As far as securing the mark, I don't see any way to ever do that. TSIG doe= sn't cover the contents of the OPT record (it can't, TSIG is in there too) = and it was the last hope. A second OPT RR in the additional is not going t= o happen anytime soon. But I bet that environments that will rely on the c= ontents of this field will have other security mechanisms in place. [1] When I had someone look over the message, he asked why I suggested this= and the explanation is worthy of being included here. I got the idea of using domain name syntax from the engineering behind TSIG= [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt]. The (secret, symmetric) = key shared among two communicating parties - a client and server - is not p= resent in the DNS data space yet is identified by a string that conforms to= a domain name. Until TSIG keys, there were no names assigned to clients in DNS although so= urce IP addresses were used in ACLs. Today, BIND's views can match on IP = ACLs and/or TSIG key names. Let me stress that I mention BIND as an exampl= e of a DNS implementation, not as a protocol reference. The significance of the name looking like a domain name but not being one (= in the semantic sense) is meant to prevent an authoritative server from hav= ing to launch queries in support of answering a question. Authoritative se= rvers should never learn from the network as that opens a vulnerability in = terms of learning poisoned data as well as participation in traffic abuses = (like DDoS). We don't want authoritative servers launching traffic for the= ir sake and our sake. -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= - Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. --_000_E6C2E8958BA59A4FB960963D475F7AC30273AB7430mailacmepacke_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

As a URI, it typically has a domain in= it and you could always choose to look at that part only on the ENUM server, o= r look at it and only a portion of the username, or whatever you want.  = So your server-side coding would only look at what you/it wants to look at.

-hadriel

 

From: PFAUTZ, = PENN L, ATTCORP [mailto:ppfautz@att.com]
Sent: Thursday, December 13,= 2007 6:43 PM
To: Edward Lewis; Hadriel Ka= plan
Cc: enum@ietf.org; Robert H. Walter; Creighton, Tom; Raja Gopal
Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

 

This is an interesting concept. I tend= to agree that a domain name  might be a better  key but for differen= t reasons. In the kind of usage I'm thinking of for infrastructure applicatio= ns a specific URI (equivalent to a calling number) is too molecular. I wouldn't = want to code to respond on what is essentially a per-calling number basis.

 

Penn Pfautz

AT&T National Access Management

+1-732-420-4962

 

 

From:= = Edward Lewis [mailto:Ed.Lewis@neustar.biz]
Sent: Thursday, December 13,= 2007 3:29 PM
To: Hadriel Kaplan
Cc: enum@ietf.org; Robert H. Walter; Creighton, Tom; Raja Gopal
Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

At 17:43 -0500 12/11/07, Hadriel Kaplan wrote:

http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00= .txt

 

Having read the draft and the thread that ensued I have two concern= s.

 

One is using EDNS (Extended DNS) for what's described as an application-specific need.  The other is the already mentioned securit= y of the data question.

 

I like this idea though.  The idea that it promotes is not ali= en to the operations of DNS although it is alien to the IETF architected versi= on of DNS.  "Views" mentioned elsewhere is an implementation-specific feature of ISC's BIND but is one that is widely und= erstood.  The notion of selecting an answer based on IP address of the querier or a signature has been floated and put into use.  Akamaization is a verb t= hat has been used at times.

 

What might be more appropriate for an identifying mark in the EDNS field is a domain name[1].  DNS, when it does, can differentiate queri= ers by either an IP address, the source address, or the TSIG key name, which is syntactically (but not semantically) a domain name.  I think it is important that the identifying mark not be used as a domain name, I think i= t would be unwise to have recursive servers try to initiate lookups based on = the identifying mark.  I am worried about a performance (and DoS?) hit.

 

A generic-to-DNS querier ID would be more acceptable in the DNS extended field than something specific to an application.=

 

As far as securing the mark, I don't see any way to ever do that.&n= bsp; TSIG doesn't cover the contents of the OPT record (it can't, TSIG is in the= re too) and it was the last hope.  A second OPT RR in the additional is n= ot going to happen anytime soon.  But I bet that environments that will r= ely on the contents of this field will have other security mechanisms in place.=

 

[1] When I had someone look over the message, he asked why I sugges= ted this and the explanation is worthy of being included here.

 

I got the idea of using domain name syntax from the engineering beh= ind TSIG [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt].  The (secret, symmetric) key shared among two communicating parties - a client and server= - is not present in the DNS data space yet is identified by a string that conforms to a domain name.

 

Until TSIG keys, there were no names assigned to clients in DNS although source  IP addresses were used in ACLs.  Today, BIND's v= iews can match on IP ACLs and/or TSIG key names.  Let me stress that I ment= ion BIND as an example of a DNS implementation, not as a protocol reference.

 

The significance of the name looking like a domain name but not bei= ng one (in the semantic sense) is meant to prevent an authoritative server fro= m having to launch queries in support of answering a question.  Authoritative servers should never learn from the network as that opens a vulnerability i= n terms of learning poisoned data as well as participation in traffic abuses (like DDoS).  We don't want authoritative servers launching traffic fo= r their sake and our sake.

<=
X-SIGSEP>--

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-
Edward Lewis           &nbs= p;            &= nbsp;           &nbs= p;           +1-571-434-5468
NeuStar

 

Think glocally.  Act confused.

--_000_E6C2E8958BA59A4FB960963D475F7AC30273AB7430mailacmepacke_-- --===============1589399385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============1589399385==-- From enum-bounces@ietf.org Fri Dec 14 18:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JdB-0001C5-A9; Fri, 14 Dec 2007 18:07:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Jd9-0001Bz-Cc for enum@ietf.org; Fri, 14 Dec 2007 18:07:43 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Jd7-0003bY-TB for enum@ietf.org; Fri, 14 Dec 2007 18:07:43 -0500 Received: from [192.168.1.101] (hlid.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id lBEN789g078966; Fri, 14 Dec 2007 18:07:21 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 14 Dec 2007 18:07:11 -0500 To: Hadriel Kaplan From: Edward Lewis Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Edward Lewis , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0964327052==" Errors-To: enum-bounces@ietf.org --===============0964327052== Content-Type: multipart/alternative; boundary="============_-1014448843==_ma============" --============_-1014448843==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" The problem with URI's is that if they are the payload of an EDNS field then you are running into something like a layer violation. (URI's have domain names in them, so I don't want/recommend URI's in the DNS packet.) It's not that I want domains in the payload, it's something that is syntactically the same as a domain name. How the payload is interpreted is up to the end points of the message. Like TSIG keys, which are entered into a DNS server via configuration (not via zonefiles). In my use of TSIG I would encode some means of identifying the endpoints and the desired expiration date of the key. So a key name might be "myorg-slave3.12.31.2005." In your use case, you could put the URI information into the payload. Hope that makes things a bit clearer. At 10:49 -0500 12/14/07, Hadriel Kaplan wrote: Interesting idea. I assume you realize such a format could be used for calling number source info as well, simply by formatting the calling number in the ENUM notation: 2.1.2.1.5.5.5.1.8.7.1.e164.mydomain Or some such. But the idea of the source-URI info was not to limit it to domains only. The ENUM server could well look at only the domain portion of the URI, or it could look at the username, or the scheme, or a uri-parameter, or whatever. The client is merely giving it extra information (of its choosing), which the server can ignore or not. Clearly that makes it a very private (closed environment) concept, for it to really work. -hadriel From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Thursday, December 13, 2007 3:29 PM To: Hadriel Kaplan Cc: enum@ietf.org; Robert H. Walter; Creighton,Tom; Raja Gopal Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt At 17:43 -0500 12/11/07, Hadriel Kaplan wrote: http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt Having read the draft and the thread that ensued I have two concerns. One is using EDNS (Extended DNS) for what's described as an application-specific need. The other is the already mentioned security of the data question. I like this idea though. The idea that it promotes is not alien to the operations of DNS although it is alien to the IETF architected version of DNS. "Views" mentioned elsewhere is an implementation-specific feature of ISC's BIND but is one that is widely understood. The notion of selecting an answer based on IP address of the querier or a signature has been floated and put into use. Akamaization is a verb that has been used at times. What might be more appropriate for an identifying mark in the EDNS field is a domain name[1]. DNS, when it does, can differentiate queriers by either an IP address, the source address, or the TSIG key name, which is syntactically (but not semantically) a domain name. I think it is important that the identifying mark not be used as a domain name, I think it would be unwise to have recursive servers try to initiate lookups based on the identifying mark. I am worried about a performance (and DoS?) hit. A generic-to-DNS querier ID would be more acceptable in the DNS extended field than something specific to an application. As far as securing the mark, I don't see any way to ever do that. TSIG doesn't cover the contents of the OPT record (it can't, TSIG is in there too) and it was the last hope. A second OPT RR in the additional is not going to happen anytime soon. But I bet that environments that will rely on the contents of this field will have other security mechanisms in place. [1] When I had someone look over the message, he asked why I suggested this and the explanation is worthy of being included here. I got the idea of using domain name syntax from the engineering behind TSIG [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt]. The (secret, symmetric) key shared among two communicating parties - a client and server - is not present in the DNS data space yet is identified by a string that conforms to a domain name. Until TSIG keys, there were no names assigned to clients in DNS although source IP addresses were used in ACLs. Today, BIND's views can match on IP ACLs and/or TSIG key names. Let me stress that I mention BIND as an example of a DNS implementation, not as a protocol reference. The significance of the name looking like a domain name but not being one (in the semantic sense) is meant to prevent an authoritative server from having to launch queries in support of answering a question. Authoritative servers should never learn from the network as that opens a vulnerability in terms of learning poisoned data as well as participation in traffic abuses (like DDoS). We don't want authoritative servers launching traffic for their sake and our sake. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. --============_-1014448843==_ma============ Content-Type: text/html; charset="us-ascii" RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
The problem with URI's is that if they are the payload of an EDNS field then you are running into something like a layer violation.  (URI's have domain names in them, so I don't want/recommend URI's in the DNS packet.)  It's not that I want domains in the payload, it's something that is syntactically the same as a domain name.

How the payload is interpreted is up to the end points of the message.  Like TSIG keys, which are entered into a DNS server via configuration (not via zonefiles).  In my use of TSIG I would encode some means of identifying the endpoints and the desired expiration date of the key.  So a key name might be "myorg-slave3.12.31.2005."  In your use case, you could put the URI information into the payload.

Hope that makes things a bit clearer.

At 10:49 -0500 12/14/07, Hadriel Kaplan wrote:
Interesting idea.  I assume you realize such a format could be used for calling number source info as well, simply by formatting the calling number in the ENUM notation:
2.1.2.1.5.5.5.1.8.7.1.e164.mydomain
Or some such.
 
But the idea of the source-URI info was not to limit it to domains only.  The ENUM server could well look at only the domain portion of the URI, or it could look at the username, or the scheme, or a uri-parameter, or whatever.  The client is merely giving it extra information (of its choosing), which the server can ignore or not.  Clearly that makes it a very private (closed environment) concept, for it to really work.
 
-hadriel
 
 
From: Edward Lewis [mailto:Ed.Lewis@neustar.biz]
Sent: Thursday, December 13, 2007 3:29 PM
To: Hadriel Kaplan
Cc: enum@ietf.org; Robert H. Walter; Creighton,Tom; Raja Gopal
Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
 
At 17:43 -0500 12/11/07, Hadriel Kaplan wrote:
http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt
 
Having read the draft and the thread that ensued I have two concerns.
 
One is using EDNS (Extended DNS) for what's described as an application-specific need.  The other is the already mentioned security of the data question.
 
I like this idea though.  The idea that it promotes is not alien to the operations of DNS although it is alien to the IETF architected version of DNS.  "Views" mentioned elsewhere is an implementation-specific feature of ISC's BIND but is one that is widely understood.  The notion of selecting an answer based on IP address of the querier or a signature has been floated and put into use.  Akamaization is a verb that has been used at times.
 
What might be more appropriate for an identifying mark in the EDNS field is a domain name[1].  DNS, when it does, can differentiate queriers by either an IP address, the source address, or the TSIG key name, which is syntactically (but not semantically) a domain name.  I think it is important that the identifying mark not be used as a domain name, I think it would be unwise to have recursive servers try to initiate lookups based on the identifying mark.  I am worried about a performance (and DoS?) hit.
 
A generic-to-DNS querier ID would be more acceptable in the DNS extended field than something specific to an application.
 
As far as securing the mark, I don't see any way to ever do that.  TSIG doesn't cover the contents of the OPT record (it can't, TSIG is in there too) and it was the last hope.  A second OPT RR in the additional is not going to happen anytime soon.  But I bet that environments that will rely on the contents of this field will have other security mechanisms in place.
 
[1] When I had someone look over the message, he asked why I suggested this and the explanation is worthy of being included here.
 
I got the idea of using domain name syntax from the engineering behind TSIG [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt].  The (secret, symmetric) key shared among two communicating parties - a client and server - is not present in the DNS data space yet is identified by a string that conforms to a domain name.
 
Until TSIG keys, there were no names assigned to clients in DNS although source  IP addresses were used in ACLs.  Today, BIND's views can match on IP ACLs and/or TSIG key names.  Let me stress that I mention BIND as an example of a DNS implementation, not as a protocol reference.
 
The significance of the name looking like a domain name but not being one (in the semantic sense) is meant to prevent an authoritative server from having to launch queries in support of answering a question.  Authoritative servers should never learn from the network as that opens a vulnerability in terms of learning poisoned data as well as participation in traffic abuses (like DDoS).  We don't want authoritative servers launching traffic for their sake and our sake.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar
 
Think glocally.  Act confused.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.
--============_-1014448843==_ma============-- --===============0964327052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============0964327052==-- From enum-bounces@ietf.org Fri Dec 14 20:21:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Lib-0007NR-JS; Fri, 14 Dec 2007 20:21:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Lia-0007Fb-Fl for enum@ietf.org; Fri, 14 Dec 2007 20:21:28 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3LiS-000629-M9 for enum@ietf.org; Fri, 14 Dec 2007 20:21:28 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Fri, 14 Dec 2007 20:21:20 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Fri, 14 Dec 2007 20:21:20 -0500 From: Hadriel Kaplan To: Edward Lewis Date: Fri, 14 Dec 2007 20:21:19 -0500 Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Index: Acg+piAuB62Ac8nNT/6M+s5Gfnm5hQAEVvlQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d70738b58489ee14fb507f541b784688 Cc: "enum@ietf.org" , "Robert H. Walter" , "Creighton, Tom" , Raja Gopal X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2134901258==" Errors-To: enum-bounces@ietf.org --===============2134901258== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC30273B2DF6Emailacmepacke_" --_000_E6C2E8958BA59A4FB960963D475F7AC30273B2DF6Emailacmepacke_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Right, but what limits me from just saying "they're syntactically like URIs= but not semantically". For example, one can't de-reference them. -hadriel ________________________________ From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Friday, December 14, 2007 6:07 PM To: Hadriel Kaplan Cc: Edward Lewis; enum@ietf.org; Robert H. Walter; Creighton,Tom; Raja Gopa= l Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt The problem with URI's is that if they are the payload of an EDNS field the= n you are running into something like a layer violation. (URI's have domai= n names in them, so I don't want/recommend URI's in the DNS packet.) It's = not that I want domains in the payload, it's something that is syntacticall= y the same as a domain name. How the payload is interpreted is up to the end points of the message. Lik= e TSIG keys, which are entered into a DNS server via configuration (not via= zonefiles). In my use of TSIG I would encode some means of identifying th= e endpoints and the desired expiration date of the key. So a key name migh= t be "myorg-slave3.12.31.2005." In your use case, you could put the URI in= formation into the payload. Hope that makes things a bit clearer. At 10:49 -0500 12/14/07, Hadriel Kaplan wrote: Interesting idea. I assume you realize such a format could be used for cal= ling number source info as well, simply by formatting the calling number in= the ENUM notation: 2.1.2.1.5.5.5.1.8.7.1.e164.mydomain Or some such. But the idea of the source-URI info was not to limit it to domains only. T= he ENUM server could well look at only the domain portion of the URI, or it= could look at the username, or the scheme, or a uri-parameter, or whatever= . The client is merely giving it extra information (of its choosing), whic= h the server can ignore or not. Clearly that makes it a very private (clos= ed environment) concept, for it to really work. -hadriel ________________________________ From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Thursday, December 13, 2007 3:29 PM To: Hadriel Kaplan Cc: enum@ietf.org; Robert H. Walter; Creighton,Tom; Raja Gopal Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt At 17:43 -0500 12/11/07, Hadriel Kaplan wrote: http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt Having read the draft and the thread that ensued I have two concerns. One is using EDNS (Extended DNS) for what's described as an application-spe= cific need. The other is the already mentioned security of the data questi= on. I like this idea though. The idea that it promotes is not alien to the ope= rations of DNS although it is alien to the IETF architected version of DNS.= "Views" mentioned elsewhere is an implementation-specific feature of ISC'= s BIND but is one that is widely understood. The notion of selecting an an= swer based on IP address of the querier or a signature has been floated and= put into use. Akamaization is a verb that has been used at times. What might be more appropriate for an identifying mark in the EDNS field is= a domain name[1]. DNS, when it does, can differentiate queriers by either= an IP address, the source address, or the TSIG key name, which is syntacti= cally (but not semantically) a domain name. I think it is important that t= he identifying mark not be used as a domain name, I think it would be unwis= e to have recursive servers try to initiate lookups based on the identifyin= g mark. I am worried about a performance (and DoS?) hit. A generic-to-DNS querier ID would be more acceptable in the DNS extended fi= eld than something specific to an application. As far as securing the mark, I don't see any way to ever do that. TSIG doe= sn't cover the contents of the OPT record (it can't, TSIG is in there too) = and it was the last hope. A second OPT RR in the additional is not going t= o happen anytime soon. But I bet that environments that will rely on the c= ontents of this field will have other security mechanisms in place. [1] When I had someone look over the message, he asked why I suggested this= and the explanation is worthy of being included here. I got the idea of using domain name syntax from the engineering behind TSIG= [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt]. The (secret, symmetric) = key shared among two communicating parties - a client and server - is not p= resent in the DNS data space yet is identified by a string that conforms to= a domain name. Until TSIG keys, there were no names assigned to clients in DNS although so= urce IP addresses were used in ACLs. Today, BIND's views can match on IP = ACLs and/or TSIG key names. Let me stress that I mention BIND as an exampl= e of a DNS implementation, not as a protocol reference. The significance of the name looking like a domain name but not being one (= in the semantic sense) is meant to prevent an authoritative server from hav= ing to launch queries in support of answering a question. Authoritative se= rvers should never learn from the network as that opens a vulnerability in = terms of learning poisoned data as well as participation in traffic abuses = (like DDoS). We don't want authoritative servers launching traffic for the= ir sake and our sake. -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= - Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= - Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. --_000_E6C2E8958BA59A4FB960963D475F7AC30273B2DF6Emailacmepacke_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

Right, but what limits me from just sa= ying “they’re syntactically like URIs but not semantically”. &= nbsp;For example, one can’t de-reference them.

-hadriel

 

From: Edward L= ewis [mailto:Ed.Lewis@neustar.biz]
Sent: Friday, December 14, 2= 007 6:07 PM
To: Hadriel Kaplan
Cc: Edward Lewis; enum@ietf.= org; Robert H. Walter; Creighton,Tom; Raja Gopal
Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

 

The problem with URI's is that if they are the payload of an EDNS f= ield then you are running into something like a layer violation.  (URI's ha= ve domain names in them, so I don't want/recommend URI's in the DNS packet.)&n= bsp; It's not that I want domains in the payload, it's something that is syntactically the same as a domain name.

 

How the payload is interpreted is up to the end points of the message.  Like TSIG keys, which are entered into a DNS server via configuration (not via zonefiles).  In my use of TSIG I would encode s= ome means of identifying the endpoints and the desired expiration date of the key.  So a key name might be "myorg-slave3.12.31.2005." = ; In your use case, you could put the URI information into the payload.

 

Hope that makes things a bit clearer.

 

At 10:49 -0500 12/14/07, Hadriel Kaplan wrote:

Interesting idea.  I assume you realize such a format could be used for calling number source info as well, simply by formatting the calli= ng number in the ENUM notation:

2.1.2.1.5.5.5.1.8.7.1.e164.mydomain

Or some such.

 

But the idea of the source-URI info was not to limit it to domains only.  The ENUM server could well look at only the domain portion of t= he URI, or it could look at the username, or the scheme, or a uri-parameter, o= r whatever.  The client is merely giving it extra information (of its ch= oosing), which the server can ignore or not.  Clearly that makes it a very priv= ate (closed environment) concept, for it to really work.

 

-hadriel

 

 

From: Edward Lewis [mailto:Ed.Lewis@neustar.biz]
Sent: Thursday, December 13, 2007 3:29 PM
To: Hadriel Kaplan
Cc: enum@ietf.org; Robert H. Walter; Creighton,Tom; Raja Gopal
Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt<= /span>

 

At 17:43 -0500 12/11/07, Hadriel Kaplan wrote:

http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00= .txt

 

Having read the draft and the thread that ensued I have two concern= s.

 

One is using EDNS (Extended DNS) for what's described as an application-specific need.  The other is the already mentioned securit= y of the data question.

 

I like this idea though.  The idea that it promotes is not ali= en to the operations of DNS although it is alien to the IETF architected versi= on of DNS.  "Views" mentioned elsewhere is an implementation-specific feature of ISC's BIND but is one that is widely understood.  The notion of selecting an answer based on IP address of = the querier or a signature has been floated and put into use.  Akamaizatio= n is a verb that has been used at times.

 

What might be more appropriate for an identifying mark in the EDNS field is a domain name[1].  DNS, when it does, can differentiate queri= ers by either an IP address, the source address, or the TSIG key name, which is syntactically (but not semantically) a domain name.  I think it is important that the identifying mark not be used as a domain name, I think i= t would be unwise to have recursive servers try to initiate lookups based on = the identifying mark.  I am worried about a performance (and DoS?) hit.

 

A generic-to-DNS querier ID would be more acceptable in the DNS extended field than something specific to an application.=

 

As far as securing the mark, I don't see any way to ever do that.&n= bsp; TSIG doesn't cover the contents of the OPT record (it can't, TSIG is in the= re too) and it was the last hope.  A second OPT RR in the additional is n= ot going to happen anytime soon.  But I bet that environments that will r= ely on the contents of this field will have other security mechanisms in place.=

 

[1] When I had someone look over the message, he asked why I sugges= ted this and the explanation is worthy of being included here.

 

I got the idea of using domain name syntax from the engineering beh= ind TSIG [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt].  The (secret, symmetric) key shared among two communicating parties - a client and server= - is not present in the DNS data space yet is identified by a string that conforms to a domain name.

 

Until TSIG keys, there were no names assigned to clients in DNS although source  IP addresses were used in ACLs.  Today, BIND's v= iews can match on IP ACLs and/or TSIG key names.  Let me stress that I ment= ion BIND as an example of a DNS implementation, not as a protocol reference.

 

The significance of the name looking like a domain name but not bei= ng one (in the semantic sense) is meant to prevent an authoritative server fro= m having to launch queries in support of answering a question.  Authoritative servers should never learn from the network as that opens a vulnerability in terms of learning poisoned data as well as participation i= n traffic abuses (like DDoS).  We don't want authoritative servers launc= hing traffic for their sake and our sake.

--

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-
Edward Lewis           &nbs= p;            &= nbsp;           &nbs= p;           +1-571-434-5468
NeuStar

 

Think glocally.  Act confused.

 

 

<=
x-sigsep>--

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-
Edward Lewis           &nbs= p;            &= nbsp;           &nbs= p;           +1-571-434-5468
NeuStar

 

Think glocally.  Act confused.

--_000_E6C2E8958BA59A4FB960963D475F7AC30273B2DF6Emailacmepacke_-- --===============2134901258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --===============2134901258==-- From enum-bounces@ietf.org Mon Dec 17 06:43:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ENL-0004wB-2h; Mon, 17 Dec 2007 06:43:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ENJ-0004w3-Hg for enum@ietf.org; Mon, 17 Dec 2007 06:43:09 -0500 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4ENI-0003sR-5Y for enum@ietf.org; Mon, 17 Dec 2007 06:43:08 -0500 Received: from [10.10.0.113] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: LOGIN axelm) by pahula with esmtp; Mon, 17 Dec 2007 12:43:05 +0100 id 0000C0C1.476660C9.000031C2 Message-ID: <476660BF.8010308@enum.at> Date: Mon, 17 Dec 2007 12:42:55 +0100 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: enum@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Enum] (late) comments on draft-kaplan-enum-source-uri-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Couple of comments on the source-URI draft (sorry for being late): at first glance, i found this to be an interesting idea (I was blamed to appreciate "weird" ideas a couple of times, so that might not be a good sign). I definitely understand the use case, and i also understand that the authors have intended this for a limited scope in private deployments (or, maybe in "trusted" cross carrier environments - did anybody say "federation"? :) However, i have a couple of concerns with this: - _If_ the nameserver is expected to return different answers depending on the contents of the Source-URI field, and those answers have to reach the client through the common mechanisms of recursion/caching etc. then this will break. The authoritative nameserver might not even receive the option, or a caching server in between might ignore it. In the end, the client might receive an answer that is perfectly correct in terms of DNS semantics, but does not reflect the "correct" answer depending on the Source URI field. In other words, unless this is used between an "enlightened" client and an "enlightened" server without intermediate DNS elements (and the client ignores all caching assumptions), this will break. Since that is the case, i wonder why this needs to be standardized anyway, since it only works in a very limited subset of scenarios? - This has nothing to do with ENUM. The document requests registration of an EDNS0 option, which is totally independent (and out of scope) of the ENUM WG. It's application to ENUM-DNS-queries (section 5/6) is a use case - not more. As the document itself says in the abstract, it proposes an "DNS extension", not an "ENUM extension". - I'm missing a way for the server to indicate that the option has actually been processed, so that the client can distinguish an "enlightened" response from a standard DNS response. What about copying the option into the response, so that the client can figure whether the answer depends on the URI? Ok, if we^Hyou want to move forward, i suggest to do the following: - Split the documents into the Option registration, and the ENUM use case. Keep the Option registration neutral, and describe it's use for ENUM in the use case document. Don't bother the ENUM wg with the option registration. (RFC 2929 mandates only a "specification" for EDNS0 options, so i think even a draft would be enough for registration) - Add extensive text about limited applicability of this option. Essentially, you can't trust it to be processed unless you control the whole chain. - Provide a mechanism to indicate in the response whether the option has been processed. - The security considerations section is err... lacking. It should at least say that info in the option can't be trusted unless some trust relation along the whole chain is in place. hope that helps, Alex _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Dec 17 10:41:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4I5X-0004ri-LB; Mon, 17 Dec 2007 10:41:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4I5V-0004mA-Tq for enum@ietf.org; Mon, 17 Dec 2007 10:41:01 -0500 Received: from hlid.ogud.com ([66.92.146.160] helo=ogud.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4I5V-00069u-FR for enum@ietf.org; Mon, 17 Dec 2007 10:41:01 -0500 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id lBHFevow098695 for ; Mon, 17 Dec 2007 10:40:57 -0500 (EST) (envelope-from ogud+enum@ogud.com) Message-Id: <200712171540.lBHFevow098695@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Dec 2007 10:39:40 -0500 To: enum@ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6 X-Spam-Score: -0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org First: What is an "ENUM server" and what protocol does it speak? From the document it sounds like it speaks DNS on the wire but the behavior is nothing that is supported by DNS. Second: + 10. Example Exchange + + [Do we need an example?] Yes please because as an DNS person I still have no clue what you want to accomplish or what your query sequence looks like. Third: >11. Security Considerations > > There are no specific security issues for this mechanism, beyond > those already applicable to DNS and ENUM. This is so wrong I do not want to start, just change it to TDB Forth: DNS is a lookup protocol where the data is retrieved by specifying the "whole Q-Trinity" QNAME, QCLASS, QTYPE all questions with the same Q-Trinity asked from the same address, to the same server should give out the same answer while the serial number of the zone in question stays the same! As far as I can tell: this document is proposing that some payload in the DNS query packet, outside the Query section, selects from different answers and possibly modifies the answer selected. Giving out the same answer with different TTL's is plain wrong depending on ENDS0 payload. TTL==0 is a BAD IDEA to start with, in particular if there are multiple parallel query streams going on. Fifth: ENDS0 is hop-by-hop mechanism not end-to-end, so this may not work if there are any intermediary DNS protocol elements between the client and the authorative server. I do not see the need for your section 8 in the document it confused me just site section 4 of RFC2671 in your section 9. Section 9, mixes the Option header with the option contents. Please do not propose sub-typing in the option just get different ENDS option code for each "version". Sixth: What is exactly the problem you want to solve? There might be other solutions and without concrete examples it is hard for outsiders like me to judge this one or propose alternatives. Seventh: IFF this working group has a firm proposal that modifies HOW DNS WORKS that proposal should migrate to DNSEXT for formal processing. DNSEXT role is still to "defend DNS from bad ideas" no matter what its current status is, it is not going away anytime soon. At this point in time, ENUM WG should figure out if modifying DNS is REQUIRED and proceed from there. Olafur _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Dec 17 18:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4P5Y-0006zh-TI; Mon, 17 Dec 2007 18:09:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4P5X-0006zV-CO for enum@ietf.org; Mon, 17 Dec 2007 18:09:31 -0500 Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4P5W-00044k-SD for enum@ietf.org; Mon, 17 Dec 2007 18:09:31 -0500 Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0; Mon, 17 Dec 2007 18:09:30 -0500 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Mon, 17 Dec 2007 18:09:30 -0500 From: Hadriel Kaplan To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , "enum@ietf.org" Date: Mon, 17 Dec 2007 18:09:21 -0500 Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Topic: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt Thread-Index: AchAw0FZgHpYmrxxR2W3EvQBSVvySAAN4qPA Message-ID: References: <200712171540.lBHFevow098695@ogud.com> In-Reply-To: <200712171540.lBHFevow098695@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Olafur, Inline... > -----Original Message----- > From: =D3lafur Gu=F0mundsson [mailto:ogud+enum@ogud.com] > Sent: Monday, December 17, 2007 10:40 AM > To: enum@ietf.org > Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt > > > First: > What is an "ENUM server" and what protocol does it speak? > From the document it sounds like it speaks DNS on the wire but the > behavior > is nothing that is supported by DNS. Yes, that is essentially correct for these servers - they're private server= s used in private/contained environments. In that sense no it's not really= different, or at least not meant to be. :) That is to say it's not meant = to be used in the public space at all, nor for DNS in general. It's really= just a very private use-case - basically proprietary - in fact we wouldn't= have bothered documenting it, except we know many vendors want to do this = type of thing in private use as well, so we figured it might as well be doc= 'ed so different vendor private clients can talk to different vendor privat= e servers. > Second: > + 10. Example Exchange > + > + [Do we need an example?] > > Yes please because as an DNS person I still have no clue what you > want to accomplish or what your query sequence looks like. The query sequence looks just like normal ENUM queries, except the querier = happens to insert some opaque data which may or may not help the server fil= ter or determine a better answer. > Third: > >11. Security Considerations > > > > There are no specific security issues for this mechanism, beyond > > those already applicable to DNS and ENUM. > > This is so wrong I do not want to start, just change it to TDB Yeah, you're right should have just said TBD. :( > Fifth: > ENDS0 is hop-by-hop mechanism not end-to-end, so this may not work > if there are any intermediary DNS protocol elements between the client an= d > the authorative server. Yes, this was intended to be hop-by-hop. > Sixth: > What is exactly the problem you want to solve? > There might be other solutions and without concrete examples it is > hard for outsiders like me to judge this one or propose alternatives. Absolutely: DNS is being used in private/contained environments as a lightweight databa= se lookup to map telephone numbers to private URI's, Calling Name lookups, = and so on - i.e., "private ENUM". This is very much a private ENUM use, no= t public ENUM (ie, not "real" DNS - it shares the protocol on the wire, but= not the architecture). The problem is, in order to give back the correct = or at least most-specific answers, those private ENUM servers need some add= itional data from the (private) queriers: source URI data. It's essentiall= y just opaque text. If the server doesn't understand it, it can just respo= nd as if it didn't exist, or create an error - either would be fine for res= olving their problem I think. > Seventh: > > IFF this working group has a firm proposal that modifies HOW DNS WORKS > that proposal should migrate to DNSEXT for formal processing. > DNSEXT role is still to "defend DNS from bad ideas" no matter what its > current status is, it is not going away anytime soon. No questions about that - it wasn't meant to modify how DNS works. It was = meant as a private-use extension for a specific private use of ENUM. -hadriel _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Dec 18 15:15:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iqI-0001fg-CA; Tue, 18 Dec 2007 15:15:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iqF-0001eB-4P; Tue, 18 Dec 2007 15:15:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4iqE-0002ht-Ku; Tue, 18 Dec 2007 15:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 7FB4A26E91; Tue, 18 Dec 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J4iqE-0005jD-Br; Tue, 18 Dec 2007 15:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Dec 2007 15:15:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-vmsg-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration of Enumservices for Voice and Video Messaging Author(s) : J. Livingood, D. Troshynski Filename : draft-ietf-enum-vmsg-01.txt Pages : 27 Date : 2007-12-18 This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice and/or video communications to a messaging system. This vmsg Enumservice registers three Enumservice types; "voicemsg", "videomsg", and "unifmsg". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vmsg-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-enum-vmsg-01.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-enum-vmsg-01.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: <2007-12-18141751.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-vmsg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-vmsg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-18141751.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart-- From enum-bounces@ietf.org Fri Dec 21 18:03:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qq9-0000kO-3K; Fri, 21 Dec 2007 17:59:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qq7-0000iF-U2; Fri, 21 Dec 2007 17:59:35 -0500 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5qq7-0003JM-G4; Fri, 21 Dec 2007 17:59:35 -0500 Received: by bosco.isi.edu (Postfix, from userid 70) id 397641052C3; Fri, 21 Dec 2007 14:59:35 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20071221225935.397641052C3@bosco.isi.edu> Date: Fri, 21 Dec 2007 14:59:35 -0800 (PST) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: enum@ietf.org, rfc-editor@rfc-editor.org Subject: [Enum] RFC 5105 on ENUM Validation Token Format Definition X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5105 Title: ENUM Validation Token Format Definition Author: O. Lendl Status: Standards Track Date: December 2007 Mailbox: otmar.lendl@enum.at Pages: 17 Characters: 33057 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-enum-validation-token-04.txt URL: http://www.rfc-editor.org/rfc/rfc5105.txt An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes a signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. [STANDARDS TRACK] This document is a product of the Telephone Number Mapping Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Dec 22 10:14:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6636-0006IR-Pt; Sat, 22 Dec 2007 10:14:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6634-0006GY-PM; Sat, 22 Dec 2007 10:13:58 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J6633-0000XR-Qs; Sat, 22 Dec 2007 10:13:58 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm17476d8d69; Sat, 22 Dec 2007 23:27:11 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm647689266; Wed, 19 Dec 2007 05:26:46 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 19 Dec 2007 05:26:46 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iqK-0001fl-4X; Tue, 18 Dec 2007 15:15:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iqF-0001eB-4P; Tue, 18 Dec 2007 15:15:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4iqE-0002ht-Ku; Tue, 18 Dec 2007 15:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 7FB4A26E91; Tue, 18 Dec 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J4iqE-0005jD-Br; Tue, 18 Dec 2007 15:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 18 Dec 2007 15:15:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 4.9 (++++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: enum@ietf.org Subject: [Enum] I-D ACTION:draft-ietf-enum-vmsg-01.txt X-BeenThere: enum@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : IANA Registration of Enumservices for Voice and Video Messaging Author(s) : J. Livingood, D. Troshynski Filename : draft-ietf-enum-vmsg-01.txt Pages : 27 Date : 2007-12-18 This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice and/or video communications to a messaging system. This vmsg Enumservice registers three Enumservice types; "voicemsg", "videomsg", and "unifmsg". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-vmsg-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-enum-vmsg-01.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-enum-vmsg-01.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: <2007-12-18141751.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-vmsg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-vmsg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-18141751.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum --NextPart--