IETF-76 SIP Identity Adhoc

512 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
512
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

IETF-76 SIP Identity Adhoc

  1. 1. IETF 76 DISPATCH WG ad hoc meeting on SIP Identity Victor Pascual Avila, John Elwell
  2. 2. History <ul><li>Various drafts published in 2008 timeframe, proposing a number of solutions </li></ul><ul><li>Also drafts relating to the E.164 problem and to identity handling at a UA </li></ul><ul><li>Presentation by Jon Peterson at IETF#73 </li></ul><ul><li>Informal “design team” held conference calls between IETF#73 and IETF#74 and developed draft-elwell-sip-e2e-identity-important </li></ul>
  3. 3. History (continued) <ul><li>Discussion at IETF#74, based on draft-elwell-sip-e2e-identity-important-03 </li></ul><ul><ul><li>Mixed feedback </li></ul></ul><ul><ul><li>Desire to see requirements stated more clearly </li></ul></ul><ul><ul><li>Mixed opinions on whether to pursue in the way it was at that time being pursued </li></ul></ul><ul><ul><li>But consensus that discussion should continue – need a different way of pursuing it </li></ul></ul><ul><li>Draft-elwell-dispatch-identity-reqs-00 published before IETF#75, but no discussion there </li></ul><ul><li>Draft-elwell-dispatch-identity-reqs-01 published in October, reflecting comments received </li></ul>
  4. 4. What are we trying to achieve? <ul><li>From IETF#74 presentation: </li></ul><ul><li>The ability for a participant in a communication to know with a high degree of certainty who the other party (caller or callee) is and that information (e.g., voice, text, video) is being sent to / received from that other party </li></ul><ul><ul><li>“ e2e authenticated identification” </li></ul></ul><ul><ul><li>to work in a large number of practical deployments </li></ul></ul>
  5. 5. What is the problem that is preventing this? <ul><li>From IETF#74 presentation: </li></ul><ul><li>Intermediate B2BUAs modify signed parts of request </li></ul><ul><ul><li>Modify SDP for media steering </li></ul></ul><ul><ul><li>Modify call-ID, contact, etc for topology hiding </li></ul></ul><ul><li>Intermediate B2BUAs modify E.164-based SIP URIs </li></ul><ul><ul><li>Canonicalization </li></ul></ul><ul><li>Both practices break e2e authenticated identification as currently defined </li></ul>
  6. 6. Current status <ul><li>Draft-elwell-dispatch-identity-reqs-01 expresses requirements </li></ul><ul><li>A number of expired drafts propose solutions, which can be roughly categorized as follows: </li></ul><ul><ul><li>reducing the amount of signed information compared to RFC 4474 (to avoid the need for breaking the signature when changing information en route) </li></ul></ul><ul><ul><li>signing a copy of certain information, so that if the original information is changed en route, the signature is still valid and the copy of the original information is still available) </li></ul></ul><ul><ul><li>performing a return routability check of some form </li></ul></ul>
  7. 7. Current status (continued) <ul><li>It is recognised that there are difficulties with E.164 numbers, in the sense of what a domain can assert about an E.164 number. However, since E.164-based SIP URIs are by far the most common (for voice at least), we should try to do something with these. </li></ul><ul><li>There seems to be a consensus we can't do much about PSTN interworking. The most we can do for a call from PSTN is to provide some authentication of the gateway that asserts the calling number (based on the assertion received from PSTN). </li></ul>
  8. 8. Where to go from here? <ul><li>Are requirements heading in the right direction? </li></ul><ul><li>Should we now try to map different known solutions to these requirements to assess what is covered/missing? </li></ul><ul><li>From there, try to assess whether a generic solution is possible or whether we need a small number of solutions for different use cases. </li></ul>
  9. 9. Questions for the group <ul><li>Do we agree we have a problem? </li></ul><ul><ul><li>Is this stated clearly in any of the prior drafts (e.g., draft-elwell-sip-e2e-identity-important)? </li></ul></ul><ul><ul><li>Or do we need to state the problem in some other way? </li></ul></ul><ul><li>If we have a problem, what should be the next step? </li></ul><ul><ul><li>Map known solutions to requirements as suggested on previous slide? </li></ul></ul><ul><li>Who is willing to be involved in ongoing work (e.g., drafting, reviewing, proposing solutions…)? </li></ul><ul><li>Is it appropriate to keep this as a DISPATCH topic and try to take more positive steps at IETF#77? </li></ul>

×