Mobility for IP (MIPSHOP)                                      W. Haddad
Internet-Draft                                                M. Naslund
Intended status: Standards Track                       Ericsson Research
Expires: July 9, 2008                                    January 6, 2008


   On Using 'Symbiotic Relationship' to Repel Network Flooding Attack
                draft-haddad-mipshop-netflood-defense-00

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 July 9, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).














Haddad & Naslund          Expires July 9, 2008                  [Page 1]


Internet-Draft          Network Flooding Defense            January 2008


Abstract

   This memo describes a simple defense mechanism against a specific
   type of network flooding attacks.  The suggested mechanism requires a
   mobile node to establish a 'symbiotic relationship' with the
   infrastructure, in order to empower it to repel such attack while
   giving enough insurance to the source(s) of the traffic about the
   need to cease sending traffic to the targeted network.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  6
   5.  New Messages and Options . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12




























Haddad & Naslund          Expires July 9, 2008                  [Page 2]


Internet-Draft          Network Flooding Defense            January 2008


1.  Introduction

   Network flooding attacks aim to saturate the targeted network, e.g.,
   the access infrastructure, with junk packets in order to create an
   environment where all hosts located on a particular link(s) become
   victims to a denial-of service attack (DoS).

   As the name suggests, network flooding attacks targets a whole
   portion of the network infrastructure instead of targeting one
   particular node (e.g., SYN flooding attack) and thus, can have a more
   devastating effect.

   This memo describes a simple defense mechanism against a specific
   type of network flooding attacks.  The suggested mechanism requires a
   mobile (and potentially multihomed) host to establish a 'symbiotic
   relationship (SR)' as described in [ProSeND], with the network
   infrastructure in order to empower it to repel such attack.  In order
   to be successful, the defense mechanism described as a "counter
   attack" mounted by the targeted infrastructure must provide enough
   insurance to the source(s) of harmful traffic about the need to cease
   sending packets towards the targeted network.






























Haddad & Naslund          Expires July 9, 2008                  [Page 3]


Internet-Draft          Network Flooding Defense            January 2008


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














































Haddad & Naslund          Expires July 9, 2008                  [Page 4]


Internet-Draft          Network Flooding Defense            January 2008


3.  Motivation

   It is safe to assume that any practical defense against network
   flooding attacks does not need to be motivated!  However, we feel
   important to highlight how such attack can be mounted in a mobile
   and/or multihomed environment(s) and describe the current defense
   mechanism and its consequences on the mobile node (MN).

   A specific type of network flooding attack can be launched from using
   Mobile IPv6 protocol (described in [MIPv6]).  Such attack is mounted
   by having the malicious MN attaching to the targeted network then
   updating each of its correspondent nodes (CNs) about its new care-of
   address (CoA) by sending binding updates (BU) messages.  Once the
   update(s) is done, each CN is supposed to start re-routing data
   packets to the MN's new CoA.  The next step for the attacker is to
   detach itself from the foreign link while keeping sending ACK
   messages to each CN via its home agent (HA).  Such step requires the
   MN to switch to another network or to use another interface in case
   it is multihomed.  However, the impact will be the same on the
   targeted network in both scenarios, since each CN will keep sending
   data packets to the MN's CoA as long as it keeps receiving ACK
   messages and the binding lifetime has not expired (for more details,
   refer to [MIPSec]).

   In MIPv6 protocol, the defense against the type of network flooding
   attack described in the above, is provided by repeating the return
   routability (RR) procedure every 7 minutes.  This means also that
   even if the MN is not moving, then it has to perform the HoTI/HoT and
   CoTI/CoT signaling exchange with each correspondent node (CN).  It
   follows that a significant amount of signaling messages can be
   imposed on the MN in some cases.

   Enhanced Mobile IPv6 (described in [EMIPv6]) introduces a strong
   optimization to MIPv6 protocol by exploiting the crypto-generated
   address technique [CGA] for the purpose of establishing a long
   lifetime bidirectional security association (SA) between the MN and
   the CN.  However, while EMIPv6 succeeds in reducing the load of
   signaling messages, it does not provide strong defense against the
   type of network flooding attack described earlier.

   Our main motivation in this document is to provide an efficient and
   simpler mechanism, which enables the targeted (visited) network to
   repel network flooding attacks mounted by an attacker using mobility
   and multihoming protocols.







