Internet DRAFT - draft-martin-nsis-nslp-natfw-security
draft-martin-nsis-nslp-natfw-security
NSIS Working Group M. Martin
Internet-Draft M. Brunner
Expires: April 19, 2004 M. Stiemerling
NEC
C. Aoun
Nortel Networks
October 20, 2003
A NAT/Firewall NSLP security infrastructure
draft-martin-nsis-nslp-security-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 April 19, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document proposes a security infrastructure for the NAT/FW
traversal NSLP of the NSIS protocol. We begin with a description of
the problem, followed by the proposed solution, based on public key
infrastructure. The document finally deals with examples that
clarify the proposed methods.
Martin, et al. Expires April 19, 2004 [Page 1]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problems to solve . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution requirements . . . . . . . . . . . . . . . . . . . . 5
4. Digital signatures: generic pros and cons . . . . . . . . . . 6
4.1 Public key deployment . . . . . . . . . . . . . . . . . . . . 6
4.2 Computational cost . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Incurred overhead . . . . . . . . . . . . . . . . . . . . . . 7
5. Digital signatures on an NSIS scenario . . . . . . . . . . . . 8
5.1 Public key deployment. Known peers . . . . . . . . . . . . . . 8
5.2 Messages changing en route . . . . . . . . . . . . . . . . . . 8
6. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Implementation of digital signatures in the NAT/FW NSLP . . . 11
7. Solution examples . . . . . . . . . . . . . . . . . . . . . . 13
7.1 Network with firewalls . . . . . . . . . . . . . . . . . . . . 13
7.2 Network with NATs . . . . . . . . . . . . . . . . . . . . . . 14
7.3 Networks with several Middle boxes . . . . . . . . . . . . . . 15
7.4 Middle boxes on foreign networks . . . . . . . . . . . . . . . 15
8. Optional extensions . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 25
Martin, et al. Expires April 19, 2004 [Page 2]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
1. Introduction
The NAT/Firewall traversal NSLP for the NSIS protocol is a highly
sensitive service. Because of its functionality, it can potentially
open paths to networks otherwise protected by NAT/FW infrastructures.
It also has the potential to render NAT/FW infrastructures
inoperative, closing paths or exhausting the resources of the
involved boxes.
For this reason, a tight security scheme has to be devised, to allow
both fine and coarse access control. This draft aims at solving this
problem by using cryptographic digital signatures to authenticate the
peers. Decisions on whether to allow access or not are based on the
authenticity of the requesting peer and the security policy
configured in the box.
Martin, et al. Expires April 19, 2004 [Page 3]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
2. Problems to solve
The NAT/FW traversal NSLP provides the following security sensitive
services:
1. Firewall traversal: override specifically set access rules, and
allow data transfer through firewall devices, both from the
inside out and the outside in.
2. NAT traversal: reach machines in a private network, which were
not meant to be accessible from the outside without specific
setups.
3. Resource allocation: Install packet filters and NAT bindings on a
machine that can only allocate a certain number of them.
Misuse of these services can compromise the network and even render
it inoperable. The NSIS-Threats document [1] shows a number of ways
in which such services can be exploited
Martin, et al. Expires April 19, 2004 [Page 4]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
3. Solution requirements
Given the problems and its exploit possibilities, our solution will
have to cover the following requirements:
1. Nodes must be able to verify the authenticity of the requests
2. Message integrity has to be warranted
3. Nodes must have the last word in deciding whether they accept a
session or not
The requirements listed can only be met by cryptographic methods,
namely, digital signatures. Through its use, nodes could be sure of
who is making a request, and what request it is, and match it with an
access list, or any other more complex decision mechanism.
This approach provides great flexibility, as the decision process can
be arbitrarily complex, and based on trustful data. For instance, we
might want to authorize certain identities, or allow for only a
number of connections per id to be accepted. More open systems with
full access would have a chance to black list users.
Martin, et al. Expires April 19, 2004 [Page 5]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
4. Digital signatures: generic pros and cons
Digital signatures provide a secure way of transmitting messages:
they proof that the author is who he says he is, and that what he is
saying has not been altered. In other words, authentication and
integrity, both strictly necessary if a node has to take security
sensitive actions.
No other mechanism nowadays provides all the functionalities of
public key cryptography, and thus this becomes a perfect candidate to
provide security on the NAT/FW NSLP.
This, of course, comes at a cost; We will face three main problems:
o Signature verification requires the public key of the sender.
This key has to be known and trusted before a signature can be
validated safely.
o Public key cryptography has a high computational cost, in
comparison to other cryptography algorithms and authentication
systems
o Introducing signatures on a message implies a certain overhead
4.1 Public key deployment
The NAT/FW NSLP is expected to enable connections between peers that
don't necessarily know each other. This of course, collides with the
necessity of knowing the public key of the sender to verify it's
signatures.
Later in this document (Section 6.1) we try to analyze what nodes are
likely to know each other, and where we can expect the public keys to
have been securely exchanged.
On the other hand, the necessity of cyphered, authenticated and non
tampered communications seems to set a trend towards proper public
key infrastructure deployments. Nowadays, though, no such public
global infrastructure exists.
4.2 Computational cost
Commonly available public key cryptography provides rather fast
algorithms, with verification/signature times around the 13.0/6.8
milliseconds on 450MHz UltraSPARC II processor [4].
This should not be an excessive load when considering a running
Martin, et al. Expires April 19, 2004 [Page 6]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
server, but is of special relevance when facing Denial of Service
attacks. In this case, the longer it takes to process a request
(even if only to reject it), the easier it is to overload the machine
into uselessness. Performance analysis should be undertaken to
evaluate these risks. We must consider, though, that authentication
and integrity will require some form of cryptography, and that will
require a certain degree of computational power.
4.3 Incurred overhead
Digital signatures, using the DSA algorithm, have a length of about
320 bits, and even shorter algorithms exist [5]
The NSLP packet payload proposed in [6] has a size of 23 bytes.
Adding a signature of 40 bytes implies a 200% packet length increase.
For this reason, we must carefully choose the kind of signature we
use, to minimize the introduced overhead.
Martin, et al. Expires April 19, 2004 [Page 7]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
5. Digital signatures on an NSIS scenario
We have seen the values and the problems involved in digital
signatures. In this section we will particularize it to the
scenarios we will face in an NSIS NAT/FW NSLP.
5.1 Public key deployment. Known peers
If we intend to use digital signatures, we must first inquire on the
availability of the public keys. Middle boxes will have a very
limited number of them available, due to the difficulty of publishing
them securely.
Neighbouring peers can not be assumed to have their public keys
exchanged. The reason is that, even though, a middle box has a very
limited number of one-hop neighbours, it is NSIS NAT/FW NSLP aware
neighbours that we are concerned about. As a first approach, we must
consider that the border middle boxes of each network on the internet
have each other as potential one-nsis-hop peers. This keeps us from
using simpler methods, (may be even not based on public key
cryptography), and forces us to carefully decide whether border
middle boxes will ever know each other, as this is basic for the
solution design.
5.2 Messages changing en route
Let us assume a create message, as defined in [6]. It contains a
source address for the pinhole specification. Let us now suppose it
goes through a NAT. Ideally, an external address and port will be
reserved, and the create message will be modified accordingly.
This step, necessary for the basic protocol functionality, also means
that any previous packet signature will be broken, since the message
changes.
Specifically, the source or target address can change when traversing
a NAT, as shown in Figure 1:
Martin, et al. Expires April 19, 2004 [Page 8]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
+------+ +------+
| NAT1 |-------------------------------| NAT2 |
+------+ +------+
| |
+------+ +------+
| DS | | DR |
+------+ +------+
DS: Data Sender
DR: Data Receiver
Figure 1: Message alterations when traversing NATs
When a create message from DS to DR traverses NAT1, the pinhole
source address must change, since the potential data packets that
will use the pinhole, will appear to come from the NAT1 external
address.
Similarly, when the create packet reaches NAT2, it matches a
reservation, and redirects it to DR. Any other boxes between NAT2
and DR would see the potential data packets as heading towards DR and
not NAT2 any more; for this reason, the destination address of the
pinhole in the create message has to be altered accordingly.
This basically means we will not be able to protect the source and
destination addresses in the NAT/FW NSLP messages, since they change
on the way. Because of that, other mechanisms will have to be
devised, as we will see in Section 6.1
Martin, et al. Expires April 19, 2004 [Page 9]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
6. Proposed solution
At this point, we are left with the necessity of digital signatures,
but also with several restrictions:
o Too many signatures involve excessive overhead, computational
cost, etc..
o We have to consider signature validity, be it because the message
changed, or because the public key is not available
If we manage to use them properly, we will be able to provide
authentication and integrity. But we are also interested in
authorization. The step from authenticating to authorizing is often
policy based. It is then reasonable to assume an arbitrarily complex
decision engine to issue verdicts based on the data we can provide
it.
Note then, that whether an NSIS NAT/FW NSLP request is honored or
not, will depend on the decision engine, which, may or may not take
into consideration the authentication information we provide it. A
first approach to this engine is given in Figure 2.
Session ID ---\
Verified (yes/no) ----\ +----------+ /-- Honored
\ | | /
Pinhole source ------>--| Decision |---<----- Remembered
Verified (yes/no) ------>--| Engine | \
/ | | \-- Rejected
Pinhole destination ----/ +----------+
Verified (yes/no) ---/
Figure 2: The decision engine interface
Based on the Session ID and pinhole specification, and whether that
data has is trustworthy because it has been verified with a known
signature, the decision engine decides from three options:
o Honored: The request is accepted, and the required rules installed
o Remembered: The request is not trusted, and thus not installed,
but is kept awaiting for a certain time, expecting later
validations.
Martin, et al. Expires April 19, 2004 [Page 10]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
o Rejected: The petition is ignored completely
Note that if the decision engine returns a reject, the communication
will not be possible at all.
Possible policies on the decision engines are:
o The basic one: authorize certain sources or destinations to use
certain pinholes
o Allow a certain request rate or amount and deny the rest. For
instance, the node next to an ISP, will allow as many connections
as the ISP contracts
o Allow requests for internal IP's, independently of their
signatures
o Allow all but perform accounting operations
We are now left with the problem of using digital signatures wisely
to provide adequate input to the Decision Engine
6.1 Implementation of digital signatures in the NAT/FW NSLP
What and where we sign is greatly related to trust relationships
between middle boxes. A detailed description of the different kinds
of trust can be found in [1]. In our approach, we expect end to end
trust, and hope for peer to peer trust in some of the hops.
For end to end trust, we will have DS sign the Session ID and include
it in the object. For peer to peer, we will sign the whole object on
each hop. In other words, the object will include:
1. Session ID signature: Session ID signed by DS except for Path
Succeeded messages, where it is signed by the previous hop on the
return path.
2. Previous hop signature: Pinhole source and destination (if
applicable), Session ID and Session ID signed by DS, plus other
objects, all of it signed by the previous hop
The first signature will be added by the NSLP. The second one,
though, since it refers to the whole packet , might be implemented on
the transport layer (NTLP). In the case that the NTLP didn't include
this service, it could be pushed up on the NSLP.
Note that the specific syntax and algorithms used to sign the
messages are not specified here. A standardized flexible option such
Martin, et al. Expires April 19, 2004 [Page 11]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
as CMS [2] could be used, but might be too cumbersome. A simple DSA
signature might suffice.
We recommend looking at the examples in Section 7 for detailed
working flows that help understand this specific use of digital
signatures.
Martin, et al. Expires April 19, 2004 [Page 12]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
7. Solution examples
7.1 Network with firewalls
In this basic network, we have two hosts, on their respective
networks, each behind a firewall that needs to be signaled for the
path to be open. The FW1 belongs to DS's network, and FW2 belongs to
DR's, as the hierarchical structure suggests in Figure 3
+-----+ +-----+
| FW1 |-------------------------------| FW2 |
+-----+ +-----+
| |
+-----+ +-----+
| DS | | DR |
+-----+ +-----+
FW: Firewall
DS: Data Sender
DR: Data Receiver
Figure 3: Firewall network
When the signaling begins, DS sends a create message to FW1. We
expect FW to honour the request for one of these reasons:
o It allows end hosts inside it's network to open pinholes (perhaps
only a given range)
o It knows DS's public key and thus verifies the request using the
previous hop signature, and it's policies allow this transaction
FW2 gets the forwarded packet, but is not likely to honor it, because
it probably does not know FW1's public key, and can not validate it's
origin. We expect it to remember the rule and forward the NSIS
packet.
DR gets it next. It does know DS, and can verify the Session ID
signature. It can also verify the target address, because it is
itself, and it is expecting this signaling (probably because of some
other application layer communication
DR replies then with a Path Succeeded message, that includes the
Session ID signature signed by DR.
Martin, et al. Expires April 19, 2004 [Page 13]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
This message gets to FW2, who does know DR, and so verifies the
Session ID signature. That verifies for him the destination of the
pinhole, and the Session ID, which it was remembering. It is
re-entered into the decision engine, which this time, honours the
request.
It then gets to FW1 which already honoured that Session ID, and to
DS, who starts data transfer on the newly created pinhole path
Note that in this example, the message does not change en route, but
this is only true because there are no NATs on the data path. Note
also that DR and FW2 can not verify the source address. This is a
weakness indeed, but it is not of extreme importance, since any
malicious node that is able to change the nsis packet source address,
is also capable of dropping the data packets afterwards.
7.2 Network with NATs
This network is analogous to the example Section 7.1 but has NATs
instead of firewalls, as shown in Figure 4.
+------+ +------+
| NAT1 |-------------------------------| NAT2 |
+------+ +------+
| |
+-----+ +-----+
| DS | | DR |
+-----+ +-----+
DS: Data Sender
DR: Data Receiver
Figure 4: NAT network
Note how exactly the same signaling (security wise) as in the
previous example would also work here. That is meant to be so,
because DS and DR do not need to know the topology of the data path.
We can see though, how the pinhole source changes after NAT1, and the
pinhole destination changes after NAT2, which means we can not sign
the whole packet at DS, for instance.
From now on, we will refer to the nodes as middle boxes, since, in
what concerns security, there is no change in how we deal with them.
Martin, et al. Expires April 19, 2004 [Page 14]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
7.3 Networks with several Middle boxes
We now increase complexity to show the signaling through more than
one middle box per network, as shown in Figure 5.
+-----+ +-----+
| MB2 |-----------------------------------| MB3 |
+-----+ +-----+
| |
+-----+ +-----+
| MB1 | | MB4 |
+-----+ +-----+
| |
+-----+ +-----+
| DS | | DR |
+-----+ +-----+
MB: Middle box (NAT or Firewall or a combination)
DS: Data Sender
DR: Data Receiver
Figure 5: Several middle boxes per network
DS sends a create message, which is honored by MB1, for the same
reasons as in Section 7.1. We expect MB2 to accept it as well,
because it knows MB1 (peer to peer trust) and the policy allows it.
MB3 and MB4, again as in Section 7.1 will remember the rule, but not
install it. When DR gets it and validates it, MB4 will honor the
request, and will sign the session ID itself. This is what makes MB3
trust the request and honor it.
Again, notice how we can not protect the source address.
7.4 Middle boxes on foreign networks
We now face the problem of middle boxes somewhere on the Internet,
that do not belong to DS's or DR's network, as shown inFigure 6.
Martin, et al. Expires April 19, 2004 [Page 15]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
+-----+ +------+ +-----+
| MB1 |-------------| MB 2 |--------------| MB3 |
+-----+ +------+ +-----+
| |
+-----+ +-----+
| DS | | DR |
+-----+ +-----+
MB: Middle box (NAT or Firewall or a combination)
DS: Data Sender
DR: Data Receiver
Figure 6: Middle boxes on the Internet
This scenario is rather rare, and presents the problem that MB2 is
unlikely to have a peer to peer trust relationship with any of the
other middle boxes. In this case, either the decision engine has a
rather loose policy that accepts unverified requests, or the
communication does not succeed.
Martin, et al. Expires April 19, 2004 [Page 16]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
8. Optional extensions
The proposed combination of signatures and handling is expected to
provide authorization in most of the cases. There is a special case
which might provide an extra level of security by securely
establishing the source of the pinhole in DS's network. This is
achieved by adding an extra signature in the NSLP, next to the
Session ID signature. The data to be signed is the Session ID and
the source of the pinhole. It is to be signed by DS or the last nat
to have modified the source address.
The relevant scenario is shown on Figure 7:
+-----+ +-----+
| FW1 |-----------------------------------| MB2 |
+-----+ +-----+
| |
+-----+ +-----+
| DS | | DR |
+-----+ +-----+
MB: Middle box (NAT or Firewall or a combination)
DS: Data Sender
DR: Data Receiver
Figure 7: End to middle authorization
Assume that MB2 does not know FW1, but it does know DS. Such a case
would be that of a company (MB2) allowing it's employees working
abroad to install pinholes even if connecting through an ISP (which
runs a firewall, FW1). The special signature we added would allow
MB2 to authenticate DS as the source. Something that FW1 could not
do, because it is not known byMB2.
This would be a case of end to middle trust.
Martin, et al. Expires April 19, 2004 [Page 17]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
9. Security Considerations
This entire memo discusses the security implications of using an NSIS
NAT/FW NSLP.
Martin, et al. Expires April 19, 2004 [Page 18]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
10. Conclusions
The proposed method provides a reasonable way to decide wheter to
honor or not NSIS NAT/FW NSLP requests. Peer to peer trust is
expected within the network, and a certain degree of flexibility is
also expected in the pinhole source.
Further field research is required to determine if we are actually
covering most of the real life scenarios.
Martin, et al. Expires April 19, 2004 [Page 19]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
11. Contributors
We would like to acknowledge the excellent contributions of Hannes
Tschofenig to this draft.
Martin, et al. Expires April 19, 2004 [Page 20]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
Normative References
[1] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
DRAFT draft-ietf-nsis-threats-01.txt, January 2003.
[2] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.
Martin, et al. Expires April 19, 2004 [Page 21]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
Informative References
[3] Tschofenig, H., Buechli, M., Van den Bosch, S. and H.
Schulzrinne, "NSIS Authentication, Authorization and Accounting
Issues", draft-tschofenig-nsis-aaa-issues-01 (work in progress),
March 2003.
[4] Gupta, V., Gupta, S. and S. Chang, "Performance analysis of
Elliptic Curve Cryptography for SSL", September 2002.
[5] Boneh, D., Lynn, B. and H. Schacham, "Short Signatures from the
Weil Pairing", 2001.
[6] Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, "A NAT/
Firewall NSIS Signaling Layer Protocol (NSLP)", DRAFT
draft-ietf-nsis-nslp-natfw-00.txt, October 2003.
Authors' Addresses
Miquel Martin
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 16
EMail: miquel.martin@ccrle.nec.de
URI:
Marcus Brunner
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 29
EMail: brunner@ccrle.nec.de
URI: http://www.brubers.org/marcus
Martin, et al. Expires April 19, 2004 [Page 22]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
Martin Stiemerling
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 13
EMail: stiemerling@ccrle.nec.de
URI:
Cedric Aoun
Nortel Networks
France
EMail: cedric.aoun@nortelnetworks.com
Martin, et al. Expires April 19, 2004 [Page 23]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
Appendix A. Acknowledgments
We would like to acknowledge and thank the valuable input Joao Girao
provided for this draft.
Martin, et al. Expires April 19, 2004 [Page 24]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Martin, et al. Expires April 19, 2004 [Page 25]
Internet-Draft NAT/FW NSLP Security infrastructure October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Martin, et al. Expires April 19, 2004 [Page 26]
