idnits 2.17.1 draft-jfp-sipfw-policy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2000) is 8687 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 377 looks like a reference -- Missing reference section? '2' on line 380 looks like a reference -- Missing reference section? '3' on line 383 looks like a reference -- Missing reference section? '4' on line 386 looks like a reference -- Missing reference section? '5' on line 389 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft J. Peterson 4 draft-jfp-sipfw-policy-00.txt Level(3) Communications 5 July 14, 2000 6 Expires: January, 2001 8 Application-layer Policy Enforcement at SIP Firewalls 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 At the boundaries of some networks, administrators may want to 34 implement policies that govern the application-layer traversal of SIP 35 signaling. This document serves as an introduction to application- 36 layer policies for SIP, discusses the architectures of network 37 boundaries at which policies might be deployed, and provides examples 38 of policies tailored to particular network services. 40 Introduction 42 As the use of the Session Initiation Protocol (SIP, [1]) in the 43 Internet at large becomes more common, network service providers have 44 begun to confront the security implications of the protocol. 45 Enterprise network administrators whose domains are currently 46 protected by off-the-shelf firewalls are discovering that they must 47 make special allowances for the ingress and egress of SIP traffic. 49 Meanwhile, emerging SIP-centric carriers seek to deploy peering 50 firewalls whose vocation is to ensure that no traffic other than SIP 51 (and the media characterized within it) can pass. 53 Fortunately, both of these roles can be performed by the same system; 54 the technology that permits SIP to traverse firewalls (addressed, for 55 example, in [2] and [3]) manages the disparate signaling and media 56 streams, dynamically allocates media ports as required for sessions, 57 and resolves network-edge complications such as Network Address 58 Translators (NAT, [4]). This document assumes the enforcement of IP- 59 layer policies at the edges of the network to be a solved problem, 60 and focuses on the cases in which the administrators of a network 61 have application-layer policies above and beyond those required for 62 basic SIP traversal that they would like to enforce at network edges. 64 In essence, the policies in question are rules to which passing 65 signaling is subject, ones which may result in the modification, 66 redirection, or rejection of passing signaling. The following 67 sections explore architectures for the implementation of such 68 policies at SIP network edges, and provides a few examples of the 69 sorts of rules that network administrators might wish to use in 70 various situations. 72 I. SIP Network Edges 74 In this document, a network edge refers simply to the border between 75 one IP network and another - whether this designates a peering point 76 between a pair of carriers, or the boundary that separates an 77 enterprise network from the public Internet, or any other sort of 78 divide between administrative domains. In this day and age, firewalls 79 are inevitably deployed at such borders to protect valuable network 80 resources; consequently, this document assumes that anyone interested 81 in applying application-layer policies to SIP traffic will also have 82 enforcers of IP-layer policy in place. 84 The instruments that reside at the edge of a SIP-enabled network are 85 assumed to be of the general form of those described in [2], 86 compromising first a firewall (FW), which handles incoming traffic at 87 the IP (layer 3 to 4) level, and second an application-layer gateway 88 (ALG) which statefully analyzes SIP methods, headers, and so forth in 89 messages which, for inbound calls, it receives from the firewall. A 90 SIP ALG will usually be colocated or associated with a SIP proxy 91 server that assists in routing messages which traverse the network 92 edge. 94 +-------++-------+ 95 | || | 96 -----+ Proxy || ALG | 97 | || | Network 98 +-------++-+---+-+ Boundary 99 | | 100 FCP | | SIP | 101 | | | 102 +-+---+-+ | 103 | | | 104 | FW +--------------| 105 | | | 106 +-------+ | 107 | 108 | 109 | 111 Figure 1: A SIP Firewall 113 On the basis of its analysis of the signaling, an application-layer 114 gateway must instruct the firewall to open ports (for media 115 transmission) at the commencement of a session, and to close these 116 ports once the session has concluded. The mechanism by which an ALG 117 signals to the FW has little direct bearing on this document, but 118 should be some sort of firewall control protocol (FCP) allowing for 119 the dynamic provisioning of IP-layer policies (related to packet 120 filtration, NAT bindings, and so forth) such as the one envisioned in 121 [5]. 123 Note that for reasons of scalability and redundancy, a given firewall 124 implementation may deploy more than one instance of each of the 125 components shown above. 127 Some types of SIP network edges are: 129 o Enterprise network facing the public Internet 130 o SIP-only network facing peer carrier 131 o SIP-only network facing external service 133 The instruments depicted in Figure 1 will perform the roles described 134 above regardless of the type of edge at which the firewall is 135 situated. However, the application-layer policies will almost 136 certainly vary with the sorts of resources that a particular network 137 edge faces. 139 II. Application-layer Policies 141 An application-layer policy is an administrative rule that proscribes 142 a particular behavior if certain characteristics are present in the 143 application-layer component of signaling traversing the policy- 144 enforcing instrument. The term 'application-layer' differentiates 145 these policies from those that apply to lower-layers in signaling 146 (such as the IP headers, where ports and addresses for low-level 147 message routing are designated). 149 Several SIP-speaking elements that might be present in a service 150 provider's network, such as redirect servers or application servers, 151 can enforce administrative rules on signaling. Application-layer 152 policies, as they are considered in this document, are applied to 153 traffic associated with a particular network edge (perhaps one among 154 many in a large service provider's network), thus differentiating 155 these policies from independent applications that might be operating 156 in a given administrative domain. While some networks (enterprise 157 networks, for example, which generally face only the public Internet) 158 have only one logical edge, others, such as those of carriers who 159 exchange sessions with several peer carriers, may wish to enforce 160 different policies at different edges. 162 The rules which application-layer policies enforce are instantiated 163 in logic (most likely software) that analyzes and/or modifies SIP 164 signaling. Generally, this logic will be predicated on the values of 165 particular SIP headers, although it is also possible that some logic 166 might be interested in the body of a SIP message (scanning for 167 supported MIME types, or analyzing bodies like SDP when appropriate). 168 Policies should have access to the complete content of a SIP message. 169 Once this content has been analyzed, policies may: 171 o Allow signaling to pass. Commonly, policies will verify that 172 certain characteristics of the session are in accordance with some 173 pre-provisioned guidelines before proxying signaling on towards its 174 final destination. 175 o Discard signaling. If the sorts of verifications mentioned in the 176 previous case fail, it may be desirable for a policy to discard 177 signaling and take no further action. 178 o Reply to signaling without passing it along. This might, for 179 example, be a more sophisticated form of rejecting signaling in 180 which an appropriate application-layer status code is returned to 181 the originating user agent, possibly soliciting a necessary 182 modification to the session. 183 o Modify signaling and pass it along. New SIP headers might be 184 added, or existing ones modified, in order to bring signaling into 185 conformity with administrative conventions of the network. This is 186 especially useful for amendments to routing. 188 And in many of the above cases, it may be appropriate for policies to 189 also: 191 o Take some other action as a side-effect of receiving the 192 signaling. Logging (for billing, alarming, trending, and so forth) 193 is the most common example of this behavior. Another example is the 194 port-provisioning systems used by an application-layer gateway to 195 instruct a firewall of addresses for media transport (which also 196 serves as an example of the analysis of the SIP body, in this case 197 certain portions of the SDP in some SIP messages). 199 Note that not all policies necessarily target inbound (that is, 200 traversing a network edge from outside to inside) sessions. Some 201 enterprise domains, especially corporate networks, apply restrictions 202 to outbound traffic in order to prevent, for example, abuse of 203 business Internet connectivity. The ALG functionality associated with 204 a conventional SIP firewall targets both inbound and outbound calls 205 (dynamic allocation of media ports is necessary for either). 207 III. Edge Architectures supporting Policy 209 The composition of a network edge will, to some extent, dictate the 210 possibilities for the deployment of instruments of policy. Almost any 211 conceivable SIP edge architecture can support the presence of one or 212 more application-layer policies, although some architectures may be 213 more efficient than others. All of the cases examined in this section 214 assume the existence of a firewall at network edges - in the absence 215 of such a firewall, edge architectures would most likely be 216 considerably simpler. 218 From a strictly logical perspective, policies are positioned between 219 the firewall (packet filterer/NAT) element of a network edge and a 220 proxy server. The proxy server in question may be an ingress element 221 (fronting for a location server, distributing inbound SIP requests to 222 the proper user agents or interior proxies) or a local outbound proxy 223 of some kind through which users inside the edge originate sessions. 224 In turn, the firewall filters inbound and outbound traffic, directing 225 SIP traffic to the ALG, permitting media associated with known 226 sessions to reach the proper endpoints, and blocking all other 227 packets. One or more policy-enforcing instruments will bridge 228 together these elements, allowing (or disallowing) signaling to pass 229 between them. 231 +------+ +------+ +------+ +------+ 232 | | | | | | | | Network 233 ---+Proxy +-+Policy+-+Policy+-+ ALG | Boundary 234 | | |One | |Two | | | | 235 +------+ +------+ +------+ +-+--+-+ | 236 | | | 237 FCP | | SIP | 238 +-+--+-+ | 239 | | | 240 | FW +--------+ 241 | | | 242 +------+ | 243 | 244 | 245 | 247 Figure 2: Chain of Policy 249 It is perhaps simplest to visualize one instrument, a back-to-back 250 UAS/UAC, per such policy. A set of these instruments are then chained 251 together, each receiving a SIP message from the previous instrument 252 in the chain, enforcing its own rule, and then, when appropriate, 253 forwarding the message on to the next instrument in the chain. 254 Inbound calls would originate with the firewall, which would forward 255 signaling to the first instrument in the chain; after traversing each 256 of the instruments in the proper sequence, the final policy 257 instrument would deliver the message to the proxy. Outbound calls 258 would originate with the proxy and traverse the chain to reach the 259 firewall - however, the inbound and outbound chains need not be 260 traversed in the same order, nor indeed constituted of the same 261 instruments. 263 While this architecture is easy to picture, it is however not a 264 terribly efficient way to implement multiple policies. Rather than 265 repeatedly transmitting the SIP message 'over the wire' between 266 distinct elements, it makes far more sense to maintain a single 267 platform that is responsible for managing all of the policies 268 associated with an edge. This platform could serve as both a 269 repository for the service logic associated with each policy, and as 270 a router that ensures the proper traversal of the policy chain. An 271 ALG as described in [2] could be considered such a platform, insofar 272 as it enforces a set of differentiable (albeit tightly coupled) 273 policies. 275 Moreover, a simple chain of instruments neglects opportunities for 276 parallelism and intelligent feature interaction that could be 277 administered by a more versatile platform. Network management tools, 278 even in the form of a service creation environment, could be used by 279 network administrators to provision and sequence such policies. 281 IV. Examples of policies 283 The majority of networks supporting SIP will have one or more edges 284 through which sessions can be exchanged with the public Internet or 285 specific peer networks. The following policies are applicable to 286 these sorts of edges. 288 - Application-layer throttle: This policy prevents an unreasonable 289 volume of inbound call requests from flooding the network behind it. 290 Upon receiving a given rate of calls (perhaps one informed by dynamic 291 conditions in the interior of the network), the policy instrument 292 does not allow signaling to pass, but rather sends a 503 status code 293 in the backwards direction with a Retry-After header specifying a 294 suitable interval. 296 - Enforcing Edge direction: Especially in the case of peering points 297 between SIP carriers, it may be desirable for an edge to be one-way, 298 allowing calls to be originated by only one of the side of the 299 network edge. 301 - Session screening: On a per-edge basis, it may make sense to block 302 sessions originating from either side of the border that are 303 associated with particular users, on account of fraud, abuse, and so 304 forth. The policy logic analyzes the From field in SIP INVITEs, 305 comparing the URI with a list of undesirables, and if it finds a 306 match returning a 403 Forbidden message and refusing to pass the 307 signaling along. 309 - Entrypoint flagging: In some cases, analysis of the From header of 310 a SIP message might not be sufficient to determine the peer network 311 which offered a particular session to an administrative domain. If 312 interior SIP resources need to know the edge at which a particular 313 call entered the network (and possibly the domain which that edge 314 faces) for the purposes of billing, routing, or whatnot, it may be 315 appropriate for a policy to add some signifier of its own identity, 316 and possibly that of the network to which it is adjacent, to SIP 317 signaling before passing it along. Such an identifier might for 318 example be appended to the existing message as a proprietary X- 319 header without any further modification to the signaling. 321 Some SIP networks may have edges that face specialty resources, such 322 as application servers or third-party call control platforms that are 323 hosted by semi-trusted entities. In such cases, network 324 administrators may wish to enforce policies that enforce rules 325 applicable to specific services managed by these external resources, 326 for example: 328 - Transaction tracking for an external routing service: Consider a 329 case in which an administrative domain uses an external service to 330 make some routing decisions. When the network sends a SIP INVITE to 331 the external service, it expects to receive one INVITE back, 332 potentially with a modified Request-URI field, or perhaps a 302 333 redirection or similar routing mechanism. One policy that might be 334 desired at a network edge facing this sort of external service is a 335 transaction tracking policy that verifies that each call sent out to 336 the service results in precisely one returning call. Timers could 337 guarantee that a request (tracked by Call-ID) is answered within a 338 provisioned interval. Only requests bearing the Call-ID of a session 339 known to be offered to the external service should be passed along 340 (and presumably, once the transaction has been completed, no further 341 requests associated with that Call-ID should be permitted to 342 originate from the external service). 344 - Checksum verification for read-only external services: Some sorts 345 of external services do not require the ability to modify SIP 346 signaling; they merely examine the messages and perform some sort of 347 unrelated behavior based on the result. Network edges facing this 348 sort of service might wish to guarantee the integrity of signaling 349 returning to the originating administrative domain by installing a 350 policy that records a simple checksum of signaling as it passes. 351 Returning messages are corollated by Call-ID, CSeq and method, 352 rehashed and compared with the original checksum to ensure that they 353 were not modified. 355 V. To do 357 o Consideration of policies which trigger on media characteristics, 358 i.e. SDP. 360 VI. Security 362 Insofar as policies are frequently instruments of security, this 363 document illustrates the means by which policies can be added to 364 network edges in order to augment the security of a particular 365 network. 367 VII. Authors' Addresses 369 Jon Peterson 370 Level(3) Communications 371 1025 Eldorado Blvd 372 Broomfield, CO 80021 373 jon.peterson@level3.com 375 VIII. References 377 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 378 sesion initiation protocol," Request for Comments (Proposed Standard) 379 2543, Internet Engineering Task Force, Mar. 1999 380 [2] J. Rosenberg, D. Drew, H. Schulzrinne, "Getting SIP through 381 Firewalls and NATs", Internet Draft (work in progress), Internet 382 Engineering Task Force, Feb. 2000 383 [3] B. Biggs, "A SIP Application Level Gateway for Network Address 384 Translation", Internet Draft (work in progress), Internet Engineering 385 Task Force, Mar. 2000 386 [4] P. Srisuresh and M. Holdrege, "IP network address translator (NAT) 387 terminology and considerations", Request for Comments (Informational) 388 2663, Internet Engineering Task Force, Aug. 1999 389 [5] J. Kuthan, J. Rosenberg, "Firewall Control Protocol Framework and 390 Requirements", Internet Draft (work in progress), Internet Engineering 391 Task Force, Jun. 2000 393 Full Copyright Statement 395 Copyright (c) The Internet Society (2000). All Rights Reserved. 397 This document and translations of it may be copied and furnished to 398 others, and derivative works that comment on or otherwise explain it 399 or assist in its implementation may be prepared, copied, published 400 and distributed, in whole or in part, without restriction of any 401 kind, provided that the above copyright notice and this paragraph are 402 included on all such copies and derivative works. However, this 403 document itself may not be modified in any way, such as by removing 404 the copyright notice or references to the Internet Society or other 405 Internet organizations, except as needed for the purpose of 406 developing Internet standards in which case the procedures for 407 copyrights defined in the Internet Standards process must be 408 followed, or as required to translate it into languages other than 409 English. 411 The limited permissions granted above are perpetual and will not be 412 revoked by the Internet Society or its successors or assigns. 414 This document and the information contained herein is provided on an 415 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 416 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 417 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 418 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 419 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.