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

[<[e-mail]>]

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



  

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Dawes, Peter, VF-Group
> Sent: Wednesday, July 15, 2009 4:47 PM
> To: Liess, Laura; [e-mail]
> Cc: [e-mail]; Pinker, Gerold; [e-mail]; 
> Jesske, Roland; Hülsemann, Martin
> Subject: Re: [sipcore] draft-kaplan-sip-session-id-02
> 
> 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: [e-mail] [mailto:[e-mail]] 
> Sent: 13 July 2009 17:00
> To: Dawes, Peter, VF-Group; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: [sipcore] draft-kaplan-sip-session-id-02
> 
> 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
>  
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] 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,
> > 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: [phone]
> > Fax: [phone]
> > 
> >  
> > E-mail: [e-mail]
> >  
> > 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: [e-mail] [mailto:[e-mail]] 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> > 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>