Peering: A Minimalist Approach

1
Peering A Minimalist Approach

• Rohan Mahy
• rohan_at_ekabal.com
• IETF 66 Speermint WG

2
What is the eventual output of Speermint?

• IMO Our output is a peering convention
  documented in one or more BCPs
• Consequence 1 We are describing a specific way
  to USE a set of protocols (SIP, ENUM, DNS,
  etc..). We are not defining a protocol.
• Consequence 2 Multiple conventions are possible,
  but we should define ONE. Documenting multiple
  conventions is inconsistent with BCP status, is
  bad for interoperability, and makes more work for
  everyone.
• Analogy SMTP is used between most mail servers,
  but does not prevent a group of consenting
  domains from using a proprietary mail exchange
  protocol among themselves

3
A Minimal Approach

• Discovery
• Determine if target address is external
• If its an E.164 address, check User ENUM
• If no records in User ENUM check Carrier ENUM
  (for at least sip and pstn enumservices)
• If you get an im or pres URI follow RFC 3861
• Peering
• Once you get a sip or sips URI, follow RFC 3263
• Connect via TLS to peer for mutual authentication
• Exchange traffic. Use the Identity header to
  assert Identity

4
To TLS or not to TLS

• Options
• Use no signaling protection
• Not allowed at IETF, see BCP 61 / RFC 3365
• Use sips (e2e TLS)
• currently impractical. would not be able to
  serve the bulk of the community, since most
  endpoints do not support sips
• Use SIP with TLS only over the carrier to carrier
  hop (authors proposal)
• author asserts this is practical, deployable, and
  easier overall than using IPsec. How do we
  measure if this assertion is valid?
• Use IPsec using a profile like that in RFC 3788
• does not provide authentication of previous/next
  hop
• requires large-scale manual configuration of
  source IP addresses to provide any security
• Allow use of either TLS or IPsec
• requires everyone to implement both and negotiate
  one. A worst of both worlds solution.

5
Trust issues

• what mechanisms are acceptable for authentication
  purposes? (ex certificate authentication w/
  trusted root)
• cacert.org (free cert) may be acceptable for
  authentication, but provides no additional
  authorization context
• how does each peer decide that the other side is
  authorized? may be based on who the trust root
  is...
• peer with a fixed list of carriers
• only peer with folks with cert signed by one of
  my federations / peering clubs
• peer with anyone with a good enough reputation or
  accreditation score (from one of my peering
  clubs).
• peer with anyone unless they are on the blacklist
  (like SMTP current practice)
• IMO Speermint needs to provide/document the
  tools. Authorization needs to be left as local
  policy

6
Federations terminology

• My draft describes how to connect to someone
  using an example peering convention. It assumes
  that both carriers somehow authorized peering
  based on strong authentication. (think of this as
  external peering). There can still be some
  club that helps make authorization decisions.
• Draft mentions a federation of domains to mean
  a group of domains that acts like a single domain
  for the purposes of the speermint peering
  convention (think of this as internal
  peering). Outside our scope?
• We need to come up with terms for both of these