Speermint Working Group H. Kaplan (Ed.)
Internet Draft Acme Packet
Intended status: Informational R. Penno
Expires: November 2008 Juniper Networks
D. Malas
CableLabs
S. Khan
Comcast
A. Uzelac
Global Crossing
November 3, 2008
SPEERMINT Routing Architecture Message Flows
draft-ietf-speermint-flows-04
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/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 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Kaplan, et al Expires May 3, 2009 [Page 1]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
Abstract
This document describes example message flows associated with the
SPEERMINT routing architecture, relative to various peering
scenarios.
Conventions used in this document
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 RFC-2119 [1]. The
terminology in this document conforms to RFC 2828, "Internet Security
Glossary".
Table of Contents
1. Introduction...................................................3
2. Definitions....................................................3
3. Peering Scenarios..............................................4
4. Basic Peering Message Flow.....................................6
5. On-Demand Peering..............................................8
5.1. Transport Layer Security..................................8
6. Static Peering................................................10
6.1. TLS......................................................10
6.2. IPsec....................................................11
6.3. Co-Location..............................................11
7. Federation Based Peering......................................11
7.1. Central Federation Proxy.................................12
7.2. Central ENUM Federation..................................13
8. Media Relay...................................................14
9. Peering Message Flow Phases...................................15
9.1. Discovery Phase..........................................17
9.2. Security Establishment Phase.............................18
9.3. Signaling Exchange Phase.................................18
9.4. Media Exchange Phase.....................................19
10. Security Considerations......................................19
11. IANA Considerations..........................................20
12. Acknowledgments..............................................20
13. References...................................................20
13.1. Normative References....................................20
13.2. Informative References..................................21
Author's Addresses...............................................21
Intellectual Property Statement..................................22
Full Copyright Statement.........................................22
Acknowledgment...................................................23
Kaplan, et al Expires May 3, 2009 [Page 2]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
1. Introduction
This document shows the message flows associated with the most
relevant SPEERMINT routing architecture peering scenarios. Most of
the message diagrams were based on previous work described within
existing IETF standards documents.
The document focuses on the messages exchanged for the purpose of
Layer 5 peering [7] between two domains. Messages exchanged for the
purpose of setting up SIP sessions within a domain are considered out
of scope and are already defined in other IETF documents.
2. Definitions
SSP: SIP Service Provider, the administrative entity providing SIP
services utilizing SIP. Note that an SSP may be a traditional
Service Provider, an Enterprise, or any administrative domain
context.
LUF: Look-Up Function, the functional step(s) necessary to determine
for a given SIP request, which terminating domain it should be
sent to.
LRF: Location Routing Function, the functional step(s) necessary to
determine for a given SIP request's terminating domain, the path
to follow to reach the terminating domain.
Routing: In the context of this document, it is forwarding of an out-
of-dialog SIP request.
SED: Session Establishment Data, the LUF and LRF data needed and used
to route a SIP request to the next-hop(s) associated with
reaching the terminating domain.
SBE: Signaling-path Border Element, the logical SIP node that
represents the logical boundaries between SSP domains (a.k.a.,
the signaling portion of an SBC, I-BCF, etc.).
SF: Signaling Function, the logical functional role for processing
SIP requests for peering/routing; i.e., the SBE's role.
Kaplan, et al Expires May 3, 2009 [Page 3]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
DBE: Data-path Border Element, the logical node that relays media
between the logical boundaries of SSP domains (a.k.a., the media
portion of an SBC, I-BGF, etc.).
MF: Media Function, the logical functional role for processing media
for peering purposes, including relaying media; i.e., the DBE's
role.
3. Peering Scenarios
This draft separates the Layer 5 peering scenarios into two major
peering scenarios:
o On-demand: In this scenario the SIP proxies in domains A and B
establish a peering relationship driven by the necessity to
deliver a SIP message to another domain, without a pre-existing
relationship. This is sometimes referred as the "email" model.
o Static: In this scenario the peering relationship between proxies
A and B is statically pre-provisioned independent of the
establishment of any SIP session between users in different
domains.
Media for a given SIP session may follow a different path from
signaling, only following the IP routed transport path when crossing
peering domains. Alternatively, media for a given session can be
directed to traverse the same SIP device used for Layer 5 peering,
i.e., the same device that handles signaling when crossing domains.
This produces three different models:
o Media-direct: In this model SIP proxies perform Layer 5 peering
Signaling Function (SF), while media is sent directly between the
User Agent's (UA's) involved in the session, as shown in Figure 1.
Therefore signaling and media follow different paths.
o Integrated: In this model, the device that performs Layer 5 SIP
peering SF/SBE also processes the associated media when crossing
domains, as an MF/DBE, as shown in Figure 2. This function is
usually referred to as media relay and is usually performed by a
B2BUA or SBC (Session Border Controller). See [6] for a complete
discussion of such SBC functions. We will refer to this picture
throughout this document.
Kaplan, et al Expires May 3, 2009 [Page 4]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
o Decomposed: In this model, media is relayed by a DBE/MF which is
physically separated from the SBE/SF. A control protocol,
typically H.248 or MGCP, is used by the SBE to control the DBE.
From the UA and peering domain's perspective, the decomposed SBE
and DBE do not function any differently than an integrated SBC.
For the purposes of this document, one can consider this model as
just a specific variant of the integrated model, and is not
discussed separately.
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | DNS | . . | DNS | .
. | 1 | . . | 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. | . . | .
. | . . | .
. +-------+ . . +-------+ .
. | SF | . . | SF | .
. | Proxy |--------------| Proxy | .
. | 1 | . . | 2 | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . Media . | | .
. | UA 1 |<========================================>| UA 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
Figure 1: Basic Peering Picture (media-direct)
Kaplan, et al Expires May 3, 2009 [Page 5]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
The integrated model is shown below:
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | DNS | . . | DNS | .
. | 1 | . . | 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. | . . | .
. | . . | .
. +-------+ . . +-------+ .
. | SBE/SF| . . | SBE/SF| .
. | & |--------------| & | .
. | DBE/MF|**************| DBE/MF|\ .
. /| | . . | | \ .
. / +-------+ . . +-------+* \ signaling .
. / * . . * \ .
. / * . . * \ .
. / * . . * \ .
. / * media . . * \ .
. / * . . * \ .
. / * . . * \ .
. / * . . * \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . . | | .
. | UA 1 | . . | UA 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
Figure 2: Integrated Peering Picture
In a decomposed model, the Signaling Function (SF) of an SBE, and the
Media Function (MF) of a DBE, are implemented in separate physical
entities. A B2BUA is generally on the SIP path performing the SF. A
vertical control protocol between the SF and MF is out of the scope
of this document.
4. Basic Peering Message Flow
This section depicts the "basic" Peering message flow. This does not
imply this is the most common peering scenario - just a baseline.
Kaplan, et al Expires May 3, 2009 [Page 6]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
The various scenarios differ mostly of how and when peering is
implemented. As stated earlier, peering can be establish dynamically
following the arrival of a message at a border proxy, or statically
based on an agreement between both domains.
Alice SF-1 DNS SF-2 Bob
| | | | |
| INVITE | | | |
|------->| | | |
| 100 | | | |
|<-------| | | |
| | NAPTR | | |
| | Query | | |
| |--------->| | |
| | NAPTR | | |
| | Reply | | |
| |"SIP+D2U" | | |
| |<---------| | |
| | SRV | | |
| | Query | | |
| |--------->| | |
| | SRV | | |
| | Reply | | |
| |<---------| | |
| | | |
| | Peering | |
| | Phase | |
| | [On-Demand] | |
| |<------------------>| |
| | INVITE | |
| |------------------->| INVITE |
| | 100 |---------->|
| |<-------------------| |
| | | 180 |
| | 180 |<----------|
| 180 |<-------------------| |
|<-------| | 200 |
| | 200 |<----------|
| 200 |<-------------------| |
|<-------| | |
| ACK | | |
|------->| ACK | |
| |------------------->| ACK |
| | |---------->|
| Both Way RTP Media |
|<=======================================>|
Kaplan, et al Expires May 3, 2009 [Page 7]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
| | | BYE |
| | BYE |<----------|
| BYE |<-------------------| |
|<-------| | |
| 200 | | |
|------->| 200 | |
| |------------------->| 200 |
| | |---------->|
| | | |
In the integrated model, media would follow the path shown below. All
other signaling call flows remain the same. In the decomposed model,
the media would also go to a MF/DBE functional entity, but it would
just be physically separate from the SF/SBE.
Alice SF/MF-1 DNS SF/MF-2 Bob
| | | | |
| | | | |
| Both Way RTP Media |
|<======>|<==================>|<=========>|
| | | |
5. On-Demand Peering
In the on-demand peering scenario, the relationship between proxies
in domains A and B is driven by the arrival of a SIP message at proxy
A directed to a user in domain B (or vice-versa).
5.1. Transport Layer Security
In case this is in fact the first SIP request between two SSPs in an
on-demand peering relationship, then the SIP request will trigger the
establishment of the TLS connection. Otherwise it is assumed the TLS
connection has been established by some other means and may be
reused.
Kaplan, et al Expires May 3, 2009 [Page 8]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
Alice Proxy 1 DNS Proxy 2 Bob
| | | | |
| | | | |
| INVITE | | | |
|------->| | | |
| 100 | | | |
|<-------| | | |
| | NAPTR | | |
| | Query | | |
| |--------->| | |
| | NAPTR | | |
| | Reply | | |
| |"SIPS+D2T"| | |
| |<---------| | |
| | SRV | | |
| | Query | | |
| |--------->| | |
| | SRV | | |
| | Reply | | |
| |<---------| | |
| | | | |
| | Peering | |
| | [TLS Connection] | |
| |<------------------>| |
| | | |
| | INVITE | |
| |------------------->| INVITE |
| | 100 |---------->|
| |<-------------------| |
| | | 180 |
| | 180 |<----------|
| 180 |<-------------------| |
|<-------| | 200 |
| | 200 |<----------|
| 200 |<-------------------| |
|<-------| | |
| ACK | | |
|------->| ACK | |
| |------------------->| ACK |
| | |---------->|
| Both Way RTP Media |
|<=======================================>|
| | | BYE |
| | BYE |<----------|
| BYE |<-------------------| |
|<-------| | |
| 200 | | |
Kaplan, et al Expires May 3, 2009 [Page 9]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
|------->| 200 | |
| |------------------->| 200 |
| | |---------->|
| | | |
[TBD: add TLS connection for upstream requests?]
6. Static Peering
In the static peering scenario the relationship between proxies A and
B is not driven by a SIP request, but before-hand through manual
provisioning.
6.1. TLS
In this model a TLS connection between proxies A and B is provisioned
following an agreement between the two domains. Creation of the TLS
connection may be established through previous SIP message exchanges,
or by continuous message exchange such as OPTIONS requests/responses.
If Mutual-TLS is used, reverse-path requests may use the same
connection as defined in [13], or separate TLS connections may be
used for each request direction.
Kaplan, et al Expires May 3, 2009 [Page 10]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
6.2. IPsec
In this model an IPSec connection between proxies A and B is
provisioned following an agreement between the two domains.
Typically either transport-mode ESP is used for SIP signaling only,
or tunnel-mode is used for either just signaling, or both signaling
and media. If tunneling is used, media-relay must be performed as
described later. No diagram is shown for the IPsec case, since the
changes are only at the network layer.
6.3. Co-Location
In this scenario the two proxies are co-located in a physically
secure location and/or are members of a segregated network, such as a
VPN. In this case messages between Proxy 1 and Proxy 2 would be sent
as clear text.
Alice Proxy 1 DNS Proxy 2 Bob
| | | | |
| | | |
| | [Peering] | |
| | Co-Location | |
| |<------------------>| |
| | | | |
\ / \ / \
/ \ / \ /
| | | | |
| INVITE | | | |
|------->| | | |
| 100 | | | |
|<-------| | | |
\ / \ / \
/ \ / \ /
| | BYE |<----------|
| BYE |<-------------------| |
|<-------| | |
| 200 | | |
7. Federation Based Peering
Multiple SSP's may be members of the same Federation, such that their
policies and relationships are defined to be the same for a given
federation. Federations are one way for a source and destination
network to find a common set of procedures for peering.
Kaplan, et al Expires May 3, 2009 [Page 11]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
7.1. Central Federation Proxy
Federation rules can dictate that calls are to be routed via a
federation-maintained central SIP proxy. In that case no further
NAPTR/SRV/A lookups need be made. Instead, the INVITE will be sent
directly via a preconfigured connection to that proxy. This proxy
acts as a redirect proxy, returning SIP 3xx responses with the
Contact URI(s) identifying the next target(s), which may need
subsequent DNS resolution per RFC 3263 to resolve. The SIP Redirect
proxy essentially performs the role of the LUF and potentially the
LRF, using SIP as the query protocol.
The following message flow provides an example describing this
process:
Peer Proxy Federation Proxy Peer Proxy Bob
| | | |
| INVITE | | |
|--------------->| | |
| 302 | | |
|<---------------| | |
| ACK | | |
|--------------->| | |
| INVITE | |
|-------------------------------->| INVITE |
| 100 |--------------->|
|<--------------------------------| 180 |
| 180 |<---------------|
|<--------------------------------| |
| | 200 |
| 200 |<---------------|
|<--------------------------------| |
| ACK | |
|-------------------------------->| ACK |
| |--------------->|
| Both Way RTP Media |
|<================================================>|
| | BYE |
| BYE |<---------------|
|<--------------------------------| |
| 200 | |
|-------------------------------->| 200 |
| |--------------->|
Kaplan, et al Expires May 3, 2009 [Page 12]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
7.2. Central ENUM Federation
Another form of centralized Federation is to use an ENUM
infrastructure instead of SIP Redirect Proxy, and thus DNS as the
query protocol for the LUF, and possibly LRF. The originating SSP
performs a NAPTR query to a pre-arranged ENUM server (a private DNS
server deployed for this role), for the destination calling party
E.164 number, with a private domain root for the Federation.
If the ENUM server provides just an LUF function, it will provide SED
data identifying the terminating SSP domain, and any number
portability data required, in its NAPTR response; but then relies on
the originating SSP to either know how to reach the terminating
domain or to perform some means of performing the LRF. If the ENUM
serve provides both, it will resolve not only the number portability
information, if any, but also return the next-hop URI target(s) for
the originating SSP to send the SIP request to.
The following diagram shows a scenario whereby the originating SSP
performs an LUF query using ENUM-DNS to a central Federation ENUM
server, which responds with the resolved peer SSP's domain. In this
particular case the originating SSP can reach the terminating SSP
directly, and happens to perform just a DNS request to resolve the
connection information for the Peer, to reach the Peer's SF-2 SBE.
This is only one particular scenario - many others are possible.
Kaplan, et al Expires May 3, 2009 [Page 13]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
Alice SF-1 ENUM DNS SF-2 Bob
| | LUF| | | |
| INVITE | | | | |
|------->| | | | |
| 100 | | | | |
|<-------| | | | |
| | NAPTR | | | |
| | Query | | | |
| |-------->| | | |
| | NAPTR | | | |
| | Reply | | | |
| |"SIP+E2U"| | | |
| |<--------| | | |
| | SRV | | |
| | Query | | |
| |------------->| | |
| | SRV | | |
| | Reply | | |
| |<-------------| | |
| | | |
| | Peering | |
| | Phase | |
| | [On-Demand] | |
| |<------------------>| |
| | INVITE | |
| |------------------->| INVITE |
| | 100 |---------->|
| |<-------------------| |
| | | 180 |
| | 180 |<----------|
| 180 |<-------------------| |
|<-------| | 200 |
| | 200 |<----------|
| 200 |<-------------------| |
|<-------| | |
| ACK | | |
|------->| ACK | |
| |------------------->| ACK |
| | |---------->|
| Both Way RTP Media |
|<=======================================>|
8. Media Relay
In the event that a source and/or destination SSP are part of a
private network, or peer through a private network, the SSP peers
Kaplan, et al Expires May 3, 2009 [Page 14]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
must enable the SIP signaling and media to route between the peers.
This process is implemented by an SBE and DBE, either in an
integrated or decomposed model. The core of the process is media
relaying, whereby the SBE forces the relay of media through its DBE
by modifying the SDP.
9. Peering Message Flow Phases
The message flow phases are Discovery, Security Establishment,
Signaling Exchange, and Media Exchange. The following flow provides
an overview of the phases. Each of the phases is described
individually in the following subsections. For the following
diagram, the signaling and media exchange phase descriptions have
been omitted for clarity purposes, because their functionality has
not changed for the purposes of peering. However, they have been
explained further in the following subsections.
Kaplan, et al Expires May 3, 2009 [Page 15]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
Alice Peer Proxy DNS Peer Policy/Proxy Bob
| | | | |
|INVITE | | | |
|----------->| | | |
| 100| | | |
|<-----------| | | |
|NAPTR Query | | |
+---->|--------------->| | |
| | NAPTR Reply| | |
Discovery Phase | |<---------------| | |
----------------| |SRV Query | | |
| |--------------->| | |
| | SRV Reply| | |
+---->|<---------------| | |
| | | |
Security Exch. | [TLS Connection] | |
--------------------->|<--------------------------->| |
Phase | INVITE | |
|---------------------------->|INVITE |
| | 100 Trying |------------->|
| |<----------------------------| 180 Ringing|
| | 180 Ringing |<-------------|
| 180 Ringing|<----------------------------| 200OK |
|<------------| 200OK |<-------------|
| 200OK |<----------------------------| |
|<------------| | |
| ACK | | |
|------------>| ACK | |
| |---------------------------->|ACK |
| | |------------->|
| | Both Way RTP Media | |
|<========================================================>|
| | | BYE |
| | BYE |<-------------|
| BYE |<----------------------------| |
|<------------| | |
| 200OK | | |
|------------>| 200OK | |
| |---------------------------->|200OK |
| | |------------->|
Kaplan, et al Expires May 3, 2009 [Page 16]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
9.1. Discovery Phase
The first phase of static or dynamic peering requests is discovery.
The discovery process can be summarized by querying the Location
Routing Function (LRF) to determine the next phase in the message
flow. The discovery phase can take place via a local or external
federation location function. Examples of the function may be
comprised of an ENUM/DNS or redirect server. After the discovery
phase has completed, the peering process will progress to a
subsequent phase, usually the policy or authentication phase. The
following message flows provide examples of the discovery phase.
Discovery phase utilizing an ENUM/DNS server as a location function:
Alice Peer Proxy DNS Peer Proxy
| | | |
|INVITE | | |
|----------->| | |
| 100| | |
|<-----------| | |
|NAPTR Query | |
+---->|--------------->| |
| | NAPTR Reply| |
Discovery Phase | |<---------------| |
-----------------| |SRV Query | |
| |--------------->| |
| | SRV Reply| |
+---->|<---------------| |
|INVITE |
|------------------------------->|
Discovery phase utilizing a REDIRECT server as a location function:
Peer Proxy Federation Proxy Peer Proxy
| | |
| INVITE | |
+---->|--------------->| |
Discovery Phase | | 302 | |
-----------------| |<---------------| |
| | ACK | |
+---->|--------------->| |
| INVITE |
|------------------------------->|
Kaplan, et al Expires May 3, 2009 [Page 17]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
9.2. Security Establishment Phase
The security establishment phase follows the described methods in
previous sections of this document. This phase follows standard
methods described in [2], so the following flow provides an example
of this phase, but does not incorporate all possibilities. This
phase assumes the previous phases were successfully completed or
purposefully omitted per peering implementation.
Peer Proxy Peer Proxy
| |
| INVITE |
+---->|------------------------------->|
| | [TLS Connection] |
Security Exch. | |<------------------------------>|
----------------| | 401 Unauthorized |
Phase | |<-------------------------------|
| | INVITE |
+---->|------------------------------->|
| 100 Trying |
|<-------------------------------|
| 180 Ringing |
|<-------------------------------|
9.3. Signaling Exchange Phase
The signaling exchange phase is a necessary step to progress towards
establishing peering. This phase may incorporate the security
exchange phase, but it is not required. This phase follows standard
methods described in [2], so the following flow provides an example
of this phase, but does not incorporate all possibilities.
Peer Proxy Peer Proxy
| |
| [TLS Connection] |
+---->|<------------------------------>|
| | INVITE |
| |------------------------------->|
Signaling Exch. | | 100 Trying |
-----------------| |<-------------------------------|
Phase | | 180 Ringing |
| |<-------------------------------|
| | 200 OK |
| |<-------------------------------|
| | ACK |
| |------------------------------->|
| | BYE |
Kaplan, et al Expires May 3, 2009 [Page 18]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
| |<-------------------------------|
| | 200 OK |
+---->|------------------------------->|
| |
9.4. Media Exchange Phase
The media exchange phase is negotiated and established during the
signaling exchange phase. This phase follows standard methods
described in [2], so the following flow provides an example of this
phase, but does not incorporate all possibilities.
Alice Peer Proxy Peer Proxy Bob
+---->|INVITE | | |
| |----------->| INVITE | |
| | 100 |------------------>| INVITE |
| |<-----------| 100 Trying |----------->|
Media Exch. | | |<------------------| 100 |
---------------| | | |<-----------|
Phase | | | | 180 |
| | | 180 Ringing |<-----------|
| | 180 |<------------------| 200 |
| |<-----------| 200 OK |<-----------|
| | 200 |<------------------| |
| |<-----------| | |
| |ACK | | |
+---->|----------->|ACK | |
| |------------------>|ACK |
| | |----------->|
| Both Way RTP Media | |
|<===========================================>|
| | | |
| | | BYE |
| | BYE |<-----------|
| BYE|<------------------| |
|<-----------| | |
|200 | | |
|----------->|200 | |
| |------------------>|200 |
| | |----------->|
10. Security Considerations
The level of security required during the establishment and
maintenance of a SIP peering relationship between two proxies can
Kaplan, et al Expires May 3, 2009 [Page 19]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
vary greatly. In general all security considerations related to the
SIP protocol are also applicable in a peering relationship.
If the two proxies communicate over an insecure network, and
consequently are subject to attacks/eavesdropping/etc., the use of
TLS or IPSec would be advisable.
If there is physical security and the proxies are co-located, or the
proxies are situated in a segregated network (such as a VPN), one
could argue that weaker measures are sufficient.
11. IANA Considerations
N/A
12. Acknowledgments
Thanks to Reinaldo Penno for his work as the original author of this
document, and to Otmar Lendl for his contributions.
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001.
[5] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call
Flow Examples", BCP 75, RFC 3665, December 2003.
[6] ETSI TS 102 333: " Telecommunications and Internet converged
Services and Protocols for Advanced Networking (TISPAN); Gate
control protocol".
[7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
Kaplan, et al Expires May 3, 2009 [Page 20]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
[8] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[9] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and
E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.
13.2. Informative References
[10] Meyer, D., Malas, D., "SPEERMINT Terminology", Internet Draft,
draft-ietf-speermint-terminology-16, February 2008.
[11] Boulton, C., Rosenberg, J., Camarillo, G., "Best Current
Practices for NAT Traversal for SIP", Internet Draft, draft-
ietf-sipping-nat-scenarios-08, April 2008.
[12] Camarillo, G., Penfield, R., Hawrylyshen, A., "Requirements
from SIP (Session Initiation Protocol) Session Border
Controller Deployments", Internet Draft, draft-camarillo-
sipping-sbc-funcs-06, June 2008.
[13] Gurbani, V., Mahy, R., Tate, B., " Connection Reuse in the
Session Initiation Protocol (SIP)", draft-ietf-sip-connect-
reuse-11, July 2008.
Author's Addresses
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803, USA
Email: hkaplan@acmepacket.com
Daryl Malas
CableLabs
858 Coal Creek Circle
Louisville, CO, 80027, USA
EMail: d.malas@cablelabs.com
Sohel Khan, Ph.D.
Comcast Cable Communications
USA
Email: sohel_khan@cable.comcast.com
Kaplan, et al Expires May 3, 2009 [Page 21]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
Reinaldo Penno
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, CA, USA
Email: rpenno@juniper.net
Adam Uzelac
Global Crossing
1120 Pittsford Victor Road
PITTSFORD, NY 14534, USA
Email: adam.uzelac@globalcrossing.com
Intellectual Property Statement
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.
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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
Kaplan, et al Expires May 3, 2009 [Page 22]
Internet-Draft draft-ietf-speermint-flows-04 November 2008
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kaplan, et al Expires May 3, 2009 [Page 23]