SIP WG Meeting IETF60 Request History Information draftietfsiphistoryinfo03

SIP WG Meeting IETF-60 Request History Information draft-ietf-sip-history-info-03. txt Mary Barnes (mary. barnes@nortelnetworks. com) Aug. 5 th, 2004 draft-ietf-sip-history-info-03

Changes from -02 v Miscellaneous editorial nits; update to new IPR template, resolving editorial notes, etc. v New text to address WG consensus on Issue-1; adding a new priv-value for History-Info header entries. v 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. v Updated Security sections to reflect WG consensus that TLS is mandatory and sufficient for general History-Info implementation. The e 2 m and m 2 m (or whatever) security solutions can be applied to History-Info when they become available to provide a more robust SIP solution. Aug. 5 th, 2004 draft-ietf-sip-history-info-03 2

Changes from -02: v 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). v 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 3 xx response goes back to the UAC and it's the UAC that retargets the INVITE request. v Clarified the addition of the Reason header in section 4. 3. 3. 1. 2. v 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. Aug. 5 th, 2004 draft-ietf-sip-history-info-03 3

Issues discussed since -03 issued v 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. [JRE-5] Use term “hi-targeted-touri” 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). Aug. 5 th, 2004 draft-ietf-sip-history-info-03 4

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

Issues discussed since -03 issued v Some minor normative changes proposed: v Comments resulting in no changes: [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. [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 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. Aug. 5 th, 2004 draft-ietf-sip-history-info-03 6

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? Aug. 5 th, 2004 draft-ietf-sip-history-info-03 7

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”. Aug. 5 th, 2004 draft-ietf-sip-history-info-03 8

History-Info – 2 options for Robust Security 1. 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. v Obviates the need for intermediary involvement and a transitive trust model. Aug. 5 th, 2004 2. draft-ietf-mahy-sipping-addbody: § 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 Pheaders 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) v Facilitates Interworking 9 draft-ietf-sip-history-info-03

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. Aug. 5 th, 2004 § 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 10

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? Aug. 5 th, 2004 draft-ietf-sip-history-info-03 11

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 Aug. 5 th, 2004 draft-ietf-sip-history-info-03 12