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

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

Internet Engineering Task Force                                 J. Palet
Internet-Draft                                                  A. Vives
Expires: August 24, 2005                                     Consulintel
                                                             G. Martinez
                                                                A. Gomez
                                              University of Murcia (UMU)
                                                       February 20, 2005


                 IPv6 Distributed Security Requirements
                 draft-palet-v6ops-ipv6security-02.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 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 August 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The security policies currently applied in Internet with IPv4,
   doesn't longer apply for end-to-end security models which IPv6 will
   enable.



Palet, et al.            Expires August 24, 2005                [Page 1]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


   Today, each network is often secured by one or several devices (i.e.
   security gateway or border firewall in the simplest configuration),
   which become a bottleneck for the end-to-end security model with
   IPv6.

   In addition, users and devices start to be nomadic, moving between
   different networks that could have different security policies.

   A distributed and dynamic approach is consequently required, as
   already described by [1].

   All these points and others are discussed in [2] as a reason of
   concern for the security administrator when operating IPv6 networks.
   In this document the problem is accepted and a step forward is done
   defining the requirements for a possible solution.

   How these requirements are satisfied by a possible solution is out of
   the scope of the present document.

































Palet, et al.            Expires August 24, 2005                [Page 2]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Security Definition  . . . . . . . . . . . . . . . . . . . .   4
   3.   Distributed Security Model . . . . . . . . . . . . . . . . .   5
   4.   The Host . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1  Interior Security  . . . . . . . . . . . . . . . . . . . .   6
     4.2  The Visiting Node  . . . . . . . . . . . . . . . . . . . .   6
     4.3  Default Security . . . . . . . . . . . . . . . . . . . . .   7
     4.4  Other Considerations . . . . . . . . . . . . . . . . . . .   7
   5.   Security Policy Server and Protocol  . . . . . . . . . . . .   8
   6.   Non-security-capable Nodes and Security Workload
        Distribution . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.   Location of the Security Policy Server . . . . . . . . . . .   9
   8.   Security Mechanism Modules . . . . . . . . . . . . . . . . .  10
   9.   Conclusions  . . . . . . . . . . . . . . . . . . . . . . . .  10
   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  11
   11.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  11
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  11
     12.1   Normative References . . . . . . . . . . . . . . . . . .  11
     12.2   Informative References . . . . . . . . . . . . . . . . .  12
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  12
        Intellectual Property and Copyright Statements . . . . . . .  14




























Palet, et al.            Expires August 24, 2005                [Page 3]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


1.  Introduction

   Today's Internet paradigms for security need a revision with the
   deployment of IPv6, as suggested in [2], offering end-to-end security
   capabilities.

   Current security policies based on a centric approach with unique
   border devices don't longer apply, the so-called network-based
   security.  Often they are based in a firewall or security gateway and
   statically configured rules, which don't work in all the situations,
   for example, they don't consider the internal threats.

   Additionally, the network-based security model is deeply incompatible
   with the model of virtual organizations that is fundamental to Grid
   computing, where virtual organizations cross all traditional security
   boundaries.

   Users and devices start to be nomadic.  They often move from one
   network to another and this needs to be taken in consideration to
   keep the security of the complete visited network abd the nomadic
   host.

   Keeping today's static security model seems to be the wrong approach,
   which interferes with the end-to-end features and advantages of IPv6.

   Enforcing the nomadic users and devices to connect to Internet by
   means of the security gateway, in tunnel mode, is often equivalent to
   disable the IPsec protocol on each node, not allowing the use of
   transport mode and consequently invalidating one of the key IPv6
   advantages.

   The lack of end-to-end secure communication and in general the
   current network-based security model, specially in enterprise
   networks, prevents innovation.

   On the other hand, it is also true and perfectly understandable that
   there is a need to enforce security in the networks, in such way that
   the security administrator has always the control over it.

2.  Security Definition

   As this document tries to stablish the security requirements for an
   IPv6 network, the definition of what is understood as security is of
   capital importance.

   We use security in the "big scope" 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 attacks could succeed against



