One document matched: draft-rafiee-6man-local-security-01.txt
Differences from draft-rafiee-6man-local-security-00.txt
Networking Group H. Rafiee
INTERNET-DRAFT Huawei Technologies Duesseldorf GmbH
Intended status: Informational C. Meinel
Hasso Plattner Institute
Expires: March 1, 2015 September 1, 2014
Recommendations for Local Security Deployments
<draft-rafiee-6man-local-security-01.txt>
Abstract
There are currently some mechanisms available to mitigate attacks in
local networks -- Secure Neighbor Discovery (SeND), First Hop
Security (FHS), SAVI, etc.. The purpose of this document is to
compare these mechanisms and offer some recommendations regarding the
implementations and deployments of these mechanisms.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current.
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."
This Internet-Draft will expire on March 1, 2015.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. This document is subject to
BCP 78 and the IETF Trust's Legal Provisions Relating to IETF
Documents (http://trustee.ietf.org/license-info) in effect on the
date of publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Rafiee & Meinel Expires March 1, 2015 [Page 1]
INTERNET DRAFT local security Deployment September 1, 2014
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IPv6 First-Hop Security (FHS) . . . . . . . . . . . . . . . . 3
3. Local link Security for all nodes . . . . . . . . . . . . . . 4
3.1. Secure Neighbor Discovery . . . . . . . . . . . . . . . . 4
3.1.1. Identifying Obstacles for SeND Deployments . . . . . 4
3.1.1.1. CGA Performance and Complexity . . . . . . . . . 4
3.1.1.2. CGA Security Issue . . . . . . . . . . . . . . . 5
3.1.1.3. Router Authorization Problem . . . . . . . . . . 5
3.2. SAVI mechanisms . . . . . . . . . . . . . . . . . . . . . 5
4. Recommendations for Local Security Deployments . . . . . . . 5
4.1. Other Alternative Algorithms in place of CGA . . . . . . 6
4.2. Router Authorization and Preventing Layer 2 Spoofing . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 6
7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Rafiee & Meinel Expires March 1, 2015 [Page 2]
INTERNET DRAFT local security Deployment September 1, 2014
1. Introduction
Local security is a very important issue in everyday life,
especially, in large enterprises that this trust can be broken by one
of fired employees. There are currently some existing mechanisms that
might be used to mitigate the attacks in local networks. The focus of
this document is to explain these mechanisms and discuss about their
level and costs of security they can provide for the nodes and offer
some recommendations for their deployments. This document also
focuses on the problems for Secure Neighbor Discovery (SeND)
[RFC3971] deployments and offer some recommendations and new models
to try to remove the obstacles for its deployments.
2. IPv6 First-Hop Security (FHS)
One of the growing concerns in local security is that the attacker
can forge the identity of the routers or play other attacks during
router discovery, Duplicate Address Detection (DAD) process, and
neighbor reachability check [FHSc]. One example is the scenario where
the attacker might spoof the router advertisement (RA) message. So,
he responds to a node's Router solicitation (RS) request with a
spoofed RA message. Since the node does not have any means to
authorize the legitimate router, it accepts the attacker's fake
router prefixes and choose this attacker as its first hop router.
There are some mitigation mechanism available such as IPv6 RA guard
[RFC6105], first-hop security binding table, IPv6 device tracking,
IPv6 port-based access list support, IPv6 global policy. These
approach have some advantages and disadvantages.
The disadvantages and limitations [FHSs] are as follow:
- The RA guard feature does not offer protection in environments
where IPv6 traffic is tunneled.
- This feature is supported only in hardware by programming the TCAM.
- This feature can be configured only on a switch-port interface in
the ingress direction.
- This feature supports only host mode.
- This feature is supported only in the ingress direction; it is not
supported in the egress direction. So,the assumption is that the
attacker is not in local link but it is somewhere outside the
network.
- This feature is supported on ether channel, but not on ether
channel port members.
- This feature is not supported on trunk ports with merge mode.
Rafiee & Meinel Expires March 1, 2015 [Page 3]
INTERNET DRAFT local security Deployment September 1, 2014
- This feature cannot protect the nodes against network layer IP
spoofing.
- This feature is applicable against fake router advertisement
attacks rather than other types of attacks that is possible in local
links. One example is that the attacker can prevent the node from IP
address configuration and this feature cannot prevent this attack.
- This feature cannot protect the node against RA attacks if the
implementation of neighbor discovery accepts unicast RA messages as
well as multicast RA messages. The Neighbor Discovery specification
used the word "SHOULD" and not "MUST. One of the operating system
(OS) that accepts unicast RA messages is Linux distributions.
- This feature might also have a patent problem since some open
source operating system such as Linux did not implement it.
3. Local link Security for all nodes
Mechanisms in this category would provide the node with, both, the
protection against IP spoofing and also protection against rogue
routers. SeND is one of the mechanism that can be classified under
this category, however, it is also considered as a first-hope
security mechanism.
3.1. Secure Neighbor Discovery
SeND provide the local security by adding four options to Neighbor
Discovery messages [RFC4861, RFC4862]. These options are timestamp,
nonce, Cryptographically Generated Addresses (CGA)[RFC3972] and
RSAsignature.
3.1.1. Identifying Obstacles for SeND Deployments
There might be several reasons that SeND is not yet supported by many
OSs. This document tries to introduce some of them.
3.1.1.1. CGA Performance and Complexity
According to CGA algorithm, if the node chooses CGA sec value higher
than 0, it needs to repeat some steps that needs the high CPU
attention. This might limit its implementation only to the nodes that
are not using battery or do not have limited resources of energy.
Unfortunately, in near future, the devices are going to be more
advanced and smaller in size but limited in battery. This is because
the battery technology is not as advanced as the computerized
devices. This is why, it is not ideal to use an approach that might
use high range of CPU and energy resources.
Rafiee & Meinel Expires March 1, 2015 [Page 4]
INTERNET DRAFT local security Deployment September 1, 2014
3.1.1.2. CGA Security Issue
Unfortunately CGA verification process allows the attacker to claim
the IP address of the CGA node with CGA different sec value
[cgaattack].
3.1.1.3. Router Authorization Problem
Before RPKI model was proposed, there was not any clear mechanism
available to be used for router authorization. There were some
solutions available but not scalable solutions. One example is that
the nodes in the network are preloaded with the router's
certification. This was not really ideal in the large enterprises
with thousands of nodes and with different user's experience.
Active Directory (AD) solves this problem but leaves the companies
with the fact that they are dependent to the use of ADs.
3.2. SAVI mechanisms
The purpose of SAVI mechanisms [SAVIWG] is to prevent IP spoofing
attacks in the local network and does not allow an attacker to use
other prefixes in this network. One of the offered solutions is the
use of SeND [SAVI]. One of the assumption for this proposal is that
SeND is already deployed and enabled on the nodes and after the
successful verification, they generate a bindings between the port of
switch that this traffic has been generated and the source IP address
of the node. There are some questions unanswered in that proposal,
One of these questions is that when one uses CGA or any other
approaches in SeND to provide the node with the proof of IP address
ownership, why one needs to use this mechanism for preventing source
IP spoofing of the hosts in the network?
The disadvantages of this mechanism
- Like SeND, it cannot protect the node with MAC spoofing section 2.2
[SAVI], so there is no more benefit to use this mechanism.
- It does not address the main problem of SeND which is trusted
anchors.
- If SeND is not deployed, then the assumption is the use of other
protocols and monitoring systems. Therefore, the protection provided
by this mechanism is similar to the FHS.
4. Recommendations for Local Security Deployments
Since SeND is one of promising approach to provide the node with both
local security and protect the nodes against IP spoofing attacks in
Rafiee & Meinel Expires March 1, 2015 [Page 5]
INTERNET DRAFT local security Deployment September 1, 2014
network layer, this section offers some possible solutions to
facilitate SeND deployments.
4.1. Other Alternative Algorithms in place of CGA
One possible solution to CGA problems would be the use of other
alternative algorithms such as SSAS [ssasAnalysisPaper,
ssasAnalysis]. It generates the IP addresses in a faster and removes
the complexity. It is also ideal for nodes with limited battery
resources.
4.2. Router Authorization and Preventing Layer 2 Spoofing
There can be a monitoring system that stores MAC address and public
key of each node. In case there is any mismatch in the network, it
immediately log this event or report it to responsible person/system.
To provide router authorization, this node needs to be preconfigured
with the router?s MAC and public key. This is like a local Trusted
Anchor (TA) that has more responsibilities.
5. Security Considerations
There is no security consideration except the one that is explained
for SeND.
6. IANA Considerations
There is no IANA consideration
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu,
C., Mohacsi, J., "IPv6 Router Advertisement Guard," RFC
6105, February 2011.
[RFC3972] Aura, T., "Cryptographically Generated Addresses
(CGA)," RFC 3972, March 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and Nikander, P.,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
Rafiee & Meinel Expires March 1, 2015 [Page 6]
INTERNET DRAFT local security Deployment September 1, 2014
[RFC4861] Narten, T., Nordmark, E., Simpson, W., Soliman,
H., "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., Jinmei, T., "IPv6
Stateless Address Autoconfiguration", RFC 4862, September
2007
7.2. Informative References
[FHSc] IPv6 First Hop Concerns,
http://www.cisco.com/web/about/security/intelligence/ipv6_first_hop.html
[FHSs] IPv6 First Hop Security,
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_
hop_security.html
Rafiee & Meinel Expires March 1, 2015 [Page 7]
INTERNET DRAFT local security Deployment September 1, 2014
Authors' Addresses
Hosnieh Rafiee
HUAWEI TECHNOLOGIES Duesseldorf GmbH
Riesstrasse 25, 80992,
Munich, Germany
Phone: +49 (0)162 204 74 58
Email: hosnieh.rafiee@huawei.com
Christoph Meinel
Hasso-Plattner-Institute
Prof.-Dr.-Helmert-Str. 2-3
Potsdam, Germany
Email: meinel@hpi.uni-potsdam.de
Rafiee & Meinel Expires March 1, 2015 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 02:28:07 |