Network Working Group M. Shore Internet-Draft D. McGrew Expires: March 11, 2007 Cisco Systems September 7, 2006 An Authorized IP Firewall Control Application draft-shore-afwc-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 11, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Authorized Firewall Control Protocol provides an interface that allows network entities to request firewall and NAT services and resources. It is an instance of a protocol that provides authorizations and other security servcies, and interworks with other such instances. AFWC uses its authorization facilities to provide network administrators more control over network border admissions decisions than is provided by other firewall pinholing protocols. Shore & McGrew Expires March 11, 2007 [Page 1] Internet-Draft AFWC September 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Network scenarios . . . . . . . . . . . . . . . . . . . . . . 4 3. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Pinholes . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Firewall pinholes . . . . . . . . . . . . . . . . . . . . 8 4.2. NAT Table mappings . . . . . . . . . . . . . . . . . . . . 8 5. Access Type . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Open Pinhole Exchange . . . . . . . . . . . . . . . . . . 10 6.1.1. Start message . . . . . . . . . . . . . . . . . . . . 10 6.1.2. Offer Message . . . . . . . . . . . . . . . . . . . . 10 6.1.3. Request message . . . . . . . . . . . . . . . . . . . 11 6.1.4. Response message . . . . . . . . . . . . . . . . . . . 12 6.2. Close Pinhole Exchange . . . . . . . . . . . . . . . . . . 13 7. Data formats . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. IPV4_SELECTOR . . . . . . . . . . . . . . . . . . . . . . 15 7.2. IPV6_SELECTOR . . . . . . . . . . . . . . . . . . . . . . 16 7.3. NAT_TUPLE . . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. INFO . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.5. NAT_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.6. ICMP_MESSAGE . . . . . . . . . . . . . . . . . . . . . . . 19 7.7. PINHOLE_ID . . . . . . . . . . . . . . . . . . . . . . . . 20 7.8. APPLICATION_ID . . . . . . . . . . . . . . . . . . . . . . 21 8. Traffic Flows . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Responder Discovery . . . . . . . . . . . . . . . . . . . . . 24 10. Authorizations . . . . . . . . . . . . . . . . . . . . . . . . 25 11. NAT discussion . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Stand-alone NAT . . . . . . . . . . . . . . . . . . . . . 27 11.2. The NAT is co-resident with the firewall . . . . . . . . . 27 11.3. There is a NAT between the controller and the firewall . . 28 12. NAT call flow examples . . . . . . . . . . . . . . . . . . . . 29 12.1. Calling endpoint is NATted, controls firewall . . . . . . 29 12.2. Calling endpoint is NATted, CCS controls firewall . . . . 30 12.3. Called endpoint NATted . . . . . . . . . . . . . . . . . . 31 13. Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 37 Shore & McGrew Expires March 11, 2007 [Page 2] Internet-Draft AFWC September 2006 1. Introduction This specification defines a protocol for establishing and managing firewall pinholes, and a formal model for evaluating pinhole requests against a pre-established set of authorizations. The design relies on a lower layer in the system to provide cryptographic protections, and to provide the authorizations of the other endpoint. In this document we refer to a "firewall control application." The application actually supports requests to both firewalls and NATs, and while we do not consider NAT to be a type of firewall or to be a security device in general, we recognize that there are substantial semantic, topological, and protocol similarities between asking for a firewall pinhole and asking for a NAT table mapping. For the sake of convenience we will refer to a firewall control application throughout this document, acknowledging that in reality the application includes NAT, a non-firewall function. Shore & McGrew Expires March 11, 2007 [Page 3] Internet-Draft AFWC September 2006 2. Network scenarios Participants in an AFWC dialogue include an initiator, a responder, and an authenticationserver. In the firewall control application, the "initiator" is the entity requesting a firewall pinhole or service, or NAT table mapping. This might be, for example, an IP telephony call control server, or a network gaming endpoint. The "responder" is the firewall or NAT, and the authentication server is the server providing authentication and authorization services to the initiator and responder. In this document we will use "initiator" and "responder" to describe protocol participants. Firewall control is typically seen as between elements in the same network, allowing implicit authorization based on topological considerations such as sharing of address space. For example, ______________ _____________ / \ / \ / Local \ / Public \ | network ------ internet | | _| FW | | | __--- ------ | \ CCS---- / \ / \______________/ \_____________/ In this figure, a VoIP call control server ("CCS") establishes a request connection to a firewall ("FW"). However, it may be the case in some instances or for some applications that an external entity, outside of the local network or address space, may wish to request pinholes or other resources from the firewall. ______________ _____________ / \ / \ / Local \ / Public \ | network ------ internet | | | FW |-_ | | ------ -__ | \ / \ -- CCS / \______________/ \_____________/ Shore & McGrew Expires March 11, 2007 [Page 4] Internet-Draft AFWC September 2006 In this scenario the trust relationships will need to be made explicit, and there may be substantial changes to the security considerations. Shore & McGrew Expires March 11, 2007 [Page 5] Internet-Draft AFWC September 2006 3. Transport AFWC relies on a cryptographic layer for transport and to provide authorizations of the other endpoint. The following cryptographic services MUST be provided by the crypto layer: o entity authentication of the peer o confidentiality of all messages sent to and from the peer o message authentication on all messages sent to and from the peer o protection from replayed messages o protection from reflected messages. In addition, the lower layer MUST establish the authorizations of the peer in a secure and reliable manner and pass these authorizations to this protocol. The messages are framed using the following format. The REQUEST (Figure 3) and RESPONSE (Figure 4) elements convey arbitrary data in their Body fields. This data is meant to convey a request or a response. The Access Type Identifier (ATI) field (Section 5) indicates the type of access that is being requested. The Body field is interpreted according to the value of the ATI field. The Request Identifier field is used to match replies to requests. That field can be set to any value by the sender of a REQUEST; these values SHOULD be distinct. The receiver of a REQUEST element MUST set that field of the corresponding RESPONSE element to the same value. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| Typecode = REQUEST | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access Type Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Shore & McGrew Expires March 11, 2007 [Page 6] Internet-Draft AFWC September 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| Typecode = RESPONSE | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access Type Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Shore & McGrew Expires March 11, 2007 [Page 7] Internet-Draft AFWC September 2006 4. Pinholes 4.1. Firewall pinholes In this specification, a pinhole is a traffic flow that the firewall permits, which can be very narrowly scoped. For example, a pinhole can be created that allows VoIP traffic to flow between a phone behind the firewall and a phone outside the firewall, but which does not allow traffic from any other hosts outside the firewall to reach the phone behind the firewall. The definition of a traffic flow used in this specification appears below. Each pinhole is associated with a PINHOLE_ID value, which can be used to uniquely identify the pinhole, and a timer value that indicates when the pinhole is to expire. A pinhole corresponds to a "permit" statement, in that it only allows traffic through the firewall, and cannot cause traffic to be blocked. There is no equivalent "deny" statement in this specification. This design decision makes the application simpler and should make implementations easier to manage. (n.b. this should not in any way be construed as suggesting that an application cannot request the closure of a pinhole it created -- see below) An initiator MAY request a pinhole for which the traffic flow is already allowed through the responder (firewall), either in part or in whole. In this case, if the responder rejects the request, it MUST NOT be construed to indicate that the flow has been blocked. 4.2. NAT Table mappings A NAT table mapping is the data structure in a NAT providing the mapping between an external {address, port, protocol} tuple and an internal, private {address, port, protocol} tuple. In some types of NAT there may be additional data associated with the mapping. For example, in a symmetric NAT each mapping is also associated with one external peer. Those additional data are opaque to the endpoint and are internal to the NAT. A NAT table mapping is represented by a PINHOLE_ID value, as well. Shore & McGrew Expires March 11, 2007 [Page 8] Internet-Draft AFWC September 2006 5. Access Type The IP Firewall Control application is identified by an Access Type Code of ACCESS_TYPE_FW_CTL. The cryptographic and authorization layers use this code in order to deliver the IP Firewall Control messages to the appropriate application on each participating device. The Access Type Code identifies an authorization application in the same way that a well-known TCP port identifies a service on a host. Shore & McGrew Expires March 11, 2007 [Page 9] Internet-Draft AFWC September 2006 6. Message Exchanges This section defines the IP Firewall application protocol. We use the notation that T* denotes zero or more instances of the term T, T+ denotes one or more instances of the term T, and T? denotes zero or one instances of the term T. In this section, I is the initiator, a device that is making an access control request to the firewall, and R is the responder, which is the firewall itself. 'I' refers to the initiator (the entity requesting pinholes) and 'R' refers to the responder, which in this case is the firewall. The crypto layer and transport layer operate below the application layer, and provide the essential security services and reliable data transport. The application layer contains the "access control dialog". It contains four messages: Start, Offer, Request, and Response. These messages are described below along with the data formats and the semantics used in the IP Firewall Control application. 6.1. Open Pinhole Exchange An initiator begins an Open Pinhole exchange in order to cause a responder to allow a particular traffic flow. The flow is described by one or more IPV4_SELECTOR or IPV6_SELECTOR TLVs, and is associated with a particular PINHOLE_ID. +----------+--------+-----------------------------------------------+ | Message | Flow | Format | +----------+--------+-----------------------------------------------+ | Start | I -> R | | | | | | | Offer | R -> I | (PINHOLE_ID (IPV4_SELECTOR | IPV6_SELECTOR)* | | | | ) | INFO | | | | | | Request | I -> R | PINHOLE_ID (IPV4_SELECTOR | IPV6_SELECTOR)? | | | | | NAT_TUPLE? | INFO | | | | | | Response | R -> I | PINHOLE_ID INFO? | NAT_INFO? | +----------+--------+-----------------------------------------------+ 6.1.1. Start message The Start message is sent by the initiator to the responder to initiate the authorization exchange. The message body is empty. 6.1.2. Offer Message A responder constructs the Offer message as follows. First, it MUST Shore & McGrew Expires March 11, 2007 [Page 10] Internet-Draft AFWC September 2006 check the authorizations of the initiator to make sure that it is authorized to act as a controller (see the section on Authorizations). If it is not, then the Offer message MUST contain an INFO element with Status Code ERROR and Info Code ACCESS_NOT_ALLOWED, and the session must be terminated. Otherwise, the responder encodes into the Offer a PINHOLE_ID that is not currently in use, which will be associated with the pinhole created by the session, if it completes successfully. The responder MAY send one or more IPV4_SELECTOR or IPV6_SELECTOR TLV element(s) describing the traffic that it is willing to allow. The use of these elements provides basic capability discovery and topology discovery . The responder indicates to the authorization system the maximum time, expressed as a number of seconds, that it is willing to allow a pinhole to remain open. This value is used by the authorization system, and is also conveyed to the initiator. A responder that also does NAT, or a stand-alone NAT, MUST include an INFO element that has a Status Code of CAPABILITIES with the NAT flag set. The responder MAY include INFO elements that indicate other conditions, though the controller MAY ignore them. An initiator processes an Offer message as follows. First, it MUST check the authorizations of the responder to make sure that it is authorized to act as a firewall or NAT (see the section on Authorizations). If it is not, then the Offer message MUST contain an INFO element with Status Code ERROR and Info Code ACCESS_NOT_ALLOWED, and the session must be terminated. If any IPV4_SELECTOR or IPV6_SELECTOR element(s) appear in the message, the initiator SHOULD use the information to guide the construction of the Request. 6.1.3. Request message The initiator builds the firewall request by including the PINHOLE_ID element sent in the Offer and zero or more IPV4_SELECTOR or IPV6_SELECTOR elements that describe the traffic that the initiator is requesting to be allowed to traverse the firewall. The initiator indicates to the authorization system the minimum time that it would like for the pinhole to remain open; this value MUST be no greater than the duration indicated with the Offer message. The initiator MAY include INFO elements that indicate other conditions, though the responder MAY ignore them. The initiator builds the NAT request by including the PINHOLE_ID element sent in the Offer and one or more NAT_TUPLE elements that describe the internal address for which the initiator is requesting a Shore & McGrew Expires March 11, 2007 [Page 11] Internet-Draft AFWC September 2006 mapping. The presence of a NAT_TUPLE element implies that a NAT table mapping is being requested, and, by implication, that a firewall pinhole request is being requested. There may be cases in which there are no SELECTOR elements but one or more NAT_TUPLE elements; in that case the request will be treated as being for both a NAT table mapping and a firewall pinhole for each NAT_TUPLE element. Otherwise the construction of the request message is the same as it is for a firewall pinhole request. A responder processes a Request message as follows. First, it MUST check the authorizations of the initiator to make sure that it is authorized to open the pinhole that it has requested (see the section on Authorizations). If it is not, then the Offer message MUST contain an INFO element with Status Code ERROR and Info Code ACCESS_NOT_ALLOWED, and the session must be terminated. Otherwise, the responder constructs a Response message. This message serves as an acknowledgement. NAT processing of the Request message is the same as firewall processing of the Request message. 6.1.4. Response message The Response message contains the PINHOLE_ID that was included in the Offer and the Request. In the firewall case, if nothing goes wrong, then this message contains an INFO element with a Status Code of NOTIFY and an Info Code of OK. If there are any errors or warnings, then the INFO element must be set appropriately. If the duration requested by the initiator is greater than the maximum that the responder is willing to allow, then the responder SHOULD install the pinhole with the maximum duration to which it consents. In this case, the firewall SHOULD send an INFO element with Status Code WARNING and Info Code of DURATION_TOO_LONG. The responder MUST implement the pinhole before sending the Response. The number of seconds before the pinhole expires is provided to the authorization system, which forwards it to the controller. If the request was for a NAT table mapping, the Response message MUST also contain a NAT_INFO TLV. The NAT_INFO TLV is used to communicate the external address back to the controller. An initiator processes a Response as follows. It uses the PINHOLE_ID to associate the reply with the request that it made earlier. If an INFO element with Status Code NOTIFY and Info Code OK appears in the message, and no element with Status Code ERROR appears in the message, then the session has concluded successfully. Otherwise, the controller MUST NOT assume that the pinhole that it has requested has been implemented by the responder. If an INFO element containing Shore & McGrew Expires March 11, 2007 [Page 12] Internet-Draft AFWC September 2006 DURATION_TOO_LONG appears, then the initiator SHOULD be prepared to make another Open Pinhole request before the pinhole times out and is removed by the responder. The duration conveyed by the authorization system indicates the number of seconds that the responder has committed to keep the pinhole open. 6.2. Close Pinhole Exchange An initiator initiates a Close Pinhole exchange to close a responder to a traffic flow that had been previously allowed via an Open Pinhole exchange. A Close Pinhole exchange causes the responder to reverse the firewall policy changes that were made in the previous exchange. The messages for this exchange are outlined in the following table. +----------+--------+-----------------------------------------------+ | Message | Flow | Format | +----------+--------+-----------------------------------------------+ | Start | I -> R | | | | | | | Offer | R -> I | (PINHOLE_ID (IPV4_SELECTOR | IPV6_SELECTOR)* | | | | ) | INFO | | | | | | Request | I -> R | CLOSE_PINHOLE PINHOLE_ID+ | | | | | | Response | R -> I | CLOSE_PINHOLE (PINHOLE_ID | INFO)+ | +----------+--------+-----------------------------------------------+ The Start message is empty, as in the Open Pinhole exchange. The responder constructs the Offer exactly as done for the Open Pinhole exchange (as it must, since at this point in the protocol it has no idea whether or not the initiator will be requesting to open or close a pinhole). The initiator constructs the Request as follows. The PINHOLE_ID sent by the responder is ignored. The message MUST start with a CLOSE_PINHOLE TLV, which indicates that the initiator is requesting that one or more previously created pinholes are to be closed. The PINHOLE_ID element associated with the pinhole(s) that the initiator wishes to close are included in the message. At least one PINHOLE_ID element MUST appear in the message. The responder constructs the Reply as follows. The message MUST start with a CLOSE_PINHOLE TLV, which acknowledges that the exchange will close previously opened pinholes. For each PINHOLE_ID that appears in the Request, the responder includes a PINHOLE_ID in the Response, followed by a INFO TLV element. The INFO element contains Shore & McGrew Expires March 11, 2007 [Page 13] Internet-Draft AFWC September 2006 a Status Code of NOTIFY and an Info Code of OK if the pinhole was closed successfully. The Close Pinhole Exchange is the same for NATs as it is for firewalls. Shore & McGrew Expires March 11, 2007 [Page 14] Internet-Draft AFWC September 2006 7. Data formats The IP Firewall application defines the following TLV types: 7.1. IPV4_SELECTOR IPV4_SELECTOR encodes a traffic selector, which defines a particular IP Version Four packet flow. The firewall uses these values as the basis for packet matches. The Value field of an IPV4_SELECTOR TLV element consists of the ipv4_selector_t structure shown below, in network byte order: typedef struct { uint32_t src_addr; uint32_t src_mask; uint32_t dst_addr; uint32_t dst_mask; uint16_t src_port_lo; uint16_t src_port_hi; uint16_t dst_port_lo; uint16_t dst_port_hi; uint16_t protocol; uint32_t spi; uint16_t reserved; } ipv4_selector_t; with the fields as follows: src_addr: source address in the IP header src_mask: a value to mask with the src_addr field dst_addr: destination address in the IP header dst_mask: a value to mask with the dst_addr field src_port_lo: ports may be specified as a range of values; this is the low value for the source port in the IP header src_port_hi: high value for the range of source ports in the IP header dst_port_lo: low value for the range of destination ports in the IP header Shore & McGrew Expires March 11, 2007 [Page 15] Internet-Draft AFWC September 2006 dst_port_hi: high value for the range of destination ports in the IP header protocol: the protocol number carried in the IP header spi: IPSec SPI. The value 0x00 is used in the protocol field to denote a match to any protocol. 7.2. IPV6_SELECTOR IPV6_SELECTOR encodes a traffic selector, which defines a particular IP Version Six packet flow. The Value field of an IPV6_SELECTOR TLV element consists of the ipv6_selector_t structure shown below, in network byte order: typedef struct { uint128_t src_addr; uint128_t src_mask; uint128_t dst_addr; uint128_t dst_mask; uint32_t flow_label; uint16_t src_port_lo; uint16_t src_port_hi; uint16_t dst_port_lo; uint16_t dst_port_hi; uint16_t protocol; uint16_t reserved; } ipv6_selector_t; with the fields as described above. 7.3. NAT_TUPLE The NAT_TUPLE TLV contains the description of an {address, port, protocol} tuple for which a NAT table mapping is being requested. In other words, the NAT_TUPLE describes an internal address. typedef struct { uint32_t addr; uint16_t port; uint16_t protocol; uint32_t hint_addr; uint16_t hint_port; uint16_t hint_protocol; Shore & McGrew Expires March 11, 2007 [Page 16] Internet-Draft AFWC September 2006 } nat_tuple_t; The addr field represents an IPv4 address. Because this is for NAT, we assume that we will not need to support NAT functions for IPv6, although this may be revisited if necessary. When the initiator is making the request on behalf of another party (for example, a call control server requesting a media pinhole for a VoIP endpoint) the hint_addr, hint_port, and hint_protocol fields SHOULD be used to assist a NAT device in resolving ambiguous requests. An example of ambiguity would be those cases when the NATted address spaces attached to two different interfaces on the same NAT use the same or overlapping addresses. An example of its use would be for, say, a VoIP call control server to use the hint fields to send the {address, port, protocol} tuple of the endpoint from which it received signaling to the NAT. The NAT would search its mapping tables on all interfaces for a match. If a match is found the interface with which the matching mapping is associated would be the interface to which the request is applied. If the hint fields are not used they MUST be null. 7.4. INFO typedef struct { uint32_t status_code; uint32_t info_code; } info_t; The Status Code describes the status state machine of the sender of the INFO element. If any condition occurred that will prevent the successful completion of the exchange, then this field will have the value ERROR. This value indicates to the recipient that it MUST NOT expect the sender to participate in the exchange any further. The Status Codes are: Shore & McGrew Expires March 11, 2007 [Page 17] Internet-Draft AFWC September 2006 +--------------+--------------------------------------------------+ | Message | Meaning | +--------------+--------------------------------------------------+ | OKAY | No error, no message | | | | | ERROR | An error was encountered | | | | | CAPABILITIES | This element contains a capabilities description | +--------------+--------------------------------------------------+ The Info Code provides detailed information, but does not convey any information about the base authorization exchange. The Info Code values that can be used by the IP Firewall Control application are as follows: +------------------------+------------------------------------------+ | Value | Meaning | +------------------------+------------------------------------------+ | OK | No problems occurred | | | | | ACCESS_NOT_ALLOWED | Access is denied due to lack of | | | authorization | | | | | DURATION_TOO_LONG | Duration requested is too long | | | | | BAD_PARAMETER | A bad parameter appeared in a request | | | | | TRY_AGAIN | Request cannot be completed, but try | | | again | | | | | RESOURCE_NOT_AVAILABLE | A resource needed for the request is not | | | available | | | | | NAT | This device provides NAT functions | +------------------------+------------------------------------------+ 7.5. NAT_INFO The NAT_INFO TLV carries the response to the NAT request (implicit in the inclusion of a NAT_TUPLE TLV in the Request message). It includes both the internal and external addresses. Shore & McGrew Expires March 11, 2007 [Page 18] Internet-Draft AFWC September 2006 typedef struct { uint32_t i_addr; uint32_t e_addr; uint32_t i_port; uint32_t e_port; uint16_t protocol; } nat_info_t; where the fields are as follows: i_addr: Internal IPv4 address e_addr: External IPv4 address i_port: Internal port e_port: External port protocol Protocol (TCP, UDP, SCTP, etc.) 7.6. ICMP_MESSAGE typedef struct { u_char icmp_type; u_char icmp_code; } icmp_t; ICMP_MESSAGE carries a description of a filter rule for ICMP messages, based on ICMP message types and codes. The values are as follows: Shore & McGrew Expires March 11, 2007 [Page 19] Internet-Draft AFWC September 2006 ICMP_ECHOREPLY 0 ICMP_UNREACH 3 ICMP_UNREACH_NET 0 ICMP_UNREACH_HOST 1 ICMP_UNREACH_PROTOCOL 2 ICMP_UNREACH_PORT 3 ICMP_UNREACH_NEEDFRAG 4 ICMP_UNREACH_SRCFAIL 5 ICMP_UNREACH_NET_UNKNOWN 6 ICMP_UNREACH_HOST_UNKNOWN 7 ICMP_UNREACH_ISOLATED 8 ICMP_UNREACH_NET_PROHIB 9 ICMP_UNREACH_HOST_PROHIB 10 ICMP_UNREACH_TOSNET 11 ICMP_UNREACH_TOSHOST 12 ICMP_UNREACH_FILTER_PROHIB 13 ICMP_UNREACH_HOST_PRECEDENCE 14 ICMP_UNREACH_PRECEDENCE_CUTOFF 15 ICMP_SOURCEQUENCH 4 ICMP_REDIRECT 5 ICMP_REDIRECT_NET 0 ICMP_REDIRECT_HOST 1 ICMP_REDIRECT_TOSNET 2 ICMP_REDIRECT_TOSHOST 3 ICMP_ECHO 8 ICMP_ROUTERADVERT 9 ICMP_ROUTERSOLICIT 10 ICMP_TIMXCEED 11 ICMP_TIMXCEED_INTRANS 0 ICMP_TIMXCEED_REASS 1 ICMP_PARAMPROB 12 ICMP_PARAMPROB_ERRATPTR 0 ICMP_PARAMPROB_OPTABSENT 1 ICMP_PARAMPROB_LENGTH 2 ICMP_TSTAMP 13 ICMP_TSTAMPREPLY 14 ICMP_IREQ 15 ICMP_IREQREPLY 16 ICMP_MASKREQ 17 ICMP_MASKREPLY 18 7.7. PINHOLE_ID typedef struct { uint32_t id; uint32_t context; Shore & McGrew Expires March 11, 2007 [Page 20] Internet-Draft AFWC September 2006 } pinhole_id_t; The PINHOLE_ID is an identifier generated by the responder and associated with a particular pinhole. The id field of a PINHOLE_ID TLV is 32 bits long, and MAY be treated as an unsigned integer in network byte order (e.g. for display to the user). The method by which the firewall generates these identifiers is intentionally left unspecified, in order to provide maximum flexibility for implementations. Of course, each PINHOLE_ID value associated with an existing pinhole MUST be unique. Each PINHOLE_ID offered to a controller in an Offer message SHOULD be unique, though it is acceptable for a controller to offer the same value twice as long as it detects this condition and does not attempt to install multiple pinholes with the same PINHOLE_ID values. The context field carries responder-specific information to distinguish context. Examples of contexts include interface identifiers and identifiers for virtualized firewalls or NATs. 7.8. APPLICATION_ID typedef struct { uint16_t id_no; char version[14]; } application_id_t; The APPLICATION_ID is a mechanism for identifying the application for which the resources (firewall pinholes, NAT table mappings) are being requested. It is expected that the information will be used as input to a policy-based decision whether or not to grant the request. The id_no member represents the application itself. It MUST use the well-known port number, allocated by the IANA, for the application. In the case where there is no well- known port, such as a Cisco- proprietary protocol for which no well-known port has been requested, a number outside the IANA registered port range MUST be allocated. There are cases in which a protocol uses a dynamically allocated port number -- for example, non-tunneled H.245 or RTP. In those cases the application_id SHOULD be that of the parent protocol (say, H.225 in the case of H.245 or SIP or RTSP in the case of RTP). The version field carries a null-terminated ASCII representation of the version number. If the version string is 14 octets long no null termination is necessary; if the version string is more than 14 Shore & McGrew Expires March 11, 2007 [Page 21] Internet-Draft AFWC September 2006 octets in length it MUST be truncated to 14 octets. For example, version "6" would appear: 1 2 3 4 +-------------+-------------+-------------+-------------+ 0 | 0x36 | 0x00 | | | +-------------+-------------+-------------+-------------+ 1 | | | | | +-------------+-------------+-------------+-------------+ 2 | | | | | +-------------+-------------+-------------+-------------+ | | | | | +-------------+-------------+-------------+-------------+ while version "3rev1 beta" would be represented as: 1 2 3 4 +-------------+-------------+-------------+-------------+ 0 | 0x33 | 0x72 | 0x65 | 0x76 | +-------------+-------------+-------------+-------------+ 1 | 0x31 | 0x20 | 0x62 | 0x65 | +-------------+-------------+-------------+-------------+ 2 | 0x74 | 0x61 | 0x00 | | +-------------+-------------+-------------+-------------+ | | | | | +-------------+-------------+-------------+-------------+ Shore & McGrew Expires March 11, 2007 [Page 22] Internet-Draft AFWC September 2006 8. Traffic Flows A flow is defined as a set of IP packets passing through a particular point in the network that match one or more IPV4_SELECTOR or IPV6_SELECTOR elements. A selector A matches a packet P when the following seven conditions hold: 1. (A.src_addr AND A.src_mask) equals (P.src_addr AND A.src_mask) 2. (A.dst_addr AND A.dst_mask) equals (P.dst_addr AND A.dst_mask) 3. A.src_port_lo <= P.src_port 4. A.src_port_hi >= P.src_port 5. A.dst_port_lo <= P.dst_port 6. A.dst_port_hi >= P.dst_port 7. A.protocol equals P.protocol, or A.protocol equals zero. When the src_addr or dst_addr of a selector is zero, the selector will match any source address or destination address, respectively. Similarly, a selector with a protocol value of zero will match any protocol. In the future, additional selector TLVs may be defined in order to express additional information (such as TCP or IP options or MPLS labels) or to express a particular sort of flow more compactly (such as the UDP port pairs often used in RTP). However, any additional selector TLVs will describe what the traffic flow of interest is, and will not describe what should be done with it. If, for example, a controller needs to express that a particular flow should have QoS applied to it, or should be rate-limited, or should be monitored or audited, then the specification of the responder behavior with respect to the traffic flow MUST be expressed using TLV elements that are separate from the selector elements. Shore & McGrew Expires March 11, 2007 [Page 23] Internet-Draft AFWC September 2006 9. Responder Discovery In some cases, the initiator may need to open a pinhole, but not know the responder to which the Open Pinhole exchange should be addressed. The authorization interception feature can be used to find the appropriate firewall, in some cases. A network device that implements the authorization system has the capability of intercepting packets that it is forwarding, and acting on those packets if appropriate, and forwarding them otherwise. A firewall implementing the Authorized IP Firewall Control application MAY intercept Start messages for that application. An initiator MAY send an Authorized IP Firewall Control message addressed to an end host behind a responder onto which a pinhole should be installed. Note that in order to discovery multiple nested firewalls, a firewall implementing Start message interception SHOULD forward the Start message on towards its destination. This firewall discovery method will work only when the responder is on both the path from the initiator to the end host and the path(s) from the end host to the other devices to which it intends to communicate over the pinhole. When a network is multi-homed, this may not be the case. Shore & McGrew Expires March 11, 2007 [Page 24] Internet-Draft AFWC September 2006 10. Authorizations We define the following TLV formats, for native authorization: The FW_CTL TLV format has a zero-length Value field. It grants permission to its holder to control responders to allow the flow of traffic described by the TLV elements that follow it. If there are no flow-description elements that follow it, then a FW_CTL element does not actually convey any authorizations. For example, the statement FW_CTL IPV4_SELECTOR1 IPV4_SELECTOR2 grants permission to control any responder to permit the flow of traffic described by the two selector elements that follow it. The FW TLV format has a zero-length Value field. It grants permission to its holder to act as a responder for the traffic described by the TLV elements that follow it. If there are no flow- description elements that follow a FW element, then the element conveys no authorizations. For example, the statement FW IPV4_SELECTOR1 IPV4_SELECTOR2 IPV4_SELECTOR3 grants permission to act as a responder and control the flow of traffic described by the three selector elements that follow it. A single authorization element MAY contain both a FW_CTL element and a FW element. Formally, the authorizations have the format ((FW IPV4_SELECTOR+)|(FW_CTL IPV4_SELECTOR+))+ using the notation described above. We say that selector A contains selector B, or B is contained by A, whenever every packet that matches selector B also matches selector A. This situation occurs if and only if all of the following conditions hold: 1. (A.src_addr AND A.src_mask) equals (B.src_addr AND A.src_mask) 2. (A.dst_addr AND A.dst_mask) equals (B.dst_addr AND A.dst_mask) 3. A.src_port_lo <= B.src_port_lo 4. A.src_port_hi >= B.src_port_hi Shore & McGrew Expires March 11, 2007 [Page 25] Internet-Draft AFWC September 2006 5. A.dst_port_lo <= B.dst_port_lo 6. A.dst_port_hi >= B.dst_port_hi 7. A.protocol equals B.protocol, or A.protocol equals zero. Note that if A contains B, it is not necessarily true that B contains A. However, if A contains B and B contains C, then it follows that A contains C. When checking authorizations against requests, a responder MUST o verify that the selector describing the authorizations granted by the server to the initiator (I_AUTHS) are contained in the server's authorizations. o verify that the selector describing the initiator's request is contained in the selector describing the authorizations granted by the server to the initiator. A future version of this specification may contain other authorization elements. Shore & McGrew Expires March 11, 2007 [Page 26] Internet-Draft AFWC September 2006 11. NAT discussion It may be the case that the firewall being controlled is co-resident with a NAT or that there is a NAT between the controller and the firewall. It may also be the case that we are controlling a stand- alone NAT. This raises some issues, some of which are addressed in this document and some of which are for future study. 11.1. Stand-alone NAT This is straightforward -- we send requests to the NAT and the NAT returns the external address, allowing us to use the external address in protocols that make use of embedded addresses, such as VoIP protocols or streaming media protocols. The behavior of the Authorized IP firewall control protocol is the same whether it is being used to control NATs or firewalls, with the difference lying in the data elements. 11.2. The NAT is co-resident with the firewall In this scenario the firewall should be treated as a stand-alone NAT. That is to say, the data elements will include the NAT_TUPLE in the Request and the NAT_INFO in the Response. The reason for this is that it is assumed that an application would not want an external address if it did not also want a firewall pinhole, and it would want both resources to have the same lifetime. When the Request arrives at the NAT/firewall device, the device MUST process the NAT request first, and the results of the NAT processing (that is to say, the NAT table mapping) passed to the firewall function as part of the pinhole descriptor. If the NAT table mapping is not acquired first and used in the filter description, the filter rule that will be installed not be correct for processing inbound (external->internal) traffic. The firewall pinhole for outbound traffic will contain: Source address: untranslated internal address Source port: untranslated internal port Destination address: untranslated peer address Destination port: untranslated peer port The firewall pinhole for inbound traffic will contain: Shore & McGrew Expires March 11, 2007 [Page 27] Internet-Draft AFWC September 2006 Source address: untranslated peer address Source port: untranslated peer port: Destination address: translated (external) address Destination port: translated (external) port 11.3. There is a NAT between the controller and the firewall The issue here is that NAT is transparent to the endpoint. In the typical case an endpoint does not know whether or not there is a NAT along the path between it and its peer. Even if communication fails the endpoint cannot know whether the failure was caused by a NAT interaction or some other network failure. When a NAT is present an endpoint will not know the external address, which is the correct one, to send in a pinhole request. A pinhole descriptor will contain the endpoint's local address and port (the address on the network interface card and the port number assigned by the local TCP or UDP stack). In the case where a NAT is present between an endpoint and the firewall on which it's requesting a pinhole, the address and port local to the endpoint are not the address and port visible outside the NAT, and the pinhole descriptor will not reflect that. The pinhole will be for the "wrong" internal address. Shore & McGrew Expires March 11, 2007 [Page 28] Internet-Draft AFWC September 2006 12. NAT call flow examples Below we show some sample SIP call flows, using the Authorized IP FW Control application to acquire NAT table mappings (and open pinholes if appropriate) to provide traversal capabilities. In all cases the SIP messages are shown in black and the AFWC messages are shown in red. These call flows assume the use of a 4-message exchange, which may be reduced to two messages in future versions of this document. In these examples, the endpoints or their call control servers always function as initiators and the NATs always function as responders. Because SIP (and, for that matter, H.323, RTSP, and other session- oriented protocols) embed addresses in signaling messages it is necessary to acquire NAT table mappings before sending an INVITE (calling party) or a 200 OK (called party). In firewall-only applications the request may be made before or after the signaling message is sent, however that entails risking that the application signaling progresses even if firewall resources are not available. In these examples and in actual use, the endpoint (or its agent, such as a call control server) will generally request NAT table entries only for the address/port tuples on which it will be listening for incoming media. The case in which requests must be made for mappings for outbound media is that in which the NAT does not automatically allocate mappings for new outbound data streams [ETH] i.e. the NAT is entirely controlled and only creates mappings on explicit request. In the exceptional case that the NAT is symmetric, both internal and external addresses will need to be installed to describe a mapping. 12.1. Calling endpoint is NATted, controls firewall In this example the calling party is NATted but is routing signaling through a call control server. It is sending AFWC messages to the firewall itself. For the sake of simplicity the call flow shows the signaling being sent directly to the called party, however in actual use it is likely that the signaling would be sent to the called party's call control server. Shore & McGrew Expires March 11, 2007 [Page 29] Internet-Draft AFWC September 2006 Calling Caller's Caller's Called endpoint NAT CCS Party | start | | | |------------->| | | | | | | | offer | | | |<-------------| | | | | | | | request | | | |------------->| | | | | | | | response | | | |<-------------| | | | | | | | INVITE | | | |=============> INVITE | | | |==============>| INVITE | | | |===========>| | | | | | | | | | | | 200 OKAY | | | |<===========| | 200 OKAY | | |<=============================| | | | | | | | | | 12.2. Calling endpoint is NATted, CCS controls firewall In this example the calling endpoint is NATted, as well, however the call control server is sending AFWC requests to the firewall/NAT. Note that in this example the call control server is topologically "outside" the firewall, which has implications for assumptions about trust relationships and suggests that the notion of a "trusted interface" cannot be relied upon in this case. Shore & McGrew Expires March 11, 2007 [Page 30] Internet-Draft AFWC September 2006 Calling Caller's Caller's Called endpoint NAT CCS Party | INVITE | | |=============================>| | | | | | | | start | | | |<--------------| | | | | | | | offer | | | |-------------->| | | | | | | | request | | | |<--------------| | | | | | | | response | | | |-------------->| | | | | | | | | INVITE | | | |===========>| | | | | | | | 200 OKAY | | | |<===========| | 200 OKAY | | |<=============================| | | | | | | | | | 12.3. Called endpoint NATted In this case the called party is NATted but its call control server is accessible. The INVITE is sent to the called party's call control server, which forwards it to the called party. Note that the call control server cannot use AFWC to acquire a NAT table mapping until it has received the 200 response from the called endpoint; this is because it needs to send the address/port tuple on which the endpoint expects to receive media as part of the AFWC request. Shore & McGrew Expires March 11, 2007 [Page 31] Internet-Draft AFWC September 2006 Calling Called party's Called Party's Called endpoint CCS NAT Party | INVITE | | | |=============> | | | | INVITE | | |===========================>| | | | | | | 200 OKAY | | |<===========================| | | | | | | start | | | |-------------->| | | | | | | | offer | | | |<--------------| | | | | | | | request | | | |-------------->| | | | | | | | response | | | |<--------------| | | | | | | | | | | 200 OKAY | | | |<=============| | | | | | | | | | | Shore & McGrew Expires March 11, 2007 [Page 32] Internet-Draft AFWC September 2006 13. Failover This application does not define its own failover system, and instead recommends that firewalls use the failover mechanisms that they have in place. A firewall may not be able to retain pinholes across reboots. However, if the firewall implements a checkpointing or standby feature, the pinholes SHOULD be included in the state that is checkpointed or duplicated on the standby system. The AFWC protocol allows for a hot-standby system by allowing one device to respond on behalf of another (assuming that the standby device is properly authenticated and authorized). This feature should allow existing standby systems to implement the AFWC without any additional changes. It may be desirable to introduce a secure mechanism by which a controller can discover if a firewall has reloaded. One way to do this would be to use a 128-bit EPOCH value, which the firewall selects randomly at boot time. By including an EPOCH element in the Offer, the firewall could securely convey the current epoch to the controller. By retaining and comparing epoch values, a controller can detect if a firewall has reloaded. Shore & McGrew Expires March 11, 2007 [Page 33] Internet-Draft AFWC September 2006 14. Security Considerations Shore & McGrew Expires March 11, 2007 [Page 34] Internet-Draft AFWC September 2006 Appendix A. Acknowledgements The authors would like to thank Raghu Gyambavantha, Eric Wang, and Jan Vilhuber for their comments and suggestions. Shore & McGrew Expires March 11, 2007 [Page 35] Internet-Draft AFWC September 2006 Authors' Addresses Melinda Shore Cisco Systems 809 Hayts Road Ithaca, New York 14850 USA Email: mshore@cisco.com David A. McGrew Cisco Systems 510 McCarthy Blvd Milpitas, California 95035 USA Email: mcgrew@cisco.com Shore & McGrew Expires March 11, 2007 [Page 36] Internet-Draft AFWC September 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shore & McGrew Expires March 11, 2007 [Page 37]