Internet Engineering Task Force P. Savola Internet Draft CSC/FUNET Expiration Date: March 2003 September 2002 Firewalling Considerations for IPv6 draft-savola-v6ops-firewalling-00.txt Status of this Memo 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/ietf/1id-abstracts.txt. To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract There are quite a few potential problems regarding firewalling or packet filtering in IPv6 environment. These include slight ambiguity in the IPv6 specification, problems parsing packets beyond unknown Extension Headers and Destination Options, and introduction of end- to-end encrypted traffic and peer-to-peer applications. There may also be need to extend packet matching to include some Extension Header or Destination Option fields. This draft discusses these issues to raise awareness and proposes some tentative solutions or workarounds. Savola [Expires March 2003] [Page 1] Internet Draft draft-savola-v6ops-firewalling-00.txt September 2002 Table of Contents 1. Introduction ............................................... 2 2. Ambiguous Text in the IPv6 Specification ................... 3 2.1. The Problem ............................................ 3 2.2. Possible Solutions ..................................... 4 3. Parsing Extension Header Chains ............................ 4 3.1. The Problem ............................................ 4 3.2. Possible Solutions ..................................... 4 4. Parsing Unknown Destination Options and Security Policy .... 5 4.1. The Problem ............................................ 5 4.2. Possible Solutions ..................................... 5 5. Firewalls and End-to-End IPSEC-encrypted ESP-traffic ....... 6 5.1. The Problem ............................................ 6 5.2. Possible Solutions ..................................... 6 6. Firewalls and Interactions with Peer-to-Peer Applications .. 6 6.1. The Problem ............................................ 6 6.2. Possible Solutions ..................................... 7 7. Security Considerations .................................... 7 8. Acknowledgements ........................................... 7 9. References ................................................. 7 9.1. Normative References ................................... 7 9.2. Informative References ................................. 7 Author's Address ............................................... 8 A. Possible Desirable Header Field Matching Extensions ........ 8 1. Introduction There are quite a few potential problems regarding firewalling or packet filtering in IPv6 environment. These include slight ambiguity in the IPv6 specification, problems parsing packets beyond unknown Extension Headers and Destination Options, and introduction of end- to-end encrypted traffic and peer-to-peer applications. There may also be need to extend packet matching to include some Extension Header or Destination Option fields. This draft discusses these issues to raise awareness and proposes some tentative solutions or workarounds. In section 2, slightly ambiguous text in the IPv6 specification is discussed. In section 3, syntactical problem with parsing unknown Extension Headers is pointed out. In section 4, a similar problem with Destination Options is discussed in the context of security policy. In section 5, implications of end-to-end encrypted traffic are considerated. In section 6, similar implications of peer-to-peer applications are mentioned. In appendix A, some possibly useful Savola [Expires March 2003] [Page 2] Internet Draft draft-savola-v6ops-firewalling-00.txt September 2002 packet matching extensions for IPv6 are brought up. In this document, the term "firewall" is used to mean any kind of packet filter; no special features (like statefullness or L7 packet inspection) is assumed. 2. Ambiguous Text in the IPv6 Specification 2.1. The Problem The [IPV6] specification forbids skipping over any of the headers before processing them or processing them at all before reaching the destination (section 4): "With one exception, Extension Headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. There, normal demultiplexing on the Next Header field of the IPv6 header invokes the module to process the first Extension Header, or the upper-layer header if no Extension Header is present. The contents and semantics of each Extension Header determine whether or not to proceed to the next header. Therefore, Extension Headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of Extension Header and process that header prior to processing all preceding ones." And: "If, as a result of processing a header, a node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header." Similar applies to the specified Destination Options processing behaviour: if the Option Type has been specified so that the packet should not be processed further in the case of unrecognized options (ie. the highest-order two bits are not "00"), should the firewall also discard the packet and/or send ICMP Parameter Problem message back to the source? Savola [Expires March 2003] [Page 3] Internet Draft draft-savola-v6ops-firewalling-00.txt September 2002 Are these also to be done by intermediate nodes (which, by some definition, should not be processing Extension Headers or Destination Options Header with Hop-by-Hop options as an exception); this seems unlikely. This wording clearly does not take into the account that there might be middleboxes, or non-final destinations, that could be processing the packet. 2.2. Possible Solutions The correct behaviour must be made clear; the wording should be clarified. Clarifications might be needed at least on: 1. whether intermediate nodes should be taken into account in the text describing the header processing 2. intermediate nodes' behaviour when detecting unrecognized headers 3. Parsing Extension Header Chains 3.1. The Problem IPv4 [RFC1122] [RFC1812] silently ignores options it does not recognize; options have a specific, pre-defined format. IPv6 Extension Headers are structured differently: the header format can change, and generally it is not possible to parse the header, or proceed to the following Extension Headers unless the processing of the previous header has been implemented. The above is problematic as it is often the case that a packet filter will want to examine terminal headers, e.g. TCP or UDP. That is not possible if there is a problem processing any one of the preceding headers. 3.2. Possible Solutions In the generic case, even ignoring the IPv6 specification, unknown headers cannot be skipped over except by making some very wild guesses of the content. Thus the solutions (or work-arounds) are: 1. always keep the packet filter up-to-date, so that it can parse all types of Extension Headers Savola [Expires March 2003] [Page 4] Internet Draft draft-savola-v6ops-firewalling-00.txt September 2002 2. never introduce new Extension Headers, except possibly in a very controlled manner; use Destination Options instead 3. standardize the format (for at least the first N bytes including at least the length and the next header value) of possibly later specified new Extension Headers, so that skipping over headers could be possible The first is not a workable solution in a generic case at least if it's expected that new Extension Headers should be introducable: the lifetime of firewall devices and software seems to be much longer than one would expect. For example, it is good to consider the case of buggy firewalls and ECN support [ECN]: even though software fixes may have been available for a long time, upgrades have not taken place, hindering the deployment of new technology. The second seems quite a bleak work-around, but as currently specified, there is little choice; most (if not all) new features can probably be implemented using Destination Options. However, it's still good to document and understand this deployment and specification deadlock. The third might be doable but it would require some standardization effort. 4. Parsing Unknown Destination Options and Security Policy 4.1. The Problem Similar to the above, Destination Options may also include unknown options. However, the options are encoded in the TLV-format. So, skipping over unknown options is technically possible. However, especially in a very controlled environments, where a firewall may implement a strict security policy, it may be desirable to reject any options the firewall does not recognize (which may cause the end-nodes to do something that has not been anticipated in the security policy controlled by the firewall). 4.2. Possible Solutions No protocol action seems to be necessary provided that the implementation would not, in this case, send ICMP messages or discard packets upon receiving an unknown header. However, it may be desirable for firewall implementations to have a feature controlling the handling behaviour of unrecognized Destination Options. Savola [Expires March 2003] [Page 5] Internet Draft draft-savola-v6ops-firewalling-00.txt September 2002 5. Firewalls and End-to-End IPSEC-encrypted ESP-traffic 5.1. The Problem With the promise of the restoration of end-to-end transparency, and if at least some of the challenges for implementing PKI's are worked around, it may be possible that the amount of end-to-end encrypted traffic will increase enermously. The traffic is likely to be encrypted using IPSEC. In this case, on-the-path observers (such as a firewall) do not have the possibility to examine usually critical headers (such as TCP/UDP). This may result in an administrative decision to disable IPSEC-encrypted traffic by filtering it out. 5.2. Possible Solutions It would be desirable, if the users wish to do so, be able to have the firewall or some node the firewall is configured to trust as an intermediary in SPI negotiation/configuration. However, even though this may mitigate the risks somewhat, but it appears that SPI's could be reused (without the intermediary) in such a way that entirely different kind of traffic could be sent. There is no fix for this, by the definition of End-to-End cryptography. One could try to encode some interesting values, e.g. protocol numbers and ports in the Flow Label field; one problem here is the relatively limited length of 20 bits. But this would have to be done in the source node, which is not usually (at least completely) trusted in this context. There appears to be no solution for this, which is indeed a feature of end-to-end cryptography. 6. Firewalls and Interactions with Peer-to-Peer Applications 6.1. The Problem As above, the restoration of end-to-end transparency provides a possibility for a more wide-spread use of peer-to-peer applications. Such applications are often a bit problematic from the firewall perspective: it is often the practise to allow outbound (from the protected site) traffic while allowing in only the related traffic (and naturally some other administratively permitted traffic). Being able to run (some) peer-to-peer applications easily in a controlled environment would be valuable. Savola [Expires March 2003] [Page 6] Internet Draft draft-savola-v6ops-firewalling-00.txt September 2002 6.2. Possible Solutions One workaround would be to try to standardize some default port ranges (in an application-specific manner) for such applications as these, for example in the above 32768 range. In this way, a site could enable/disable (default) port ranges for (some) peer-to-peer applications at will. A major disadvantage here would be that this could violate the trust model: some applications could intentionally try to use some other's port range to gain entry through the firewall even if the default range was blocked. This implies there's at least some form of trust here. A real, but possibly quite a complex solution would be to implement some form of peer-to-peer "pinholing" [MIDCOM]. This hasn't yet been standardized even for IPv4 (though the concept is quite protocol- independent). 7. Security Considerations This draft discusses security considerations related to IPv6 firewalling. When discussing potential solutions for problems, the weaknesses are also pointed out. In general, the firewall does not, and cannot, often trust the node(s) it protects. These may even belong to different administrative entit(y/ies). In that case, making compromises will usually open some holes in the firewall. 8. Acknowledgements Brian Carpenter suggested an IPv6 firewall could support P2P pinholing. 9. References 9.1. Normative References [IPV6] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 9.2. Informative References [RFC1122] Braden, R. (Editor), "Requirements for Internet Hosts -- Communication Layers", RFC1122, October 1989. [RFC1812] Baker, F. (Editor), "Requirements for IP Version 4 Routers", RFC1812, June 1995. Savola [Expires March 2003] [Page 7] Internet Draft draft-savola-v6ops-firewalling-00.txt September 2002 [ECN] Garzik, J., "ECN-under-Linux Unofficial Vendor Support Page", http://gtf.org/garzik/ecn/, March 2002. [MIDCOM] Srisuresh, P. et al, "Middlebox communication architecture and framework", RFC3303, August 2002. [RHHAOSEC] Savola, P. "Security of IPv6 Routing Header and Home Address Options", work-in-progress, draft-savola-ipv6-rh-ha-security-02.txt, March 2002. [MIPV6] Johnson, D., et al, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18.txt, work-in-progress, June 2002. [MIPV6CAO] O'Neill, A., "MIPv6 Care of Address Option", draft-oneill-mipv6-cao-00.txt, work-in-progress, Sep 2002. Author's Address Pekka Savola CSC/FUNET Espoo, Finland EMail: psavola@funet.fi A. Possible Desirable Header Field Matching Extensions As Destination options and Extension Header types are taken into use, it may be desirable for a firewall to support some matching against certain header fields. These include, for example: - whether or not a specific Extension Header or a Destination Option is detected - behaviour when an unknown (or specified) Extension Header or Destination Option is detected - (Routing Header -specific) being able to match segments left (mainly, whether it is zero or not), type and the next-to-be- swapped destination(s) [RHHAOSEC] - (Home Address Option [MIPV6] -specific) being able to match against the home address - (Care-of Address Option [MIPV6COA] -specific) being able to match against the care-of address used for ingress filtering - (ESP/AH -specific) being able to match against SPI - (Tunneled-traffic specific) being able to match against the embedded IPv4 address in e.g. 6to4, ISATAP, etc. Some of these are much more useful than others; the list is only meant to give ideas about possibly useful (in some scenarios, at least) functionalities. Savola [Expires March 2003] [Page 8]