WDIFF

draft-aboba-nat-ipsec-02.txt --> draft-aboba-nat-ipsec-03.txt

IPSEC Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
Category: Informational
<draft-aboba-nat-ipsec-02.txt>
11 July
<draft-aboba-nat-ipsec-03.txt>
20 November 2000

NAT and IPSEC

IPSEC-NAT Compatibility Requirements

1. 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.

2. Copyright Notice

3. Abstract

Perhaps the most common use of IPSEC is in providing virtual private
networking capabilities. One very popular use of VPNs is to provide
tele-commuter access to the corporate Intranet. With Today NATs being
increasingly are widely
deployed in home gateways, NAT-IPSEC as well as in other locations likely to be
used by tele-commuters, such as hotels. The result is that IPSEC-NAT
incompatibilities have become a major barrier to deployment of IPSEC in
one of its principal uses. This draft describes known incompatibilities
between NAT and IPSEC IPSEC, and discusses alternatives describes the requirements for addressing
them.

Aboba Informational [Page 1]

INTERNET-DRAFT IPSEC-NAT Compatibility Reqts. 20 November 2000

4. Requirements language

In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [2].

Aboba Informational [Page 1]

INTERNET-DRAFT NAT

Please note that the requirements specified in this document are to be
used in evaluating protocol submissions. As such, the requirements
language refers to capabilities of these protocols; the protocol
documents will specify whether these features are required, recommended,
or optional. For example, requiring that a protocol support
confidentiality is NOT the same thing as requiring that all protocol
traffic be encrypted.

A protocol submission is not compliant if it fails to satisfy one or
more of the MUST or MUST NOT requirements for the capabilities that it
implements. A protocol submission that satisfies all the MUST, MUST
NOT, SHOULD and IPSEC 11 July 2000 SHOULD NOT requirements for its capabilities is said to
be "unconditionally compliant"; one that satisfies all the MUST and MUST
NOT requirements but not all the SHOULD or SHOULD NOT requirements for
its protocols is said to be "conditionally compliant."

5. Introduction

Perhaps the most common use of IPSEC [6] is in providing virtual private
networking capabilities. One very popular use of VPNs is to provide
tele-commuter access to the corporate Intranet. With Today NATs [8]-[9] being
increasingly are
widely deployed in home gateways, NAT-IPSEC as well as in other locations likely
to be used by tele-commuters, such as hotels. The result is that IPSEC-
NAT incompatibilities have become a major barrier to deployment of IPSEC
in one of its principal uses. This draft describes known
incompatibilities between NAT and IPSEC IPSEC, and discusses alternatives describes the requirements
for addressing them.

6. Known incompatibilities between NAT and IPSEC

The incompatibilities between NAT and IPSEC are numerous, ranging from
the obvious to the subtle. Some of the known incompatibilities include:

a) Incompatibility between IPSEC AH [3] and NAT. Since the AH header
incorporates the IP source and destination addresses in the
keyed message integrity check, NAT or reverse NAT devices making changes
to address fields will invalidate the message integrity check.
Since IPSEC ESP [4] does not incorporate the IP source and
destination addresses in its keyed message integrity check,
this issue does not arise for ESP.

b) Incompatibility between checksums and NAT. TCP/UDP/SCTP

Aboba Informational [Page 2]

INTERNET-DRAFT IPSEC-NAT Compatibility Reqts. 20 November 2000

checksums have a dependency on the IP source and destination
addresses through inclusion of the "pseudo-header" in the
calculation. As a result, where checksums are calculated and
checked on receipt, they will be invalidated by passage through
a NAT or reverse NAT device.

As a result, IPSEC ESP will only pass unimpeded through a NAT if
TCP/UDP/SCTP protocols are not involved (as in IPSEC tunnel
mode or IPSEC/GRE), or checksums are not calculated (as is
possible with UDP). As described in [13], TCP checksum
calculation and verification is required.

Note that since transport mode IPSEC traffic is integrity protected
and authenticated using strong cryptography, modifications
to the packet can be detected prior to checking UDP/TCP/SCTP
checksums. Thus, checksum verification only provides assurance
against errors made in internal processing.

