Subject: [Enum] Re: Access controls on URI end points

From: "Stastny Richard" <[email-masked]>
Date: Thu, 23 Jun 2005 09:42:04 -0400

Hi Jim (and Patrik),
 
>Richard, I have read RFC3764. What you've quoted above is different
>from what I was talking about. It is of course right and proper for SIP
>servers (or whatever) to insist on authenticating and validating their
>clients by whatever means they choose: secret handshakes, certificates,
>SSH keys, etc. etc. Access filters typically block incoming traffic
>based on the source address. This was what Michael was (indirectly)
>referring to. In these cases the filters prevent clients from speaking
>to the servers so the clients don't get the opportunity to authenticate
>themselves to those servers.

The problem you are talking about goes much further then ENUM.
It is the general problem of the NGN to use IETF protocols and also
part of the Internet Infrastructure on one side, but basically do not
want to be connected really. So what we have is:
- SIP Proxy not allowing you to connect
- SIP proxy filtering addresses
- Domain names reserved but not resolving (e.g. ims.3gppnetwork.org)
- "Public" IP not reachable from the Internet
etc.
 
I strongly recommend to read the publicly available GSMA document
IR.65 IMS Roaming and Interworking Guidelines, especially section 8,
to understand the problem they have:
 
http://uk.sitestat.com/gsm/gsmworld/s?IR65_ims_roaming&ns_type=pdf&ns_url=[http://www.gsmworld.com/documents/ireg/ir65.pdf]
 
first and then the text I posted this week on the TISPAN WG4 mailing list:
 
------snip-----
 
Dear all,

Coming back from Stockholm, I re-read the public GSM-A document
IR.65 "IMS Roaming & Interworking Guidelines" and here especially
Section 8 "Addressing and Routing"

So I would like to get some questions answered from
GSMA and also how TISPAN is dealing with these issues?

In Section 8.1 "User addressing" is clearly stated:

>In addition to private used identity, every IMS user has one or
>more public user identities. The public user identity is used in
>e.g. user-to-user communication. For example, it might be
>included on a business card."

If I can include a PUI sip:richard.stastny at sonera.fi
on my business card, I expect it
to stand there alone and not with a footnote stating:
*) to be used only in A1/Vodafone/mobile IMS/TISPAN NGN/etc.
I expect it to be usable in PUBLIC like an e-mail address.

Q1, This implies that access from the Internet TO IMS is needed,
how is this achieved?

Q2. How is the public DNS accessed from within an IMS network?

This two questions should be added to the issues in WG4TD18.

>Public user identities can be used to identify the user's
>information within the HSS. Format of public user identity
>is either SIP URI (RFC 3261&
RFC 2396) or the "tel:"-URI format (RFC 2806), for
example sip:clint.eastwood at acme.org or tel: +358405344455."

>From the example given and other text one may come to the conclusion
that IMS networks may host two types of Public User Identities:

A non-portable PUI in the form sip:user at sonera.fi
A portable PUI in the form sip:clint.eastwood at acme.org

The latter option is very interesting because it requires
a hosting of a user provided domain name with the operator
This could be achieved by providing SRV records in the users
domain pointing to a X-CSCF? On the public Internet.

There is only a BIG problem here, not only for
acme.org type PUI, but even for sonera.fi type PUI
as stated later in Section 8.4 "Interworking Specific
Issues":

>IMS interworking needs additional support regarding used domains,
>since recipient belonging to another operator is addressed with
user->friendly public user identity such as mickey.mouse at sonera.fi
instead
>of mickey.mouse at mnc123.mcc456.3gppnetwork.org.
>Originating operator needs to be able to route INVITE SIP request
towards >recipient's I-CSCF based on only this sonera.fi domain.
Therefore there
>has to some method mapping sonera.fi domain and the corresponding
I-CSCF
>IP address. Logically this method would be DNS, but this is a bit
>problematic.

A BIT problematic? Is it? Now it comes:

>Public DNS likely cannot be used in this, since I-CSCF
>IP addresses should not be available in public Internet. GRX DNS can
>neither be used, since GRX DNS should not be used to resolve public
>domains such as sonera.fi.

Again a Catch 22 ;-)

So if this even does not work for sonera.fi, how can one expect
this to work for acme.org? You cannot use public DNS, and you cannot
use GRX either.

The proposed ways out of this problem are problematic even
for sonera.fi, they are impossible for acme.org:

>There are some ways to solve this DNS usage issue; all of these require

