Internet DRAFT - draft-hong-nsis-pbs-nslp

draft-hong-nsis-pbs-nslp






Network Working Group                                            S. Hong
Internet-Draft                                    Hughes Network Systems
Intended status: Standards Track                          H. Schulzrinne
Expires: April 17, 2014                                      Columbia U.
                                                        October 14, 2013


                PBS NSLP: Network Traffic Authorization
                    draft-hong-nsis-pbs-nslp-04.txt

Abstract

   This document describes the NSIS Signaling Layer protocol (NSLP) for
   network traffic authorization on the Internet, the Permission-Based
   Sending (PBS) NSLP.  This NSLP aims to prevent Denial-of-Service
   (DoS) attacks and other forms of unauthorized traffic.  PBS NSLP is
   based on a hybrid approach: a proactive approach of explicitly
   granting permissions and a reactive approach of monitoring and
   countering attacks.  Signaling installs and maintains the permission
   state of routers for a data flow.  A monitoring mechanism provides a
   second line of defense against attacks.  PBS NSLP uses two security
   mechanisms: message security for protecting the integrity of the
   message on end-to-end traffic and channel security for protecting the
   integrity and confidentiality between adjacent nodes.  To
   authenticate data packets, the PBS NSLP requests a sender to use an
   existing security protocol, the IPsec Authentication Header (AH).

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 April 17, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Hong & Schulzrinne       Expires April 17, 2014                 [Page 1]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


   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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.










































Hong & Schulzrinne       Expires April 17, 2014                 [Page 2]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Design Overview  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Robust system  . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Secure system  . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Scalable system  . . . . . . . . . . . . . . . . . . . . .  7
     4.4.  Defense against DoS attacks  . . . . . . . . . . . . . . .  7
       4.4.1.  Proactive Approach . . . . . . . . . . . . . . . . . .  7
       4.4.2.  Reactive Approach  . . . . . . . . . . . . . . . . . .  8
   5.  PBS NSLP Architecture  . . . . . . . . . . . . . . . . . . . .  9
     5.1.  On-path Signaling  . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Traffic Management . . . . . . . . . . . . . . . . . . . . 10
   6.  PBS NSLP Operation . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Basic Operation  . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  Asymmetric Operation . . . . . . . . . . . . . . . . . . . 12
   7.  Security of Messages . . . . . . . . . . . . . . . . . . . . . 13
   8.  PBS Detection Algorithm (PDA)  . . . . . . . . . . . . . . . . 15
     8.1.  Basic Operation of PDA . . . . . . . . . . . . . . . . . . 15
     8.2.  Example of Detecting a Packet Drop Attack (Black Hole
           Attack)  . . . . . . . . . . . . . . . . . . . . . . . . . 16
       8.2.1.  Drop All Packets . . . . . . . . . . . . . . . . . . . 17
       8.2.2.  Drop Selected Packets (Drop Only Data Packets) . . . . 17
   9.  PBS NSLP Messages Format . . . . . . . . . . . . . . . . . . . 19
     9.1.  Common Header  . . . . . . . . . . . . . . . . . . . . . . 19
     9.2.  Message Formats  . . . . . . . . . . . . . . . . . . . . . 19
       9.2.1.  Query  . . . . . . . . . . . . . . . . . . . . . . . . 19
       9.2.2.  Permission . . . . . . . . . . . . . . . . . . . . . . 19
     9.3.  Object Format  . . . . . . . . . . . . . . . . . . . . . . 20
     9.4.  PBS NSLP Objects . . . . . . . . . . . . . . . . . . . . . 20
       9.4.1.  Flow Identification (FID)  . . . . . . . . . . . . . . 20
       9.4.2.  Message Sequence Number  . . . . . . . . . . . . . . . 21
       9.4.3.  Requested Volume (RV)  . . . . . . . . . . . . . . . . 21
       9.4.4.  Sent Volume (SV) . . . . . . . . . . . . . . . . . . . 21
       9.4.5.  Allowed Volume (AV)  . . . . . . . . . . . . . . . . . 22
       9.4.6.  TTL  . . . . . . . . . . . . . . . . . . . . . . . . . 22
       9.4.7.  Refresh Time . . . . . . . . . . . . . . . . . . . . . 22
       9.4.8.  Public Key Certificate . . . . . . . . . . . . . . . . 23
       9.4.9.  Defense  . . . . . . . . . . . . . . . . . . . . . . . 23
       9.4.10. Authentication Data  . . . . . . . . . . . . . . . . . 24
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28




