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

Versions: 00 01 02 03 draft-vives-distsec-framework

Internet Engineering Task Force                                 A. Vives
Internet-Draft                                                  J. Palet
Expires: October 20, 2004                                    Consulintel
                                                          April 21, 2004


                    IPv6 Security Problem Statement
               draft-vives-v6ops-ipv6-security-ps-00.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 October 20, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   Today, each network is often secured by a unique device (i.e.
   security gateway or firewall), that becomes a bottleneck for the
   end-to-end security model with IPv6. The deployment of IPv6 enabled
   devices and networks bring some issues, which must be addressed by
   security administrators in order to guarantee at least the same level
   of security obtained nowadays with IPv4 and perimeter security
   schemes, allowing at the same time all the IPv6 advantages.

   The most important issues are the rediscovery of end-to-end
   communications, the availability of IPsec in all IPv6 stacks, the



Vives & Palet           Expires October 20, 2004                [Page 1]


Internet-Draft      IPv6 Security Problem Statement           April 2004


   increase in the number and type of IP devices and also the increase
   in the number of "nomadic" devices, meaning devices that will be
   connected to different networks (that could have different security
   policies).

   The security policies and architectures currently applied in Internet
   with IPv4, does not longer apply for end-to-end security models which
   IPv6 will need. This document outlines the advantages and drawbacks
   of both security schemes: perimeter and distributed.

   This document aims to identify IPv6 issues that justify the need of a
   distributed security model for IPv6, that is, simply to show that a
   security problem will arise with the deployment of IPv6 networks if
   nothing is done.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Perimeter versus Host-based Security . . . . . . . . . . . . .  4
     2.1   Perimeter Security . . . . . . . . . . . . . . . . . . . .  4
     2.2   Host-based Security  . . . . . . . . . . . . . . . . . . .  5
   3.  IPv6 Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1   End-to-End . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2   IPsec-encrypted ESP-traffic in transport mode  . . . . . .  8
     3.3   Mobility . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.4   Addresses  . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.5   Neighbor Discovery Weakness  . . . . . . . . . . . . . . .  9
   4.  Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 11
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
       Intellectual Property and Copyright Statements . . . . . . . . 13
















Vives & Palet           Expires October 20, 2004                [Page 2]


Internet-Draft      IPv6 Security Problem Statement           April 2004


1.  Introduction

   This document will cope only with IPv6 issues related to security,
   i.e., will try to answer the following question: How would affect the
   security of a network the deployment of IPv6? This network would be
   an existent IPv4 one which will have also IPv6 traffic from IPv6
   capable nodes, or an IPv6 only network.

   As the deployment of IPv6 enabled devices and networks come, some
   points must be taken in account by the security administrator:

   o  The rediscovery of end-to-end communications.

   o  The availability of IPsec in all IPv6 stacks.

   o  The increase in the number and type of IP devices.

   o  The increase in the number of "nomadic" devices, meaning devices
      that will be connected to different networks and moving.

   The security policies and architectures currently applied in Internet
   with IPv4, does not longer apply for end-to-end security models which
   IPv6 will enable. This document will outline the advantages and
   drawbacks of both security schemes: perimeter and distributed.

   Also IPv6 issues will be identified that justify the need of
   distributed security for IPv6, that is, simply to show that a
   security problem will arise with the deployment of IPv6 networks if
   traditional schemes are used.

   The following issues are out of scope of this document and will be
   addressed elsewhere:

   o  State the security requirements for the addressed IPv6 scenario.

   o  Propose a solution or architecture to address the problem stated
      in this document.

   o  To address security problems derived from the use of transition
      mechanisms.

   Last but not least, this document contains a brief definition of what
   we understand by "security". We use security in the "big sense" of
   the word, trying to include as much as possible. In other words, a
   host, a network or some information, will be secure when no threats
   could succeed against them, by mean of different kinds of attacks. A
   success will mean compromise of availability, integrity,
   confidentiality or authenticity. The realistic objective is to be as



Vives & Palet           Expires October 20, 2004                [Page 3]


Internet-Draft      IPv6 Security Problem Statement           April 2004


   much secure as possible in a precise moment. It will be part of the
   requirements to establish which kind of security is given using a
   number of mechanisms.

