Subject: RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment

From: "Pfautz, Penn L, ALABS" <[email-masked]>
Date: Tue, 10 Aug 2004 10:16:40 -0400

<FONT face=Arial color=#0000ff 
size=2>Kim:
I 
still see a couple of issues that would motivate separate user and operator ENUM 
Tier 2s. In at least some opt-in countries, the user would be allowed to choose 
the Tier 2 that actually held the NAPTR records. So you have a problem as soon 
as user and operator both want entries which are different and want them in 
different Tier 2s. The existing implementation with NS records in Tier doesn't 
support this. The I-D Steve Lind and I offered ( 
"draft-pfautz-lind-enum-carrier-00.txt) was an attempt to get around that 
problem but the problem is real.
<FONT face=Arial color=#0000ff 
size=2> 
Penn 
Pfautz

  <FONT face=Tahoma 
  size=2>-----Original Message-----From: enum-bounces at ietf.org 
  [mailto:enum-bounces at ietf.org]On Behalf Of Fullbrook Kim 
  (UK)Sent: Tuesday, August 10, 2004 8:54 AMTo: 
  'enum at ietf.org'Subject: [Enum] ENUM Privacy Consensus, RFC 3824 and 
  ENUM deployment
  Although the debate about ENUM 
  privacy issues has subsided, having read the new RFC 3824 I feel that it's 
  worth summarising the key points of the privacy discussion and the 
  implications for the RFC, as well as making some general suggestions for ENUM 
  deployment.
  This is my understanding of the 
  summary of the privacy debate:  
  <summary> <FONT 
  face=Arial color=#0000ff size=2>With the privacy concerns about personal 
  information put in a publicly accessible DNS, particularly with the "opt in" 
  privacy policies in some countries, we would not expect SIP URIs of the format 
  johndoe at bigtelco.com in the DNS to be available for all subscribers 
  globally.  However, if John Doe's E.164 number is 1234567890 you could 
  put the SIP URI  sip:1234567890 at bigtelco.com in the public DNS because 
  this doesn't cause any privacy difficulties while also providing a necessary 
  link in the call routing chain.  If there was no SIP URI record for a 
  particular E.164 number in the DNS you couldn't route SIP calls which are 
  addressed via E.164 number and the service would break unless some other 
  routing solution was provided. In "opt in" countries John Doe could "opt in" 
  to include his SIP URI in the DNS or in certain countries everyone would 
  automatically be added unless they "opted out".  There is no need to have 
  separate "user" and "operator" ENUM infrastructures for resolving E.164 
  numbers into a SIP URI: everything as described above can go in the public 
  "user" DNS because the privacy concerns are gone. (You might need operator 
  ENUM for something else but that's not the topic for debate here).  
  
  </summary> 
  Section 8 of RFC 3824 acknowledges 
  security concerns over SIP URIs in the DNS but only suggests using a SIP URI 
  like anonymous00045 at example.com  for those concerned about privacy.  
  I'd suggest that this section of the RFC should reflect the outcome of our 
  privacy debate and include the principles summarised in this note, or whatever 
  we agree if my words and suggestions aren't right.
  An implication of the summary above 
  is that the "lowest common denominator" for SIP URI would be the numeric 
  format  e.g. sip:1234567 at domain.com  if we choose to recommend it. 
  With this in mind, let's test the suggestion by moving forward a few years 
  into a future where SIP-based telephony is more widespread, including 
  3GPP-based IMS systems and where DNS provisioning issues are important.  
  Take the example of a SIP user who wishes to make a call to another SIP 
  customer using their E.164 number.  If the called customer has "opted in" 
  to ENUM and a SIP URI exists such as sip:johndoe at siptelco.com  this will 
  work in the normal way. If they are not "opted in", then provided the DNS 
  datafill has been done in line with the "lowest common denominator" format, a 
  numeric SIP URI exists in the ENUM DNS e.g. sip:987654321 at siptelco.com so the 
  ENUM lookup will succeed and the call routes via 
  siptelco.com     
  This works fine but what about the 
  implications for DNS provisioning ?  If we said that all customers (SIP 
  and non-SIP) have an entry in the ENUM DNS using the numeric SIP URI format we 
  would need to build a huge DNS table containing entries like:
  4412345678  ->   
  sip:4412345678 at owning-operator.com 
  Although there would be a huge number 
  of DNS entries, an individual entry would only need to change if the number 
  was ported to a different operator 
  e.g. sip:987654321@ 
  owning-operator.com  changed to  
  sip:987654321 at alternatesipco.com 
  Having an individual DNS record for 
  each phone number is simple conceptually but involves creating a huge number 
  of records which look something like this:
  e.g.  
  8.7.6.5.4.3.2.1.4.4.e164.arpa  ->  
  !^.*$!sip:4412345678 at big-uk-telco.co.uk 
  However, if it is possible to do full 
  wildcarding in DNS in conjunction with a rewrite rule this could be fairly 
  easy to set up.  The idea is that a single line for a whole dial code 
  range combined with a clever rewrite rule could rewrite any matching E.164 
  number in that range to a suitable SIP URI:
  *.8.0.2.4.4.e164.arpa  
  ->   sip: <reg exp> @uk-sip-telco.co.uk    
  So that, using letters to 
  represent the generalised E.164 number  44208abcdef <FONT 
  face=Arial color=#0000ff size=2>f.e.d.c.b.a.8.0.2.4.4.e164.arpa ->  
  sip:44208abcdef at uk-sip-telco.co.uk 
  Having experimented with a test DNS 
  the wildcarding part works fine: you can have a general wildcarding rule for 
  the whole number range pointing to the "owning" operator together with 
  specific entries to over-ride the wild card where a particular E.164 number 
  has been ported to a different operator.  Unfortunately my skills in 
  regular expressions are not good enough to figure out whether you could create 
  a rewrite rule to do what's needed in the above example. Any "regular 
  _expression_" experts out there interested in this challenge ?
  Summarising the suggestions. 
  - All SIP customers have a "minimum" 
  URI entry in the publicly visible ENUM DNS with their E.164 number e.g. 
  sip:5432112345 at bigsipco.com
  - There shouldn't be any privacy 
  concerns with the above - In 
  "opt in" countries a SIP customer could add their SIP URI if they wished  
  e.g. johndoe at bigsipco.com - 
  You could add non-SIP customers to the DNS using the numeric SIP URI format, 
  allowing SIP calls to them to route to the right interconnect point (SIP to 
  POTS interworking)
  - DNS wildcarding in conjunction with 
  a clever rewrite rule might allow easy creation of these numeric SIP URIs 
  without needing to create millions of individual DNS records
  Kim Fullbrook <FONT 
  face=Arial color=#0000ff size=2>O2 UK 

  ========================================================This electronic 
  message contains information from the mmO2 plc Group which may be 
  privileged or confidential. The information is intended tobe for the use 
  of the individual(s) or entity named above. If you are notthe intended 
  recipient be aware that any disclosure, copyingdistribution or use of the 
  contents of this information is prohibited. If youhave received this 
  electronic message in error, please notify usby telephone or email (to the 
  numbers or address above) 
  immediately.========================================================
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Fullbrook Kim (UK)" <[email-masked]>
Date: Wed, 11 Aug 2004 10:11:45 -0400

To clarify what I was trying to say in the original proposal note:

- All SIP customers have a "minimum" URI entry in the publicly visible ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com

- In "opt in" countries a SIP customer could add their SIP URI if they wished  e.g. sip:johndoe at bigsipco.com

In other words, those customers who wish to add their SIP URI - i.e. which username they wish to use - can do so, with a minimum DNS entry of just a numeric SIP URI

Just to recap, I'm talking about the ENUM DNS here.  I can't see that there is a problem with a customer having two or more id's in here - a numeric SIP URI (sip:5432112345 at bigsipco.com) plus a username type SIP URI (sip:johndoe at bigsipco.com). Please correct me if I have misunderstood the RFCs here.

On the other hand, in the cases where the customer wishes to publish a username type SIP URI, there would be no problem technically if the numeric SIP URI was removed.  The thinking was that having a numeric SIP URI for everyone ought to make DNS provisioning easier because it is always there. 

John Curran in his recent note summed up quite well what I'm trying to achieve (thanks John for your words which I've changed slightly here) - specify the common expectation of ENUM DNS contents necessary for interoperability.

Kim.

-----Original Message-----
From: James Seng [mailto:jseng at pobox.org.sg] 
Sent: 10 August 2004 16:18
To: Fullbrook Kim (UK)
Cc: 'enum at ietf.org'
Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment

 > - All SIP customers have a "minimum" URI entry in the publicly visible
 > ENUM DNS with their E.164 number e.g. sip:5432112345 at bigsipco.com

-James Seng

Fullbrook Kim (UK) wrote:

> James,
> 
> I don't believe I've said anything about enforcing what usernames people 
> wish to use and would be very grateful if you can point out where this 
> is described.
> 
> Thanks,
> Kim.
> 
> -----Original Message-----
> From: James Seng [mailto:jseng at pobox.org.sg]
> Sent: 10 August 2004 15:55
> To: Fullbrook Kim (UK)
> Cc: 'enum@
ietf.org'
> Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM deployment
> 
> 
> i find it ridiclous that you think you can enforced how people wants to
> assign username on their own sip boxes.
> 
> this is like saying 'you cannot have email address with your name in
> their' and publish it as an rfc.
> 
> james

========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby telephone or email (to the numbers or address above) immediately.========================================================
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Pfautz, Penn L, ALABS" <[email-masked]>
Date: Wed, 11 Aug 2004 10:35:48 -0400

<FONT face=Arial color=#0000ff 
size=2>Kim:
Are 
you assuming that "bigsipco" represents the carrier of record for the number in 
the PSTN?
Who 
owns the Tier 2 where these NAPTRS are when both carrier and end user want 
records which are different?
<FONT face=Arial color=#0000ff 
size=2> 
Penn 
Pfautz

  <FONT face=Tahoma 
  size=2>-----Original Message-----From: enum-bounces at ietf.org 
  [mailto:enum-bounces at ietf.org]On Behalf Of Fullbrook Kim 
  (UK)Sent: Wednesday, August 11, 2004 10:09 AMTo: 
  'enum at ietf.org'Cc: 'James Seng'Subject: RE: [Enum] ENUM 
  Privacy Consensus, RFC 3824 and ENUM deployment
  To clarify what I was trying to say in the original proposal 
  note: 
  - All SIP customers have a "minimum" URI entry in the publicly 
  visible ENUM DNS with their E.164 number e.g. 
  sip:5432112345 at bigsipco.com
  - In "opt in" countries a SIP customer could add their SIP URI 
  if they wished  e.g. sip:johndoe at bigsipco.com 
  In other words, those customers who wish to add their SIP URI 
  - i.e. which username they wish to use - can do so, with a minimum DNS entry 
  of just a numeric SIP URI
  Just to recap, I'm talking about the ENUM DNS here.  I 
  can't see that there is a problem with a customer having two or more id's in 
  here - a numeric SIP URI (sip:5432112345 at bigsipco.com) plus a username type 
  SIP URI (sip:johndoe at bigsipco.com). Please correct me if I have misunderstood 
  the RFCs here.
  On the other hand, in the cases where the customer wishes to 
  publish a username type SIP URI, there would be no problem technically if the 
  numeric SIP URI was removed.  The thinking was that having a numeric SIP 
  URI for everyone ought to make DNS provisioning easier because it is always 
  there. 
  John Curran in his recent note summed up quite well what I'm 
  trying to achieve (thanks John for your words which I've changed slightly 
  here) - specify the common expectation of ENUM DNS contents necessary for 
  interoperability.
  Kim. 
  -----Original Message----- From: James 
  Seng [mailto:jseng at pobox.org.sg] 
  Sent: 10 August 2004 16:18 To: 
  Fullbrook Kim (UK) Cc: 'enum at ietf.org' 
  Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM 
  deployment 
   > - All SIP customers have a "minimum" URI entry in 
  the publicly visible  > ENUM DNS with their 
  E.164 number e.g. sip:5432112345 at bigsipco.com 
  -James Seng 
  Fullbrook Kim (UK) wrote: 
  > James, > <FONT 
  size=2>> I don't believe I've said anything about enforcing what usernames 
  people > wish to use and would be very grateful if 
  you can point out where this > is described. 
  > > Thanks, <FONT 
  size=2>> Kim. > > 
  -----Original Message----- > From: James Seng [<A 
  href="mailto:jseng at pobox.org.sg">mailto:jseng at pobox.org.sg] 
  > Sent: 10 August 2004 15:55 > 
  To: Fullbrook Kim (UK) > Cc: 'enum@ 
  ietf.org' > Subject: Re: [Enum] ENUM Privacy 
  Consensus, RFC 3824 and ENUM deployment > 
  > > i find it ridiclous 
  that you think you can enforced how people wants to <FONT 
  size=2>> assign username on their own sip boxes. <FONT 
  size=2>> > this is like saying 'you cannot have 
  email address with your name in > their' and 
  publish it as an rfc. > <FONT 
  size=2>> james

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 11 Aug 2004 14:16:21 -0400

<FONT face=Arial color=#0000ff 
size=2>Mandating, as you seem to suggest below, the use of telephone numbers in 
the user portion of a SIP AoR as the best way to achieve privacy might work for 
the ENUM case, but neglects the broader SIP case. RFC3824 was not a product of 
the ENUM WG (though the document was last-called here as well to make sure it 
didn't step on ENUM's toes), and the guidance for creation of private URIs 
in that document reflects SIP practices (e.g., RFC3323), without assuming that 
SIP is only used with an ENUM bootstrap. <FONT 
face=Arial color=#0000ff size=2>Strictly speaking, even revealing the hostname 
"bigsipco.com" (as you propose below) can be cause for privacy concerns in some 
cases - if my personal domain were to appear in the host portion, for example, 
that would be sufficient to identify that the record pointed to me. So, from a 
SIP privacy perspective, I would consider the mechanism below to be a partial 
solution that addresses a small segment of the total problem 
space.
<FONT face=Arial color=#0000ff 
size=2> 
<FONT face=Arial color=#0000ff 
size=2>Moreover, the hard fact of the matter is that there are, and will 
continue to be, greenfield SIP services unaffiliated with the PSTN, and ENUM 
NAPTR records should be able to point to those services, even if such services 
do not support usernames that happen to be E.164 numbers. While many 
greeenfield SIP deployments (like FWD or iptel.org) can provide users with 
numeric username identifiers, those identifiers are not E.164 numbers (my FWD 
numeric username is five digits long). In contrast, your proposal seems to at 
best assume, and at worst mandate, that the operator of my SIP service be 
authoritative for any telephone number for which I happen to provision a NAPTR 
record in ENUM. This assumption creates an unnecessary linkage between the 
operators of E.164 numbers and the operators of SIP services. The DNS (and this 
goes for ENUM too) just provides pointers to network resources; those resources 
may not know that they are being pointed to by the DNS, and certainly we should 
not try to constrain the internal naming conventions used by those resources 
just because something in the DNS may happen to be pointing at them at any given 
moment.
<FONT face=Arial color=#0000ff 
size=2> 
It is 
also probably worth mentioning that RFC3824 does discourage placing multiple SIP 
URIs in a given ENUM NAPTR RR set (see the third bullet in Section 
4).
<FONT face=Arial color=#0000ff 
size=2> 
Jon 
Peterson
<FONT face=Arial color=#0000ff 
size=2>NeuStar, Inc.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <FONT face=Tahoma 
  size=2>-----Original Message-----From: Fullbrook Kim (UK) 
  [mailto:Kim.Fullbrook at O2.COM]Sent: Wednesday, August 11, 2004 7:09 
  AMTo: 'enum at ietf.org'Cc: 'James Seng'Subject: 
  RE: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM 
  deployment
  To clarify what I was trying to say in the original proposal 
  note: 
  - All SIP customers have a "minimum" URI entry in the publicly 
  visible ENUM DNS with their E.164 number e.g. 
  sip:5432112345 at bigsipco.com
  - In "opt in" countries a SIP customer could add their SIP URI 
  if they wished  e.g. sip:johndoe at bigsipco.com 
  In other words, those customers who wish to add their SIP URI 
  - i.e. which username they wish to use - can do so, with a minimum DNS entry 
  of just a numeric SIP URI
  Just to recap, I'm talking about the ENUM DNS here.  I 
  can't see that there is a problem with a customer having two or more id's in 
  here - a numeric SIP URI (sip:5432112345 at bigsipco.com) plus a username type 
  SIP URI (sip:johndoe at bigsipco.com). Please correct me if I have misunderstood 
  the RFCs here.
  On the other hand, in the cases where the customer wishes to 
  publish a username type SIP URI, there would be no problem technically if the 
  numeric SIP URI was removed.  The thinking was that having a numeric SIP 
  URI for everyone ought to make DNS provisioning easier because it is always 
  there. 
  John Curran in his recent note summed up quite well what I'm 
  trying to achieve (thanks John for your words which I've changed slightly 
  here) - specify the common expectation of ENUM DNS contents necessary for 
  interoperability.
  Kim. 
  -----Original Message----- From: James 
  Seng [mailto:jseng at pobox.org.sg] 
  Sent: 10 August 2004 16:18 To: 
  Fullbrook Kim (UK) Cc: 'enum at ietf.org' 
  Subject: Re: [Enum] ENUM Privacy Consensus, RFC 3824 and ENUM 
  deployment 
   > - All SIP customers have a "minimum" URI entry in 
  the publicly visible  > ENUM DNS with their 
  E.164 number e.g. sip:5432112345 at bigsipco.com 
  -James Seng 
  size=2>> Kim. > >