Hong & Schulzrinne       Expires April 17, 2014                 [Page 3]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


1.  Introduction

   This document defines an NSIS Signaling Layer Protocol (NSLP) for
   network traffic authorization to prevent Denial-of-Service (DoS)
   attacks and other forms of unauthorized traffic, the Permission Based
   Sending (PBS) NSLP.  PBS NSLP is within the signaling application
   layer of the NSIS protocol suit which is described in [RFC4080].

   In the PBS NSLP, a sender of IP data packets first has to receive
   permission from the intended receiver before it injects any packets
   into the network.  The term "permission" represents the authority to
   send data.  Therefore, unauthorized packets without permission and
   attack packets that exceed the permission given to the flow are
   dropped at the first router that is aware of the PBS NSLP.  By
   default, routers only forward packets that are covered by a
   permission or may be rate-limited to a very small volume for high-
   assurance networks.  The PBS NSLP has a network traffic monitoring
   mechanism, the PBS Detection Algorithm (PDA).  In PDA, the periodic
   signaling messages are used to detect the attack flows.  PDA provides
   the second line of defense against malicious traffic, which may have
   circumvented the permission-based mechanism.  If it detects attacks,
   the signaling message triggers a reaction against the detected
   attack.

   The PBS NSLP exploits the General Internet Signaling Transport (GIST)
   [RFC5971] that delivers the signaling messages along the data path to
   configure permission state of routers for a data flow.  The message
   security (public key cryptography) is used to protect messages from
   being modified by attackers.  The channel security (TLS and DTLS) is
   used to distribute a shared key for IPsec of data packets to the
   routers along the data path.  The IPsec Authentication Header (AH) is
   used for authentication of the data packets.

   Below, Section 4 gives an overview of the design.  The PBS NSLP
   architecture is presented in Section 5.  Section 6 describes the PBS
   NSLP operation.  Section 7 presents the security of the message.  The
   PBS detection algorithm is described in Section 8.  Section 9
   describes PBS NSLP message and object formats.  Section 10 describes
   security considerations.












Hong & Schulzrinne       Expires April 17, 2014                 [Page 4]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


2.  Requirements Notation

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














































Hong & Schulzrinne       Expires April 17, 2014                 [Page 5]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


3.  Terminology

   The terminology defined by GIST [RFC5971] are used in this document.

   In addition, the following terms are used:

   Attack: Denial-of-Service (DoS) attack.

   Permission: The authority to send data.  It is granted by a intended
   receiver who receives a request from a sender.

   Trustworthy network: Routers are trusted and are not compromised.  In
   this, DoS attacks from end users are not considered.

   Byzantine network: Neither the sender nor the routers are trusted.

   On-path: The data flow path.

   On-path attacker: An attacker on on-path, such as a compromised
   router.

   Off-path attacker: An attacker who inserts packets into the data
   path, but is not located on the data path himself.

   Packet drop attack: An on-path attacker that drops legitimate
   packets.

   PBS NE: NSIS Entity (NE) that supports the functions of PBS NSLP.

   Flow identifier: A descriptor of data flow.  The information in the
   flow identification are source IP address, destination IP address,
   protocol identifier, and source and destination port numbers.



















Hong & Schulzrinne       Expires April 17, 2014                 [Page 6]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


4.  Design Overview

   There are four design requirements: robust, secure, scalable, and
   able to deflect DoS attacks.

4.1.  Robust system

   The PBS NSLP should be robust for changes of state.  Soft-state
   supports the robustness of the system.  Thus, the permission state is
   periodically refreshed by signaling messages.  At the absence of the
   state refresh, the permission state is eliminated.  The periodic
   refreshing of the state guarantees the awareness of changes of the
   permission state and data path.

4.2.  Secure system

   The permission state setup and management should be secure.  The
   signaling messages that install and modify the permission state and
   distribute cryptography keys should not be forgeable.  PBS NSLP uses
   message and channel security to protect authentication and integrity
   of messages.  The authentication and integrity of the data messages
   should be guaranteed.  PBS NSLP requests to use IPsec to protect the
   authentication and integrity of data message.

4.3.  Scalable system

   PBS NSLP should be scalable to be applicable in high-speed and large
   scale networks.  PBS NSLP functionality does not need to be
   implemented in all routers.  Thus, some of the routers that have PBS
   NSLP functionality should properly handle the authorization of data
   flows.  In addition, the computational and signaling overhead should
   be small for scalability.

