140 likes | 239 Views
SIP WG Meeting IETF-57. Request History – Solution. draft-ietf-sip-history-info-00.txt. Mary Barnes (mbarnes@nortelnetworks.com). Solution draft – changes from individual -02. Editorial updates: Updated references and added reference to Security solution draft.
E N D
SIP WG Meeting IETF-57 Request History – Solution draft-ietf-sip-history-info-00.txt Mary Barnes (mbarnes@nortelnetworks.com)
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.
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.
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. Solution draft –Issues • 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.
Solution draft – Issues • 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). • Processing for “Internal Retargetting” requires clarification. • Requirement’s document defines “Internal retargeting”. • Issue: need corresponding normative text.
Solution draft – Issues • 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. • Privacy • Section 1.3 refers to the use of RFC 3323 for privacy of the header • Issue: need corresponding normative text addressing privacy.
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.
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)
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: • Is the solution put forth adequate for the identified problem? • Request additional feedback on the mailing list and WG review. • More normative work required around the processing and handling of AIIHB in responses. • Proposal: Continue detailed documentation of proposed solution.
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.
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.
Backup • Value of securing HI in the overall SIP security scheme. • Details of Indexing mechanism
200 HI:<B,C, D, E> 200 HI: <B,C, D, E> 11 9 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”. 200 HI: <B,C, D, E> 10 Proxy1 Proxy2 INVITE R-Uri: <D> HI: <B,C, D> A E@bubba.com INVITE R-Uri: <B> To: <B> From: <A> HI: <B> 5 1 INVITE R-Uri: <E> To: <B> From: <A> HI: <B,C, D, E> 8 4 302 <D> INVITE R-Uri: <D> HI: <B,C, D> 6 3 7 Busy Here INVITE R-Uri: <C> HI: <B,C> INVITE R-Uri: <B> HI: <B> 2 C D B@home.com
B is serial forking first to C then to D. C is parallel forking. Solution draft – History-Info – Index Example A B C E | \ F | \ D G • A sends INVITE targeted to B. HI: B, n=1. • 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