Network Working Group H. Soliman Internet-Draft Elevate Technologies Intended status: Standards Track G. Daley Expires: August 28, 2008 S. Krishnan Ericsson February 25, 2008 Firewall Control for Public Access Networks (FCON) draft-soliman-firewall-control-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Soliman, et al. Expires August 28, 2008 [Page 1]
Internet-Draft Firewall Control Protocol February 2008 Abstract This document proposes a new mechanism that allows end nodes to signal its preferences for traffic filters to a firewall function in the network or to another node that controls the firewall function in the network. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 7 4. Firewall Scenarios . . . . . . . . . . . . . . . . . . . . . . 9 5. PDP Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. DHCP extensions . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. PDP Sub-Option Format . . . . . . . . . . . . . . . . 13 6. Authorization Mechanism . . . . . . . . . . . . . . . . . . . 15 6.1. Proof of ownership . . . . . . . . . . . . . . . . . . . . 15 6.2. Firewall request policy . . . . . . . . . . . . . . . . . 16 7. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 17 7.1. The Request Message Format . . . . . . . . . . . . . . . . 17 7.2. The Response Message Format . . . . . . . . . . . . . . . 18 7.3. The Init Message . . . . . . . . . . . . . . . . . . . . . 19 7.4. The Init Acknowledgement Message . . . . . . . . . . . . . 20 7.5. Protocol Options . . . . . . . . . . . . . . . . . . . . . 21 7.5.1. The Acknowledgement Option . . . . . . . . . . . . . . 21 7.5.2. The Filter Identifier Option . . . . . . . . . . . . . 22 7.5.3. The Nonce Option . . . . . . . . . . . . . . . . . . . 23 7.5.4. The Timestamp Option . . . . . . . . . . . . . . . . . 24 7.5.5. The IP Address Option . . . . . . . . . . . . . . . . 25 7.5.6. The Cookie Option . . . . . . . . . . . . . . . . . . 27 7.5.7. The Public Key Option . . . . . . . . . . . . . . . . 28 7.5.8. The Lifetime Option . . . . . . . . . . . . . . . . . 29 7.5.9. The Certificate Option . . . . . . . . . . . . . . . . 30 7.5.10. The Digital Signature Option . . . . . . . . . . . . . 31 8. Establishing a Secure Connection . . . . . . . . . . . . . . . 34 9. Creating New entries . . . . . . . . . . . . . . . . . . . . . 35 10. Updating Entries . . . . . . . . . . . . . . . . . . . . . . . 37 11. Requesting an IPv4 Address . . . . . . . . . . . . . . . . . . 38 12. Timeouts and Retransmissions . . . . . . . . . . . . . . . . . 39 12.1. Session Start Delays . . . . . . . . . . . . . . . . . . . 39 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 14. Security Considerations . . . . . . . . . . . . . . . . . . . 41 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 16. Normative References . . . . . . . . . . . . . . . . . . . . . 43 Appendix A. Dynamic PDP Discovery (Informative) . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Soliman, et al. Expires August 28, 2008 [Page 2]
Internet-Draft Firewall Control Protocol February 2008 Intellectual Property and Copyright Statements . . . . . . . . . . 48 Soliman, et al. Expires August 28, 2008 [Page 3]
Internet-Draft Firewall Control Protocol February 2008 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Soliman, et al. Expires August 28, 2008 [Page 4]
Internet-Draft Firewall Control Protocol February 2008 2. Introduction The need for network protection has led operators to deploy firewalls with typical configurations that limit the traffic coming into or out of a network to the administrators configuration. An administrators configuration is typically static and affects all users within the network. While such security measure is regarded as successful and is widely deployed, it has several drawbacks from a user and network operator's points of view. The assumption in such deployments is that there is a common configuration that satisfies all users. That is, the same type of applications are used by all network users and that all users do not need to be reachable unless they initiate a connection. Alternatively, in some deployment scenarios, e.g. IP Multimedia System (IMS) in 3GPP, the assumption is that externally initiated connection will use a signaling protocol, through local proxies, and therefore a local firewall can be manipulated by such proxies to allow such connections. Another assumption in deploying firewalls is that there is a Trusted side (the administrator's network) and an Untrusted side (The Internet). This is reasonable in a network where you assume no one on the inside of the network would intentionally try to attack the network infrastructure. The assumptions above are clearly workable in a network where there is a defined behaviour for the users. For instance enterprise network users can easily be told what applications and protocols are acceptable for the users according to company policy. However, in a public network, such restrictions cannot be made without introducing serious limitations on users. Furthermore, in a public network, one can no longer assume that users on the inside are trusted. This is especially true in networks with anonymous users as well as users who may not be competent in protecting their own infrastructure. The need for firewalling traffic still exists in public networks. Operators may wish to provide general protection for their infrastructure and users. At the same time, there is a clear need for flexibility in order to allow users a high degree of freedom in choosing the applications and protocols that they want to run. The firewall function may also be located closer to the user than the traditional deployment of firewalls on the core edge of the network. This allows for greater scalability by allowing the firewall function to serve a smaller number of users, which reduces bottlenecks in the core. This is particularly useful for IPv6 networks where there should be no need for Network Address Translators. To allow for a more flexible firewall deployment, both in the location and configuration of the firewall, this document proposes a new mechanism that allows end nodes to signal its preferences for traffic filters to a firewall function in the network or to another Soliman, et al. Expires August 28, 2008 [Page 5]
Internet-Draft Firewall Control Protocol February 2008 node that controls the firewall function in the network. The mechanism introduced in this document allows for a high degree of fexibility and security. A generic mechanism for firewall control has the following advantage: o Removes the reliance on specific application proxies for signalling to allow incoming connections. o Allows easy deployment of new services without requiring specific application gateways. o Allows easy deployment of new protocols that may not be known to the firewall and would otherwise be blocked. o Allows maximum user control, which provides the finest granularity for firewall configuration. One of the approaches for firewall control can be found in [I-D.ietf-nsis-nslp-natfw]. However, this approach assumes a form of pre-established trust. With mobility becoming the norm on the Internet, it is difficult to assume trust without the use of global Public Key Infrastructure (PKI), which is not available today. Other approaches to firewall control include the presence of application proxies that are either colocated or physically separate from the firewall. The mechanism introduced in this document allows end nodes to signal their preferences directly to the firewall, or to another entity that controls the firewall. Hence, this mechanism allows network operators to continue the use of application proxies that control the firewall, while adding this new mechanism as a generic option. Soliman, et al. Expires August 28, 2008 [Page 6]
Internet-Draft Firewall Control Protocol February 2008 3. Protocol operation The FCON protocol allows nodes to send its preferences to a Policy Decision Point (PDP) in order to configure a firewall with those preferences. The PDP may be located anywhere in the network, including the access router sharing the node's link. Furthermore, it may be colocated with the firewall. FCON allows the node to create new entries, add entries, as well as, modify or delete existing entries. FCON uses ICMP for transporting its messages between the node in question and the PDP. FCON can also be used to request the allocation of a unique IPv4 address and one or more port numbers by a Network Address Translator (NAT). | | +--------+ +---------+ | PDP | 2.PDP/PEP Protocol |Firewall/| | |<--------------------->| NAT | +--------+ (out of scope) +---------+ ^ | | | | 1. FCON Protocol | | | | | +--------+ 3. Data Stream | +--------+ | IPv6 |--------------------------->O------------->| Peer | | Node | <-----O--------------| Node | +--------+ | +--------+ | Figure 1: Communication architecture Nodes that implement FCON first need to discover the IP address of the PDP in order to send future messages. The PDP's address is either included in a router advertisement option or a new DHCPv6 option. Alternative discovery mechanisms are described in Appendix A. Following the discovery phase, a node may start sending messages to the PDP requesting that certain protocols or port numbers be opened for its traffic on a firewall or Policy Enforcement Point (PEP). A node may also request a unique IPv4 address and one or more port numbers for NAT traversal. All entries created by a node have a lifetime associated with them and MUST be refreshed in order to avoid losing them. The lifetime is set by the PDP and cached by the node using FCON. Depending on the network configuration, from the end host's point of view, the PDP may be colocated with a firewall or separated. Soliman, et al. Expires August 28, 2008 [Page 7]
Internet-Draft Firewall Control Protocol February 2008 Moreover, both functions could be colocated with an access router or located within the core network. The protocol between the PDP and the firewall is outside the scope of this document. Authentication and authorization of FCON messages takes place by the PDP. The PDP is assumed to be authenticated with the firewalls through one of several methods, including manual configuration of security associations, public key-based authentication, or any other method deemed appropriate by the network administrator. Message authentication and authorization is a critical component of the FCON protocol. Different deployment models may have different requirements for authentication and authorization. In some deployments the use of public keys and trusted certificates can be sufficient to authorize an end node for FCON messages. Examples of such deployments may include enterprise or home networks. Other deployments may require proof that the sender is authorized to perform the action requested. Given the information exchanged in the FCON messages, it is sufficient for a node to prove the ownership of the address included in a message to be authorized to perform the requested action provided that such action does not violate the network administrator's policies. Hence, the PDP first needs to know that a sending node owns the address included in the message, then ensure that the request does not violate any known policies. Following such verification the PDP would configure the firewall/NAT with the necessary information requested by the end node. This specification allows FCON security to be based on self-generated public keys and Cryptographically Generated Addresses (CGAs). This allows nodes to provide the necessary address ownership credentials in those deployments that require it. Alternatively, public keys associated with PKI can be used for deployments that do not require proof of address ownership. Soliman, et al. Expires August 28, 2008 [Page 8]
Internet-Draft Firewall Control Protocol February 2008 4. Firewall Scenarios This section describes limitations in current firewall deployment, and illustrates challenges in attempting to control firewalls dynamically using FCON. Scenarios are described which motivate features described in this document. Manual policy firewalls describe the state of the art, with respect to deployed networks. A management platform acts as a static policy decision point, propagating policy out to one or more policy enforcement points. Such an environment is displayed in Figure 2. Connection state creation occurs when data plane packets compliant with policy are received. Static firewalls such as these may exist where the PDP and PEP are collapsed into the same entity, and long term configuration occurs on the same device where connection state is created. PEP ^ / / / PDP---\ \ \ V Host====================> PEP=====================>Peer Connection State Creation Figure 2: Static Firewall As shown in Figure 2, where connection state is required for inbound packet flows, the PEP's preconfigured policy is used to create inbound connection state. Such connections are available at all times, and depend upon the specificity of the PDP's inbound policy in order to maintain internal network security. These inbound communications remain available regardless of the lifetime of the individual server applications. Soliman, et al. Expires August 28, 2008 [Page 9]
Internet-Draft Firewall Control Protocol February 2008 PEP ^ / / / PDP---\ \ \ V PEP Server <=====================O<=============== Client Connection State Creation Figure 3: Inbound Connection on Static Firewall Problems emerged when people attempted to support peer-to-peer applications with dynamic source and destination addresses. This is illustrated in Figure 4. Transport layer connection state is unable to identify the upper layer inbound connection associated with the peer-to-peer application. Inbound packets are dropped on the secondary session unless the Firewall snoops and understands the specific protocol, and the inbound policy is loosened to permit such inbound sessions. PEP ^ / / / PDP---\ \ \ V P2P Signaling Host =======================>PEP====================> Peer X<======================= Figure 4: Peer-to-Peer Connection on Static Firewall By enabling dynamic signalling, a host can inform the network elements of its intention to send packets with a particular source and destination address, and transport profile. This means that the policy decision and enforcement can occur at the time that the session is established, and adapt specifically to the needs of the network's current transmission profile. Soliman, et al. Expires August 28, 2008 [Page 10]
Internet-Draft Firewall Control Protocol February 2008 In Figure 5, the host informs the PDP which protocols are expected through the network gateways using a Request message to create a flow decriptor entry in the firewall. The PDP indicates whether the session will be allowed, and state created on the PEP. In this case, a Response message is sent, indicating that the PDP believes the communications are allowed. Request /----------------PDP.. //----------------/ . // ACK . / V V Host =====================>PEP======================= > Dest Figure 5: Outbound Session with PDP Signaling In many environments, multiple Firewalls exist on the path to the Internet. This is shown in Figure 6. Signalling is either performed to a single PDP which passes information to both PEPs, or to a separate PDP for each PEP. By using separate PDPs, different trust policy and vendor independence may be readily achieved. This may particularly be applicable where the internal firewall is operated by an enterprise, and the exterior firewall by a service provider. Request /---------------->PDP.. //-----------------/ . // ACK . / V V Host======================>PEP============>PEP============>Dest \ ^ | ^ \ \ ACK | . \ \----------------------O------------\ . \---------------------->O----------->PDP Request | Figure 6: Multiple On-Path Firewalls Soliman, et al. Expires August 28, 2008 [Page 11]
Internet-Draft Firewall Control Protocol February 2008 5. PDP Discovery 5.1. DHCP extensions In order to configure PDPs on hosts using the existing access infrastructure, a DHCP option is provided. The option format includes PDPs with destination coverage information on a per-PDP basis in a suboption format. This would allow for specific PDPs to have jurisdiction over different network ranges (for example, for a Data Centre, and an Internet Firewall). The DHCP option for identifying PDPs is described using the format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_FC_PDP | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | PDP Sub-option 1 | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + PDP Sub-option N + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: FCON PDP Discovery DHCPv6 Option OPTION_FC_PDP Assigned DHCP option code for PDP discovery. TBD. option-len Soliman, et al. Expires August 28, 2008 [Page 12]
Internet-Draft Firewall Control Protocol February 2008 The length of the entire option in bytes, less 4 PDP Sub-option A sub option containing information for each PDP the host should configure. 5.1.1. PDP Sub-Option Format Each PDP has its own IP address and validity information. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PDP-SOPT | Prefixes | suboption-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | PDP IP Address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLen1 | Prefix 1 .... | +-+-+-+-+-+-+-+-+ + | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PrefixLen2 | Prefix2... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PrefixLenN | PrefixN... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Figure 8: FCON PDP Discovery DHCPv6 Option Soliman, et al. Expires August 28, 2008 [Page 13]
Internet-Draft Firewall Control Protocol February 2008 PDP-SOPT A sub option Prefixes The number of prefixes covered by this PDP. suboption-len The length of the PDP sub-option in bytes, including all fields. PDP IP Address The IP Address of the PDP which is used as a destination for FCON requests. PrefixLen i The length of the next prefix, in bits. Prefix i The space consumed by the Prefix is the number of bytes required to store the prefix (PrefixLen i/8), rounded up to the nearest integer. A Prefix of 0::/0 is encoded with a zero length Prefix Field, and indicates the PDP is responsible for all destinations. Soliman, et al. Expires August 28, 2008 [Page 14]
Internet-Draft Firewall Control Protocol February 2008 6. Authorization Mechanism The protocol described in this document uses a two step authorization procedure. The right to control the firewall will be granted if o The node making the request is behind the firewall and owns the IP address o The request made by the node is allowed by local firewall policy. 6.1. Proof of ownership This document relies on Cryptographically Generated Addresses (CGAs) as defined in [RFC3972] in order to prove that the requesting node owns the address from which the firewall control request was sent. This is possible because the CGA address of the node is derived based on a hash of the public key of node with other known pieces of information like the prefix. The procedure for verification of CGA addresses is described in Section 5 of [RFC3972]. If the PDP receive a signed firewall control request message that includes the public key and the CGA of the requester it can verify that the sender of the request indeed owns the address and that the address corresponds to the public key carried in the message. Since creating this signature requires the corresponding private key of the public key contained in the message, it can also conclude that the message has not been tampered with. In addition to this, to prevent replay attacks, the PDP can verify that the sender is in fact reachable and alive, using a to be defined FCON protocol message that uses nonces to verify that the received message was not replayed from an earlier run of the protocol. e.g. The PDP could send a nonce to the requesting node in this message encrypted by the public key of the requesting node. Only the requesting node can decrypt this message and obtain the nonce. Then it needs to increment the nonce and encrypt it and send it back to the PDP. Once the PDP receives this message it can be assured that the requester is alive and reachable. If either of these tests fail, the PDP rejects the firewall configuration request with an error that indicates that the address ownership was not confirmed. Please note that the PDP does not have to verify who owns the public key. It just needs to verify whether the owner of the address is the same as the owner of the public key contained in the signed message. It can do so solely based on the information contained in the message prefix of the address, public key etc., by running the algorithm mentioned earlier. Soliman, et al. Expires August 28, 2008 [Page 15]
Internet-Draft Firewall Control Protocol February 2008 6.2. Firewall request policy Once the PDP has verified that the requesting node owns the concerned address and is reachable, the PDP needs to start processing the request message itself. Since it is possible that the firewall control request may not conform to administrative policy, the PDP verifies that the request falls within the parameters specified by such policy. If it does, the PDP starts acting on the request and sends configuration messages to the necessary firewall(s). If not, the PDP rejects the firewall configuration request with an error that indicates that the request did not comply with local administrative policy. Soliman, et al. Expires August 28, 2008 [Page 16]
Internet-Draft Firewall Control Protocol February 2008 7. Protocol Messages FCON uses ICMPv6 for transporting its messages. The protocol is based on a request respose message exchange. Hence, two ICMP message types are needed. The ICMP Code field is used to distinguish different types of FCON messages. Each message can contain one or more options. This sections lists all protocol messages and options. 7.1. The Request Message Format The Request message is sent from the end node to the PDP. The purpose of the message depends on the options included. For each operation described in this specification a specific set of options must be included. The format of the request message is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Id | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: The Request Message Format Session Id An unsigned 16-bit integer that includes a session identifier. The session identifier is initially picked by the end node when a security association is created with the PDP. The Session Id MUST be unique for a particular end node, which is identified by its public key. Reserved This field MUST be set to zero by the sender and ignored by the receiver. Message Id This field include a message identifier. The message identifier is a simple counter incremented by 1 for every new message. This field is used to match responses with their correcponding requests. Soliman, et al. Expires August 28, 2008 [Page 17]
Internet-Draft Firewall Control Protocol February 2008 7.2. The Response Message Format The Response message is sent from the PDP to the end node in response to a request message sent from the end node. The response message includes the same Session Id and Message Id that were included in the sender's Request message. The Response message may contain several options. The options contained in a given message depend on the type of operation requested in the Request message. The format for the Response message is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Id | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: The Response Message Format Session Id An unsigned 16-bit integer that includes a session identifier. The session identifier is initially picked by the end node when a security association is created with the PDP. The Session Id MUST be unique for a particular end node, which is identified by its public key. Reserved This field MUST be set to zero by the sender and ignored by the receiver. Message Id This field include a message identifier. The message identifier is a simple counter incremented by 1 for every new message. A Response message's identifier is set to the message identifier of the corresponding request message. Soliman, et al. Expires August 28, 2008 [Page 18]
Internet-Draft Firewall Control Protocol February 2008 7.3. The Init Message The Init message is sent from the end node to the PDP in order to establish a secure association before sending further requests. This message MUST NOT include information about flows that need to be installed in the firewall. Instead, the message contains the end node's security credentials and a challenge for the PDP. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Id | Sec Mode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: The Init Message Format Session Id An unsigned 16-bit integer that includes a session identifier. The session identifier is initially picked by the end node when a security association is created with the PDP. The Session Id MUST be unique for a particular end node, which is identified by its public key. Sec Mode This field indicates the type of credentials used to establish the security association. A value of 1 indicates the use of self- generated public keys. A value of 2 indicates the use of trusted certificates, which are either signed by the same administrative authority or a trusted third party. Reserved This field MUST be set to zero by the sender and ignored by the receiver. Message Id This field include a message identifier. The message identifier is a simple counter incremented by 1 for every new message. Soliman, et al. Expires August 28, 2008 [Page 19]
Internet-Draft Firewall Control Protocol February 2008 7.4. The Init Acknowledgement Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Id | Sec Mode | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: The Init Acknowledgement Message Format Session Id An unsigned 16-bit integer that includes the session identifier included in the Init message. Sec Mode This field includes the same value for the Sec Mode field included in the Init message if the Status field indicated a successful operation. Otherwise, the field includes the value supported by the PDP. Status This field indicates the success or failure of the processing of the Init message. Values below 128 indicate success, while values of 128 and above indicate failure. Message Id This field includes the value of the Message Id that was included in the Init message being responded to. The following values are reserved for the Status field: 0 Success 128 Reason unspecified 129 Security mode not supported 130 Invalid format 131 Certificate not accepted Soliman, et al. Expires August 28, 2008 [Page 20]
Internet-Draft Firewall Control Protocol February 2008 7.5. Protocol Options 7.5.1. The Acknowledgement Option The Acknowledgement Option is used to carry information about a requested operation. The format of the Acknowledgement option is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: The Acknowledgement Option Format Type A value assigned to this option. Length The length of this option in 8-octet units. Status This field indicates whether an operation was a success or a failure. Values of 128 and higher indicate failure. Otherwise this field indicates a successful operation. Reserved MUST be set to zero by the sender and ignored by the receiver. The following values are reserved for the Status field: 0 Indicates Success. 128 Failure, reason unspecified. 129 Message poorly formed. 130 Unknown session identifier. 131 Flow descriptor format not supported 132 Action not supported. Soliman, et al. Expires August 28, 2008 [Page 21]
Internet-Draft Firewall Control Protocol February 2008 133 Security Information Required. 134 Liveness Proof Required. 7.5.2. The Filter Identifier Option The filter identifier option is used to encode information that describes a flow and the treatment needed for such flow. A host may request that a flow be allowed, blocked, or removed from the firewall, which defaults to the firewalls original settings. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Format | PRI | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow descriptor...... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: The Flow Identifier Option Format Type A value assigned to this option. TBA Length The length of this option in 8-octet units. Index A Unique value that identifies a particular flow description. This value is assigned to the flow description by the end node. Action This field indicates the type of operation requested by the end node for the flow included in the option. The following values are assigned to this field. A Value of 1 indicates a request to Allow the flow. 2 indicates a request to Block a flow. 3 indicates a request to Update a flow. 4 indicates a request to Delete a flow. Format Soliman, et al. Expires August 28, 2008 [Page 22]
Internet-Draft Firewall Control Protocol February 2008 This field indicates the format used for the flow descriptior. Values TBA PRI This field indicates the priority of a particular flow. A lower value indicates a higher priority. A value of 1 indicates the highest priority. A value of zero is not allowed by this specification. The rpiority field is needed in cases where two flow descriptions overlap while having conflicting Action fileds. The Action field included in the option with higher priority takes precedence. Reserved This field MUST be set to zero by the sender and ignored by the receiver. 7.5.3. The Nonce Option The Nonce Option is illustrated in Figure 15 and is used to ensure freshness in acknowledgements from the PDP to the requesting FCON node. It works by making sure that the PDP copies the Nonce Option from the request into the response. The Nonce is checked along with other freshness and authentication information before As such, a new Nonce MUST be selected for each transmission of a request message. PDPs receiving a valid request message MUST copy the Nonce option into the response, regardless of the status of any individual flow. The Nonce MUST be unpredictable, and SHOULD contain hardware generated randomness, where possible. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: The Nonce Option Format Type Soliman, et al. Expires August 28, 2008 [Page 23]
Internet-Draft Firewall Control Protocol February 2008 A value assigned to this option. Length The length of this option in 8-octet units. Nonce The Nonce is a block of data selected by the requester to be sent to the PDP. the entire length of the Nonce block MUST NOT exceed 384 bits. It MUST contain at least 64 bits of unpredictable random data. It SHOULD contain significantly more randomness. PDPs receiving the Nonce SHOULD cache it to ensure that duplicate request packets are not processed from the same source. 7.5.4. The Timestamp Option The Timestamp option format is used to ensure attackers are unable create state in the future by replaying signed FCON messages. It relies on congruence between clock information within nodes and PDPs, and therefore has some limitations where secured time synchronization is not available The following option format follows the principles and message formats as described in the [RFC3971], except that its protections may be weaker when operating in a multi-hop domain. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: The Timestamp Option Format Type A value assigned to this option. Length Soliman, et al. Expires August 28, 2008 [Page 24]
Internet-Draft Firewall Control Protocol February 2008 The length of this option in 8-octet units. Timestamp A 64-bit unsigned integer field containing a timestamp. The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/64K fractions of a second. Each FCON message MUST contain the Timestamp option, and recipients SHOULD ensure that Timestamps are valid to prove freshnes of the message. Processing of this option follows that for SEND, except that that the corresponding figures for clock drift and fuzz are more lenient. This allows for longer attack windows of attack against FCON infrastructures, but also allows for deviations in packet transfer delays on multi-hop networks and the extended duration of the state created in Firewalls, as opposed to Neighbour Discovery: TIMESTAMP_DELTA 600 seconds (10 minutes) TIMESTAMP_FUZZ 6 seconds TIMESTAMP_DRIFT 1 % (0.01) 7.5.5. The IP Address Option The IP address option is used by a node to request a unique IPv4 address and one or more port numbers. Soliman, et al. Expires August 28, 2008 [Page 25]
Internet-Draft Firewall Control Protocol February 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | PadLen | Protocol1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ProtocolN | Padding... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interior Port 1 | Exterior Port 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interior Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exterior Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interior Port N | Exterior Port N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interior Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exterior Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: The IP Address Option Format Type A value assigned to this option. Length The length of this option in 8-octet units Padlen The length in bytes of the Padding field Protocol i The ith IP protocol number Padding This field SHOULD be set to zero by the sender and ignored by the receiver. Interior Port i Soliman, et al. Expires August 28, 2008 [Page 26]
Internet-Draft Firewall Control Protocol February 2008 The 16 bit Transport layer internal identifier of the of the ith session for which a mapping is requested. Where such identifiers do not make sense for a particular protocol, this field SHOULD be set to zero Exterior Port i The 16 bit Transport layer identifier of the of the ith session for which a mapping is requested. Where such identifiers do not make sense for a particular protocol , this field SHOULD be set to zero Requesters SHOULD set this field to zero, if they wish the PDP to assign a port Exterior Address i The address of the ith external IP address to which a mapping is requested. Requesters SHOULD set this field to zero, if they wish the PDP to assign an address. Interior Address i The address of the ith internal IP address for which a mapping is requested 7.5.6. The Cookie Option The Cookie Option contains a string of information chosen by the PDP to the host to when requesting further security credentials. The cookie can contain any information which the PDP desires, and the cookie must be returned to the PDP along with credential information When the host sends further credential information it MUST add the cookie to the Init or SEND Certification Path Advertisements sent to validate the credentials. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Cookie . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: The Cookie Option Format Soliman, et al. Expires August 28, 2008 [Page 27]
Internet-Draft Firewall Control Protocol February 2008 Type The assigned type of this option (TBD). Length The length of this option in 8-octet units. C The Flag indicating Certificate Path Discovery is ok (Flag Set). This flag being set allows the response to use [RFC3971] Certifcation Path Advertisement Messages to convey the list of certificates for the respondent. If this flag is not set, the sender MUST use Init messages instead. This Cookie is required to appear in all such messages (IANA Note). Length A string of bytes chosen by the PDP to ensure liveness of responses. The entire option, carrying this field needs to be copied into an INIT for transmission to the PDP, along with credential information. 7.5.7. The Public Key Option The Public Key option is used to provide information to the PDP about the identity being used to sign the message. By using the key information in this option, or a cached copy, the PDP can use information in the Digital Signature Option, to verify the message's integrity. This Option MUST be present in the message sent from a particular host to a PDP, and from a PDP to a host with which it has not communicated, unless the same information is provided within the message using a Certificate Option. If a host or PDP communicate with each other during a period where security state is still in existence, then the sender MAY leave this option out. Where a receiving endpoint does not support a Key Type, it may indicate this to the far end in an acknowledgement but otherwise SHOULD NOT create any state in PEPs. Soliman, et al. Expires August 28, 2008 [Page 28]
Internet-Draft Firewall Control Protocol February 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Key Type | Pad Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Information ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: The Public Key Option Format Type A value assigned to this option. TBA Length The length of this option in 8-octet units. Key Type A description of the keying information to be supplied in the following Public Key Information field. The algorithms and formats to be supported are to be determined. A type value of 1 is CGA with the Public Key Information containing information compatible with [RFC3972] formats. Pad Length The length of the pad in bytes Public Key Information A stream of bytes describing a public key accordingto the algorithm specific format specified in they Key Type. Padding This field SHOULD be set to zero by the sender and ignored by the receiver. 7.5.8. The Lifetime Option This lifetime option is included in the Response and Init Acknowledgement messages from the PDP to the end node to indicate the lifetime for the entries in a Request message or to indicate the Soliman, et al. Expires August 28, 2008 [Page 29]
Internet-Draft Firewall Control Protocol February 2008 lifetime of a security association, respectively. The option format is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: The Lifetime Option Format Type A value assigned to this option. Length The length of this option in 8-octet units. Reserved This field MUST be set to zero by the sender and ignored by the receiver. Time This field contains the lifetime in units of seconds. 7.5.9. The Certificate Option The Certificate option contains a digital certificate issued by one of the Certificate Authorities in the sender's trust chain. It provides information about trust delegated to the sender or its authorizing authorities. This option follows the same format as in [RFC3971], and the certificates can be sent in Certification Path Advertisement messages, between hosts and PDPs. The Certificate Option MAY be included in an FCON request or response message instead of including the Public Key option. It is RECOMMENDED that only one of the Public Key Option or Certificate Option is included in any FCON request or response message. Soliman, et al. Expires August 28, 2008 [Page 30]
Internet-Draft Firewall Control Protocol February 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Cert Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Certificate ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21: The Certificate Option Format Type A value assigned to this option. Length The length of this option in 8-octet units. Cert Type The type of certificate presented in the Certificate field. Type 1 is an X.509v3 digital certificate. Certificate A stream of bytes describing a one of the sender's certificates from it's trust chain. The format of a particular certificate is governed by the Cert Type. Padding This field SHOULD be set to zero by the sender and ignored by the receiver. 7.5.10. The Digital Signature Option The Digital Signature Option MUST be included in every FCON message, and authenticates the preceding message contents. It does this by performing a signature over the message contents by the key identifies in the Key Hash field. It is always placed last in any sequence of options, before presentation for transmission. If multiple identities are signing the message, the most specific user signs the message with the first digital signature option, over Soliman, et al. Expires August 28, 2008 [Page 31]
Internet-Draft Firewall Control Protocol February 2008 all options preceding that one. Subsequent signers include all required option information to ensure validation of their message after this signature, and then include their own digital signature at the end, signing over all included options, including the previous digital signature. This allows user level and host level authentication within the same message, and provides distinction between administrative and non-power users on a multi-user server. If a device receives a digital signature and is unable to identify the Public Key to which the signature is tied, it may challenge the sender, or silently discard the received FCON message. Therefore, it is important to include the Public Key Option in a message unless it is known that the peer device is known to have recently received it. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sign Type | Pad Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Key Hash + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Digital Signature ... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 22: The Digital Signature Option Format Type A value assigned to this option. Length The length of this option in 8-octet units. Sign Type Soliman, et al. Expires August 28, 2008 [Page 32]
Internet-Draft Firewall Control Protocol February 2008 The type of digital signature used within the Digital Signature field of this option. Type 1 is allocated as a PKCS 1.5 Digital Signature over the field sequence as described in [RFC3971]. Pad Length The length of the Padding field in octets. Key Hash The left most (most significant) 128 bits of an SHA-1 hash over the public key information included in a Public Key Information field of a Public Key Option. Digital Signature A digital signature of the format specified in the field Sign Type. This signature is over the entire message, including the ICMPv6 Pseudo Header, and all options up to and preceding this option. The length of the Digital Signature field is the length in octets of the message subtracting 12 octets for fixed length fields, and the contents of the Pad Length field. Padding This field SHOULD be set to zero by the sender and ignored by the receiver. Soliman, et al. Expires August 28, 2008 [Page 33]
Internet-Draft Firewall Control Protocol February 2008 8. Establishing a Secure Connection A host wishing to request that state be created on a PEP signals a PDP with either an Init message containing credential information, or a Request message containing the filter information describing the host's intended protocol behaviour. Either of these messages MUST contain the Public Key Option (or a Substituted Certificate Option containing the relevant Public Key) and a Digital Signature Option, along with Timestamp and Nonce information. In addition, the Init message contains a unique session identifier field selected by the requesting node. This session identifier field will be used for subsequent signaling of other messages upon successful establishment of a secure session. If the PDP can determine from the contents of the message that it believes the host is an acceptable requester, it can respond to the request with the appropriate success acknowledgement in the Init Acknowledgement message. If the PDP is not able to authemticate or authorize the credentials for the host, it replies with an Init-Ack or Response containing a non success response code, and a Cookie Option. Where the host wishes to establish a secure connection, the host must return this same cookie in the subsequent message (or messages for trust chains which exceed a single packet). The host may then send additional information in the form of either a sequence of Certificate Path Advertisements, if allowed in the Cookie option. Finally, when all credentials are transmitted, the host again sends an Init message containing the last received cookie. For the case where the Init-Ack contained the failure code "Liveness Test Needed", no further credentials are required, although an Init MUST be resent containing the received Cookie Option. Soliman, et al. Expires August 28, 2008 [Page 34]
Internet-Draft Firewall Control Protocol February 2008 9. Creating New entries Entries consist of one or more flow identification options that are sent from an end node to the PDP. In order to create entries the end node must send a Request message to the PDP. The Request message MUST contain and appropriate session identifier value, and a Message identifier. The message identifier can be implemented as a monotonously increasing counter. The Request message contains the following options: o One or more Flow Identification options. Each option contains a unique Index field, an appropriate Action field, a format field indicating the format of the flow descriptor and an appropriate priority in the PRI field. o The Nonce option o The Digital Signature option. Upon receiving the Request message, the PDP verifies the signature in the message. If the verification fails, the message is silently discarded. Upon successful verification of the Request message, the PDP checks the message header. If the session identifier is not known, the PDP sends a Response message with the same session and message identifiers and includes and Acknowledgement option with the status field set to 130. If the message is correctly formed, the PDP inspects each flow identification option. If an error is found in any of the flow options, the PDP sends a Response message with the Acknowledgement indicating failure with the appropriate error code. The failed options MUST be included in the Response message. successful options are processed by the PDP. The process of updating existing flows is described in Section 10. If all options are processed successfully, the PDP sends a Response message. The session and message identifier fields are set to the same value in the Request message. The Response message includes the following options: o The Acknowledgement option. This option's status field indicates success o The Lifetime option. This option includes the lifietime associated with the new entries. The end node needs to refresh Soliman, et al. Expires August 28, 2008 [Page 35]
Internet-Draft Firewall Control Protocol February 2008 those entries before the lifetime expires. o The nonce option. o The Digital Signature option. Note that the process of adding new entries does not require the end nodes to send all existing entries. Only new flows need to be included in the Request message. Soliman, et al. Expires August 28, 2008 [Page 36]
Internet-Draft Firewall Control Protocol February 2008 10. Updating Entries Updating existing entries may take place due to the need for changing the flow description, deleting an existing entry, or simply refreshing an entry before its timer expires. When refreshing entries there is no need for the requesting node to send the entire Flow identifier option in a Request message. It is sufficient to send the option without the flow descriptor. Updating entries is done using the same Request message as described in Section 9 Upon receiving the Request message, the PDP verifies the Digital signature option. If the verification failed, the message is silently discarded. After successfully verifying the message, the PDP processes each flow identifier option for formatting, flow descriptor (if the FID field indicates a new flow) and the Action field. If all of the flow identifier options are rejected, the PDP responds with a Response message, including the acknowledgement option, which indicates failure with an appropriate error code. If some of the filter identifier options are rejected and others are accepted, the PDP responds with the Response message, including the acknowledgement option, which indicates partial success. The Response message also includes the lifetime option with an appropriate lifetime for the accepted options. In addition, the Response message includes all of the failed options. Each of the failed options includes a Status field, which indicates the reason for failure. After receiving the Response message, the requesting node updates its list of accepted entries and the corresponding lifetimes for those entries. Soliman, et al. Expires August 28, 2008 [Page 37]
Internet-Draft Firewall Control Protocol February 2008 11. Requesting an IPv4 Address A requesting node may wish to know the public IPv4 address and port numbers allocated to it by a NAT for one or more of its applications. To do that, it can request one or more IP addresses and port numbers while specifying the protocol that it wants to use. This is done by sending a Request message that includes the following options: o The IP address option. o The nonce option. o The digital signature option. Upon receiving the Request message, the PDP verifies the digital signature included. If the verification failed, the PDP silently discards the message. If the PDP allows nodes to request an IPv4 address, it can proceed with the processing of the IP address option. Otherwise, the PDP rejects the request by sending a Response message with an acknowledgement option contaiing the appropriate error code. If the IP address option is valid, the PDP proceeds to allocate the requested address(es) and port numbers. The method used by the PDP to communicate with the NAT/firewall is outside the scope of this document. If after allocating the IP address to the requesting node, the PDP sends a Response message including the IP address option, which includes the allocated addresses and ports, the nonce option, the lifetime option and the digital signature option. Upon receiving the Response message and verifying the digital signature option, the requesting node can use the IP address(es) and ports allocated in the message for the duration of the lifitime option. Should the requesting node wish to refresh the allocated addresses and ports, it MUST send the Request message with the IP address option including all the previously allocated IP addresses and ports. Soliman, et al. Expires August 28, 2008 [Page 38]
Internet-Draft Firewall Control Protocol February 2008 12. Timeouts and Retransmissions Where a host receives no response to a packet sent directly to a PDP, it may need to retransmit its initial packet. Each request MAY be transmitted up to four (4) times, each with a different Nonce and updated TimeStamp. Separation between one transmission and its next should be performed such that timeouts are exponential. RECOMMENDED timeouts are 1,2 and 4 seconds. A host SHOULD delay an initial retransmission by between 0 and 100ms, to ensure any retransmissions are serialized. The PDP never sends packets to the host, except in response to an FCON message. In order to respond in sufficient time, it is recommended that the PDP respond without induced delay to any packet sent directly to its IP address. 12.1. Session Start Delays When a new session is established, if a data plane transmission delays until FCON acknowledgements are received, there is likely to be significant added delay for every TCP or UDP session creation. It is therefore recommended that FCON immediately precedes packet transmission on the data plane, where it is not harmful to lose one or two of the initial packets. This may for example, be the case with unreliable protocols such as VoIP. Also, when a host has one or more existing communications open in negotiation with a PDP, it is possible to send the packets immediately after sending the FCON request. This optimizes for the case where new state is able to be created immediately, and reduces latency at the risk of causing packet loss and retransmission on initial packets. Where a host has not communicated to a PDP previously, it MAY induce additional delay before sending the data plane packets, in order to limit additional delays due to retransmission and timeout at the Transport Layer of the data session. Significantly, when FCON packet loss or delay occurs on the signalling path, this means that packet loss or delay will ensue, with the timings described in the prior section. Soliman, et al. Expires August 28, 2008 [Page 39]
Internet-Draft Firewall Control Protocol February 2008 13. IANA Considerations TBD Soliman, et al. Expires August 28, 2008 [Page 40]
Internet-Draft Firewall Control Protocol February 2008 14. Security Considerations Certain assumptions underly the initial version of this draft, which need to be considered appropriately. Firstly, the role of CGAs in providing proof of address ownership in this protocol is primarily an enabler, and may be insufficient in some environments to authorize communications for a particular destination. This may particularly be the case for devices with multiple users, where individuals have permission to access specific data services, but others are excluded. CGAs at host level granularity are insufficient to distinguish which of the users is attempting a communication. Mechanisms which could be used to provide such distinction are user- level digital signatures over the filter message contents and freshness information, in addition to CGA information. Additionally, to ensure that the PDP only has to process a single digital signature, subsets users on multi-host systems could be allocated CGAs tied to their own public key information while using that host. Therefore FCON messages from different users on a system would have different security credentials, and still allow CGA authorization. The internal processes on the host to allow for signing such messages is beyond the scope of this document, but it is easy to envisage an ICMP message signing service which a user subscribes to, that uses the subscribed private-key credentials to sign FCON and SEND messages. Regardless of the identity of the message signer, FCON request messages require authentication of the node, and the response messages require proof of the PDP's identity in order to prevent denial-of-service through spoofing attacks. Denial of service can occur due to the requirement to process digital signatures on response messages. Hosts which detect many excessive responses from PDPs, such as would indicate a denial-of-service attempt MAY defer processing digital signatures on responses, and rely on freshness and Nonce information in the message itself to determine if a digital signature needs to be processed. This limits denial . of service attacks to those who are able to guess nonces, or are on the path to the PDP. Soliman, et al. Expires August 28, 2008 [Page 41]
Internet-Draft Firewall Control Protocol February 2008 15. Acknowledgements Soliman, et al. Expires August 28, 2008 [Page 42]
Internet-Draft Firewall Control Protocol February 2008 16. Normative References [I-D.ietf-nsis-nslp-natfw] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-18 (work in progress), February 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, May 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. Soliman, et al. Expires August 28, 2008 [Page 43]
Internet-Draft Firewall Control Protocol February 2008 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Soliman, et al. Expires August 28, 2008 [Page 44]
Internet-Draft Firewall Control Protocol February 2008 Appendix A. Dynamic PDP Discovery (Informative) In some of the described scenarios, it may not be feasible to prepopulate the endpoints with information for all of the relevant PDPs responsible for firewall policy along a particular data path. For these scenarios, sending data to an existing configured PDP may be insufficient to create state in all firewalls on the path. This may lead to packets being dropped, even though signalling has been performed, and all known signaling accomplished. One mechanism to ensure that all PDPs for a data path are informed of changes is to send CREATE packets along the path at the time establishing a data connection. Such packets would be sent to the same IP source and destination as the packets in the data stream, but the IP packet would contain the Router-Alert Hop-By-Hop option [RFC2460]. Enforcement or Decision Point devices which receive such probes, would refer the packet for processing, and identify that the ICMP message contained a CREATE operation. The message filter contents would then define which sessions are requested to be allowed through the firewall. Depending upon policy, the PDP or PEP would either DENY the data flow, sending a CREATE-NACK message, refer the sender to an appropriate PDP using the PDP-REDIRECT message, or create the state for the session according to the filter, and send a CREATE-ACK. In the case that the session state creation is refused or redirected, the CREATE packet packet itself is dropped. In the alternative case where state is created, the CREATE packet should be forwarded onward toward its destination. At this stage, the potential to create multiple responses to a single message is the primary danger of this method. An alternative which increases setup latency is to drop the CREATE packet when new state is created, and send a CREATE-ACK. On each successive CREATE packet which does not alter session state, the CREATE packet is passed onward towards the destination. This removes any multiplication attacks, but causes delay of up to N x RTT for N policy devices along the path. Similar operations for UPDATE would also occur, with state being created if it didn't exist, or replaced in the case it already was in place. Once a host discovers that a Policy Decision Point exists on a particular path, it can then signal directly to it. Devices can add these to the PDPs discovered using DHCP or other mechanisms. Soliman, et al. Expires August 28, 2008 [Page 45]
Internet-Draft Firewall Control Protocol February 2008 Even though the packets are sent between the same source and destination addresses as those of the data session, they may travel a different path to the actual data stream, for example due to load balancing. In such a case, a PDP or PEP which receives the CREATE or UPDATE method can send a PDP-REDIRECT, to refer the origin to the appropriate policy decision point for the data flows. Where a host application accepts inbound packets passively, it may be useful to ensure that Policy enforcement and decision points beyond the DHCP configured range are included in signaling. Such can be achieved by configuring a filter describing the allowed inbound source and destination addresses of packets and addressing a hop-by- hop CREATE packet to a set of potential inbound source addresses. Such probing can be limited in terms of the number of addresses to probe, as well as the time-to-live of the packet itself, in order to prevent impacts upon the network. Soliman, et al. Expires August 28, 2008 [Page 46]
Internet-Draft Firewall Control Protocol February 2008 Authors' Addresses Hesham Soliman Elevate Technologies Email: hesham@elevatemobile.com Greg Daley Email: hoskuld@hotmail.com Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: suresh.krishnan@ericsson.com Soliman, et al. Expires August 28, 2008 [Page 47]
Internet-Draft Firewall Control Protocol February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Soliman, et al. Expires August 28, 2008 [Page 48]