Subject: [Sip] SIP Tracing Facility

From: "Dale Worley" <[email-masked]>
Date: Wed, 04 Mar 2009 13:28:33 -0500

I wrote up the "170" trace proposal as an I-D:

A new version of I-D, draft-worley-trace-00.txt has been successfuly
submitted by Dale Worley and posted to the IETF repository.

Filename:        draft-worley-trace
Revision:        00
Title:           SIP Tracing Facility
Creation_date:   2009-03-03
WG ID:           Independent Submission
Number_of_pages: 18

Abstract:
This document defines a SIP option tag, "trace", to be used within
SIP messages to request that SIP elements (both proxies and UASs)
that receive the message reflect to the UAC the request they received
and the response they gave by encapsulating the request and response
in a provisional response.  A new provisional response code "170" is
defined to carry the request and response.  This option tag is
expected to be used solely for diagnostic purposes.

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 05 Mar 2009 10:25:36 -0500

On Thu, 2009-03-05 at 08:16 +0000, Elwell, John wrote:
> What about non-INVITEs? Provisional responses are designed for INVITEs
> and I am not certain about their applicability to non-INVITEs.

Yes, provisional responses to non-INVITEs may be slightly out of
specification, but I don't expect any SIP element to malfunction if it
receives a provisional response to a non-INVITE request.  OTOH, I would
expect most uses of 'trace' to be attached to INVITEs, although that
makes me think that tracing an OPTIONS might be a useful test tool.

(Which leads to an unexpected observation:  RFC 3261 presupposes that
all non-INVITE responses are processed promptly, but in the face of
transport errors, this is not always so.  In sipX, we've adjusted
transaction handling so that if a re-send of a non-INVITE message is
seen the recipient sends a 100 to quench further re-sends.  It seems to
work exactly as expected, and noticeably reduces re-sends in situations
with transport errors.)

> In the case of INVITE, what about Contact? Is it permissible to send a
> 1xx (other than 100) without a Contact URI? RFC 3261 seems to indicate
> it is optional in a 1xx, but that might be solely to cater for omission
> in 100.

The Contact value of a 170 should never be used, so it doesn't really
matter if one is provided, or if it is usable.  OTOH, every SIP element
should be able to create a usable Contact URI.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 6 Mar 2009 12:05:19 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale
> Worley
> Sent: Thursday, March 05, 2009 10:26 AM
>

OPTIONS doesn't always get routed through the same path as INVITE, fwiw.

> work exactly as expected, and noticeably reduces re-sends in situations

I agree for most methods, but we've seen problems with 100 for the OPTIONS.  Some devices use the OPTIONS as a reachability ping/test, so sometimes the 100 makes them think the far-end is reachable even if they get a 408 later; in other cases some devices look for specific response codes to detect administrative out-of-service, for example a 500/503 to an OPTIONS sometimes is used for that, and sometimes they didn't code for the 100 Trying as being a possibility, so they see it and assume it's not out-of-service, and the 503 sent later doesn't get processed the same.  I consider these bugs/broken implementations, but just noting sending the 100 is not bug-free.

 -hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 6 Mar 2009 12:52:14 -0500

Hi Dale,

I appreciate that doing troubleshooting of SIP in SIP is very appealing, but I'm worried about it.  There are some real security issues with this, even if we don't want to admit it.  The reality is that if this trace mechanism is actually adopted by any sizeable measure, then middleboxes will be forced to munge the messages more than they already do, to prevent it from being used/work.  In other words it's a self-defeating mechanism.

Today you can do incrementing Max-Forwards traceroute, similar to the ICMP traceroute TTL trick, and even that's gotten some folks worried enough to make us munge the Max-Forwards value (despite the obvious dangers in doing so).  But anyway why isn't that type of trace enough for your needs?

Also, a couple specific questions/comments regarding this draft:

1) You use the term "final response" a couple times as being sent in the 170's body.  How would a final response be sent in a 170 response, since the 170 would be before a final response?

2) You state that a UAC should not create an early-dialog for the 170, but for any B2BUA in the path which did not know about this new trace mechanism, wouldn't it create early dialogs on the b2bua since it would treat it as a 183?

-hadriel

> Sent: Wednesday, March 04, 2009 1:29 PM
> To: SIP
> Subject: [Sip] SIP Tracing Facility
>
> _______________________________________________
> 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: Eric Burger <[email-masked]>
Date: Fri, 6 Mar 2009 12:59:38 -0500

Wouldn't SIP-CLF be a better way to go?

On Mar 6, 2009, at 12:52 PM, Hadriel Kaplan wrote:

> Hi Dale,
>
> I appreciate that doing troubleshooting of SIP in SIP is very  
> appealing, but I'm worried about it.  There are some real security  
> issues with this, even if we don't want to admit it.  The reality is  
> that if this trace mechanism is actually adopted by any sizeable  
> measure, then middleboxes will be forced to munge the messages more  
> than they already do, to prevent it from being used/work.  In other  
> words it's a self-defeating mechanism.
>
> Today you can do incrementing Max-Forwards traceroute, similar to  
> the ICMP traceroute TTL trick, and even that's gotten some folks  
> worried enough to make us munge the Max-Forwards value (despite the  
> obvious dangers in doing so).  But anyway why isn't that type of  
> trace enough for your needs?
>
>
> 1) You use the term "final response" a couple times as being sent in  
> the 170's body.  How would a final response be sent in a 170  
> response, since the 170 would be before a final response?
>
> 2) You state that a UAC should not create an early-dialog for the  
> 170, but for any B2BUA in the path which did not know about this new  
> trace mechanism, wouldn't it create early dialogs on the b2bua since  
> it would treat it as a 183?
>
> -hadriel
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 6 Mar 2009 13:09:22 -0500

Yes that's what I was thinking too - for basic connectivity check type things, do SIP ping/traceroute.  To troubleshoot actual proxy and UA behavior issues, retargeting issues, perform any type of root-cause, etc., you need logs and there's just no getting away from that.  And only the authoritative administrator of each SIP device can (and *should*) be able to get such info.

The real question is whether we can (or could) provide standardized ways of helping admin's get the info they need.
And I think that is actually a really good topic for a BOF, or at least a discussion on RAI-DISPATCH.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Burger
> Sent: Friday, March 06, 2009 1:00 PM
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 06 Mar 2009 12:27:43 -0600

Hadriel Kaplan wrote:
> Yes that's what I was thinking too - for basic connectivity check
> type things, do SIP ping/traceroute.  To troubleshoot actual proxy
> and UA behavior issues, retargeting issues, perform any type of
> root-cause, etc., you need logs and there's just no getting away from
> that.  And only the authoritative administrator of each SIP device
> can (and *should*) be able to get such info.
> 
> The real question is whether we can (or could) provide standardized
> ways of helping admin's get the info they need. And I think that is
> actually a really good topic for a BOF, or at least a discussion on
> RAI-DISPATCH.

Funny you should mention a BoF.  Eric has also suggested that we
hold a Bar BoF to discuss sipping-clf.

I am modifying sipping-clf based on Dale's extensive comments
from the last round and from other comments received.  It
will be submitted before the Monday deadline and we can think
of holding at least a Bar BoF on this.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Dale Worley <[email-masked]>
Date: Wed, 25 Mar 2009 00:04:23 -0400

> Wouldn't SIP-CLF be a better way to go?

Not really, because log files slice the universe of data the wrong way.
A log file tells everything that happens at a particular element, almost
all of which is irrelevant regarding a particular transaction.

Transaction tracing is to extract the data relevant to a particular
transaction, across all elements that handle that transaction.  In many
cases, the person doing the trace is not and should not be authorized to
see the log of the elements the transaction traverses -- but they should
be authorized to see what happened to that one transaction.

Dale

---

From: Dale Worley <[email-masked]>
Date: Wed, 25 Mar 2009 00:13:00 -0400

> words it's a self-defeating mechanism.

Yes, there should be a mechanism so that a transit network can make
itself appear to be a wire, to be one hop, with regard to the trace
mechanism.  But there is no reason that the routing on the *far side* of
a transit network should be hidden from the UAC -- at least, from the
point of view of the transit network, the far-end network might have
policies.

(I'm envisioning a world in which the UAC's end may be involved in
complex service provisioning in which there may be more than one transit
network and more than one element that provides complex call routing.
Though a transit network should be able to hide its internal structure,
the UAC has the right to know what element the transit network delivered
the request to, since that is what the UAC is paying the transit network
to do.)

> Today you can do incrementing Max-Forwards traceroute, similar to the
> ICMP traceroute TTL trick, and even that's gotten some folks worried
> enough to make us munge the Max-Forwards value (despite the obvious
> dangers in doing so).  But anyway why isn't that type of trace enough
> for your needs?

