Request History Information

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