Haddad & Naslund          Expires July 9, 2008                  [Page 5]


Internet-Draft          Network Flooding Defense            January 2008


4.  Protocol Overview

   In order to empower the network infrastructure to repel the type of
   network flooding attack described earlier, the suggested protocol
   puts a strong -yet neutral in its effect- requirement on any node
   attaching to the network access infrastructure.  The new requirement
   consists on establishing an SR with any public key(s) advertised by
   the access router (AR) in the router advertisement (RtAdv) messages.
   This is motivated by the fact that an AR may or may not be the
   node(s), which can launch a counter attack to repel the flooding
   attack.  Consequently, the AR has to advertise the public keys of
   other dedicated node(s), which has this feature.  It follows, that a
   main assumption in our protocol is to have the secure neighbor
   discovery [SeND] protocol deployed in the targeted infrastructure.
   For simplicity reasons, we assume in the following that the AR is the
   node able to carry counter attacks if/when needed.  This means that
   no additional public key(s) is advertised in the RtAdv messages.

   When configuring its IPv6 address, e.g., CoA, the MN MUST establish
   the SR and sends back the RAN(128) to the AR.  The MN SHOULD encrypt
   the RAN(128) with the AR's public key and the latter SHOULD NOT allow
   access to any node which does not establish an SR upon attachment to
   its corresponding link(s).  Upon receiving a neighbor discovery
   message [NDP] carrying the SR component, the AR should validate it
   before storing it in its cache memory.  Only after storing the SR in
   its cache memory and approving it in a signed NDP message, that a MN
   can trigger the exchange of mobility signaling messages with the
   CN(s), in order to request re-routing data traffic to its new CoA.

   Let's assume that after resuming data packets exchange using its new
   CGA, the MN (being malicious!) decides to mount the same type of
   network flooding attack against the visited network.  This means that
   once it has synchronized the transmission of ACK messages sent via
   other paths with data packets rates received from the CNs, it can
   detach itself from the foreign link and keep sending ACK messages to
   the CNs at the appropriate frequencies.

   After leaving the link, the AR will notice at some point (e.g., using
   NDP messages) that the MN has vanished while data packets are still
   routed to the MN's CoA.  At this stage, the AR MAY decide to act
   immediately or within a pre-configured time interval.  In both
   scenarios, the AR will launch its counter attack by fetching first
   all IP source address(es) carried in data packets sent to the MN's
   CoA, then sending a new mobility message (called "Flush Request
   (FR)") to each corresponding CN.  The FR message MUST carry the MN's
   CoA together with the SR corresponding "proof of relationship (PoR)"
   and MUST be signed with the AR's CGA private key.




Haddad & Naslund          Expires July 9, 2008                  [Page 6]


Internet-Draft          Network Flooding Defense            January 2008


   Upon receiving a FR message, the CN validates it by checking first if
   the CoA is stored in its binding cache entries (BCE) table.  Then, it
   checks in the following order:

   - the SR PoR
   - the AR's CGA address
   - the signature

   If the FR message is valid, the CN MUST immediately flush out the
   MN's CoA from its BCE and tear down all ongoing sessions using the
   MN's IPv6 home address which is bind to the CoA carried in the FR
   message.  Then, the CN SHOULD send a "Flush Acknowledgment (FA)"
   message to the AR which MUST carry the token and the PoR.  Finally,
   the CN MUST also sign the FA message with its CGA private key.  In
   case any of the above validation steps fail, the CN SHOULD silently
   discard the message and keeps exchanging data packets with the MN.

   As mentioned earlier, the AR MUST send a FR message to each CN in
   order to completely stop the attack.  This means that the intensity
   of the flooding attack should gradually decrease gradually before it
   comes to a halt.






























Haddad & Naslund          Expires July 9, 2008                  [Page 7]


Internet-Draft          Network Flooding Defense            January 2008


5.  New Messages and Options

   TBD
















































Haddad & Naslund          Expires July 9, 2008                  [Page 8]


Internet-Draft          Network Flooding Defense            January 2008


6.  Security Considerations

   This document describes a defense mechanism against a specific type
   of network flooding attack which can be mounted by one or many
   malicious node(s) having to attach to the targeted network before
   triggering the attack.  Consequently, the main goal behind this
   document is to increase the overall network infrastructure security.
   It should be noted however, that the suggested defense mechanism
   looses its efficiency when the CN is also involved in the attack.

   A key feature in our mechanism is the SR between any host and the AR.
   However, such feature can easily be turned into a denial-of-service
   (DoS) attack against the host itself in case it accepts to establish
   an SR with any node whose claimed certificate cannot be verified.  It
   follows that a key requirement is to have SeND deployed in order to
   protect the link between the AR and the MN.  Note that in case the AR
   gets compromised then it can send at anytime an FR message to the CN
   to tear down the MN's ongoing session(s).  However, such scenario is
   no different than having the AR dropping data packets sent to the MN.

   Finally, it should be noted that the AR is not taking any step in
   order to protect the CN against attacks which aim to exhaust its
   processing power by flooding it with fake FR messages.  In fact,
   there are three reasons for not imposing a preventive step, e.g., a
   CoTI/CoT message exchange.  First, the CN is able to check the SR
   before it validates the signature.  This means that the CN will drop
   the message in case the SR is not valid.  The second reason is that
   the RAN(128) parameter is sent in an encrypted form to the AR only.
   Consequently, prior to sending an FR message, the SR is known only by
   the MN and its AR.  The third one is the fact that after sending a FR
   message, the MN's CoA won't be used anymore so disclosing it in a FR
   message should not introduce any new threat against the CN.



















Haddad & Naslund          Expires July 9, 2008                  [Page 9]


Internet-Draft          Network Flooding Defense            January 2008


7.  References

7.1.  Normative References

   [CGA]      Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3792, March 2005.

   [EMIPv6]   Vogt, C., Arkko, J., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, June 2006.

   [MIPSec]   Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
              Nordmark, "Mobile IP Version 6 Route Optimization Security
              Design Background", RFC 4225, December 2005.

   [MIPv6]    Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              for IPv6", RFC 3775, June 2004.

   [NDP]      Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [SeND]     Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P.
              Nikander, "Secure Neighbor Discovery (SeND)", RFC 3971,
              March 2005.

   [TERM]     Bradner, S., "Key Words for Use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP , March 1997.

7.2.  Informative References

   [ProSeND]  Haddad, W. and M. Naslund, "On Secure Neighbor Discovery
              Proxying Using 'Symbiotic' Relationship", Internet
              Draft, draft-haddad-cgaext-symbiotic-sendproxy-00.txt,
              January 2008.

















Haddad & Naslund          Expires July 9, 2008                 [Page 10]


Internet-Draft          Network Flooding Defense            January 2008


Authors' Addresses

   Wassim Haddad
   Ericsson Research
   Torshamnsgatan 23
   SE-164 80 Stockholm
   Sweden

   Phone: +46 8 4044079
   Email: Wassim.Haddad@ericsson.com


   Mats Naslund
   Ericsson Research
   Torshamnsgatan 23
   SE-164 80 Stockholm
   Sweden

   Phone: +46 8 58533739
   Email: Mats.Naslund@ericsson.com































Haddad & Naslund          Expires July 9, 2008                 [Page 11]


Internet-Draft          Network Flooding Defense            January 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Haddad & Naslund          Expires July 9, 2008                 [Page 12]