4.4.  Defense against DoS attacks

   The PBS NSLP should properly prevent DoS attacks in various network
   environments.  The PBS NSLP uses the hybrid approach of proactive and
   reactive approaches.  This hybrid approach can compensate the
   disadvantages of both approaches and accelerate the advantages of
   both approaches.

4.4.1.  Proactive Approach

   A receiver grants a sender a permission that represents an authority
   to send data.  Therefore, data packets are categorized into two
   types; authorized packets and unauthorized packets.  In the closed
   network in which all end users have a PBS NSLP functionality, the
   unauthorized packets without permission are dropped at the first



Hong & Schulzrinne       Expires April 17, 2014                 [Page 7]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


   router by default.  In the open Internet in which some end users do
   not have a PBS NSLP functionality, the flows from the end users who
   do not have a PBS NSLP functionality are rate-limited by default.
   This explicit permission can control resources on the path from a
   sender to a receiver.  This permission for each flow mitigates the
   attacks since the attacker cannot exceed the spoofed permission.

4.4.2.  Reactive Approach

   Even though the attack flow does not have permission, the attack flow
   might spoof the permission.  Therefore, we need to monitor the
   traffic flow and react against the detected attack.  The PBS NSLP has
   a detection algorithm called PBS Detection Algorithm (PDA).  Based on
   the detection, the PBS NSLP triggers the reaction against the
   attacks.  The details of the PDA are described in Section 8.




































Hong & Schulzrinne       Expires April 17, 2014                 [Page 8]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


5.  PBS NSLP Architecture

   The PBS NSLP architecture has three components: on-path (path-
   coupled) signaling, authorization, and traffic management.  Figure 1
   shows the PBS NSLP architecture.

         +--------------------+
         |  On-path signaling |
         |  +-------------+   |           +---------------+
         |  | PBS NSLP    |***************| Authorization |
         |  | Processing  |   |           +---------------+
         |  +-------------+   |                  *
         |    |   *    .      |                  *
         |    .   *    |      |                  *
         |  +-------------+   |                  *
         |  | NTLP (GIST) |   |                  *
         |  | Processing  |   |                  *
         |  +-------------+   |                  *
         |    |        .      |                  *
         +--------------------+                  *
              .        |                         *
              |        .                         *
         +-------------------------------------------------+
    < .->|            Traffic Management                   |< .->
    ====>|                                                 |====>
         +-------------------------------------------------+

   < -.- > = signaling flow
   ======> = data flow
   ******* = configuration

                      Figure 1: PBS NSLP architecture

5.1.  On-path Signaling

   On-path signaling installs and maintains permission state, monitors
   attacks, and triggers the authentication mechanism.  The NTLP (GIST)
   [RFC5971] handles all incoming signaling messages and it passes the
   signaling messages related to the PBS NSLP.  The delivery of
   signaling messages is handled using a peer-to-peer approach.  Thus,
   each PBS NE forwards the signaling message to the next PBS NE when it
   receives the PBS NSLP message.

5.2.  Authorization

   The authorization component decides the granting of permission
   (amount of volume) for a flow.  One of main objectives of this
   component is to detect and identify the attack.  The authorization



Hong & Schulzrinne       Expires April 17, 2014                 [Page 9]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


   component also decides the solution against an attack.  There are
   three solutions: IPsec AH using symmetric cryptography algorithm,
   IPsec AH using public key cryptography algorithm, and changing the
   flow path.  The details of the detection of and solution against the
   attack are described in Section 8.

5.3.  Traffic Management

   The traffic management component handles all incoming packets,
   including signaling messages and data packets.  It passes signaling
   messages up to NTLP (GIST).  Based on the permission state of flows,
   the traffic manager screens the data packets to see whether the data
   packets are authorized.  An IP packet filter is used to filter the
   unauthorized packets.  To see whether the flow exceeds the given
   permission, this component monitors the volume of the data flow that
   it has received since the permission state was set up.  The
   authentication of packets is verified by this component.


































Hong & Schulzrinne       Expires April 17, 2014                [Page 10]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


6.  PBS NSLP Operation

