Network Working Group S. Hong Internet-Draft H. Schulzrinne Intended status: Standards Track Columbia U. Expires: January 15, 2009 July 14, 2008 PBS NSLP: Network Traffic Authorization draft-hong-nsis-pbs-nslp-01.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 January 15, 2009. Hong & Schulzrinne Expires January 15, 2009 [Page 1] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 Abstract This document describes the NSIS Signaling Layer protocol (NSLP) for network traffic authorization in the Internet, the Permission-Based Sending (PBS) NSLP. This NSLP aims to prevent Denial-of-Service (DoS) attacks and other forms of unauthorized traffic. In the PBS NSLP, a receiver grants a sender a permission that gives the sender the authority to send data. Signaling installs and maintains the permission state of routers for a data flow. The PBS NSLP has a detection algorithm, the PBS Detection Algorithm (PDA), that monitors attacks. To authenticate 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 January 15, 2009 [Page 2] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Distributed and Stateful System . . . . . . . . . . . . . 7 4.2. Deployable and Scalable System . . . . . . . . . . . . . . 7 4.3. DoS Defense Mechanism . . . . . . . . . . . . . . . . . . 7 4.3.1. DoS Detection Mechanism . . . . . . . . . . . . . . . 7 4.3.2. Reaction Mechanism Against DoS Attacks . . . . . . . . 8 5. PBS Components . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. On-path Signaling . . . . . . . . . . . . . . . . . . . . 10 5.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Traffic Management . . . . . . . . . . . . . . . . . . . . 11 6. PBS NSLP Signaling Messages . . . . . . . . . . . . . . . . . 12 6.1. PBS NSLP Signaling Message Types . . . . . . . . . . . . . 12 6.1.1. Query Message . . . . . . . . . . . . . . . . . . . . 12 6.1.2. Permission Message . . . . . . . . . . . . . . . . . . 13 6.2. Basic Operation of PBS NSLP . . . . . . . . . . . . . . . 14 7. PBS Detection Algorithm (PDA) . . . . . . . . . . . . . . . . 16 7.1. Basic Operation of PDA . . . . . . . . . . . . . . . . . . 16 7.2. Example of Detecting a Packet Drop Attack (Black Hole Attack) . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2.1. Drop All Packets . . . . . . . . . . . . . . . . . . . 17 7.2.2. Drop Selected Packets (Drop Only Data Packets) . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 10. Normative References . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Hong & Schulzrinne Expires January 15, 2009 [Page 3] Internet-Draft PBS NSLP: Network Traffic Authorization July 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 can inject 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 rate-limit to very small volume for high-assurance networks. 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 PBS Detection Algorithm (PDA) monitors data flows, and then detects and identifies the attacks. After detecting the attacks, the PBS NSLP uses an existing security protocol, IPsec, for the authentication of packets. To avoid the path to the compromised router that drops legitimate packets, the PBS NSLP triggers the sender to change the data path. Below, Section 3 gives an overview of the design. The PBS NSLP components are presented in Section 4. Section 5 describes the PBS NSLP signaling messages. Section 6 presents the PBS Detection Algorithm (PDA). Section 7 describes security considerations. Hong & Schulzrinne Expires January 15, 2009 [Page 4] Internet-Draft PBS NSLP: Network Traffic Authorization July 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 January 15, 2009 [Page 5] Internet-Draft PBS NSLP: Network Traffic Authorization July 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 a sender who requests it by an intended receiver. 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 addition attack: An attacker who inserts bogus packets along the data path. 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. As NSIS Framework [RFC4080] describes, the information in the flow identification are: source IP address, destination IP address, protocol identifier and higher (port) addressing, flow label (typical for IPv6), SPI field for IPsec encapsulated data, and DSCP/TOS field. Hong & Schulzrinne Expires January 15, 2009 [Page 6] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 4. Design Overview There are three features of the PBS: distributed and stateful system, deployable and scalable system, and DoS defense mechanism. 4.1. Distributed and Stateful System The PBS NSLP is a distributed and stateful system. Since the permission is granted by the receiver of a flow, it does not require a central server to control the permissions. Since signaling installs the permission state of routers for data flows, routers do not need to contact a central server to maintain their permission state for a data flow. A subset of routers keeps state for a data flow, and monitor whether the flow is authorized. The permission state is refreshed periodically by a soft-state mechanism. This soft-state mechanism supports the robustness of the system. 4.2. Deployable and Scalable System Incoming data packets are screened by the permission state using the flow identification of the packets, and existing security protocols, such as IPsec, are used to distinguish the legitimate packets from bogus packets. This makes it possible for PBS NSLP to be applied to current networks without modification of current protocols (e.g., the PBS NSLP does not change IP and TCP packet header). Not all routers need to be aware of PBS NSLP. The flow identification of the data packets are used to determine whether the data flow is authorized or not. To reduce overhead, only the data packets from the sender that are affected by the attacks use a security protocol for the authentication of the data flow. 4.3. DoS Defense Mechanism 4.3.1. DoS Detection Mechanism Since there are many more legitimate packets than attack packets, it is not efficient to use security protocols, such as IPsec, for all data packets for packet authentication, especially in backbone networks. Therefore, a detection algorithm allows only the data packets from senders who affected by the attack to use a security protocol. The detection algorithm is called PBS Detection Algorithm (PDA). Based on the attack detection, the PBS NSLP triggers the reaction of the DoS attacks. The details of the PDA are described in Section 7. Hong & Schulzrinne Expires January 15, 2009 [Page 7] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 4.3.2. Reaction Mechanism Against DoS Attacks Three mechanisms to prevent the attacks are considered: limited permission for data flow, IPsec AH for authentication, and changing paths to avoid a compromised router. 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 PBS NSLP functionalities, the unauthorized packets without permission are dropped at the first router by default. In the open Internet in which some end users do not have PBS NSLP functionalities, the flows from the end users who do not have PBS NSLP funtionalities are rate-limited by default. 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. The flow identification of the data packets is encrypted to certify that the data packets and signaling packets have the same origin. In the Byzantine network, public key cryptography algorithm, such as ECDSA [ANSIX9.62], 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. For the data packets, a security protocol is not turned on by default to reduce computational overhead. The security protocol for data packets is triggered when attacks are detected by PDA. Thus, if no attack is detected, the data packet does not use IPsec, but if the attack is detected and the receiver requests authentication of data packets, IPsec is used to protect the packet from a spoofing attack. If the receiver considers the authentication of data packets even in the absence of attacks, it requests the sender to use IPsec for data flow. For the signaling packets, a security protocol is used by default. Since attackers can forge signaling messages to install bogus permission state along the path, authentication of the signaling messages is needed. Since signaling messages are not generated Hong & Schulzrinne Expires January 15, 2009 [Page 8] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 frequently, applying IPsec to signaling packets does not cause significant overhead. To avoid a compromised router that drops legitimate packets, changing data flow path is needed. 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 January 15, 2009 [Page 9] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 5. PBS Components 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 regenerates the signaling message to forward it to the next node when it receives the PBS NSLP message. 5.2. Authorization The authorization component decides the grants of permission (amount of volume) for a flow. One of main objectives of this component is Hong & Schulzrinne Expires January 15, 2009 [Page 10] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 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 detection of and solution against the attack are described in Section 7. 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 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 permssion, 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 January 15, 2009 [Page 11] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 6. PBS NSLP Signaling Messages 6.1. PBS NSLP Signaling Message Types There are two message types; namely Query (Q) and Permission (P) messages. 6.1.1. Query Message The Query message Q is sent by a sender to request permission to send data. It contains the following fields: o Message type flag (M): Set to M=0 to indicate that the signaling message is the Query message. o Flow identifier of the request o Requested volume (RV): This field contains the number of bytes that a sender requests. o Volume information (V): This field contains the number of bytes that a sender has sent since the sender received the permission from the intended receiver for the flow. This information is used to monitor the DoS attacks. o Public key (Ks): This field contains the sender's public key which is certificated by the trusted third party, a certificate authority (CA). This public key is used to verify the authentication of the sender's packets. An X.509 certificate [RFC5280] is used for the digital signature. o Cryptography algorithm (C): The cryptography algorithm to be used for the authentication field in IPsec AH. * C=00: RSA * C=01: DSA * C=10: ECDSA * C=11: HMAC Hong & Schulzrinne Expires January 15, 2009 [Page 12] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 6.1.2. Permission Message The Permission message P is sent by the receiver who grants the permission to the sender. This message is used to set up (grant), remove (revoke) and modify permission state for a flow. This message is sent after receiving the Query message, and it can be sent when a receiver wants to change (revoke and modify) the permission state and change security mechanism without receiving the Query message. It contains the following fields: o Message type flag (M): Set to M=1 to indicate the message is the Permission message. o Flow identifier of the request o Allowed volume (AV): This field contains the number of bytes that a receiver grants a sender for the request. o Time limit (TTL): This field contains the time limit for the permission of the data flow. It is used to prevent unused permission state from being in the permission state forever. o Refresh period (T): A sender sends a Query message every period T. It is used for the soft-state of the permission. The parameter T can be omitted when the permission state does not last long enough, and the value of T can be optimized depending on the application. o Solution flags (S): S consists of S1 and S2 flags (S=S1S2). * S=00: No reaction. * S=01: The sender needs to use IPsec AH with symmetric key cryptography (HMAC) for the data flow. * S=10: The sender needs to use IPsec AH with public key cryptography (ECDSA) for the data flow. * S=11: The sender needs to change path for the data flow. o Public key (Kr): The receiver's public key which is certificated by a CA. An X.509 certificate is used for the digital signature. o Cryptography algorithm (C): The cryptography algorithm to be used for the authentication field in IPsec AH. Hong & Schulzrinne Expires January 15, 2009 [Page 13] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 * C=00: RSA * C=01: DSA * C=10: ECDSA * C=11: HMAC 6.2. Basic Operation of PBS NSLP Figure 2 shows how permissions are set up between a sender and a receiver. The Query and Permission messages are used for handshake to set up permission state along the path. A sender sends a receiver the Query message to request permission. An attacker can flood the receiver by sending a lot of Query messages. To prevent this attack, proof-of-work can be used for rate limiting the Query message. The sender's public key, Ks, is distributed to the routers and the receiver. The key is used to authenticate the signaling messages that the sender generates. 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 Query message is protected by IPsec. The authentication field of IPsec AH is generated by the private key of the sender. The receiver sends the sender the Permission messages to allow incoming data packets along the reverse path of the Query message. The receiver's public key, Kr, is distributed to the routers and the sender. It is used to authenticate the signaling messages that the receiver generates. The Permission message is protected by IPsec. The authentication field of IPsec AH is generated by the private key of the receiver. After the permission state is set up between the sender and the receiver, the sender can send the allowed volume (AV) of data to the receiver during the time limit (TTL). The sender sends the Query messages every refresh period T since PBS NSLP is a soft-state protocol. The receiver sends the sender the Permission message after receiving the Query message. Hong & Schulzrinne Expires January 15, 2009 [Page 14] Internet-Draft PBS NSLP: Network Traffic Authorization July 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 Hong & Schulzrinne Expires January 15, 2009 [Page 15] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 7. 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 a receiver compare the volume of data in the signaling message with the volume of data that has been received. 7.1. Basic Operation of PDA PDA uses the PBS NSLP signaling messages: Query and Permission messages. Figure 3 shows the basic operation of PDA. The first two signaling messages are to set up the permission state for a flow between the sender and the receiver. We assume that the receiver grants 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 it sends additional attack packets whose total volume is 2 MB. After 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 IPsec AH with public key cryptography, others cannot generate 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 use IPsec AH (S=10). After the sender receives the Permission message, the sender sends data packets using IPsec AH. Therefore, the attack packets are dropped at a PBS NE because of the IPsec verification process. If the receiver trusts the network (i.e., the routers are not compromised), it can request the sender to use symmetric key cryptography by setting solution flags to S=01. In this case, IKEv2 [RFC4306] can be used to set up the shared key along the path. Since the PBS NSLP uses a peer-to-peer approach, the adjacent nodes use IKEv2 to set up the shared key. Otherwise, a group key exchange protocol, such as group Diffie-Hellman [GDH], is needed. Setting up a shared key causes additional message overhead. Hong & Schulzrinne Expires January 15, 2009 [Page 16] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 Sender PBS NE PBS NE Receiver | | | | | Query | | | --+-------------------->| Query | | ^ | +-------------------->| Query | | | | +-------------------->| | | | | Permission (AV=10MB)| | | | Permission (AV=10MB)|< -------------------+ | | Permission (AV=10MB)|< -------------------+ | | |< -------------------+ | | | | | Data flow (1 MB) | | |================================================================>| | | | | | | | | | T | | | | | Attacker | Attack flow (2 MB) | | | |==================================================>| | | (spoofing sender's address) | | | | | | | | | | | | | | | | | | | | | | | | | | | V | Query (V=1MB) | | | --+-------------------->| Query (V=1MB) | | | +-------------------->| Query (V=1MB) | | | +-------------------->| | | | Permission (S=10) | | | Permission (S=10) |< -------------------+ | Permission (S=10) |< -------------------+ | |< -------------------+ | | | | | | Figure 3: Basic operation of PBS detection algorithm (PDA) 7.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. 7.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 January 15, 2009 [Page 17] Internet-Draft PBS NSLP: Network Traffic Authorization July 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) 7.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 (S=11). After receiving the Permission message, the sender changes the path in order to avoid the compromised router. Hong & Schulzrinne Expires January 15, 2009 [Page 18] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 Sender PBS NE Attacker Receiver | | | | | Query | | | --+-------------------->| Query | | ^ | +-------------------->| Query | | | | +-------------------->| | | | | Permission (AV=10MB)| | | | Permission (AV=10MB)|< -------------------+ | | Permission (AV=10MB)|< -------------------+ | | |< -------------------+ | | | | | Data flow (1 MB) | | | |==========================================>| | | | | | | | | | | T | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V | Query (V=1MB) | | | --+-------------------->| Query (V=1MB) | | | +-------------------->| Query (V=1MB) | | | +-------------------->| | | | Permission (S=11) | | | Permission (S=11) |< -------------------+ | Permission (S=11) |< -------------------+ | |< -------------------+ | | | | | | Figure 5: Drop only data packets Hong & Schulzrinne Expires January 15, 2009 [Page 19] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 8. 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 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 be also used for the authentication. However, IPsec AH [RFC4302] suffices the authentication of packets. Hong & Schulzrinne Expires January 15, 2009 [Page 20] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 9. Acknowledgements This work is supported by InterDigital Communications, LLC. Hong & Schulzrinne Expires January 15, 2009 [Page 21] Internet-Draft PBS NSLP: Network Traffic Authorization July 2008 10. Normative References [ANSIX9.62] ANSI X 9.62, "American national standard for financial services-Public key cryptography for the financial services industry: The elliptic curve digital signature algorithm (ECDSA)", American National Standard Institute , 1998. [GDH] Steiner, M., Tsudik, G., and M. Waidner, "Diffie-Hellman Key Distribution Extended to Group Communication", Proceedings of the ACM CCS, New Delhi, India, March 1996. [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. [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. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 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 January 15, 2009 [Page 22] Internet-Draft PBS NSLP: Network Traffic Authorization July 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 January 15, 2009 [Page 23] Internet-Draft PBS NSLP: Network Traffic Authorization July 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 January 15, 2009 [Page 24]