Subject: Re: [Sip] draft-kuthan-sip-derive

From: Adam Roach <[email-masked]>
Date: Wed, 12 Nov 2008 18:10:16 -0600

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 Nov 2008 23:38:10 -0700

On Oct 26, 2008, at 15:10 , Juha Heinanen wrote:

> Hannes Tschofenig writes:
>
>>> pai does not help if you receive a request from anywhere on
>>> the internet.
>>
>> Depends a bit on what you call "YOU receive".
>
> if you cannot trust the proxy or ua you receive the request from, pai
> header has no value.
>
> -- juha

+1

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 Nov 2008 23:54:35 -0700

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:

> 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.
>
>
> 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.
>
>
> 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.
>
> 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.
>
> 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
> =====================
>
> 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.
>
>
> 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.
>
> 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.
>
> 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  
> 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

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 13 Nov 2008 05:27:49 -0800

>for E.164 style addresses?

I can't help remembering how hard it was for network designers to give up SNA addressing (at that time used for 80%-90% of the data networks) for IP addresses.

Is anyone really thinking there are new, future applications and services that may use E.164?
If so, it would be interesting to know what they may be. An example would help.
Sure, there is the huge installed base of E.164, but so was SNA.

This is not a valid reason to reject Derive.
In this light, the limitations of Derive are very acceptable IMO.

Henry

On 11/13/08 12:54 AM, "Cullen Jennings" <[email-masked]> wrote:

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Nov 2008 18:39:08 -0600

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:
>> 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.
>>
>>
>> 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.
>>
>>
>> incidence of dialog package implementation should only go up -- it 
>> has immense value in a number of useful services. However, the 
>> 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.
>>
>> 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.
>>
>> Contact header-field of the INVITE and sending back an innocuous 
>> in-dialog request of some kind (UPDATE? OPTIONS? Dare I say INFO?)

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 14 Nov 2008 15:06:14 +0100

Hi Adam,

thank you very much  -- that's been most helpful indeed and I agree
with pretty much all the points. I would highlight the scope and
the actual verification mechanisms.

I think that the scope, better-than-nothing, which just works with
the same infrastructure, as for INVITE delivery, and makes on
particular trust assumptions, begins to be agreeable.

I agree too the actual verification mechanism, is difficult to agree
upon. For now,I would resort to listing how such can differ from each
other:
- it it E2E (i.e., without any support in the network)
   -- that's obviously the objective
- does it work with existing UA implementations, at least with
   some? That's desirable, not sure if really feasible.
- if it leans on some existing SIP extensions, are these specified
   in a way that the scenario can unambiguously lean upon? (unfortunately
   not the case with dialog package)
- does it work for requests that don't establish dialogs (preferably
   yes)
- can it deal with forking?

So far I have heard further suggestions for using some combination of
OPTIONS, dialog authorization, or even a new method -- but we haven't
really yet tested those hard.

Also the applicability is a key  aspect -- reverse routability
agreeably being the most important one (apart from latency, security
assumptions such as uncompromised DNS). I think the general
approach is to explain that positive assertions are useful, negative
don't give much, and document examples of when it fails, possibly
accompanied by remedy suggestions:
- unregistered UAC, UAC with call forwarding, anonymous UAC: don't do it :)
   (possibly offer to retry)
- B2BUA: if you break it you fix it
- tel URI .... perhaps resolving to IP if possible?
- shared URI ....
- UAC's proxy forwarding SUBSCRIBEs somewhere else...
- 3pcc...

-jiri

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 14 Nov 2008 14:17:34 +0000

