Subject: [Enum] Re: Unused-00

From: lconroy <[email-masked]>
Date: Fri, 12 Jan 2007 12:07:13 +0000

Hi Penn, Richard, folks,
  I also appreciate the comments. I trust you did get a drink after  
reading this.
-------------
Re. 3.5 (The gateway loop issue) -
There are gateways that try to place calls to VoIP end points using  
ENUM already.
Such gateways may not be aware of the entire numbering plans around  
the world.
It is not possible for such an "unaware" gateway to know what case it  
is handling.
Provisioning NAPTRs as proposed gives it that knowledge.

The loop need not be with a single unit. We have seen a different  
gateway selected
by a "drop back" to the PSTN, followed by an attempt to direct a call  
to an endpoint
via ENUM. The second gateway instance does not know that the first  
unit has tried
ENUM and dropped back to the PSTN. Such "extended" loops do occur.  
They can be
avoided if 'unused' are provisioned as we recommend.
-------------

Re. 7.4 (information leakage)
In our defence, I should point out that the last paragraph in 7.1 was  
originally
a separate sub-section, covering the different choices that NRAs can  
and have made.
We had feedback from our in-house reviewers that this did not help  
(and made the
document even longer), so we trimmed it to just the important case -  
you may not
be allowed to publish data that allows such leakage.

We also put this in as the first condition for provisioning cases 2,  
3 to help
it "stand out".

The paragraph in section 7.1 and those conditions in 7.4 don't seem  
vague or hidden
to me (or to my in-house reviewers). If anyone has text he/she finds  
clearer than
'the NRA allows identification of unused/"in service" numbers' then  
please feel
free to propose it.

Usually the security section of an RFC concerns the security of the  
protocol
rather than the operational issues (I know - we have had comments on  
that with
other documents). That's why this important issue is the  
"operational" section.

If people (including the AD and IESG who have to read all this stuff)  
are happy
for this issue and its needed context/ explanation to be added to the  
security
considerations section as well then I'm happy.

-------------

Re. 7.4 cases 2 and 3 - This draft tries to cover all of the possible  
cases.
Where the CSP is not allowed to or will not provision each of the  
ENUM domains,
the alternative allows the Client to know what capability to try  
rather than guess.
The short answer is yes.

<CRUE>
With apologies to our esteemed co-chair, one option being considered  
in the UK for
"user" ENUM is a hybrid scheme (called CRUE, for Carrier Registration  
in User ENUM).
It is designed to allow carriers to indicate how "user" ENUM clients  
should process
calls. Provisioning in this Block domain allows a carrier to indicate  
to clients
that do not have access to private or infrastructure schemes how they  
should handle
a call that has no specific ENUM registration for the number queried.

In this scheme, the end user device (or PBX, or whatever) making a  
call wants to
handle that call using ENUM information, if available. This client  
decides what
to do with the call, not just relying on the the originating  
carrier's choices.
The ENUM client may well be interested in user ENUM data, taking into  
account
the called subscriber's choices for appropriate communications (Cases  
4 or 5).

Where there is no ENUM registration for a number (Cases 2 or 3) the  
carrier
can indicate its preferred treatment for calls to that block of  
numbers. This
bypasses the originating carrier, as that may well not be considering  
"user"
ENUM queries in its call processing.

Note - using this alternative and provisioning a record in the Block  
domain
is a choice on the part of the CSP. Likewise, performing the second  
query is
a choice of the client.

For more information on CRUE, come to the pub next Wednesday (see  
Jim's earlier
email :).
</CRUE>

For open number plans, using a similar technique is also interesting.  
The
registrant for a number in such a plan may well configure such a  
record the
apex of its zone, allowing calling ENUM clients to know what to do if  
the number
queried does not have special treatment - for example, to deliver the  
call to the
SIP AoR associated with a receptionist.
-------------

all the best,
   Lawrence

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

---

From: Jay Daley <[email-masked]>
Date: Tue, 16 Jan 2007 22:39:25 +0000

> For more information on CRUE, come to the pub next Wednesday (see 

Those of you who cannot make it can get the CRUE document here:

        http://download.nominet.org.uk/ENUM/CRUEv7.pdf

Jay Daley
Nominet UK

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 17 Jan 2007 14:48:11 +0100

After reading the mentioned CRUE document, I have some
comments:

Privacy:

CRUE says:

"3.2.2  Carrier identification in NAPTR

However OfCom have indicated one area of concern that needs to be
addresses by carriers intending to use 
this service.  Currently it is not possible to determine by simple
examination of a database whether a number 
has been ported and to whom it has been ported.  With this system this
may be possible by use of DNS 
lookups  and  cross-referencing  with  the  information  on  IP  address
allocation  held  by  Regional  Internet 
Registries.

OfCom are clear that it is not practical to completely prevent such
information exposure, but that suitable 
measures must be put into place to ensure that it is not trivial.  They
have therefore concentrated on the name 
of the server given in the SIP record.  If the name of the operating
telco is immediately obvious from reading 
the name (e.g. sip1.bt.com) then this is not acceptable, but if it is
not (e.g. sip1.internet.co.uk) then this is 
acceptable."

I think this is completely nonsense:

Since CRUE requires that all entries of a Carrier are the same,
one simple has to look up one number he knows which carrier it is,
Retrieve the domain name and then he looks up the number in question

This is not even secrecy by obscurity.

So you could as well enter bt.com in the first place.

So either these paragraphs are cancelled or CRUE cannot be implemented.

I also consider this a bit weird:

"4.  The data about a participating telco's SIP gateways will be public.
For security and operational 
reasons, most telcos choose not publish details of their interconnect
points and network topology. 
They may not even disclose this to other telcos."

Can one please explain to me how a telco may interconnect with other
telcos if they do not disclose details of their interconnection points
to them?

Ah, yes, use XConnect ;-)

