Request History

1
Request History Solution
SIP WG Meeting IETF-57
draft-ietf-sip-history-info-00.txt
Mary Barnes (mbarnes_at_nortelnetworks.com)
2
Solution draft changes from individual -02

• Editorial updates
• Updated references and added reference to
  Security solution draft.
• Removed appendix D which included background on
  analysis of solution options.
• Cleaned up the document format per rfc2223bis.

3
Solution draft changes from individual -02

• Strengthened the inclusion of the INDEX as a MUST
  (per discussion at IETF-56).
• Added text around the capturing of the Reason
  (SHOULD be captured for SIP responses and MAY be
  captured for other things such as timeouts).
• Clarified the response processing 2.3.3.2 to
  include provisional responses and the sending of
  a 183 to convey History-Info.
• Added section 2.3.4 to address Redirect Server
  behavior.

4
Solution draft Issues

• Issue for loose routing, you cant determine
  gaps or lack of HI based upon received request.
  
• Proposal
• Make the INDEX a mandatory field.
• Clarify how the INDEX is calculated and
  interpreted.
• Clarify the applicability of HI for loose vs
  strict routing.

• Index is a MUST, however, its still an optional
  field as there is an exception
• When there is no HI and one is fabricated from
  the received request prior to retargeting.
• Premise for this being that a gap could be
  recognized.

5
Solution draft Issues

• Proposal
• Include a description of internal retargeting
  in the context of the resolution for Issue 1.
• Add an example which combines more internal
  retargeting with retargeting to intermediaries
  (I.e. pathological example showing a variety of
  service interactions).

• Processing for Internal Retargetting requires
  clarification.
• Requirements document defines Internal
  retargeting.
• Issue need corresponding normative text.

6
Solution draft Issues

• Proposal Add a more detailed section for the
  privacy aspects of the solution
• Detailing use of RFC 3323.
• Describing impacts of local policies on privacy
  and HI.

• Privacy
• Section 1.3 refers to the use of RFC 3323 for
  privacy of the header
• Issue need corresponding normative text
  addressing privacy.

7
Next Steps

• Updates for the issues available in a few weeks.
• Complete the additional details/annotations to
  the flows in the Appendix.
• Request additional feedback on the mailing list.
• Dependency on the security solution - this draft
  cant complete without a well progressed security
  solution.

8
A Mechanism to Secure SIP Identity Headers
inserted by Intermediaries
SIP WG Meeting IETF-57
draft-barnes-sipping-sec-inserted-info-00.txt
Mary Barnes (mbarnes_at_nortelnetworks.com)
9
Security solution proposal

• Primary security concern is with regards to a
  rogue application/proxy changing HI entries
  Invalid information
• Proposal modeled after authid-body to protect the
  identities captured in the HI.
• In addition, the solution has been generalized to
  any other identity related headers.

• Issues/Concerns
• Is the solution put forth adequate for the
  identified problem?
• Request additional feedback on the mailing list
  and WG review.
• More normative work required around the
  processing and handling of AIIHB in responses.
• Proposal Continue detailed documentation of
  proposed solution.

10
Broader Issues/concerns

• Should the scope of this work be broadened as a
  more general middle to end security solution?
• more value for WG.
• - would likely slow down progress of HI
  solution draft.

11
Next Steps

• Complete the detailed solution.
• Add more examples/usecases.
• Request additional feedback on the draft on the
  mailing list.
• Further consideration of this proposal in the
  context of a broader middle to end security
  draft, complimenting the proposal in
  draft-ono-sipping-end2middle-security-00 being
  discussed in SIPPING WG on Thursday.

12
Backup

• Value of securing HI in the overall SIP security
  scheme.
• Details of Indexing mechanism

13
Request History Enhancing SIP security

• With secured History-Info, SIP security between
  proxies is strengthened
• A can ascertain through the secured HI that
  E_at_bubba.com is really a valid destination for
  the user associated with B whose only address A
  knows is B_at_home.com.

200 HI ltB,C, D, Egt
10
Proxy1
Proxy2
INVITE R-Uri ltDgt HI ltB,C, Dgt
A
E_at_bubba.com
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
C
D
B_at_home.com
14
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
•