[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/