Internet DRAFT - draft-hong-nsis-pbs-nslp
draft-hong-nsis-pbs-nslp
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]