Richard

> -----Original Message-----
> From: Jay Daley [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2007 11:39 PM
> To: IETF ENUM WG
> Cc: lconroy
> Subject: Re: [Enum] Re: Unused-00 - CRUE
>

---

From: Jay Daley <[email-masked]>
Date: Wed, 17 Jan 2007 14:30:46 +0000

Richard

> I think this is completely nonsense:

You are not alone.

> So either these paragraphs are cancelled or CRUE cannot be implemented.

If that is what the regulator wants then ...

> telcos if they do not disclose details of their interconnection points

CRUE by definition is within the public tree.  This means that anyone, not 
just telcos can see this information.

Jay Daley
Nominet UK

---

From: [email-masked]
Date: Wed, 17 Jan 2007 09:32:07 -0500

CRUE says:

   If the name of the operating telco is immediately obvious from
   reading the name (e.g. sip1.bt.com) then this is not acceptable,
   but if it is not (e.g. sip1.internet.co.uk) then this is
   acceptable."

Has anyone pointed out to these people that "internet.co.uk" *is* an
immediatly obvious identifier for a company?

   "4.  The data about a participating telco's SIP gateways will be
   public.  For security and operational reasons, most telcos choose
   not publish details of their interconnect points and network
   topology.  They may not even disclose this to other telcos."

The only way this can make sense is if "interconnect points" and
"network topology" refers to PSTN interconnects, not PSTN-to-Internet
interconnects.

Dale

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 17 Jan 2007 15:41:58 +0100

> "network topology" refers to PSTN interconnects, not PSTN-to-Internet

You forgot Internet-to-Internet Interconnection points.

The SIP URI in CRUE is to be used also for I2I interconnect

Richard

---

From: Jay Daley <[email-masked]>
Date: Wed, 17 Jan 2007 14:43:40 +0000

> immediatly obvious identifier for a company?

Yes.

---

From: Jim Reid <[email-masked]>
Date: Wed, 17 Jan 2007 23:43:15 +0000

On Jan 17, 2007, at 13:48, Stastny Richard wrote:

> After reading the mentioned CRUE document, I have some comments:

Until the CRUE document surfaces in this WG as an I-D I think it is  
out of scope for this list. Any followup discussion about the merits  
or otherwise of this scheme should take place elsewhere.

> I think this is completely nonsense:

So what?

> This is not even secrecy by obscurity.

Nobody is claiming it is "secure" or "anonymising". As far as the  
Regulator is concerned, obscuring the name of the sip server as  
proposed is good enough. [It raises a barrier that will deter the  
average citizen, but wouldn't make any difference to the tiny  
percentage of the planet that has a clue about how the internet  
works.] You Richard don't have to like it or implement CRUE, just as  
I don't have to like or implement the eccentricities of the Austrian  
telephone numbering plan. CRUE is a UK matter, at least in the first  
instance. If you want to improve that document, feel free to  
participate in UK ENUM meetings.

CRUE isn't even up for discussion in this WG yet: nobody's submitted  
a draft or proposed it as a work item.

> So either these paragraphs are cancelled or CRUE cannot be  

Richard, I humbly suggest you take these remarks elsewhere. As  
currently proposed, CRUE *has* been implemented and there is  
considerable interest from Communication Service Providers in the UK  
in using this scheme once commercial ENUM activities start under  
4.4.e164.arpa. So what you've said here is 100% wrong.

> telcos if they do not disclose details of their interconnection points

You have completely missed the point. All this section of the CRUE  
document does is illustrate one of the potential drawbacks of  
participating. Whether CRUE is or isn't used for interconnect is  
irrelevant. The idea was originally developed for an entirely  
different objective, namely bulk data population of 4.4.e164.arpa =>  
increased use of ENUM-aware software and services because lookups  
would be more likely to get meaningful data back from the DNS. That  
the data entered using CRUE *might* be used for interconnect or for  
SIP peering is fortunate side-effect.

Can we all now please shut up about CRUE and get back to commenting  
on enum-unused-03? Thanks.

---

From: Jim Reid <[email-masked]>
Date: Wed, 17 Jan 2007 23:46:24 +0000

> immediatly obvious identifier for a company?

<scarcasm on>
WHAT??? Do you mean someone can *do that* with a domain name?
<\scarcasm>