Peering: A Minimalist Approach

Rohan Mahy

rohan@ekabal.com

IETF 66 — Speermint WG

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

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

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 (author’s 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.

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

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