Page 1 IETF Speermint Working Group Speermint Requirements/Guidelines for SIP session peering draft-ietf-speermint-requirements-02 IETF 69 - Monday July Jean-François Mulé - Editor

Page 2 IETF Speermint Working Group Agenda Changes in draft-02 Scope Open Issues Detailed Review Any other Feedback

Page 3 IETF Speermint Working Group Changes in draft-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

Page 4 IETF Speermint Working Group 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

Page 5 IETF Speermint Working Group 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 in [voip-use-cases]) is acting as a direct peer (Section ) What do we do about this?

Page 6 IETF Speermint Working Group 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 ) –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 and [voip-use-cases] Section –Implied SBE requirement on SUBSCRIBE/NOTIFY ([arch], ) 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

Page 7 IETF Speermint Working Group 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?

Page 8 IETF Speermint Working Group 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?

Page 9 IETF Speermint Working Group 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?

Page 10 IETF Speermint Working Group Detailed Review (4) - Security Requirements Security threat analysis: draft-niccolini-speermint- voipthreats identified threats and some solutions Signaling Security –Current Section 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?

Page 11 IETF Speermint Working Group 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?

Page 12 IETF Speermint Working Group Thanks. Other Feedback?