Request History – Solution

Mary Barnes (mbarnes@nortelnetworks.com)

SIP WG MeetingIETF-57

draft-ietf-sip-history-info-00.txt

July 16th 2003 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.

July 16th 2003 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.

July 16th 2003 4

Solution draft –Issues

1. Index is a MUST, however, it’s 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.

Issue: for loose routing, you can’t 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.

July 16th 2003 5

Solution draft – Issues

2. Processing for “Internal Retargetting” requires clarification. Requirement’s

document defines “Internal retargeting”.

Issue: need corresponding normative text.

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

July 16th 2003 6

Solution draft – Issues

3. Privacy Section 1.3 refers to

the use of RFC 3323 for privacy of the header

Issue: need corresponding normative text addressing privacy.

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.

July 16th 2003 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 can’t complete without a well progressed security solution.

A Mechanism to Secure SIP Identity Headers inserted by

Intermediaries

Mary Barnes (mbarnes@nortelnetworks.com)

SIP WG MeetingIETF-57

draft-barnes-sipping-sec-inserted-info-00.txt

July 16th 2003 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:

1. Is the solution put forth adequate for the identified problem? Request additional

feedback on the mailing list and WG review.

2. More normative work required around the processing and handling of AIIHB in responses. Proposal: Continue detailed

documentation of proposed solution.

July 16th 2003 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.

July 16th 2003 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.

July 16th 2003 12

Backup

– Value of securing HI in the overall SIP security scheme.

– Details of Indexing mechanism

July 16th 2003 13

Request History – Enhancing SIP securityWith secured History-Info, SIP security between proxies is

strengthened:• “A” can ascertain through the secured HI that “E@bubba.com” is

really a valid destination for the user associated with “B” whose only address A knows is “B@home.com”.

A

Proxy1

B@home.com C D

E@bubba.com

INVITER-Uri: <B>HI: <B>

INVITER-Uri: <B>To: <B>From: <A>HI: <B>

1

2INVITER-Uri: <C>HI: <B,C>

3

INVITER-Uri: <D>HI: <B,C, D>

5

INVITER-Uri: <D>HI: <B,C, D>

67

302 <D>

4

Busy Here

8

200HI: <B,C, D, E>

9Proxy2

INVITER-Uri: <E>To: <B>From: <A>HI: <B,C, D, E>

200HI: <B,C, D, E>

10200

HI: <B,C, D, E>11

July 16th 2003 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

 

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