Jiri, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jiri Kuthan
> Sent: 14 November 2008 14:06
> To: Adam Roach
> Cc: SIP IETF; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [Sip] draft-kuthan-sip-derive
> 
> Hi Adam,
> 
[JRE] This is a pointless exercise if it can't be deployed without
fixing SIP intermediaries that are out there at present, and many of
these are B2BUAs. This is similar reasoning to that which says that it
has to work with the majority of UAs out there at present. There has to
be a good chance of the mechanism working in the majority of
inter-domain situations, and sadly that will nearly always involve
B2BUAs of some form, and sadly this means a lot of things in SIP
messages get changed. We can't do much about B2BUAs that are
deliberately trying to stop things working, but we should at least try
to take account of B2BUAs that are going about their legitimate
business. Otherwise this will be yet another SIP RFC that never or
rarely gets deployed.

John

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Nov 2008 17:55:26 -0800

> business. Otherwise this will be yet another SIP RFC that never or

Let's steal a pagebook from the PSTN, circa the early 1990's, when
disable-echo-cancellation tones were introduced.  As everyone probably
remembers, they were necessary for the >9600bps modems and fax machines.  At
the time, no PSTN equipment understood the disable tones so nobody could use
their fancy 14.4kbps modem at 14.4kbps.  But as time went on more PSTN
equipment understood the disable tones and eventually you could almost always
get a >9600bps speed connection.  It did not happen overnight, and did not
happen immediately.  People that bought the faster modems were often unhappy
they could not use the faster speed.  But the specification was written,
intermediaries (Service Providers) agreed it caused them no harm, eventually
the intermediary equipment understood the disable-echo-cancellation tones.
Briefly, world hunger was solved.

If that situation doesn't ring with some familiarity, there are many other
situations where where intermediaries had to upgrade in order for the end user
to benefit:  unleaded gasoline; airport runways long enough for passenger
jets.  I'm sure more creative people can think of other situations where this
worked well.  Obviously there are zillions of counter examples as well (e.g.,
hydrogen powered cars are not viable due to insufficient numbers and poor
distribution of hydrogen fueling stations; supersonic flight over continents
is not viable because the people living on the continent do not generally
enjoy the supersonic boom).

-d

---

From: Hendrik Scholz <[email-masked]>
Date: Sat, 15 Nov 2008 11:54:24 +0100

Hi!

How would the TDM interworking work?
Look at 'Figure 1: Overview of Operation' and assume this:

- Call SIP->PSTN

The callee is in the PSTN/TDM world and proxy 2 acts as
a gateway.
In this case the callee would never send a SUBSCRIBE.
If there is no authentication/authorization for the call
the gateway may opt to subscribe to the user?

- Call PSTN->SIP

The caller is on the TDM side and proxy 1 acts as a PSTN to SIP
gateway. The callee sends the SUBSCRIBE which ends up at
the edge on proxy 1.
What should the proxy do?
a) Respond on behalf of the caller
b) do not support the Dialog event package and respond
    with 489 to the SUBSCRIBE
c) do some magic based on information conveyed on the
    TDM side?

Cheers,
  Hendrik

-- 
Hendrik Scholz <[email-masked]>

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 16 Nov 2008 23:53:53 +0100

> enjoy the supersonic boom).

Hi Dan and John,

I actually do have a counter-example which makes me a bit worried -- NATs.
(not meaning to disagree ... just trying to understand the evolution cycle)
Think of IP addresses in application payload with NATs. That appears 
remarkably
similar as reference to a call in SUB/NOT in DERIVE, which -- if not 
translated
by the B2BUA that translates it in callid/to/from header-field -- will fail.
Obviously ignoring NATs didn't work quite well.

I would tend to be pragmatic and like to make DERIVE B2BUA-resilient, I'm
just failing to see how. If a UA can be smart and robust enough to deal
with strange things in the network, why don't we do that. The problem is
really I don't see a clear way of doing that. To my best knowledge, there
is not a single piece of SIP message which a B2BUA would guarantee to
deliver to the other party. The notion of B2BUA is largely unspecified
in its behaviour.

We could try to guess a behaviour of a "resonable B2BUA". For example we
could assume that if we don't put dialog references in payload (e.g. by 
using
an in-dialog new-method IS-IT-YOU request), the dialog reference will be
translated like for the initial INVITE and things will work.

