1 / 10

Flemming Andreasen (fandreas@cisco)

SIP Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks <draft-ietf-sip-privacy-04.txt>. Flemming Andreasen (fandreas@cisco.com)

kalin
Download Presentation

Flemming Andreasen (fandreas@cisco)

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. SIP Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks<draft-ietf-sip-privacy-04.txt> Flemming Andreasen (fandreas@cisco.com) W. Marshall, K. K. Ramakrishnan, E. Miller, G. Russell, B. Beser, M. Mannette, K. Steinbrenner, D. Oran, F. Andreasen, J. Pickens, P. Lalwaney, J. Fellows, D. Evans, K. Kelly, M. Watson IETF - March 2002

  2. Draft Status • Lots of list discussion and off-line comments • Currently in WG Last Call

  3. Overview of Changes • Applicability Statement about appropriate use • Within administrative domain or cooperating domains • Draft is for network-asserted identity, not user-asserted • Anonymity header removed • Issue of IP address privacy still described, but no solution offered (general service invocation issue) • Extensions must be documented in an RFC and undergo designated expert review • Grammar fixes and 2543bis alignment • Various editorial changes

  4. Open Issue #1 • Proxy handling of a Remote-Party-ID received from untrusted entity (proxy or UA) • Option 1 • If verifiable, set “screen=yes” • If not verifiable, set “screen=no” • Option 2 • Always remove untrusted Remote-Party-ID • If identity can be determined, add new Remote-Party-ID with identity information • Option 1 more general than option 2 • Option 1 allows unsupported identity types to be passed while still supporting the general privacy handling functions • Option 2 assumes that an untrusted Remote-Party-ID is always useless. Option 1 lets the user decide • Recommendation: Option 1

  5. Open Issue #2 • Explicitly indicate the party type (rpi-pty-type) or infer from message • Option 1 • Explicit “calling” and “called” party types • Option 2 • Always infer from message, i.e. “calling” in request and “called” in response • Deprecate rpi-pty-type • Option 1 more general than option 2 • Allows “calling” and “called” in other messages than requests and response respectively (European requirement (?)) • Allows for other types of party information in the future (related extensibility issue) • Recommendation: Option 1

  6. Open Issue #3 • Types of Identity Information (rpi-id-type) • Option 1 • User, Subscriber, and Terminal • Option 2 • User only (inferred) • Deprecate rpi-id-type • Option 1 more general than option 2 • Allows different types of identity information to be conveyed which could be important for some network based services • Allows for other types of identity information in the future (related extensibility issue) • Recommendation: Option 1

  7. Open Issue #4 • Define “privacy” parameter as a general URI parameter or restrict to Remote-Party-ID • Option 1 • Let “privacy” parameter apply only to Remote-Party-ID. • Option 2 • Let “privacy” parameter be a general URI parameter • Option 2 more general than option 1 • Not clear why the UA couldn’t just make other URIs “private” to begin with • Significant draft change • More discussion needed

  8. Open Issue #5 • Extensibility of rpi-pty-type and rpi-id-type • Option 1 • Make them extensible • Require RFC and designated expert review • Option 2 • Do not make them extensible • Option 1 more general than option 2 • Enables use of existing privacy mechanism for new types of party and identity information in the future • Potential for abuse, however the required designated expert review can prevent this • Recommendation: Option 1

  9. Open Issue #6 • Names of rpi-pty-types • Currently “calling” and “called”, however somewhat misleading • Alternative suggestions welcome

  10. Open Issue #7 • Cryptographically random identifier in From header field • Leftover from 2543 • No longer required given From-tag uniqueness requirement • Recommendation: • Use “anonymous@localhost” instead

More Related