[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04

Network Working Group                                            S. Hong
Internet-Draft                                            H. Schulzrinne
Intended status: Standards Track                             Columbia U.
Expires: July 16, 2010                                  January 12, 2010


                PBS NSLP: Network Traffic Authorization
                    draft-hong-nsis-pbs-nslp-03.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 the proactive approach of explicitly granting permissions
   and the reactive approach of monitoring and reacting against the
   attacks.  Signaling installs and maintains the permission state of
   routers for a data flow.  PBS NSLP uses two security mechanisms:
   message security in an end-to-end fashion and channel security in a
   hop-by-hop fashion.  The message security is for protecting the
   integrity of the message on end-to-end traffic and channel security
   is for protecting the integrity and confidentiality between adjacent
   nodes.  These security mechanisms enable the secure distribution of
   shared keys, as well as protection of signaling messages.  To
   authenticate data packets, the PBS NSLP requests a sender to use an
   existing security protocol, the IPsec Authentication Header (AH).
   This allows routers to drop bogus packets by using an IP packet
   filter.  To avoid a compromised router that drops legitimate packets,
   the PBS NSLP triggers the sender to change the data flow path.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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.



Hong & Schulzrinne        Expires July 16, 2010                 [Page 1]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 16, 2010.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.
































Hong & Schulzrinne        Expires July 16, 2010                 [Page 2]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


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)  . . . . . . . . . . . . . . . . 14
     8.1.  Basic Operation of PDA . . . . . . . . . . . . . . . . . . 14
     8.2.  Example of Detecting a Packet Drop Attack (Black Hole
           Attack)  . . . . . . . . . . . . . . . . . . . . . . . . . 15
       8.2.1.  Drop All Packets . . . . . . . . . . . . . . . . . . . 15
       8.2.2.  Drop Selected Packets (Drop Only Data Packets) . . . . 16
   9.  PBS NSLP Messages Format . . . . . . . . . . . . . . . . . . . 18
     9.1.  Common Header  . . . . . . . . . . . . . . . . . . . . . . 18
     9.2.  Message Formats  . . . . . . . . . . . . . . . . . . . . . 18
       9.2.1.  Query  . . . . . . . . . . . . . . . . . . . . . . . . 18
       9.2.2.  Permission . . . . . . . . . . . . . . . . . . . . . . 18
     9.3.  Object Format  . . . . . . . . . . . . . . . . . . . . . . 19
     9.4.  PBS NSLP Objects . . . . . . . . . . . . . . . . . . . . . 19
       9.4.1.  Flow Identification (FID)  . . . . . . . . . . . . . . 19
       9.4.2.  Message Sequence Number  . . . . . . . . . . . . . . . 20
       9.4.3.  Requested Volume (RV)  . . . . . . . . . . . . . . . . 20
       9.4.4.  Sent Volume (SV) . . . . . . . . . . . . . . . . . . . 20
       9.4.5.  Allowed Volume (AV)  . . . . . . . . . . . . . . . . . 21
       9.4.6.  TTL  . . . . . . . . . . . . . . . . . . . . . . . . . 21
       9.4.7.  Refresh Time . . . . . . . . . . . . . . . . . . . . . 21
       9.4.8.  Public Key Certificate . . . . . . . . . . . . . . . . 22
       9.4.9.  Defense  . . . . . . . . . . . . . . . . . . . . . . . 22
       9.4.10. Authentication Data  . . . . . . . . . . . . . . . . . 23
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27




Hong & Schulzrinne        Expires July 16, 2010                 [Page 3]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


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.  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.  If it detects attacks, the signaling message triggers a
   reaction against the detected attack.

   The PBS NSLP exploits the General Internet Signaling Transport (GIST)
   [I-D.ietf-nsis-ntlp] 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 July 16, 2010                 [Page 4]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


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 July 16, 2010                 [Page 5]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


3.  Terminology

   The terminology defined by GIST [I-D.ietf-nsis-ntlp] 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 July 16, 2010                 [Page 6]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


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 functionality does not need to be implemented in all
   routers.  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 moderate to be applied
   to the backbone networks.

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
   router by default.  In the open Internet in which some end users do