So in summary these are IMO the options to deal with it:
a) ignore B2BUA traversal in anticipation if they break something,
    they will be motivate to fix it
b) align the design to something we guess has a better chance
    to get through B2BUAs without a normative reliance on their
    behaviour (but what could it be???)
c) in addition to a/ or b/, do B2BUA-BEHAVE :)

Aside from architectural and evolution arguments on both a and b, does 
anyone
have an opinion on what can safely get through the B2BUAs?

-jiri

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 16 Nov 2008 22:36:57 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiri
> Kuthan
> Sent: Sunday, November 16, 2008 5:54 PM
> To: Dan Wing
>

Audio.  :)
Whatever you choose, don't use the call-id or tags.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 16 Nov 2008 23:28:32 -0600

> I actually do have a counter-example which makes me a bit 

I've heard about them.

> Aside from architectural and evolution arguments on both a 
> and b, does anyone

RTP, after the call is set up.  Everything else is problematic 
to varying degrees.

If SBC vendors and SP see it is possible to provide (some sort
of) "identity", while still preserving the reasons they deploy
SBCs, they will do it.  Especially when spammers start stealing
identities and reducing the effectiveness of whitelists beause
of those stolen identities.

-d

---

From: Dean Willis <[email-masked]>
Date: Mon, 17 Nov 2008 00:01:00 -0600

>> have an opinion on what can safely get through the B2BUAs?

Maybe. Sometime they transcode, which can mess things up.

--
Dean

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Mon, 17 Nov 2008 14:02:31 +0100

> Maybe. Sometime they transcode, which can mess things up.

Or they just mix different RTP streams

-- 
Victor Pascual Ávila

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 17 Nov 2008 14:19:56 +0100

> Whatever you choose, don't use the call-id or tags.

:)

well, this is really guessing which can be quite brittle but isn't dialog
id safer? For lot of other things to function, it must be translated
consistently from A to X on one side and X to A in the reverse direction,
mustn't it? So that using some method with same callid/tags as the tested
INVITE should get to the same place?

-jiri

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Nov 2008 08:25:04 -0500

> From: Dean Willis [mailto:[email-masked]]
> >
> > Audio.  :)
>

I said "audio" - not RTP, not codec.  And sure the volume and frequency may be changed a bit.  Just talk slowly and calmly. ;)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Nov 2008 08:40:51 -0500

> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Monday, November 17, 2008 8:20 AM
>

Oh I don't think I'm guessing.  I'm pretty sure there's a large population of B2BUA's that will change the call-id and tags when requests go through them.  SBC's for example, but not just SBC's - lots of App/feature Servers too.

They will "fix" them for requests within that dialog, or some vendors can fix them for requests outside the dialog but only if the request flows through them or through another box in the same network.  In your case you can't send the return-check in-dialog ('cause that would be pointless presumably).  And you wouldn't even want to send it with a pre-loaded route-set of the received call attempt's path, because that would also be pointless.

And even if they get to the same set of b2bua's, you have to hope they each will "fix" the call-id_tags embedded in the body content of your check message to match the ones from the original INVITE, which is more than just normal "fixing" of the call-id+tags in the normal SIP headers.

So if you use the call-id+tags its chances of success are slim if there are b2bua's.  Of course it could be that your mechanism is popular enough that the b2bua's decide to add support for fixing it - like the Replaces header in REFER transfer cases was sufficiently popular to make b2bua's auto-fix the dialog info in them eventually.  Or it could end up like S/MIME.  Or you could choose to ignore b2bua's altogether.  Or you could pick something else to use for verification.

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 17 Nov 2008 14:04:45 +0000