Palet, et al.            Expires August 24, 2005                [Page 4]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


   them.  A success will mean compromise of availability, integrity,
   confidentiality or authenticity.  The realistic objective is to be as
   much secure as possible in a precise moment.

   So the security solution should include a number of mechanisms to
   provide security to network devices.  Current mechanisms could be
   integrated in the solution and defined in the security policy.  For
   example there could be active firewalling together with Intrusion
   detection, antivirus software and system update mechanisms.

   Security mechanisms should also include techniques to mitigate the
   danger in case of a compromised host and/or network.

3.  Distributed Security Model

   As described in [2], a possible security scheme is the distributed
   one [1], as an alternative to the network-based model.

   The aim is to keep, or even more, be able to increase the security in
   the network as a whole and simultaneously keep the control of it
   under the security administrator hands, while the individual nodes
   can take advantage of end-to-end and secure end-to-end
   communications.

   The basic idea is simple: the Security Policy is centrally defined
   using the Policy Specification Language and distributed to each host
   by means of a Policy Exchange Protocol.  The Network Entities need to
   be authenticated in order to be trusted.  See [2] for more details.

   These hosts must respect the security policy of the network where
   they are attached.  In case of a conflict which is not automatically
   resoluble, a resolution arbitration mechanism should be established.

   The effect is simple to understand: instead of a one or a few
   firewalls, each one being a point of failure for the complete
   network(s), that could be attacked or fail, creating a bottleneck for
   all the communications, there will be a number of firewalls (at every
   host) configured according to a central policy, which increase the
   scalability, reliability, efficiency and performance of the complete
   network.

   This is often becoming possible in most of the nodes because even if
   IPsec and encryption are enforced for most of the communications,
   nodes often have powerful CPUs with unused cycles that will easily
   accommodate the extra required workload.  In case of small devices,
   they may not have those resources, and still need to rely on other
   devices for performing security functions on their behalf.




Palet, et al.            Expires August 24, 2005                [Page 5]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


   On the other hand, the central firewalls will be able to dedicate CPU
   cycles to new functions, or be able to protect bigger networks.

4.  The Host

   With IPv6 and the distributed security model the host play a crucial
   role in the network security, in other words, the security mechanisms
   are moved to each host.

   As said above the entities, in this case the hosts, should
   authenticate themselves in order to be trusted.  This will be a
   requirement of a possible solution.

4.1  Interior Security

   With this approach, the security of each host is not only towards
   communications with Internet or other networks, but also with the
   rest of the nodes in the same network.

   This means an increase in the overall security and the possibility to
   isolate individual nodes if required.

4.2  The Visiting Node

   This distributed security model is valid not only for fixed nodes,
   i.e.  desktop computers, but specially interesting and important for
   those nodes like laptops and PDAs, which keep moving among different
   networks.  Vice versa, this model is of key importance for those
   networks that receive visits from nodes that are not under the
   control of the network/security administrator.

   Different visited networks have different security requirements.
   Consequently is required that those nomadic nodes dynamically
   accommodate their own security policy to the one defined in the
   visited network and arbitrate the conflict resolution between
   different policies.

   Nodes attaching to a network via VPNs, RAS, dial-up modems or other
   similar means can also be considered as visiting nodes, as they can
   also create a path between the visited network and any other network
   where they are actually connected.  They must also be able to
   dynamically configure their own security to match the one existing in
   the visited network.

   When a node is attached to a visited network and receives the visited
   Network's security policy, basically there are two possible
   situations:




Palet, et al.            Expires August 24, 2005                [Page 6]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


   1.  The network security policy is equivalent or less restrictive
       than the node configuration.  In this case, the node could not
       change its security policy configuration or relax its
       restrictions if needed for some applications, always following
       the received security policy.  For this some degree of
       granularity in the security policy specification and enforcement
       should be given.

   2.  The network security policy is more restrictive than the actual
       node configuration.  In this case, the node will adapt its
       security configuration to at least match the one indicated by the
       security policy.

   A possible solution should take into account the case of a device
   attaching to the network and not following the security policy,
   either because it does not want to or because is not able to.

   The alternative often used today to accomplish this, is by means of
   manual changes in the configuration of the visiting node, but they
   are always prone to errors and dangerous to be considered useful and
   secure enough, specially considering that the visiting node can be
   already infected from previous connections to other non-protected
   networks (home network, hot-spot, ...).

