Page 1 IETF Speermint Working Group Speermint Requirements/Guidelines for SIP session peering draft-ietf-speermint-requirements-02 IETF 69 - Monday July

IETF Speermint Working GroupPage 1

Speermint

Requirements/Guidelines for SIP session peering

draft-ietf-speermint-requirements-02

IETF 69 - Monday July 23 2007

Jean-François Mulé - [email protected], Editor


Agenda

• Changes in draft-02

• Scope

• Open Issues

• Detailed Review

• Any other Feedback


Changes in draft-02

http://tools.ietf.org/html/draft-ietf-speermint-requirements-02

• Aligned text with terminology draft-07

• Clarified intended status and scope of the document

• Added requirement and guidelines from various drafts– draft-elwell-speermint-enterprise-usecases– draft-rosen-speermint-peeringbcp-v1

• Integrated requirements from presence & im requirement draft– draft-houri-speermint-presence-im-requirements– Some requirements were generic and covered by “duplicates”– Some other requirements are specific to IM & presence (Section 4.4.)

• Added some policy parameters based on input and drafts– draft-rosen-speermint-peeringbcp-v1


Scope

• In Scope – The declaration, advertisement

and management of ingress and egress for session signaling and media

– Information related to the Session Establishment Data (SED)

– Security requirements each peer may enforce on its network to accept and secure session exchanges

– Details to determine the minimum set of parameters required to achieve SIP and SDP interoperability.

– Requirements for Signaling path Border Elements, Data path Border Elements (when applicable)

– Some guidelines on what should be considered by an SSP in its peering policy docs

• Out-of-Scope– Media

(e.g., type of media traffic to be exchanged)

– Mechanisms to ensure quality of service for signaling/media

– Layer-3 IP connectivity between the Signaling Path and Data Path Border Elements

– “Traffic capacity control” (e.g. maximum number of SIP sessions at each ingress point, maximum number of concurrent IM or VoIP sessions)

– Accounting


Open Issues (1)

• It is difficult to extract or derive requirements from all the documented use cases

• VoIP Use Case doc states:“there are different requirements between the scenarios and [the VoIP Consolidated Use Case] document serves to help identify the requirements for SIP Peering for VoIP. “

• Different use cases do not necessarily exhibit distinct requirements– E.g. direct and transit peering use cases: the transit PSP

(Section 3.2.1 in [voip-use-cases]) is acting as a direct peer (Section 3.1.2.)

• What do we do about this?


Open Issues (2)

• Other speermint wg documents include hints about potential requirements but these are not discussed on the list for inclusion in BCP/requirement document

• E.g.– Use of RFC 3861 for IM & presence address resolution since draft-ietf-speermint-

architecture-01.txt; not present in IM & presence requirement draft (draft-ietf-speermint-architecture-03 [arch], Section 5.1.1.)

– Implied requirement on SBE to normalize dial-string (011 44) into E.164 numbers ([arch], Section 5.1.1)

– TLS and client cert validation in both [arch], Section 5.2.3 and [voip-use-cases] Section 4.2.3.

– Implied SBE requirement on SUBSCRIBE/NOTIFY ([arch], 5.2.5.)

• What do we as a wg do about these?– Some discussion is probably required on the list– Proposal

» Keep informative language in the architecture/use-case document for document readability, and,

» Ensure the actual requirements are in speermint requirements/guideline BCP


Detailed Review (per wg meeting agenda)

• Current Document Organization– General Requirements: scope, session peering

points, and SED– Signaling and Media Guidelines

» Protocol Specifications» Minimum set of SIP-SDP requirements» Requirements for Presence and IM» Security

– Appendix A (informational): parameters for session policies

Any comments/feedback on document structure?


Detailed Review (2)

• General Requirements– Scope (see previous slide)

– Session peering points» Location of SIP “peering points” or SBEs via RFC 3263 &

RFC 3861 (to be added)» Location of an SSP’s STUN servers via DNS SRV via RFC 3489» What about dynamic declaration/advertisement of DBEs?

Should anything be done?

– Session Establishment Data (SED)» Text on User Identities and SIP URIs, and URI reachability» No requirements, guidelines or mechanisms for retrieving additional

parameters that the outgoing SBEs require to complete the call (without call attempt)

• E.g. list of SIP specs supported, trusted CAs for TLS client certs, etc.

• Current wg consensus seems to be that this will be dealt with offline between SSPs, posted on web page, etc.

» Any other gaps in guidelines for how to deal with SED?

Any comments/feedback on General Requirements?


Detailed Review (3)

• Signaling and Media Guidelines for Session Peering – Protocol Specifications (Section 4.1):

New text based on input from Brian Rosen

– Minimum set of SIP-SDP-related requirements (4.2):» Minor changes in existing text:

previous agreement to reference SIP Hitchhikers’ guide and not further create categories of SIP specifications for session peering

» For indirect or assisted peering, added guidelines for session transparency based on J. Elwell and B. Rodrig’s use cases for enterprise

– Media-related Requirements (Section 4.3): basic, minimal set of guidelines

– Requirements for IM and Presence» Authored by A. Houri, E. Aoki and S. Parameswar» Limited feedback received on previous drafts» Is the list of requirements representative of IM and Presence “session

peering”?

Any comments/feedback?


Detailed Review (4) - Security Requirements

• Security threat analysis: draft-niccolini-speermint-voipthreats identified threats and some solutions

• Signaling Security– Current Section 4.5.2 provide guidelines for SIP over TLS between

SSPs– SSPs SHOULD agree on one or more Certificate Authorities (CAs)

to trust for client/server certs– SSPs should indicate domain policies around SIP Identity (RFC

4474)– Other various and obvious requirements (valid X.509 cert for

SBEs), list of parameters that 2 SSPs should exchange for successful TLS connections

– Referencing work in SIP/SIPPING for certificate management (I-D.gurbani-sip-domain-certs, I-D.ietf-sip-certs)

– Need more reviews from both operators and SIP security folks

• Media Security: mostly TBD Any comments/feedback?


Detailed Review (5) – Policy Parameters

• Appendix A lists various types of parameters that should be considered by

– implementers when deciding what configuration parameters to expose to system admins or management stations, and what parameters to make session-dependent/independent, or domain/peer dependent-independent

– SSPs or federations of SSPs when discussing the technical aspects of a session peering policy

Any comments/feedback?


Thanks.Other Feedback?

mailto:[email protected]

Documents

Page 1 IETF Speermint Working Group Speermint Requirements/Guidelines for SIP session peering draft-ietf-speermint-requirements-02 IETF 69 - Monday July