Internet DRAFT - draft-rafiee-6man-local-security

draft-rafiee-6man-local-security






Networking Group                                              H. Rafiee
INTERNET-DRAFT                                                          
Intended status: Informational                                          
Expires: November 8, 2015                                    May 8, 2015


             Recommendations for Local Security Deployments
                <draft-rafiee-6man-local-security-03.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 November 8, 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 
   include Simplified BSD License text as described in Section 4.e of 


Rafiee         Expires November 8, 2015                         [Page 1]

INTERNET DRAFT         local security Deployment             May 8, 2015

   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   . . . . . . .  6
     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         Expires November 8, 2015                         [Page 2]

INTERNET DRAFT         local security Deployment             May 8, 2015


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         Expires November 8, 2015                         [Page 3]

INTERNET DRAFT         local security Deployment             May 8, 2015

   - 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         Expires November 8, 2015                         [Page 4]

INTERNET DRAFT         local security Deployment             May 8, 2015


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 Resource Public Key Infrastructure (RPKI) [RFC6810] 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].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 algorithm in 
   SeND options to provide the node with the proof of IP address 
   ownership, how this mechanism can be helpful to provide this 
   assurance? SAVI-send mechanism is similar to Trust in First Use 
   (TIFU) mechanisms. otherwise the switch is configured manually with 
   the router in the network so that it can only be useful for router 
   authorization. Because for the proof of IP address ownership, it is 
   CGA or other similar algorithm that can help. 

   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 otherwise manually configure the switch. 

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



Rafiee         Expires November 8, 2015                         [Page 5]

INTERNET DRAFT         local security Deployment             May 8, 2015


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 
   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 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 the matching of 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. 



Rafiee         Expires November 8, 2015                         [Page 6]

INTERNET DRAFT         local security Deployment             May 8, 2015

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

   [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 

   [RFC6810] Bush, R., Austein, R.,"The Resource Public Key 
             Infrastructure (RPKI) to Router Protocol" , RFC6810, 
             January 2013 

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 

   [cgaattack] Rafiee,H., Meinel, C., "Possible Attack on 
               Cryptographically Generated Addresses (CGA)", 
               http://tools.ietf.org/html/draft-rafiee-6man-cga-attack, 
               2015 























Rafiee         Expires November 8, 2015                         [Page 7]

INTERNET DRAFT         local security Deployment             May 8, 2015

Authors' Addresses

      Hosnieh Rafiee
      http://www.rozanak.com
      Munich, Germany
      Phone: +49 (0)162 204 74 58
      Email: ietf@rozanak.com














































Rafiee         Expires November 8, 2015                         [Page 8]