SIP WG Meeting IETF57 Request History Solution draftietfsiphistoryinfo00

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

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

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

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

Solution draft – Issues 2. Processing for “Internal Retargetting” requires clarification. § Requirement’s document defines “Internal retargeting”. v Issue: need corresponding normative text. July 16 th 2003 Ø 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). 5

Solution draft – Issues 3. Privacy 1. Section 1. 3 refers to the use of RFC 3323 for privacy of the header v Issue: need corresponding normative text addressing privacy. July 16 th 2003 Ø 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. 6

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

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

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

Broader Issues/concerns v 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 16 th 2003 10

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-end 2 middle-security 00 being discussed in SIPPING WG on Thursday. July 16 th 2003 11

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

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”. 11 A 200 Proxy 1 HI: <B, C, D, E> 1 INVITE R-Uri: <B> To: <B> From: <A> HI: <B> 2 INVITE R-Uri: <B> HI: <B> 200 HI: <B, C, D, E> 1 0 9 INVITE R-Uri: <D> HI: <B, C, D> 5 200 HI: <B, C, D, E> 8 4 3 302 <D> INVITE R-Uri: <C> HI: <B, C> B@home. com July 16 th 2003 Proxy 2 C 6 INVITE 7 R-Uri: <D> Busy Here HI: <B, C, D> E@bubba. com INVITE R-Uri: <E> To: <B> From: <A> HI: <B, C, D, E> D 13

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. 1) HI: B, n=1; C, n=1. 1; E, n=1. 1. 1 sent in INVITE to E and response to B, A 2) 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 July 16 th 2003 14