> Sent: 17 November 2008 13:20
> To: Hadriel Kaplan
> Cc: Dan Wing; 'Adam Roach'; [email-masked]; 'SIP 
> IETF'; [email-masked]; Elwell, John; 
> [email-masked]; [email-masked]
> and b, does
[JRE] It requires the B2BUA to modify the contents of the SUBSCRIBE and
NOTIFY bodies. If B2BUAs would do this, that would work. The problem I
see is that a non-compliant B2BUA might act as UAS for the SUBSCRIBE
request and send back a NOTIFY with its own dialog information. It only
proves that the call has come from that B2BUA, which doesn't mean much.
How does the callee UA distinguish this unhelpful case from the helpful
case where the SUBSCRIBE request has been relayed all the way back to
the caller's UA (or at least the caller's domain) and the NOTIFY comes
from there? I guess it falls back to using RFC 4474 to sign the NOTIFY
request. But then a NOTIFY request signed by the local domain's B2BUA is
unhelpful, and a NOTIFY request from the caller's UA or its domain
proxy/B2BUA would have its signature broken by intervening B2BUAs. So we
are back where we started.

I suppose we have two seemingly incompatible requirements:
- it must work through any "reasonable" B2BUA behaviour in such a way
that the callee UA can detect whether e2e return routability has been
achieved;
- it must work without modifications to existing caller UAs.

If it is indeed impossible to satisfy both requirements, then which of
these is more important?

John

---

From: Adam Roach <[email-masked]>
Date: Mon, 17 Nov 2008 08:12:03 -0600

On 11/17/08 7:40 AM, Hadriel Kaplan wrote:
> Or you could pick something else to use for verification.

Such as...?

/a

---

From: Raphael Coeffic <[email-masked]>
Date: Mon, 17 Nov 2008 15:15:40 +0100

> If it is indeed impossible to satisfy both requirements, then which of
Obviously the former. But we might end-up designing a B2BUA traversal 
mechanism to exchange either the original call-id, or some other piece 
of information. IMO, the principle of DERIVE might be kept, even if we 
are using something else as the dialog event package. The key is that we 
need something to correlate on.

Raphael.

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 17 Nov 2008 15:25:29 +0100

Hadriel Kaplan wrote:
> Oh I don't think I'm guessing. 

I was referring to myself, when I mean guessing :)

>  I'm pretty sure there's a large population of B2BUA's that will change 
the call-id and tags when requests go through them.  SBC's for example, 
but not just SBC's - lots of App/feature Servers too.
> They will "fix" them for requests within that dialog, or some vendors can fix them for requests outside the dialog but only if the request flows through them or through another box in the same netw…

Messages with some dialog-id but not in-dialog could get translated
consistently but supposedly they will break just because of such an
unusual message constructions anyhow.

> So if you use the call-id+tags its chances of success are slim if there are b2bua's.  Of course it could be that your mechanism is popular enough that the b2bua's decide to add support for fixing i…

P-Charging-Vector? :)

-jiri

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Mon, 17 Nov 2008 16:12:54 +0100

> And even if they get to the same set of b2bua's, you have to hope they each will "fix" the call-id_tags embedded in the body content of your check message to match the ones from the original INVITE…

One could use the Target-Dialog header [RFC4538] and include there the
original dialog-ID. Could this safely get through a B2BUA?
-- 
Victor Pascual Ávila
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Mon, 17 Nov 2008 09:17:34 -0600

>> Or you could pick something else to use for verification.

The as-yet-undocumented Globally Unique Call Control Identifier, or  
"GUCCI" . . . It's just like the Call-ID, but SBC's don't change it  
(yet) because they don't about it (yet). Of course, that will change  
once the RFC is published and some crazed operator beats their SBC  
vendor into implementing a GUCCI updating algorithm. I predict that  
this "feature" will be managed under the codename "Paris spring  
fashion show", but that's not important right now.

What IS important is that we understand that no such feature can be  
made to work with an SBC that is actively disrupting it. We already  
wrote specs that said "Don't do this", and they did it anyhow, so why  
should we expect them to cooperate the next time? Rational or not,  
there are reasons for most of this behavior.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Mon, 17 Nov 2008 09:24:22 -0600

On 11/17/08 9:17 AM, Dean Willis wrote:
> made to work with an SBC that is actively disrupting it.

