Subject: [Enum] VOVI draft enumservice 'voice:sip' - and there's more

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sat, 8 Mar 2003 22:49:41 +0000

Hi Jon, folks,
   I've put this as a separate posting as it has a different purpose and
strictly may be out of scope for the IETF - it's just to explain why we
bother with this enumservice, even though it is, apparently, contentious.

Consider this scenario:
A company has a mixed voice infrastructure with "steam 'phones", gateways,
and SIP "hard phones", plus the Registrar/Proxy and firewall/ALG sub-systems.
These are all under the administrative control of the Telecomms group in the
Facilities department.

None of the employees are allowed to register ANYTHING with this Proxy other
than these SIP phones; to do so is treated as "Gross Industrial Misconduct".

AoRs assigned to the 'phones and Registered with this Proxy are made available
through the company's ENUM entries. Note - these are AoRs, NOT the contact
addresses of the 'phones themselves. Such contact addresses would be of
little use, as the 'phones are NATTED and visible to the "outside world"
only via the ALG that is part of the voice infrastructure (and under
control of the Telecomms group).

The employees can use the I.T. department's proxy to register their
SIP-based IM programs. These breach the firewall at a separate ALG
(under the control of the I.T. department). The employees are assigned
-separate- IM identities (AoRs) through the I.T. department Proxy/Registrar.
Company rules do NOT allow employees to use company connections for voice
or video calls other than those provided by the company and going through
the Telecomms group systems.

I agree that it is possible to combine more than one AoR at a third party
SIP provider. However... Much as I've tried, it isn't easy to explain to
I.T. departments that this is not a bad thing, and that potential incoming
forking behaviour from external INVITEs is not a sign of a DoS attack -
remember, these are the same folk that believed that being slashdotted
was a sign of an intentional cyberattack, and pulled the plug. You
might think that a strange reaction, but I couldn't possibly comment.

Not only am I not a lawyer nor play one on TV, I am not a Personnel /
Human Resources specialist, and do not understand the logic here - I
take it as a given.

Thus the company has personnel and I.T./Telecomms policies (not subject
to any technical standardisation that I understand) that mean that the
'voice' account WILL only have voice capable devices associated with it.
There are no protocol features involved in this, just the threat of
dismissal if employees break the rules - IMHO, a pretty effective
constraint.

I suggest that this is not an uncommon scenario, and that indicating
'voice:sip' in the NAPTR holding an AoR "provided by the Telecomms
group", with a separate NAPTR indicating 'im:sip' with an AoR "provided
by the I.T. department" is valid and may be useful; if these ENUM records
are presented to a human being, then they can select the entry accordingly.

I'm sure I speak for all of the authors in agreeing that publishing
SIP contact addresses in ENUM is a BAD and EVIL THING; to be honest I
hadn't even considered it until it was mentioned as a possibility.
In this example, all of the SIP URIs published in ENUM would be full
AoRs. They would have an implied capability simply through the company's
choice of systems configuration, and enforcement of policies.

Finally, in the above scenario, the constraints are not technical
but administrative and the reasons for two accounts are bureaucratic.

I'm happy to explain to potential customers that they don't need this
separation; I'm happy to show that they can probably same money with
a combined system. The I.T. department might not have to deal with
a W2K Server and ALG, or the Telecomms group might come to love W2K.

However, I'm not in a position to tell a potential customer that they
can't have a system that fits their bureaucratic designs just because
it's unnecessary.

At least in the Real World we now have web servers and file servers
managed by the same group - things do change.

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 9 Mar 2003 01:02:18 -0500

Some more below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
> Sent: Saturday, March 08, 2003 2:50 PM
> To: [email-masked]; Rudi on the road; 
> [email-masked]
> Cc: [email-masked]
> Subject: VOVI draft enumservice 'voice:sip' - and there's more
> 
> 
> Hi Jon, folks,

I wonder about what this policy is supposed to accomplish, but we'll return
to that later.

> control of the Telecomms group).

