1. Request History – Solution Mary Barnes (mbarnes@nortelnetworks.com) SIP WG Meeting IETF-57 draft-ietf-sip-history-info-00.txt

2. July 16th 2003 2 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.

3. July 16th 2003 3 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 2.3.3.2 to include provisional responses and the sending of a 183 to convey History-Info.  Added section 2.3.4 to address Redirect Server behavior.

4. July 16th 2003 4 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.

5. July 16th 2003 5 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).

6. July 16th 2003 6 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 3323.  Describing impacts of local policies on privacy and HI.

7. July 16th 2003 7 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.

8. A Mechanism to Secure SIP Identity Headers inserted by Intermediaries Mary Barnes (mbarnes@nortelnetworks.com) SIP WG Meeting IETF-57 draft-barnes-sipping-sec-inserted-info-00.txt

9. July 16th 2003 9 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.

10. July 16th 2003 10 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.

11. July 16th 2003 11 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.

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

13. July 16th 2003 13 Request History – Enhancing SIP security With secured History-Info, SIP security between proxies is strengthened: “A” can ascertain through the secured HI that “E@bubba.com” is really a valid destination for the user associated with “B” whose only address A knows is “B@home.com”. A Proxy1 B@home.com CD E@bubba.com 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: 6 7 302 4 Busy Here 8 200 HI: 9 Proxy2 INVITE R-Uri: To: From: HI: 200 HI: 1010 200 HI: 11

14. July 16th 2003 14 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