[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

IPv6 maintanance Working Group (6man)                         H. Rafiee
INTERNET-DRAFT                                                C. Meinel
Intended status: Informational Track            Hasso Plattner Institute
Expires: June 4, 2014                                   December 4, 2013


             Recommendations for Local Security Deployments
                <draft-rafiee-6man-local-security-00.txt>

Abstract

   There are currently some mechanisms available to mitigate attacks in
   local networks. The purpose of this document is to compare these
   mechanisms and offer some recommendations regarding the
   implementations and deployments of these mechanisms. Then it focuses
   on the deployment of one of the promising approach in local security,
   i.e., Secure Neighbor Discovery (SeND) [RFC3971].



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 June 4, 2014.





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, et al.         Expires June 4, 2014                     [Page 1]


INTERNET DRAFT         local security Deployment        December 4, 2013

   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.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  IPv6 First-Hop Security (FHS)  . . . . . . . . . . . . . . . .  3
   4.  Local link Security for all nodes  . . . . . . . . . . . . . .  4
     4.1.  Secure Neighbor Discovery  . . . . . . . . . . . . . . . .  4
       4.1.1.  Identifying Obstacles for SeND Deployments   . . . . .  4
         4.1.1.1.  CGA IPR  . . . . . . . . . . . . . . . . . . . . .  5
         4.1.1.2.  CGA Performance and Complexity   . . . . . . . . .  5
         4.1.1.3.  CGA Security Issue   . . . . . . . . . . . . . . .  5
         4.1.1.4.  Router Authorization Problem   . . . . . . . . . .  6
   5.  Recommendations for Local Security Deployments   . . . . . . .  6
     5.1.  SSAS an alternative to CGA   . . . . . . . . . . . . . . .  6
     5.2.  Router Authorization and Preventing Layer 2 Spoofing   . .  6
       5.2.1.  CN as Monitoring Node  . . . . . . . . . . . . . . . .  7
       5.2.2.  Generation of RPK and SPK  . . . . . . . . . . . . . .  7
       5.2.3.  Process of RPK and SPK.  . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

























Rafiee, et al.         Expires June 4, 2014                     [Page 2]


INTERNET DRAFT         local security Deployment        December 4, 2013



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. aThis document also
   focuses on the problems for Secure Neighbor Discovery (SeND)
   [RFC3971] deplopyments and offer some recommendations and new models
   to try to remove the obstacles for its deployments.



2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC 2119 significance.



3.  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 [1]. 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 [2] 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 switchport interface in


Rafiee, et al.         Expires June 4, 2014                     [Page 3]


INTERNET DRAFT         local security Deployment        December 4, 2013

   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.

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



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



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



4.1.1.  Identifying Obstacles for SeND Deployments


Rafiee, et al.         Expires June 4, 2014                     [Page 4]


INTERNET DRAFT         local security Deployment        December 4, 2013


   There might be several reasons that SeND is not yet supported by many
   OSs. This document tries to introduce some of them.



4.1.1.1.  CGA IPR

   SeND without CGA cannot protect all nodes against IP spoofing but it
   can authorize the routers. This means that after setting all the
   requirements and accept the complexity of certification
   configuration, still the leverage of protection is similar to when
   the network only supports the FHS mechanisms. This is why, CGA is one
   of the necessary option in SeND that provide all nodes in the network
   with the proof of IP address ownership but why CGA might be a
   problem?

   At first sight, CGA IPR allows a loyalty free implementation of this
   specification but on the other hand, some implementers do not like to
   implement something that hold a patent which might cause problem for
   them in future (Refer to this article regarding the concerns about
   royalty free IPR [3]).



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



4.1.1.3.  CGA Security Issue

   Unfortunately CGA verification process allows the attacker to claim
   the IP address of the CGA node with CGA different sec value [4]. The
   other problem is that, the plain text of CGA hash is clear for the
   attacker and he can use the same value as what the CGA node used. So,
   the attacker can only play with public key or endings of the hash
   value to generate a fast matching collision with the CGA node. He
   also does not need to use a very strong key size and he can use a key
   size that gives him ability to play with this plain text ending bits.






Rafiee, et al.         Expires June 4, 2014                     [Page 5]


INTERNET DRAFT         local security Deployment        December 4, 2013

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



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



5.1.  SSAS an alternative to CGA

   One possible solution to CGA problems would be the use of SSAS [5,
   6]. It generates the IP addresses in a faster and remove the
   complexity. It is also ideal for nodes with limited battery
   resources.



5.2.  Router Authorization and Preventing Layer 2 Spoofing

   Since SSAS alone cannot authorize the legitimates routers in the
   network. There is a need for an auxiliary mechanism to help SSAS. To
   verify the authorized router in the local network and to create a
   partial trust within the network, this document propose the use of a
   local centralized Resource Public Key Infrastructure (RPKI) which is
   based on the centralized version explained in RFC 6494 and RFC 6495.
   Figure 1 depicts the architecture of this new RPKI framework. In this
   framework, a Controller Node (CN) is used whereby administrators will
   be able to manually store, in the database of this node, the router?s
   public key and MAC address. There are two new different SeND/NDP
   messages, Request Public Key (RPK) and Send Public Key (SPK), that
   can be used by nodes to request the public key of the router or other
   nodes, and can be used to send from the CN node the public key of the
   requested node. The CN node has a fixed MAC address (a reserved MAC
   address). It is a reserved MAC address which is known to all nodes.
   One possible way to implement CN is to use a new module in routers
   capable of processing these two messages. In this case, one CN node
   could be available in two different local networks when the same
   router is available between these two networks. When a node first
   sends a RPK message, the CN node will add its MAC address and public
   key to its database. This gives other nodes the capability of
   verifying this new node by asking for the public key of this node.


Rafiee, et al.         Expires June 4, 2014                     [Page 6]


INTERNET DRAFT         local security Deployment        December 4, 2013

   The CN node maintains this data for as long as it receives NS
   messages from this node. Nodes frequently check neighbor reachability
   and the CN node receives these messages passively. If the CN node
   does not see a message from a node that has an entry in its database,
   then it sends a NS message to that node. If it does not receive a
   response from that node, it set the active flag of this node to
   inactive and after being inactive for a week, it removes that node
   from its database. Nodes that are added manually to the CN database
   MUST be removed manually from the CN database.



5.2.1.  CN as Monitoring Node

   To mitigate any layer 2 attacks or to prevent MAC spoofing in initial
   conversation of nodes with CN node, it is RECOMMENDED that the CN
   node listens passively to the network and alarm any malicious
   activity of the nodes that want to spoof its MAC address. The nodes
   also MUST keep the MAC address and public key of the CN node in their
   cache and keep it for 3 months. The node MIGHT update this value if
   it is in a different network or if it does not receive any message
   from CN node. Before any action to remove CN node from their cache,
   the node MUST process the reachability for CN node.



5.2.2.  Generation of RPK and SPK

   Figure 1 shows the format of these two new NDP/SeND messages. The NDP
   message type used for RPK is 140 and for SPK is 141 (these numbers
   are assigned by IANA). These are set in the ICMPv6 header. There are
   two new types in these messages: type 20 and type 21. These new types
   are helpful when an existing node wants to generate a new IP address
   and wants to update its public key in CN node. This allows the CN
   node to detect that it is not the MAC spoofing attack.

   - Type 20: If a node wants to change its IP address or generate a new
   one, it sign its MAC address and timestamp using its old private key
   and set it in Signature Ia type 20 RPK message which indicates the
   use of its MAC address and timestamp signed by its old private key.

   - Type 21: This contains the node's new public key and the signature
   signed by using the node's new private key.

   When a CN node wants to generate the SPK, it adds the requested
   public key to the type 20 section of the message and then includes
   its own public key and generates a signature using its own private
   key created from the concatenation of timestamp with set it type 21
   section of SPK message.


+--------+---------+---------------------------+
|  Type  |  Length |          Reserved         |


Rafiee, et al.         Expires June 4, 2014                     [Page 7]


INTERNET DRAFT         local security Deployment        December 4, 2013

| 1 byte |  1 byte |          6 bytes          |
+----------------------------------------------+
|               timestamp                      |
+---------+--------+---------------------------+
|  Type=20| Length |        public key         |
|  1 byte | 1 byte |                           |
+---------+--------+-----------+---------------+
|  Type=21| Length |  pubkeylen|   CN public   |
|  1 byte | 1 byte |  1 byte   |      key      |
+------------------+---------------------------+
|  Algorithm type  |        Signature II       |
|      1 byte      |                           |
+----------------------------------------------+
|                   Padding                    |
+----------------------------------------------+

 SPK message

+--------+---------+---------------------------+
|  Type  |  Length |          Reserved         |
| 1 byte |  1 byte |          6 bytes          |
+----------------------------------------------+
|               timestamp                      |
+---------+--------+-------------+-------------+
|  Type=20| Length |  Algorithm  | Signature I |
|  1 byte | 1 byte | type(1 byte)|             |
+---------+--------+-------------+-------------+
|  Type=21| Length |  pubkeylen|   new public  |
|  1 byte | 1 byte |  1 byte   |      key      |
+------------------+---------------------------+
|  Algorithm type  |        Signature II       |
|      1 byte      |                           |
+----------------------------------------------+
|                   Padding                    |
+----------------------------------------------+

 RPK message
Figure 1 Format of Request Public Key (RPK) and Send Public Key (SPK)



5.2.3.  Process of RPK and SPK.

   When a new node joins a network, it generates its local IP address
   using the SSAS algorithm and then sends a Router Solicitation message
   to obtain a router advertisement and to generate its global IP
   address. This message does not need to include the SSAS data
   structure. The router responds to the node with a Router
   Advertisement (RA). The new node needs to obtain the public key for
   this router from the CN node. It then generates a RPK. After
   successful verification, the CN node checks whether or not this MAC
   address already exists in its database. If it does, it checks to see
   whether or not the public key is the same as that which is available


Rafiee, et al.         Expires June 4, 2014                     [Page 8]


INTERNET DRAFT         local security Deployment        December 4, 2013

   in its database. If it finds a match, it generates a SPK message and
   sends it to the node. If the CN node finds a different public key
   than that of this node, it sends the SPK setting the length of the
   type 20 option to 1 and setting the one byte public key to 1. This
   informs the new node that there is an existing MAC address with a
   different public key. If this node is the owner of the old public key
   that is available in the CN node, it includes its old public key as
   shown in figure 1 and sends a new RPK. Otherwise it considers this an
   attack on his MAC address and sets the one byte of the old public key
   to zero and the length of the type 20 option to one, and sends this
   message. This message causes a flag to be added to the database to
   inform the network administrator that something is wrong in this
   network.

   If the public key and MAC address of the new node are not available
   in the CN, after receiving the RPK message and after a successful
   SSAS verification, it will add these values to its database.

   When the other nodes want to add a new node to their neighboring
   caches, after receiving the neighbor advertisement message, they will
   ask the CN node for the public key of this node. After successful
   verification, they will add the public key, MAC address and IP
   address of this node to their neighboring cache. The next time they
   will not need to ask the CN node for any information to check the
   reachability of the neighboring nodes in their cache. This decreases
   the number of messages exchanged between the CN node and the other
   nodes in this network.



6.  Security Considerations

   There is no security consideration except the one that is explained
   for SSAS/SeND.



7.  IANA Considerations

   This document introduces a new, local RPKI based on the centralized
   RPKI. It is necessary that the IANA assign two numbers to two
   different messages that were introduced by this document. The RPKI
   node also needs to have a reserved MAC address.





8.  References

8.1.  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to


Rafiee, et al.         Expires June 4, 2014                     [Page 9]


INTERNET DRAFT         local security Deployment        December 4, 2013

             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.

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

8.2.  Informative References

   [1] IPv6 First Hop Concerns,
       http://www.cisco.com/web/about/security/intelligence/ipv6_first_hop.html

   [2] IPv6 First Hop Security,
       http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_security.html

   [3] Vaelimaeki, M., Oksanen, V., "Patents on Compatibility
       Standards and Open Source ? Do Patent Law Exceptions and
       Royalty-Free Requirements Make Sense?" ,
       http://www2.law.ed.ac.uk/ahrc/script-ed/vol2-3/valimaki.asp,
       September 2005

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

   [5] Rafiee, H., Meinel, C., "'SSAS: a Simple Secure Addressing
       Scheme for IPv6 AutoConfiguration". In Proceedings of the 11th
       IEEE International Conference on Privacy, Security and Trust
       (PST), IEEE Catalog number: CFP1304F-ART, ISBN:
       978-1-4673-5839-2.

   [6] Rafiee, H., Meinel, C., "'SSAS: a Simple Secure Addressing
       Scheme for IPv6 AutoConfiguration".
       http://tools.ietf.org/search/draft-rafiee-6man-ssas, 2013








Rafiee, et al.         Expires June 4, 2014                    [Page 10]


INTERNET DRAFT         local security Deployment        December 4, 2013

Authors' Addresses

      Hosnieh Rafiee
      Hasso-Plattner-Institute
      Prof.-Dr.-Helmert-Str. 2-3
      Potsdam, Germany
      Phone: +49 (0)331-5509-546
      Email: ietf@rozanak.com


      Dr. Christoph Meinel
      (Professor)
      Hasso-Plattner-Institute
      Prof.-Dr.-Helmert-Str. 2-3
      Potsdam, Germany
      Email: meinel@hpi.uni-potsdam.de





































Rafiee, et al.         Expires June 4, 2014                    [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/