6.1.  Basic Operation

   PBS NSLP follows NSIS framework [RFC4080].  Thus, it works on top of
   the GIST (the implementation of the NTLP).  There are two message
   types in the PBS NSLP, namely Query (Q) and Permission (P) messages.
   The Query message is sent by a sender to request permission to send
   data, specifying the volume of data.  It contains the flow
   identification object, 5-tuple (source IP address, destination IP
   address, source port, destination port, and protocol identifier),
   describing a data flow.  The Permission message is sent by the
   receiver who grants the permission to the sender along the reverse
   path of the Query message.  The reverse path is set up by the GIST
   reverse routing state.  The Permission message is used to set up
   (grant), remove (revoke) and modify permission state for a flow.  The
   Permission message contains the flow identification, the allowed
   volume in bytes, the time limit for the permission, and the refresh
   time for soft-state.  PBS NE stores this information to keep track of
   permission states.  The delivery of signaling messages is performed
   hop-by-hop between the adjacent PBS NEs.  The Query and Permission
   messages are periodically transmitted to establish soft-state that
   enables the detection of permission state and security algorithm
   changes.

   Figure 2 shows how permissions are set up between a sender and a
   receiver.  A sender sends a receiver a Query message to request a
   permission.  The receiver returns a Permission messages to allow
   incoming data packets.  After the permission state is set up between
   the sender and the receiver, the sender can send the allowed volume
   of data to the receiver during the time interval specified.  The
   sender and receiver periodically sends Query and Permission messages
   after each soft-state period T.


















Hong & Schulzrinne       Expires April 17, 2014                [Page 11]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


   Sender               PBS NE                PBS NE            Receiver
     |                     |                     |                     |
     |   Q (FID, RV)       |                     |                     |
   --+-------------------->|    Q (FID, RV)      |                     |
   ^ |                     +-------------------->|    Q (FID, RV)      |
   | |                     |                     +-------------------->|
   | |                     |                     |P (FID, AV, TTL, RT) |
   | |                     |P (FID, AV, TTL, RT) |< -------------------+
   | |P (FID, AV, TTL, RT) |< -------------------+                     |
   | |< -------------------+                     |                     |
   | |                     |   Data flow         |                     |
   | |================================================================>|
   | |                     |                     |                     |
     |                     |                     |                     |
   T |                     |                     |                     |
     |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   V |   Q (FID, RV)       |                     |                     |
   --+-------------------->|    Q (FID, RV)      |                     |
     |                     +-------------------->|    Q (FID, RV)      |
     |                     |                     +-------------------->|
     |                     |                     |P (FID, AV, TTL, RT) |
     |                     |P (FID, AV, TTL, RT) |< -------------------+
     |P (FID, AV, TTL, RT) |< -------------------+                     |
     |< -------------------+                     |                     |
     |                     |                     |                     |

                 FID : Flow identification
                 RV  : The volume of data that the sender requests
                 AV  : The volume of data that the receiver grants
                 TTL : Time limit for the permission
                 RT  : Refresh time for soft-state

                   Figure 2: Basic operation of PBS NSLP

6.2.  Asymmetric Operation

   The PBS NSLP supports the asymmetric transmission of Query/Permission
   messages.  After the permission state is set up, if the receiver
   wants to change the permission state or security algorithm, it sends
   the Permission message without receiving the Query message.




Hong & Schulzrinne       Expires April 17, 2014                [Page 12]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


7.  Security of Messages

   For secure permission state setup and management, PBS NSLP uses a
   public key cryptography mechanism for the authentication and
   integrity of signaling messages.  Each sender and receiver generates
   a public/private key pair, and generates a digital signature by
   encrypting the objects of signaling messages using its own private
   key (i.e., the sender encrypts the objects of the Query message and
   the receiver encrypts the objects of the Permission message).  Each
   public key in the form of the X.509 certificate [RFC5280], which is
   certified by a certificate authority, is distributed by a signaling
   message to the PBS NEs.  The certificate is used to bind a public key
   and a user name (which includes the common name, an email address and
   an IP address).  The Query message carries the sender's public key
   and the Permission message carries the receiver's public key.  To
   validate the authentication and integrity of the signaling messages,
   each PBS NE decrypts the digital signature using the distributed
   public key.  The sequence number of the PBS NSLP message is used to
   prevent replay attacks.

   For the authentication and integrity of data packets, the IPsec
   Authentication Header (AH) is used.  The Permission message carries
   the shared key and security parameter index (SPI), which are
   generated by the receiver and will be used for IPsec.  When each PBS
   NE receives the Permission message, it stores the shared key and
   installs the security association (SA).  For each flow, the SA has
   field values for destination IP address, IPsec protocol (AH or ESP)
   and SPI.  To securely deliver the key and SPI value, channel security
   (TLS or DTLS) is used between adjacent PBS NEs.  PBS NSLP
   functionality allows PBS NEs to validate the IPsec header that uses
   transport mode between the two end hosts (sender and receiver) using
   the shared key.

   For the authentication data field in IPsec AH, the sender uses
   symmetric key cryptography or public key cryptography.  In symmetric
   key cryptography, the shared symmetric key that is delivered in the
   Permission message is used for the encryption.  The public key
   cryptography method entails using the sender's private key for
   encryption.  The receiver has the right to choose a cryptography
   algorithm for IPsec based on the policy, network and applications,
   and this notification is carried in the Permission message.

   Figure 3 shows the secure two-way handshakes for permission state
   setup and how PBS NSLP can prevent attack flows.  The authentication
   field is encrypted by one's private key.  The defense object (DF) has
   the indicated solution against the attack, the cryptographic
   algorithm for the IPsec authentication field, a shared key, and SPI
   value.  Since the attacker does not have the shared key, the attack



