1 / 12

Request History Information

SIP WG Meeting IETF-60. Request History Information. draft-ietf-sip-history-info-03.txt. Mary Barnes (mary.barnes@nortelnetworks.com). Changes from -02. Miscellaneous editorial nits; update to new IPR template, resolving editorial notes, etc.

livia
Download Presentation

Request History Information

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-60 Request History Information draft-ietf-sip-history-info-03.txt Mary Barnes (mary.barnes@nortelnetworks.com)

  2. Changes from -02 • Miscellaneous editorial nits; update to new IPR template, resolving editorial notes, etc. • New text to address WG consensus on Issue-1; adding a new priv-value for History-Info header entries. • Removed Open Issues section. For Issue-2, there was not WG consensus to define an algorithm for bounding the History-Info entries, but rather that is left as an implementation decision. • Updated Security sections to reflect WG consensus that TLS is mandatory and sufficient for general History-Info implementation. The e2m and m2m (or whatever) security solutions can be applied to History-Info when they become available to provide a more robust SIP solution. draft-ietf-sip-history-info-03

  3. Changes from -02: • Section 4.1 (Protocol structure): Added additional text to ensure that all the information in the History-Info header is appropriately and normatively described (in text). • Added text in section 4.3.1 and an example to the appendices to address the UAC having added multiple History-Info headers for the case where the 3xx response goes back to the UAC and it's the UAC that retargets the INVITE request. • Clarified the addition of the Reason header in section 4.3.3.1.2. • Further delineated the basic rules in section 4.3.3.1.3 for calculating the index for various scenarios, as this was still causing some confusion. draft-ietf-sip-history-info-03

  4. Issues discussed since -03 issued • Editorial nits and clarifications: [JRE-1] Further clarification in security section (3.2) req’d since the “more robust security solution” (per Adding bodies, etc.) is no longer a dependency (per mailing list agreement) [JRE-2] Clarification in section 3.3. [JRE-3/10] Add SUBSCRIBE as an allowed method in 4.1. Propose also to add PUBLISH. • Editorial nits and clarifications: [JRE-5] Use term “hi-targeted-to-uri” to be more explicit when discussing Request-URIs in section 4.1 [JRE-8/9] Rename “hist-info” to “hi-entry”. Use “hi-entry” rather than the general History-Info entry or header, where applicable. [JRE-11] 4.3.3/Item 4. Clarify the conditions under which Privacy header is added (i.e. clarify “this” in the next to the last sentence). draft-ietf-sip-history-info-03

  5. Issues discussed since -03 issued • Editorial nits and clarifications: [JRE-13] 4.3.3.1.1 – Privacy headers – section has some duplication and is unclear. [JRE-14.1] 4.3.3.1.3 – Clarify that each dot reflects a hop or level of nesting and that the number of hops is determined by the number of dots. Using “digits” vs. “integer” for index. [JRE-14.2] 4.3.3.1.3 – Remove last sentence. It’s inaccurate and a holdover from earlier version of the doc. • Editorial nits and clarifications: [JRE-15] 4.3.3.1.3 – Forking/parallel search scenario. Clarify that the processing of the amalgamated (or aggregated) History-Info entries is similar to that as described in section 16.7 of RFC3261 for aggregating Authentication Header Field values. Use of term “aggregated” vs “amalgamated”? draft-ietf-sip-history-info-03

  6. Issues discussed since -03 issued • Some minor normative changes proposed: [JRE-4] Add MUST strength to adding History-Info entries following any in the received request. [JRE-10] Add PUBLISH as an allowed method in 4.1. • Comments resulting in no changes: [JRE-6/12] Section 4.1, Reason description. Reason is added by “processing entity that initially added the Request-URI”. History-Info is also captured for forwarding (and not just retargeting). [JRE-7] Privacy is handled with a single new priv-value “history” which either covers all the entries or a single entry. Thus, either the Privacy header is added to the request or escaped as part of the hi-targeted-to-uri. draft-ietf-sip-history-info-03

  7. Next Steps • Request additional individuals to do a detailed review following next update. • Feedback in the form of alternative text on any other issues identified is most constructive. • Update the flows in the appendix including additional details & annotations. • Ready for WGLC? draft-ietf-sip-history-info-03

  8. History-Info – Going Forward towards “Robust” Security • Caveat: these next few charts summarize some thoughts on History and • the more robust security solution based on discussions in SIP WG on • Wednesday; these thoughts are not necessarily “fully baked” yet, but • intended as a basis for discussion to understand the current solution • proposals as applied to History-Info. • Accept the current specification in RFC 3261 on determining request targets as sufficient as it provides flexibility in implementation. • Retargeting is only applicable if the Request-URI reflects a domain for which the element is responsible. • “If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding”. draft-ietf-sip-history-info-03

  9. 2. draft-ietf-mahy-sipping-add-body: • Proposes to “relax” restriction that proxies cannot add message bodies to allow securing information added by intermediaries. • Provides a general purpose mechanism, thus avoiding the requirement to define P-headers for cases where this functionality is useful. • Doesn’t entirely resolve the “robust” security problem for History-Info - another intermediary needs to unpack to access index (transitive model) • Facilitates Interworking • draft-ietf-sip-identity-02: • Redirect ONLY in the case of retargeting “to a domain for which the processing entity is not responsible” • Scenario is a corner case and not the most likely one involving History-Info, thus impact is likely less than perceived. • Seems to put a large burden on points of Interworking and UAC, rather than the intermediary. May be difficult to make backwards compatible. • Obviates the need for intermediary involvement and a transitive trust model. History-Info – 2 options for Robust Security draft-ietf-sip-history-info-03

  10. History-Info –Privacy Effectively, History-Info has a similar dichotomy for Privacy Solution: • History-Info is not added for the typical case where there is a Privacy header, per RFC 3323. • New privacy tag applied to scenarios to support privacy in the case that the retargeting is “to a domain for which the processing entity is responsible”. draft-ietf-sip-history-info-03

  11. History-Info – Security and Privacy Summary • Reality: WG has been stalled on this problem for 2+ years. Only progress has been P-Asserted-Identity (and Privacy). • Can we not consider accepting the 2 options, exploring them further and determining how the policy work can be used as an enabler? • Would it be useful to revamp draft-barnes-sipping-inserted-info-01 (expired in April 04) to further explore these solution options? Propose to refocus that draft as History-Info specific (as originally put forth) since other drafts provide the more general mechanisms. • Are folks comfortable with the dichotomy of the privacy solution in the current History-Info draft? draft-ietf-sip-history-info-03

  12. 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 draft-ietf-sip-history-info-03

More Related