c) Incompatibility between IKE address identifiers and NAT.
Where IP addresses are used as identifiers in IKE MM [7]
or QM, modification of the IP source or destination
addresses by NATs or reverse NATs will result in a
mismatch between the identifiers and the addresses in the
IP header. As described in [7], IKE implementations are
required to discard such packets.

While

In order to avoid use of IP addresses as IKE MM and QM identifiers,
userIDs or and FQDNs as identifiers can be used instead. Where user authentication
is possible
within IKE, there are usage scenarios (e.g. SPD entries
describing subnets) that cannot desired, an ID type of ID_USER_FQDN can be accomodated this way.

Aboba Informational [Page 2]

INTERNET-DRAFT NAT and IPSEC 11 July 2000 used, as described in
[5]. Where machine authentication is desired, an ID type of ID_FQDN
can be used. In either case it is necessary to verify that the
proposed identity matches that enclosed in the certificate.
However, while use of USER_FQDN or FQDN identity types is possible
within IKE, there are usage scenarios (e.g. SPD entries
describing subnets) that cannot be accommodated this way.

d) Incompatibility between fixed IKE destination ports and NAPT.
Where multiple hosts behind the NAPT initiate
IKE SAs to the same responder, a mechanism is needed
to allow the NAPT to demultiplex the incoming IKE
packets. This is typically accomplished by translating
the IKE UDP source port. While it is permissible to float
the IKE UDP source port, this can result in unpredictable
behavior during rekeys. re-keys. Unless the floated source port is
used as the destination port for the rekey, re key, the NAT may
not be able to send the re-key packets to the correct
destination.

Alternatives

Aboba Informational [Page 3]

INTERNET-DRAFT IPSEC-NAT Compatibility Reqts. 20 November 2000

e) Incompatibilities between IKE cookie usage and NAT.
Today some NAT implementations attempt to source port use IKE cookies
to de-multiplex incoming IKE traffic. As with source-port
de-multiplexing, such
as IKE cookie de-multiplexing, de-multiplexing also result results
in problems with
rekeying, re-keying, since re-keys typically will
not use the same cookies as the earlier traffic.

f) Incompatibilities between overlapping SPD entries and NAT.
Where hosts behind a NAT negotiate overlapping SPD entries
with the same destination in IKE QM, packets may be sent
down the wrong IPSEC SA. This occurs because to the
sender, the IPSEC SAs appear to be equivalent, since they
exist between the same endpoints and can be used to pass
the same traffic.

g) Incompatibilities between IPSEC SPI selection and NAT.
Since IPSEC ESP traffic is encrypted and thus opaque to the NAT,
the NAT must use elements of the IP and IPSEC header to
demultiplex incoming IPSEC traffic. The combination of the
source
destination IP address, security protocol (AH/ESP) and IPSEC SPI
is typically used for this purpose.

However, since the outgoing and incoming SPIs are chosen
independently, there is no way for the NAT to determine
what incoming SPI corresponds to what destination host
merely by inspecting outgoing traffic. Thus, were two
hosts behind the NAT to attempt to bring up IPSEC SAs to
the same destination simultaneously, it is possible that
the NAT will send the incoming IPSEC packets to the
wrong destination.

Note that this is not an incompatibility with IPSEC per
se, but rather with the way it is typically implemented.
With both AH and ESP, the receiving host specifies the
SPI to use for a given SA. At present, the combination of
Destination IP, SPI, and Security Protocol (AH, ESP) uniquely
identifies a Security Association. This means that the
receiving host can select SPIs such that
it has one Security Association (SA) with (SPI=470,
Dest IP=1.2.3.4) and a different Security Association with
(SPI=470, Dest IP=2.3.4.5).

It is also possible for the receiving host to allocate
a unique SPI to each unicast Security Association. In
this case, the Destination IP Address need only be checked
to see if it is "any valid unicast IP for this host", not
checked to see if it is the specific Destination IP address
used by the sending host. This approach is completely backwards

Aboba Informational [Page 4]

INTERNET-DRAFT IPSEC-NAT Compatibility Reqts. 20 November 2000

compatible and only requires the particular receiving host to
make a change to its SPI allocation and ipsec_esp_input() code.