Hong & Schulzrinne       Expires April 17, 2014                [Page 13]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


   flow failed during IPsec verification.

   Sender               PBS NE                PBS NE            Receiver
     |                     |                     |                     |
     |Q (FID, RV, PK, Auth)|                     |                     |
   --+-------------------->|Q (FID, RV, PK, Auth)|                     |
   ^ |                     +-------------------->|Q (FID, RV, PK, Auth)|
   | |                     |                     +-------------------->|
   | |                     |P (FID, AV, TTL, RT, |                     |
   | |P (FID, AV, TTL, RT, |   PK, Auth, DF)     |< -------------------+
   | |   PK, Auth, DF)     |< -------------------+ P (FID, AV, TTL, RT,|
   | |< -------------------+                     |    PK, Auth, DF)    |
   | |                     |  Data flow / IPsec  |                     |
   | |================================================================>|
   | |                     |                     |                     |
     |                     |                     |                     |
   T |                     |                     |                     |
     |                     |                     |                     |
   | |       Attacker      |                     |                     |
   | |             |======>X (IPsec verification |                     |
   | |                     | failed. Drop packet)|                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   V |Q (FID, RV, PK, Auth)|                     |                     |
   --+-------------------->|Q (FID, RV, PK, Auth)|                     |
     |                     +-------------------->|Q (FID, RV, PK, Auth)|
     |                     |                     +-------------------->|
     |                     |P (FID, AV, TTL, RT, |                     |
     |P (FID, AV, TTL, RT, |   PK, Auth, DF)     |< -------------------+
     |   PK, Auth, DF)     |< -------------------+ P (FID, AV, TTL, RT,|
     |< -------------------+                     |    PK, Auth, DF)    |
     |                     |                     |                     |

                 FID : Flow identification
                 RV  : The volume of data that the sender requests
                 AV  : The volume of data that the receiver grants
                 TTL : Time limit for the permission
                 RT  : Refresh time for soft-state
                 PK   : The certificate of a public key
                 Auth : The authentication field
                 DF   : Defense object

                  Figure 3: Basic operation of prevention







Hong & Schulzrinne       Expires April 17, 2014                [Page 14]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


8.  PBS Detection Algorithm (PDA)

   Routers that do not have PBS functionality cannot generate bogus data
   packets because they do not have the shared key.  A compromised PBS
   NE that knows the shared key, however, can generate and insert attack
   packets when symmetric key cryptography is used in IPsec AH.
   Furthermore, an off-path attacker (i.e., external attacker) might
   obtain the shared key by controlling compromised PBS NEs.  In
   addition, compromised routers, which may or may not be PBS NEs, can
   drop legitimate packets.  To prevent these attacks in this Byzantine
   network, PBS NSLP requires monitoring of network traffic and
   detecting attacks.  The detection algorithm is called the PBS
   Detection Algorithm (PDA).  PDA uses a soft-state mechanism of PBS
   NSLP, where a sender periodically sends the Query message that
   contains the volume of data it has sent after permission was granted.
   The receiver compares the volume of data in the signaling message
   with the volume of data that has been received.  If they differ, the
   receiver suspects that there is an attack.  Based on the detection, a
   receiver requests the senders to respond to the attack (using methods
   like changing the encryption algorithm or changing the path) using
   the indication in the Permission message.