And that's my point. Hadriel stood up and effectively said "SBCs break 
everything. If you want identity to work, you need to find something 
that SBCs don't break."

My understanding of set theory is somewhat rudimentary, but I am fairly 
certain that the inverse of the universe is the null set, and that the 
intersection of the null set and anything else will always be the null set.

So, unless you can point out the flaw in that logic, then the only 
progress we can make is by ignoring SBCs and hope they catch up.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Nov 2008 10:32:31 -0500

> From: Adam Roach [mailto:[email-masked]]
> Sent: Monday, November 17, 2008 9:12 AM
>

Either a new header or a new parameter.  We seem to be getting this requirement a lot lately in various SIP-related WG's: we need some unique per-call identifier thingy that crosses b2bua's without change.  I propose we just standardize one, but avoid making it have any property which made changing call-id value's a necessity. (like don't put addressing info in it, and don't make it a dialog match criteria in the state machine, etc.)  I was planning to submit a draft to do that before the deadline, but was too busy.

It would require the UA's to change to support it if you want to use it for Derive, but somehow I don't really believe a significant market share of deployed UA's support the rfc4235 subscribe dialog-package yet either (despite Sipit's poll).  And I think we'd have uses for a logical call-id not in Call-ID.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Nov 2008 10:57:04 -0500

> Sent: Monday, November 17, 2008 10:24 AM
>

Actually, I'm pretty sure I said *B2BUA's* change the Call-ID and tags, and that there were far more than just SBCs.  Honestly, most every box I see traces from appears to be a b2bua of some form or other these days. (of course that's probably because of the types of networks my product's in to begin with, so it's a myopic view I know)  Some of these b2bua's change the call-id+tags, some don't.

> progress we can make is by ignoring SBCs and hope they catch up.

The set of the universe is not germane to the issue at hand.  Many B2BUA's change call-id+tags; that says nothing about whether they change other things.  And it says nothing about their motivation for the changes.

SBC's cannot "catch up" to not change call-id's - it's what their owners want them to do.  Speaking as just one vendor, we don't change call-id's and tags by *default*.  Virtually EVERYONE changes that default behavior and configures us to change the call-id and tags as soon as they install the system.  That doesn't mean they will change anything no matter what - they have specific motivation for changing the call-id.  The IETF SIP WG gave them that motivation, by putting an IP Address in it.  That was a mistake.  It was a big mistake.

-hadriel

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Mon, 17 Nov 2008 17:06:44 +0100

Hendrik,

> c) do some magic based on information conveyed on the

This is a limitation. IMO the GW could handle it for you in a useful
way but I see two issues:
- Different GWs might be used for the incoming INVITE and the outgoing
SUBSCRIBE requests
- Transitive trust (you do need to trust the GW)

Cheers,

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Nov 2008 11:11:58 -0500

> Sent: Monday, November 17, 2008 10:18 AM
>

There are reasons people change Call-ID's, and reasons people change To-URI, From-URI, contact-URI, SDP, etc.  Absolutely.  If you need some mechanism Foo, and the purpose or use or syntax of Foo goes against the wishes of the owner of an SBC, then be prepared for Foo to not work or be changed.  That is kinda the point of an SBC after all: control.

When it comes to a "call identifier string", which is unique for each high-level "call", I don't think that goes against the wishes of most SBC owners, or B2BUA owners.  It just can't identify the IP-Address/hostname/port of the UA or anything really, should not be a URI, should not be in a body, and should not be overly long.

-hadriel

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 17 Nov 2008 17:18:58 +0100

> progress we can make is by ignoring SBCs and hope they catch up.

I'm afraid that's the best conclusion we can make indeed.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 17 Nov 2008 20:53:18 +0100

> How would the TDM interworking work?

There are some limitations indeed -- if a gateway calls a SIP phone,
and supports DERIVE, DERIVE actually asserts "can I reach *a gateway
you are momentarily using*" (as opposed to say "I can reach you via
your address"). Still I think that's meeting the "better-than-nothing"
expectation offered by DERIVE. If we wanted to get closer to the caller,
we would have to dig in the PSTN protocols.

