1 / 9

IETF 76 DISPATCH WG ad hoc meeting on SIP Identity

Victor Pascual Avila, John Elwell. IETF 76 DISPATCH WG ad hoc meeting on SIP Identity. History. Various drafts published in 2008 timeframe, proposing a number of solutions Also drafts relating to the E.164 problem and to identity handling at a UA Presentation by Jon Peterson at IETF#73

jenski
Download Presentation

IETF 76 DISPATCH WG ad hoc meeting on SIP Identity

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. Victor Pascual Avila, John Elwell IETF 76 DISPATCH WGad hoc meeting on SIP Identity

  2. History • Various drafts published in 2008 timeframe, proposing a number of solutions • Also drafts relating to the E.164 problem and to identity handling at a UA • Presentation by Jon Peterson at IETF#73 • Informal “design team” held conference calls between IETF#73 and IETF#74 and developed draft-elwell-sip-e2e-identity-important

  3. History (continued) • Discussion at IETF#74, based on draft-elwell-sip-e2e-identity-important-03 • Mixed feedback • Desire to see requirements stated more clearly • Mixed opinions on whether to pursue in the way it was at that time being pursued • But consensus that discussion should continue – need a different way of pursuing it • Draft-elwell-dispatch-identity-reqs-00 published before IETF#75, but no discussion there • Draft-elwell-dispatch-identity-reqs-01 published in October, reflecting comments received

  4. What are we trying to achieve? • From IETF#74 presentation: • 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 • “e2e authenticated identification” • to work in a large number of practical deployments

  5. What is the problem that is preventing this? • From IETF#74 presentation: • Intermediate B2BUAs modify signed parts of request • Modify SDP for media steering • Modify call-ID, contact, etc for topology hiding • Intermediate B2BUAs modify E.164-based SIP URIs • Canonicalization • Both practices break e2e authenticated identification as currently defined

  6. Current status • Draft-elwell-dispatch-identity-reqs-01 expresses requirements • A number of expired drafts propose solutions, which can be roughly categorized as follows: • reducing the amount of signed information compared to RFC 4474 (to avoid the need for breaking the signature when changing information en route) • 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) • performing a return routability check of some form

  7. Current status (continued) • 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. • 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).

  8. Where to go from here? • Are requirements heading in the right direction? • Should we now try to map different known solutions to these requirements to assess what is covered/missing? • From there, try to assess whether a generic solution is possible or whether we need a small number of solutions for different use cases.

  9. Questions for the group • Do we agree we have a problem? • Is this stated clearly in any of the prior drafts (e.g., draft-elwell-sip-e2e-identity-important)? • Or do we need to state the problem in some other way? • If we have a problem, what should be the next step? • Map known solutions to requirements as suggested on previous slide? • Who is willing to be involved in ongoing work (e.g., drafting, reviewing, proposing solutions…)? • Is it appropriate to keep this as a DISPATCH topic and try to take more positive steps at IETF#77?

More Related