8.1.  Basic Operation of PDA

   Figure 4 shows the example of the PDA basic operation.  The first two
   signaling messages (Query and Permission messages) are used to set up
   the permission state for a flow between the sender and the receiver.
   We assume that the receiver grants permission to the sender to send a
   flow of size 10 MB.  After setting up the permission state, the
   sender sends data packets whose total volume is 1 MB.  There is an
   attacker A who spoofs the sender's address and has the shared key,
   and it sends additional attack packets whose total volume is 2 MB
   with the correct IPsec header.  After the soft-state period T, the
   sender sends a Query message indicating that it has sent 1 MB of
   data.  The receiver can detect the attack by comparing the volume (1
   MB) in the Query message and total volume of data (3 MB) that it has
   received.  After the receiver detects the attack, it sends the
   Permission messages with an indication to use public key cryptography
   to generate the authentication field of IPsec header.  After that,
   the attack packets are dropped at a PBS NE because of the IPsec
   verification failure.










Hong & Schulzrinne       Expires April 17, 2014                [Page 15]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


      Sender            PBS NE                PBS NE            Receiver
     |                     |                     |                     |
     |   Q (RV = 10 MB)    |                     |                     |
   --+-------------------->|    Q (RV = 10 MB)   |                     |
   ^ |                     +-------------------->|    Q (RV = 10 MB)   |
   | |                     |                     +-------------------->|
   | |                     |                     |   P (AV = 10 MB)    |
   | |                     |   P (AV = 10 MB)    |< -------------------+
   | |   P (AV = 10 MB)    |< -------------------+                     |
   | |< -------------------+                     |                     |
   | |                Data flow (size = 1 MB) / IPsec (symm key)       |
   | |================================================================>|
   | |                     |                     |                     |
     |                     |                     |                     |
   T |                     |                     |                     |
     |       Attacker    Attack flow (size = 2 MB) / IPsec (symm key)  |
   | |             |==================================================>|
   | | (spoofs sender's address,                 |                     |
   | |  and has the shared key)                  |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   V |   Q (SV = 1 MB)     |                     |                     |
   --+-------------------->|    Q (SV = 1 MB)    |                     |
     |                     +-------------------->|    Q (SV = 1 MB)    |
     |                     |                     +-------------------->|
     |                     |                     |P (public key crypto)|
     |                     |P(public key crypto) |< -------------------+
     |P (public key crypto)|< -------------------+                     |
     |< -------------------+                     |                     |
     |                     |                     |                     |

                 RV : The volume of data that the sender requests
                 AV : The volume of data that the receiver grants
                 SV : The volume of data that the sender has sent

        Figure 4: Basic operation of PBS detection algorithm  (PDA)

8.2.  Example of Detecting a Packet Drop Attack (Black Hole Attack)

   Drop attack is one of the on-path attacks.  It is also known as the
   black hole attack.  A compromised router drops all packets (including
   signaling messages) or selected packets (e.g., every n packets).  PDA
   can detect the packet dropping attacks by a compromised router.






Hong & Schulzrinne       Expires April 17, 2014                [Page 16]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


8.2.1.  Drop All Packets

   As shown in Figure 5, when a compromised router drops all packets,
   since the sender does not receive a Permission message after two
   tries, the sender suspects that the packets have been dropped.
   Therefore, the sender changes the path.  To change the path, the
   sender can use a relay node used for tunneling or path diversity by
   multihoming.

      Sender               PBS NE               Attacker        Receiver
        |                     |                     |                  |
        |        Query        |                     |                  |
   -----+-------------------->|      Query          |                  |
     ^  |                     +-------------------->|                  |
     |  |                     |                     |                  |
     |  |                     |                     |                  |
   T.O. |                     |                     |                  |
     |  |                     |                     |                  |
     |  |                     |                     |                  |
     V  |        Query        |                     |                  |
   -----+-------------------->|      Query          |                  |
     ^  |                     +-------------------->|                  |
     |  |                     |                     |                  |
     |  |                     |                     |                  |
   T.O. |                     |                     |                  |
     |  |                     |                     |                  |
     |  |                     |                     |                  |
     V  |                     |                     |                  |
   -----+                     |                     |                  |
    (Change path)

           Figure 5: Drop all packets (signal and data packets)

8.2.2.  Drop Selected Packets (Drop Only Data Packets)

   As shown in Figure 6, when a compromised router drops some data
   packets, the amount of volume (0 byte in the figure) that the
   receiver has received and the volume information (1 MB) in the Query
   message differ, so the receiver suspects that packets have been
   dropped and sends a Permission message indicating a request to change
   path.

   Data packet loss due to natural causes is also possible, and this is
   not an attack.  Because of PDA, the natural packet loss might be
   regarded as a dropping attack.  To avoid this, we apply a threshold-
   based decision scheme.  If the difference between the amount of
   delivered packets and the volume information in the Query message is
   within a defined threshold, this is not regarded as a dropping