There is a practical and IMO worse concern: a telephone number can resolve
to way too many places: SIP routing is not symmetric in this case and
pstn-2-sip request can take a different path than sip-2-pstn request. Thus
a verifier can very likely end up with a different GW than the one
which initated the call in question. (If the phone number is offered
in From as tel URI, one could for example try to perform an ENUM
query with non-e164 result but I'm not sure it make sense -- in the end,
if there is such URI it could have been put in From straight).

> the gateway may opt to subscribe to the user?

that's the best we can get, without PSTN interaction the
gateway has to act on the party's behalf.

> c) do some magic based on information conveyed on the

It does not have to be the proxy, it can be the gateway but the
real problem is IMO if the SUBSCRIBE gets there at all. If it
gets there, I think a) is the appropriate answer. (or b) if
it does not support DERIVE). c) is apparently a difficult one.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 17 Nov 2008 21:19:08 +0100

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? 

(based on Adam's note that there is a nuance between e.164 numbers and
PSTN destinations)....
I don't think we can realiably cover PSTN destinations, primarily because
of asymmetric routing -- there are too many UASs that can serve a PSTN
destination.

> 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.

I think it should be important feature of DERIVE that it makes minimum
assumptions about trust. Managing trust relationships is IMO equaly or
more prohibitive than putting security protocols in place and I hope we
can accomodate scenarios that are happy with  better-than-nothing without
trust models. (Apart from trust in uncompromised DNS and IP).

-jiri

>> I suspect that the exact mechanism defined in the current draft is not 
>> "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 
>> Further, interaction with find-me-follow-me services -- or, really, 
>> any service with serial forking -- can potentially result in dramatic 
>> 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

---

From: Raphael Coeffic <[email-masked]>
Date: Mon, 17 Nov 2008 22:10:57 +0100

> When it comes to a "call identifier string", which is unique for each high-level "call", I don't think that goes against the wishes of most SBC owners, or B2BUA owners.  It just can't identify the…
Something like a UUID (www.ietf.org/*rfc*/*rfc4122*.txt)? I don't think 
there is any privacy or topology relevant information in it.

-Raphael.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Nov 2008 16:38:40 -0500

> From: Raphael Coeffic [mailto:[email-masked]]
> Sent: Monday, November 17, 2008 4:11 PM
>