2.  Perimeter versus Host-based Security

   In this section two different approaches are analyzed to be used
   later in the rationale about the security problems that IPv6 could
   introduce

2.1  Perimeter Security

   The perimeter scheme is the most common one and is based in the
   topology of the network, i.e., host's security will depend on where
   it is connected to. The security policy is enforced in a central host
   or firewall (FW), which provides secure network connectivity to one
   or more network segments. The FW will be what an "outside" host sees
   when tries to attack the network. Attacks coming from the same LAN
   segment are not protected by the FW.


                        /-------\
                       /         \
                      |  Internet |
                       \         /
                        \---+---/
                            |
                            | Policy Enforcement Point
                        +---+---+
            LAN-1       |       |     DMZ-1
          ----+---------+  FW   +-------+----
              |         |       |       |
            +----+      +---+---+    +----+
            | H1 |          |        | S1 |
            +----+          |LAN-2   +----+
                            |
                    +----+  |
                    | H2 |--+
                    +----+  |

   Figure 1: Perimeter Security

   This model is based on the following assumptions:

   o  The threats come from "outside" the FW, basically the Internet.

   o  Everybody from "inside" the FW is trustable.




Vives & Palet           Expires October 20, 2004                [Page 4]


Internet-Draft      IPv6 Security Problem Statement           April 2004


   o  The protected nodes won't go "outside" where FW won't be able to
      protect them.

   o  There are no backdoors on the network (modem, WLAN, other
      connections).

   o  The hosts will not need to be accessed directly from outside (at
      least in a general manner, i.e., all ports on all hosts).

   The main advantage of this scheme is its simplicity and easiness as
   the elements and points of configuration are reduced to the minimum,
   requiring few/none protocols and mechanisms to implement the
   security.

   The drawbacks of this model are:

   o  This is a centralized model: Single point of failure for both
      performance and availability. If the FW fails, then all the
      networks connected to it loose network connectivity.

   o  A big percentage of the threats come from inside the FW, and are
      not addressed by this security model.

   o  The most dangerous threats come from inside the FW.

   o  The FW usually acts as NAT and/or proxy box, interfering or even
      disallowing end-to-end communications.

   o  Transport mode secured communications (using IPsec ESP for
      example) need special solutions ([1]).

   o  The same security policy is enforced for all the nodes of each
      network connected to the FW. Consequently an error in the FW will
      equally expose all hosts in a network.

   o  Virtual organizations, for example those using GRID models, don't
      work with traditional centralized security models.

   o  The lack of secure end-to-end prevents innovation.


2.2  Host-based Security

   Host based security model, already introduced by [2], is based on the
   idea of enforcing the security policy in each network host from a
   central control point.

   The three main elements identified in the distributed security model



Vives & Palet           Expires October 20, 2004                [Page 5]


Internet-Draft      IPv6 Security Problem Statement           April 2004


   are:

   o  Policy Specification Language.

   o  Policy Exchange Protocol.

   o  Authentication of Entities.

   The basic idea is simple, the Security Policy is centrally defined
   using the Policy Specification Language and distributed to each host
   by means of the Policy Exchange Protocol. The Network Entities need
   to be authenticated in order to be trusted, for example to allow an
   incoming connection or to trust on the received Security Policy.


                        /-------\
                       /         \
                      |  Internet |
           +------+    \         /
           |Sec.  |     \---+---/
           |Policy|         |
           +------+         |
              |           /---\  LAN-3
              |          | \ / |-------+--
             -+---+------+  x  +       |
            LAN-1 | (*)  | / \ |       | (*)Policy Enforcement Point
               +----+     \---/      +----+
               | H1 |       | LAN-2  | H3 |
               +----+       |        +----+
                            | (*)
                         +----+
                         | H2 |
                         +----+

   Figure 2: Host-based Security

   This model is based on the following assumptions:

   o  Each host can be unique and securely identified.

   o  The security policy could be applied in one or more of the
      following levels: network, transport and application.

   o  The threat comes from anywhere in the network.

   o  The intruder has no physical access to the protected network hosts
      (what about malicious users? See other topics section).