h) Incompatibilities between embedded IP addresses and NAT.
Since the payload is integrity protected, any IP addresses
enclosed within IPSEC packets will not be translatable by a
NAT. Protocols that utilize embedded IP addresses include
FTP, IRC, SNMP, LDAP, H.323, SIP and many games.

Aboba Informational [Page 3]

INTERNET-DRAFT NAT and IPSEC 11 July 2000

7. Alternatives

The following alternatives have been proposed Requirements for addressing the
incompatibilities between NAT and IPSEC:

UDP encapsulation
RSIP
Changes IPSEC-NAT compatibility

In evaluating a solution to IKE

We discuss IPSEC-NAT incompatibility, the pros and cons of each alternative in turn.

7.1. UDP encapsulation

In this approach, IKE and IPSEC packets are encapsulated following
criteria should be kept in UDP prior to
being sent. The receiver then discards mind:

Deployability
Since IPv6 will address the outer IP header and UDP
encapsulation, thus disregarding any changes address scarcity issues that may have been made by
intervening NAPTs.

This approach has several advantages. It does not require any changes
frequently lead to
either the IKE or IPSEC protocols, and is compatible use of NATs with all IPSEC
protocols (AH/ESP) and modes (transport/tunnel), although some changes
to IKE implementations are required. Since it relies only on NAPT
support for UDP, this approach IPv4, the IPSEC-NAT
compability issue is likely a transitional problem that needs to work with be
solved in the vast majority
of existing NAT implementations.

In terms timeframe prior to widespread deployment of disadvantages, this proposal
IPv6. Therefore, to be useful an IPSEC-NAT compatibility
solution MUST be deployable on a shorter time scale than IPv6.

Since IPv6 deployment requires changes to existing
hosts, both routers and adds 28 octets of additional overhead. By adding
hosts, a NAT IPSEC-NAT compatibility mode solution which requires
changes to IKE/IPSEC, both routers and hosts will be deployable on
approximately the total same time to negotiate scale as IPv6. Thus, an IPSEC SA
may IPSEC-NAT
compatibility solution SHOULD require changes only to hosts,
and not to routers.

Among other things, this implies that communication between
the host and the NAT MUST NOT be increased significantly. For example, when required by an IKE initiator
fails to receive IPSEC-NAT
compatibility solution, since existing NATs cannot meet such a
requirement.

Telecommuter scenario
Since a response, typical telecommuter is only interested in obtaining
access to the corporate Intranet for itself, an IPSEC-NAT
compatibility solution need not enable gateway-gateway
connectivity. Thus, it can be assumed that negotiated SPD
entries will typically need only refer to try again using
UDP encapsulation, since the lack communication endpoints, and
there is no need to support negotiation of response may have been due SPD entries
involving subnets. to the
presence

Scaling An IPSEC-NAT compatibility solution should be capable of intervening NATs.

7.2. RSIP

RSIP, described in [10]-[11], includes mechanisms for IPSEC traversal,
as described in [12]. By enabling host-gateway communication, RSIP
addresses issues being
deployed within an installation consisting of IPSEC SPI de-multiplexing as well as SPD overlap. It thousands of
telecommuters. In this situation, it is thus suitable for use in enterprise as well as home networking
scenarios.

By tunneling IKE and IPSEC packets, RSIP avoids changes to the IKE and
IPSEc protocols, although major changes are required to IKE and IPSEC
implementations not possible to retrofit them for RSIP-compatibility. It
assume that only a single host is thus
compatible communicating with all existing protocols (AH/ESP) and modes (transport and
tunnel). a given
destination at a time. Thus, an IPSEC-NAT compatibility

Aboba Informational [Page 4] 5]

INTERNET-DRAFT NAT and IPSEC 11 July IPSEC-NAT Compatibility Reqts. 20 November 2000

In order to handle

solution MUST address the issue of overlapping SPD entries and
de-multiplexing of IKE re-keys, RSIP requires
floating incoming packets.

Mode support
At a minimum, an IPSEC-NAT compatibility solution MUST support
passage of the IKE source port, as well as re-keying to the floated
port. As IPSEC ESP tunnel mode through a result, interoperability with existing NAT. Since IPSEC implementations
transport mode is not assured.

