Subject: [Speermint] Re: draft-rosen-speermint-peeringbcp-v1-00.txt

From: Otmar Lendl <[email-masked]>
Date: Tue, 24 Oct 2006 16:59:52 +0200

Brian,

here are some comments on draft-rosen-speermint-peeringbcp-v1-00.txt:

That's a well-written draft which will be helpful for a productive
discussion in San Diego.

>2.  Overview
>
>   The SIP standard [RFC3261] models much of its protocol operations on
>   familiar Internet applications such as email and the web.  For
>   example, SIP clients contact remote domains by resolving SIP URIs
>   which are, like email addresses, composed of a username and domain
>   name portion.  As is the case with email, a client need not have any
>   pre-association with a remote domain in order to initiate a session
>   with a user in that domain.  The security of SIP is designed to
>   counter the sorts of threats that arise on the Internet - threats
>   based on eavesdropping, packet spoofing, impersonation of identity,
>   and the like.  

Good points.

>   Endpoints must assume responsibility for most of these
>   security functions.  Like email and the web, SIP assumes that the
>   Internet end-to-end model applies: that is, that entities using SIP
>   have unimpeded connectivity to one another.

This doesn't follow. SIP works fine if the user endpoints have
firewalls which restrict SIP communication (not RTP) to their respective
proxy servers only. Just use Record-Route: and you're done.

You won't win bonus points with the SIP purists, but it works fine.

>   There are however operational models in which the assumptions of
>   traditional Internet applications do not hold up.  The end-to-end
>   reachability of user agents is commonly obstructed by network-layer
>   impediments like network address translators (NATs) or firewalls.
>   Many SIP user agents, and SIP deployments, utilize telephone numbers
>   rather than email-like SIP URIs, which introduces requirements for a
>   new resolution process in the routing of requests.  Some SIP service
>   providers are also uncomfortable leaving the management of security
>   to user agents, for a variety of reasons.
>
>   To a voice service provider that leverages SIP in a commercial
>   offering, these concerns are all basic issues of usability.  Most SIP
>   user agents today have dial pads, and users are accustomed to the use
>   of telephone numbers of voice applications.  Without a transparent
>   and automatic NAT traversal function such as ICE (which in turn
>   relies on STUN and TURN services), SIP calls on the public Internet
>   may face serious problems establishing media paths.  Users similarly
>   cannot be burdened with understanding and supporting security
>   functions.

Yes, sure. Then just firewall them and route all sip messages via the
provider's proxy which handles the NAT and security requirements.

>   Solving these concerns also motivates voice service providers to
>   establish formal peering relationships with one another.  

The concerns listed above are an argument why SIP end-devices should
not talk SIP directly to anybody on the Internet. These concerns are
completely orthogonal on whether service providers should can run open
SIP ingress points.

The concerns below are more important:

>   Peering
>   represents an agreement between parties to permit the exchange of
>   traffic, generally in accordance with some pre-established policy.
>   Without agreement between two VSP domains, for example, on how
>   telephone numbers are resolved, it is impractical for users in
>   different domains to call one another.  Security, and in particular
>   authorization, is perhaps the most fundamental reason for peering.
>   The email model, while quite successful, has a very widespread
>   problem with undesirable traffic (namely spam), and a comparable
>   problem for SIP could be quite harmful to commercial offerings.
>   Peering agreements would allow providers to trace accountable sources
>   of undesired traffic and to make appropriate authorization decisions
>   based on traffic sources.

These are the real issues we face in speermint. IMHO and all that.

>   Peering at the session layer can occur on a bilateral basis or a
>   multilateral basis, where the latter generally takes the form of a
>   federation (typically in an "assisted" peering configuration).  At

(We need to clarify the use of the term "federation". I'm not 100%
sure we're on the same page there. I'll expand that in a seperate mail.)

>   lower layers of the Internet architecture, there are also various
>   forms of bilateral and multilateral connections which are established
>   between Internet service providers; the more service providers
>   require interconnection, however, the less attractive bilateral
>   connections become, if only because the cost of constructing physical
>   links between networks becomes unwieldy.  While it might seem that

