1. Request History Capability – Requirements & Solution
SIPPING WG Meeting
IETF-56
Request History Capability – Requirements & Solution
draft-ietf-sipping-req-history-02.txt
draft-barnes-sipping-history-info-02.txt
Mary Barnes

2. Requirements - Changes from –00 to–02
Updated intro to clear specify that the solution is to define a building block and not a complete solution for any specific application .
Defined a separate section for Privacy requirements, with additional minor rewording in the –02 version.
Security requirements remain, with more general security requirements being defined in a separate document.
Added additional applications in the introduction:
Diagnostics
Enhancing SIP security.
Status: Should be complete.
Mar,
draft-ietf-sipping-request-history-02
draft-barnes-sipping-history-info-02

3. Solution draft – changes from –00 to -02
Capture a single URI “targeted-to”:
Original Request URI is captured prior to retargeting.
Previous entry then reflects “Retargeted-from” when retargeting occurs and “Retargeted-to” is captured.
Defined an explicit counter:
Required to determine context for “Retargeted-to” and “Retargeted-from”
Index uses a dot delimiter to reflect depth of forking, and levels of redirection.
WG feedback resulted in more detailed normative text around the maintenance of the index in the –02 version.
Additional high level flow in Appendix C.
Mar,
draft-ietf-sipping-request-history-02
draft-barnes-sipping-history-info-02

4. Solution draft –Issues
Advantages of Index:
Indicates level of nesting and # of redirections
Potential Issues:
Might have gaps for instances where HI isn’t being captured (due to local policy), thus cases where no index is available.
Needs further consideration and discussion on list.
Should the index be mandatory?
Index is currently defined as an optional field.
It’s not possible to apply any semantics to the captured URIs in terms of number of redirections or forking without an index.
Mar,
draft-ietf-sipping-request-history-02
draft-barnes-sipping-history-info-02

5. Solution draft – Issues/concerns - Security
Requires entities which are capturing HI to re-sign the entirety of the HI entries to ensure that order is maintained.
At a minimum, must verify the previous entry to determine validity of index for HI being captured.
Other Options:
Have stepped back to fundamental requirements analysis and taking a broader look at available security solutions.
Proposal: Clearly document and analyze requirements and proposed solution.
Primary security concern is with regards to a rogue application/proxy changing HI entries: Invalid information
Initial Proposal assumed the use of a Security Service/Authenticated identities similar to draft-ieft-sip-authid-body to protect the identities captured in the HI.
Mar,
draft-ietf-sipping-request-history-02
draft-barnes-sipping-history-info-02

6. Request History – Enhancing SIP security
With secured History-Info, SIP security between proxies is strengthened:
“A” can ascertain through the secured HI that “E” is really a valid destination for the user associated with “B”.
200
HI: <B,C, D, E> 10
200
HI: <B,C, D, E> 11
Proxy1
Proxy2
200
HI: <B,C, D, E> 9 A
INVITE
R-Uri: <D>
HI: <B,C, D> E
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> 3 6 7
INVITE
R-Uri: <C>
HI: <B,C>
Busy Here 2
INVITE
R-Uri: <B>
HI: <B> B C D
Mar,
draft-ietf-sipping-request-history-02
draft-barnes-sipping-history-info-02

7. Next Steps Requirements: Security solution: Solution:
Ready for WGLC?
Security solution:
Complete the requirements analysis.
Detail the solution
Draft available soon after IETF-56.
Solution:
Complete the additional details/annotations to the flows in the Appendix.
Dependency on the security solution.
Should this go to SIP WG?
Request additional feedback on the drafts on the mailing list.
Mar,
draft-ietf-sipping-request-history-02
draft-barnes-sipping-history-info-02

8. Backup Details of Indexing mechanism Mar, 19 2003
draft-ietf-sipping-request-history-02
draft-barnes-sipping-history-info-02

9. 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
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
Mar,
draft-ietf-sipping-request-history-02
draft-barnes-sipping-history-info-02