Subject: RE: [Enum] DNS for E.164-IP Address Mapping

From: James Yu <[email-masked]>
Date: Fri, 7 Jan 2000 12:08:47 -0600

I assume that the "scheme" or "mechanism" is there by using different URL
types.  Would appreciate if you can briefly describe the scheme/mechanism or
point to some documents.  For services/applications that are not yet
supported by the identified URL types, I assume that new URL types must be
defined.  Is it correct?

James

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, January 07, 2000 12:23 PM
> To: James Yu
> Cc: [email-masked]
> Subject: Re: [Enum] DNS for E.164-IP Address Mapping
> 
> 
> This is already addressed by the current solution. You can obtain a
> variety of URL types (sip, ldap, mailto) from the DNS. Enum 
> is actually
> better described as a phone number to URL mapping solution.
> 
> -Jonathan R.
> 
> James Yu wrote:
> > 
> > In the SCN, the same E.164 number (a national number in the 
> US) can be
> > mapped to different Signaling System 7 addresses (e.g., point codes)
> > depending on the applications.  For example, an E.164 
> number is mapped to a
> > Line Information Database (LIDB) point code for caller ID 
> and caller name
> > services, and to an end office (class 5 switch) that serves 
> the E.164 number
> > for Call Completion to Busy Subscriber (CCBS) service.
> > 
> > The same will apply to the E.164 to IP address mapping.  So 
> far, enum has
> > focused on the voice calls only.  There are other services 
> that will require
> > mapping between the E.164 number and the IP address of a 
> server/database
> > depending on the applications.
> > 
> > One application that I have identified is the Inter-Company Voice
> > Mail/Messaging where a voice mail/messaging server's IP 
> address is to be
> > mapped to a particular E.164 number.  There will be others. 
>   If DNS is to
> > be used for all the services for E.164 to IP address 
> mapping, we may need
> > the ability to indicate the "application/service" type in 
> the DNS query so
> > that specific records can be returned.  Another may is just 
> to return all
> > the records that may be associated with the associated 
> E.164 number with
> > different record types for different applications/services 
> and let the DNS
> > query sender decide which one or ones to use.   Any comments?
> > 
> > James Yu
> > Principal Technical Industry Liaison
> > NeuStar Inc.
> > 1120 Vermont Avenue, NW,
> > Suite 550
> > Washington, D.C. 20005
> > USA
> > +1-202-533-2814 (B)
> > +1-202-533-2975 (Fax)
> > +1-202-256-1200 (Mobile)
> > [email-masked]
> > http://www.neustar.com
> > 
> > _______________________________________________
> > enum mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/enum
> 
> -- 
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120 
> dynamicsoft                                 West Orange, NJ 07052
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 

_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jan 2000 13:45:12 -0500

I used the work "mechanism" when URI scheme is the correct term. Check
rfc2396 for a general discussion. There are many URI schemes defined;
I'm not sure if there is an IANA procedure somewhere defined for
registering them. 

-Jonathan R.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 07 Jan 2000 13:34:18 -0600

>I'm not sure if there is an IANA procedure somewhere defined for

Well for telephony applications there is a draft outlining how the URL's 
should be defined. I'm sure if there were other types of applications that 
need to be referenced in NAPTR records... Universal Messaging Servers, 
T.38, it should be no trouble defining a simple registration procedure.

Jonathan.... one of the things I'm increasingly concerned about is DNS 
security here. Do you have any thoughts on how much of DNSSEC we might have 
to require?

Title           : URLs for Telephone Calls
         Author(s)       : A. Vaha-Sipila
         Filename        : draft-antti-telephony-url-12.txt
         Pages           : 22
         Date            : 29-Dec-99

This document specifies URL (Uniform Resource Locator) schemes
'tel', 'fax' and 'modem' for specifying the location of a
terminal in the phone network and the connection types (modes of
operation) that can be used to connect to that entity. This
specification covers voice calls (normal phone calls, answering
machines and voice messaging systems), facsimile (telefax) calls and
data calls, both for POTS and digital/mobile subscribers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-antti-telephony-url-12.txt

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Jan 2000 01:42:59 -0500

> security here. Do you have any thoughts on how much of DNSSEC we might have

Not really... I hope some real security experts can provide guidance on
that. Clearly the DNS SIG record is most important for us; I presume we
would need to provide signatures on both the NS and SRV (with NS really
important). I'd love to hear from folks whether dnssec is deployed and
used anywhere - is it in bind?

-Jonathan R.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 10 Jan 2000 08:01:48 +0100

--On 2000-01-10 01.42 -0500, Jonathan Rosenberg <[email-masked]> 
wrote:

>> security here. Do you have any thoughts on how much of DNSSEC we might
>> have to require?
>

Some part is in bind already, but not to a level that it scales so one can 
use it in operations. The signing process and some other things makes 
operations very difficult. We also need some resolver library additions 
which can verify the chain of keys/sig, aswell as some secure connection 
between the client resolver and the host which verifies the keys.

Note though that I don't see that we need more security here than what we 
have on DNS in general. I.e. if the ENUM resolution ends up with an 
interaction using SIP, H.323 or some other protocol on top of IP, that will 
be as insecure as the ENUM resolution. I.e. strengthening the ENUM part 
will not help until all parts are stronger.

So, because of this, I definitely think we should point to, and find it 
being enough that, DNSSEC is what should be used to secure DNS. I.e. this 
whole thing of securing DNS is someone elses problem :-)

It is VERY easy to say, but this time I think it is the only reasonable 
thing to say.

   paf

---

From: Bill Manning <[email-masked]>
Date: Tue, 11 Jan 2000 07:40:35 -0800 (PST)

% Richard Shockey wrote:
% > 
% > Jonathan.... one of the things I'm increasingly concerned about is DNS
% > security here. Do you have any thoughts on how much of DNSSEC we might have
% > to require?
% 
% Not really... I hope some real security experts can provide guidance on
% that. Clearly the DNS SIG record is most important for us; I presume we
% would need to provide signatures on both the NS and SRV (with NS really
% important). I'd love to hear from folks whether dnssec is deployed and
% used anywhere - is it in bind?

DNSSEC is not deployed widely and is still only used in testbeds. It's been
in BIND for some time but is not always backward compatable.  The current
release will sign both NS and SRV records.

--bill

---

From: Graham Klyne <[email-masked]>
Date: Tue, 11 Jan 2000 11:33:10 +0000

>I'm not sure if there is an IANA procedure somewhere defined for

There is now:

A new Request for Comments is now available in online RFC libraries.

         BCP 35
         RFC 2717

         Title:      Registration Procedures for URL Scheme Names
         Author(s):  R. Petke, I. King
         Status:     Best Current Practice
         Date:       November 1999
         Mailbox:    [email-masked], [email-masked]
         Pages:      10
         Characters: 19780
         Updates/Obsoletes/See Also: None
         I-D Tag:    draft-ietf-urlreg-procedures-08.txt

         URL:        ftp://ftp.isi.edu/in-notes/rfc2717.txt

#g

------------
Graham Klyne
([email-masked])