Hong & Schulzrinne       Expires April 17, 2014                [Page 17]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


   attack.  The threshold value can be defined by the receiver based on
   the network environment.  PDA can also detect the heavy congestion
   link where there is significant packet loss.

   Sender               PBS NE               Attacker           Receiver
     |                     |                     |                     |
     |   Q (RV = 10 MB)    |                     |                     |
   --+-------------------->|    Q (RV = 10 MB)   |                     |
   ^ |                     +-------------------->|    Q (RV = 10 MB)   |
   | |                     |                     +-------------------->|
   | |                     |                     |    P (AV = 10 MB)   |
   | |                     |    P (AV = 10 MB)   |< -------------------+
   | |    P (AV = 10 MB)   |< -------------------+                     |
   | |< -------------------+                     |                     |
   | |                Data flow (size = 1 MB)    |                     |
   | |==========================================>X                     |
   | |                     |                     |                     |
     |                     |                     |                     |
   T |                     |                     |                     |
     |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   V |    Q (SV = 1 MB)    |                     |                     |
   --+-------------------->|    Q (SV = 1 MB)    |                     |
     |                     +-------------------->|     Q (SV = 1 MB)   |
     |                     |                     +-------------------->|
     |                     |                     | P (change the path) |
     |                     | P (change the path) |< -------------------+
     | P (change the path) |< -------------------+                     |
     |< -------------------+                     |                     |
     |                     |                     |                     |

                 RV : The volume of data that the sender requests
                 AV : The volume of data that the receiver grants
                 SV : The volume of data that the sender has sent

                     Figure 6: Drop only data packets










Hong & Schulzrinne       Expires April 17, 2014                [Page 18]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


9.  PBS NSLP Messages Format

   A PBS NSLP message consists of a common header and type-length-value
   (TLV) objects.

9.1.  Common Header

   All PBS NSLP messages carry a common header.  The Figure 7 shows the
   common header format.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message Type |    Reserved   |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 7: Common PBS NSLP Header

   The fields in the common header are the following.

   Message type (8 bits):

   o  1=Query

   o  2=Permission

9.2.  Message Formats

9.2.1.  Query

   Query message is used to request permission and monitor traffic flow.

   Query = Common Header / Flow Identification / Message Sequence Number
   / Requested Volume / Sent Volume / Public Key Certificate /
   Authentication Data

9.2.2.  Permission

   Permission message is used to set up, remove, and modify permission
   state for a flow.

   Permission = Common Header / Flow Identification / Message Sequence
   Number / Allowed Volume / TTL / Refresh Time / Public Key Certificate
   / Defense / Authentication Data







Hong & Schulzrinne       Expires April 17, 2014                [Page 19]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


9.3.  Object Format

   PBS NSLP objects begin with the common object header.  The Figure 8
   shows the common object header format.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|B|r|r|  Object Type  |r|r|r|r|          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 8: Common Object Header

   Object Type (8 bits): The type of the object.

   AB=00 ("Mandatory"): If the object is not understood, the entire
   message containing it MUST be rejected, and an error message sent
   back.

   AB=01 ("Ignore"): If the object is not understood, it MUST be deleted
   and the rest of the message processed as usual.

   AB=10 ("Forward"): If the object is not understood, it MUST be
   retained unchanged in any message forwarded as a result of message
   processing, but not stored locally.

   Length (16 bits): The byte length of the object.

9.4.  PBS NSLP Objects

9.4.1.  Flow Identification (FID)

   Type: FID

   Length: Variable

   Version (4 bits): IP address version (version 4 or 6).

   Protocol (8 bits): Protocol identifier.

   Source Port (16 bits): The port number of the sender.

   Destination Port (16 bits): The port number of the intended receiver.

   Source IP Address (variable): IP address of the sender.

   Destination IP Address (variable): IP address of the intended
   receiver.



Hong & Schulzrinne       Expires April 17, 2014                [Page 20]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version  |   Protocol  |        Reserved                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Source Port             |    Destination Port           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                  Source IP Address                          //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                  Destination IP Address                     //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.4.2.  Message Sequence Number

   Type: Message-Seq

   Length: 32 bits

   Value: An incrementing sequence number.  Used to prevent a replay
   attack.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Message Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.4.3.  Requested Volume (RV)

   Type: Req-vol

   Length: 32 bits

   Value: The number of bytes that a sender requests for a flow.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Requested Volume (RV)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.4.4.  Sent Volume (SV)

   Type: Send-vol

   Length: 32 bits

   Value: The number of bytes that a sender has sent since the sender



