One document matched: draft-rosen-speermint-peeringbcp-v1-00.txt
speermint B. Rosen
Internet-Draft NeuStar
Intended status: Standards Track November 13, 2006
Expires: May 17, 2007
Best Current Practices for Session Peering on the Internet by Carriers
through Federationsr
draft-rosen-speermint-peeringbcp-v1-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 17, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo defines a first version Best Current Practice for peering
among a federation of voice or other multimedia service providers
Rosen Expires May 17, 2007 [Page 1]
Internet-Draft BCP for Peering Through Federations November 2006
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Addressing and Routing . . . . . . . . . . . . . . . . . . 4
2.2. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Security (Accountability) . . . . . . . . . . . . . . . . 5
2.4. Quality . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Protocol Mediation . . . . . . . . . . . . . . . . . . . . 6
2.6. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Responsibilities of Federations . . . . . . . . . . . . . . . 6
3.1. Federation Static Policies . . . . . . . . . . . . . . . . 6
3.1.1. Membership . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Identity . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Media Exchange . . . . . . . . . . . . . . . . . . . . 7
3.1.4. Capacity Controls . . . . . . . . . . . . . . . . . . 7
3.1.5. Protocol Specification . . . . . . . . . . . . . . . . 7
3.1.6. CODEC choices . . . . . . . . . . . . . . . . . . . . 8
3.1.7. Billing . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Layer 3 interconnection . . . . . . . . . . . . . . . . . 8
3.3. Layer 5 interconnection . . . . . . . . . . . . . . . . . 8
3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Transcode . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Capacity Controls . . . . . . . . . . . . . . . . . . . . 9
3.8. Protocol Mediation . . . . . . . . . . . . . . . . . . . . 9
4. Responsibilities of peers . . . . . . . . . . . . . . . . . . 9
4.1. Conformance to Policies . . . . . . . . . . . . . . . . . 9
4.2. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Transcode . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Rosen Expires May 17, 2007 [Page 2]
Internet-Draft BCP for Peering Through Federations November 2006
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
It is assumed that the reader is familiar with the terminology and
acronyms defined in [RFC3261]
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. 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.
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.
Solving these concerns also motivates voice service providers to
establish formal peering relationships with one another. Peering
Rosen Expires May 17, 2007 [Page 3]
Internet-Draft BCP for Peering Through Federations November 2006
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.
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
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
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.
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.
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
Rosen Expires May 17, 2007 [Page 4]
Internet-Draft BCP for Peering Through Federations November 2006
networks of peers. 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
Most NAT traversal schemes, such as TURN, require the availability of
a relay that is reachable by both parties in a call. A peering point
is a natural place to stage such a relay precisely because its
position in the network is unlikely to introduce additional latency
in the media by lengthening the call path.
2.3. Security (Accountability)
SIP can be used in constrained environments, effectively closed IP
networks, where the threats that are quite plausible on the public
Internet become very unlikely - especially environments that are
based on traditional telephone networks. In those closed
environments the use of the baseline SIP security mechanisms may seem
very unattractive. Some form of transitive trust is typically viewed
as sufficient in this sort of environment. The use of network-layer
security gateways that connect individual networks to a closed
peering point VLAN would be one example of how this might operate.
Certain application-layer functions can assist with the establishment
of transitive trust and the management of service provider
authorization based on that trust. For example, mechanisms like
RFC3325 or RFC4474, which provide assurance of the identity of the
originator of a SIP request, can be performed by a SIP proxy server
resident in the peering point. Note that especially when telephone
number translations are centrally managed by the federation,
providing identity functions for Caller-ID typical must also be
managed by the federation.
2.4. Quality
The use of protocols to establish quality of service across a traffic
path in an IP network is quite controversial, especially when tied to
a real-time application like voice over IP. Traffic engineering,
management of quality across a particular link, is more common and
generally less complex than resource reservation on a per-call basis.
Moreover, the extremely large deployments of certain VoIP
applications on the public Internet which lack any per-call resource
reservation have created a great deal of skepticism about the need to
incur any significant expense to assure quality.
Layer 3 peering points are general points of optimal quality in the
Rosen Expires May 17, 2007 [Page 5]
Internet-Draft BCP for Peering Through Federations November 2006
network from a latency and bandwidth perspective, and accordingly
they are likely to be the best place to stage any network-based
mechanism which would help to assure call quality.
2.5. Protocol Mediation
[[ unsure if we'd want to talk about different SIP "variants" and the
normalization of SIP signaling, this is just a placeholder entry ]]
2.6. Model
Directories NAT SIP
+---+ +---+ +---+ +---+ 3325
| | | | | | | |
+---+ +---+ +---+ +---+ 4474
| | | |
| | | |
Peering +--+------+------+------+---------
Point | Applications
--- |
Peered / \ |
Network ---------| +--------+
//\ /
// -+-
// |
// |
/ |
Peered |
Network |
Peered
Network
3. Responsibilities of Federations
3.1. Federation Static Policies
Federations must establish explicit policies on at least the
following matters. Such policies may be in in the form of a contract
or other agreement between the federation and peers, a web page, or
other prominant mechanism. In some cases, the federation MAY
explicity permit or prohibit parts of the policy described to be a
matter for bilateral agreements within the federation. In this
version of the BCP, we provide no standardized way to express this
form of policy.
Rosen Expires May 17, 2007 [Page 6]
Internet-Draft BCP for Peering Through Federations November 2006
3.1.1. Membership
The Federation MUST specify who is allowed to peer at the federation,
and how the peers are made known to one another. The policy MUST
include a statement of whether indirect (i.e. transit) peers are
permitted.
3.1.2. Identity
The Federation MUST specify the requirements on peers to identify
users. The Federation MAY permit [RFC3325] asserted identity. The
Federation SHOULD permit [RFC4474] Identity. Federations supporting
RFC4474 MUST specify the CA(s) permitted to issue certificates of the
authentication service (which MAY be operated by the Federation).
The Federation policy MUST specify the date maximum descrepancy
period, The policy MUST specify what is permitted in the display name
of the From: header, and what mechanisms peers must have to control
such content.
3.1.3. Media Exchange
The Federation MUST specify mechanisms for the interchange of media
among the peers. This MUST include mechanisms for NAT traversal.
3.1.4. Capacity Controls
The Federation MUST specify policy to control the traffic sent to and
recieved by peers. The policy SHOULD include limits on the maximum
number of active calls, maximum number of calls/messages per
specified unit time and the aggregate media bandwidth.
Specifications for both aggregate traffic to/from the federation as
well as limits between two peers MAY be specified.
The Federation MAY specify policy for individual ingress/egress
elements as well as total traffic to/from a peer.
Federations MAY permit peers to specify and/or form bilateral
agreements on the limits. This version of the BCP does not specify
mechanisms for dynamic discovery or modification of such policies.
3.1.5. Protocol Specification
The Federation MUST specify details of the (SIP) signaling messages
that peers must conform to. Such specification SHOULD include
minimal extensions that MUST be supported, and what options MUST be
supported, MUST NOT be supported or MAY be supported. This
specification SHOULD include a description of the services that are
expected to be supported across the Federation, and the signaling
Rosen Expires May 17, 2007 [Page 7]
Internet-Draft BCP for Peering Through Federations November 2006
associated with such services.
3.1.6. CODEC choices
The federation defines a codec policy to which all peers must adhere
which would include designation of one or more mandatory to deploy
codec and/or local transcode capability for each supported media type
(audio, video, text) so that all calls can successfully complete
offer/answer exchange. Consideration should be given in specifying
mandatory-to-deploy codecs to include at least one that has minimal
degradation of signal fidelity when two transcodes are required to
achieve actual end to end compatibility.
3.1.7. Billing
The Federation MUST specify what charging mechanisms for the exchange
of traffic it permits, and any support for such practices (e.g. CDR
production) it provides. Where the Federation provides explicit
billing arrangements, such arrangements must be described, including
currency choices.
3.2. Layer 3 interconnection
The federation MUST specify and/or provide the mechanism by which
peers exchange packets at the TCP/IP layer. This may involve
addrressing issues (if not using public IP addresses), and VPN or
other tunneling mechanisms. The federation MUST detail the processes
by which peers establish, text and maintain their TCP/IP connections.
3.3. Layer 5 interconnection
The Federation MUST provide a mechanism for discovery and
addressability of multiple ingress elements (proxy servers, SBCs or
B2BUAs) from multiple egress elements to allow exchange of signaling
between the peers. Where multiple ingress elements are permitted,
the Federation must specify how origination peers select one of the
ingress elements, and how termination peers may control such
selection mechanisms. This version of the BCP does not define
automatic load sharing or overload recovery mechanisms.
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
permitted, the Federation MUST either prohibit two or more transit
Rosen Expires May 17, 2007 [Page 8]
Internet-Draft BCP for Peering Through Federations November 2006
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
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
3.5. NAT Traversal
The Federation MAY provide facilities to assist NAT traversal,
including STUN and TURN servers.
3.6. Transcode
A Federation MAY provide transcode capability. If it does, it MUST
specify the mechanism by which peers engage it's transcoder service.
3.7. Capacity Controls
A Federation MAY provide mechanisms to monitor and/or limit capacity.
This may take the form of mechanisms to determine and report traffic
(active calls, calls/messages per unit time, media bandwidth) as well
as mechanisms to limit traffic to federation/peer policy.
3.8. Protocol Mediation
A Federation MAY provide protocol mediation services to peers which
would ameliorate protocol specification limits described in
Section 3.1.5
4. Responsibilities of peers
4.1. Conformance to Policies
Peers MUST adhere to the policies of the Federation
Rosen Expires May 17, 2007 [Page 9]
Internet-Draft BCP for Peering Through Federations November 2006
4.2. Identity
Each peer must make certain the identity of the originating and
terminating endpoints are reliably marked. If [RFC3325] is permitted
by the Federation, the peer MUST restrict access to its services to
its subscribers, provide a reliable authentication mechanism to
identify them, and assert P-A-I with the actual TN for that endpoint.
The peer MUST NOT allow endpoints to assert their own P-A-I unless
the peer checks the validity of the assertion. If the Federation
permits [RFC4474] identity, the peer MUST operate an authorization
service or make a 3rd party service available to its subscribers that
meet the policy of the Federation. The certificate of the
authorization service MUST be signed by a CA authorized by the
Federation. The peer SHOULD operate a verification service to
validate Identity assertions in traffic recieved from the Federation.
4.3. Transcode
Where the peer permits endpoints to offer a codec list that does not
contain a codec on the federation mandatory-to-deploy list, the peer
must provide transcode capability to at least one of the codecs on
the federations list for each type of media. The trancoder should be
transparent to another federation peer; the offer/answer from the
peer should include a codec on the federation's list, with no action
required by the other side to engage the transcoder (unless it has
its own, equivalent transcode issue),
5. Security Considerations
[RFC3261].
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
Rosen Expires May 17, 2007 [Page 10]
Internet-Draft BCP for Peering Through Federations November 2006
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
Author's Address
Brian Rosen
NeuStar
470 Conrad Dr
Mars, PA 16046
US
Phone: +1 724 382 1051
Email: brian.rosen@neustar.biz
Rosen Expires May 17, 2007 [Page 11]
Internet-Draft BCP for Peering Through Federations November 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rosen Expires May 17, 2007 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-20 16:55:09 |