I envision sending 20 INVITEs to the same request-URI, with gradually
increasing Max-Forwards values.  Any UAS that can be reached in less
than the maximum number of hops will get hammered.

And, as you say, SBCs are already trying to prevent that.

> the 170's body.  How would a final response be sent in a 170 response,
> since the 170 would be before a final response?

Clearly, the 170 would have to be formulated after the final response is
formulated.  But I don't see any particular prohibition on that, and
there isn't any real restriction in the order that responses are sent.

> 2) You state that a UAC should not create an early-dialog for the 170,
> but for any B2BUA in the path which did not know about this new trace
> mechanism, wouldn't it create early dialogs on the b2bua since it
> would treat it as a 183?

I suppose it would.  Which would be somewhat resource-inefficient.  But
I don't expect the fraction of requests that are traced to be over 0.1%,
so it shouldn't be a problem in practice.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 25 Mar 2009 03:29:58 -0400

> From: Dale Worley [mailto:[email-masked]]
> Sent: Wednesday, March 25, 2009 12:13 AM
> 

IMO the UAC has no right to know any such thing.  It has no rights - it's not a human.  The calling human has a right to know the far-end called human it got delivered to.  But they don't care nor have a right to know the *host* element it got delivered to, or host elements it forked to but did not succeed at, etc.  It's none of their business, frankly.

And if we're thinking the far-end terminating Enterprise or provider will want to tell some originating Enterprise or provider what's going on inside their network, well... once again we all live in different worlds. :)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Mar 2009 11:09:51 -0400

> And if we're thinking the far-end terminating Enterprise or provider will want to tell some originating Enterprise or provider what's going on inside their network, well... once again we all live i…

I think Dale's point is that it should not be the business of the 
transit network to prevent the UAC from learning things about the path 
after it leaves the transit network.

If the UAS network doesn't want that divulged, then fine. But if it is 
willing to have it divulged, then that should be fine too.

A really good example of that is when the UAC and UAS networks are 
branches of the same organization, that use a sip service provider for 
their interconnect.

	Thanks,
	Paul

---

From: Vijay Gurbani <[email-masked]>
Date: Wed, 25 Mar 2009 10:38:14 -0500

> Not really, because log files slice the universe of data the wrong way.

Not as much wrong as different; i.e., log files slice the universe of
data a different way.

> all of which is irrelevant regarding a particular transaction.

Depends.  If that element is misbehaving -- either through flawed source
code or because of external influences -- the state of a transaction
preserved in a log file from the point of that element is of extreme
interest for analysis.

However, as you note, log files do not help in dynamic tracing
of the transaction across a set of elements.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 25 Mar 2009 14:24:44 -0400

> of the transaction across a set of elements.

As we both understand, the two mechanisms slice the universe of data in
different ways, which are most useful for attacking different problems.

What makes the problem more complex is that different elements have
different owners, and one can reasonably say that the UAC-owner can look
at the action of a proxy in regard to one of the UAC's requests, but not
have the right to examine the proxy's full log.

Conversely, taking the intersection of the two questions, a log file
format should record at least enough information about a transaction as
you would want in a trace facility.

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 25 Mar 2009 14:34:15 -0400

On Wed, 2009-03-25 at 03:29 -0400, Hadriel Kaplan wrote:
> IMO the UAC has no right to know any such thing.  It has no rights -
> it's not a human.  The calling human has a right to know the far-end
> called human it got delivered to.  But they don't care nor have a
> right to know the *host* element it got delivered to, or host elements
> it forked to but did not succeed at, etc.  It's none of their
> business, frankly.
> 
> And if we're thinking the far-end terminating Enterprise or provider
> will want to tell some originating Enterprise or provider what's going
> on inside their network, well... once again we all live in different
> worlds. :)

I'm sure we live in different worlds.

But there are considerable situations where the UAC's owner, or the
enterprise or service provider supervising the UAC has rights to know
quite a bit.  The obvious case is when the owner has contracted with the
transit network to provide particular intelligent routing services --
they're going to want to be able to verify that the transit network is
performing as contracted.

To construct a more interesting case, one that will be a reasonable
business case within a year or two:

- a UAC within an enterprise network
- a transit network from the enterprise to a provider of intelligent
call routing
- the provider of intelligent call routing
- another transit network from the provider to a destination enterprise
- a UAS within the destination enterprise network

Each of the last 4 operations may want to hide the details of its
network, but the originator of the call should have the right (assuming
that it's contracting for these services) to monitor the four
connections between these networks.

Dale