Subject: Re: [dispatch] Proposed charter for work on logging

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 13 Jun 2013 11:17:36 +0000

Hello All,
Following on from the comments at IETF#86 (http://www.ietf.org/proceedings/86/minutes/minutes-86-dispatch), where there was mild support for working on logging, I have updated the log me requirements draft with 3 potential solutions (in clause 7) which can meet the requirements (http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-02.txt). Opinions and comments on these or any other potential solutions would be very welcome.

It was commented at IETF#86 that a security analysis is needed so I would like to understand if any scenarios exist with potential security threats in order to add them to requirements. In many cases, a network simply logs the signalling that passes through it so no new security issues are created. Collecting end-to-end logging for signalling that crosses multiple networks must not compromise security or privacy, but I would expect networks to remove any security sensitive fields before forwarding signalling regardless of whether that signalling is of interest to logging. Also, as far as I can see no final decision was made whether INSIPID could be a home for the logging topic. I think INSIPID would be a good working group to discuss a log me indicator since troubleshooting is one possible use of session-id.

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: 10 March 2013 17:26
To: [email-masked]
Subject: Re: [dispatch] Proposed charter for work on logging

Peter has suggested a minor modification to the charter text (which he also plans to make to the abstract of the requirements document).

   SIP networks use signalling monitoring tools to diagnose user
   reported problem and for regression testing if network or client
   software is upgraded.  As networks grow and become interconnected,
   including connection via transit networks, it becomes impractical to
   predict the path that SIP signalling will take between clients, and
   therefore impractical to monitor SIP signalling end-to-end.

   This work will provide for adding an indicator to the SIP
   protocol which can be used to mark signalling as of interest to logging.
   Such marking will typically be applied as part of network testing
   controlled by the network operator and not used in regular client
   signalling.  However, such marking can be carried end-to-end
   including the SIP terminals, even if a session originates and
   terminates in different networks.

The change is in the 2nd paragraph, changing "subject to" to "of interest to".

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of DRAGE, Keith (Keith)
> Sent: 15 February 2013 22:08
> To: [email-masked]
> Subject: [dispatch] Proposed charter for work on logging
> 
> Peter Dawes has submitted
> 
> https://datatracker.ietf.org/doc/draft-dawes-dispatch-logme-reqs/
> 
> as a set of requirements that will work with the session identifier 
> produced by the INSIPID working group to enable identification of 
> loggable sessions.
> 
> The INIPID WG did consider this work, but considered it was out of 
> scope of the work they are currently chartered to do.
> 
> I propose the following scope for DISPATCH to consider based on the 
> Abstract of the above document.
> 
>    SIP networks use signalling monitoring tools to diagnose user
>    reported problem and for regression testing if network or client
>    software is upgraded.  As networks grow and become interconnected,
>    including connection via transit networks, it becomes impractical to
>    predict the path that SIP signalling will take between clients, and
>    therefore impractical to monitor SIP signalling end-to-end.
> 
>    This work will provide for adding an indicator to the SIP
>    protocol which can be used to mark signalling as subject to logging.
>    Such marking will typically be applied as part of network testing
>    controlled by the network operator and not used in regular client
>    signalling.  However, such marking can be carried end-to-end
>    including the SIP terminals, even if a session originates and
>    terminates in different networks.
> 
> 
> Milestones
> 
> Dec 2013	Requirements for marking SIP sessions for logging to IESG
> (Informational)
> Mar 2014	Protocol for marking SIP sessions for logging to IESG
> (Proposed standard)
> 
> I would note that the work does not necessarily need a new working 
> group, it could for example be an extension of the work of either the 
> SIPCORE WG or the INSIPID WG, but that is for the discussion to decide.
> 
> Your comments and proposals for revision are welcome.
> 
> For information there have been a number of previous documents on the 
> subject, but these might or might not form part of the proposed 
> solution, particularly given that some of them predate the INSIPID work.
> 
> http://tools.ietf.org/html/draft-dawes-sipping-debug-id-01
> http://tools.ietf.org/html/draft-dawes-sipping-debug-event-01
> http://tools.ietf.org/html/draft-kaithal-dispatch-sip-log-information-
> 00
> http://tools.ietf.org/html/draft-dawes-sipping-debug-05
> http://tools.ietf.org/html/draft-dawes-dispatch-debug-00
> http://tools.ietf.org/html/draft-kaithal-sipclf-sip-log-information-00
> 
> 
> Regards
> 
> Keith
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 13 Jun 2013 16:22:54 -0500

