Subject: Re: [sipcore] draft-kaplan-sip-session-id-02

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Mon, 13 Jul 2009 13:12:11 +0200

Hello Hadriel, Dale,
Regarding the length of the session-id header field, is it really
necessary to guarantee global uniqueness and use 128 bits? The uses of
this new header field described in -02 are 'troubleshooting' and
'identity verification mechanisms', but troubleshooting will be
restricted to relatively short time period after which a session-id
value could be reused. Identity verification is not described but does
it require a globally unique session-id?

Troubleshooting is also the topic of my draft
http://tools.ietf.org/html/draft-dawes-sipping-debug-01, which is
similar to session-id but also describes how troubleshooting starts and
stops, and how entities determine when to add a header field for
debugging. According to session-id-02, the session-id header field is
present in all dialogs, which implies troubleshooting needs to record
everything, potentially at multiple entities some of which may not be
involved in the session being investigated, and then post-analyse for
the particular session that is targetted for troubleshooting. This seems
inefficient, or have I misunderstood?
 
Best Regards,
Peter 

Peter Dawes 
Group R&D
 
Tel: +44 (0)7717 275009
Fax: +44 (0)1635 234873

E-mail: [email-masked]
 
www.betavine.net  - Web
betavine.mobi  - Mobile Web
 
Vodafone Group Services Limited 
Registered Office: Vodafone House, The Connection, Newbury, Berkshire
RG14 2FN Registered in England No 3802001

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dale Worley
Sent: 24 June 2009 21:51
To: SIPCORE
Subject: [sipcore] draft-kaplan-sip-session-id-02

Looking at draft-kaplan-sip-session-id-02, the shorter the Session-Id
header is, the fewer complaints people will have about using it in
practice.  A couple of things could be done to shorten it:

- assign a single-letter abbreviation for the name

- use base64 rather than hex encoding

Base64 encoding reduces the header value to 22 characters from 32.

Dale

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: <[email-masked]>
Date: Mon, 13 Jul 2009 18:00:04 +0200

Peter,

we intend to use the Session-ID for traffic monitoring. 
Personally, I like the debug drafts a lot because it is a quite
efficient mechanism for detecting faults quickly but it covers quite
different scenarios than Session-ID. We discussed internaly what to use
and decided for Session-ID for following reasons: 

- The monitoring is done by a separate device, we don't use the logfiles
of the proxies. 
- We can not rely on end devices.  We already have a lot of end devices
in the field which do not have session-ID or debug-id implemented. First
SBC in the path has to insert the new ID. Also, the security people
whant to use the ID to trace attacks and we assume that the attacker's
clients will not insert the debugg-id. 
- We want to be able to correlate the messages end-to-end also if we do
not know in advance if we want to monitor a specific call. 
- The monitoring is active all the time. The security people want to be
able to look what happened in the past. So the global uniqueness
requirement makes sense for me. 
- The hashing is needed because we do not want the calle to see the
IP-address of the caller end most devices insert the IP-address in the
call-id.  

Kind regards
Laura

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dawes, Peter, VF-Group
> Sent: Monday, July 13, 2009 1:12 PM
> To: SIPCORE; Hadriel Kaplan
> Cc: Dale Worley
> Subject: Re: [sipcore] draft-kaplan-sip-session-id-02
> 
> Hello Hadriel, Dale,

---

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Wed, 15 Jul 2009 16:46:40 +0200

Hello Laura,
Thanks for the very interesting extra perspective. Does your traffic
monitoring solution pass all SIP signalling through this 'separate
device for monitoring', and does this device record all network activity
all the time? I ask because one thing that the session-id-02 draft does
not seem to help with is how you identity a particular session you are
interested in. Since session-id is very similar to Call-ID, it doesn't
seem very different from recording everything and then searching based
on Call-ID.
I agree with you that a solution should not rely on end devices,
although ideally end devices are included in troubleshooting. Draft
http://tools.ietf.org/html/draft-dawes-sipping-debug-01 also does not
rely on end devices (in 5.2 it says that the first proxy in the path can
insert the new P-Debug-ID header), but I should probably revise the
draft structure to make the responsibilities of each entity (UAC, Proxy,
UAS, etc.) clearer.  

