Network Working Group S. Kiesel Internet-Draft NEC Intended status: Informational July 6, 2009 Expires: January 7, 2010 Interaction of dynamic firewall control protocols and SIP draft-kiesel-mmusic-firewall-sip-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 7, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Kiesel Expires January 7, 2010 [Page 1] Internet-Draft Firewalls and SIP interaction July 2009 Abstract SIP-based multimedia applications dynamically negotiate parameters for the related media streams, such as UDP port numbers. Therefore, firewalls that want to inspect these streams have to interact with the session signaling. Several architectures and protocols have been developed for the dynamic control of firewalls on the media path, e. g., MIDCOM, SIMCO, and the NSIS NAT/FW NSLP. This document investigates problems with the interaction of standard SIP (as of RFC 3261) and these firewall control protocols, especially with respect to error handling. It will be pointed out how existing SIP extensions can be used for improving the interaction, and which additional mechanisms need to be specified. While the actual specification of such additional mechanisms is out of the scope of this document, it solicits feedback and discussion. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Scope of this document . . . . . . . . . . . . . . . . . . 4 2.2. Firewall control protocol terminology . . . . . . . . . . 5 3. Behaviour under normal conditions . . . . . . . . . . . . . . 7 4. Analysis of possible error conditions . . . . . . . . . . . . 9 4.1. Impact of firewall errors on SIP . . . . . . . . . . . . . 9 4.1.1. Firewall errors at SIP session establishment . . . . . 9 4.1.2. Firewall errors during existing SIP session . . . . . 13 4.2. Impact of SIP errors on firewall control . . . . . . . . . 14 5. Specification of mechanisms for proposed solution . . . . . . 15 5.1. SIP response code firewall failure . . . . . . . . . . . . 15 5.2. Firewall Precondition for SDP Media Streams . . . . . . . 15 5.3. Summary of required SIP extensions . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Kiesel Expires January 7, 2010 [Page 2] Internet-Draft Firewalls and SIP interaction July 2009 1. Requirements notation 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]. Kiesel Expires January 7, 2010 [Page 3] Internet-Draft Firewalls and SIP interaction July 2009 2. Introduction Multimedia communication requires the exchange of signaling information for call/session control, as well as the transport of the actual user data (e. g., speech). Often, different protocols are used for these two tasks. In the following, we assume that SIP/SDP [RFC3261] is used for the signaling and RTP/RTCP [RFC3550][RFC3551] is used for the media transport. Separate UDP or TCP flows are used for conveying the messages of these protocols. Parameters for the RTP streams, including end point IP addresses and port numbers are negotiated dynamically using SDP messages embedded in the SIP signaling. In many scenarios the SIP signaling messages travel along a different path through the network (e. g., via proxies) than the RTP media streams do (e. g., directly between the terminals). A firewall is one or a group of network elements that enforce an access control policy on the traffic at the border between network domains with different security levels and requirements. Specifically, both signaling traffic and media streams have to be checked. The corresponding logical functions of the firewall will be referred to as signaling component and media component, respectively. How the signaling component decides whether to accept a SIP INVITE message that tries to establish a new session is out of the scope of this document. Once the signaling component has accepted a new call the media component must be informed that the corresponding media streams are allowed to pass the firewall. Several architectures and protocols have been specified to control the media compontent of a firewall, e. g., MIDCOM [RFC3303] [RFC5189] [RFC5190] and SIMCO [RFC4540], the NSIS NAT/FW NSLP [RFC4080] [I-D.ietf-nsis-nslp-natfw], etc. However, although support for SIP based multimedia communications is one of the key motivations for these protocols, the interaction between SIP an these firewall control protocols has not been described in detail by an IETF document so far. 2.1. Scope of this document This document considers scenarios where the media component of the firewall (i. e., the logical entity that inspects RTP media streams) is controlled by a SIP entity, which is not the SIP endpoint, e.g., a B2BUA. This is a typical usage scenario for MIDCOM (see Fig. 3 of [RFC3303]) and similar path-decoupled firewall signaling architectures. The same problems arise if path-coupled firewall signaling is used only on parts of the end-to-end RTP path (e. g., using NSIS NAT/FW NSLP, see Fig. 2 of [RFC4080]). Kiesel Expires January 7, 2010 [Page 4] Internet-Draft Firewalls and SIP interaction July 2009 _________ --->| SIP |<-----\ / | B2BUA | \ | |_________| | 1| |^ ^| 4| | || || | |8 2||3 7||6 |5 ______________ | || || | _____________ | |<-/ _v|____|v___ \->| | | External | Na | | Nc | SIP Phone | | SIP phone |>------->| Middlebox |>------>| within | | |<-------<|___________|<------<| Pvt. domain| |____________| Nb Nd |____________| Figure 1: MIDCOM framework with SIP (Fig. 3 of RFC 3303, corrected: SIP proxy replaced with B2BUA) Proxy1 Proxy2 +------+ +----+ +----+ +----+ +----+ +--------+ |Sender|-...->|Appl|--->| R |--->| R |--->|Appl|-...->|Receiver| | | |+--+| |+--+| |+--+| |+--+| | | +------+ ||NE||====||NE||====||NE||====||NE|| +--------+ |+--+| |+--+| |+--+| |+--+| +----+ +----+ +----+ +----+ +--+ |NE| = NSIS ==== = Signaling ---> = Data flow messages +--+ Entity Messages (unidirectional) Appl = signaling application Figure 2: On path NSIS proxy (Fig. 2 of RFC 4080) 2.2. Firewall control protocol terminology In the following sections, the terminology and message names of the MIDCOM architecture [RFC3303] and protocol [RFC5189] will be used. However, the identified problems and proposed solutions apply to other firewall control architectures and protocols as well. Specifically, the MIDCOM "PER" (Policy Enable Rule) message is used for requesting the firewall to open a "pinhole", which allows traffic to flow through the firewall if it matches the filter criteria given as parameters of the PER message. The firewall answers with a "PER PR" (PER Positive Reply) message if it was able to open the requested Kiesel Expires January 7, 2010 [Page 5] Internet-Draft Firewalls and SIP interaction July 2009 pinhole, otherwise with a "PER NR" (PER Negative Reply) message. If an existing pinhole is removed from the firewall at the request of an authorized third party, the original creator is informed by means of an "ARE" (Asynchronous Rule Event) message. Kiesel Expires January 7, 2010 [Page 6] Internet-Draft Firewalls and SIP interaction July 2009 3. Behaviour under normal conditions Figure 3 shows a message sequence chart of the interaction between SIP session signaling and firewall control in the error free case, assuming the scenario as depicted in Figure 1. This message sequence chart has also been depicted in Section 7.1 of [RFC3303] (with slightly different notation). However, it will be shown later that this straightforward way of interaction will cause problems under error conditions. Two pinholes are required to admit the media streams related to a session, one per direction. The INVITE message contains information (SDP_A) about the address at which the calling party is waiting for incoming media streams. As soon as the INVITE message reaches the B2BUA, the first PER transaction is issued to open a pinhole that allows media to the calling party. The second PER request is sent by the B2BUA upon reception of the 200 OK message, when the called party has already picked up the receiver and the conversation is about to start. When either party indicates the session end by sending a SIP BYE message, the pinholes are removed from the firewall by means of PLC (Policy Lifetime Change) transactions, which set the remaining lifetime of the pinholes to zero. Kiesel Expires January 7, 2010 [Page 7] Internet-Draft Firewalls and SIP interaction July 2009 Calling SIP B2BUA Middlebox Called SIP Phone (MIDCOM agent) (Firewall) SIP Phone | | | | |--INVITE+SDP_A-->| | | |<-100 Trying-----| | | | | | | | |+++++PER(SDP_A)++++++>| | | |<++++PER PR(PID_A)++++| | | | | | |<=-=-=-=-=-=-=-=-=-=RTP/RTCP=-=-=-=-=-=-=-=-=... | | | | | | |-----INVITE+SDP_A------------------->| phone | |<----180 Ringing---------------------| rings |<--180 Ringing---| | | | | | | | | | | B goes | |<----200 OK+SDP_B--------------------| off-hook | | | | | |+++++PER(SDP_B)++++++>| | | |<++++PER PR(PID_B)++++| | |<--200 OK+SDP_B--| | | |-------ACK------>| | | | |-----------ACK---------------------->| | | | | |<===================RTP/RTCP==========================>| | | | | |------BYE------->| | | | |-----BYE---------------------------->| | |<----200 OK -------------------------| | | | | | |+++++PLC(PID_A,LT=0)+>| | | |<++++PLC PR(PID_A)++++| | | | | | | |+++++PLC(PID_B,LT=0)+>| | | |<++++PLC PR(PID_B)++++| | |<--200 OK--------| | | | | | | Legend: ++++ MIDCOM control traffic ---- SIP control traffic <=-= RTP/RTCP media traffic (early media) <==> RTP/RTCP media traffic (two-way) Figure 3: MIDCOM / SIP interaction: error free session setup and teardown Kiesel Expires January 7, 2010 [Page 8] Internet-Draft Firewalls and SIP interaction July 2009 4. Analysis of possible error conditions This section investigates possible error conditions in the same scenario as shown in the previous section. For now, it is assumed that session signaling uses SIP as of [RFC3261], with no additional protocol mechanisms. Later, such SIP extensions will be proposed to mitigate the problems. 4.1. Impact of firewall errors on SIP The basic problem in this error category is that the required pinholes in the firewall cannot be opened, or that they will be closed prematurely, before the normal session end. In these cases, the session should not be established or it should be terminated gracefully, and the users should be informed about the problem with a reasonable error message. 4.1.1. Firewall errors at SIP session establishment A PER request to open a new pinhole may fail for various reasons, which fall into two classes: o Technical errors, e. g., resource shortage at the firewall or problems with the signaling association to it. These problems are usually temporary effects, i. e., it may be worthwhile to retry the call later. o Violation of other policies that have higher precedence. See, for example, the "Policy Interface" of [RFC3303] or the "PDR" transaction in SIMCO [RFC4540]. This situation may be permanent, e. g., due to static policies, or temporary, e. g., if a network intrusion detection system believes that the network is already under attack and no additional pinholes should be opened. In some cases the middlebox may indicate why the request failed, e. g., in the PER NR message. In the following, the same basic scenario as in the previous good- case (see Figure 3) will be assumed. If the transsaction for opening the first pinhole fails, the call flow is straightforward (see Figure 4). An error message indicating that firewall configuration failed is returned to the calling user agent in response to the INVITE message. For a discussion which SIP response code to use, see Section 5.1. Kiesel Expires January 7, 2010 [Page 9] Internet-Draft Firewalls and SIP interaction July 2009 Calling SIP B2BUA Middlebox Called SIP Phone (MIDCOM agent) (Firewall) SIP Phone | | | | |--INVITE+SDP_A-->| | | |<-100 Trying-----| | | | | | | | |+++++PER(SDP_A)++++++>| | Firewall | |<++++PER NR+++++++++++| | config |<--5xx FW Error--| | | FAILED! | | | | Legend: ++++ MIDCOM control traffic ---- SIP control traffic <=-= RTP/RTCP media traffic (early media) <==> RTP/RTCP media traffic (two-way) Figure 4: MIDCOM / SIP interaction: failure opening the first pinhole The situation becomes more difficult if the second PER transaction fails. From a SIP perspective, the calling party will be sent a negative response to their INVITE, as above. Regarding the called party, it is no longer possible for the B2BUA to abort the session setup (e. g., by sending a CANCEL message), as the calling party has already sent a final response (200) to the INVITE and assumes the session to be established. In order to remove this session state gracefully the B2BUA can send an ACK message immediately followed by a BYE message. However, the error occurs only after the called SIP phone has already alerted its user and the session has been accepted. Therefore, from the called user's perspective it looks like the calling party has terminated the session immediately after it had been accepted. The B2BUA should include a reason header [RFC3326] with the same error code as above in the BYE message, in order to inform the called user that this disturbing "ghost ring" was due to technical problems and not caused intentionally by the calling party. Finally, the already configured other pinhole has to be removed by means of a PLC transaction (see Figure 5). Even with the reason header, disturbing the called party with "ghost rings" is unsatisfactory. One possible solution is the use of preconditions, as outlined in [RFC3312] and [RFC4032], which specify the integration of resource management and SIP. Indeed, from a syntactical perspective, firewall control has similar issues as resource control. However, the conditions whether a session is admitted may be very different. Kiesel Expires January 7, 2010 [Page 10] Internet-Draft Firewalls and SIP interaction July 2009 Figure 6 and Figure 7 show call flows when using this mechanisms for the successful case and when the second PER transaction fails, respectively. The differences between the SDP messages SDP_A and SDP_A1, or SDP_B and SDP_B1, respectively, will be explained in Section 5.2. Calling SIP B2BUA Middlebox Called SIP Phone (MIDCOM agent) (Firewall) SIP Phone | | | | |--INVITE+SDP_A-->| | | |<-100 Trying-----| | | | | | | | |+++++PER(SDP_A)++++++>| | | |<++++PER PR(PID_A)++++| | | | | | |<=-=-=-=-=-=-=-=-=-=RTP/RTCP=-=-=-=-=-=-=-=-=... | | | | | | |-----INVITE+SDP_A------------------->| phone | |<----180 Ringing---------------------| rings |<--180 Ringing---| | | | | | | | | | | B goes | |<----200 OK+SDP_B--------------------| off-hook | | | | | |+++++PER(SDP_B)++++++>| | Firewall | |<++++PER NR+++++++++++| | config |<--5xx FW Error--| | | FAILED! | | | | | |-----ACK---------------------------->| line | |-----BYE (Reason: 5xx FW Error)----->| is dead | |<----200 OK -------------------------| | | | | | |+++++PLC(PID_A,LT=0)+>| | | |<++++PLC PR(PID_A)++++| | | | | | Legend: ++++ MIDCOM control traffic ---- SIP control traffic <=-= RTP/RTCP media traffic (early media) <==> RTP/RTCP media traffic (two-way) Figure 5: MIDCOM / SIP interaction: ghost ring Kiesel Expires January 7, 2010 [Page 11] Internet-Draft Firewalls and SIP interaction July 2009 Calling SIP B2BUA Middlebox Called SIP Phone (MIDCOM agent) (Firewall) SIP Phone | | | | |--INVITE+SDP_A-->| | | | |+++++PER(SDP_A)++++++>| | | |<++++PER PR(PID_A)++++| | | | | | |<=-=-=-=-=-=-=-=-=-=RTP/RTCP=-=-=-=-=-=-=-=-=... | | | | | | |-----INVITE+SDP_A------------------->| not yet | |<----183 Session Progress+SDP_B------| ringing! | | | | | |+++++PER(SDP_B)++++++>| | | |<++++PER PR(PID_B)++++| | |<-183 SPro+SDP_B-| | | |--PRACK--------->| | | | |-----PRACK-------------------------->| | |<----200 OK (PRACK)------------------| |<-200 OK (PRACK)-| | | |--UPDATE+SDP_A1->| | | | |-----UPDATE+SDP_A1------------------>| | |<----200 OK (UPDATE)+SDP_B1----------| |<-200 OK (UPD.)--| | | phone | |<----180 Ringing---------------------| rings |<--180 Ringing---| | | |--PRACK--------->| | | | |-----PRACK-------------------------->| | |<----200 OK (PRACK)------------------| |<-200 OK (PRACK)-| | | | | | | | | | | B goes | |<----200 OK (INVITE)-----------------| off-hook |<-200 OK(INVITE)-| | | |-------ACK------>| | | | |-----------ACK---------------------->| | | | | |<===================RTP/RTCP==========================>| | | | | Legend: ++++ MIDCOM control traffic ---- SIP control traffic <=-= RTP/RTCP media traffic (early media) <==> RTP/RTCP media traffic (two-way) Figure 6: MIDCOM / SIP interaction: successful session setup with preconditions Kiesel Expires January 7, 2010 [Page 12] Internet-Draft Firewalls and SIP interaction July 2009 Calling SIP B2BUA Middlebox Called SIP Phone (MIDCOM agent) (Firewall) SIP Phone | | | | |--INVITE+SDP_A-->| | | | |+++++PER(SDP_A)++++++>| | | |<++++PER PR(PID_A)++++| | | | | | |<=-=-=-=-=-=-=-=-=-=RTP/RTCP=-=-=-=-=-=-=-=-=... | | | | | | |-----INVITE+SDP_A------------------->| not yet | |<----183 Session Progress+SDP_B------| ringing! | | | | | |+++++PER(SDP_B)++++++>| | Firewall | |<++++PER NR+++++++++++| | config |<--5xx FW Error--| | | FAILED! | |-----CANCEL (Reason: 5xx FW Error)-->| | |<----487 Request Terminated----------| | | | | | |+++++PLC(PID_A,LT=0)+>| | | |<++++PLC PR(PID_A)++++| | | | | | Legend: ++++ MIDCOM control traffic ---- SIP control traffic <=-= RTP/RTCP media traffic (early media) <==> RTP/RTCP media traffic (two-way) Figure 7: MIDCOM / SIP interaction: unsuccessful session setup with preconditions 4.1.2. Firewall errors during existing SIP session An existing pinhole may be closed at the discretion of the firewall at any time, e. g., because a network intrusion detection system considers the corresponding flows harmful. The "owner" that requested the pinhole is informed by means of an ARE (Asynchronous Rule Event) message. A similar situation occurs if pinholes are softstate and a transaction for extending their lifetime fails. If the media stream, which can no longer flow through the now closed pinhole, is crucial to the session the B2BUA may terminate the session by sending BYE messages to both parties. Again, it should include a reason header, to inform that the session was terminated due to technical problems and not at the request of the other party. Any other pinhole belonging to that session should be closed by the B2BUA (see Figure 8). Kiesel Expires January 7, 2010 [Page 13] Internet-Draft Firewalls and SIP interaction July 2009 Calling SIP B2BUA Middlebox Called SIP Phone (MIDCOM agent) (Firewall) SIP Phone | | | | |<===================RTP/RTCP==========================>| | | | | | |<+++ARE(PID_B,LT=0)+++| | | | | | | |-----BYE (Reason: 5xx FW Error)----->| | |<----200 OK -------------------------| |<-BYE (Rsn:5xx)--| | | |--200 OK-------->| | | | | | | | |+++++PLC(PID_A,LT=0)+>| | | |<++++PLC PR(PID_A)++++| | | | | | Legend: ++++ MIDCOM control traffic ---- SIP control traffic <=-= RTP/RTCP media traffic (early media) <==> RTP/RTCP media traffic (two-way) Figure 8: MIDCOM / SIP interaction: early closing of a pinhole 4.2. Impact of SIP errors on firewall control The signaling component in the considered scenario needs to be session stateful, e. g., a session stateful SIP B2BUA. Usually, SIP creates a hard state in the B2BUA, i. e., the B2BUA assumes the session to be active until a BYE or similar message is received. However, due to network connectivity problems or software failures at another SIP entity, this graceful session termination may never occur, leaving stale state information at the B2BUA and open pinholes in the media component. Eventually, it may happen that new sessions cannot be established because resources in the B2BUA or in the media component are exhausted due to these stale sessions. The signaling component must consider SIP sessions as soft state, i. e., it must use additional SIP mechanisms such as the keepalive mechanism described in [RFC4028] to detect whether a SIP session is still intended to be active. If the signaling component detects that a session has terminated abnormally it must remove all corresponding pinholes from the media component and delete state information. Kiesel Expires January 7, 2010 [Page 14] Internet-Draft Firewalls and SIP interaction July 2009 5. Specification of mechanisms for proposed solution 5.1. SIP response code firewall failure The configuration of pinholes in the media component may fail for various reasons: o Temporary technical problems, e. g., resource shortage at the media component or connectivity problems with the signaling association o Requested pinholes conflict with static policy o Requested pinholes conflict with temporary policy, e. g., issued by network intrusion detection system These error conditions have to be indicated to the SIP user agents by means of SIP Response Codes, which are registered with IANA [iana.sip-response-codes]. TBD: Whether the different firewall error conditions should be mapped to existing error codes, or whether one or several new, firewall-specific SIP response codes should be registered with IANA is subject to further discussion. 5.2. Firewall Precondition for SDP Media Streams The Session Description Protocol Preconditions mechanism, defined in [RFC3312] as updated by [RFC4032], allows to specify conditions, which have to be satisfied for a given media stream in order for session establishment or modification to proceed. That way, annoying "ghost rings" can be avoided, i. e., situations in which it turns out that a new multimedia session cannot be established only after the called party has already been alerted (e.g., by a ringing phone). In addition to the generic framework, [RFC3312] also defines the Quality-of-Service (QoS) precondition, which can be used to ensure availability of network resources prior to alerting the called party. Further preconditions can be registered with IANA [iana.sip-precond-types], e.g., the Security Precondition [RFC5027], which can be used to ensure the availability of kryptrographic keys at the endpoints, which are required for the desired encryption of a media stream. Similar to this, a new Firewall Precondition (proposed string: "fw"), should be specified and registered with IANA. Note that a normative specification of the firewall precondition is out of the scope of this document and will be done in a separate document, as IANA registration requires a standards-track RFC while most of the content in this document is of informational nature. Kiesel Expires January 7, 2010 [Page 15] Internet-Draft Firewalls and SIP interaction July 2009 However, some properties of this firewall precondition will be described here until a first version of the normative specification is published: The firewall precondition must always be used in conjunction with the "end-to-end" status defined in the Preconditions framework, indicating that all firewalls on the media path between the endpoints have to be (or have been, respectively) configured to allow the respective media stream. Usage of the firewall precondition in conjunction with the "segmented" status type is unspecified. The firewall precondition can be used with the strength-tag "mandatory" (i.e., all firewalls have to be configured successfully before the session establishment can proceed) or "none" (used by a user agent to indicate that the precondition is supported in principle, but not requested for this specific media stream). 5.3. Summary of required SIP extensions The following list summarizes SIP mechanisms which go beyond the scope of [RFC3261] and may help to avoid the problems analyzed in the previous section: o SIP Reason header field [RFC3326] o One or several SIP response codes for indicating firewall configuration problems (see Section 5.1) o SIP Preconditions Framework [RFC3312][RFC4032] o Firewall Preconditions for Session Description Protocol (SDP) Media Streams (see Section 5.2) o SIP Session Timers [RFC4028] Kiesel Expires January 7, 2010 [Page 16] Internet-Draft Firewalls and SIP interaction July 2009 6. Security Considerations Firewalls are a widely deployed means for securing network interconnections. The usage of SIP for establishing multimedia sessions often requires a more dynamic control of these firewalls. This document analyzes possible error conditions and proposes additional mechanisms for handling them reasonably. It is assumed that these additional mechanisms (e. g., error codes) as such do not introduce new security issues. However, the overall solution has to be thoroughly analyzed for possible security vulnerabilites, taking into account the specific protocol that has been chosen for firewall control. Kiesel Expires January 7, 2010 [Page 17] Internet-Draft Firewalls and SIP interaction July 2009 7. IANA Considerations This document describes several error conditions that may occur when firewalls are present on the RTP media path. These errors have to be indicated to the SIP user agents by means of appropriate SIP Response Codes (see Section 5.1). Whether existing response codes should be re-used, or whether one or several new, firewall-specific SIP Response Codes should be registered with IANA in the SIP Response Code Registry [iana.sip-response-codes] is subject to further discussion. This document proposes the specification of a new "Firewall Precondition" type for SIP and its registration with IANA in the SIP precondition types registry [iana.sip-precond-types]. However, the actual specification of this precondition is out of the scope of this document and should be done in a separate document. Kiesel Expires January 7, 2010 [Page 18] Internet-Draft Firewalls and SIP interaction July 2009 8. References 8.1. 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. [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005. [iana.sip-precond-types] Internet Assigned Numbers Authority (IANA), "Precondition Types used with Session Initiation Protocol (SIP)", Web Site http://www.iana.org/assignments/sip-precond-types, August 2002. [iana.sip-response-codes] Internet Assigned Numbers Authority (IANA), "SIP Response Codes Registry", Web Site http://www.iana.org/assignments/sip-parameters, June 2002. 8.2. Informative References [I-D.ietf-nsis-nslp-natfw] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-18 (work in progress), February 2008. [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and Kiesel Expires January 7, 2010 [Page 19] Internet-Draft Firewalls and SIP interaction July 2009 A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0", RFC 4540, May 2006. [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5027, October 2007. [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communication (MIDCOM) Protocol Semantics", RFC 5189, March 2008. [RFC5190] Quittek, J., Stiemerling, M., and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", RFC 5190, March 2008. Kiesel Expires January 7, 2010 [Page 20] Internet-Draft Firewalls and SIP interaction July 2009 Author's Address Sebastian Kiesel NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 232 Email: sebastian.kiesel@nw.neclab.eu Kiesel Expires January 7, 2010 [Page 21]