Internet Engineering Task Force J. Palet
Internet-Draft A. Vives
Expires: January 17, 2005 Consulintel
G. Martinez
A. Gomez
University of Murcia (UMU)
July 19, 2004
IPv6 Distributed Security Requirements
draft-palet-v6ops-ipv6security-01.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 January 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
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 January 17, 2005 [Page 1]
Internet-Draft IPv6 Distributed Security Requirements July 2004
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Definition . . . . . . . . . . . . . . . . . . . . 3
3. Distributed Security Model . . . . . . . . . . . . . . . . . 4
4. Interior Security . . . . . . . . . . . . . . . . . . . . . 5
5. The Visiting Node . . . . . . . . . . . . . . . . . . . . . 5
6. Default Security . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Policy Server and Protocol . . . . . . . . . . . . 6
8. Single versus Multiple Points of Attack . . . . . . . . . . 8
9. Non-security-capable Nodes and Security Workload
Distribution . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Location of the Security Policy Server . . . . . . . . . . . 9
11. Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
13. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 10
14. Security Considerations . . . . . . . . . . . . . . . . . . 11
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
16.1 Normative References . . . . . . . . . . . . . . . . . . . 11
16.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . 13
Palet, et al. Expires January 17, 2005 [Page 2]
Internet-Draft IPv6 Distributed Security Requirements July 2004
1. Introduction
The 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 not work in all the situations, as
they don't consider the internal threads.
Additionally, the firewall 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.
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, is also true and perfectly understandable that
there is a need to enforce security in the networks, in such way that
the security (or network) 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 January 17, 2005 [Page 3]
Internet-Draft IPv6 Distributed Security Requirements July 2004
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 will 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
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 network/security administrator hands, while the individual
nodes can take advantage of end-to-end and secure end-to-end
communications.
This can be achieved with a distributed or host-based model replacing
the current network-based one.
The distributed security model implies the use of node or host
firewalls and the usage of end-to-end application level security
(i.e., Web Services security standards).
Other security functions, like Intrusion Detection, could also be
distributed in a similar fashion.
These node or host firewalls 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 single firewall, a
single point of failure for the complete network, or a set of them,
that could be easily attacked or fail, and create a single bottleneck
for all the communications, there will be a number of firewalls (at
every host), configured according 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,
Palet, et al. Expires January 17, 2005 [Page 4]
Internet-Draft IPv6 Distributed Security Requirements July 2004
they may not have those resources, and still need to rely on other
devices for performing security functions on their behalf.
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. Interior Security
With this approach, the security of each node 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.
5. 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 the
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
then visited network.
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 no 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, ...).
Palet, et al. Expires January 17, 2005 [Page 5]
Internet-Draft IPv6 Distributed Security Requirements July 2004
6. Default Security
Implementing IPsec in the IPv6 stack of the nodes is only a first
step for a sophisticated security model.
However, a more complete approach is required. These 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.
This is the common case, for example, in hot-spots, public networks,
ad-hoc networks or even networks temporarily setup for conferences.
In order to keep the appropriate security level, each node should
incorporate a kind of node or host firewall.
The node or host firewall must be configured by default with a very
restrictive set of rules. At this way, the node is self-defended, in
any circumstance.
The node or host firewall must act as a policy enforcer.
The node or host firewall should offer a simple user interface to
facilitate to relax the security restrictions, if required by certain
applications or services, assuming the lack of expertise of the user.
In case the device (i.e. laptop), belongs to an enterprise or
similar network, which has its own security policy, it can be
enforced to certain degree of protection, even when not attached to
the network.
7. 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
dynamically 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 network/security
administrator will define the security rules required by all the
networks and/or individual nodes.
The different nodes should 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.
Palet, et al. Expires January 17, 2005 [Page 6]
Internet-Draft IPv6 Distributed Security Requirements July 2004
When a node is attached to a visited network and receives the visited
network security policy, basically there are two possible situations:
1. The network security policy is equivalent or less restrictive
than the node configuration. In this case, the node will not
change its security policy configuration. What happens if the
new network policy is less restrictive and for example enables a
videoconferencing system that was not available in the "default
home network" ?. TBD.
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.
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 network/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 language or protocol 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, is required.
For simplicity, the policy server could be integrated in the border
router, firewall, or other network elements (AAA, DHCP, COPS, ...).
A candidate approach is to align this with the existing COPS [3] and
COPS-PR [4] standards.
Following this approach, the network/security administrator will use
a PMT (Policy Management Tool), to edit the policies and distribute
them via PMP (Policy Decision Points) to the PEP (Policy Enforcement
Points), in this case the end nodes.
Palet, et al. Expires January 17, 2005 [Page 7]
Internet-Draft IPv6 Distributed Security Requirements July 2004
For the interaction with IPsec policies, it seems appropriate the
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.
8. Single versus Multiple Points of Attack
The single security gateway approach is a single point of failure and
consequently a bottleneck.
At the same time, is easier to attack a single device, so the
possibilities of a security threat are higher.
On the other hand, the distributed approach reduces the risk of a
single point of failure and increases the difficulties for potential
attackers to succeed (port scanning is more difficult).
The failure of the central firewall could completely disconnect the
network from Internet or other networks.
In the case of a central policy server failure, the nodes should be
configured by the security policy in such way that they continue
working, keeping the same trusted security restrictions previously
imposed by the policy server. In case of a major breach, the
security policy could had been configured in order to partition every
node, or to temporarily use the default perimeter firewall. TBD.
How about a compromised host that pretends to conform to the central
policy but is actually a hacker heaven? TBD.
9. 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.
These nodes could be partitioned from the network as a simple
solution, 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.
This seems only possible if minimum security verification can be done
by those nodes, i.e. digital signature verification.
Palet, et al. Expires January 17, 2005 [Page 8]
Internet-Draft IPv6 Distributed Security Requirements July 2004
It could be even considered a system to provide a kind of security
workload-balancing.
Some work is still required to define if the security level that can
be achieved by those nodes is good enough, and to avoid possible
attacks.
This section needs to be completed in further revisions of this
document. TBD.
10. 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.
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.
11. Virus
As part of the services offered by the distributed security model, it
could offer means to alleviate the effects of virus.
To be completed in next versions of the document. TBD.
12. Spam
One more possible service of the distributed security model solution,
could be the protection against spam.
This could mean for example, extensions to protocols as SMTP, etc.
To be completed in next versions of the document. TBD.
Palet, et al. Expires January 17, 2005 [Page 9]
Internet-Draft IPv6 Distributed Security Requirements July 2004
13. Conclusions
Towards achieving an IPv6 distributed security solution, the
following requirements should be taken into account:
1. Dynamic security policy specification language, exchange protocol
and server.
2. Authentication of entities.
3. Support of SEND protocol ([7]).
4. Support for unmanaged nodes/devices.
5. Control and node/network partition mechanism, to ensure the
securization of the rest of the network in case of a thread, even
if internal.
6. Alert/notification mechanism to facilitate the inter-node and/or
node-policy server communication.
7. Node or host firewall, with a secure enough default
configuration, that can be updated by a trusted dynamic security
policy server. The node or host firewall should also include
functionalities such as:
1. Integral thread protection.
2. Resolution and arbitration of conflicts between different
security policies.
3. Support for end-to-end application level security (i.e., Web
Services security standards).
4. Intrusion detection.
5. Collection of audit information.
8. Optionally it could also include:
1. Anti-virus.
2. Anti-spam.
TBD.
Palet, et al. Expires January 17, 2005 [Page 10]
Internet-Draft IPv6 Distributed Security Requirements July 2004
14. Security Considerations
This document is concerned entirely with security. TBD.
15. 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.
16. References
16.1 Normative References
16.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",
draft-vives-v6ops-ipv6-security-ps-00 (work in progress), April
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",
draft-morelli-v6ops-ipv6-ix-00 (work in progress), July 2004.
[7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05
(work in progress), April 2004.
Palet, et al. Expires January 17, 2005 [Page 11]
Internet-Draft IPv6 Distributed Security Requirements 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
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 January 17, 2005 [Page 12]
Internet-Draft IPv6 Distributed Security Requirements July 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 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 (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.
Palet, et al. Expires January 17, 2005 [Page 13]