Best regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 13 July 2009 17:00
To: Dawes, Peter, VF-Group; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [sipcore] draft-kaplan-sip-session-id-02

Peter,

Kind regards
Laura

> similar to session-id but also describes how troubleshooting starts 
> and stops, and how entities determine when to add a header field for

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 15:52:00 +0200

Peter,

Currently we have a B2BUA (instead of a proxy) and a PSTN gateway. 
One of the reasons for using a B2BUA is to avoid that the callee knows the IP-address of the caller.(This requirement came in from the guys dealing with security and privacy.) So, there are two different dialogs with two different Call-IDs on both sides of the B2BUA. 
  
The monitoring is done for every network element. All incomming and outgoing messages are written in logfiles by the monitoring system. These logfiles have nothing in common with the logfiles generated by the network elements. The logfiles are used: 
 1)by the operation people, to identify failures (debugging) 
 2)by the security people, to trace calls in case they suspect that user passwords were stolen. 
 3)for billing, as a verification in case of discrepancies between the DT accounting data and the accounting data of the customer ( private customers or other carriers)

In principle, we need a mean to convey the Call-ID of the A-side dialog in the B-side messages, in order to be able to corelate the A-side dialog with the B-side dialog. This is what the Session-ID does. Because we down't want the callee to know the IP-address of the caller, the B2BUA hashes the Call-ID before writing it in the Session-ID. The monitoring system has to know the hash key.  

Kind regards
Laura

> Sent: Wednesday, July 15, 2009 4:47 PM
> To: Liess, Laura; [email-masked]
> Cc: [email-masked]; Pinker, Gerold; [email-masked]; 
> Jesske, Roland; Hülsemann, Martin

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 17 Jul 2009 12:29:01 -0400

Hey Dale, inline...

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dale Worley
> 

That was asked for in the draft (see section 7.1).
 
> Base64 encoding reduces the header value to 22 characters from 32.

Is that 10 character savings really worth anything?  I guess I don't really care, either way.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 17 Jul 2009 13:07:31 -0400

Hi Peter, comments inline...

> From: Dawes, Peter, VF-Group [mailto:[email-masked]]
> Sent: Monday, July 13, 2009 7:12 AM
> 
> Hello Hadriel, Dale,

The draft mentions it could be used as part of an identity verification mechanism, but it's beyond the scope of the draft.  Really the draft is focused on the header value being useful for identification for troubleshooting purposes.  While a 16-byte value might seem overly large for such use, SIP sessions can last indefinitely, not just for a short duration; and since the value is a random one and can just by coincidence overlap with another from a different session (because each UA creates it), I thought it safer to error on the side of caution with 128-bit randomness.

> http://tools.ietf.org/html/c, which is

The Session-ID header-value is just there for any troubleshooting use - whether an operator/system actually chooses to debug a given session or not does not matter.  For example, I would expect (and have seen) probes/monitors used which collect all signaling and store it for long periods of time, for later analysis.  That analysis could be for troubleshooting, fraud investigation, whatever.  For example, the proposed SIP CLF format(s) tries to provide some correlation of messages on both sides of a B2BUA - this Session-ID allows one to do that as well in a CLF, or even with just a sniffer type trace without a CLF from the B2BUA.

With the draft-dawes-sipping-debug-01 concept, for example, you need to tell the UA what debug-id value to use, because you don't have a Session-ID header value at your disposal.  If you had one, you could just tell it to set a param to "true" or whatever, to indicate to proxies to generate logs for the message.  Right?  That way it's not some header-value only usable/available by a draft-dawes-sipping-debug-01 subscribe/notification mechanism in particular (which I think is one of only many ways to do debugging) - but rather a value which crosses B2BUA's/forks available for any debugging mechanism to use.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 17 Jul 2009 17:51:16 -0400