Why "physical links"? If you're just worried about SPIT, and thus want
to accept incoming calls only from pre-screened peering partners, then
TLS with appropriate certificates over the public Internet is just fine.
There is no need to establish physical links just because you want to
know whom you're talking to.

>   there is no similar difficulty with the establishment of bilateral
>   peering at the session layer, there are a number of reasons why voice
>   service providers might want to minimize the number of connections
>   they establish to peer networks: for example, to reduce load on
>   gateways (SBCs and IPSec gateways), or to simplify authorization or
>   routing decisions by delegating that responsibility to network
>   elements operated by the federation.

Could be.

>
>   Moreover, if there are media-based applications which need to be made
>   available to the federation as a whole, a point of lower layer
>   interconnection, such as a traditional layer 3 interexchange point,
>   is an ideal place to stage them.  Any such applications like
>   transcoders and media relays would best be situated in a layer 3
>   point of interconnection.

Fine.

>
>   The following sections detail some of the functions that might be
>   performed at a peering point and briefly explain how they benefit
>   from being deployed in a federation environment.
>
>2.1.  Addressing and Routing
>
>   Several forms of private directories are useful in a peering context.
>   Aside from the widely-attested need to translate telephone numbers
>   into an identifier that can be routed on the Internet (typically via
>   ENUM or an ENUM-like mechanisms), there is a further need in a
>   peering environment to manage points of egress and ingress on the
>   networks of peers.  

I'm not sure I get the correct meaning here: Do you mean ingress/egress
point of one VSP towards other VSPs inside a shared federation, or
do you mean the ingress point of the federation over which someone
external to that federation can reach federation members?

>   While this can take the form of a conventional
>   DNS lookup, such a lookup could return IP addresses that are only
>   routable within a peering point, thereby restricting their access to
>   the federation.
>
>2.2.  Connectivity
>2.3.  Security (Accountability)
>2.4.  Quality
>2.5.  Protocol Mediation

Ok, fine.

>2.6.  Model
>3.  Responsibilities of Federations

As mentioned above, I'd also accept more lightweight federations.
Otherwise, that's a good list of things a federation can manage.

>3.1.6.  CODEC choices

An open question here is whether such strict rules on the codecs
are sensible. Perhaps yes, for established media types. We need to
be careful that such federations won't become the bottlenecks when
deploying new SIP - based applications.

>
>3.4.  Routing
>
>   The Federation MUST specify the mechanism by which peers discover
>   routing information for the exchange of traffic.  Routing mechanisms
>   MUST permit any peer to discover how to route to any other peer's
>   subscribers (or, in the case of a transit peer, the indirect peer's
>   subscribers) based on the Address of Record.  Where transit peers are

Sorry, I have difficulties parsing that sentence. Is this routing
based on SIP AoRs and thus domains?

Could you please provide a definition of "transit peer"?

>   permitted, the Federation MUST either prohibit two or more transit
>   peers from providing access from the same indirect peer (requiring
>   the indirect peer to choose which transit peer represents it at the
>   Federation), or provide provide mechanisms allow an origination
>   network to choose from more than one transit peer who provides
>   transit to the indirect peer.
>
>   For interoperability reason's, each Federation MUST support at least
>   a Federation supplied ENUM query interface where the Federation
>   supports TN based addressing.  If the ENUM data is not in the public
>   DNS tree, the Federation MUST support a provisioning mechanism for a
>   peer to supply it's TNs for peering

Shouldn't that better be formulated as

 If a Federation supports TN based addressing, then it MUST either refer
 to a public ENUM tree or a support a Federation supplied ENUM query interface.

or do I misread the intentions?

>   The Federation SHOULD provide mechanisms for peers to change their
>   routing information dynamically.  The change mechanism SHOULD have
>   reasonable ways to bound the time from the initiation of the change
>   to it's effectivity for all peers in the Federation

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint