Of course people are trying to make it work for E.164 -- that's the
entire point of draft-wing-sip-e164-rrc.
However, E.164 addresses that correspond to PSTN destinations pose their
own set of challenges that are similar to the issues I discuss below in
the "SIP and Return Routability of AORs" section. Most of these have to
do with the availability of multiple routes to the PSTN -- factor in
least-cost-routing logic and "carrier enum" deployments, and the chances
of routing back to the the exact same domain as the PSTN ingress appear
to become vanishingly small.
This highlights a point that I think is critically important -- there is
a huge, flashing,
jumping-up-and-down-naked-painted-safety-orange-from-head-to-toe-with-strobes-and-klaxons-strapped-to-your-head
difference between doing this kind of thing for E.164 numbers that
ultimately resolve to PSTN destinations, and doing this kind of thing
for E.164 numbers that ultimately resolve to IP destinations without
ever traversing the PSTN. In the latter case, dial-back mechanisms work
as well as they do with SIP addressing. In the former, I think the best
we can hope for, in terms of dial-back, is failure (due to the factors I
describe above). Which one were you asking about?
/a
Cullen Jennings wrote:
One questions about the scope of this work ... are people only trying
to make it work for email style address or is the scope to also try
for E.164 style addresses? I think it is important to be clear about
this when looking at any Forward Routing Verification or Return
Routing Verification type scheme. I also think in any identity scheme,
it's important to be clear what the trust relationship is between all
the sip elements.
On Nov 12, 2008, at 17:10 , Adam Roach wrote:
I've spent quite a bit of time over the past few days pondering the
approach laid out in the DERIVE draft. I think the approach of using
some form of "dial-back" to confirm identity has some merit (with a
few very strong caveats). I think the idea of leveraging
already-defined behavior is a good idea and somewhat clever; however,
I suspect that the exact mechanism defined in the current draft is
not yet well enough deployed for us to accept the limitations that it
imposes.
The Need For User-Visible Caveats
=================================
As we've seen with the XMPP system, dial-back approaches can be used
with a fair amount of success to prevent certain types of identity
spoofing (see XEP-0220). Caveats associated with this approach in
general include reliance on security of the DNS and IP routing
systems. We have seen real-world attacks on bot h in the past [1][2],
so we need to make sure that user expectations for any dial-back
system are set appropriately.
SIP and Return Routability of AORs
==================================
However, when the flexibility of SIP routing is thrown into the mix,
the ability to reliably route back to the calling user's specific
device using that user's AOR becomes a much larger issue.
For example, a caller at a call center my well advertise a calling
identity that reflects the contact point for that call center as
their "From" identity. However, calls made to that identity will
either reach an IVR or be dispatched to a random call center device
that has no knowledge of the calling party's dialog. Other normal
subscribed services, such as time-of-day routing, can have similar
results. Further, interaction with find-me-follow-me services -- or,
really, any service with serial forking -- can potentially result in
dramatic post-dial-delays that make execution of such a call-back
service infeasible.
All of which is to say: any dial-back attempt using an AOR may
legitimately reach a device (or several devices) without reaching the
calling party's actual device. I would therefore assert that any
dial-back based strictly on AOR can at best confirm the veracity of
the "To" header field (with the DNS and routing caveats I mention
above). It cannot, under any circumstances, *refute* a claim.
Dialog-Package Re-Use
=====================
The actual use of the dialog event package in the DERIVE draft is
clever. The idea of being able to deploy a system based on what is
already in the field is very attractive, as it allows us to put the
solution into play immediately. However, based on results at SIPits,
it is supported by somewhere less than 50% of current UA
implementations (the estimate I got was "probably about one out of
three").
That's actually not a bad percentage, especially considering that the
incidence of dialog package implementation should only go up -- it
has immense value in a number of useful services. However, the
behavior that the dialog event package needs to exhibit to support
DERIVE is not sufficiently well defined in RFC 4325. We've had a
number of SIP experts weigh in on the SIP mailing list with widely
differing opinions about how UAs *should* operate. And if *we* can't
figure it out, I can guarantee that implementors have done... let's
use the work "innovative"... things in this space.
In other words, I fear that whatever gains we achieve by re-using the
dialog event package are largely negated by the fact that we're using
the very aspects of it that have been most poorly specified.
Potential Alternate Approaches
==============================
If we don't re-use the dialog event package as-is, then we need to
either find some other widely-deployed, well-defined UA behavior that
we can leverage, or we need to define new behavior on both the caller
and callee equipment. I can't immediately think of a solution that
falls into the former category -- perhaps someone else can come up
with something clever. That leaves defining some new mechanism to
address a call-back mechanism. Jiri has suggest defining a new method
for call-back validation, and I think this is a reasonable approach.
Regardless of the approach taken, I would suggest that we should
leverage the use of public GRUUs to assist with routing to the proper
device. Devices that validate the identity of an incoming request can
render the public GRUU (with the ;gr parameter stripped) as the
calling party identity after they use it to reach the exact calling
device. With GRUUs thrown into the mix, we get around the issue of
potentially being unable to reach the calling party devices -- this
allows us to return actual negative hits in addition to positive hits.
In fact, if the calling party is using a GRUU, we might be able to
achieve some interesting results by taking the GRUU out of the
Contact header-field of the INVITE and sending back an innocuous
in-dialog request of some kind (UPDATE? OPTIONS? Dare I say INFO?)
*without* any route headers to see whether we get a 481 response...
Conclusion
==========
In short, I support work towards dial-back "better than nothing"
style security. And, while I commend the authors of DERIVE for their
ingenuity, I fear that the dialog event package is a poor enough fit
that we should explore other alternatives before going too far down
this path.
/a
[1]
http://arstechnica.com/news.ars/post/20080225-insecure-routing-redirects-youtube-to-pakistan.html
[2]
http://arstechnica.com/news.ars/post/20071212-dns-poisoning-used-to-redirect-unwitting-surfers.html
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