> Sent: Wednesday, July 15, 2009 10:47 AM

With regards to identifying a particular session you're interested in, I'm not sure if you mean that in the sense of:
    1) Once I know I want Session X, how do I find the messages for it? 
Or...
    2) How do I even decide Session X is what I want to log?  

The answer to the first question is: using the Session-ID.  And Session-ID is different from a Call-ID, purely because it gets through B2BUA's.  If you determine you want to find all SIP messages from a given Call-ID, you have to take into account that the Call-ID changes along the path.  Some of the devices change it due to security reasons, which is what I wrote http://tools.ietf.org/html/draft-kaplan-sip-secure-call-id-00 to try to avoid - but some devices change it for very different, unavoidable reasons.  You can record everything all day long, but you have to figure out what inbound dialog is associated with what outbound dialog(s) in the B2BUA's along the path, to actually troubleshoot it.  So Session-ID is to solve that problem.

For the question (2) semantically that is more of a "filter" question, than an identifier once the filter is triggered.  It's just asking "what filters do I want to use, in order to choose which calls to debug?"  In other words, deciding what session to analyze is a separate thing from identifying which messages are part of the same session.  In your debug draft, the "filter" is the set of things in the XML identified by the <start-trigger> and <stop-trigger> elements, for things like target URI's and time.  The debug draft just ties those together with the message identifier, so that it can only be done in real-time, and in a certain way. (I think)

-hadriel

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 17 Jul 2009 22:14:43 -0400

The Session-Id has a tremendous advantage over the "secure Call-Id":  In
a system that is not tightly managed by a central authority, middleboxes
have no way of knowing whether a UA is generating "secure Call-Ids" or
not.  So they must replace all Call-Ids, subverting the UAs that are
generating secure Call-Ids.  But (absent malice on the part of UAs),
Session-Ids are known to be secure, and middleboxes know not to replace
them.  So I think we should deprecate draft-kaplan-sip-secure-call-id in
favor of draft-kaplan-sip-session-id.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 19 Jul 2009 20:53:59 -0400