Vives & Palet           Expires October 20, 2004                [Page 6]


Internet-Draft      IPv6 Security Problem Statement           April 2004


   o  "Outside" hosts can access all hosts "Inside".

   The advantages of this model are:

   o  The security policy can be host-defined.

   o  A host can take better decisions as it knows what it is doing or
      trying to do, that means it can better detect strange packets. For
      example, can allow mail traffic to only one application on the
      system.

   o  Enables the usage of end-to-end applications level security (i.e.
      web services security standards).

   o  Can protect a host not depending on the topology, i.e., wherever
      the host is connected.

   o  Do not need specific devices to secure a host (consider the case
      of single host with a CPE).

   o  Can control the outgoing attempts from each host, avoiding local
      network misbehavior or malicious practices.

   o  The collection of audit information could be more complete in a
      distributed model, despite the processing of that information is
      done distributed or centralized.

   o  It maintains the centralized control of the security policies,
      from where they are distributed to each host (central decisions,
      local enforcement).

   The drawbacks of this model are:

   o  It is more complex than the perimeter one.

   o  The uniqueness and secured identification of hosts is not trivial,
      for example using certificates ([2]).


3.  IPv6 Issues

   When IPv6 is deployed, either in an existing IPv4 network or in a new
   IPv6-only network, the security administrator must take into account
   that IPv6 traffic will be different from the IPv4 one.

   IPv6 enabled nodes will have global addresses, which means they are
   reachable from any other IPv6 node in the Internet. A security
   administrator can avoid this but, if so, it makes no sense to use



Vives & Palet           Expires October 20, 2004                [Page 7]


Internet-Draft      IPv6 Security Problem Statement           April 2004


   IPv6.

3.1  End-to-End

   As stated in [3], section 6, there is a problem with end-to-end
   communications, which means that every host must be reachable from
   any other host, included the ones from "outside". This is a problem
   in the perimeter security model.

   This kind of communications provides the required framework for
   further innovation, where technologies like P2P or GRID can widely
   spread with no problems.

   In [4] some possible solutions are outlined, one of them being a host
   firewall.

3.2  IPsec-encrypted ESP-traffic in transport mode

   As stated in [3], section 5, there is a problem with the IPv6
   encrypted traffic (IPsec ESP mechanism in transport mode, for
   example) and the perimeter security model.

   The idea is that a host inside the network can establish an encrypted
   communication channel with other host outside of the network, for
   example. A middlebox (for example the perimeter firewall) won't be
   able to inspect the content of such a communication.

   In [4] some possible solutions are outlined, one of them being a host
   firewall.

3.3  Mobility

   In parallel to the increase in the number of devices, IPv6
   facilitates that those devices are "mobile", that is, can easily move
   from one network to another using Mobile IPv6 or just disconnecting
   from one and connecting to another (sometimes called micro- and macro
   mobility respectively).

   Because of the amount of addresses available and the facilities given
   by Autoconfiguration mechanisms together with the mentioned rise of
   the number of IP devices, this kind of behavior should be taken into
   account by the security administrator, as these devices will be
   connected to networks where they have no control and consequently, no
   responsibility.

   A possible solution for these devices is the use of host based
   security, enabled in every network it is connected. The policies and
   mechanisms should be described elsewhere.



Vives & Palet           Expires October 20, 2004                [Page 8]


Internet-Draft      IPv6 Security Problem Statement           April 2004


3.4  Addresses

   Regarding the addresses in IPv6 must be taken into account that:

   o  The amount of addresses is much bigger for a given network.

   o  Each host will have more than one address, one ore more of them
      globally routable.

   o  An IPv6 node can use randomly generated addresses [5].

   That means:

   o  To scan a given network whole range of addresses and ports will
      take a really big effort [6]. It would be easier to do that
      sniffing a LAN segment looking for existent addresses.

   o  The common way of identify a host by means of its IP address will
      be more difficult to use.

   o  If a host uses randomly generated addresses [5], it could be
      problematic to identify a host using its IP address for security
      policy matching purposes.

   Regarding the scan of addresses, [6] demonstrates that the "brute
   force" scanning would make no sense for an IPv6 address range,
   typically a minimum of /64.

   So an attacker would change the scanning method reducing the range as
   much as possible and when a host is found, the attacker should try to
   compromise this one, as then the scanning could continue from the
   compromised host, from where the success would be greater. If the
   found host could not be compromised, then the first "brute force"
   scanning could continue until the next host is found.

   A host based security scheme would protect the other hosts from the
   compromised one.

   The idea behind all this is that the new IPv6 address scheme and
   mechanisms will somehow protect from existent attack techniques but
   we can be sure that they will adapt themselves to the new scheme and
   we have to act consequently being prepared.