Disadvantages of RSIP include that it requires major changes to both
host implementations as well used for tunneling protocols such as to gateways. As a result, an RSIP-
enabled host requires a corresponding RSIP-enabled gateway in order to
establish L2TP
[1], an IPSEC-NAT compatibility solution SHOULD support IPSEC SA with another host.

7.3. IKE and checksum processing changes

In this approach, a number
transport mode using ESP, at least for protection of changes UDP
traffic where no embedded IP addresses are made in IKE usage and checksum
processing. The advantage present. Since
passage of this approach AH through a NAT is that it does not add
additional overhead as does the encapsulation approach. In addition,
minimal changes are required possible in any mode, there
is no need for an IPSEC-NAT compatibility solution to the IKE or IPSEC protocols.

However, this approach offers only limited attempt
to address this.

Interoperability
An IPSEC-NAT compatibility solution MUST be interoperable with
existing IPSEC
tunnel mode (only enabling negotiation of "me" and "any" SPD entries),
and may only be used to allow transport of implementations. Thus, existing IPSEC ESP through a NAT, not
AH.

This approach also requires changes to host
implementations as well as
modest changes to existing NATs. As a result, it can MUST be expected able to
work communicate with a substantial fraction of existing NATs, although by an IPSEC-NAT
compatible implementation in the case where no means
all of them.

Another disadvantage of this approach NAT is present.
This implies that it does not address issues
of SPD conflict or incoming IPSEC SPI de-multiplexing. As a result,
unless it is combined an IPSEC-NAT compatibility solution MUST be
backwards-compatible with a host-gateway communication protocol such IPSEC as
RSIP, this approach cannot defined in [3]-[7], and
SHOULD be applied able to enterprise scenarios where
multiple hosts behind detect the presence of a NAT may establish IPSEC SAs to the same
destination.

In this approach, so that the following
required changes are required:

a) Use of IPSEC ESP null instead of AH.
Since IPSEC ESP null provides integrity protection and
authentication services without covering the IP header
in the message integrity check, IPSEC ESP null is
used in preference to IPSEC AH.

b) Optional checksum verification for IPSEC transport mode SAs.
Since transport mode IPSEC traffic is integrity protected
and authenticated using strong cryptography, modifications
to the packet can NAT compatibility will only be detected prior used when
necessary.

For example, it may be possible to checking UDP/TCP/SCTP
checksums. Thus, checksum verification only provides assurance
against errors made enable ISAKMP to pass
information about each host's perception of its own IP
address, in internal processing. In order to

Aboba Informational [Page 5]

INTERNET-DRAFT make key management aware of the presence
of the NAT and IPSEC 11 July 2000

remove facilitate the incompatibility between checksum processing and
NAT, checksum verification is made optional on packets
covered by IPSEC transport mode SAs.

c) Floating IKE source ports.
To enable NATs to easily de-multiplex IKE traffic, it is
more convenient use of standard key management
methods through a NAT to float IKE source ports than support ESP/AH.

Security An IPSEC-NAT compatibility solution MUST NOT introduce
additional security vulnerabilities into IKE. For example, an
acceptable solution must demonstrate that it introduces no new
denial of service or spoofing vulnerabilities.

8. Existing solutions

8.1. RSIP

RSIP, described in [10]-[11], includes mechanisms for IPSEC traversal,
as described in [12]. By enabling host-gateway communication, RSIP
addresses issues of IPSEC SPI de-multiplexing as well as SPD overlap. It
is thus suitable for use in enterprise as well as home networking
scenarios. By enabling hosts behind a NAT to
de-multiplex using cookies. Assuming source ports are floated,
to enable de-multiplexing of IKE re-keys, share the initiator will need
to send external IP
address of the re-key packets gateway, this approach is compatible with protocols
including embedded IP addresses.

Aboba Informational [Page 6]

INTERNET-DRAFT IPSEC-NAT Compatibility Reqts. 20 November 2000