Hong & Schulzrinne       Expires April 17, 2014                [Page 21]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


   received the permission.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Sent Volume (SV)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.4.5.  Allowed Volume (AV)

   Type: Allow-vol

   Length: 32 bits

   Value: The number of bytes that a receiver allows for a flow.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Allowed Volume (AV)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.4.6.  TTL

   Type: TTL

   Length: 32 bits

   Value: The time limit for the permission state of a flow.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           TTL                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.4.7.  Refresh Time

   Type: Refresh

   Length: 32 bits

   Value: The period for the soft-state.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Refresh Time                            |



Hong & Schulzrinne       Expires April 17, 2014                [Page 22]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.4.8.  Public Key Certificate

   Type: PK-cert

   Length: Variable

   Value: The X.509 certificate of a node's public key.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                Public Key Certificate                       //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.4.9.  Defense

   Type: Defense

   Length: Variable

   Solution (8 bits): The indicated solution against an attack.

   o  1=No action

   o  2=IPsec with symmetric key cryptography for a flow

   o  3=IPsec with public key cryptography for a flow

   o  4=Change the path to avoid the compromised router

   IPsec authentication algorithm (8 bits): The cryptography algorithm
   for the IPsec authentication field.

   o  1=HMAC-SHA1

   o  2=HMAC-SHA-256

   o  3=HMAC-MD5

   o  4=RSA-1024

   o  5=RSA-2048

   o  6=ECC-160





Hong & Schulzrinne       Expires April 17, 2014                [Page 23]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


   o  7=ECC-224

   o  8=DSA-1024

   o  9=DSA-2048

   o  10=Algorithm from X.509 certificate


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Solution    |Auth Algorithm |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPsec key (variable): The key for the IPsec authentication field.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                  IPsec Key                                  //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.4.10.  Authentication Data

   Type: Auth-data

   Length: Variable

   Value: The encrypted data of message fields for authentication and
   integrity.  Public key is used for the encryption.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                  Authentication Data                        //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+














Hong & Schulzrinne       Expires April 17, 2014                [Page 24]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


10.  Security Considerations

   This document describes how to authorize the network traffic between
   a sender and a receiver along the data path.  The authorization is
   controlled by a receiver by granting the permission to a sender.  To
   prevent spoofing of the legitimate sender's address, IPsec AH is used
   for data packets.

   There are two IPsec headers; the Authentication Header (AH) and
   Encapsulating Security Payload (ESP).  IPsec ESP [RFC4303] can also
   be used for authentication.  However, IPsec AH [RFC4302] suffices the
   authentication of packets.

   The Cryptographically Generated Addresses (CGA) [RFC3972] can work
   with IPv6 to bind an IPv6 address and a public key, instead of a
   public key certificate, but cannot work with IPv4.

   An attacker can send a lot of signaling messages to make the PBS NE
   incur computational overhead to validate them.  To resolve this
   problem, PBS NSLP can use a puzzle-based mechanism for per-
   computation fairness.  Since a sender has to spend its CPU time to
   solve a puzzle before requesting permission, it can provide fairness.





























Hong & Schulzrinne       Expires April 17, 2014                [Page 25]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


11.  Acknowledgements

   This work was supported by InterDigital Communications, LLC.  The
   authors would like to thank Swen Weiland for his help in implementing
   the PBS NSLP.














































Hong & Schulzrinne       Expires April 17, 2014                [Page 26]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


12.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC4080]  Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
              Bosch, "Next Steps in Signaling (NSIS): Framework",
              RFC 4080, June 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5971]  Schulzrinne, H. and R. Hancock, "GIST: General Internet
              Signalling Transport", RFC 5971, October 2010.


























Hong & Schulzrinne       Expires April 17, 2014                [Page 27]

Internet-Draft   PBS NSLP: Network Traffic Authorization    October 2013


Authors' Addresses

   Se Gi Hong
   Hughes Network Systems
   11717 Exploration Lane
   Germantown, MD  20876
   US

   Email: segi.hong@hughes.com


   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Email: hgs@cs.columbia.edu
































Hong & Schulzrinne       Expires April 17, 2014                [Page 28]