4.3  Default Security

   The nodes can be attached to a network which doesn't offer any
   protection means, not only against external attacks, but also those
   coming from the same network, for example, in hot-spots, public
   networks, ad-hoc networks or even networks temporarily setup for
   conferences.

   The distributed security model addresses this case because the host
   will have all the necessary means to protect itself.  A Possible
   solution must take this into account and have an appropriated
   mechanism to detect the connection to a foreign network and apply the
   correspondent security policy, previously defined by the host
   security administrator.

   This security Policy applied in foreign networks and/or in case of
   not having connectivity with the Policy Enforcement Point will be
   called the Default Security Policy.

4.4  Other Considerations

   A requirement will be to offer Policy Change Facilities allowing the
   user or the host security administrator to change security settings.
   Also the switching between two or more allowed security policies



Palet, et al.            Expires August 24, 2005                [Page 7]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


   could be implemented.

5.  Security Policy Server and Protocol

   In order to achieve the benefits of the distributed security model,
   and at the same time provide the mean for the adequate and dynamic
   control of the overall network security by the network/security
   administrator, a security policy server is required.

   The policy server(s) function could replace the main functionality of
   the central firewall and complement it.  The security administrator
   will define the security rules required by all the networks and/or
   individual nodes.

   A requirement will be to have a reliable Security Policy distribution
   mechanism.  For example, the different nodes could query to the
   policy server to learn about the network security policy and adapt
   themselves in order to match it.  The policy server could also
   request information and security status to the nodes.

   Until the node performs and acknowledge the required security policy
   configuration update, it must not be allowed to transfer/receive data
   to/from other nodes either in the network or other connected
   networks.

   The security policy server can also dynamically update the security
   policy for the complete network or specific nodes.  This can be done
   in response to a security administrator decision, or other
   situations, like information received from an external or internal
   attack, detected by an intrusion detection system, firewall or even
   by nodes inside the network.

   The security policy should be administered at a network level or
   individually for every node, upon decision of the network/security
   administrator.

   A single standard Policy definicion Language and a Policy Exchange
   protocol are required for the signaling between the nodes, security
   policy servers, firewalls (including node or host firewalls),
   intrusion detections systems, honey pots, routers, and any other
   elements implicated in the overall network and nodes security.

   Following this approach, the security administrator will use a PMT
   (Policy Management Tool), to edit the policies and distribute them
   via PXP (Policy Exchange Protocols) to the PEP (Policy Enforcement
   Points), in this case the end nodes.

   For the interaction with IPsec policies, it seems appropriate the



Palet, et al.            Expires August 24, 2005                [Page 8]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


   existing IPsecCPIM [5].

   To guarantee the self-security of this model, the security policy
   being communicated to the nodes should be digitally signed, in order
   to provide integrity, origin authentication and non-repudiate
   authenticity of the source.

6.  Non-security-capable Nodes and Security Workload Distribution

   Increase in security often means increase in processing power.  Some
   nodes could not have the required CPU cycles to afford the complete
   required security policy.

   Another requirement will be to take into account this, what we will
   call non-security-capable nodes.

   The possible solution could fragment the security enforcement in
   different levels establishing a ligh set of security requirements for
   those kind of nodes.  Another alternative is that the noces could be
   partitioned from the network and treated as non-security-capable
   nodes.  Alternatively, the firewalls or even other security-capable
   nodes with free resources, could act as trusted security gateways for
   the non-security-capable nodes.

   How to address this requirement is out of the scope of this document.

   Despite the adopted solution, it seems only possible if minimum
   security verification can be done by those nodes, i.e.  digital
   signature verification.

   It could be even considered a system to provide a kind of security
   workload-balancing.

7.  Location of the Security Policy Server

   Firewalls and security gateways are expensive devices and they are
   required to sit at the border of the network.  They also require
   qualified personal to manage them.

   In the case of the distributed security model, the security policy
   server isn't required to be collocated as a border device.

   This provides the opportunity to have this device not only inside the
   network, but also at any other point in Internet.

   This opens the doors to new services and business models that provide
   very sophisticated security services, especially for Home, SOHO and
   SMEs.



Palet, et al.            Expires August 24, 2005                [Page 9]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


   Some possible "ideal" locations for the security policy servers could
   be Internet Exchanges [6] or in general PoPs, ISPs, and other similar
   central Internet locations.