By tunneling IKE and IPSEC packets, RSIP avoids changes to the IKE source port used in the
original negotiation. Use of floated and
IPSEc protocols, although major changes are required to host IKE source ports and
IPSEC implementations to retrofit them for RSIP-compatibility. It is already
allowed within IKE [7].

d) Use of userIDs
thus compatible with all existing protocols (AH/ESP) and FQDNs as IKE MM modes
(transport and QM identifiers. tunnel).

In order to avoid use handle de-multiplexing of IP addresses as IKE MM and QM identifiers,
userIDs and FQDNs are used instead. Where user authentication
is desired, an ID type re-keys, RSIP requires
floating of ID_USER_FQDN can be used, the IKE source port, as described in
[5]. Where machine authentication is desired, an ID type of ID_FQDN
can be used. In either case it is necessary well as re-keying to verify that the
proposed identity matches that enclosed in the certificate.

8. Security considerations

Since the UDP encapsulation approach requires the additional work of
decapsulation prior to floated
port. As a result, inter-operability with existing IPSEC processing, it may result in increased
susceptibility to denial of service attacks. implementations
is not assured.

However, since no changes
are made in IKE or IPSEC usage, no other vulnerabilities are introduced.

The RSIP approach introduces does not satisfy the requirements for a IPSEC-NAT
compatibility solution because it requires major changes to both hosts and gateways so host
implementations as well as to gateways. As a result, an RSIP-enabled
host requires a corresponding RSIP-enabled gateway in order to establish
an IPSEC SA with another host. This means that it RSIP deployment is likely that additional bugs will be introduced as a result of the scale
same degree of difficulty as IPv6. Similarly for vendors, implementation
of RSIP requires a substantial fraction of the resources required changes. However, the for an
IPv6 solution. Thus, RSIP does not introduce
changes provides the solution to IPSEC a "transitional"
problem on a long-term time scale, which is not useful.

9. Security considerations

By definition, IPSEC-NAT compatibility requires that hosts and IKE routers
implementing IPSEC be capable of securely processing other than the use packets whose IP
headers are not cryptographically protected. A number of floating
source ports, so issues arise
from this that no new protocol vulnerabilities are created.

Changes in IKE usage and checksum processing introduce changes on both
the host and gateways so that new implementation bugs may be introduced
as a result. Of the usage changes, the most significant from worth discussing.

Since IPSEC AH cannot pass through a security
point NAT, one of view is the change in usage of IKE MM and QM identifiers.
There is no security value to TCP/UDP/SCTP checksums, so not checking
them does not decrease security. Similarly, use side effects of
providing an IPSEC-NAT compatibility solution may be for IPSEC ESP with
null
instead encryption to be used in place of AH does not introduce any security vulnerabilities.

Where certificate-based authentication is possible, where a NAT exists between the
source and destination. However, it is believed should be noted that
the use of ID_USER_FQDN or ID_FQDN in IKE MM instead of addresses will ESP with null
encryption does not introduce additional provide the same security vulnerabilities, properties as long as the
presented identity is verified to correspond AH. For
example, there are security risks relating to IP source routing that in the certificate.

Aboba Informational [Page 6]

INTERNET-DRAFT NAT and IPSEC 11 July 2000

Use are
precluded by AH, but not by ESP with null encryption.

In addition, since ESP with any transform does not protect against
source address spoofing, some sort of ID_FQDN or ID_USER_FQDN identifiers in IKE QM raises the issue as
to what traffic will be accepted in the IPSEC SA. Since packets will be
integrity protected, it is possible source IP address sanity checking
needs to verify that be performed. The importance of the source anti-spoofing check is in
posession of not
widely understood. There is normally an anti-spoofing check on the negotiated keys. Thus, for transport mode SAs, it may
be sufficient to require that traffic originate only from a single
Source IP
address (such as Address as part of ipsec_{esp,ah}_input(). This ensures that
the packet originates from the same address used in as that was claimed within
the original IKE QM negotiation), MM and to
verify packet integrity.

Things are somewhat trickier for IPSEC tunnel mode, where restricting
identifiers to ID_USER_FQDN or ID_FQDN would prevent use of subnet or
address range identifiers, which may QM security associations. When a receiving host
is behind a NAT, this check might not strictly be required meaningful for gateway to gateway
communications. Thus unicast
sessions, whereas in the Global Internet this approach check is not universally applicable.

