Speermint Requirements/Guidelines for SIP session peering draft-ietf-speermint-requirements-02

1
SpeermintRequirements/Guidelines for SIP
session peering draft-ietf-speermint-requirement
s-02

• IETF 69 - Monday July 23 2007
• Jean-François Mulé - jfm_at_cablelabs.com, Editor

2
Agenda

• Changes in draft-02
• Scope
• Open Issues
• Detailed Review
• Any other Feedback

3
Changes in draft-02

• http//tools.ietf.org/html/draft-ietf-speermint-re
  quirements-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

4
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

5
Open Issues (1)

• It is difficult to extract or derive requirements
  from all the documented use cases
• VoIP Use Case doc statesthere 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?

6
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

7
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?

8
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 SSPs 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?

9
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 textprevious
  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. Rodrigs 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?

10
Detailed Review (4) - Security Requirements

• Security threat analysis draft-niccolini-speermin
  t-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?

11
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?

12
Thanks.Other Feedback?

• mailtospeermint_at_ietf.org