As an aside, I'd draw your attention to the considerable amount of work that
has been done recently on the SIP concept of 'globally routable contact
addresses'. These are needed for numerous conferences and transfer-control
applications when devices use private IP address space. Anyway, just because
a phone has been NAT'd does not mean that its contact addresses are of no
use. These GRCA systems allow a lot of control to proxy operators, etc, and
are probably a good solution to problems along these lines.

> the Telecomms group systems.

Deep in this is the capital-"P" Problem that I suspect has motivated a lot
of the confusion about the need for these enumservices. Let's grant the AoR
for Telecomms for a particular user is [email-masked]', and their AoR
for I.T. is [email-masked]'. Two different AoRs, as you say.

You say that company rules do not allow employees to use connections other
than those provided by the company. Fine. It is, however, possible to
register the AoR [email-masked]' as a contact address under
[email-masked]'. Astonishingly enough, the Telecomms proxy would not
even be able to distinguish whether a SIP request for [email-masked]'
had gone through the IT proxy or not (unless IT had some out-of-band way of
notifying Telecomms of this, say). A request that goes through the IT proxy
first will look like any other request for [email-masked]', and would
have the same security properties; no firewall circumvention would occur, or
anything like that. Registering an AoR under another AoR is almost always
the SIP solution for these problems. The user then distributes
[email-masked]' as their AoR for ENUM and any other purposes, so
incoming requests will go to Telecomms or IT as appropriate.

Now, if you introduce another constraint that the IT department also will
not allow anything but SIP-based IM programs to register at their proxy
(again, the enforceability of which is questionable), even that admits of a
SIP solution. A single REGISTER request can contain multiple contact
addresses which could include both the device URI for the IM program and the
AoR for Telecomms. If, finally, you say that IT will not allow contact
addresses for anything but a single device URI representing an IM program,
then you might have a real policy deadlock, and a third-party AoR would be
necessary.

More on the Problem in a minute...

> might think that a strange reaction, but I couldn't possibly comment.

Well, sending a single INVITE to two places isn't exactly slashdotting. I'm
surprised it would even be a detectable condition, especially since IT and
Telecomms have separately administered systems.

A more important question is what IT departments have to do with a
third-party AoR. If you go get an iptel.org SIP URI, IT doesn't have to know
about it or change their behavior in any way. They just receive SIP
requests; the requests won't say that their Request-URI was learned at
iptel.org. Your company doesn't have to do anything to support your IT AoR
or Telecomms AoR being registered under iptel.org. 

Think of it like hyperlinking - by having a globally-reachable SIP AoR on
the Internet, you're essentially doing something like putting up a web page.
The question of whether somebody gets to your page by entering the URL into
a browser application, or by clicking a link on another page, or by being
redirected from another page, is more or less unanswerable by the operator
of the page - they just get requests. In SIP, it is even more invisible than
it is in HTTP - a redirect server (which I believe is how iptel.org works)
leaves no trace of itself in subsequent requests. It is literally impossible
for IT to detect or do anything about the fact that a client got their SIP
URI from iptel.org. It would be no different than if they'd found the SIP
URI on a web page or business card.

Concerns that the above is not the case have often seemed to motivate
arguments for multiple enumservices since all of this started. This property
about how SIP registrations and proxy/redirection work is also what makes
policies about registration seem absurd to me. It would be like if you had a
globally-reachable web page up on your companies web site, and your company
would fire you if you linked to that page from an external site, or
something. It's a globally-reachable page - it's there to be reached! The
idea that an Telecomm department's proxy, say, would not allow you to have a
registration for your IT AoR as a matter of policy is like saying that your
Telecomms department would not let you have a web link from your
globally-reachable Telecomms web page to your globally-reachable IT group
web page. In short, it's ludicrous. What problems is this policy supposed to
prevent? Considering this for a few minutes, I can't come up with a single
plausible answer to that question.

