SIP WG Meeting IETF58 Request History Solution draftietfsiphistoryinfo01

SIP WG Meeting IETF-58 Request History – Solution draft-ietf-sip-history-info-01. txt Mary Barnes (mary. barnes@nortelnetworks. com) Nov 12 th 2003

History Info: changes from -00 v Miscellaneous editorial changes (i. e. Hist. Info -> Histinfo, etc. ) v Removed definitions of new terms, only referencing the terms from the requirements in the context of the fundamental SIP processing implied by the terms. v Fair amount of rewriting to be more explicit about the fundamental processing associated with the header, including applicability to loose routing. v Clarified the Index and the related processing in terms of how it’s calculated and maintained. Nov 12 th 2003 2

History-Info: changes from -00 v Added more detail addressing the privacy requirements in terms of impact of Privacy header and local policies, per previous email discussion on requirements. v Added a bit more detail on security. The security solution remains in a separate document and this document will need updating once that is completed. v Updated the examples (in section 2. 5 and appendix). v Corrected the Reason description in section 2. 1. There had been an error in the description of the processing that was a remnant of the change to include only a single URI for each History-Info header. Nov 12 th 2003 3

History-Info – Issues 1. Per the current model, the Request URI is captured as the request is forwarded, thus requiring the Reason for retargetting to be added to the previous History-Info entry. § Premise for this being that it provides a “complete” history. v Issue: this appears to make the security even more complicated. Nov 12 th 2003 Options: § § Capture only at the point of retargeting BUT, that leads to the loss of information that was the premise for this draft. Ø Proposal: § Reason is only added for History-Info entries added by the retargeting entity, thus it’s not a security issue as much as a complexity issue. 4

History-Info – Issues 2. Privacy § § Section 1. 3 is now explicit in that HI SHOULD not be added if there is privvalue of Session or Header level privacy. Consistent with conclusions to previous email discussions on Requirements (and normative RFC 3323 text). Due to the ability of HI to reveal general routing information that may be subject to privacy, also MAY be excluded due to Local Policy. Nov 12 th 2003 v Alternatives: v Add tags to allow HI to be added when privacy restrictions are involved, but must be removed when it’s being forwarded to non-trusted domain (per local policy). Ø Proposal: § Keep it simple and update normative processing in section 2 (Protocol details) to reflect that information is not included when there are privacy considerations. 5

Next Steps • Complete the additional details/annotations to the flows in the Appendix. • Bring the requirements into this document? • Request additional feedback on the mailing list. Ø Dependency on the security solution - this draft can’t complete without a well progressed security solution. Nov 12 th 2003 6

Potential Applications of History-Info – Value proposition of History-Info in the overall SIP security scheme. – Voicemail Nov 12 th 2003 7

Request History Example– Enhancing SIP security • “A” calls “B@home. com” but the call is answered by “C@bubba. com”. • With secured HI “A” can be certain that “C@bubba. com” is a valid destination for the user associated with “B” whose only address A knows is “B@home. com”. 8 A 1 200 HI: <B, C> Proxy 1 INVITE R-Uri: <B> To: <B> From: <A> HI: <B> 2 Nov 12 th 2003 200 HI: <B, C> 7 INVITE R-Uri: <B> HI: <B> 4 INVITE R-Uri: <C> HI: <B, C> 3 302 <C> B@home. com Proxy 2 200 HI: <B, C> 6 5 C@bubba. com INVITE R-Uri: <C> To: <B> From: <A> HI: <B, C> 8

History-Info – Applicability to Voicemail Alternatives for Voicemail solutions: – Service specific URI mechanism based on RFC 3087 – Service specific URI mechanism discussed in draft-jennings-sip-voicemail-uri-00. Ø Requires the proxy to understand the valid targets for the UM system, thus distributing the service logic between the proxy and the UM system. – Makes use of netann service specific URIs. – Proposes the addition of a Reason and Target parms to the Request URI. Nov 12 th 2003 9

History-Info – Applicability to Voicemail – History-Info header based solution: – Allows the proxy to pass call related history information that allows an intelligent UM system to make decisions about handling of the call. Proxy merely makes routing decision. – Makes use of the Reason captured with the Request URIs in the History-Info – Keeps the voicemail specific processing in the UM server. Nov 12 th 2003 10

Backup Nov 12 th 2003 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 Nov 12 th 2003 12