Request History – Solution Mary Barnes SIP WG Meeting IETF-57 draft-ietf-sip-history-info-00.txt

July 16th Solution draft – changes from individual -02  Editorial updates:  Updated references and added reference to Security solution draft.  Removed appendix D which included background on analysis of solution options.  Cleaned up the document format per rfc2223bis.

July 16th Solution draft – changes from individual -02  Strengthened the inclusion of the INDEX as a MUST (per discussion at IETF-56).  Added text around the capturing of the Reason (SHOULD be captured for SIP responses and MAY be captured for other things such as timeouts).  Clarified the response processing to include provisional responses and the sending of a 183 to convey History-Info.  Added section to address Redirect Server behavior.

July 16th Solution draft –Issues 1.Index is a MUST, however, it’s still an optional field as there is an exception:  When there is no HI and one is “fabricated” from the received request prior to retargeting.  Premise for this being that a “gap” could be recognized.  Issue: for loose routing, you can’t determine “gaps” or lack of HI based upon received request.  Proposal:  Make the INDEX a mandatory field.  Clarify how the INDEX is calculated and interpreted.  Clarify the applicability of HI for loose vs strict routing.

July 16th Solution draft – Issues 2.Processing for “Internal Retargetting” requires clarification.  Requirement’s document defines “Internal retargeting”.  Issue: need corresponding normative text.  Proposal:  Include a description of “internal retargeting” in the context of the resolution for Issue 1.  Add an example which combines more “internal retargeting” with retargeting to intermediaries (I.e. pathological example showing a variety of service interactions).

July 16th Solution draft – Issues 3.Privacy  Section 1.3 refers to the use of RFC 3323 for privacy of the header  Issue: need corresponding normative text addressing privacy.  Proposal: Add a more detailed section for the privacy aspects of the solution :  Detailing use of RFC  Describing impacts of local policies on privacy and HI.

July 16th Next Steps Updates for the issues available in a few weeks. Complete the additional details/annotations to the flows in the Appendix. Request additional feedback on the mailing list.  Dependency on the security solution - this draft can’t complete without a well progressed security solution.

A Mechanism to Secure SIP Identity Headers inserted by Intermediaries Mary Barnes SIP WG Meeting IETF-57 draft-barnes-sipping-sec-inserted-info-00.txt

July 16th Security solution proposal  Primary security concern is with regards to a rogue application/proxy changing HI entries: Invalid information  Proposal modeled after authid-body to protect the identities captured in the HI.  In addition, the solution has been generalized to any other identity related headers.  Issues/Concerns : 1.Is the solution put forth adequate for the identified problem?  Request additional feedback on the mailing list and WG review. 2.More normative work required around the processing and handling of AIIHB in responses.  Proposal: Continue detailed documentation of proposed solution.

July 16th Broader Issues/concerns  Should the scope of this work be broadened as a more general “middle to end” security solution? + more value for WG. - would likely slow down progress of HI solution draft.

July 16th Next Steps Complete the detailed solution. Add more examples/usecases. Request additional feedback on the draft on the mailing list.  Further consideration of this proposal in the context of a broader “middle to end” security draft, complimenting the proposal in draft-ono-sipping-end2middle-security- 00 being discussed in SIPPING WG on Thursday.

July 16th Backup –Value of securing HI in the overall SIP security scheme. –Details of Indexing mechanism

July 16th Request History – Enhancing SIP security With secured History-Info, SIP security between proxies is strengthened: “A” can ascertain through the secured HI that is really a valid destination for the user associated with “B” whose only address A knows is A Proxy1 CD INVITE R-Uri: HI: INVITE R-Uri: To: From: HI: 1 2 INVITE R-Uri: HI: 3 INVITE R-Uri: HI: 5 INVITE R-Uri: HI: Busy Here HI: 9 Proxy2 INVITE R-Uri: To: From: HI: 200 HI: HI: 11

July 16th Solution draft – History-Info – Index Example B is serial forking first to C then to D. C is parallel forking. A  B  C  E | \  F | \  D  G 1)A sends INVITE targeted to B. HI: B, n=1. 2) B retargets to C. HI: B, n=1; C, n=1.1 is sent in INVITE and response to A. 3) C parallel forks to E and F. HI: B, n=1; C, n=1.1; E, n=1.1.1 sent in INVITE to E and response to B,A HI: B, n=1; C, n=1.1; F, n=1.1.2 sent in INVITE to F and response to B,A 4) both branches of fork to C fail. B retargets to D with the following History Info entries: HI: B, n=1; C, n=1.1; E, n=1.1.1; F, n=1.1.2; D, n=1.2