1 / 14

Request History – Solution

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.

hass
Download Presentation

Request History – Solution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. 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. 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.

  5. 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.

  6. 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.

  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. 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)

  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: • 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.

  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. 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. Backup • Value of securing HI in the overall SIP security scheme. • Details of Indexing mechanism

  13. 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

  14. 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

More Related