Network Working Group D. Crocker
Internet Draft Brandenburg
draft-crocker-mast-proposal-00.txt InternetWorking
Expires: <2-04> August 28, 2003
Multiple Address Service For Transport (MAST):
An Extended Proposal
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.
COPYRIGHT NOTICE
Copyright (C) The Internet Society (2003). All Rights
Reserved.
ABSTRACT
Classic Internet transport protocols use a single source IP
address and a single destination IP address, as part of the
identification for an individual data flow. TCP includes
these in its definition of a connection and its calculation
of the header checksum. Hence the transport service is tied
to a particular IP address pair. This is problematic for
multi-homed hosts and for mobile hosts. Both have multiple
IP addresses but cannot use more than one, for any single
transport association (context). Multiple Address Service
for Transport (MAST) defines a mechanism that transparently
supports association of multiple IP addresses with any
transport association. It requires no change to the IP
infrastructure, and no change to IP modules or transport
modules in the end-systems. Instead, it defines a wedge
layer between IP and transport that operates only in the end
systems and affects only participating hosts.
CONTENTS
1. INTRODUCTION
2. IETF BACKGROUND
2.1. HIP
2.2. DCCP
2.3. SCTP
3. REQUIREMENTS
4. FRAMEWORK
4.1. Architectural Model
4.2. Alternative Approaches
4.3. Operation Through Nats
5. MAST FUNCTIONALITY
5.1. Association Attributes
5.2. The INIT Operation
5.3. The SET Operation
5.4. The PROBE Operation
5.5. The SHUT Operation
5.6. The ERR Operation
6. TRANSFER SERVICE
7. ADDRESS SELECTION
8. IMPLEMENTATION
8.1. Typical Transport Interfacing
8.2. Mast Through Nat
8.3. Mast In Nat
9. SECURITY CONSIDERATIONS
10. APPENDIX
10.1. Acknowledgements
10.2. References
10.3. AuthorsÆ Addresses
10.4. Full Copyright Statement
1. INTRODUCTION
Classic Internet transport protocols use a single source IP
address and a single destination IP address, as part of the
identification for an individual data flow. For example,
TCP includes these in its definition of a connection and its
calculation of the header checksum. Hence a classic
transport association is tied to a particular IP address
pair. This is problematic for multi-homed hosts and for
mobile hosts. Both have access to multiple IP addresses,
but they are prevented from using more than one within an
existing transport exchange. For a host to use a different
IP address pair, participants must initiate a new exchange.
In the case of TCP, this means a new connection.
Multiple Address Service for Transport (MAST) defines a
mechanism to support association of multiple IP addresses
during the life of any transport instantiation. It requires
no change to existing transport protocols and no changes to
IP. Instead, it defines a wedge layer between IP and
transport. It operates only in the end systems and affects
only participating hosts. MAST may be invoked at any time,
for existing or future transport associations.
Hence a host may initiate and conduct a classic, single IP-
pair TCP connection. It may then separately query for remote
host support of MAST and initiate a MAST exchange to be used
by that connectivity. Either participant is then free to
add or remove addresses. Of course use of MAST may instead
be performed before a transport context is established, so
that future contexts immediately have access to multiple IP
addresses.
For a multi-homed host it will be reasonable to associate
multiple IP addresses with a transport context at the time
the first context between that host-pair is initiated. For
a mobile host, addresses may be added and removed as the
host moves across the Internet fabric, acquiring and losing
use of different IP addresses. Over the life of a mobile
transport context, different addresses might be active at
different times. Support is provided for continuation of
service across complete connectivity interruptions to mobile
hosts, when a host's set of available IP addresses becomes
empty and the host later re-acquires a usable IP address.
NOTE: This document is an extended proposal,
rather than a fully detailed
specification. It defines MAST
functionality, nearly to the level of
specification. However it leaves some
details unresolved, in the belief that
they are essential to implementation of
the protocol, but not to the initial
analysis of its proposal. The proposal
also incorporates some critical details
by reference and general adaptation,
rather than stating then in the detail
that is needed for a complete
specification. Again, this permits
initial analysis but is not sufficient
for adoption and implementation.
2. IETF BACKGROUND
Support for mobility and multi-homing have been notable
challenges within the Internet architecture. Classic
connection-based transport services do not mobility
directly, nor can they take advantage of multiple access
paths accessible through alternate IP addresses. When a
host gains a new IP address, transport services can exercise
it only with new connections.
IETF focus on mobility has split between using DHCP for
initial system attachment to the network, versus using
infrastructure-based IP forwarding services. In contrast,
the current proposal provides support that requires no new
infrastructure and no changes to existing protocols.
This work derives from discussions in the IETF, in the mid-
1990s. A particular technical concern was protecting the
address-changing negotiation.
The current proposal leverages recent work done on HIP
[HIPARC, HIP, MOBHOM], although it makes significantly
different technical choices. MAST incorporates a number of
the capabilities provided by [SCTP] and [DCCP].
2.1. HIP
The MAST proposal exploits the considerable HIP work done to
uncover usability issues and edge conditions. MAST suggests
the same core functionality as HIP and a similar approach,
but uses a simpler protocol, with a somewhat narrower
functional focus.
HIP has a substantial focus on creating and using special
security mechanisms. MAST has more somewhat more modest
requirements and relies on the kind of protection provided
in SCTP.
Unlike HIP, MAST does not define a new, global name space.
Rather, it employs random, transient identifiers that are
known only to the host-pair that use them in MAST. They
protect against redirection attacks and support recovery
after loss of IP addresses. Existing mechanisms are used
for rendezvous and system identification.
The HIP Section 3 discussion, Usage Scenarios, provides an
excellent description of the environments for which this
proposal is intended. However Section 3.2, Location Privacy,
is not pursued in MAST. It would be an interesting
enhancement over the core requirement, but is inessential to
that core. It is likely that this proxy masking capability
can be layered on top of the current specification, as a
MAST control exchange "relaying" mechanism.
Section 3 of [MOBHOM], without section 3.2,
is included here, by reference.
The section comprises the following sub-
sections:
3. Usage scenarios
3.1 End-host mobility
3.2 Location privacy à
3.3 End-host multi-homing
3.4 Site multi-homing
3.5 Combined mobility and multi-homing
3.6 Network renumbering
3.7 Combined all
2.2. DCCP
DCCP is a proposal for an unreliable datagram delivery
service. It specifies a connection mechanism that seems
particularly robust for protecting MAST against redirection
attacks.
2.3. SCTP
SCTP is a reliable transport protocol for multiplexed data
streams. It includes modern mechanisms for safe initiation
of a connection, as well as the necessary tools for
reliability and congestion control. It also has a mechanism
for communication access to multiple IP addresses between
the participation host pair.
MAST does not need the general transport mechanisms that are
in SCTP, for user data and its reliable transport. Further
MAST traffic is expected to comprise few, occasional
packets. Hence, the concern for MAST's being congestion-
friendly is quite limited.
NOTE: For simplicity, this MAST proposal uses a
subset of SCTP as references (examples)
for its core features. This supplies
guidance for basic packet formats,
components of functionality, appropriate
security techniques, and support for IPv4
and IPv6 addressing.
3. REQUIREMENTS
MAST has four requirements:
a) The goal for this service is to support the use of multiple
IP addresses by either participant in a transport association.
When multiple addresses are stable and pre-existing,
the host is called "multi-homed". When the set of
usable IP addresses varies over the life of the
association, the host is called "mobile".
NOTE: When a stable network changes its
connectivity to the rest of the Internet
-- such as when it changes up-stream
providers -- the change can be viewed as
a kind of mobility. This is significant,
to the extent that MAST can facilitate
network migrations to different
providers.
b) The service should require no changes to the IP network
infrastructure, to the IP layer in end-systems, or to the
transport layer in the end-systems.
All knowledge of the service, and all activity about
it, must reside only in the end-systems using it. In
order to avoid start-of-association operation, the
service must support operation of classic transport
associations, with post-hoc introduction of the multi-
address mechanism.
c) The service must be resilient against classic, basic
security threats, especially spoofing, where a third-party
attempts to take over the association.
d) The service must operate across administrative and
operational boundaries and across address translation
boundaries (NAT).
4. FRAMEWORK
4.1. Architectural Model
The current architecture for transport use of IP addresses
makes a direct linkage to a specific IP address pair:
Connection
(IP.a, Port.l, IP.y, Port.r)
+-----------------+
| Port.l | Port.r
+-----+ +-----+
| TCP | | TCP |
+-----+ +-----+
| IP.a | IP.y
+-----+ +-----+
| IP | | IP |
+-----+ +-----+
| | | |
IP.a IP.f IP.q IP.y
This example shows each host being multi-homed. Each must
choose a single IP address and bind the connection to it.
MAST permits each host to use one, then the other, or both
of its available addresses, varying the binding and the use
over the life of the connection.
Connection
(IP.a, Port.l, IP.y, Port.r)
+-------------------------+
| Port.l | Port.r
+------+ +------+
| TCP | | TCP |
+------+ +------+
IP.a | | IP.y
|+----+ control +----+|
< MAST >-----------< MAST >
|+----+ +----+|
IP.a,| |IP.q,
IP.f | | IP.y
+------+ +------+
| IP | | IP |
+------+ +------+
| | | |
IP.a IP.f IP.q IP.y
MAST is a control protocol for the exchange of notification
and authorization information, to use additional IP
addresses in a given host-pair context.
The primary MAST exchange transmits:
* A list of current IP addresses supported by the sender
Support exchanges:
* Establish a host-pair context
* Establish relevant authentication between the pair
4.2. Alternative Approaches
It is possible to support multi-homing and mobility through
a number of different mechanisms.
4.2.1. Application-Level
Applications often provide themselves with enhanced
infrastructure support services, to compensate for the lower
protocol layers that lack the requisite features. A typical
example is with reliable data transfer, when using an
unreliable datagram service. The obvious difficulty with
this approach is that it burdens each new application with
re-creating these underlying services.
Although there might be some benefit in permitting
applications to discover details about multiple-address
capabilities, and possibly even to specify some controls
over their use, the prevalence of multi-homing and mobility
dictate their support in lower layers.
4.2.2. Transport-Level
Recent transport protocols, such as SCTP and the proposal
for DCCP, provide for the use of multiple IP addresses in a
session. This has the benefit of placing the necessary
functionality only in end-systems. It well might be the
best, long-term architectural choice. However the fact that
the functionality is applicable to all transport services
suggests that there should be some consideration of the
benefit in having IP multi-homing and mobility functionality
reside in a single architectural module, separate from any
specific transport service.
In any case, these new transport protocol efforts cannot
affect the considerable installed base of services using
older transport protocols, such as TCP and UDP. MAST is
designed to work with unmodified versions these protocols
and it achieves this functionality without imposing any
start-of-association delays.
4.2.3. Session-Level
In effect, implementing support in a layer that is above
transport, but below the application, is a way of
institutionalizing application-level support. The merit of
placing multi-homing and mobility support at the session
layer is that it can use multiple transport services.
The problem with this approach is that a full session layer
typically requires replicates substantial portions of the
transport service, in order to ensure reliability and in-
order data sequencing. This makes the session-level
approach notably complicated.
4.2.4. IP-Level
Classic approaches to mobility support involve the addition
of mechanisms to the IP layer, such as with encapsulating
forwarding services.
Conceptually, the biggest problem with this approach is that
it attempts to take topology-related information -- the IP
address -- and use it non-topologically.
Operationally, the biggest problems with this approach are
that forwarding services are inefficient, multi-layer
encapsulation adds complexity, and the service requires
infrastructure change. Changing the infrastructure also
makes the adoption process much slower and more fragile.
4.2.5. Host Identity Protocol (HIP)
HIP takes an approach that has notable similarities to MAST.
It creates a "wedge" layer in between IP and Transport.
The HIP approach:
* Creates a new, globally unique name space
* Uses strong, cryptographically based protocol details,
overloading some HIP functionality with security
functionality
* Is tied significantly to [IPSEC]
* Creates a new DNS RR entry
* Requires a Rendezvous server for mobility support
* Requires that NATs be aware of HIP
Many of the HIP features are appealing, such as the
cleanliness of the architectural model depicted in Section 4
of [HIPARCH]. Were the Internet stack being created now,
HIP well might be an excellent approach. However
retrofitting this approach into the existing, deployed
Internet entails serious barriers to adoption.
MAST is explicitly designed to impose the minimum change
feasible. It seeks to achieve the basic function of
supporting multiple addresses between host transport
associations. Problems such as rendezvous, flooding and
spoofing are significant, but they go beyond the basic
requirement of multi-address support. Hence they are
deferred for separate solution.
MAST takes a more modest approach, with a simpler
specification, and permitting easier implementation and
adoption.
Consequently, MAST differs from the list of HIP requirements
in that it:
* Uses a name space that is transient and local to the
host-pair
* Uses existing, SCTP security mechanisms
* Has no special requirements on DNS
* Defers the question of rendezvous
* Is transparent to NATs
In general, addition of a DNS SRV record can be useful for
achieving efficient rendezvous, with or without mobility.
It permits participants to know whether a service is
supported by its partner, without requiring a probe packet.
However this enhancement to DNS data structures is not
required.
The same assessment applies to pursuit of a separate
rendezvous service.
Security functions that are essential to proper operation of
MAST are adapted from those used in SCTP, for the same
purpose.
4.3. Operation Through NATs
A Network Address Translation (NAT) device maps between one
set of addresses, and another. In typical cases, addresses
from the interior of a network are mapped to different ports
on a single, public address on the outside of the network.
Obviously this mapping task must be performed with knowledge
of transport protocol details and must adjust transport
headers, as well as IP-level addresses.
Stateless NATs need no modification to support MAST, in that
the NAT will simply do its usual task of replacing IP
addresses and adjusting dependent transport headers
accordingly. However, there is the basic question of
whether a sending MAST participant correctly knows its own
addresses. In this, MAST suffers the same difficulty as
other application protocols that embed IP addresses.
ISSUE: How does this limit real-world utility of
the protocol?
Interestingly, MAST can be implemented as a NAT that is
internal to an end-system. That is, one can model the
implementation of MAST as a NAT activity between the IP
layer and the transport layer inside the host. It takes one
set of addressing attributes on one side and maps them to
another set on the other side.
ISSUE: Is this perspective useful? Does it
suggest additional benefits or problems?
5. MAST FUNCTIONALITY
This section discusses MAST operations between participating
hosts. Since this is a proposal, rather than a detailed
specification, discussion is about basic functionality, with
examples drawn from SCTP to illustrate how the function can
be performed in a way that is appropriate for MAST.
NOTE: As guidance about the association
relationship between two participating
MAST hosts, SCTP Section 4, "SCTP
Association State Diagram" provides a
useful framework. See [SCTPMOB] for
discussion of mobility enhancements that
are applicable to MAST.
5.1. Association Attributes
An MAST association is between a pair of hosts. It
comprises a domain name double, an Association Nonce double,
and a transaction sequence number (TSN) double.
* It has a globally unique, macro-label comprising a domain
name for each host, and an internal, association label
comprising
an Association Nonce double, with one from each host.
* The Association Nonce is an internal identifier for the
MAST association; it comprises a random value, such as
defined in Section 6.4.2, "Connection Nonce Feature" and
used in Section 6.4.3, "Identification Option", in
[DCCP]. Also see [RAND].
* The TSN indicates data flow during the association and is
used for detecting duplicates, detecting missing data,
and correlating responses.
NOTE: More complex association behaviors are
possible, such as permitting
specification of address subsets for
different transport context. This level
of sophistication is beyond the scope of
the current effort, but will be
interesting to explore after a basic
capability is achieved.
5.2. The INIT Operation
At the beginning of a MAST session, each host sends an
"init" element, to create a host-pair association and define
the initial set of valid addresses that may be used. The
association is fully established after each host has
received an acknowledgement to the "init" operation that it
sent.
NOTE: SCTP Section 3.3.2, "Initiation (INIT)"
defines a mechanism that provides this
capability.
The "init" operation includes:
* Sender Association Nonce
* TSN
* Sender and Receiver domain names
* List of sender IPv4 and IPv6 addresses
5.3. The SET Operation
When a host wants to specify a new list of its own IP
addresses, supported in this MAST association with the other
host, it sends a "SET" operation to the other host.
This function is isomorphic with the INIT operation, except
that it uses the existing "Association Nonce" and continues
the existing TSN sequence. The domain names must be the same
as were used in the "init" operation for this association.
NOTE: A SET operation may occur after a
complete interruption of service, such as
when a mobile host has not had
connectivity for a time, and then
reacquires access to the network. In
this case, the set of sender addresses is
likely to have no members in common with
the set that was valid before the
interruption.
NOTE: A complete list of valid addresses is
included, rather than specifying only
incremental changes. The list of valid
addresses is small and does not require
the synchronization complexity of an
incremental function.
5.4. The PROBE Operation
Status of the association is queried with the "probe"
operation. It serves three functions:
* Permit a sender to discover the IP address and port
number, being presented to a receiver, if subject to NAT
transformations; the receiving MAST participant responds
with the sender's IP address and port number it received
in the IP datagram for the PROBE operation.
* Confirm the continued utility of the destination address
used for the PROBE operation.
* Provide an association keep-a-live.
The "probe" operation includes:
* Association Nonce
* TSN
* Sender and Receiver IP addresses
The IP addresses in the "probe" operation are the same as
are specified by the sender in the containing IP datagram.
The "probe response" operation includes:
* Association Nonce
* TSN
* Received MAST Probe-level Sender and Receiver IP
addresses
* Received IP-level Sender and Receiver IP addresses
5.5. The SHUT Operation
The SHUT operation terminates use of MAST between a host-
pair; it uses a 3-way graceful close, with no half-open
state.
NOTE: SCTP Section 3.3.8 "Shutdown Association
(SHUTDOWN)" defines a mechanism that
provides this capability.
The "shut" operation includes:
* Association Nonce
* TSN
* Sender and Receiver domain names
5.6. The ERR Element
ERR elements are sent, in MAST, when there is an error.
NOTE: SCTP Section 3.3.10, "Operation Error
(ERROR)" defines a mechanism that
provides this capability.
The "err" operation includes:
* Association Nonce
* TSN
6. TRANSFER SERVICE
The MAST control exchange has modest transfer (transport)
requirements, except that it must itself be able to operate
by using multiple IP addresses for each host. Transactions
are small and are expected to be infrequent. However they
must be reliably delivered, and they must be secure, with
respect to redirection and replay attacks by third parties.
NOTE: As appropriate, algorithms and services
can be adapted from SCTP, to provide
reliable, secure exchange of address
information by MAST.
7. ADDRESS SELECTION
Having gained access to the list of IP addresses by which a
destination host may be reached, a sender must select one,
for the next set of data. As with any dynamic resource
selection opportunity, the choice of schemes is extensive
and can be quite sophisticated. However until there is
experience with the basic dynamics of this service,
conservative usage models are encouraged.
As with SCTP, the conservative approach is to choose a
primary address and use others as alternatives only to
ensure robustness to the association. Periodic use of the
PROBE operation to each addresses that the other side
purports to have available will provide basic path
availability and performance data.
8. IMPLEMENTATION
The MAST protocol only provides for controlled and protected
exchange of address lists. The utility of these lists
hinges on their integration into host networking stack
services.
8.1. Typical Transport Interfacing
This discussion considers addition of MAST to an existing
Internet protocol stack. It is possible to integrate MAST
more tightly and efficiently, but this is not an immediate
concern for early adoption of the service.
MAST must be added to a host implementation of Internet
Protocol and associated transport services, in a way that is
transparent to the IP module and the transport modules. It
is injected between IP and transport. Interfacing to IP
transparently is straightforward.
For classic transport services that use IP addresses, it is
necessary to present a single, consistent address during the
life of the association. When MAST is invoked after the
start of a transport association, the transport service will
already have a particular address that it associates with
the other participant. In this case, it is easiest to map
the packets being handed up to the transport layer, from
additional addresses into the original one.
Another approach is to make all destination addresses appear
to the transport service as coming from an internally
allocated address, such as one allocated in [PRIV]. A
networking software stack would use public IP addresses for
rendezvous functions, but transport would re-use addresses
from this private, internal address space.
8.2. MAST through NAT
Network Address Translation [NAT] devices map one address
space into another, typically between an intranet set of
host addresses to a smaller set of Internet addresses. In
effect, they use port numbers as a means of mapping internal
hosts to the smaller set of external addresses.
This causes problems for any transport that performs end-
system calculations that using IP addresses. The end system
does the calculations on one set of addresses, but the NAT
device changes an address, so that the calculation by the
receiving party will not be correct. Hence, NAT devices
also need to know about transport-level use of IP addresses
and must adjust the values for those calculations carried in
transport (or above) headers.
MAST exacerbates this situation, since the mapping between
IP address and transport calculations is more complicated.
Whereas there used to be only one IP address to worry about,
now there can be more.
Note the section 4.3 specification of the "probe" operation,
to discover NAT transformation on the sender's address.
8.3. MAST in NAT
Multi-homing is often a feature of a network, rather than a
host. Hosts often do not know that there are multiple
Internet connections, especially when the local network uses
internal (private) addressing that is different from the
network's public address.
In these cases, it might be possible for MAST to be
implemented as a feature of the local network's NAT
function, rather than in the end-system. Since the NAT is
already doing address translation, adding MAST only requires
that the NAT query the other end of the communication, to
obtain permission to add MAST exchanges and multiple
addresses.
9. SECURITY CONSIDERATIONS
Basic Internet transport protocol activity does not apply
any security-related mechanisms, other than relying on
having a source addresses be usable as a destination
address, to reach the originator of the previous, source
data. So, transport-level security is based on address
confirmation by virtue of reachability. This reliance on
underlying routing behavior has well-known weaknesses. MAST
does not to exacerbate or remedy them.
However, MAST affects the core of Internet transport
associations, by permitting new addresses to be associated
with traffic for other addresses. Hence, MAST invites
spoofing, redirection, and other manners of evil.
The protection against these attacks is to conduct MAST
control exchanges over a session that is protected, so that
modification to the set of addresses permitted between a
host-pair take place over a channel that cannot be spoofed,
redirected, or the like.
Protection is based on association-time self-authentication.
Using the same basis as applies to typical transport session
validation, MAST participants exchange protection keys prior
modification of the list of acceptable addresses. These
keys are then used in later transactions.
Section 11.2.4.2, Blind Masquerade, of [SCTP]
is incorporated by reference.
When stronger protection is needed, [IPsec] or [TLS] should
be used for the MAST control channel, or application-level
security should be used for the user data flows.
10. APPENDIX
10.1. Acknowledgements
Funding for the RFC Editor function is currently provided by
the Internet Society.
The original ideas for MAST were developed a number of years
ago. Christian Huitema independently developed the same
technical constructs, at the same time.
When a wedge layer was first suggested, the most serious
concern was for securing the exchange of additional address
information. The mechanisms in SCTP nicely resolve this
manner, without requiring a massive security infrastructure.
As noted earlier in this document, recent work on HIP
continues the core construct of an IP/transport wedge for
mapping addresses.
10.2. References
10.2.1. Normative
[DCCP] Kohler, E., M. Handley, S. Floyd, J.
Padhye, "Datagram Congestion Control
Protocol (DCCP)", draft-ietf-dccp-spec-
04.txt, 30 June 2003
[HIPARC] Moskowitz, R., "Host Identity Protocol
Architecture", <
http://www.ietf.org/internet-drafts/draft-
moskowitz-hip-arch-03.txt >
[MOBHOM] Nikander, P., "End-Host Mobility and Multi-
Homing with Host Identity Protocol", <
http://www.ietf.org/internet-drafts/draft-
nikander-hip-mm-00.txt>
[RAND] Eastlake, D., S. Crocker, J. Schiller. ,
"Randomness Recommendations for Security",
RFC 1750, December 1994.
[SCTP] L. Ong, and J. Yoakum "An Introduction to
the Stream Control Transmission Protocol
(SCTP)",
<http://ietf.org/rfc/rfc3286.txt?number=328
6>, May 2002
[SCTPMOB] R. Stewart, et al, "Stream Control
Transmission Protocol (SCTP) Dynamic
Address Reconfiguration", draft-ietf-tsvwg-
addip-sctp-07.txt, February 26, 2003
10.2.2. Non-Normative
[HIP] Mostkowitz, R., "Host Identity Protocol",
<ietf-id: draft-moskowitz-hip-07>
[IPSEC] Kent, S. and R. Atkinson, "Security
Architecture for the Internet Protocol",
RFC 2401, November 1998
[NAT] Egevang, K., and P. Francis, "The IP
Network Address Translator (NAT)", RFC1631,
May 1994
[PRIV] Rekhter, Y., B. Moskowitz, D. Karrenberg,
G. J. de Groot, and E. Lear, "Address
Allocation for Private Internets", RFC
1918, February 1996.
[TLS] Dierks, T., C. Allen , "The TLS Protocol
Version 1.0", RFC 2246, January 1999.
10.3. AuthorsÆ Addresses
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086 USA
tel: +1.408.246.8253
dcrocker@brandenburg.com
10.4. 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
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.