Finally, it's important to point out that this sort of linking has no
security implications whatsoever. Just because you learned the Telecomms AoR
from the IT AoR or iptel.org doesn't mean you have any privileges at
Telecomms. The Telecomms systems would treat your request like any other
request - challenging and authorizating it as necessary. It goes through the
same firewalls either way, and so on.

Anyway, it's not strange that IT departments are conservative, and I can
imagine there are enterprises that are not comfortable with SIP and that
might believe all kinds of crazy things. What is strange is that you for
some reason think putting the two AoRs in ENUM would not result in the same
behavior from IT's perspective as putting the two under a third-party AoR.
More on this below...

> are presented to a human being, then they can select the entry
accordingly.

A number of things about this:

First: what phone number for ENUM? Your PSTN steam-phone number? Or some
personal number of yours? If it's the company's phone, then they are the
assignee, and they decide what goes in your ENUM record, right? Given their
ultra-paranoid policies about SIP registrations, I find it very hard to
believe that they would not apply similar constraints to ENUM. This kind of
begs the question of what their policies with regard to SIP were meant to
prevent that ENUM does not allow.

The question is, what's the non-technical difference between putting these
AoRs in ENUM and registering them in a single SIP AoR? From an
administrative perspective, these are identical concepts. If you put both
AoRs in ENUM, someone can suck them up and spit out requests at either.
Sure, a user who is calling you might select entries according to advertised
capability, and only send appropriate requests to each, but then again, they
might not - just because I receive a 'voice:sip' ENUM record does not mean I
cannot offer video or IM in the SDP of my requests. Putting these AoRs in
ENUM does not prohibit anyone from sending any sort of SIP request at either
of them. Much more stringent policies could be enforced, incidentally, at
the IT or Telecomms SIP proxy server if the AoRs were composed there, unlike
the DNS which dumps all of the relevant records in the client's lap. Putting
them in ENUM can and will lead to all the behaviors you sounded worried
about above - 'incoming forking behavior from external INVITEs', and so on,
especially if I have a multiservice client.

Once the URIs are in the DNS, they are both fair game. Nothing about the
URIs says 'I got these from ENUM'. So what was it, exactly, that IT and
Telecomms wanted to prevent by prohibiting certain SIP registrations that
they do not enable with ENUM?

If you personally control the ENUM record (it's for some personal number of
yours, maybe your cell-phone number), I think the same parallels arise, but
it's more comparable to the iptel.org AoR. You have some external
composition of the work AoRs in an offline system that isn't under the
control of IT or Telecomms. They are similarly unable to determine whether
or not your ENUM record was accessed to learn their URIs, or whether they
came from iptel.org, or whether the client's user pulled the URIs from some
agony column in the Guardian. Nor does it have any impact on policy one way
or another whether or not the client did. Certainly, any justification to
punish you for composing the AoRs at iptel.org would also be justification
to punish you for doing so in ENUM.

> choice of systems configuration, and enforcement of policies.

Okay... but... I'm really not sure how "vovi" works without contact
addresses unless you're messing with SIP, as my other mail suggests. I agree
that you're talking about AoRs in this mail, but your talking about AoRs
with some sort of bizarre policy constraint. Policy constraints, however,
doth not implementation standards make. The fact that someone -could- deploy
a device in a policy-constrained environment in which the "vovi" standards
make some sense would be no argument to standardize them, especially since
the standard can be used outside of that environment, and that environment
entails non-standard SIP behavior. In any event, I think the environment
described above can also be realized without "vovi", as I hope I
illustrated, and I would further contend that it can be better implemented
without "vovi" (because stricter authentication-based policies at SIP
proxies can govern the distribution of requests to devices).

> but administrative and the reasons for two accounts are bureaucratic.

Agreed, but it's not at all clear what the policy is meant to accomplish, or
what it's implications to ENUM would be.

> can't have a system that fits their bureaucratic designs just because

Different criteria, however, may be applied to standards. Not all that is
implemented is standardized. Also, there's the question of whether or not
your specific enumservices are actually necessary to satisfy the
bureaucratic requirements (not to mention - what are those requirements?).