1 / 19

Request History Capability – Requirements & Solution

This draft proposes the addition of a History-Info header to capture retarget information in SIP requests. It addresses security, privacy, and indexing issues associated with the captured information.

guffey
Download Presentation

Request History Capability – Requirements & Solution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SIPPING WG Meeting IETF-55 Request History Capability – Requirements & Solution draft-ietf-sipping-req-history-00.txt draft-barnes-sipping-history-info-00.txt Mary Barnes (mbarnes@nortelnetworks.com)

  2. Changes from individual –02 to WG –00 (Requirements) • Added a specific Requirement to address Optionality. • Removed a Security Requirement which stated that MUST be able to to determine whether a previously added Request History content has been removed, as this wouldn’t be possible given the privacy requirements and local policy implications. • Removed solution oriented text. draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  3. Solution draft • Defines History-Info Header • Captures “retarget” information. • Calling party is able to be notified of “retargetting” information. • Captures the new URI • Addresses security and privacy aspects associated with the information. • Defines HistInfo option • For the UAC to indicate History-Info in responses • Specified in the Supported header draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  4. Solution draft – History-Info – Current ABNF History-Info = ("History-Info" / "h") HCOLON HI-retargeted-from-uri HI-retargeted-to-uri *( SEMI HI-param ) HI-retargeted-from-uri = name-addr HI-retargeted-to-uri= name-addr HI-param = HI-reason / HI-reason-cause / HI-reason-text / HI-extension HI-reason = "HI-reason" EQUAL HI-reason-protocol HI-reason-protocol = "SIP" / "Q.850" / token HI-reason-cause = "cause" EQUAL 1*DIGIT HI-reason-text = "text" EQUAL quoted-string HI-extension = generic-param draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  5. Solution draft – History-Info - ABNF Issues 2. Replicates (rather than reuses) Reason Header. • Proposal that Reason header can be used and included as part of the captured retargeted URI. • Current ABNF results in duplication of header field for multiple entries. • Should be modified to comma delimit multiple entries. draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  6. Solution draft – History-Info - ABNF Issues • Proposal that by capturing the URI prior to retargeting (I.e. “targeted-to”) • Potential Issues: • Might have gaps for instances where HI isn’t being captured (due to local policy). • Needs further consideration and discussion on list. 3. Do we need both Retargeted-to and Retargeted-from URIs? • Retargeted-to is needed to capture information for responses (for last instance where there is no retargeting). draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  7. Solution draft – History-Info - ABNF Issues b. Allow duplicate counts, letting the index indicate the depth. A combination of the captured URIs and counts can be used to “recreate” forking tree at application needing that level of info • Issue:Will this work with only a single URI being captured? • Should we have an explicit counter? • Plain counter won’t work due to forking. • Options include: a. Indexing using a dot delimiter (to reflect depth of forking, etc.) • Issues would include, how do you limit depth and seems complex. draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  8. B is serial forking first to C then to D. C is parallel forking. Solution draft – History-Info – Index Option a A  B  C  E       |         \  F       |        \ D  G • History-Info: X, Y indicates a retarget record from X (old URI) to Y (new URI). • A sends INVITE targeted to B • B retargets to C. History-Info: B, C, n=1 is sent in INVITE and response to A • 3) C parallel forks to E and F. • HI: C, E, n=1.1 sent in INVITE to E and response to B,A • HI: C, F, n=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, C, n=1 HI: C, E, n=1.1 HI: C, F, n=1.2 HI: C, D, n=2 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  9. B is serial forking first to C then to D. C is parallel forking. Solution draft – History-Info – Index Option b A  B  C  E       |         \  F       |        \ D  G • History-Info: X, Y indicates a retarget record from X (old URI) to Y (new URI). • A sends INVITE targeted to B • B retargets to C. History-Info: B, C, n=1 is sent in INVITE and response to A • 3) C parallel forks to E and F. • HI: C, E, n=2sent in INVITE to E and response to B,A • HI: C, F, n=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, C, n=1 HI: C, E, n=2 HI: C, F, n=2 HI: C, D, n=3 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  10. Solution draft – Issues/concerns - Forking • Concerns • Need to work through more scenarios. • Need to add more detail/recommendations with regards to processing for specific classes of responses. • It is likely that for some scenarios all the information won’t be captured, but this may not be a problem. • Propose to add more detail to section 2.3.3. • Have some basic scenarios using sequential forking. • Assumption that it would also be controlled by local policy as to whether parallel Forking is captured. draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  11. Solution draft – Issues/concerns - Privacy • Issues/Concerns • The application wanting to make use of the information MUST describe the impact of privacy. • Depends upon how the privacy is implemented (i.e. Session, Header and/or Proxy-require with “privacy” tag). • Proposal assumes the use of a Privacy Service as defined in the draft-ietf-sip-privacy-general. • The application wanting to make use of the information MUST describe the impact of privacy. draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  12. Solution draft – Issues/concerns - Privacy • Propose to go with Option 2, but welcome further discussion on the list around these issues/options. • Options: • Just don’t capture Request URIs. • Pros: Simple implementation for HI. • Cons: Could potentially limit applicability/use of HI. • Define basic guidelines for HI interactions with Privacy Service, that would allow some applications to make use of information in requests which have associated Privacy. draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  13. Solution draft – Issues/concerns - Security • Primary security concern is with regards to a rogue application/proxy changing HI entries. • Proposal assumes the use of a Security Service/Authenticated identities as defined in the draft-peterson-sip-identity to protect the identities captured in the HI. • Concerns • Would likely require entities which are capturing HI to re-sign the entirety of the HI entries to ensure that order is maintained. • Is that a problem? • Other Options: • Open to suggestions. Proposal: • Complete the security protocol details in the draft. draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  14. Questions for SIPPING WG on Requirements draft? • Is the Requirements document ready for WGLC? • If NOT, what are the issues or concerns with the requirements as specified? draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  15. Questions/discussion for SIPPING WG on Solution draft? • Is the scope of the security solution accurate? • If NOT, what are the issues or concerns? • Proposal going forward: • Update draft for the concerns discussed with further detail for security and privacy aspects. • Complete the additional details/annotations to the flows in the Appendix. • Request additional feedback on the draft on the mailing list. draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  16. Backup - Examples draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  17. Summary of proposed requirements: • Record old URI in request when ‘retargetting’ (changing of Request-URI) occurs. • Record new URI to maintain ‘history’ for retargetting. • Inform UAC when retargetting occurs • Provide reason for retargetting. • Chronological ordering of the information to allow the capture of each occurrence of retargetting. draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  18. 1 5 UA1 Proxy1 Proxy2 6 4 8 7 2 3 UA2 UA3 UA4 UA5 Example 1: • UA 1 sends a call to proxy 1 which sequentially tries several places before retargetting the call to a second proxy which unfortunately tries many of the same places. Use of Request History optimizes sequential forking for terminations draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

  19. Example 2: • UA 1 called UA A which had been forwarded to UA B which forwarded to a UA VM (voicemail server) which needs information (e.g. reason the call was retargetted) to make a policy decision about what mailbox to use, which greeting to play etc. 1 (INV) 6 (INV) UA 1 Proxy UA VM 3 (INV) 4 (302) 5 (INV) UA A UA B Use of Request History enables the Voicemail Service. draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

More Related