8.  Security Mechanism Modules

   As said above, the security mechanism implemented could address
   several security problems by means of a number of tools.

   The basic ones should be firewall, IDS (Intrusion Detection System),
   Anti-virus and software version checker.

   These different tools could be thought as modules for both the policy
   definition and enforcement and the solution implementation.

9.  Conclusions

   In this document it was accepted that a problem will arise with the
   network-based security scheme and the deployment of IPv6.  Also the
   security scheme that was in mind during the requirements definition
   was the host-based or the distributed one [2].

   Possible solutions to addresses the requirements outlined in this
   document is out of the scope and will be defined elsewhere.

   The Distributed Security Scheme has been described as the one that
   best fits as a solution to the Security Problem Stated [2].  This
   doesn't mean that the solution must follow this scheme strictly but
   seems to be useful at least as a guideline.

   The purpose of this document is to give some abstract requirements of
   a possible solution.

   As a summary of what has been seen above, we can outline the
   following requirements:

   1.  The solution must try to address as much as possible, in the
        sense of being able to protect against different threats using a
        number of mechanisms.  The recommended ones are firewall, IDS,
        Anti-virus and software version control.

   2.  There must be a control mechanism to detect if a node is not
        following the appropriate security policy.  This allows the
        solution to be prepared to receive foreign hosts.

   3.  The solution must allow the hosts to move to other networks under
        the same security policy, under a different one or under no
        security at all.



Palet, et al.            Expires August 24, 2005               [Page 10]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


   4.  The security policy and its enforcement must be given with a
        certain degree of granularity in order to ease the different
        policies comparison and use.

   5.  A Security Policy Specification tool must be provided.  This tool
        should use a single standard Security Policy Specification
        Language.

   6.  A reliable Security Policy Distribution mechanism must be
        provided.  This mechanism should use a single standard Policy
        Exchange Protocol.

   7.  A reliable Security Policy Enforcement mechanism must be
        provided.

   8.  A reliable entity identity's authentication mechanism must be
        provided.

   9.  The solution must be dynamic in the sense of being able to
        respond to security events and adapt the policies accordingly.

   10.  Related to the previous one, a mechanism of "alarm distribution"
        is recommended, allowing the hosts to report security events to
        other hosts even in the case of, for example, problems in the
        Security Policy Server.  The idea is that a distributed system
        could be more robust than a client-server one.

   11.  The solution must ease the security administrator's work
        allowing, for example, the centralized Security Policy
        management, i.e., definition, distribution and updating.


10.  Security Considerations

   This document is concerned entirely with security.  TBD.

11.  Acknowledgements

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

12.  References

12.1  Normative References





Palet, et al.            Expires August 24, 2005               [Page 11]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


12.2  Informative References

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

   [2]  Vives, A. and J. Palet, "IPv6 Security Problem Statement",
        Internet-Draft draft-vives-v6ops-ipv6-security-ps-02, October
        2004.

   [3]  Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
        Sastry, "The COPS (Common Open Policy Service) Protocol",
        RFC 2748, January 2000.

   [4]  Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
        Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS
        Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.

   [5]  Jason, J., Rafalow, L. and E. Vyncke, "IPsec Configuration
        Policy Information Model", RFC 3585, August 2003.

   [6]  Morelli, M., "Advanced IPv6 Internet Exchange model",
        Internet-Draft draft-morelli-v6ops-ipv6-ix-00, July 2004.

   [7]  Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
        "SEcure Neighbor Discovery (SEND)",
        Internet-Draft draft-ietf-send-ndopt-06, July 2004.


Authors' Addresses

   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












Palet, et al.            Expires August 24, 2005               [Page 12]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


   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


   Gregorio Martinez
   University of Murcia (UMU)
   Campus de Espinardo s/n
   Murcia
   E-30071 - Spain

   Phone: +34 968 364 607
   Fax:   +34 968 364 151
   Email: gregorio@um.es


   Antonio F. Gomez Skarmeta
   University of Murcia (UMU)
   Campus de Espinardo s/n
   Murcia
   E-30071 - Spain

   Phone: +34 968 364 607
   Fax:   +34 968 364 151
   Email: skarmeta@um.es




















Palet, et al.            Expires August 24, 2005               [Page 13]


Internet-Draft    IPv6 Distributed Security Requirements   February 2005


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 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.


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 (2005).  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.




Palet, et al.            Expires August 24, 2005               [Page 14]


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