Hong & Schulzrinne        Expires July 16, 2010                 [Page 7]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


   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.

   Two reaction mechanisms against the attacks are considered: IPsec AH
   and changing paths to avoid a compromised router.

   To prevent an attacker from forging the flow identification of a
   packet (e.g., from spoofing the source address), the authentication
   algorithm is used to protect the legitimate packets from the attack
   packets.  The IPsec Authentication Header (AH) [RFC4302] is used for
   authentication and integrity of packets.

   In the Byzantine network, public key cryptography algorithm, such as
   RSA and ECC, is used for the authentication data field in IPsec AH.
   If a symmetric key cryptography algorithm is used for the
   authentication of packets, the on-path attacker (compromised router)
   can generate the encrypted data since it has the shared key.

   In the trustworthy network, symmetric key cryptography algorithm,
   such as HMAC [RFC2104], can be used for the authentication data field
   in IPsec AH since there is no on-path attacker in the trustworthy
   network.

   To avoid a compromised router that drops legitimate packets, the data
   flow path needs to be changed.  To change the data path, a relay node
   that is far away from the current path can be used or path diversity
   by multihoming can be used.  The way of changing path is out of scope
   of the PBS NSLP.











Hong & Schulzrinne        Expires July 16, 2010                 [Page 8]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


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)
   [I-D.ietf-nsis-ntlp] handles all incoming signaling messages and it
   passes the signaling messages related to the PBS NSLP to the PBS
   NSLP.  The delivery of signaling messages is handled using a peer-to-
   peer approach.  Thus, each node that is aware of PBS NSLP forwards
   the signaling message to the next node 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



Hong & Schulzrinne        Expires July 16, 2010                 [Page 9]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


   component is to detect and identify the attack.  The authorization
   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 handles all incoming packets, including
   signaling messages and data packets.  It passes signaling messages up
   to NTLP (GIST).  Based on the permission state of a flow that is
   stored in routers aware of the PBS NSLP, the traffic manager screens
   the data packets to see whether the data packets are authorized.  IP
   packet filter is used to filter the unauthorized packets.  To see
   whether the flow exceeds the given permission, it calculates the
   volume of the data flow that it has received or sent since the
   permission state was set up.  The authentication of packets is
   verified by the traffic management component.
































Hong & Schulzrinne        Expires July 16, 2010                [Page 10]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


6.  PBS NSLP Operation

6.1.  Basic Operation

   There are two message types; namely Query (Q) and Permission (P)
   messages.  The Query and Permission messages are used for handshake
   to set up permission state along the path.  The Query message is sent
   to request permission for the receiver.  The Permission message is
   sent by the receiver who grants the permission to the sender.  The
   Permission message is used to set up (grant), remove (revoke) and
   modify the permission state for a data flow.

   Figure 2 shows how permissions are set up between a sender and a
   receiver.  A sender sends a receiver the Query message to request
   permission.  The requested application is described in the flow
   identifier.  The Query message installs the reverse routing state in
   GIST for the Permission message path.

   The receiver sends the sender the Permission messages to allow
   incoming data packets along the reverse path of the Query message.

   After the permission state is set up between the sender and the
   receiver, the sender can send the allowed volume (permission) of data
   to the receiver during the time limit.

   The sender sends the Query messages every refresh period since PBS
   NSLP is a soft-state protocol.  The receiver sends the sender the
   Permission message after receiving the Query message.























Hong & Schulzrinne        Expires July 16, 2010                [Page 11]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


   Sender               PBS NE                PBS NE            Receiver
     |                     |                     |                     |
     |       Query         |                     |                     |
   --+-------------------->|        Query        |                     |
   ^ |                     +-------------------->|       Query         |
   | |                     |                     +-------------------->|
   | |                     |                     |     Permission      |
   | |                     |      Permission     |< -------------------+
   | |    Permission       |< -------------------+                     |
   | |< -------------------+                     |                     |
   | |                     |   Data flow         |                     |
   | |================================================================>|
   | |                     |                     |                     |
     |                     |                     |                     |
   T |                     |                     |                     |
     |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   | |                     |                     |                     |
   V |       Query         |                     |                     |
   --+-------------------->|       Query         |                     |
     |                     +-------------------->|       Query         |
     |                     |                     +-------------------->|
     |                     |                     |     Permission      |
     |                     |      Permission     |< -------------------+
     |     Permission      |< -------------------+                     |
     |< -------------------+                     |                     |
     |                     |                     |                     |

                   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 July 16, 2010                [Page 12]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


7.  Security of Messages

   The signaling message should not be forgeable.  Thus, the fields in
   the signaling messages should be protected by a security algorithm.
   The PBS NSLP uses public key cryptography algorithm to protect the
   fields in the signaling messages.  This encryption supports the
   authentication and integrity of the messages.  To bind the public key
   and the sender, X.509 certificate [RFC5280] is used, and the
   certificate is carried in the signaling messages.  An attack can
   flood the receiver and link by sending a lot of Query messages.  To
   prevent this attack, proof-of-work can be used for rate limiting the
   Query message.

   To prevent an attacker from forging the flow identification of a data
   packet, IPsec AH is used for the authentication and integrity of
   packets.  IPsec is used for end-to-end (transport mode) or two secure
   gateways (tunnel mode).  Thus, routers do not check IPsec if the
   destination address is not the router's address.  However, PBS NSLP
   functionality allows PBS NEs to check the IPsec that uses the
   transport mode between the two end hosts (sender and receiver).

   For the authentication data field in IPsec AH, symmetric key
   cryptography, such as HMAC, can be used in the trustworthy network,
   and public key cryptography, such as RSA and ECC, can be used in the
   Byzantine network.  The receiver has the right to choose a
   cryptography algorithm for the data message based on the policy,
   network, and applications.  In the PBS NSLP functionality, security
   association (SA) and key are managed by signaling messages.  To
   securely distribute the shared key for IPsec AH, the Permission
   message carries the shared key with channel security protocol, TLS
   and DTLS, in a hop-by-hop fashion along the data path.




















