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]
