Network Working Group M. Shore Internet-Draft Cisco Systems Expires: August 30, 2006 February 26, 2006 The NLS Firewall Application draft-shore-nls-fw-00.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 August 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Network Layer Signaling Transport Layer provides a generalized packetization and messaging framework for on-path signaling. It is designed to carry a variety of "applications." This document describes a lightweight firewall pinholing application, designed to carry requests for firewall resources to firewalls along a path between two endpoints. Shore Expires August 30, 2006 [Page 1] Internet-Draft The NLS Firewall Application February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. NLS Firewall Messages . . . . . . . . . . . . . . . . . . . . 4 2.1. The NLS-FW Header . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Message Types . . . . . . . . . . . . . . . . . . . . 4 2.1.2. Version . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.3. Length . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. NLS-FW TLVs . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Network Access Identifier: Type=1 . . . . . . . . . . 6 2.2.2. Request TLV: Type=2 . . . . . . . . . . . . . . . . . 6 2.2.3. Lifetime TLV: Type=3 . . . . . . . . . . . . . . . . . 9 2.2.4. Response TLV: Type=4 . . . . . . . . . . . . . . . . . 10 2.2.5. Alert TLV: Type=5 . . . . . . . . . . . . . . . . . . 11 2.2.6. Teardown TLV: Type=6 . . . . . . . . . . . . . . . . . 11 3. NLS-FW Messaging Procedures . . . . . . . . . . . . . . . . . 13 3.1. Sending a Request . . . . . . . . . . . . . . . . . . . . 13 3.2. Firewall Request Processing Procedures . . . . . . . . . . 13 3.2.1. Alternative Firewall Processing Procedures . . . . . . 14 3.3. Sending a Response . . . . . . . . . . . . . . . . . . . . 14 3.4. Alert Messages . . . . . . . . . . . . . . . . . . . . . . 14 3.5. Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4.1. Attacks Against Requests . . . . . . . . . . . . . . . . . 16 4.2. Attacks Against Responses . . . . . . . . . . . . . . . . 16 4.3. Attacks Against Alerts . . . . . . . . . . . . . . . . . . 16 4.4. Topology Exposure . . . . . . . . . . . . . . . . . . . . 16 4.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 17 5. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6.1. NLS-FW Message Types . . . . . . . . . . . . . . . . . . . 19 6.2. NLS-FW TLVs . . . . . . . . . . . . . . . . . . . . . . . 19 6.3. NLS-FW Request Subtypes . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Shore Expires August 30, 2006 [Page 2] Internet-Draft The NLS Firewall Application February 2006 1. Introduction The Network Layer Signaling Transport Protocol [Shore] provides a generalized transport for carrying signaling messages between two endpoints. By "signaling messages" we mean messages intended to be intercepted and interpreted by network devices through which the message is routed. In the firewall NLS application, the messages are requests for firewall pinholes. An endpoint wishing firewall pinholes for a particular data stream sends a message towards the other endpoint of that stream. The message contains a description of the pinhole(s) along with associated information which may be used as the basis for granting or denying the request (i.e. authorization policy data). When a firewall intercepts the message it extracts the request, verifies the authentication, and either authorizes or denies the pinhole request based on local security policy. +--------+ +------------+ +--------+ | Host A |----->| Firewall A |--->| Host B | +--------+ +------------+ +--------+ Figure 1 Design goals for NLS-FW include: o Low messaging overhead o Low endpoint memory consumption o Minimal retained state not directly associated with firewall resources o Clean, robust NAT interactions o Supporting, rather than bypassing, local security policy Throughout this document we refer to the endpoint initiating the Request as the "sender" and its peer endpoint as the "receiver," using the terminology from RSVP [RFC2205]. Shore Expires August 30, 2006 [Page 3] Internet-Draft The NLS Firewall Application February 2006 2. NLS Firewall Messages NLS Firewall messages are encapsulated in NLS-TL messages and sent with NLS-TL Application ID = 3. The NLS-FW packet format is: +-------------+-------------+-------------+-------------+ | NLS-FW header | +-------------+-------------+-------------+-------------+ | | // payload // // // | | +-------------+-------------+-------------+-------------+ Figure 2 2.1. The NLS-FW Header The NLS-FW header format is: +-------------+-------------+-------------+-------------+ | msg type | version | length | +-------------+-------------+-------------+-------------+ Figure 3 2.1.1. Message Types The Message Type field is one octet in length. There are three NLS Firewall message types: o Request = 1 o Response = 2 o Alert = 3 The Request message carries the firewall request from the sender towards its peer reciever, and includes a description of the firewall resources (pinhole) being requested. The message is constructed by the sender and MAY NOT be modified by intermediate nodes. Shore Expires August 30, 2006 [Page 4] Internet-Draft The NLS Firewall Application February 2006 The Response message carries the results of the request. It is constructed by the receiver and sent towards the sender, and it MAY be modified by intermediate nodes. The Alert message is used to carry asynchronous notifications from firewalls to the sender, and MAY NOT be modified by intermediate nodes. By "asynchronous" we mean that the messages are initiated by the firewalls and are not necessarily sent in response to request messages. 2.1.2. Version The Version field is one octet in length and carries the NLS-FW version number. The current version number is 1. 2.1.3. Length The Length Field is two octets in length and carries the length in octets of the entire NLS-FW message payload, including the NLS-FW header. It does NOT include the transport layer header. 2.2. NLS-FW TLVs NLS-FW data elements are carred in {type,length,value} tuples (TLVs). Some of these data elements are appropriate only for particular types of NLS-FW messages, while others may be more generally applicable. The TLV format is: +-------------+-------------+-------------+-------------+ |R|R| type | length | +-------------+-------------+-------------+-------------+ // data element // +-------------+-------------+-------------+-------------+ Figure 4 where the fields are: Reserved: The first two bits of the TLV are reserved for future use, to maintain compatibility with other TLV formats Type: Identifier describing the TLV. This is maintained through a registry (IANA) Shore Expires August 30, 2006 [Page 5] Internet-Draft The NLS Firewall Application February 2006 Length: The length of the TLV in octets, including the TLV header Data Element: The actual content of the data element. The data elements are described below 2.2.1. Network Access Identifier: Type=1 The Network Access Identifier (NAI) is a mandatory data element to be included in each NLS-FW payload as the first element following the NLS-FW header. The format is described in [RFC2486], and it is carried in the NLS-FW message as follows: +-------------+-------------+-------------+-------------+ | length | NAI | +-------------+-------------+-------------+-------------+ // NAI // +-------------+-------------+-------------+-------------+ Figure 5 Length: The length of the NAI in octets, NOT including the length field NAI: A variable-length field carrying Network Access Identifier representing the user on behalf of whom the firewall resources are being requested. This is usually also the sender of the NLS-FW request message, but not always (for example, when the request is being proxied) 2.2.2. Request TLV: Type=2 [Note: the request TLV format is flexible and can carry a variety of request types -- several payload formats are proposed here but-- they should not be construed as final or complete.] The request TLV consists of one or more descriptions of firewall resources (pinholes, usually) being requested. It MAY NOT be carried in a Response Message. There are several pinhole request formats. The request TLV uses the format shown in Figure 6. Shore Expires August 30, 2006 [Page 6] Internet-Draft The NLS Firewall Application February 2006 +-------------+-------------+-------------+-------------+ | req subtype | flags | length | +-------------+-------------+-------------+-------------+ | pinhole ID | +-------------+-------------+-------------+-------------+ | | // pinhole request // | | +-------------+-------------+-------------+-------------+ Figure 6 The fields are: Request Subtype: the type of pinhole request contained in the payload. See below. Flags: flags for the request, as follows 0x01 DENIED: at least one firewall along the path has denied the request Length: the length in octets of the request, including the header pinhole ID: a 32-bit random identifier to be used as a reference for the pinhole. Pinhole request: the pinhole request itself 2.2.2.1. Pinhole Descriptor: Subtype=1 +-------------+-------------+-------------+-------------+ | Internal address tag | +-------------+-------------+-------------+-------------+ | External IPv4 address | +-------------+-------------+-------------+-------------+ | External IPv4 netmask | +-------------+-------------+-------------+-------------+ | Protocol Id | unused | External port | +-------------+-------------+-------------+-------------+ | ICMP type | ICMP code | Options | +-------------+-------------+---------------------------+ Shore Expires August 30, 2006 [Page 7] Internet-Draft The NLS Firewall Application February 2006 A Pinhole descriptor resembles a traditional firewall pinhole descriptor, with addresses, port numbers, TCP flags, and so on, and is derived from the Diameter [RFC3588] IPFilterRule AVP. It differs from the traditional descriptor in its use of NLS tagged addresses (see XXX). Because NLS-FW is designed for pinholing along a path between two endpoints, wildcarding on internal addresses is not permitted. That would be a configuration function, and firewall configuration is outside the scope of this protocol. However, wildcarding is supported on "external"/foreign addresses to provide some flexibility as needed. The fields are as follows: Internal address tag: The address tag to identify the address/port/ protocol tuple being carried in a NAT_ADDRESS TLV in the NLS-TL header. See section XXX. External IPv4 address: The external address to be installed in this pinhole. External IPv4 netmask: The network address mask for the external address in this pinhole, to allow network wildcarding. Protocol ID: The IP protocol number. External port: The TCP, UDP, or SCTP port number for the external address in this pinhole. ICMP type: The ICMP type and ICMP code fields are ignored unless the ICMP bit is set in the options field. Options: A subset of IP and TCP options. See Figure 8 FRAG . . . . . . . . . . . . . . . x SSRR . . . . . . . . . . . . . . x . LSRR . . . . . . . . . . . . . x . . RR . . . . . . . . . . . . x . . . TCPESTABLISHED . . . . . . . . . . . x . . . . TCPSETUP . . . . . . . . . . x . . . . . ICMP . . . . . . . . . x . . . . . . Figure 8 Shore Expires August 30, 2006 [Page 8] Internet-Draft The NLS Firewall Application February 2006 When the FRAG bit is set, match if the packet is a fragment but not the first fragment of a datagram. When the SSRR bit is set, match if the strict source route IP option is set. The LSRR bit is used to indicate the loose source route IP option, and RR is used to indicate the record route IP option. TCPESTABLISHED is used to match TCP packets that have the RST or ACK bits set. It is meaningless for non-TCP packets and the middlebox SHOULD return a "malformed request" error if it receives a request in which this bit is set but the protocol is not TCP. TCPSETUP is used to match TCP SYN packets. It is meaningless for non-TCP packets and the middlebox SHOULD return a "malformed request" error if it receives a request in which this bit is set but the protocol is not TCP. The ICMP type and ICMP code fields are ignored unless the ICMP bit is set in the options field. 2.2.2.2. Offset descriptor: Subtype=2 +-------------+-------------+-------------+-------------+ | Offset | Length | +-------------+-------------+-------------+-------------+ // Value // +---------------------------+-------------+-------------+ This object allows senders to request filtering on arbitrary values at arbitrary offsets from the start of the IP packet. For example, this could be used to carry an IPSec SPI, which would allow filtering requests on encapsulated packets. Offset is a 16-bit value representing the number of octets from the start of the IP packet at which to begin the comparison. Length is a 16-bit value representing number of length in octets of the value to be compared against, and Value is a variable-length field carrying the Value itself. 2.2.3. Lifetime TLV: Type=3 The Lifetime structure is a 32-bit value which carries the duration for which the pinhole is being requested, expressed in seconds. Shore Expires August 30, 2006 [Page 9] Internet-Draft The NLS Firewall Application February 2006 +-------------+-------------+-------------+-------------+ | lifetime | +-------------+-------------+-------------+-------------+ 2.2.4. Response TLV: Type=4 A Response TLV is used to return the results of a Pinhole Request back to the sender. It is typically originated by the receiver, although in some cases it may be generated by a firewall within the network or by a proxy (see below). Its format is: +-------------+-------------+-------------+-------------+ | pinhole ID | +-------------+-------------+-------------+-------------+ | flags | +-------------+-------------+-------------+-------------+ Figure 11 The fields are: Pinhole ID: the 32-bit random identifier contained in the request Flags: Indicates success or failure, optionally including reason indicators: 0x0000 success 0x0001 failure, no reason given 0x0002 malformed request 0x0004 unauthorized operation 0x0008 resources unavailable Flags may be OR'ed together Shore Expires August 30, 2006 [Page 10] Internet-Draft The NLS Firewall Application February 2006 2.2.5. Alert TLV: Type=5 An Alert TLV is used to carry Alert messages from firewalls to senders. Its format is: +-------------+-------------+-------------+-------------+ | Type | Code | +-------------+-------------+-------------+-------------+ where the fields are: Type: a one-octet field containing the message from the firewall to the sender. Code: a three-octet field containing additional information related to the code The Types and Codes are: 0x01: Request denied 0x001: Authorization denied 0x002: Authentication failure 0x003: Resources unavailable 0x004: Malformed request 0x005: No such resource exists 0x02: Pinhole deleted 0x001: Time expired 0x002: Resources exhausted 0x03: Pinhole will be deleted Number of seconds until deletion An Alert message of type 0x00 is invalid and MUST be ignored. 2.2.6. Teardown TLV: Type=6 The Teardown TLV is sent in a Request message, asking the firewall to delete the pinhole in the Pinhole ID. +-------------+-------------+-------------+-------------+ | Pinhole ID | +-------------+-------------+-------------+-------------+ Shore Expires August 30, 2006 [Page 11] Internet-Draft The NLS Firewall Application February 2006 where Pinhole ID is the Pinhole ID of the pinhole the firewall is being asked to delete. Shore Expires August 30, 2006 [Page 12] Internet-Draft The NLS Firewall Application February 2006 3. NLS-FW Messaging Procedures 3.1. Sending a Request An endpoint wishing to request firewall pinholes along a path between itself and another endpoint will send an NLS-FW Request Message addressed to the endpoint. The format of an NLS-FW message is: o NLS-FW header, followed by o NAI, followed by o One or more firewall pinhole requests Those messages SHOULD be sent with the BUILD-ROUTE bit set in the NLS-TL header. This allows the creation of a pinned route, which improves error handling and the response when a request is denied (see XXX). The DENIED flag in each request header MUST be set to 0x0. Multiple Request payloads MAY be included in each Request message. 3.2. Firewall Request Processing Procedures When an NLS-capable firewall receives an NLS message, it examines the application TLVs to determine whether or not it contains an NLS-FW payload. If it does, it passes the payload, along with its associated NLS-TL NAT TLVs, to the NLS firewall application. The firewall application examines the request and, based on policy, determines whether or not it will grant the request. If the request is not granted, the DENIED flag MUST be set to 1. The firewall MAY choose to send an Alert message directly back to the sender (originator) of the request. However, in doing so the firewall exposes itself to the sender, which would be undesirable in cases where the network administrators wish to hide network topology, particularly the location of firewalls. A firewall denying a request MAY also add a reason by either inserting a Response TLV into the Request message if one is not already present, or by turning on the appropriate reason bits if one is already present. It MAY NOT turn off any bits that are already on. Shore Expires August 30, 2006 [Page 13] Internet-Draft The NLS Firewall Application February 2006 Whether or not the request is granted, the NLS Transport Layer writes the hop information into the NLS-TL header and sends the request on towards the receiver. 3.2.1. Alternative Firewall Processing Procedures The procedures described in the preceding section allow for what are essentially "discovery" procedures. That is to say that all participating firewalls along the path are queried and they have the option of sending an alert back to the sender explaining the cause of the failure. It may be the case, however, that conserving bandwidth is a priority or that there is absolutely no desire to allow firewalls to send alerts back to the sender. In that circumstance the first firewall that denies a request MAY return a response message towards the sender following the procedures described in Section 3.3. 3.3. Sending a Response When a receiver or its proxy receives an NLS-FW Request message, it is responsible for generating a Response message and sending it back towards the sender. A response message consists of a NLS-FW header with Message Type set to Response, followed by the NAI included in the Request message, followed by one or more Response TLVs. There MUST be one response for each pinhole request in the Request message. If there is a Response TLV for a pinhole present in the Request message, that Response TLV MUST be copied exactly into the Response Message. There MUST NOT be more than one Response TLV for each pinhole requested. 3.4. Alert Messages A firewall MAY send unsolicited messages to the endpoint (or its proxy) that sent a request. This may be in response to a request, or to send information about the status of an established firewall pinhole. Alert messages MUST always be sent from the firewall to the sender. They MUST NOT be sent by the sender or receiver, and they MUST NOT be sent from the firewall to the receiver. An alert message carries optional information which the firewall MAY wish to convey to the endpoint. It is addressed to the sender's NLS signaling port as an NLS-FW message of type Alert (Type=3). It contains an Alert TLV, described in Section 2.2.5 Shore Expires August 30, 2006 [Page 14] Internet-Draft The NLS Firewall Application February 2006 3.5. Teardown The circumstances under which a firewall pinhole may be deleted include: o The requested lifetime has expired o Timers local to the firewall (idle timer, for example) have expired o The firewall needs to release resources to protect itself against attack o The sender explicitly requests that a pinhole be deleted before its lifetime expires The Teardown TLV is used for explicit pinhole deletion requests. A Teardown TLV MAY be carried in the same NLS-FW message as Pinhole Requests, but if it has the same Pinhole ID as a Pinhole Request in the same NLS-FW message, the request MUST be denied. If an Alert message is sent to notify the sender, the Type MUST be "Request denied" and the Code MUST be "Malformed request (0x004)". Shore Expires August 30, 2006 [Page 15] Internet-Draft The NLS Firewall Application February 2006 4. Security Considerations A protocol which requests firewall resources is necessarily extremely sensitive. It provides the opportunity to both violate network security policy and to commit denial-of-service attacks against on- path firewalls. The NLS Transport Layer provides hop-by-hop authentication for transport layer purposes, but it is inadequate to provide appropriate protection against the attacks described below. [Ed. note: Cryptographic mechanisms will be specified in the next version of this document] 4.1. Attacks Against Requests The most obvious and potentially most dire attack against the Request facility is exploiting the ability to create firewall pinholes in order to allow unauthorized traffic through the firewall. The Request Message MUST be authenticated. It MUST be integrity protected in order to prevent an attacker along the path from modifying the request. Protection SHOULD also be provided against denial-of- service attacks (see Section 4.5 4.2. Attacks Against Responses The primary attack against response messages is a denial-of-service attack, in which a false response reports the failure to create the requested pinholes. The Response message MUST be authenticated and integrity-protected by the receiver. 4.3. Attacks Against Alerts An attacker may send a bogus Alert message to inform a sender that a pinhole has been torn down when, in fact, it has not been. Alert messages MUST be authenticated and integrity-protected. 4.4. Topology Exposure Both service providers and enterprises are frequently reluctant to deploy a protocol which might expose information about the topology of their network, and in particular the location of their firewalls and other security devices. One of the advantages of the messaging model used by NLS-FW is that network topology may be completely concealed. That is to say, the Shore Expires August 30, 2006 [Page 16] Internet-Draft The NLS Firewall Application February 2006 only address that the endpoint has is the address of its peer for which it is requesting the pinhole. A firewall MAY choose to reveal its location by sending an Alert message, but that is optional. Note that when Alert messages are used, an attacker may be able to discover firewall location or other topology information by injecting Request messages he knows will fail (for example, the authentication is incorrect) in order to force the firewall to return an Alert message. The use of Alerts should be considered carefully, and in some cases local policy may be used to determine whether or not an Alert should be sent. For example, Alerts may be sent in response to Requests arriving on inward-facing interfaces, but not outward-facing interfaces. 4.5. Denial of Service Denial of service attacks are typically either attacks that consume all available resources or attacks that disable a device by making it unavailable (for example, an unauthorized shutdown). The second type of attack is primarily operational (inside the box), and so we are primarily concerned with protecting resources. One common mechanism for executing denial of service attacks is to consume state. Firewalling is an inherently stateful operation, and because NLS-FW is used to create and maintain firewall state care must be taken to protect against the use of NLS-FW to exhaust firewall resources. In particular, we are concerned about protecting against exhausting the available pinhole/filter state, and about protecting against an unmanageable computational load being caused by an excessively large number of cryptographic operations. [stick drop strategy discussion here] Shore Expires August 30, 2006 [Page 17] Internet-Draft The NLS Firewall Application February 2006 5. Proxies Both the sender and receiver may be proxied in those cases where there is a desire to offload firewall signaling from endpoints. When NLS-FW requests are proxied, the proxy will need to "know" which addresses and ports need firewall resources. That suggests that either the proxy must be participating in the session (for example, a VoIP call control server) or that it can sniff signaling traffic. The latter case is somewhat fraught, since 1) the application traffic will have to be travelling in the clear or the proxy will have to have access to keying material that would allow it to decrypt the application traffic, and 2) the application would not have access to the results of the NLS-FW request, and in particular would not know not to continue if the request were denied. Because NLS-FW is a path-oriented signaling protocol, the proxy would need to be placed in a topologically-appropriate location. In particular it would need to be behind the same set of firewalls as the endpoint for which it is acting as a proxy. Shore Expires August 30, 2006 [Page 18] Internet-Draft The NLS Firewall Application February 2006 6. IANA Considerations Because NLS-FW is carried as an NLS-TL application, TCP and/or UDP port numbers are unnecessary. However, the NLS-FW Application ID (3) must be registered. Registries should be established for NLS-FW message types, TLVs, and firewall request subtypes. Initial values are given below. 6.1. NLS-FW Message Types NAME VALUE DEFINITION Request 1 See Response 2 See Alert 3 See 6.2. NLS-FW TLVs NAME VALUE DEFINITION NAI 1 See Request 2 See Lifetime 3 See Response 4 See Alert 5 See Teardown 6 See 6.3. NLS-FW Request Subtypes NAME VALUE DEFINITION pinhole descriptor 1 See offset descriptor 2 See Shore Expires August 30, 2006 [Page 19] Internet-Draft The NLS Firewall Application February 2006 7. References 7.1. Normative References [Shore] Shore, M., Biswas, K., and D. McGrew, "Network-Layer Signaling: Transport Layer", draft-shore-nls-tl-01.txt (work in progress), November 2005. 7.2. Informative References [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Shore Expires August 30, 2006 [Page 20] Internet-Draft The NLS Firewall Application February 2006 Author's Address Melinda Shore Cisco Systems 809 Hayts Road Ithaca, New York 14850 USA Email: mshore@cisco.com Shore Expires August 30, 2006 [Page 21] Internet-Draft The NLS Firewall Application February 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shore Expires August 30, 2006 [Page 22]