Hong & Schulzrinne        Expires July 16, 2010                [Page 13]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


8.  PBS Detection Algorithm (PDA)

   When a symmetric key cryptography is used in IPsec AH, a compromised
   router on the data path that knows the shared key can flood the
   receiver.  The compromised router can also drop the packets.  Thus,
   to prevent the attacks in the Byzantine networks, the PBS NSLP has a
   mechanism that monitors the traffic flow and detects the attacks.
   This is called the PBS Detection Algorithm (PDA).  The PDA uses the
   existing PBS NSLP signaling messages.  A sender sends a signaling
   message that contains the volume of data that it has sent after the
   permission is granted.  The PBS NEs and the receiver compare the
   volume of data in the signaling message with the volume of data that
   has been received.

8.1.  Basic Operation of PDA

   Figure 3 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 a 10 MB size permission to the
   sender.

   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.

   After a refresh period T, the sender sends a Query message that
   contains a volume (1 MB) of data that it has sent.  Since the Query
   message is protected by public key cryptography, others cannot
   generate and modify the Query message.  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 change the cryptography algorithm of
   IPsec AH to public key cryptography, such as RSA and ECC.

   After the sender receives the Permission message, the sender changes
   the cryptography algorithm for the IPsec AH of data packets.
   Therefore, the attack packets are dropped at a PBS NE because of the
   new IPsec verification process.









Hong & Schulzrinne        Expires July 16, 2010                [Page 14]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


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


        Figure 3: 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 or drops
   selected packets.

8.2.1.  Drop All Packets

   In Figure 4, the attacker drops all packets including signaling
   messages.  Since the sender does not receive a Permission message
   after two tries, it suspects that the packets might have been
   dropped.  Therefore, it changes the path.



Hong & Schulzrinne        Expires July 16, 2010                [Page 15]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


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

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

8.2.2.  Drop Selected Packets (Drop Only Data Packets)

   In Figure 5, the attacker only drops data packets and forwards
   signaling messages.  The Query message contains the volume (1 MB) of
   data that the sender has sent.  Since the receiver has not received
   the data, the receiver can detect the packet drop attack.  The
   receiver sends a Permission message indicating a request to change
   path.  After receiving the Permission message, the sender changes the
   path in order to avoid the compromised router.


















Hong & Schulzrinne        Expires July 16, 2010                [Page 16]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


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


                     Figure 5: Drop only data packets

















Hong & Schulzrinne        Expires July 16, 2010                [Page 17]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


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 6 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 6: 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 July 16, 2010                [Page 18]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


9.3.  Object Format

   PBS NSLP objects begin with the common object header.  The Figure 7
   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 7: 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 July 16, 2010                [Page 19]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


    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 July 16, 2010                [Page 20]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


   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 July 16, 2010                [Page 21]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


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

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 July 16, 2010                [Page 22]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


   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 July 16, 2010                [Page 23]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


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.



































Hong & Schulzrinne        Expires July 16, 2010                [Page 24]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


11.  Acknowledgements

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














































Hong & Schulzrinne        Expires July 16, 2010                [Page 25]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


12.  Normative References

   [I-D.ietf-nsis-ntlp]
              Schulzrinne, H. and M. Stiemerling, "GIST: General
              Internet Signalling Transport", draft-ietf-nsis-ntlp-20
              (work in progress), June 2009.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

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

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
























Hong & Schulzrinne        Expires July 16, 2010                [Page 26]

Internet-Draft   PBS NSLP: Network Traffic Authorization    January 2010


Authors' Addresses

   Se Gi Hong
   Columbia University
   Dept. of Electrical Engineering
   500 West 120th Street
   New York, NY  10027
   US

   Email: segihong@cs.columbia.edu


   Henning Schulzrinne
   Columbia University
   Dept. of Computer Science
   1214 Amsterdam Avenue
   New York, NY  10027
   US

   Email: schulzrinne@cs.columbia.edu































Hong & Schulzrinne        Expires July 16, 2010                [Page 27]


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