Internet Engineering Task Force Jiri Kuthan Internet Draft GMD Fokusdraft-kuthan-fcp-01.txtdraft-kuthan-fcp-02.txt Jonathan RosenbergJune,November, 2000 dynamicsoft Expires:December 2000 Firewall Control ProtocolMay 2001 Middlebox Communication: Framework and Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract The purpose of this document is tocollectdevelop framework andput under discussionrequirements for a protocolallowingthat will allow fordecompositioncommunicating control data associated with IP/transport-layer data flows or aggregates ofapplication-awareness fromthem between intermediate packet processingin firewalls.devices and external controllers. The protocol will beused by application-aware entitiesextensible in order to allow for communicating arbitrary control data associated with packet flows and defining packet flow processing. It will include provisions for verifying the integrity ofapplications traversing firewalls dynamically. This kindeach message as well as ensuring authentication of all parties involved in the transactions. A major application of this protocol will be the controlallowsof packet processing policies in decomposed firewalls/NATs/NAT-PTs by externalized Application Level Gateways. This particular use will relieve firewalls/NATs from application-layer processing to improve their maintainability and performance. Examples of other possible applicationsusing session control protocolsinclude but are not limited totraverse firewalls while still retaining restrictive packet filtering policy. Networkbuffer managementtoolsand load balancing. Contents 1 Introduction.....................................................2 2 Terminology......................................................3 3 Case Study: Traversal of Applications Using Session Control Protocols across Firewalls/NATs ..................................5 4 Protocol Requirements for FCP....................................7 4.1 FCP Operational Model..........................................7 4.2 Functional Requirements: Management of Packet Flow Processing States .........................................................7 4.3 Rule Manipulation Operations...................................7 4.4 Soft-state Rule Design.........................................7 4.5 Rule Language..................................................7 4.5.1 Packet Matching Expressions..................................8 4.5.2 Rule Processing Precedence...................................8 4.5.3 Control State Content........................................9 4.6 Feedback......................................................10 4.7 Security......................................................11 4.8 Reliability...................................................11 4.9 Real-time Operation...........................................11 4.10 Extensibility................................................11 4.11 On Support Specific to NAT/NAPT/NAT-PT.......................12 5 Related Issues..................................................13 5.1 Access Control................................................13 5.2 Rule Ownership................................................13 5.3 Default Flows.................................................13 5.4 Location of FCP Controllers...................................14 6 Open Issues.....................................................14 6.1 Location of Intermediate Devices..............................14 7 Performance and Scalability Considerations......................15 8 Security Considerations.........................................15 9 Document Status.................................................15 10 Acknowledgments................................................16 1 Introduction Though the Internet has been designed to provide network layer connectivity end to end [2] it actually consists of mixed network realms. These include IPv4 networks, IPv6 networks, networks hidden behind NATs and firewalls. This problem was referred to as "transparency loss" and discussed in [3]. Applications being run across mixed realms mayalso utilizeexperience lack of interoperability or suboptimal performance. To assists applications in traversing network boundaries Application Level Gateways (ALGs) embedded in intermediate devices have been used. However, tight coupling of application and network/transport layer processing results in reduced maintainability of the intermediate devices. Built-in application awareness typically requires updates of operating systems with new applications or versions of it. Operators of such systems wanting to support new applications cannot use software supplied by third parties and are at the mercy of vendors of their equipment. Furthermore, support of numerous application protocols increases complexity of such integrated systems and may affect performance. To deal with this sort of problems we suggest decomposition of application awareness from network/transport layer processing. We assume that applications control network/transport layer processing in intermediate devices through a generic application-independent control protocol. In the common case, the application-awareness resides in proxies ("externalized ALGs") that hide boundary traversals from end-devices. +--------------------+ +------+-----------+ | +----------+ FCP | | Per-Flow | | +----------+|..........| | State | | | ALGs ||..........| FCP | Table | | policy +--------+ +----------+ | unit |-----------| | protocol | policy | | | ACL ~~~~~~~~~~~~~~+ server | __________+------+-----------+ | +--------+ | Intermediate | | Device | +--------------------+ Device | | Interfaces | | ... IN OUT ... Legend: .... FCP ~~~~ policy protocol Figure 1: Middlebox Communication Architecture The rest of this document describes framework and requirements for the missing piece, the control protocol. We refer tomanage packet-processing policies.this protocol as Flow Processing Control Protocol (FCP). Discussion on how FCP maps or does not map to an existing protocol is out of scope of this document. Section 2 defines terms used throughout this memo. In Section 3, we demonstrate the use of the FCP in a case study. Wesuggestformulate protocol requirements in Section 4. Issues that are related to protocol operation but do not affect protocol specification are summarized in Section 5. Unresolved issues are identified in Section 6. Section 7 reviews performance issues. Security is considered in Section 8 and status of this memo in Section 9. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. o Endpoint address - general term describing source or destination of a packet. This is, depending on context, IP address and/or TCP/UDP port number. o Packet matching expression - expression that specifies values of header fields of packets to be selected. The inspected header fields MAY be but are not limited to source and destination IP addresses, TCP/UDP port numbers, etc. o Packet flow - a sequence of packets matched by a packet matching expression. o Rule - a packet matching expression and control state used to determine processing of packets matched by the expression. o Session - a set of packet flows belonging to anextensible frameworkapplication. o Session control protocol - a protocol used to negotiate endpoint addresses of flows belonging to a session. Examples of such protocols are SIP, H.323, RTSP. o Proxy - an intermediary server that relays application messages from one entity to another one. A proxy acts as server for message senders and as client on behalf of the senders for message receivers. It may be used formanagementenforcement ofarbitrary per-flowapplication-level policies such as content filtering or message translation. With applications using session controlstatesprotocols, proxies typically relay session control protocols and do not relay data flows belonging to a session. o Packet filter - a network device that examines headers of forwarded packets and allows only packets conforming to a security policy to pass through. The security policy defines which endpoint addresses are considered trustworthy and which are not. For example, it may permit data traffic of an application identified by a port numbe only from/to a trusted proxy. o Network Address Translator (NAT) - a packet processing device that is able to map source and/or destination endpoint addresses of forwarded packet flows to a pool of other addresses. This technique is used to conserve IP address space and/or hide IP address of hosts behind the NATs from outside of the NATs. The NAT concept is described in [10]. o Bind - a pair consisting of an original and translated endpoint address. o Intermediate device - a packet-processing device located along end-to-end path. It may be a packet filter, NAT, intrusion detection system, load balancer, etc. o Firewall - centrally maintained devices set-up to increase networknodes. 1 Introductionsecurity by putting restrictions on information flows. The restrictions are applied with packet filters at the packet level and/or proxies at the application level. Optionally, NATs may be used. Note that the term "firewall" is sometimes used to refer to packet filters. o Application Level Gateways (ALGs) - application-aware modules that control processing state in firewalls/NATs and manipulate application messages to accomplish firewall/NAT traversal. Typically, ALGs are embedded in firewalls/NATs. They may also be externalized to remote proxies if a control interface between them and firewalls/NATs is provided [4]. o Flow Processing Control Protocol (FCP) - protocol for communicating flow processing policy between external controllers and intermediate devices. The intermediate devices accept only authorized FCP requests. The authorization can come from an internal access control list or an external policy server. o Access Control List (ACL) - policy defining who may access/manipulate controlled devices with FCP. The ACLs may be outsourced to an external policy server. 3 Case Study: Traversal of Applications Using Session Control Protocols across Firewalls/NATs Firewalls are trusted, administrator-maintained devices used toprotect networks from external attacksincrease network security by enforcing restrictions on information flows. The restriction policies are centrally defined and maintained by network administrators. The firewalls consist ofApplication Level Gateways (ALGs)proxies and packet filters.ALGsProxies are application-aware entities acting on behalf of untrusted hosts at application layer. They examine application protocol flows and allow only messages conformant to security policies to pass through. Optionally, they modify the messages to make them policy-conformant. Packet filters are used to impose security restrictions at lower layers. They usually inspect IP and TCP/UDP packet headers against tables of filtering rules. Only conforming IP packets are allowed to pass through filters. The packet filtering policy may be either 'default-permit' or'default-deny'.'default- deny'. 'Default-permit' policy allows all but explicitly stated IP flows whereas 'default-deny' policy allows only explicitly stated IP flows to pass through. Typically, the latter policy is set up to allow traffic from and to trustedALGsproxies to pass through.The 'default-deny' policyIt provides higher security by being more restrictive.ItThus, it is frequently deployed in corporate networks. Unfortunately,itthis policy makes firewall traversal difficult for applicationsthat useusing session bundles. This means that such applications (e.g., SIP[1],[5], H.323[2],[6], RTSP[7], and FTP[3]) negotiate[8])negotiate IP addresses and port numbers with a session control protocol dynamically and then use the negotiated addresses to establish packet streams for transport ofrawdata. This technique is useful, for example, if multiple applications want to receive RTP[21][9] flows and cannot share the same TCP/UDP port number or an application uses port numbers to demultiplex multiple incoming RTP flows. It is also necessary if IP address information is dynamic.WithoutAs akind of firewall control these applications cannot open firewall pinholes for their data streams dynamically. Additionally, they needresult, dynamically created sessions fail toquery or set address translations for their packet flows if the packet filters deploytraverse firewalls deploying static 'default-deny' filtering policies. If network address translation(NAT)[15]. Only then will they be able to include(NAT)[10] is deployed thetranslated addresses in theirtraversal fails as well because sessioncontrol protocols. We propose to use application-awareness residingsignaling conveys unroutable IP addresses and port numbers. This problem has been addressed intrusted nodes located outfirewalls/NATs by usage oftheembedded Application Level Gateways (ALGs) [15]. They adapt packetfiltersprocessing policy tomanage packet-filtering policies dynamically. Exploiting the application-awareness allows for implementation of very fine security policies that meetapplication needsbut still remain restrictive. Decomposition of application-awarenessdynamically. However, embedded ALGs suffer frompacket processing is likely tolimited maintainability, increaseperformancecomplexity ofpacket filtersfirewalls/NATs andmake maintenance of the application-awareness easier. Application logic residing in arbitraryfail to operate if message authentication or encryption is used. Thus we suggest using externalALGsapplication proxies that control firewalls/NATs and relieve them from application processing. Arbitrary application proxies may be added to manageable firewalls easily. Hop-by-hop security is enabled. Existing software such as SIP proxies or H.323 gatekeepers may be usedfor this purposewithouthaving to make packet filters understandduplicating theindividual applications. End- devices do remain unchanged. The only needed extension is a controlapplications' protocolbetweenstacks in theALGs and packet filters. For example, afirewalls/NATs. The reference scheme is depicted in Figure 2:. There are FCP-enabled, trusted, administrator-maintainedSIP may open temporary pinholes inproxies acting as external ALGs and controlling a packet filterfor media belonging only to SIP sessions considered trustworthy. This scenario is illustrated in Figure 1. Alocated within the same administrative domain. The packet filter implements the 'default-deny' packet filtering policy. It permits session control traffic from and to theALGs (SIP proxy, FTP proxy).trusted proxies and accepts FCP requests from them. TheALGsproxies use theirapplication- awarenessapplication-awareness to control the packet filter dynamicallythrough a control protocol. If a new application protocolwith FCP. They also enforce application-level policy such asH.323 is introduced no changes to packet filters are required. This setting is referred to in [11] as "internal service, separated proxy". This document summarizes requirements for the control protocol between the packet filters and their controllers. We call this protocol "Firewall Control Protocol" (FCP). We use the term FCP to refer to the general concept in this document. Discussion on how FCP mapsdropping messages infected with known viruses, ordoes not map to an existing protocol is out of scope of this document.lacking user authentication. TheFCP framework is described as follows. Section 2 defines terms used throughout this document. In Section 3, we formulate requirements for Firewall Control Protocol (FCP). Open issues that need additional discussion before translating thempolicy decisions may be delegated torequirements are presented in Section 3.7. Performance issues are introduced in Section 4. Related issues that do not impose requirements on FCP directly are listed in Section 5. Section 6 illustrates FCP usage by examples. Security considerations are described in Section 7 and status of this memo in Section 8.an external policy server. +--------+ | App. | | Policy | +---------+ SIP | Server |~~~~~~~~~| SIP+---------+_____________+_____________ | +--------+ ________| Proxy |________|SIP Proxy|\ | / +---------+.. +----+---------------+ | : FCP +------+-----------+ |__ ||RSTP +----------+ :...........| | Per-Flow | |__ SIP | ____| RSTP |..............| ||management| | | Per-Flow |State | |__ | / |tools |..............|Proxy |______________| FCP |StateTable | | | | +----------+ | unit |Table-------- | | | | FTP +---------+.............| | ACL | | | | _____|FTP Proxy|_____________+------+-----------+ | | | / +---------+ | Packet | | | | -----| Filter||-- +-----------+/ +----+---------------+/-----| |-- +-----------+| data streams/// +----+---------------+ +-----------+||----------->----// |+-----------+||----------------/|end-devices||------------<----- ||end-devices||+-----------+ (RTP, ftp-data, etc.) |+-----------+ |Inside | Outside Legend: ---- raw data streams ____ application control protocols ....Firewall Control Protocol Figure 1:FCPArchitecture 2 Terminology o Endpoint address - general term describing source or destination of a packet. This is, depending on context, IP address and/or TCP/UDP port number. o Packet flow _ a sequence of packets with identical source and destination endpoint addresses. o Session - a set of packet-flows belonging to an application. o Session control protocol - a~~~~ policy protocolused to negotiate endpoint addresses of flows belonging to a session. Examples are SIP, H.323, FTP control connection. o Flow descriptor - packet-matching expression describing a packet flow or a group of them. o Application Level Gateways (ALGs) - trusted, administrator- maintained, application-aware entities acting on behalfFigure 2: Use ofuntrusted hosts atFCP for Firewall/NAT Decomposition 4 Protocol Requirements for FCP 4.1 FCP Operational Model In theapplication layer. (ALGs are also called proxies.) o Packet filter - a network node that examines headersremainder offorwarded packets and allows only packets conforming tothis document we assume asecurity policy to pass through. The security policy defines which endpoint addresses are considered trustworthy andmodel in whichare not. For example, it may permit data traffic of an application only from/to ALGs. o Network Address Translator (NAT) - apacket processing in an intermediate devicethat is able to map source and/or destination endpoint addresses of forwarded packet flows tolocated at apool of other addresses. This techniquenetwork edge isused to conserve IP address space and/or hide IP address of hosts behind the NATs from outsidedetermined by an ordered set ofthe NATs.rules. TheNAT concept is described in [15]. o Firewall - centrally maintained devices set-up to protect a network from outside networks by putting restrictions on information flows.rules consist of packet matching expressions and control state. Therestrictionspacket matching expressions select packets and associated control state determines how selected packets areapplied withtreated. A packetfilters at themay match multiple packetlevel and/or ALGs atmatching expressions. If this happens theapplication level. Optionally, NATs mayfirst one will beused. o Firewall Control Protocol - protocol used to control packet filters using external controllers.taken. Thecontrollers MAY be ALGs such as SIP proxies, management tools or any other hostsrules are manipulated withauthorized access. There may be multipleFCP dynamically. Multiple FCP controllersdrivingMAY control apacket filter in parallel. Asinglecontroller may also control multiple filters if needed. The protocol may be used between remote as well as co- located nodes. o Bind - association between end-point address and application. Bindingintermediate device. It isusually implemented as API call if the receiving application resides at the same host to whichexpected that only asender sends packets. Iffew trusted hosts from apacket relayer is in the middle of packet path, an additional mechanism is needed to establish an association between relayer's and receiver's endpoint. 3 Requirements forsingle administrative domain will act as FCP3.1controllers. 4.2 Functional Requirements: Management of Packet Flow Processing States The primary goal of FCP is to allow for remote dynamic management of packetfiltering rules in a decomposed manner. Fromflow processing rules. As ageneral point of view what the FCP does is it controls per-flow states. The following requirements attempt to reach this abstraction and allow for easy extension ofminimum requirement, the FCP MUST enable controllers toa generic 'flow-state control' protocol. Such a protocol does not only allow to control filtering policy but also any other control data associated with packet-flows. In the remainderpermit/forbid processing ofthe section 3.1 we assume a model in whichspecific packet flowsor classes of flows are identified by packet matching expressions and associated with per-flow control states. The control state determines how matched packets are handled. Both flow matching expressionsandassociated states are manipulated by FCP. 3.1.1 Staterequest/release NAT/NAPT/NAT-PT[11] translations. 4.3 Rule Manipulation Operations FCP MUST allow for setting, releasing and querying packet flow processing rules. Operations like modification of existing rules and keeping them alive are most likely to be implemented with the 'set' operation.This increases protocol reliability in case of message loss/duplication and/or failure of the controlled node.The 'set' operation MAY either specify values of updated state elements explicitly or omit them to allow controlled entities to assign appropriate values. These MAY be default values (e.g. 0 for packet counter), ephemeral values, or current values if the state elements already exists (useful for keep-alive messages).3.1.2 Packet Matching Expressions4.4 Soft-state Rule Design. To avoid accumulation of stale rules in case of controller failures rules MUST have timers that expire if they are no more refreshed by controllers. FCP MUST enable controllers to refresh rules periodically. FCP MUST also allow controllers to set the timer's length -- it is frequently a controller that knows best what timer length is appropriate. If a controller does not specify timer value explicitly a default value will be assigned. A trivial value for infinite timer MUST be defined. 4.5 Rule Language This section specifies requirements for the language of packetmatching expressions.rules. Note that FCP-controlled hosts have to understand all expressions written in this language but FCP controllers may use only a subset of them.A)4.5.1 Packet Matchingexpressions are used to identify packet flows or classes of them. Experiences from packet filters like tcpdump [16] could be adopted.Expressions A) As a minimum requirement, the language of packet matchingexpressionexpressions MUST allow for specification of the following protocols and their respective header fields: - IPv4: source and destination IP address or group ofthem,them determined by a netmask, protocol number, TOS field - IPv6: source and destination IP address or group ofthem,them determined by a netmask, next header fields (Note that multiple fields may need to be traversed until a match is found.), traffic class field - UDP: source and destination port numbers or group of them - TCP:port numbers, SYN, FIN, ACKsource andRST flagsdestination port numbers or group of them, "SYN packets" permission - ICMP: type and code - IGMP: typeCompatibility with ipsec selectors (see Section 4.4.2 in [22]) is REQUIRED except the names that are subject to future extensions of FCP.B)Notion of packet filter interfaces is neededFCP controllers MUST be able to specify inthe expressions because different flow processing policieswhich direction packets mayapply at differenttraverse controlled devices. This requires notion of device interfaces.For example, a packet filter may want to drop all packets coming from the network insideThe notion ofthe firewall with source address not belonging to the network [18]. Predefinedinterfaceclasses such asis abstract and independent on interface technology and assigned IP address. Support for generic predefined interface names "in", "out", "loopback" (synonym for senders and receivers located at the controlled device), and "DMZ" (demilitarized zone)areis REQUIRED.C)Packet traversal direction may be expressed in various ways, for example by inbound and outbound interfaces or by interface and direction in which packets pass it. 4.5.2 Rule Processing Precedence The ability tospecifyindicate desired rule processing precedence is REQUIRED to enable controllednodesdevices to resolve conflicts between multiple applicable matchingexpressions.rules in a predictable manner. If no precedence is specifiedexplicitly,for a rule, default precedence will be assigned by FCP-controllednode.device. Multiple rules MAY share a single precedence.3.1.3Note: Though precedence sharing leaves processing order of rules with the same precedence undetermined it greatly simplifies certain common cases. For example, allocating a single precedence for all dynamically generated firewall pinholes does not affect firewall's behavior because all the pinhole rules result in the same action, which is packet forwarding. Then none of multiple FCP controllers needs to determine at which position a new rule will be inserted in a rule base. 4.5.3 Control State Content The control state associated with a packet matching expression in a rule keeps information related to a packet flow. It MAY include flow processing actions, timer information,encryption policy, statistics,number of matched packets, traffic limitations, etc. Members of the control states are subject to future extensions.This section discusses coreThe following control statemembers.members are REQUIRED: A)Actions define"Action" defines whether matched packets areprocessed. The REQUIRED actions are 'passing packets' and 'droppingforwarded. It takes the values 'pass packets', 'drop packets with or without ICMP notification'. B)Packet modifiers describe one or more rules for changing content of matched packets if needed. For example, these rules may be used to control network address/port translation or QoS classification. The modifier rules will consist of identification of the packet fields to be changed (syntax possibly a subset of packet matching expression language), operators (at least the assignment operator is required) and values. Modifier support is OPTIONAL. If implemented, the modifier has to be able to change the following protocol header fields: - IPv4: IP addresses, TOS field - IPv6: IP addresses, traffic class field - UDP: port numbers - TCP: port numbers Note that packet filters implementing modifiers are REQUIRED to recalculate packet checksums if a modifier is enabled. C) State timer"Rule timer" defines time remaining until state expiration.They are REQUIRED.See also discussion of soft-state ruledesign indesign. C) "Logging" of asynchronous events related to a rule. The protocol MUST allow FCP controllers to request logging of asynchronous events such as packet match and timer expiration. The protocol MUST enable controllers to specify log level and frequency. The log frequency is used to avoid voluminous logging if an event occurs frequently. Choice of thenext section.notification/logging mechanism is a configuration option that does not need to be specified with FCP. D) Uniqueflow"flow stateidentifiersidentifiers" are REQUIRED unless matching expressions are uniquely identifiable. Otherwise, state modification/releasingwouldcould notwork.work consistently. The identifiers may be generated either byclientscontrollers or byservers.controlled devices. They may be random or ephemeral. Ifclientscontrollers generate them, they MUST be random to avoidcollisions.collisions with identifiers generated by other controllers. If controllednodesdevices generate identifiers, they MAY be ephemeral. Ephemeral identifiers are typically shorter but lose their uniqueness under a failure.3.1.4 Soft-state Rule Design. Opening dynamic pinholes in firewalls makes only sense if they are closed on session termination. To avoid unreleased rules dueE) "Packet modifier" allows tosystem failures introducing timeoutsdescribe one or more rules for re- writing header fields of matched accepted packets. The modifier rules will consist of identification of the packet fields to be changed, operators (at least theper-flow control statesassignment operator isdesirable. Since controllers are most likely to know best how longREQUIRED) and operands. In particular, thesessions canmodifier MUST beit is appropriate to allow themable tospecify rule expiration period when setting upchange the following protocol header fields: - IPv4: IP addresses, TOS field - IPv6: IP addresses, traffic class field - UDP: port numbers - TCP: port numbers Note that if modifiers are used packet checksums MUST be recalculated. The following control state members are RECOMMENDED: F) "Packet counter" keeps number of packets matched by a rule.To keepG) "Maximum packets per second" specifies therules alive if session duration exceeds timeout periodmaximum allowed packet rate of a flow. Packets exceeding this rate will be dropped. H) "Maximum bitrate" specifies theissuermaximum allowed bitrate of aruleflow. Packets exceeding this rate willhave to send keep-alive-messages periodically. 3.1.5 Reflexive Rulesbe dropped. I) "Inactivity timer" specifies period of time after which a rule is released if no packet matches. J) "Reflexive Rules": In order to allow replies to TCP/UDP data flows originated from the internal side of firewall while still keeping the filtering policy as restrictive as possible,so-calledso- called reflexive rules are used. Reflexive rules are rules that allow packet flows reverse to explicitly permitted active flows. They are defined implicitly by permittingthemtheir generation within specification of the original explicit rules. They specify the same protocol, IP addresses, port numbers as flows matching the original rule do except the addresses and port numbers are swapped. If permitted, packet filters generate a reflexive ruleifwhenever a new flow matches an explicit rule. No controller's intervention is needed. The reflexive rules are valid only temporarily. TheyareMUST be released when an inactivity timer expires, the flow is terminated explicitly (e.g., by a FIN segment with TCP) or the original rule is deleted. If creation of reflexive rules is supported, FCP MUST allow to specify values of their control state members. Note: If endpoint address modifiers are enabled in the original rules they MUST be reflected in the reflexive rules; namelypacket- matchingpacket-matching expressions of the reflexive rules MUST match flows reverse to modified flows and modifiers MUST be enabled to translate endpoint addresses of reverse flow to addresses before modification.FCP support for permitting generation of reflexive rules is RECOMMENDED. If implemented, FCP MUST allow to specify their inactivity timers, and to which interface they apply. 3.2 Responses This section discusses content of FCP responses.4.6 Feedback FCP controllers need to receive feedback on their control messages in order to learn about results of requested operations. Both positive and negative responses are REQUIRED. Positive responses indicate successful operation andmayMAY possibly describe content of the controlled states or part of them.ControlledPer-flow control state or part of it is always returned if it was asked for by 'query' operation. Negative responses indicate failures and describe reasons for them. Minimum negative responses REQUIRED are "Authenticationneeded",failed", "Not permitted", "SyntaxError", "Unknown control state field", and "Invalid control state field value". 3.3Error". 4.7 Security In order to prevent unauthorized entities fromlearningmanipulating thefirewallstateand controlling itof controlled device the FCP channel MUST beprivate and authenticated. FCP privacy by encryption is REQUIRED since no general assumption can be made aboutsecure. It MUST include provisions for verifying theprivacyintegrity oftransmission channel.each message as well as ensuring authentication of all parties involved in the transaction. It is RECOMMENDED that the FCP channel is private so that a malicious listener cannot find out packet processing policy easily. Theencryptionsecurity protocols may take place either at lower layers (IPSec, TSL) or at the FCP layer. Though IP-address based authentication may be satisfactory in particular cases cryptographic authentication is REQUIRED generally. Note that we discuss theauthentication takes placesecurity between FCP controllers and controllednode. Authenticationdevice. Security mechanisms usedbetween FCP-enabled ALGs end ALG usersby applications to communicate with FCP controllers are a separate issue out of scope of this memo.3.44.8 Reliability As with almost any other control protocol reliability is REQUIRED regardless if it is implemented by FCP itself or an underlying transport protocol.3.54.9 Real-time Operation The protocol transactions must be fast in terms of RTT to avoid introducing delays to applications. Unless network loss results in retransmission, total transaction time SHOULD beas close tooneRTT as possible.RTT. Note:ifIf TCP is used as underlying protocol to provide reliability, pre-established TCP connections may be used to reduce transaction time.3.64.10 Extensibility Protocol extensibility is REQUIRED in order to enable reuse of FCPto manage arbitrary packet-flow processing state such as ipsec encryption policies [22], accounting data, etc.for control of a variety of packet-processing mechanisms. In particular, adding new control statefields,fields (e.g., buffer management information), new reply codes and elements of packet matching expression language MUST be supported. The protocol MUST conveytheprotocol version number in order to makethetransition to potential future versions easier.3.7 Open Issues 3.7.1 Multicasting Does control of multicasting flows introduce any challenges to FCP? In particular, do multicasting flows require some specific state4.11 On Support Specific tobe maintained inNAT/NAPT/NAT-PT One of thecontrolled packet processing devices? 3.7.2 Controller/Firewall Discovery HowFCP purposes is toestablish a relationcommunicate NAT/NAPT/NAT-PT binds betweenthe controlled packet filterscontrollers andtheir controllers? Is this to be done administratively? Should a discovery mechanism be deployed instead? If so, does it belong to FCP's scope? Note that if deployed, the discovery mechanism MUST be secure. If there are multiple packet filters how does a controller know whichcontrolled devices. Knowledge ofthem it shouldthe binds is necessarily needed by session controlin orderproxies toget an application through a firewall? In fact, itoperate properly. The primary question isimpossible unless the controller knows routing tables along the path between end-devices andwho creates thefirewalls. 3.7.3 Subscribe-Notify The protocol MUST allow FCPbinds. One alternative is controllerstorequestlogging of asynchronous events. Choice of the notification/logging mechanism seems to beaconfiguration option. FCP is abstractnew bind anddoes not mandate or specify the mechanism. DiscussionNATs create and return it. The other choice isneeded on: o To what events couldthe controllerssubscribe? Probablycreate a bind and instruct NATs tocontrol- state changes caused by explicit FCP operations, internal events (e.g., timer expiration, exceeded numberuse it. Locating the bind logic in NATs follows the decomposition concept "IP/transport intelligence in controlled devices, application intelligence out ofpermitted packets), events triggered by matched packets, or allthem". It relieves controllers such as SIP proxies from maintenance ofthem. o Notification frequency. Generating a notification for every eventthe address pools and making bind assignments. It avoids collisions that wouldcertainly notbeuseful for events triggered by matched packets. Instead, periodical notifications or notifications on modulo n-th eventdue if multiple controllers wouldbe useful. 3.7.4 NAT Support Packet filters deploying NAT translate only endpoint addresses conveyed in IP/UDP/TCP headers. ALGs are needed to translate endpointaccess a single device. (We do not consider splitting a pool of public addressesconveyed in session control protocols. Thus, external ALGs have to haveamong multiple controllers a solution. It would beat theability to query or/and setpurpose of NAT which is addresstranslations for use in session control. There are several questions about how to support interactionsharing.) A minor drawback ofFCP controllersthis logic placement is it requires two-stage transactions if NATs are co-located withNATs. Thefirewalls. In the firstone is how doesstage, a controllerknow that the controlled node deploys NAT. This knowledge is needed since FCP flows for scenarios with NATs can differ from those without them. For example, a SIP proxymust findout the address translation before forwarding an INVITEout, if NATis enabled. The same proxy does not haveapplies todo anything at this call stage if no NATa given address and request a bind to include in its signaling. In the second stage, when application signaling isdeployed. The knowledge of NAT deploymentover, it permits a packet flow using the reserved translation. With bind logic residing in controllers, both operations may bestatically configureddone jointly in theFCP controllers or preferably obtained with a protocol from controlled nodes. FCP could be used for this purpose atsecond phase and thebeginning of every transaction. This alternative supports scenariosfirst phase can be skipped. A specific scenario whereNAT selectively applies only to traffic from/to some hosts behindlocating thefirewall without havingbind logic toconfigure this policy in every single FCP controller. The next questioncontrollers iswho manages the address translation. Controller-driven NAT compels ALGsadvantageous is if a controller wants tomaintainmake sure the same addresspools. Clearly more than onetranslation is applied in multiple controlled devices. Clearly, this wouldexpect from, for example, SIP proxy. Additionally, synchronizationnot be possible if the devices assigned the binds independently. We leave the answer to location ofaddress pool management would needbind intelligence to configuration. It is REQUIRED that FCP supports both alternatives. The following protocol operations are REQUIRED: o FCP controllers MUST besolved for multiple controllers. Thus, management byable to request NAT translations. If NAT is used, controllednodes seemsdevices allocate an address translation and return it. o FCP controllers MUST be able to set NAT translations. (Note that this can be accomplished with modifiers.) Controlled devices MUST be able to indicate if themore viable alternative. In this case,translation cannot be set because it is already reserved. o With NAPT, allocating port blocks is REQUIRED, i.e., FCP controllers MUSThave the additional abilitybe able toqueryrequest a translation of a contiguous block of port numbers andreleasecontrolled devices MUST allocate abinding or groupcontiguous block ofthem betweentranslated port numbers to such request. The least significant bit of both private andpublic endpoint addresses. Binding of address groupstranslated port numbers MUST be same. It is needed, for example,to accommodateby RTP[21][9], which recommends allocation of even port numbers for itself, subsequent port number for RTCP and contiguous block of port numbers for layered encoding applications. o The controllers MUST be able to release the allocated bindings. o The allocated address bindings are subject to timer expiration in a similar way aspacket-filteringsoft-state packet-processing rules are.4 Performance Issues The 'default-deny-and-dynamic-open' filtering policy compels stateful packet filters to maintain potentially huge tables of filtering rules. The rule lookup-processing overhead grows with number of rules and may lead to increased packet latency. Mechanisms for fast rule lookup in large, frequently changing filter databases are needed. Results of some recent research in this area were published in [7], [8], and [9]. Both complex packet matching expressions as well as complex actions such as packet modification may affect filtering performance. The trade-off between rule complexity and processing speed is left to be resolved by administrator.5 Related Issues This Section explicitly names related features that are out of scope of protocol requirements and are matter of implementation, administrative policy or anything else. 5.1Complex versus Fast Rules As already noted in the Section on performance there is a trade-off between complex and simple rules. Though FCP-controlled nodes must understand all rules permitted by FCP language, execution of complex rules may degrade their performance. The trade-off between complex and simple rules is to be resolved by administrators of FCP controllers. 5.2Access Control There may be differentpoliciesaccess control lists (ACLs) defining who may access and modify whatrules.rules in an intermediate device. For example, anaccess policyACL may specify that an FCP controller may only control rules describing traffic to and from a specific subnet. Additionally, it may define in which way the controller is required to authenticate and which precedence it may use for its rules. The access control policies may be stored and applied locally or they may be outsourced to an external policy server using a policy protocol. In either case they are out of scope of FCP. The only required FCP feature is authentication support.5.3 State5.2 Rule Ownership Multiple controllers may control a singlenodedevice with FCP. It is desirable to avoid modification of per-flow control states by other entities than those that created them (perhaps with exception of a network manager).However,Thus, thestate ownership is not a protocol but packet filter requirement.controlled devices MUST implement the notion of rule ownership. The only required protocol functionality is authentication.5.45.3 Default Flows If a packet does not match any of matching expressions maintained in a packet filter a defaultper-flow control staterule has to be applied. Otherwise, packet handling would be undefined. Thus, all packet filters controlled by FCP must always maintain the default rule. The matching expression of the rule matches all packets at lowest priority so that any other matching rules take precedence over it. The content of the default control statemayMAY be modified with FCP, the matching expression MUST NOT. 5.4 Location of FCP Controllers FCP controllers maynot.be located on any side of controlled network device. Their location with respect to the controlled device does not affect protocol specification but may result in different protocol flows. For example, an application proxy located on the private side of a NAT needs to set up a single permanent translation that enables it to receive inbound messages and forward them to their destinations. If the proxy is located on the public side, it needs to set up multiple translations for inbound messages forwarded to individual destinations located on the private side. 6 Open Issues 6.1 Location of Intermediate Devices Determining which intermediate device a controller should control is out of the scope of this document. Administrators can accomplish this task manually. Alternatively, a discovery protocol could be used. A difficult problem arises if packet flows may take path through multiple intermediate devices at the network edge. FCP controllers cannot easily determine which of them they should control. The problem is illustrated in the example depicted in Figure 3: IN | OUT +-----+ SIP +------------+ +-------+ | SIP |____________| firewall 1 |____________| SIP | |proxy|............| | | proxy | +-----+ : +------------+ +-------+ | : FCP ... | | | MGCP : +------------+ MGCP | | :.......|firewall i | | +--------+ : +------------+ +-------+ |media | : ... | ?<-------|media | |gateway |--->? : +------------+ |gateway| +--------+ :..|firewall N | +-------+ +------------+ | Figure 3: Controlling Multiple Intermediate Devices In this example, multiple firewalls 1 .. N are present in a network. A SIP proxy relays SIP signaling, has knowledge of all the firewalls and is authorized to control them. It knows source and destination endpoints of data flows belonging to a session but does not know which of the firewalls they will traverse. It cannot calculate it because it does not know routing tables along the entire end-to-end path. Solutions are still sought. A possible solution is to let controllers instruct all controlled devices in parallel, most likely using multicast. This solution scales only for a small number of controlled devices. With NAT, it assumes the translation assignments to be communicated from FCP controllers to controlled devices. 7 Performance and Scalability Considerations The ability to add processing rules to control packet-processing devices dynamically may result in creation of large and rapidly changing rule tables. For example, if FCP is used to open pinholes in a 'default-deny-and-dynamic-open' firewall for Internet telephony sessions the table size grows with number of sessions linearly. The lookup processing overhead grows as well and may lead to increased packet latency. Maintenance of per-flow states makes use of FCP meaningful only in network edges. Mechanisms for fast rule lookup in large, frequently changing filter databases are needed. Results of some recent research in this area were published in [12], [13], and [14]. Use of packet modification may also affect processing performance. A performance improvement may be reached administratively by definition of an application-aware rule precedence policy. A controller may request that rules for packet flows with higher expected packet rate will be assigned a higher precedence than rules for packet flows with lower packet rate. Then, the most commonly accessed rules will be processed first and average packet processing time will decrease. Note that this mechanism is not extremely fair to streams with low bandwidth consumption since their processing time will increase. 8 Security Considerations The security requirements for the control protocol are described in Section 4.7. Note that security of the protocol does not help alone. Additionally, security of the entire control system is subject to security of the FCP controllers and access control in FCP-controlled devices (see Section 5.1.). 9 Document Status This document is in the stage of collection of requirements and open issues. Numerous updates result from discussions on the foglamps mailing list. Previous versions were issued as draft-kuthan-fcp- {00|01}.txt. 10 Acknowledgments Numerous people have been contributing to collection of these requirements. Many document clarifications and enhancements resulted from discussions on the foglamps mailing list. We specially acknowledge the following people for their help: Scott Bradner, Stefan Foeckel, Melinda Shore, Dave Oran, and Jon Peterson. The firewall traversal problem was stated in [15], [16]. Appendixes A Examples This section shows how to use FCP by examples. Many of the examplesare relatedrefer to the application described in Section 3 and use SIPbecause it isas a prominentcaseexample of a session controlprotocols. 6.1protocol. A.1 FCP Transaction Examples This section illustrates how FCP requests could look like. The requests in the following examples use abstract syntax in this form: <state manipulation operation> PME=<packet matching expression> [<control-state-element-id> [=<value>] ...] The syntax of packet matching expression is borrowed fromtcpdump[16]. Atcpdump. An additional keyword 'if'specifying at which filter'sspecifies interface to whose incoming queue the matching expressionappliesisadded.applied. A similar syntax is used for definition of packet modifiers. Discussion on how these abstract FCP examples map or do not map to existing protocols is out of scope of this document. In the examples bellow, a protected host behindthea firewall has the address 10.1.1.1, an outside host has the address10.1.3.1130.149.17.15 and thepacket filterfirewall's outbound interface has10.1.2.42.193.174.152.25. Example 1: Opening a Pinhole in a Packet Filter for an Outgoing Flow In this example, a controller opens a pinhole for a packet flow being sent from the inside to the outside host. SET PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst port 77 and dst host10.1.3.1'130.149.17.15' action=pass => REPLY: OK Example 2: Opening a Pinhole in a Packet Filter w/NAPT for an Outgoing Flow In this example, a controller queries a NAT bind and opens a pinhole for a translated packet flow being sent from the outside to the inside host through a NAT.Before opening the pinhole, the controller queries network address translations. NAT_bind_incoming PME='dst host 10.1.1.1 and udp dst port 55'QUERY_NAT_TRANSLATION udp:10.1.1.1:55 => REPLY: NAT_OK,dst host 10.1.2.42 and udp dst port 66udp:10.1.1.1:55=udp:193.174.152.25:48374 SET PME='dst host10.1.2.4210.1.1.1 and udp dst port6655 and if out and src host10.1.3.1130.149.17.15 and udp src 77' action=PASSmodifier='dst host = 10.1.1.1, udp dst port = 55'=> REPLY: OK Example 3: TOS Control The controller instructs the controllednodedevice to set TOS of matched packets to hexadecimal value 0x10. SET PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst port 77 and dst host10.1.3.1' modifier='tos0x10'130.149.17.15' modifier='tos=0x10' => REPLY: OK Example 4: Querying Number of Matched Packets QUERY PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst port 77 and dst host10.1.3.1'130.149.17.15' packet_count => REPLY: OK, packet_count=333 Example 5: Refreshing Per-Flow State SET PME='if in and udp src port 55 and src host 10.1.1.1 and udp dst port 77 and dst host10.1.3.1'130.149.17.15' => REPLY: OK Example 6:Prevention of Spoofed Packets Originating from LocalNetwork Ingress Filtering See[18][17] for more details on this scenario. The first rule denies all packets on the "in" interface. The second rule with higher priority explicitly permits packets from the 10.1.2 network. SET PME='if in' precedence=default action=drop(no_ICMP) => REPLY: OK SET PME='if in andnotsrc net 10.1.2'action=drop(no_ICMP)precedence=high action=pass => REPLY: OK Example 7: Reflexive HTTP Rules The next rule allows controlled packet filters to create temporary rules that permit inbound TCP packets for HTTP transactions initiated from the internal side of a firewall. SET PME='if in and tcp dst port 80' REFLEXIVE='permit=yes, timer=180s,apply_to=out'if=out' => REPLY: OK If an HTTP request from 10.1.1.1:37313 to10.1.3.1:80130.149.17.15:80 matches this rule a reflexive rule of the following form is generated: PME='if=out and tcp src port 80 and src host10.1.3.1130.149.17.15 and tcp dst port 37313 and dst host 10.1.1.1' Example 8: Packet Redirection In this scenario, all HTTP traffic from inside network is redirected to a Web proxy (10.1.4.4) transparently. This scenario is sometimes also referred as 'transparent proxy'. The rule allows for automatic creation of reflexive rules. SET PME='if in and tcp dst port 80' modifier='ip dst host = 10.1.4.4' reflexive_rules='permit=yes, inactivity_timer=240s, if=dmz' => REPLY: OK If an HTTP request from 10.1.1.1:37313 to10.1.3.1:80130.149.17.15:80 matches this rule a reflexive rule of the following form is generated: PME='if=dmz and tcp src port 80 and src host 10.1.4.4 and tcp dst port 37313 and dst host 10.1.1.1' modifier='ip srchost=10.1.3.1' 6.2host=130.149.17.15 A.2 Using FCP to Getaan Outgoing SIP/SDP Session through a'Default-Deny''Default- Deny' Firewall w/NAPT This example illustrates how FCP can be used to get an outgoing SIP call through a firewall deploying 'default-deny' packet filtering policy. Network configuration as displayed in Figure 1 is assumed: The packet filter allows SIP signaling only from/to a SIP proxy, the proxy rejects calls considered untrustworthy, and instructs the packet filter to open pinholes for RTP streams belonging to trustworthy SIP/SDP sessions for the time of session duration. Additionally, NAPT is deployed. Precise timing of opening and closing pinholes in SIP sessions and issues such as 183 provisional media and re-invites are subject to discussion which is out of scope of this document. Management of RTCP and ICMP pinholes is omitted for the sake of simplification. Note that the pinholes in the packet filter arequietquite 'wide'. This means they allow packets with arbitrary source address and port number to pass through because SDP does not communicate source endpoint addresses. Notation: In the diagram "INV 10.1.1.1:55" means an INVITE message with the SDP body indicating IP address 10.1.1.1 with port 55 as the receiving address and port for an incoming media-stream. Similarly "200 OK10.1.3.:77"130.149.17.15:77" indicates an OK response with IP address10.1.3.1130.149.17.15 and port 77 for receiving media. The value 0.0.0.0:0 stands for any IP address and port number. Per-flow control states in this example are identified by packet matching expressions. +---------------------------------------------+--------------------+ | INSIDE | OUTSIDE | +---------------------------------------------+--------------------+ 10.1.1.110.1.2.42 10.1.3.1 UAC SIP Proxy AuthServer FW UAS | | | | | /* process SIP invitation; do not open firewall pinholes until callee accepts the call */ | ----------------->| | | | | INV 10.1.1.1:55 | | | | | | ------> | | | | | auth ? | | | | | <------ | | | | | OK auth | | | | | | | | -------------------------------------------> | | | INV 10.1.1.1:55 | /* process SIP OK, open pinholes for outgoing and incoming media as soon as SIP ACK arrives */ | | <------------------------------------------- | | | 200 OK 10.1.3.1:77 | | <-----------------| | | | 200 OK 10.1.3.1 77| | | | ----------------->| | | | ACK | ----------------------> | | | |FCP SET | | | |PME='dst udp 10.1.3.1:77 | | | | src udp 0.0.0.0:0 | | | | if=in', action=PASS | | | | <---------------------- | | | | FCP OK | | | | ----------------------> | | | |FCP SET | | | |PME='dst udp 10.1.1.1:55 | | | | src udp 0.0.0.0:0 | | | | if=out', action=PASS | | | | <---------------------- | | | | FCP OK | | | | -------------------------------------------> | | | ACK | | | ...............................................................> | | RTP DST 10.1.3.1:77 | | <............................................................. | | RTP DST 10.1.1.1:55 | /* close pinholes when either party sends SIP BYE */ | | <------------------------------------------- | | | BYE | | | <---------------- | | | | BYE | | | | ----------------->| | | | 200 OK | | | | | ----------------------> | | | |FCP RELEASE | | | |PME='dst udp 10.1.3.1:77 | | | | src udp 0.0.0.0:0 | | | | if=in' | | | | <---------------------- | | | | FCP OK | | | | ----------------------> | | | |FCP RELEASE | | | |PME='dst udp 10.1.1.1:55 | | | | src udp 0.0.0.0:0 | | | | if=out' | | | | <---------------------- | | | | FCP OK | | | |--------------------------------------------> | | | 200 OK | | Figure 2: Protocol Flow for "SIP Session over Firewall" 6.3 Using FCP to Get a SIP/SDP Session through a NAT-enabled Firewall This example is analogous to the previous one. Additionally, NAT is deployed. +---------------------------------------------+--------------------+ | INSIDE | OUTSIDE | +---------------------------------------------+--------------------+ 10.1.1.1 10.1.2.42 10.1.3.1193.174.152.25 130.149.17.15 UAC SIP Proxy AuthServer NAT/FW UAS | | | | | | | | | | /* process SIP invitation, bind to a public address for receiving media, modify the invitation accordingly; do not open firewall pinholes until both parties agree to establish a call; note that binding of source address for outgoing media is not done because SDP does not care about source addresses */ | ----------------->| | | | | INV 10.1.1.1:55 | | | | | | ------> | | | | | auth ? | | | | | <------ | | | | | OK auth | | | | | | | | | | ----------------------> | | | |FCPbind_incomingquery_nat | | | |dstudp10.1.1.1:55:10.1.1.1:55 | | | | <---------------------- | | || OK dst udp 10.1.2.42:66|OK udp:193.174.152.25:66 | | | | -------------------------------------------> | | | INV10.1.2.42:66193.174.152.25:66 | /* process SIP OK, open NAT-enabled pinholes for outgoing and incoming media as soon as SIP ACK arrives */ | | <------------------------------------------- | | | 200 OK10.1.3.1:77130.149.17.15:77 | | <-----------------| | | | 200 OK10.1.3.1 77| |130.149.17.15:77 | |----------------->| || ----------------->|--------------------------------------------->| | ACK | ----------------------> | | | |FCP SET | | | |PME='dst udp10.1.3.1:77 |130.149.17.15:77 | | | src udp 0.0.0.0:0 | | | | if=in', action=PASS | | | | <---------------------- | | | | FCP OK | | | | ----------------------> | | | |FCP SET | | | |PME='dst udp10.1.2.42:66|10.1.1.1:55 | | | | src udp 0.0.0.0:0 | | | | if=out', action=PASS, | | | |modifier='dst udp | | | | 10.1.1.1:55'| | | | <---------------------- | | | | FCP OK | | | | -------------------------------------------> | | | ACK | | | ...............................................................> | |RTPUDP/RTP DST10.1.3.1:77130.149.17.15:77 | | <...........................................~................... | |RTPUDP/RTP DST 10.1.1.1:55RTPUDP/RTP DST10.1.2.42:66 |193.174.152.25:66| /* close pinholes when either party sends SIP BYE */ | | <------------------------------------------- | | <---------------- | BYE | | | BYE | | | | ----------------->| | | | 200 OK | ----------------------> | | | |FCP RELEASE | | | |PME='dst udp10.1.3.1:77 |130.149.17.15:77 | | | src udp 0.0.0.0:0 | | | | if=in' | | | | <---------------------- | | | | FCP OK | | | | ----------------------> | | | |FCP RELEASE | | | |PME='dst udp10.1.2.42:66|10.1.1.1:55 | | | | src udp 0.0.0.0:0 | | | | if=out' | | | | <---------------------- | | | | FCP OK | | | | ----------------------> | | | |FCP release_bind | | | |dstudp 10.1.1.1:55 | | | | <---------------------- | | | | OK | | | | -------------------------------------------> | | | 200 OK | | Figure3:4: Protocol Flow for "SIP Session over NAT"6.4 SIP and Mobile IP through Firewalls This section gives hints on how FCP could be used to set up firewall traversal for Mobile IP [19]. In the following examples, mobility agents use FCP to permit data flows belonging to authenticated mobile hosts. Note that this kind of filtering policy is not as detailed and restrictive as an application-aware policy. A typical scenario is shown in Figure 4. A mobile node M moved from its home subnet to another one during a SIP call. The foreign subnet is located on the external side of the firewall protecting the home subnet.B Bibliography 1 S. Bradner: " Theforeign network deploys no firewall. M is using a foreign agent care-of address. Media streams between M and C are shown in the figure, SIP signaling is omitted. Foreign subnetInternetHome subnet ---------------------------------><-----------><-------------------- +-------+ | | C>M C>M +------+ M>C | call | +--------+ +-----+ | |--------------------------->|party C| | | | | |mobile| | |-->| home |-->|home | | node | +-------+ +-------+ |firewall| |agent| | M |<--|foreign|<===========================| |<==| | +------+ |agent | +--------+ +-----+ +-------+ encapsulated M<C M<C Figure 4: Firewall TraversalStandards Process -- Revision 3", RFC 1602, IETF, October 1996. 2 B. Carpenter: "Achitectural Principle ofSIP and Mobile IP In this scenario, the following packet filtering policy could be set up with FCP: 1) Home agent is allowed to send encapsulated mobile IP traffic anywhere it wants through the firewall. 2) 'C>M' permission remains unchanged. 3) The home agent may optionally forbid all outbound streams originated by M. If reverse tunneling for mobile IP [20] is used as shown in Figure 5, the home agent will instruct the firewall to open tunnels between trusted foreign agents and the home agent. If there is a firewall deployed in the foreign networktheforeign agent uses FCP to open tunnels in the same way. Note that considerable trust is delegated to the peer domain since inbound tunneled traffic is accepted as is. Applying packet-filtering rules to tunneled packets could be usedInternet", RFC 1958, IETF, June 1996. 3 B. Carpenter: "Internet Transparency", RFC 2775, IETF, February 2000. 4 P. Srisuresh: " Framework formore restrictive policy. Foreign subnet Internet Home subnet ---------------------------------><-----------><-------------------- +-------+ C<M encapsulated M>C | | C>M +------+ +--------+ | call | +--------+ +-----+ | | | | |party C|<--| |<--| | |mobile| |foreign | +-------+-->| home |-->|home | | node |-->+-------+==>|firewall|==============>|firewall|==>|agent| | M |<--|foreign|<==| |<==============| |<==| | +------+ |agent | +--------+ +--------+ +-----+ +-------+ : encapsulated M<C :...........: :...........: FCP FCP Figure 5: Reverse Tunneling of SIP and Mobile IP If reverse tunneling is not used and the foreign network deploys a firewall the foreign agent can use FCP to permit data flows originating from the mobile host. Otherwise, the packets would be filtered out by anti-spoofing rules. See Figure 6. Foreign subnetinterfacing with Network Address Translator", IETF, InternetHome subnet ---------------------------------><-----------><-------------------- +-------+ M>C | | C>M C>M +------+ M>C +--------+ | call | +--------+ +-----+ | |-------------->| |-->|party C| | | | | |mobile| |foreign | | |-->| home |-->|home | | node | +-------+ |firewall| +-------+ |firewall| |agent| | M |<--|foreign|<==| |<==============| |<==| | +------+ |agent | +--------+ +--------+ +-----+ +-------+ : :............: encapsulated M<C FCP M<C Figure 6: SIP and Mobile IP w/2 Firewalls 7 Security Considerations The security requirements for the control protocol are described in Section 3.3. Note that security of the protocol does not help alone. Additionally, security of the entire control system is subject to security of the FCP controllers and authentication policy installed in the hosts under FCP control. Security provided by FCP-controlled systems is subject to administration policy maintained in FCP controllers. 8 Document Status This document is in the stage of collection of requirements and open issues. In the next stage, translation of the open issues into requirements and discussion of all the requirements will follow. Finally, the requirements will be mapped to protocols. 8 Acknowledgments Numerous people contributed, are contributing and committed to contribute to collection of these requirements. The firewall traversal problem was statedDraft, July 2000. Work in[11], [12]. Appendix A Bibliography [1]progress. 5 M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg: "SIP: Session Initiation Protocol", RFC 2543, IETF, March 1999.[2]6 ITU-T Recommendation H.323. "Packet-based Multimedia Communications Systems," 1998.[3]7 H. Schulzrinne, A. Rao, R. Lanphier: "Real Time Streaming Protocol", RFC 2326, IETF, April 1998. 8 Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", RFC 959, IETF. October 1985.[4] Case, J., Fedor, M., Schoffstall, M.9 Schulzrinne, Casner, Frederick, Jacobson: "RTP: A Transport Protocol for Real-Time Applications", Internet Draft, Internet Engineering Task Force, March 2000, Work in progress. 10 P. Srisuresh andJ. Davin, "The Simple Network Management Protocol", RFC 1157, IETF, May 1990[5] M. Leech,M.Ganis, Y. Lee, R. Kuris, D. Koblas,Holdrege: "IP network address translator (NAT) terminology andL. Jones: "SOCKS Protocol Version 5",considerations", RFC1928,2663, IETF,April 1996. [6] Postel, J. and Reynolds, J.: "TelnetAugust 1999. 11 G. Tsirtsis, P. Srisuresh: "Network Address Translation - ProtocolSpecification",Translation (NAT-PT)", RFC854,2766, IETF,May 1983. [7]February 2000. 12 A. Feldmann, S. Muthukrishnann: "Tradeoffs for Packet Classification", In Proc. IEEE INFOCOM 2000, 2000.[8]13 V. Srinivasan, S. Suri, G. Varghese: "Packet Classification Using Tuple Space Search", In Proc. ACM SIGCOMM '99, 1999.[9]14 P. Gupta, N. McKeown: "Packet Classification on Multiple Fields", In Proc. ACM SIGCOMM '99, 1999.[10] J. Touch: "Report on MD5 Performance", RFC 1810, IETF, June 1995. [11]15 J. Rosenberg, D. Drew, H. Schulzrinne: "Getting SIP through Firewalls and NATs", Internet Draft, Internet Engineering Task Force, Feb. 2000. Work in progress.[12]16 M. Shore: "H.323 and Firewalls: Problem Statement and Solution Framework", Internet Engineering Task Force, Feb. 2000. Work in progress.[13] S. Mercer, A. Molitor, M. Hurry, T. Ngo: "H.323 Firewall Control Interface (HFCI)", Nov. 1998. Expired Internet Draft. [14] F. Baker: "IP Forwarding Table MIB", RFC 1354, IETF. July 1992. [15] P. Srisuresh and M. Holdrege: "IP network address translator (NAT) terminology and considerations", RFC 2663, IETF, August 1999. [16] S. McCanne, C. Leres, V. Jacobson: "tcpdump, the protocol packet capture and dumper program"; available at ftp://ftp.ee.lbl.gov/tcpdump.tar.Z [17] Rusty Russel: "Linux IP Firewalling Chains", http://www.rustcorp.com/linux/ipchains/ [18]17 P. Ferguson, D. Senie: "Network Ingress Filtering: Defeating Denial of Service Attacks which Employ IP Source Address Spoofing", RFC2267, IETF, January 1998. [19]C. Perkins: "IP Mobility Support", RFC 2002,2827, IETF,October 1996. [20] C. Montenegro: "Reverse Tunneling for Mobile IP", RFC 2344,May1998. [21] Shulzrinne, Casner, Frederick, Jacobson: "RTP: A Transport Protocol for Real-Time Applications", Internet Draft, Internet Engineering Task Force, March 2000, Work in progress. [22] S. Kent, R. Atkinson: "Security Architecture for the Internet Protocol", RFC 2401, IETF, November 1998. B2000. C Glossary of Abbreviations ACL Access Control List ALG Application Level Gateway DMZ Demilitarized Zone FCPFirewallFlow Processing Control Protocol FTP File Transfer Protocol IP Internet Protocol HTTP Hypertext Transfer ProtocolMAC Message Authentication Check MTU Maximum Transmission UnitMGCP Media Gateway Control Protocol NAPT Network Address Port Translation NAT Network Address TranslationNAPTNAT-PT Network AddressPortTranslation - Protocol Translation RTP Transport Protocol for Real-time Applications RTSP Real Time Streaming Protocol RTT Round Trip Time SDP Session Description Protocol SIP Session Initiation Protocol TCP Transmission Control Protocol TOS Type of Service UDP User Datagram Protocol D Authors' Addresses Jiri Kuthan GMD Fokus Kaiserin-Augusta-Allee 31 D-10589 Berlin, Germany E-mail: kuthan@fokus.gmd.de Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: jdrosen@dynamicsoft.com E Full Copyright Statement Copyright (c) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.