Internet Engineering Task Force A. Vives
Internet-Draft J. Palet
Expires: January 12, 2006 Consulintel
P. Savola
CSC/FUNET
July 11, 2005
Distributed Security Framework
draft-vives-v6ops-distributed-security-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 January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Current Internet trends in several fields have brought some security
concerns with regards to what will happen with the current security
paradigms and mechanisms.
This document analyzes two security paradigms, the network-based and
the host-based. The former refers to what is being used nowadays out
Vives, et al. Expires January 12, 2006 [Page 1]
Internet-Draft Distributed Security Framework July 2005
there and the latter is based on the distributed firewall concept
[2].
From the point of view of these security concerns it is stated that
there is a problem that must be addressed.
Some insights are given with respect to the host-based security
paradigm.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Models . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Network-based . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Host-based . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
4. Framework for Distributed Security . . . . . . . . . . . . . . 11
4.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Enterprise . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2 Home-User . . . . . . . . . . . . . . . . . . . . . . 14
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) . . . . . . . . . . . . . . . . . 15
4.3.3 Security Status (SS) . . . . . . . . . . . . . . . . . 15
4.3.4 Security Domain (SD) . . . . . . . . . . . . . . . . . 16
4.3.5 Policy Enforcement Agent (PEA) . . . . . . . . . . . . 16
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 . . . . . . . . . . . 18
4.4.5 Moving between security domains . . . . . . . . . . . 18
5. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1 Normative References . . . . . . . . . . . . . . . . . . . 19
9.2 Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
Vives, et al. Expires January 12, 2006 [Page 2]
Internet-Draft Distributed Security Framework July 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
regard to what will happen in a medium/short term.
Nowadays we are seeing how IP-enabled devices are more common each
day, so we don�t just see laptops but also PDAs and mobile
phones walking around and connecting/roaming to/between different
networks. This comes together with the use of P2P and GRID
applications which are based on the end-to-end paradigm.
In line with the end-to-end paradigm is the new Internet Protocol
version (IPv6) [3] because of the provision of enough globally
routable addresses as required. For example Mobile IP needs several
addresses for each moving host [4].
IPv6 also adds the availability of IPsec [5] [7] in the stack, what
could be used for end-to-end encrypted communications, with all the
problems that this imply to the security infrastructures currently
deployed.
Another kind of IP devices that are appearing are home automation
devices which have its own IP stack and applications but few
computing resources. These devices are susceptible of being
compromised and used for malicious things but have almost no
resources to be used for being self-protected.
From this perspective, this document analyzes the most (currently)
used security paradigm, which from now will be referred as network-
based security scheme. The objective is to identify its drawbacks
and advantages against the new foreseen scenarios.
Based on the distributed firewall concept [2] we introduce the host-
based security scheme, which extends the security mechanisms used
from only firewalling to a number of them (IDS, firewalling, anti-
virus, version control, etc.). Not only its drawbacks and advantages
against the new foreseen scenarios are identified but also it is
presented as a possible direction to follow to solve the above-
mentioned security concerns.
Once these two security models are described we state that a security
problem will arise if no new techniques are used to address the
coming technologies.
In order to provide some insights about the distributed security
Vives, et al. Expires January 12, 2006 [Page 3]
Internet-Draft Distributed Security Framework July 2005
model some definitions and scenarios are given along with some
concrete issues analysis.
2. Security Models
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&#
65533;s network security policy.
/-------\
/ \
| Internet |
\ /
\---+---/
|
(*) Policy Enforcement Point
+---+---+ /---\ +-------+
| | | \ / | | |
---+-----(*)+ FW1 +(*)---+----+ X +---(*)+ FW2 +(*)-----+-----+--
| | | | | / \ | | | | |
+-+--+ +---+---+ +--+-+ \-+-/ +---+---+ +--+-+ +-+--+
| S1 | (*) | H2 | | (*) | H5 | | H6 |
+----+ | +----+ | +----+ | +----+ +----+ +----+
| +--+ H3 | +--+ H4 |
+----+ | | +----+ | +----+
| H1 +--+
+----+ |
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 H5 and
H6 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.
Vives, et al. Expires January 12, 2006 [Page 4]
Internet-Draft Distributed Security Framework July 2005
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.
This model is based on the following assumptions to work properly:
o The threats come from "outside" the protected network, basically
the Internet.
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.
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.
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 loose 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.
Vives, et al. Expires January 12, 2006 [Page 5]
Internet-Draft Distributed Security Framework July 2005
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 ([1]).
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 [2]. 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 January 12, 2006 [Page 6]
Internet-Draft Distributed Security Framework July 2005
/-------\
/ \
| Internet |
+------+ \ /
|Secur.| \---+---/
|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 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.
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.
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.
Vives, et al. Expires January 12, 2006 [Page 7]
Internet-Draft Distributed Security Framework July 2005
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.
The drawbacks of this model are:
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, [2] 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
Vives, et al. Expires January 12, 2006 [Page 8]
Internet-Draft Distributed Security Framework July 2005
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 starting points are the new technologies we mentioned above and
the network-based security model. We will demonstrate that things
like IPv6 deployment or P2P applications impose a problem to the most
common security models.
Finally we will outline how the host-based security model is able to
address a number of those problems.
Not only new technologies but also new threats have appeared that use
security holes in the software. Viruses, spyware, adware, spam,
worms and (D)DoS attacks have made necessary to use several security
tools to fight these threats. This is the reason of the appearance
of different software pieces that are installed on both the servers
(anti-spam and anti-virus) and the user hosts (software version
control, anti-virus and anti-spyware). The trend seems to be to
direct the attacks against user hosts, the attacks directed to
servers are decreasing.
We can summarize the consequences of the appearance of new
technologies (IPv6, P2P, GRID, mobile IP, etc.), new behaviors and
new threats as:
Vives, et al. Expires January 12, 2006 [Page 9]
Internet-Draft Distributed Security Framework July 2005
1. The need/use of end-to-end communications.
2. The availability/use of IPsec on all IP devices. For example,
all IPv6 stacks have IPsec capability that can be used if
required.
3. Nomadic IP devices that will move between different networks
under different security administration.
4. A number of different security mechanisms are needed in order to
protect a network/host.
The network-based security model has problems addressing the above
points. This can be summarized in:
1. It difficults/avoids end-to-end communications because of the FWs
acting as NAT and/or proxy.
2. Transport mode secured communications (using IPsec ESP for
example) need special solutions ([1]). The basic idea is that
the encrypted payload can�'t be inspected.
3. It is not able to protect nomadic nodes that move out of the
protected network. In foreign network the nodes are exposed to
threats and can be infected when they come back to their "home"
network.
In the other hand the host-based security model could address the
following points from the above-mentioned:
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 encrypting 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.
In any case it should be clearly stated that the network-based
security model is a mature technology which have been used for a long
time. The host-based security model is basically just this, a model,
and several issues must be solved before it takes place.
Security improvements in both the network-based and the host-based
Vives, et al. Expires January 12, 2006 [Page 10]
Internet-Draft Distributed Security Framework July 2005
security models are required, for example to be able to cope with all
the actual security threats. The idea is to try to integrate in a
unique solution as much mechanisms as possible, and tune them to
follow the security policy within a protected network and its hosts,
in case they move to a foreign network.
Following this idea a hybrid model could be used where both the
network-based and host-based models are used. The tasks could be
distributed among both or be activated depending of where the host is
connected to, if there is a security alert situation, etc.
Insights over the problems that host-based security model must
resolve before being deployed in real life are outlined in following
sections.
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.
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.
Vives, et al. Expires January 12, 2006 [Page 11]
Internet-Draft Distributed Security Framework July 2005
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
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
Vives, et al. Expires January 12, 2006 [Page 12]
Internet-Draft Distributed Security Framework July 2005
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.
/\ /-------------------------\ \ /
/ \ / 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
Vives, et al. Expires January 12, 2006 [Page 13]
Internet-Draft Distributed Security Framework July 2005
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.
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.
Vives, et al. Expires January 12, 2006 [Page 14]
Internet-Draft Distributed Security Framework July 2005
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.
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
Vives, et al. Expires January 12, 2006 [Page 15]
Internet-Draft Distributed Security Framework July 2005
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
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.
Vives, et al. Expires January 12, 2006 [Page 16]
Internet-Draft Distributed Security Framework July 2005
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.
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
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.
Vives, et al. Expires January 12, 2006 [Page 17]
Internet-Draft Distributed Security Framework July 2005
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.
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
Vives, et al. Expires January 12, 2006 [Page 18]
Internet-Draft Distributed Security Framework July 2005
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.
7. Security Considerations
This document is concerned entirely with security.
8. 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.
9. References
9.1 Normative References
9.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] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
Vives, et al. Expires January 12, 2006 [Page 19]
Internet-Draft Distributed Security Framework July 2005
November 1998.
[7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 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
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 January 12, 2006 [Page 20]
Internet-Draft Distributed Security Framework July 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 January 12, 2006 [Page 21]