P2P-SIP BOF J. Quittek
Internet-Draft M. Stiemerling
Expires: August 31, 2006 T. Dietz
S. Niccolini
NEC
February 27, 2006
Problem Statement for SIP-signalled Peer-to-Peer Communication across
Middleboxes
draft-quittek-p2p-sip-middlebox-00
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 August 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Middleboxes, particularly firewalls and network address translators,
are essential components of today's Internet infrastructure. They
are designed to support client-server applications well, but very
often they are obstacles for peer-to-peer communication. This memo
discusses middlebox traversal issues of SIP-based peer-to-peer
Quittek, et al. Expires August 31, 2006 [Page 1]
Internet-Draft SIP P2P Middlebox Problem February 2006
communication. Required communication steps are analyzed concerning
their potential constraints caused by middleboxes. The requirements
derived from this analysis are compared with the capabilites of
currently available middlebox traversal methods and SIP signaling
standards. The comparison identifies open issues that need to be
considered when designing standards for a SIP-based peer-to-peer
communication infrastructure.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Middlebox Issues of SIP-based Peer-to-Peer Communication . . . 3
2.1. Step 1: Middlebox Detection . . . . . . . . . . . . . . . 4
2.1.1. Communication Means Detection . . . . . . . . . . . . 4
2.1.2. NAT Parameter Detection . . . . . . . . . . . . . . . 5
2.2. Step 2: Registration . . . . . . . . . . . . . . . . . . . 5
2.3. Step 3: Search and Connect Relay . . . . . . . . . . . . . 6
2.4. Step 4: Address Lookup . . . . . . . . . . . . . . . . . . 7
2.5. Step 5: Connection Establishment and termination . . . . . 7
3. Middlebox Traversal Methods . . . . . . . . . . . . . . . . . 7
3.1. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Network-initiated Middlebox Signaling . . . . . . . . . . 8
3.3. Terminal-initiated Middlebox Signaling . . . . . . . . . . 9
3.3.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. UPnP . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.3. SOCKS and RSIP . . . . . . . . . . . . . . . . . . . . 9
3.3.4. NSIS NATFW NSLP . . . . . . . . . . . . . . . . . . . 10
4. Open Issues for SIP-based Peer-to-Peer Communication . . . . . 10
4.1. SIP-related Issues . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Terminal Reachability . . . . . . . . . . . . . . . . 10
4.1.2. Communication Service Requirement . . . . . . . . . . 11
4.1.3. Communication Service Offering . . . . . . . . . . . . 11
4.2. SIP-unrelated Issues . . . . . . . . . . . . . . . . . . . 11
4.2.1. Middleobox Detection Beyond UDP . . . . . . . . . . . 11
5. Security considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Quittek, et al. Expires August 31, 2006 [Page 2]
Internet-Draft SIP P2P Middlebox Problem February 2006
1. Introduction
Firewall and Network Address Translators (NATs) are essential
components of today's Internet infrastructure. They belong to the
class of middleboxes [RFC3234] and are widely used for protecting
networks, connecting private networks to the public Internet, and
further purposes. They are designed to support client-server
applications well, but very often they are obstacles for peer-to-peer
communication.
This memo analyzes middlebox traversal issues and problems of SIP-
based peer-to-peer communication. The analysis concerns signaling
across middleboxes as well as data streaming. It is conducted for
each individual step that is expected to be required for SIP-based
peer-to-peer communication. Required steps are derived from
observation of existing peer-to-peer applications and from the
general requirements for SIP-based peer-to-peer Internet telephony
described in [I-D.baset-sipping-p2preq]. The analysis considers
requirements for middlebox control as well as for SIP signaling
required specifically for traversing middleboxes and it is performed
for the terminal side as well as for the peer-to-peer infrastructure
side.
The analysis in section Section 2 is followed by an overview of
existing middlebox traversal techniques in section Section 3.
Section Section 4 compares existing SIP capabilities and available
common middlebox traversal methods against the requirements
identified in section Section 2. The result describes four issues,
three SIP-related, one SIP-unrelated, that should be considered when
designing standards for a SIP-based peer-to-peer communication
infrastructure.
2. Middlebox Issues of SIP-based Peer-to-Peer Communication
This section discusses steps of SIP-based peer-to-peer communication
across middelboxes. Not all steps are required for all possible
scenario variations and depending on design and implementation of
SIP-based peer-to-peer communication infrastructures and terminals,
the sequence of steps may be varied.
The steps discussed in the following subsections are
* middlebox detection,
* registration,
* search for relays,
Quittek, et al. Expires August 31, 2006 [Page 3]
Internet-Draft SIP P2P Middlebox Problem February 2006
* address lookup,
* call setup,
* call termination.
2.1. Step 1: Middlebox Detection
Detecting middleboxes in the signaling path or the data streaming
path is a step that usually should be performed by a general SIP
terminal each time it gets connected to an access network. The step
is not required if the terminal receives this information by manual
configurations or by interaction with a management system.
This step can be carried out explicitly and separately by using
special protocols and/or servers designed and deployed for this
particular purpose. But it can also be integrated in the steps
described in the following subsections.
The information gathered by middlebox detection concerns available
communication means and NAT parameters. Efficient methods may
perform both checks at once.
Existing SIP terminals and peer-to-peer terminals for voice over IP
use special protocols for this detection step, such as the STUN
protocol [RFC3489]. The availability of detections techniques is
discussed in section Section 3.3
2.1.1. Communication Means Detection
The terminal needs to detect the communication means that are
available for
* registering with the peer-to-peer infrastructure,
* incoming and outgoing signaling within the peer-to-peer
infrastructure,
* data streaming to and from other terminals or relays.
Depending on the requirements for the actions listed above, checks
will include the availabilbity of
* sending and receiving UDP packets,
* the capability of opening incoming and outgoing TCP
connections,
* the options to use certain fixed port numbers that are used
within the peer-to-peer infrastructure,
* the option to relay or tunnel signaling messages and streamed
data if the means for regular transport are too restrictive.
Many existing SIP solutions need UDP for signaling as well as for
Quittek, et al. Expires August 31, 2006 [Page 4]
Internet-Draft SIP P2P Middlebox Problem February 2006
data streaming. They do not need any support by TCP. However, this
is expected to change. In order to protect SIP signaling from
several kinds of attacks, SIP signaling over TLS [RFC2246] or other
more secure protocols is currently considered. If the chosen secure
solution is based on TCP or uses IPsec [RFC4301], then more than just
UDP connectivity needs to be checked.
2.1.2. NAT Parameter Detection
If a NAT was detected between the terminal and the peer-to-peer
infrastructure, then it may be necessary to explore the properties of
the present network address translation. Particularly, the type of
NAT and the assigned public IP address and port number need to be
determined if a NAT is present.
Basic types of NATs are described in [RFC2663]. Further types are
described in the terminology section of [RFC3489].
2.2. Step 2: Registration
Once the terminal has sufficient information about middleboxes
between itself and other parts of the peer-to-peer infrastructure, it
can register itself using a communication means that has proven to be
available.
Typically, a registration would be performed as a client-server
operation that is permitted by most NAT and firewall configurations.
However, in highly restrictive environments, there might be a need
for relaying or tunneling the registration, because direct access to
registration servers or the agreed port number for this purpose is
blocked. In such a case, the search for a relay that is described in
the following section needs to be made before registering.
The registration step includes up to four actions
* authentication of the user
The authentication can be integrated into SIP signaling or into
another protocol that is used within the peer-to-peer
infrastructure. In general, also peer-to-peer infrastructures
without authentication could be used, but the practical use
might be limited in today's Internet. It is recommendable that
the user authenticates itself at the peer-to-peer
infrastructure. However, in oder to increase security (and
avoid potential man-in-the-middle attacks) it is desirable that
the peer that receives the user authentication authenticates
itself at the user.
Quittek, et al. Expires August 31, 2006 [Page 5]
Internet-Draft SIP P2P Middlebox Problem February 2006
* notification of communication capability and willingness
The user need to notify the peer that receives its registration
about its communication capabilities and its willingness to
receive session invitations.
If during the middlebox detection step it was found that a
relay is needed for communication with other terminals, then it
might be required for the registration to indicate that the
terminal is not at all able to communicate. If this problem
can be solved by connecting to a relay in step 3, the
registration of communication capabilities can be updated.
* registration of contact parameters
The user needs to register its contact parameters, such as IP
address and port numbers at which it can receive invitations to
calls. These values might depend on the result of the
middlebox detection performed in step 1. If a relay is
required for signaling or for data streaming, then this
information cannot be provided before the relay has been found
and connected.
* notification of service provisioning capability and willingness
The user need to notify the peer that receives its registration
about its capabilities and willingness to offer services to
other users of the peer-to-peer infrastructure, such as
authentication relaying, signaling relaying, lookup service
provisioning, data stream relaying, etc.
These actions can be performed separately using different protocols,
but in an efficient solution, they are all fully integrated into SIP
signaling.
2.3. Step 3: Search and Connect Relay
In case the middlebox detection in step 1 indicated that there is a
need for relaying signaling and/or data streaming, the terminal can
request suggestions for or assignment of a relay of the peer-to-peer
infrastructure In implementations this step can be integrated with
the registration, but logically, it is a separate action.
There are several ways of finding a suited relay, but since relays
are considered parts of the peer-to-peer infrastructure, the
selection of the relay to use will probably be based on a list of
suggested relays that the terminal receives from the peer at which it
registered or via a lookup service that was made available by the
registration. The actual choice of a relay may depend on the results
of the middlebox detection in step 1.
The requirements for SIP-based peer-to-peer Internet telephony in
Quittek, et al. Expires August 31, 2006 [Page 6]
Internet-Draft SIP P2P Middlebox Problem February 2006
[I-D.baset-sipping-p2preq] suggest that a relay should be located
such that the communication delay is not significantly increased.
This may imply that different relays are chosen for calls to
different other peers which requires a call-by-call search for a
relay.
After a suited relay has been found, the terminal connects to it and
receives from the relay the address parameters (IP address and port
number) that the relay provides for the terminal. With this
information, the terminal can update its initial registration and
register itself as ready to receive invitations to sessions.
2.4. Step 4: Address Lookup
After registering with the peer-to-peer infrastructure and before
intiating a call, the terminal needs to lookup addresses of concrete
and potential callees. There are two common ways to do so: per call
look-up of the callee's address or call-independent lookup of the
addresses for a predefined "buddy list".
In both cases, the peer-to-peer infrastructure needs to be contacted
and a lookup of a single address or a list of addresses needs to be
initialized. Because of the client-server nature of this lookup
procedure, it should be permitted by most NAT and firewall
configurations. However, in case it is not, relaying is required
also for this step.
2.5. Step 5: Connection Establishment and termination
After step 1-4 have been performed (as far as necessary), the
terminal should be prepared to establish connections across the
detected middleboxes either by using direct peer-to-peer
communication or via a relay server.
When exchanging addresses for data streaming with another peer,
addresses and port numbers provided by a NAT or relay need to be
considered.
In some cases direct communication with middleboxes is required for
this step. For example, if the terminal assumes that affected
middleboxes support the NSIS NATFW NSLP [I-D.ietf-nsis-nslp-natfw],
then signaling between terminal and firewall would be required at
call establishment and at termination.
3. Middlebox Traversal Methods
This section discusses standardized and/or well known existing
Quittek, et al. Expires August 31, 2006 [Page 7]
Internet-Draft SIP P2P Middlebox Problem February 2006
middlebox traversal methods. They are grouped into tunneling
methods, network-initiated methods and terminal-initiated methods.
Tunneling methods work around existing firewall and NAT
configurations that intend to block certain kinds of traffic.
Therefore, they should be used only, if there is no doubt that their
use is appropriate and does not violate any service agreement.
Network-initiated methods use explicit signaling between a
controlling entity in the network, such as a network or service
management system or a "call agent", and one or more middleboxes.
Terminal-initiated methods use explicit or implicit signaling between
the terminal and one or more middleboxes.
3.1. Tunneling
Tunneling is a highly controversial means for traversing firewalls
and NATs. It is discussed, because it exists, is well known and -
unfortunately - used by common applications for Internet telephony.
Most problematic is tunneling using well known port numbers used for
other services, such as DNS and HTTP. Most commonly, these port
numbers are open to be used for DNS and HTTP services. Using them
for other purposes might be considered as illegal use of the network.
But for obvious reasons, many tunneling tools concentrate on port
numbers that are most commonly open.
A more legitimate tunneling technology is Traversal Using Relay NAT
(TURN) [I-D.rosenberg-midcom-turn]. TURN does not mis-use fixed port
numbers, but provide an network address translation for terminals
behind a NAT that is not peer-to-peer-friendly. TURN is particularly
helpful in the presence of symmetric NATs. But also if more than one
terminals of a session are located behind a NAT, TURN can be very
helpful. This case is described in more detail in [I-D.srisuresh-
behave-p2p-state].
3.2. Network-initiated Middlebox Signaling
Network-initiated middlebox signaling is based on the assumption that
there is an entity in the network that manages sessions. Such a
system could be a service management system or a special call agent.
This system directly controls middleboxes in order to enable sessions
by using a control protocol, such as SNMP [RFC3410] and the MIDCOM
MIB [I-D.ietf-midcom-mib] or the SIMCO protocol [I-D.stiemerling-
midcom-simco]. Both provide sufficient means to an authenticated
entity to configure the middlebox such that sessions can be
established across them.
Quittek, et al. Expires August 31, 2006 [Page 8]
Internet-Draft SIP P2P Middlebox Problem February 2006
3.3. Terminal-initiated Middlebox Signaling
Terminal-initiated signaling is performed between the terminal and
one or more middleboxes. Terminal-initiated signaling is suggested
to be used for SIP-based Internet telephony by [I-D.baset-sipping-
p2preq].
Signaling may be performed explicitly or implicitly. Explicit
signaling requires specific support at the middleboxes for the used
signaling protocol and method, for example, the NSIS NATFW NSLP
[I-D.ietf-nsis-nslp-natfw], while implicit signaling configures the
firewall rather by a side-effect as, for example, the STUN protocol
[RFC3489] does it.
Network-initiated signaling methods exist for middlebox detection
purposes as well as for middlebox configuration.
The following methods are discussed commonly used or currently under
standardization:
* STUN
* UPnP
* SOCKS and RSIP
* NSIS
3.3.1. STUN
The Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs) [RFC3489], also referred to as STUN, gives
the terminal the ability to test NATs on the path for their UDP
properties and to determine the terminal's publicly reachable IP
address and port number. It is limited to UDP flows only. This
technique is widely used by deployed SIP user agents to determine
their reachability.
3.3.2. UPnP
UPnP [UPNP] is a link broadcast technique used to locate services in
a small office/home office network. One of the services is home
gateway detection, i.e., locating your home gateway/NAT. UPnP is
well integrated into the Windows operating system and may home
gateways. It is not well supported on other operating system
platforms.
3.3.3. SOCKS and RSIP
SOCKS [RFC1928] enables authenticated NAT traversal for terminals.
The protocol enables terminals located behind a single NAT to
Quittek, et al. Expires August 31, 2006 [Page 9]
Internet-Draft SIP P2P Middlebox Problem February 2006
authenticate itself and to request NAT traversal service. SOCKS has
been partially deployed in the past, especially in enterprise
networks, but is not so much used by today anymore. UDP support is
very rudimentary at best.
RSIP [RFC3103] is a tunnel mechanism, where a RSIP-aware terminal can
request allocation of a publicly reachable IP address and other
parameters at RSIP-aware firewalls and NATs. The other parameters
are UDP/TCP ports, IPsec SPIs, etc. A tunnel for the requested flow
is created between the terminal and the NAT. As for SOCKS, RSIP
supports only a single NAT on one side of the network.
3.3.4. NSIS NATFW NSLP
A recent protocol proposal for locating and configuring NATs and
firewalls is the NAT and firewall NSIS Signaling Layer Protocol
(NATFW NSLP) [I-D.ietf-nsis-nslp-natfw] defined by the IETF NSIS
working group. NAT/firewall signaling shares a property known from
Quality of Service (QoS) signaling. The signaling of both must reach
any device on the data path that is involved in QoS or NATFW
treatment of data packets. Therefore, the NATFW NSLP signaling
follows the data path and configures any NATFW NSLP-enabled firewall.
This protocol requires at least one side of the network to support
NSLP signaling, but works end-to-end if supported by both ends.
4. Open Issues for SIP-based Peer-to-Peer Communication
This section lists open issues of middlebox traversal for SIP-based
peer-to-peer communication. The issues are grouped into issues that
concern SIP signaling and issues that concern middlebox traversal
methods outside of SIP.
4.1. SIP-related Issues
This section describes three SIP-related issues of middlebox
traversal. They concern missing capabilities of SIP for signaling
* terminal reachability,
* communication service requirements,
* communication service offers.
4.1.1. Terminal Reachability
The relevance of this open issue depends on design decisions
concerning the registration and relay selection process. If a
terminal in an restricted environment needs to register before it can
select a relay, then it needs to express within its registration that
Quittek, et al. Expires August 31, 2006 [Page 10]
Internet-Draft SIP P2P Middlebox Problem February 2006
it is currently unreachable. Currently, the SIP protocol does not
provide explicit means for signaling such a state.
4.1.2. Communication Service Requirement
A terminal in a restricted environment needs to be able to express
its needs for communication services provided by other peers, such as
relaying signaling messages, lookup requests, and/or data streams.
Currently, the SIP protocol does not provide explicit means for
signaling such requirements.
4.1.3. Communication Service Offering
A terminal in an unrestricted environment (or just slightly
restricted) environment might be able (and the user willing) to offer
services to other peers, such as relay services and lookup services.
Currently, the SIP protocol does not provide explicit means for
signaling such offers.
4.2. SIP-unrelated Issues
There is only one SIP-unrelated issue identified by this document.
It concerns middlebox detection for protocols other than UDP.
4.2.1. Middleobox Detection Beyond UDP
As stated in section Section 2.1, it will probably not be sufficient
for secure SIP-based peer-to-peer communication to just detect NAT
properties for the UDP protocol, but TCP checks or further checks for
IPsec will be necessary. Currently, there are no commonly known
tools available for performing these checks.
5. Security considerations
Obviously, securing access to firewall and NAT configuration is
extremely important for maintaining network security. Whatever means
are applied for enabling SIP-based peer-to-peer communication across
firewalls and NATs, it should be ensured that the security policy
that was used for configuring the firewall and/or NAT is not violated
by this action.
Particularly tunneling over port numbers that are assigned to other
services, such as the HTTP or DNS port numbers can often be
considered a violation of the policy that was set up by the access
network operator. Furthermore, such tunnels may be mis-used by
attackers as entry points into otherwise well protected network.
Quittek, et al. Expires August 31, 2006 [Page 11]
Internet-Draft SIP P2P Middlebox Problem February 2006
If explicit methods for firewall and NAT configuration are used, the
security considerations section of the respective standards document
should be considered.
6. Acknowledgements
Martin Stiemerling is partly funded by Ambient Networks, a research
project supported by the European Commission under its Sixth
Framework Program. The views and conclusions contained herein are
those of the authors and should not be interpreted as necessarily
representing the official policies or endorsements, either expressed
or implied, of the Ambient Networks project or the European
Commission.
7. Informative References
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928,
March 1996.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi,
"Realm Specific IP: Protocol Specification", RFC 3103,
October 2001.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Quittek, et al. Expires August 31, 2006 [Page 12]
Internet-Draft SIP P2P Middlebox Problem February 2006
[I-D.rosenberg-midcom-turn]
Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-08 (work in progress),
September 2005.
[I-D.srisuresh-behave-p2p-state]
Srisuresh, P., "State of Peer-to-Peer(P2P) communication
across Network Address Translators(NATs)",
draft-srisuresh-behave-p2p-state-01 (work in progress),
October 2005.
[I-D.baset-sipping-p2preq]
Baset, S., "Requirements for SIP-based Peer-to-Peer
Internet Telephony", draft-baset-sipping-p2preq-00 (work
in progress), November 2005.
[I-D.stiemerling-midcom-simco]
Stiemerling, M., "Simple Middlebox Configuration (SIMCO)
Protocol Version 3.0", draft-stiemerling-midcom-simco-08
(work in progress), December 2005.
[I-D.ietf-midcom-mib]
Quittek, J., "Definitions of Managed Objects for Middlebox
Communication", draft-ietf-midcom-mib-06 (work in
progress), January 2006.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in
progress), February 2006.
[UPNP] UPNP Web Site, "Universal Plug and Play Web Site", Web
Site http://www.upnp.org/, February 2006.
Quittek, et al. Expires August 31, 2006 [Page 13]
Internet-Draft SIP P2P Middlebox Problem February 2006
Authors' Addresses
Juergen Quittek
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 15
Email: quittek@netlab.nec.de
URI: http://www.netlab.nec.de
Martin Stiemerling
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 13
Email: stiemerling@netlab.nec.de
URI: http://www.netlab.nec.de
Thomas Dietz
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 28
Email: dietz@netlab.nec.de
URI: http://www.netlab.nec.de
Saverio Niccolini
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 18
Email: saverio.niccolini@netlab.nec.de
URI: http://www.netlab.nec.de
Quittek, et al. Expires August 31, 2006 [Page 14]
Internet-Draft SIP P2P Middlebox Problem February 2006
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Quittek, et al. Expires August 31, 2006 [Page 15]