Hi Dale,
The thing is they're really trying to solve different things, though I know I didn't do a good job explaining it at the last WG meeting. :(

The secure-call-id is trying to provide a real Call-ID value which middleboxes won't change - for middleboxes that change it for the specific purpose of privacy or topology-hiding.  And by that I mean a real Call-ID: useful for dialog matching, the dialog-events package, and any of the things a Call-ID value is used in (there are many, as you know).

People put Call-ID values in all sorts of things, and expect it to work end-to-end, and are "surprised" when something in the middle changed them.  So secure-call-id is trying to provide a Call-ID that won't be changed by those middleboxes.  It *will* still be changed by other B2BUA's, for example many IP-PBX's and App Servers change the Call-ID, and will continue doing so.  It's ok that they do - most of the applications which use Call-ID's are targeted to those IP-PBXs/App-Servers, and they have some other reasons for changing them.

Session-ID is for something different: a session identifier which crosses any form of middlebox including real/full B2BUA's, but is not used for the dialog-matching type things a Call-ID is used for.  When I tried to use it for some of those other things, I got feedback with concern that it was subverting the Call-ID mechanism - if a B2BUA changed the Call-ID then it was unwise of me to try to second-guess it and bypass its replacement.  I agreed with that concern, so Session-ID is for troubleshooting purposes only at this time.

So the two mechanisms are not at odds, nor are they alternatives for the same thing.

A middlebox which replaces Call-ID's *does* know if it's a secure-call-id.  If it has no '@', and no IP Addr/hostname format in it, it's sufficiently benign to not change.

-hadriel

---

From: <[email-masked]>
Date: Mon, 20 Jul 2009 17:40:46 +0200

Hi Hadriel,

what could be the solution for the case that there is a concatenation of full B2BUAs? E.g. there are several App Servers, and the application is targetting the last App Server in the signalling path or respectively needs to match a certain dialog at this AS. I think even a secure-call-id won't be successfull here?

BR, Martin

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Hadriel Kaplan
> Gesendet: Montag, 20. Juli 2009 02:54
> An: Dale Worley; [email-masked]
> Betreff: Re: [sipcore] draft-kaplan-sip-session-id-02
> 
> Hi Dale,
> The thing is they're really trying to solve different things, 
> though I know I didn't do a good job explaining it at the 
> last WG meeting. :(
> 
> The secure-call-id is trying to provide a real Call-ID value 
> which middleboxes won't change - for middleboxes that change 
> it for the specific purpose of privacy or topology-hiding.  
> And by that I mean a real Call-ID: useful for dialog 
> matching, the dialog-events package, and any of the things a 
> Call-ID value is used in (there are many, as you know).
> 
> People put Call-ID values in all sorts of things, and expect 
> it to work end-to-end, and are "surprised" when something in 
> the middle changed them.  So secure-call-id is trying to 
> provide a Call-ID that won't be changed by those middleboxes. 
>  It *will* still be changed by other B2BUA's, for example 
> many IP-PBX's and App Servers change the Call-ID, and will 
> continue doing so.  It's ok that they do - most of the 
> applications which use Call-ID's are targeted to those 
> IP-PBXs/App-Servers, and they have some other reasons for 
> changing them.
> 
> Session-ID is for something different: a session identifier 
> which crosses any form of middlebox including real/full 
> B2BUA's, but is not used for the dialog-matching type things 
> a Call-ID is used for.  When I tried to use it for some of 
> those other things, I got feedback with concern that it was 
> subverting the Call-ID mechanism - if a B2BUA changed the 
> Call-ID then it was unwise of me to try to second-guess it 
> and bypass its replacement.  I agreed with that concern, so 
> Session-ID is for troubleshooting purposes only at this time.
> 
> A middlebox which replaces Call-ID's *does* know if it's a 
> secure-call-id.  If it has no '@', and no IP Addr/hostname 
> format in it, it's sufficiently benign to not change.
> 
> -hadriel
> 
> > The Session-Id has a tremendous advantage over the "secure 
> Call-Id":  
> > In a system that is not tightly managed by a central authority, 
> > middleboxes have no way of knowing whether a UA is 
> generating "secure 
> > Call-Ids" or not.  So they must replace all Call-Ids, 
> subverting the 
> > UAs that are generating secure Call-Ids.  But (absent malice on the 
> > part of UAs), Session-Ids are known to be secure, and 
> middleboxes know 
> > not to replace them.  So I think we should deprecate 
> > draft-kaplan-sip-secure-call-id in favor of 
> draft-kaplan-sip-session-id.
> > 
> > Dale
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 20 Jul 2009 17:09:59 -0400

Hi Martin, 

Correct - secure-call-id won't fix it if a B2BUA changes the Call-ID and something breaks due to that (because secure-call-id is a Call-ID).  

The other draft mechanism (session-id) tried to do that originally, but met with derision for not being able to fix everything possible in all cases. 

-hadriel

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 20, 2009 11:41 AM
> 
> what could be the solution for the case that there is a concatenation of
> full B2BUAs? E.g. there are several App Servers, and the application is
> targetting the last App Server in the signalling path or respectively
> needs to match a certain dialog at this AS. I think even a secure-call-id
> won't be successfull here?

---

From: <[email-masked]>
Date: Tue, 21 Jul 2009 09:43:53 +0200

Hi Hadriel,

but perhaps it would nevertheless be worth to describe the session-id mechanism as a solution for some problems under certain conditions. Perhaps also a recommendation can be included that because of the restrictions implementors should be careful when using it, and that it is only valid for certain network architectures.

BR, Martin

> Von: Hadriel Kaplan [mailto:[email-masked]] 
> Gesendet: Montag, 20. Juli 2009 23:10
> An: Hülsemann, Martin; [email-masked]; [email-masked]
> Betreff: RE: [sipcore] draft-kaplan-sip-session-id-02
> 
> 
> Hi Martin, 
> 
> Correct - secure-call-id won't fix it if a B2BUA changes the 
> Call-ID and something breaks due to that (because 
> secure-call-id is a Call-ID).  
> 
> The other draft mechanism (session-id) tried to do that 
> originally, but met with derision for not being able to fix 
> everything possible in all cases. 
> 
> -hadriel
> 
> > what could be the solution for the case that there is a 
> concatenation 
> > of full B2BUAs? E.g. there are several App Servers, and the 
> > application is targetting the last App Server in the 
> signalling path 
> > or respectively needs to match a certain dialog at this AS. I think 
> > even a secure-call-id won't be successfull here?
>

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 23 Jul 2009 15:04:44 -0400

On Sun, 2009-07-19 at 20:53 -0400, Hadriel Kaplan wrote:
> secure-call-id.  If it has no '@', and no IP Addr/hostname format in
> it, it's sufficiently benign to not change.

I see no reason to believe that -- sipXecs generates call-id's that have
no @ and not addr/hostname, but they're by no means random.

Moreover, the draft does not specify that call-ids with the specified
format MAY NOT be changed by middleboxes, so once middlebox vendors
realize my point in the previous paragraph, they'll start changing them.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 23 Jul 2009 17:53:13 -0400

> From: Dale Worley [mailto:[email-masked]]
> Sent: Thursday, July 23, 2009 3:05 PM
> 

It's not the property of being random that's really important - it's the property of not revealing the generator's identity - by which I mean its IP Address or hostname.  I.e., by looking at a Call-ID value that sipXecs sends me, can I discern its IP-addr/host?

Note: There is an argument by some that if it even reveals the vendor/model, then it's too sensitive, and obviously letting any word string be a Call-ID lets that happen - I am consciously ignoring that concern in the current draft's proposal, because I think the benefits outweigh the concern... but I'm slightly on the fence about that particular topic.

> realize my point in the previous paragraph, they'll start changing them.

Even if we define a new format, if the contents reveal something a middle-box doesn't want revealed (or really that their owner doesn't want revealed), there's nothing we can do to prevent it being changed.  BUT, the middlebox vendors do have an incentive not to change it, as much as they can.

-hadriel

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 23 Jul 2009 20:43:08 -0400

On Thu, 2009-07-23 at 17:53 -0400, Hadriel Kaplan wrote:
> It's not the property of being random that's really important - it's
> the property of not revealing the generator's identity - by which I
> mean its IP Address or hostname.  I.e., by looking at a Call-ID value
> that sipXecs sends me, can I discern its IP-addr/host?
> 
> 
> Note: There is an argument by some that if it even reveals the
> vendor/model, then it's too sensitive, and obviously letting any word
> string be a Call-ID lets that happen - I am consciously ignoring that
> concern in the current draft's proposal, because I think the benefits
> outweigh the concern... but I'm slightly on the fence about that
> particular topic.
>  
> 
> Even if we define a new format, if the contents reveal something a
> middle-box doesn't want revealed (or really that their owner doesn't
> want revealed), there's nothing we can do to prevent it being changed.
> BUT, the middlebox vendors do have an incentive not to change it, as
> much as they can.

In order to get value out of the proposed mechanism, we need to define
how a UA can generate Call-Ids that middleboxes won't (in practice) feel
the need to change.  If the proposal requires that the Call-Ids be
pseudo-random strings of a specified length and encoding, then
middleboxes truly don't need to change them, as they don't reveal
*anything*.  But we still have to get the middleboxes to have a
reasonably effective test for this situation, and then act on it.

As I see it, all of these aspects of the situation need to be addressed
in the draft, or otherwise it won't accomplish its purpose.

Dale

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 29 Jul 2009 17:11:55 +0200

Hi,

note that this draft proposes a new SIP header but it does not seem to 
update any of our core specs. Therefore, it would be better to discuss 
it on the DISPATCH WG's list.

Cheers,

Gonzalo
SIPCORE co-chair