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]