3.5  Neighbor Discovery Weakness

   As said above, one of the assumptions of the host-based security
   model is that all hosts in the network are non trusted, the possible
   threats coming from the same LAN segment must be taken into account,



Vives & Palet           Expires October 20, 2004                [Page 9]


Internet-Draft      IPv6 Security Problem Statement           April 2004


   in this case the ones coming from Neighbour Discovery (ND) [7][8].

   Note that this is not possible within the perimeter security model,
   although some detection mechanism could be implemented, nothing can
   be done to protect the hosts.

   As described in [4] there are some threats over ND.

   There are some ways to interfere in the normal behavior of the
   autoconfiguration process, causing redirection of traffic and/or DoS
   (Denial of Service).

   Special attention must be put on Router Advertisement (RA), Router
   Solicitation (RS), Neighbour Solicitation (NS), Neighbour
   Advertisement (NA) and Redirect messages. See [4] for a detailed
   explanation of possible threats.

   The possibility of using host firewalls and/or IDS (Intrusion
   Detection Systems) for protecting hosts against these threats must be
   studied.

   It seems straightforward that if the hosts sending packets must be
   authenticated against the rule-set configured in the host firewall
   [2], that protects the host against most of the threats described in
   [4].

4.  Other Issues

   Further elaboration is required (TBD) on:

   o  Malicious users: We can't protect the network from malicious users
      that have physical access to network hosts in the protected
      network. The objective is to minimize the danger they can cause.

   o  In the host based security, the host that stores and distributes
      the security policies seems to be the best option to be the one
      that acts as IDS.


5.  Security Considerations

   This document is concerned entirely with security.

6.  Acknowledgements

   The authors would like to acknowledge the inputs of Brian Carpenter
   and the European Commission support in the co-funding of the Euro6IX
   project, where this work is being developed.



Vives & Palet           Expires October 20, 2004               [Page 10]


Internet-Draft      IPv6 Security Problem Statement           April 2004


7.  References

7.1  Normative References

7.2  Informative References

   [1]  "IETF midcom WG", <http://www.ietf.org/html.charters/
        midcom-charter.html>.

   [2]  Bellovin, S., "Distributed Firewalls", November 1999, <http://
        www.research.att.com/~smb/papers/distfw.pdf>.

   [3]  Savola, P., "Firewalling Considerations for IPv6",
        draft-savola-v6ops-firewalling-02 (work in progress), October
        2003.

   [4]  Nikander, P., "IPv6 Neighbor Discovery trust models and
        threats", draft-ietf-send-psreq-04 (work in progress), October
        2003.

   [5]  Narten, T. and R. Draves, "Privacy Extensions for Stateless
        Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [6]  Chown, T., "IPv6 Implications for TCP/UDP Port Scanning",
        draft-chown-v6ops-port-scanning-implications-00 (work in
        progress), October 2003.

   [7]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
        IP Version 6 (IPv6)", RFC 2461, December 1998.

   [8]  Thomson, S. and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.


Authors' Addresses

   Alvaro Vives Martinez
   Consulintel
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain

   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   EMail: alvaro.vives@consulintel.es






Vives & Palet           Expires October 20, 2004               [Page 11]


Internet-Draft      IPv6 Security Problem Statement           April 2004


   Jordi Palet Martinez
   Consulintel
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain

   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   EMail: jordi.palet@consulintel.es










































Vives & Palet           Expires October 20, 2004               [Page 12]


Internet-Draft      IPv6 Security Problem Statement           April 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Vives & Palet           Expires October 20, 2004               [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/