Request History Capability

1
Request History Capability Requirements
Solution
SIPPING WG Meeting IETF-56
draft-ietf-sipping-req-history-02.txt draft-barnes
-sipping-history-info-02.txt
Mary Barnes (mbarnes_at_nortelnetworks.com)
2
Requirements - Changes from 00 to02

• 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.

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.

4
Solution draft Issues

• Advantages of Index
• Indicates level of nesting and of redirections
• Potential Issues
• Might have gaps for instances where HI isnt
  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.
• Its not possible to apply any semantics to the
  captured URIs in terms of number of redirections
  or forking without an index.

5
Solution draft Issues/concerns - Security

• Concerns
• 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.

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 ltB,C, D, Egt
10
Proxy1
Proxy2
A
INVITE R-Uri ltDgt HI ltB,C, Dgt
E
INVITE R-Uri ltBgt To ltBgt From ltAgt HI ltBgt
5
1
INVITE R-Uri ltEgt To ltBgt From ltAgt HI ltB,C, D,
Egt
8
4
302 ltDgt
INVITE R-Uri ltDgt HI ltB,C, Dgt
6
3
7
INVITE R-Uri ltCgt HI ltB,Cgt
Busy Here
INVITE R-Uri ltBgt HI ltBgt
2
B
C
D
7
Next Steps

• Requirements
• 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.

8
Backup

• Details of Indexing mechanism

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, n1.
• B retargets to C. HI B, n1 C, n1.1 is sent
  in INVITE and response to A.
• 3) C parallel forks to E and F.
• HI B, n1 C, n1.1 E, n1.1.1 sent in
  INVITE to E and response to B,A
• HI B, n1 C, n1.1 F, n1.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, n1 C, n1.1 E, n1.1.1 F,
  n1.1.2 D, n1.2
•