However, in client important for
tunnel-mode unicast sessions to gateway communications with prevent a spoofing attack described in
[14].

Aboba Informational [Page 7]

INTERNET-DRAFT IPSEC-NAT Compatibility Reqts. 20 November 2000

Let us consider two hosts, A and C, both behind (different) NATs, who
negotiate IPSEC tunnel mode SAs,
these restrictions SAs to router B. Hosts A and C may have
different privileges; for example, host A might belong to an employee
trusted to access much of the corporate Intranet, while C might be more workable. a
contractor only authorized to access a specific web site.

If subnet or host C sends a tunnel mode packet spoofing A's IP address range
identifiers are not used, address, as the
source, it is reasonable to assume important that only traffic
from a single IP address is permitted inside the tunnel. A reasonable
assumption would this packet not be accorded the privileges
corresponding to A. If authentication and integrity checking is
performed, but no anti-spoofing check (verifying that this the originating IP
address corresponds to the source
address used when setting up SPI) then host C may be allowed to reach
parts of the IKE QM SA.

9. network that are off-limits. As a result, an IPSEC-NAT
compatibility scheme MUST provide some degree of anti-spoofing
protection.

10. Acknowledgments

Thanks to Steve Bellovin of AT&T Research, William Dixon of Microsoft,
Ran Atkinson of Extreme Networks and Daniel Senie for useful discussions
of this problem space.

10.

11. References

[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and
Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August
1999.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[3] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402,
November 1998.

[4] Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 2406, November 1998.

[5] Piper, D., "The Internet IP Security Domain of Interpretation of
ISAKMP", RFC 2407, November 1998.

[6] Atkinson, R., Kent, S., "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.

[7] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC
2409, November 1998.

Aboba Informational [Page 7]

INTERNET-DRAFT NAT and IPSEC 11 July 2000

[8] Srisuresh, P., and Egevang, K., "Traditional IP Network Address
Translator (Traditional NAT)", Internet draft (work in progress),
draft-ietf-nat-traditional-03.txt, September 1999.
draft-ietf-nat-traditional-04.txt, April 2000.

Aboba Informational [Page 8]

INTERNET-DRAFT IPSEC-NAT Compatibility Reqts. 20 November 2000

[9] Srisuresh, P. and Holdredge, M., "IP Network Address Translator
(NAT) Terminology and Considerations," RFC 2663, August 1999.

[10] Borella, M., Lo, J., Grabelsky, D., Montenegro, G., "Realm Specific
IP: A Framework", Internet draft (work in progress), draft-ietf-
nat-rsip-framework-04.txt, March
nat-rsip-framework-05.txt, July 2000.

[11] Borella, M., Grabelsky, D., Lo, J., Taniguchi, K., "Realm Specific
IP: Protocol Specification", Internet draft (work in progress),
draft-ietf-nat-rsip-protocol-05.txt, January
draft-ietf-nat-rsip-protocol-07.txt, July 2000.

[12] Montenegro, G., Borella, M., "RSIP Support for End-to-End IPSEC",
Internet draft (work in progress), draft-ietf-nat-rsip-
ipsec-03.txt, March 2000.

[13] Information Sciences Institute, "Transmission Control Protocol",
RFC 793, September 1981.

11.

[14] Kent, S., "Authenticated Source Addresses", IPSEC WG Archive (
ftp://ftp.ans.net/pub/archive/ipsec ), Message-Id:
<v02130517ad121773c8ed@[128.89.0.110]>, January 5, 1996.

12. Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: 425-936-6605 +1 425 936 6605
EMail: bernarda@microsoft.com

12.

13. 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.

Aboba Informational [Page 8] 9]

INTERNET-DRAFT NAT and IPSEC 11 July IPSEC-NAT Compatibility Reqts. 20 November 2000

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.

13.

14. Full Copyright Statement

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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

14.

15. Expiration Date

This memo is filed as <draft-aboba-ipsec-nat-02.txt>, <draft-aboba-nat-ipsec-03.txt>, and expires
February July
1, 2001.

Aboba Informational [Page 9] 10]

----