Internet DRAFT - draft-vives-distsec-framework
draft-vives-distsec-framework
Internet Engineering Task Force A. Vives
Internet-Draft J. Palet
Expires: February 26, 2006 Consulintel
P. Savola
CSC/FUNET
August 25, 2005
Distributed Security Framework
draft-vives-distsec-framework-00.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 February 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Over the years, it has been noticed that network firewalls are an
inadequeate mechanism in most cases for protecting the hosts,
especially from internal attacks. This document analyzes two
security paradigms, the network-based and the host-based
(distributed), and in consequence outlines a problem statement and
framework for distributed security.
Vives, et al. Expires February 26, 2006 [Page 1]
Internet-Draft Distributed Security Framework August 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Models . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Network-based . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Advantages . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Drawbacks . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Host-based . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3. Drawbacks . . . . . . . . . . . . . . . . . . . . . . 8
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
4. Framework for Distributed Security . . . . . . . . . . . . . . 10
4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Enterprise . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. Home-User . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. Public Hot-Spot . . . . . . . . . . . . . . . . . . . 14
4.3. Functions of the Elements . . . . . . . . . . . . . . . . 14
4.3.1. Policy Specification Language (PSL) . . . . . . . . . 14
4.3.2. Security Policy (SP) . . . . . . . . . . . . . . . . . 14
4.3.3. Security Status (SS) . . . . . . . . . . . . . . . . . 15
4.3.4. Security Domain (SD) . . . . . . . . . . . . . . . . . 15
4.3.5. Policy Enforcement Agent (PEA) . . . . . . . . . . . . 15
4.4. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1. Node Addition/Deletion . . . . . . . . . . . . . . . . 16
4.4.2. Authentication . . . . . . . . . . . . . . . . . . . . 17
4.4.3. Policy Exchange Protocol . . . . . . . . . . . . . . . 17
4.4.4. Data Integrity and Authenticity . . . . . . . . . . . 17
4.4.5. Moving between security domains . . . . . . . . . . . 18
5. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Vives, et al. Expires February 26, 2006 [Page 2]
Internet-Draft Distributed Security Framework August 2005
1. Introduction
There are a lot of emerging technologies that lead to scenarios where
the current security paradigms, mechanisms and practices are not
capable to protect against current threats, which have increased in
type and number. These have raised some security concerns with
regards to what will happen in a medium/short term.
Nowadays we see IP-enabled devices (laptops, PDAs, mobile phones,
etc.) moving around and connecting/roaming to/between different
networks. Another example are home automation devices with few
resources to be used for being self-protected. This comes together
with the use of peer-to-peer and GRID applications which are based on
the end-to-end paradigm. The new Internet Protocol version (IPv6)
[RFC2460] provides enough globally routable addresses and includes
IPsec [RFC2401] [RFC2406] on all stacks, easing end-to-end
communications, encrypted or not, and Mobile IP [RFC3775].
From this perspective, this document analyzes the most (currently)
used security paradigm, which from now will be referred as network-
based security scheme. The technologies used in the network-based
model are the basis for future solutions. Using these technologies
[DF] provided a new concept, the distributed firewall. Just
extending the security mechanisms used from only firewalling to a
number of them (IDS, firewalling, anti-virus, version control, etc.)
we have got the host-based security scheme, which is presented as a
possible direction to follow to solve the above-mentioned security
concerns.
In order to provide some insights about the distributed security
model some definitions and scenarios are given along with some
concrete issues analysis.
2. Security Models
The threat model for distributed security is described in a separate
document, [draft-savola-v6ops-distsec-threat-model-00.txt].
2.1. Network-based
To secure a network one or more Firewalls (FW) are used depending on
the network topology and size. The FW can perform security tasks
over the traffic that goes through/to its interfaces. The security
administrator will be in charge of putting the firewalls where it
considers and to configure them to accomplish the organization's
network security policy.
Vives, et al. Expires February 26, 2006 [Page 3]
Internet-Draft Distributed Security Framework August 2005
/-------\
/ \
| Internet |
\ /
\---+---/
|
(*) Policy Enforcement Point
+---+---+ /---\ +-------+
| | | \ / | | |
---+-----(*)+ FW1 +(*)---+----+ X +---(*)+ FW2 +(*)-----+
| | | | | / \ | | | |
+-+--+ +---+---+ +--+-+ \-+-/ +---+---+ +--+-+
| S1 | (*) | H2 | | (*) | H6 |
+----+ | +----+ | +----+ | +----+ +----+
| +--+ H3 | +--+ H4 |
+----+ | | +----+ | +----+
| H1 +--+ +-+--+
+----+ | | H5 |
+----+
Figure 1: Network-based Security
As an example we can see in Figure 1 a network with one connection to
Internet and several LANs. With this configuration the FW1 could
inspect all the traffic coming in/out from/to Internet. This means
that FW1 will be the first node that an outside attack will see. As
can be seen the security policy in enforced in all FWs interfaces.
Note that, for example, traffic between H2 and H3 or between H4 and
H5 is not noticed by any FW.
This is the most used scheme, where the security of a host depends on
the point of the network it is connected to, i.e., depends on the
topology of the network.
The complexity of the security infrastructure will be proportional to
the size of the network and the decisions taken by the security
administrator who will decide the number and type of FWs. There are
mechanisms to propagate the configuration among different firewalls,
from the same manufacturer and for big appliances, in order to
simplify the administration in case of large networks.
2.1.1. Assumptions
This model is based on the following assumptions to work properly:
o The threats come from "outside" the protected network, basically
the Internet.
Vives, et al. Expires February 26, 2006 [Page 4]
Internet-Draft Distributed Security Framework August 2005
o Everybody from the same LAN segment is trusted.
o The protected nodes won't go "outside" the protected network where
the security infrastructure 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., potentially all ports on all
hosts).
o The security policy could be applied in one or more of the
following levels: network, transport and application.
2.1.2. Advantages
The advantages of this model are:
o It is a mature technology which have been used for a long time.
o Its simplicity and easiness as the elements and points of
configuration are reduced to the minimum.
2.1.3. Drawbacks
The drawbacks of this model are:
o This is a firewall-dependant model, i.e., if a FW fails, then all
the networks connected to it will lose network connectivity unless
specific fail-over techniques are applied.
o A big percentage of the threats come from inside the protected
network. To protect all the inter-LAN communications in a large
network the number and cost of the needed FWs could be too much.
In any case the hosts are not protected within its own LAN
segment.
o The most dangerous threats, in the sense that one may not be able
to protect from them, come from inside the protected network.
o The FW usually acts as NAT and/or proxy box, interfering or even
disallowing end-to-end communications. In complex configurations,
even more than one level of NAT/proxy could appear.
o Transport mode secured communications (using IPsec ESP for
example) need special solutions (e.g., [MIDCOM]).
Vives, et al. Expires February 26, 2006 [Page 5]
Internet-Draft Distributed Security Framework August 2005
o The same security policy may be enforced for all the nodes of each
network connected to the FW, but it is also possible to have
separate policies for all hosts. In any case, an error in a FW
will equally expose all hosts on networks connected to that FW.
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 deployment of innovative
applications.
2.2. Host-based
We will call Host-based security model an evolution of the concept of
distributed firewall already introduced by [DF]. It is based on the
idea of enforcing the security policy in each network host from a
central control point.
The biggest challenge is trusting that the hosts comply to the rules
they've received, for example that the user can't just disable the
firewall if (s)he dislike the policy. Of course, this only can
happen in the case (s)he has administrative rights for that (often
not the case in non-personal systems, those not owned by the end-
user, such as corporate PCs or laptops). It seems that one or more
network entities would have to keep watch over the hosts in order to
detect if they are not following the received policy.
From a security point of view this model somehow eases the work to
the "enemies", putting the Policy Enforcement Point in their hands.
So, not only mechanisms to prevent direct attacks to the security
solution must be developed but mechanisms to minimize the
consequences as well.
Vives, et al. Expires February 26, 2006 [Page 6]
Internet-Draft Distributed Security Framework August 2005
/-------\
/ \
| Internet |
+------+ \ /
|Secur.| \---+---/
|Policy| |
+--+---+ |
(*) /-+-\
| | \ / | LAN-3
-+---+------+ x +-------+--
LAN-1(*) | / \ | (*) Policy Enforcement Point
+--+-+ \-+-/ +-+--+
| H1 | | LAN-2 | H3 |
+----+ | +----+
(*)
+--+-+
| H2 |
+----+
Figure 2: Host-based Security
2.2.1. Assumptions
This model is based on the following assumptions:
o Each host can be uniquely and securely identified.
o The security policy could be applied in one or more of the
following levels: network, transport and application.
o Threats come from anywhere in the network.
o "Outside" hosts may be able to access all hosts "Inside",
depending on the policies.
o No assumptions are made about where the host can be connected.
2.2.2. Advantages
The advantages of this model are:
o The flexibility in the definition of security policies, as it is
based on the assumption of an available Policy Specification
Language which can be used for high-level definitions of all the
needed policies.
Vives, et al. Expires February 26, 2006 [Page 7]
Internet-Draft Distributed Security Framework August 2005
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, it could allow mail traffic to only one application
on the system.
o Enables the usage of end-to-end applications level security (e.g.,
web services security standards).
o Enables better protection from attacks by the "internal" users,
and possibly even to a degree from those in the local segment.
For example address spoofing can be detected and avoided coming
from the same LAN segment, without router participation, because a
host in a LAN can detect packets from other host with source
addresses that are not used in that LAN.
o Can protect a host independent of the topology, i.e., wherever the
host is connected.
o Does not need specific devices to secure a host. Consider the
case of a single host with a CPE (Customer Premises Equipment), if
the CPE has no (user-controllable) firewall functions.
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 in a distributed or centralized fashion.
o It maintains the centralized control of the security policies,
from where they are distributed to each host (central decisions,
local enforcement), despite the size of the network to protect.
In general it scales well.
o It enables new distributed and cooperative solutions to improve
the network security.
o This model address the case of trusted nodes that are secured
enough for having less restrictions than the applied policy has.
This kind of flexibility could be useful for both allowing a
trusted node to have more freedom or for restricting non-trusted
nodes even more.
2.2.3. Drawbacks
The drawbacks of this model are:
Vives, et al. Expires February 26, 2006 [Page 8]
Internet-Draft Distributed Security Framework August 2005
o It is more complex than the Network-based one as more elements are
needed, some of them need to be defined or even designed.
o The uniqueness and secured identification of hosts is not trivial
(for example, [DF] proposes the use of certificates).
o The hosts must be trusted (or designed appropriately) so that they
will operate according to the policy. For example, it must be
impossible to disable the firewall functions or if the policy is
not followed network communication is not allowed.
o A host that becomes compromised or infected with a worm or virus
in any case can't be trusted to operate according to the policies,
as the worms/viruses probably first create holes or disable the
protections if they can.
o It may be challenging to design the system so that policy updates
are made available to the nodes which may not be network-reachable
all the time.
o It may be difficult to distinguish a misbehaving application from
a legitimate application (for example, many email worms may be
channeled through the MUA which must be authorized to send the
mails to operate correctly).
o Because of having a centralized Policy Decision Point (PDP) from
where the Security Policies are distributed a weakness is
introduced in form of a central point of failure unless more
complexity is added, for example with a distributed/replicated
system.
o The host security is in some sense 'server-dependant'. It must be
able to detect the lost of connectivity with the PDP and act in
consequence. It also seems that being disconnected from the PDP
for a long period could be dangerous because updated security
information raise the security level.
3. Problem Statement
The threats that the network firewalls, over 10 years ago, intended
to protect against have evolved. In particular, worms and viruses
exploiting vulnerabilities have become commonplace, and often also
spread in the internal networks. Spyware, adware, turning into spam
or DDoS zombies have also emerged. Further, new drivers such as IPv6
deployment, peer-to-peer, mobile IP or GRID, all call for new
paradigms. It is clear that perimeter-based security is
insufficient.
Vives, et al. Expires February 26, 2006 [Page 9]
Internet-Draft Distributed Security Framework August 2005
Various different software pieces have been installed on both the
servers (anti-spam and anti-virus) and the user hosts (software
version control, anti-virus and anti-spyware) to mitigate these
issues. The trends seems to be to direct the attacks against user
hosts, the relevance of attacks directed at servers are decreasing.
We propose a distributed security framework, where hosts use the
techniques such as those applied today (host firewalls, anti-virus,
etc.), but in closer coordination with the network security
components. A number of proprietary implementations of this model
already exist, and the goal is to survey and standardize the
mechanism for policy distribution and communication across the
network.
The distributed security framework presents the following advantages:
1. It assumes end-to-end connectivity of all nodes, so the end-to-
end communications are the natural way of doing things.
2. As the security rules could be applied before encrypting the
payload, the encryption does not affect the security mechanism
which could work in a straightforward way.
3. Nodes will be protected wherever they are as always will have
security mechanisms on the hosts. It should be taken into
account that the security policy update must be done as
frequently as possible.
4. Framework for Distributed Security
4.1. Definitions
To describe the distributed security model several terms will be
used. They are defined here as follows:
o SD (Security Domain): Network portion under the administration of
the same Security Administrator/Organization.
o SP (Security Policy): We refer to the information that is
distributed to each policy enforcement point within a SD in order
to achieve the desired level of security. This information will
follow the whole protected network security policy defined by the
Security Administrator of that network. This information will be
converted to specific rules for each platform by the Policy
Enforcement Agent.
Vives, et al. Expires February 26, 2006 [Page 10]
Internet-Draft Distributed Security Framework August 2005
o SS (Security Status): Information about host different aspects
that could be used to measure how secure it is.
o PSL (Policy Specification Language): Language used to define SP
and SS.
o PDP (Policy Decision Point): The node where the SPs for a SD are
defined. From the PDP the SPs are distributed to PEPs.
o PEP (Policy Enforcement Point): The place where a SP is applied.
o PEA (Policy Enforcement Agent): The entity in charge of applying
the SP at the PEP.
o PXP (Policy Exchange Protocol): The protocol used for distribution
of the SP to the PEA.
/-------\
/ \
( Internet )
\ /
+-----+ \---+---/
| PDP | |
+--+--+ (*)
(*) /--+--\
| | \ / | LAN-3
-+---+---(*)+ PEA4 +(*)----+--
LAN-1 (*) | / \ | (*)
+--+-+ \--+--/ +-+--+
|PEA1| (*) |PEA3|
+----+ | +----+
|
|
(*) LAN-2
+--+-+
|PEA2| (*) Policy Enforcement Point
+----+
Figure 3: Definitions: Basic Scheme
The basic idea is simple: the Security Policy is centrally defined
using the Policy Specification Language and distributed to each
Policy Enforcement Agent by means of the Policy Exchange Protocol.
The PEA will apply the SP to each Policy Enforcement Point it is
responsible for. The network entities need to be authenticated in
Vives, et al. Expires February 26, 2006 [Page 11]
Internet-Draft Distributed Security Framework August 2005
order to be trusted, for example to allow an incoming connection or
to trust on the received Security Policy.
4.2. Scenarios
In order to gain some insights in the distributed security analysis
some scenarios are depicted to be considered when drawbacks and
advantages are outlined.
The idea is to address some general scenarios which already exist and
where new technologies, devices, users and behaviors take place. For
example the deployment of the new Internet Protocol, IPv6, the use of
P2P and GRID applications and new nomadic IP devices could be seen as
some of the issues that bring new security scenarios that should be
analyzed.
One important issue that must be taken into account is the movement
of a host between different scenarios/networks. This point will be
addressed in section 4.4.5 of this document.
Basically three possible scenarios have to be addressed, all of them
interconnected through Internet:
o Enterprise.
o ISP-Client.
o Public.
Vives, et al. Expires February 26, 2006 [Page 12]
Internet-Draft Distributed Security Framework August 2005
/\ /-------------------------\ \ /
/ \ / INTERNET \ \/
/ \ / /-\ \ +--+ +---+
*---------* / | X +-|---|AP| ))) |PEA|
| | | /--------\ \-/ | +--+ +---+
| +---+| | | /-\ ISP| | Public
| |PEA++-|--+-+ X | | | Hot-Spot
|+-+ +---+| | | \+/ | |
|| | | | | | | |
++-+------+ | | +-+-+ | /--------\ |
Home-User | | |PDP| | | /-\ ISP| |
| \+---+---/ | | X | | |
| | \+/ | /
\ | | | /
\ \---+----/ /
\------------------+-----/
|
/-\ Enterprise
-+-----+ X +-----+-
| \+/ |
+-+-+ | +-+-+
|PEA| +-+-+ |PEA|
+---+ |PDP| +---+
+---+
Figure 4: Scenarios
4.2.1. Enterprise
This scenario considers the case of an organization with its own
infrastructure containing both PDP(s) and PEP(s). This means that
all the security infrastructure elements will be within the
organization premises under the same administration.
All the hosts connected to the protected network will also be
administered by the above-mentioned administration. So, it is highly
probable that they use some kind of distributed security software
that would collaborate to increase the security.
4.2.2. Home-User
This scenario considers the case of an Residential Customer which has
its PEP as part of the security solution. The user has several
choices as PDP. The user could even not have a PDP and define by
himself the Security Policy. Also could use one provided as a paid
service from a company located somewhere in Internet. The ISP could
also offer a PDP service for its customers.
Vives, et al. Expires February 26, 2006 [Page 13]
Internet-Draft Distributed Security Framework August 2005
In case of a user connecting to his/her enterprise VPN the PDP used
should be the one from that network. Even in the case of not using a
VPN the PDP could be the one from the user company.
Other hosts in the same network will be in charge of the Home-User,
so they could use some kind of distributed security software that
would collaborate to increase the security.
4.2.3. Public Hot-Spot
This scenario considers the case of the host being connected to a
pubic Internet connection (not neccesarily only the case of a Wi-Fi
Hot-Spot). In this case the PEP will be located at the host but
could not be sure to trust/have connectivity to a foreign PDP.
Other hosts in the same network can not be trusted at all to be using
some kind of distributed security software that would collaborate to
increase the security.
4.3. Functions of the Elements
4.3.1. Policy Specification Language (PSL)
The host-based model is based on the assumption of the use of a
number of security mechanisms, for example firewall, IDS, anti-virus
and software version control.
This requirement means that the PSL must be flexible enough to
specify the information about different objects and rules to behave
depending on the value of that information.
Also the PSL must be able to specify security policies for new
mechanism that could be added or appear in the future.
The flexibility in the PSL will allow the coordinated use of the
different security mechanisms by the PEA. For example it could be
defined that if the version of the mail user agent is not a safe one
(version control security mechanism) the mail traffic is not allowed
(firewall security mechanism).
The syntax and semantics of the PSL must be clearly defined in a
standard way.
4.3.2. Security Policy (SP)
Thanks to the flexibility of the PSL the SP will include all the
needed rules to follow the Security Administrator needs.
Vives, et al. Expires February 26, 2006 [Page 14]
Internet-Draft Distributed Security Framework August 2005
The security policy should have rules to define configuration for all
the security mechanisms used, based on the Security Status of the
host.
The SP could be specified with different granularity and using
conditional statements.
Granularity refers to the ability of referencing, at each layer, to
all the possible elements. For example, TCP/UDP ports or any IP
header element�s value. It is a matter of the implementation
to reach a compromise between granularity and complexity.
Conditional statements refers to the ability of taking decisions
based on the values of different elements, as detailed as the
granularity allows. Even different complete sets of rules could be
defined for different situations, like changing to a different SD
(see Scenarios section above). For example, in case of the change of
a value the PEA could already have a rule on the received SP for the
new value, avoiding the need of communicating it to the PDP, which
would have to define a new SP and send it to the PEA.
The SP also will be used to manage the update of elements in the host
in order to increase the security, for example, a new anti-virus
signature file or a new patched version of a piece of software with a
known security breach.
4.3.3. Security Status (SS)
Security Status is the list of the defined properties of the system,
to be used for checking the conformance to the Security Policy. For
example: "firefox", "1.0.2"; where the security policy might mandate
that version 1.0.3 would be required.
4.3.4. Security Domain (SD)
The concept of Security Domain is of capital importance in order to
clarify where a SP must be applied. Also the concept of changing
from one SD to another one is important and will be addressed leter
in this document in detail.
A host that connects to a SD must accept the SP it receives and apply
it. In case of not following this rule the host could not be sure to
have network connectivity. It is matter of the security solution how
to manage the hosts that don't apply the received policy.
4.3.5. Policy Enforcement Agent (PEA)
The PEA will have a key role in the whole system as it will be the
Vives, et al. Expires February 26, 2006 [Page 15]
Internet-Draft Distributed Security Framework August 2005
one in charge of assuring that the received SP is applied. To
accomplish this task several issues must be addressed:
o Verification of Authenticity and integrity of the received SP.
o Verification of the Security Status (SS) of the PEP.
o Comparison between the SS and the received SP and application of
the specified rules depending on the comparison results.
o Running the different security mechanisms.
o Being able to communicate with other PEAs in order to allow
distributed security mechanisms.
o Being proactive in order to detect and respond to any security
event.
4.4. Issues
4.4.1. Node Addition/Deletion
We refer to addition to both:
o The process of configuring a totally new node, installing the PEA
and its first message exchange with the PDP or other PEAs.
o The addition of a node to the process launched when a node that
has been off-line get reconnected again and tries to communicate
with one PDP to get the last available SP.
This dual approach applies also for the deletion process.
During the process of a node addition the host must be able to find
the correct PDP which should authenticate itself as must do the host
as well. It should be taken into account the case of a fake PDP
attack.
The solution must support the addition and deletion of hosts from the
SD dynamically with no degradation of the functionality and
performance.
When a new node is connected to the SD network it should follow the
required steps in order to be authenticated and configured following
the appropriated SP.
It will be a matter of the solution to assure that the hosts are
following the received SP during the time they are connected to the
Vives, et al. Expires February 26, 2006 [Page 16]
Internet-Draft Distributed Security Framework August 2005
SD network.
4.4.2. Authentication
It is required that new hosts connected to the network demonstrate
their identity for both receiving a useful SP and to communicate with
other hosts within the same SD.
This way, a host needs to authenticate itself first. After that, the
host may or may not be authorized to have connectivity with other
networks through a switch/router or to be able to communicate with
other hosts.
As a guideline, cryptographic certificates could be used for this
purpose, in order to guarantee the identity of the sender of a
message. As the identity will be used within the SD a SD-wide PKI
could be used.
4.4.3. Policy Exchange Protocol
The PXP is in charge of the distribution of the corresponding SP(s)
to the PEAs. This protocol should assure the delivery and update of
the SP even in the case of possible problems, like the chance of a
PDP failure or some kind of unreachability, for example in case of
network segmentation.
Also either the PEA or the PDP could launch an event that results in
a SP update or change. The PDP will update the SP in case of new
security information is received for one or more of the used security
mechanisms. The PEA could also inform the PDP of a new Security
Status because of some change in the PEP configuration. Based in
this new status the PDP could update the SP.
There could be some active mechanisms, like IDS, that could lead to
some SP change.
4.4.4. Data Integrity and Authenticity
There are several pieces of information that will be passed among
entities within the security solution that would be a good target for
an attack. This information should be protected both while stored in
a host and while transmitted from one host to another.
As a guideline, cryptographic certificates could be used for this
purpose, in order to guarantee the integrity and origin of the
information. As the identity will be used within the SD a SD-wide
PKI could be used.
Vives, et al. Expires February 26, 2006 [Page 17]
Internet-Draft Distributed Security Framework August 2005
4.4.5. Moving between security domains
As have been seen above a host, with its PEA, could move between
different SD or between different scenarios, some of them with no
security guarantees at all and no PDP available.
If all network devices are globally reachable there will be no
problem on reaching other hosts belonging to the same security
solution cluster, including the PDP, which could be inside the
corporate network.
The solution must be able to manage this situation both being able to
detect a network/SD change and responding in consequence, for example
establishing a default SP in foreign networks (presumably a
restrictive SP).
5. 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 information collector.
6. Conclusions
New technologies (IPv6, P2P, GRID, Mobile IP, etc.), behaviors (use
of small devices like PDAs and moving to different networks) and
threats (Virus, spam, spyware, adware, etc.) require improving the
security mechanisms actually being used. By one side the integration
of different mechanisms and by other side the movement of the
security policy enforcement point towards the hosts interfaces are
recommended in order to improve the security of the hosts and in
consequence of the network.
Also a centralized control over the policy definition and enforcement
is of importance in order to have a scalable solution.
The network-based security model has problems addressing the new
technologies and threats. The host-based model has been described as
a reference for a possible solution. The latter model is presented
as complementary to the former one.
Vives, et al. Expires February 26, 2006 [Page 18]
Internet-Draft Distributed Security Framework August 2005
7. IANA Considerations
This document does not require any IANA action.
8. Security Considerations
This document is concerned entirely with security.
9. Acknowledgements
The authors would like to acknowledge the inputs of Brian Carpenter,
Satoshi Kondo, Shinsuke Suzuki, Peter Bieringer and the European
Commission support in the co-funding of the Euro6IX project, where
this work is being developed.
10. References
10.1. Normative References
10.2. Informative References
[DF] Bellovin, S., "Distributed Firewalls", November 1999,
<http://www.research.att.com/~smb/papers/distfw.pdf>.
[MIDCOM] "IETF midcom WG",
<http://www.ietf.org/html.charters/midcom-charter.html>.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Vives, et al. Expires February 26, 2006 [Page 19]
Internet-Draft Distributed Security Framework August 2005
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
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
Pekka Savola
CSC/FUNET
Espoo
Finland
Email: psavola@funet.fi
Vives, et al. Expires February 26, 2006 [Page 20]
Internet-Draft Distributed Security Framework August 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.
Vives, et al. Expires February 26, 2006 [Page 21]
