Internet-Draft O. Andreasson draft-oskar-andreasson-cstp-00.txt Frozentux Expires 17th December 2004 June 2004 Connection State Transfer Protocol This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This draft documents a new protocol which may be used to connect several firewalls together, and to share connection states between these stateful firewalls. This has been a problem for several years and in several Operating Systems, including Linux. Another problem that this draft addresses is the ability to share connection states between non-vendor specific firewalls, hence hopefully making it possible to connect firewalls in "firewall clusters" from different vendors. Introduction Motivation For several years there has been a lack of protocols for transfering connection states between firewalls. A connection state meaning the current state that a specific connection is in, is it up or is it down, or is it about to close? If you have redundant firewalls, and the first one crashes, this means that all of the connections going over the first firewall will also crash. This protocol will make it possible to seamlessly transit all traffic to a secondary (or Andreasson [Page 1] Internet-Draft June 2004 tertiary) firewall as needed. Scope This is a multipurpose protocol for transporting both real connection states as described by [ROOIJ], as well as partial connection states. Real connection states (Called Full State updates throughout this document) are very expensive to transport between firewalls, but at the same time provides for much higher security in failover. Partial state updates are less expensive, both in bandwidth and processing power. However, the fallback is that Partial State updates gives less security in a failover, or loadbalanced firewall scenario. Packet types 5 types of defined packets: - Auth request - Auth reply - Full State update - Partial state update - Full state request Basic headers 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pkt_type | Unused bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * pkt_type: 1. Auth request 2. Auth reply 3. Full State update 4. Partial state update 5. Full state request * Unused bits For future enhancements of the protocol. Andreasson [Page 2] Internet-Draft June 2004 Auth request headers 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hostid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Crypto_type | Pwd_len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Password ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Protocol runs on top of TCP. * The whole stream should be acredited by single successful initial handshake. * Failed initial handshake should lead to drop of connection. headers: * hostid - 48 bits used to distinguish separate routers/firewalls in HA network. Each host can have separate credentials for each host. * crypto_type - 16 bits Which type of encryption is used for the password. This is extensible, if need be to add new encryptions in the future. 1. Clear text 2. DES 3. 3DES 4. MD5? 5. Blowfish? * Unused bits Bits that are currently not used, for future enhancements. * pwd_len - 16 bits Password length, after encryption, in bits. * Password - Variable length The full password, either clear text of encrypted with crypto specified in crypto type field. The length of the field is specified in pwd_len. Auth reply headers On success of authorization from the connecting party, the connected party must also send credentials back to complete the connection. This is used to prevent man in the middle attacks of the protocol. Andreasson [Page 3] Internet-Draft June 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hostid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Crypto_type | Pwd_len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Password ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Reply packet contains the exact same headers as request packet. * If auth reply packet fails, the connection should be dropped. Full state update All packets of a Full State update type will carry the generic headers first. Full state updates must be sent for every packet that is sent. This due to the fact that it carries information that must be known to be able to make a secure takeover of the connection state tables from one machine to another. A connection using Full State updates must use Full State updates throughout the entire session between the firewalls. This means that you can not handle one connection by Full State updates, while another connection uses the Partial State update at the same time. Full State updates are very costly from a bandwidth and processing usage point of view, but should facilitate a very secure failover between firewalls that support real connection tracking. It should even be possible to use this for load balancing firewalls, as long as the packets within a stream are not reordered. Generic headers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Unused | Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Protocol - 8 bits The subprotocol of IP that the state update refers to. * Unused - 8 bits Unused bits for future enhancements of the protocol. Andreasson [Page 4] Internet-Draft June 2004 * Timeout - 16 bits The number of seconds left before the connection will timeout. Based upon the protocol specified in the protocol field, the upcoming headers differ. We have specified the required information for TCP, UDP and ICMP here. TCP headers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source port | Destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State |A|R| Unused | Source Window | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Acknowledgment number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination window | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Acknowledgment number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Source - 32 bits Source IP address of expectation. * Destination - 32 bits Destination IP address of expectation. * Source port - 16 bits Source port of expectation. * Destination port - 16 bits Destination port of expectation. * State - 8 bits The current state of the stream. See section [Currently available states]. * Assured - 1 bit Andreasson [Page 5] Internet-Draft June 2004 Tells us if the connection in question is assured or not. If it is not assured, it may be dropped in case the connection tracking device is trying to track too many connections. * Reply - 1 bit If we have seen a reply to the originating packet of this stream. * Unused - 6 bits For future usage within the protocol. * Source Window - 16 bits The current window, in which the sender is willing to accept packets in, starting from the Acknowledgment field. This is sent for true connection tracking capabilities[ROOIJ]. It may be ignored by other end. If the party sending the state update doesn't have the Window available, the field may be set to all zeroes. * Source Sequence number - 32 bits The sequence number or the last packet seen in a specific direction. It may be ignored by receiving host. If the sending party does not know the source sequence number, it may set the field to all zeroes. * Source Acknowledgment number - 32 bits The source acknowledgment number is taken from the last packet seen. It may be ignored by recipient, or set to all zeroes by sending party. It is included for true connection tracking capabilities. * Destination Window - 16 bits Used for true connection tracking capabilities. Works the same as for the Source window, but for the destination endpoint of a connection. * Unused - 16 bits For future enhancements of the protocol. * Destination Sequence number - 32 bits Used for true connection tracking capabilities. Works the same as for the source sequence number, but for destination endpoint of a connection. * Destination acknowledgment number - 32 bits Used for true connection tracking capabilities. Works the same as for the source acknowledgment number, but for destination endpoint of a connection. Andreasson [Page 6] Internet-Draft June 2004 UDP headers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source port | Destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State |A|R| Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Source - 32 bits Source IP address of expectation. * Destination - 32 bits Destination IP address of expectation. * Source port - 16 bits Source port of expectation. * Destination port - 16 bits Destination port of expectation. * State - 8 bits The current state of the stream. See section [Currently available states]. * Assured - 1 bit Tells us if the connection in question is assured or not. If it is not assured, it may be dropped in case the connection tracking device is trying to track too many connections. * Reply - 1 bit If we have seen a reply to the originating packet of this stream. * Unused - 18 bits For future usage within the protocol. Andreasson [Page 7] Internet-Draft June 2004 ICMP headers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | State | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Source - 32 bits Source IP address of expectation. * Destination - 32 bits Destination IP address of expectation. * Type - 8 bits The ICMP Type of the packet we have seen. * Code - 8 bits The ICMP Code of the packet we have seen. * State - 8 bits The current state of the stream. See section [Currently available states]. * Unused - 8 bits For future usage within the protocol. Partial state update All packets of a Partial State update type will carry the generic headers first. Partial state updates must not be sent more than at a state change, or once at every n'th packet. It must also be transmitted every time the State field changes. This is used to facilitate hosts that want to transfer states between firewalls, but where bandwidth usage may be very high, and hence state updates may not be possible for every single packet. This type of state update should be friendlier to both bandwidth and processing power. Partial State updates will not allow for real connection tracking[ROOIJ], nor real connection tracking failover. Andreasson [Page 8] Internet-Draft June 2004 Generic headers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Unused | Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Protocol - 8 bits The subprotocol of IP that the state update refers to. * Unused - 8 bits Unused bits for future enhancements of the protocol. * Timeout - 16 bits The number of seconds left before the connection will timeout. Based upon the protocol specified in the protocol field, the upcoming headers differ. We have specified the required information for TCP, UDP and ICMP here. This protocol may be updated for other protocols as necessity dictates. TCP headers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source port | Destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State |A|R| Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Source - 32 bits Source IP address of expectation. * Destination - 32 bits Destination IP address of expectation. * Source port - 16 bits Source port of expectation. * Destination port - 16 bits Andreasson [Page 9] Internet-Draft June 2004 Destination port of expectation. * State - 8 bits The current state of the stream. See section [Currently available states]. * Assured - 1 bit Tells us if the connection in question is assured or not. If it is not assured, it may be dropped in case the connection tracking device is trying to track too many connections. * Reply - 1 bit If we have seen a reply to the originating packet of this stream. * Unused - 22 bits For future usage within the protocol. UDP headers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source port | Destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State |A|R| Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Source - 32 bits Source IP address of expectation. * Destination - 32 bits Destination IP address of expectation. * Source port - 16 bits Source port of expectation. * Destination port - 16 bits Destination port of expectation. * State - 8 bits The current state of the stream. See section [Currently available states]. * Assured - 1 bit Andreasson [Page 10] Internet-Draft June 2004 Tells us if the connection in question is assured or not. If it is not assured, it may be dropped in case the connection tracking device is trying to track too many connections. * Reply - 1 bit If we have seen a reply to the originating packet of this stream. * Unused - 18 bits For future usage within the protocol. ICMP headers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | State | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Source - 32 bits Source IP address of expectation. * Destination - 32 bits Destination IP address of expectation. * Type - 8 bits The ICMP Type of the packet we have seen. * Code - 8 bits The ICMP Code of the packet we have seen. * State - 8 bits The current state of the stream. See section [Currently available states]. * Unused - 8 bits For future usage within the protocol. Full state request Upon receiving a packet of Full state request, the recipient must send all of its tracked connections to the host requesting the update. The request is answered by sending all of the currently tracked connections that are locally generated by State update packets. Andreasson [Page 11] Internet-Draft June 2004 Currently available states These values depends upon the protocol which was used in the generic headers. The states are only valid within their specified protocol, and if you add a new protocol, you are advised to create a new States table for the additional protocol. TCP states: Integer value State name 0 NONE 1 SYN_SENT 2 SYN_RECV 3 ESTABLISHED 4 FIN_WAIT 5 TIME_WAIT 6 CLOSE 7 CLOSE_WAIT 8 LAST_ACK 9 LISTEN UDP states: Integer value State name 0 NONE 1 NEW 2 ESTABLISHED ICMP states: Integer value State name 0 NONE 1 NEW Security considerations This protocol contains vital information regarding connections between firewalls. If possible, it should be avoided at all costs to send this protocol over non-trusted networks because of the sensitivity of the contained data. The best solution for this, is to either run the protocol through an encrypted tunnel, or over a cross-over cable between the primary and secondary firewalls, which share no other hosts. Andreasson [Page 12] Internet-Draft June 2004 Iana considerations This document has no actions for IANA. Author's Address Oskar Andreasson C/O Andreas Forsgren Kantatvägen 29 SE-13140 NACKA Phone: +46-739-166024 EMail: oan@frozentux.net References Informative References [ROOIJ] Rooij, G., "Real Stateful TCP Filtering in IP Filter", Origin IT, 2000 Normative References Expires 17th of December 2004 Andreasson [Page 13]