Network Working Group S. Hong Internet-Draft H. Schulzrinne Intended status: Standards Track Columbia U. Expires: May 4, 2009 October 31, 2008 PBS NSLP: Network Traffic Authorization draft-hong-nsis-pbs-nslp-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 4, 2009. Hong & Schulzrinne Expires May 4, 2009 [Page 1] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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. Hong & Schulzrinne Expires May 4, 2009 [Page 2] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Hong & Schulzrinne Expires May 4, 2009 [Page 3] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 4] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 5] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 6] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 7] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 8] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 9] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 10] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 11] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 12] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 13] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 14] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 15] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 16] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 17] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 18] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 19] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 20] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 21] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 May 4, 2009 [Page 22] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 23] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 24] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 25] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 12. Normative References [I-D.ietf-nsis-ntlp] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", draft-ietf-nsis-ntlp-15 (work in progress), February 2008. [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 May 4, 2009 [Page 26] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 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 May 4, 2009 [Page 27] Internet-Draft PBS NSLP: Network Traffic Authorization October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Hong & Schulzrinne Expires May 4, 2009 [Page 28]