>the originating operator maintaining some kind of system by itself to
>support IMS interworking.

Back to de-centralized management of all domain names?

>This kind of distributed functionality is needed, since GRX DNS itself
>should not handle .com type of domain names.

Logically, because this would just shift the problem of maintaining
a separate complete DNS system

>Main issue is to route all IMS inter-operator related queries to
>stay within the operator community (i.e. use only inter-operator DNS
>hierarchy), thus Internet DNS should be queried only in the case
>of traffic destined to external networks.

Ok, that means a split horizon in GRX for all sonera.fi's, and
nice to hear that THERE IS a way to query the Internet DNS. The
question is only how this is done, because above this is excluded.

>Three ways to solve this issue:
>* Use operator's internal DNS (or other database) to store
>statically configured information mapping domain to I-CSCF IP
>address (not recommended due to amount of manual labour needed
>in configuring this static information)

Good that this is not recommended.

>* Better solution would be to use a dynamic query, where each
>operator would deploy a "private operator DNS server", that replies
>with correct I-CSCF IP address when another "private operator DNS
server"
>queries it. Addresses of these operator DNS servers itself
>would be stored in e.g. IR.21 database
>Implementing this does not necessarily require additional equipment,
>for example the existing operator DNS server that is needed anyway
>due to e.g. GPRS roaming, can be reused for this purpose. Benefit of
>using this is reducing the number of static mappings to just one thus
>reducing management efforts and also handling of domain names becomes
>easier

I do not understand this, can anybody please explain. I only have
the impression that this does not solve the acme.com problem either

>* Third possible solution uses domain name rewriting by adding
>"mncXXX.mccYYY.gprs" to the domains that need to be resolved
>(e.g. operator.com => operator.com.mnc123.mcc456.gprs), therefore
>making these public domains resolvable for the GRX DNS. Rewriting
>can be done by the CSCF using internal rewrite lists mapping used
>public domain name and the corresponding MNC & MCC. But a better
>solution is to utilize NAPTR (Naming Authority Pointer Resource Record
of >DNS, RFC 3401-4) domain rewrite rules in the local operator DNS
>If DNS solution is used, then CSCF sends a query for DNS concerning
>the public domain to be resolved. DNS reply contains the rewritten
>domain name, fetched from the domain specific NAPTR field. Supporting
>this kind of functionality means that each operator would maintain a
>list of its IMS partners in its local DNS
>Note: The operator should register the domain used in public user
>identity in order to prevent any problems.
>Also, it might be beneficial if operators could agree on the used
>domain model for IMS public user addressing, e.g. ims.operator.com.
>However, various different domains can be handled, as long as everybody
is >aware of which domain belongs to which operator. For example, these
>domains could be listed in IR.21 database.

I also do not understand this proposal in detail, but it also works
only for known operator names such as sonera.fi and not for acme.com

>Since operator.com type of domains can exist also in public Internet,
>care is needed with domain queries in order to avoid mixing these two
>separate issues. For example it might be possible for IMS user to
connect >also to fixed line SIP clients, therefore this fixed line
recipient
>(such as elvis.presley at graceland.com) needs to be discovered by
utilizing
>normal public internet DNS queries. One solution could be to first
check
>every outgoing domain with internal mapping mechanism and if no I-CSCF
is
>found, then query this domain from public internet DNS and route it
there.

Now this is an interesting one, because here at least outbound calls
to other "operator domains" such as "sip:elvis.presley at graceland.com"
are mentioned, so

1. Again you need to access the public Internet DNS and
2. you also need to interconnect with the public Internet
outbound.

This raises the minor question how to "call back" into the IMS,
This loops back to my first question raise
This implies that access from the Internet TO IMS is needed,
how is this achieved?

Best regards

Richard

Richard Stastny
OeFEG
tel:+43 664 420 4100
enum:+43 780 203 211
callto://fordprefect
http://voipandenum.blogspot.com

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 Jun 2005 18:32:40 -0400

On Jun 23, 2005, at 06:44, Stastny Richard wrote:
- Domain names reserved but not resolving (e.g. ims.3gppnetwork.org)
I have no problems with domain names not resolving, but I have  
problems when the PUBLIC tree for ENUM, e164.arpa, include  
delegations by NS or non-terminal NAPTR point to records that do not  
resolve.

I.e. the only ones that should resolve such names are the ones that  
can resolve them. Timeouts in DNS is a bad thing.

   paf