Yup, but using one of the algorithms not based on the host MAC.
And we'd need a header, like "Session-ID", or "B2bua-Pwn3d".
:)

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 17 Nov 2008 21:46:48 +0000

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 17 November 2008 15:57
> To: Adam Roach; Dean Willis
> Cc: [email-masked]; 'SIP IETF'; 
> [email-masked]; [email-masked]; Elwell, 
> John; Dan Wing; [email-masked]
> Subject: RE: [Sip] draft-kuthan-sip-derive
> 
> 
> Actually, I'm pretty sure I said *B2BUA's* change the Call-ID 
> and tags, and that there were far more than just SBCs.  
> Honestly, most every box I see traces from appears to be a 
> b2bua of some form or other these days. (of course that's 
> probably because of the types of networks my product's in to 
> begin with, so it's a myopic view I know)
[JRE] funny you should say that - my eyesight seems to be suffering in
the same way.

John

> > intersection of the null set and anything else will always 
> be the null
> > set.
> The set of the universe is not germane to the issue at hand.  
> Many B2BUA's change call-id+tags; that says nothing about 
> whether they change other things.  And it says nothing about 
> their motivation for the changes.
> 
> SBC's cannot "catch up" to not change call-id's - it's what 
> their owners want them to do.  Speaking as just one vendor, 
> we don't change call-id's and tags by *default*.  Virtually 
> EVERYONE changes that default behavior and configures us to 
> change the call-id and tags as soon as they install the 
> system.  That doesn't mean they will change anything no 
> matter what - they have specific motivation for changing the 
> call-id.  The IETF SIP WG gave them that motivation, by 
> putting an IP Address in it.  That was a mistake.  It was a 
> big mistake.
> 
> -hadriel
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 17 Nov 2008 21:47:50 +0000

> Sent: 17 November 2008 15:33
> To: Adam Roach
> Cc: Jiri Kuthan; Dan Wing; [email-masked]; 'SIP 
> Either a new header or a new parameter.  We seem to be 
> getting this requirement a lot lately in various SIP-related 
> WG's: we need some unique per-call identifier thingy that 
> crosses b2bua's without change.  I propose we just 
> standardize one, but avoid making it have any property which 
> made changing call-id value's a necessity. (like don't put 
> addressing info in it, and don't make it a dialog match 
> criteria in the state machine, etc.)  I was planning to 
> submit a draft to do that before the deadline, but was too busy.
> 
> It would require the UA's to change to support it if you want 
> to use it for Derive, but somehow I don't really believe a 
> significant market share of deployed UA's support the rfc4235 
> subscribe dialog-package yet either (despite Sipit's poll).  
> And I think we'd have uses for a logical call-id not in Call-ID.
[JRE] In fact SIPIT showed 16% support for the dialog event package, but
there is no analysis of how many of these were UAs that supported the
package as notifiers, as opposed to subscribers. My suspicion is that
the population is small. Requiring support for something like a unique
call identifier, plus a simple event package to confirm its presence,
would probably be no more onerous than requiring support for the dialog
event package as notifier.

John

---

From: Raphael Coeffic <[email-masked]>
Date: Mon, 17 Nov 2008 21:54:32 +0100

> Yup, but using one of the algorithms not based on the host MAC.
Version 4 shall be mandated (see section 4.4 in RFC4122).
> And we'd need a header, like "Session-ID", or "B2bua-Pwn3d".
Or maybe as DTMF mixed into the audio stream at the beginning of the 
session ;-)

-Raphael.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 17 Nov 2008 16:31:34 -0600

> event package as notifier.

Be careful how you use measurements like that 16%. Note that the same
measurement at the previous SIPit was 28%. My rough feel is that about
1/3 of the UAs around now have or are in the process of implementing
this package.

I can't clarify right now how much of those act as servers. Based on  
casual
conversations, I expect that we'll find its most of them. I'll ask in  
more detail
at my next opportunity.

RjS

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 17 Nov 2008 18:43:36 -0600

> if there is such URI it could have been put in From straight).

This isn't a concern, though.  Even if the return routing worked
perfectly and you got back to the very same PSTN gateway, the
best you can achieve is trusting the caller-id asserted by the
PSTN.  Which can be spoofed, as we all know.  So, DERIVE to
an E.164 that terminates on a PSTN gateway can't tell you too
much; DERIVE to an E.164 that terminates on a SIP UA can be
pretty worthwhile.  I admit that a PSTN gateway could lie and
pretend to be a normal SIP UA; thus, a DERIVE validation of
an E.164 isn't as trustworthy as a DERIVE validation of an
email-style SIP URI because the PSTN gateway could lie.

If we had a way to determine who 'owns' an E.164, we could
make that owner prove they received the DERIVE query (by
asking them to encrypt something with their private key), 
which prevents a PSTN gateway from lying.  This is something 
that could be bolted on later, if/when we figure out how 
to map an E.164 to certificate that 'owns' it.

-d

---

From: Hendrik Scholz <[email-masked]>
Date: Thu, 20 Nov 2008 02:52:39 +0100

Hi!

> original dialog-ID. Could this safely get through a B2BUA?

Section 2 of RFC4538 states:
"
This header field contains the dialog identifiers for the
INVITE dialog between user agents A and B, composed of the Call-ID,
local tag, and remote tag.
"

While this could go through a B2BUA/SBC in most cases the config
would be to remove/change this as it contains the Call-ID.

My two cents are on Hadriel's Session-ID.

Hendrik