On 06/13/2013 06:17 AM, Dawes, Peter, Vodafone Group wrote:
> Hello All, Following on from the comments at IETF#86
> (http://www.ietf.org/proceedings/86/minutes/minutes-86-dispatch),
> where there was mild support for working on logging, I have updated
> the log me requirements draft with 3 potential solutions (in clause
> 7) which can meet the requirements
> (http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-02.txt).
> Opinions and comments on these or any other potential solutions would
> be very welcome.

Peter: I am not being a contrarian, just being curious.

What is the utility of a log-me marker if all traffic is logged
through a mechanism such as SIP CLF?

> It was commented at IETF#86 that a security analysis is needed so I
> would like to understand if any scenarios exist with potential
> security threats in order to add them to requirements. In many cases,
> a network simply logs the signalling that passes through it so no new
> security issues are created. Collecting end-to-end logging for
> signalling that crosses multiple networks must not compromise
> security or privacy, but I would expect networks to remove any
> security sensitive fields before forwarding signalling regardless of
> whether that signalling is of interest to logging.

We went through discussions related to all of the above points during
the SIP CLF work.  See the Security Consideration section of [1]; it
may provide you some answers.

[1] http://tools.ietf.org/html/rfc6872

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 20 Jun 2013 14:05:03 +0000

Hi Vijay,
The utility of a marker is that currently there is no SIP protocol mechanism to indicate that signalling is of interest to logging, so it is not a logging format issue but an issue of making regression testing and troubleshooting scaleable by not having to log everything. 

Thanks for the pointer to RFC 6872, I will take a look at it.

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
Sent: 13 June 2013 22:23
To: [email-masked]
Subject: Re: [dispatch] Proposed charter for work on logging

What is the utility of a log-me marker if all traffic is logged through a mechanism such as SIP CLF?

> signalling that crosses multiple networks must not compromise security 
> or privacy, but I would expect networks to remove any security 
> sensitive fields before forwarding signalling regardless of whether 
> that signalling is of interest to logging.

We went through discussions related to all of the above points during the SIP CLF work.  See the Security Consideration section of [1]; it may provide you some answers.

Thanks,

- vijay
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq _______________________________________________

---

From: "Javier Martinez (mjavier)" <[email-masked]>
Date: Wed, 26 Jun 2013 17:55:49 +0000

Hi Peter,

I agree with the utility of the marker proposal. In large SIP network deployments it is a challenge collecting logs and debug traces during trouble
 shooting  sessions, even with a single vendor deployments. In most situations you end up with large amounts of data to sort through to extract the sessions, or files
 of interest from multiple boxes, in others you end up missing pieces of information.

There is a need for an automated way to extract the specific logs of interest in multi-vendor  deployments.
This  proposal is also a great complement to the "End-to-End Session Id" proposal.

I would be glad to help in any way to get an implementation proposal going,

Regards
Javier

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dawes, Peter, Vodafone Group
Sent: Thursday, June 20, 2013 8:05 AM
To: Vijay K. Gurbani; [email-masked]
Subject: Re: [dispatch] Proposed charter for work on logging

Hi Vijay,

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
Sent: 13 June 2013 22:23
To: [email-masked]
Subject: Re: [dispatch] Proposed charter for work on logging

Thanks,

- vijay