[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                  D. Crocker
Internet Draft                                        Brandenburg
     draft-crocker-mast-proposal-01.doc           InternetWorking
Expires: <2-04>                                September 16, 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 multihomed
     hosts and for mobile hosts. They cannot use more than one, for
     any single transport association (context).  Multiple Address
     Service for Transport (MAST) defines a mechanism that supports
     association of multiple IP addresses with any transport
     association.  It requires no change to the Internet
     infrastructure, no change to IP modules or transport modules in
     the end-systems, and no new administrative effort. Instead, it
     defines a layer between classic IP and transport that operates
     only in the end systems and affects only participating hosts.
     Additional functionality is obtained by use of a DNS and
     "presence" rendezvous service.



     CONTENTS

     1.   INTRODUCTION
     1.1. TERMINOLOGY
     1.2. DISCUSSION VENUE
     1.3. DOCUMENT HISTORY

     2.   REQUIREMENTS

     3.   PROTOCOL
     3.1. TRANSACTION MODEL
     3.2. ASSOCIATION ATTRIBUTES
     3.3. THE INIT OPERATION
     3.4. THE SET OPERATION
     3.5. THE PROBE OPERATION
     3.6. THE SHUT OPERATION
     3.7. THE ERR OPERATION

     4.   TRANSFER SERVICE

     5.   SOURCE VALIDATION

     6.   RENDEZVOUS
     6.1. DNS
     6.2. PRESENCE

     7.   PATH SELECTION

     8.   IMPLEMENTATION
     8.1. TYPICAL TRANSPORT INTERFACING
     8.2. MAST THROUGH NAT
     8.3. MAST AGENT

     9.   SECURITY CONSIDERATIONS

     APPENDIX
     A.   ACKNOWLEDGEMENTS
     B.   REFERENCES
     C.   AUTHOR'S ADRESS
     D.   FULL COPYRIGHT STATEMENT


     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 transport 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 multihomed 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.

     In recent years, there have been efforts to overcome many of
     these limitations, through different approaches at different
     places in the Internet architecture. Some modify the IP
     infrastructure, with embedded redirection services.  Some define
     transport enhancements to support a set of addresses directly,
     and some define a layer between classic IP and classic transport.
     Each of the existing proposals has notable limitations in
     functionality, implementation, deployment or use. A discussion of
     the architectural choices and summary of existing multiaddressing
     projects is in [CHOICE].

     Multiple Address Service for Transport (MAST) supports
     association of multiple IP addresses during the life of any
     transport instantiation, by defining a layer between IP and
     transport. It operates only in the end systems and affects only
     participating hosts. MAST does not require modification to the
     Internet infrastructure and does not require modification to any
     host's IP or transport modules, although improved functionality
     can be obtained with some changes.

     Further, MAST works with existing IPv4 and IPv6 transport
     services and it is useful to any two hosts that try to use it
     with each other. It does not define any new naming or addressing
     structure. It has no additional packet header overhead and
     minimal additional packet-processing overhead. It employs
     existing administrative structures. Hence MAST has a low barrier
     to adoption and use, while permitting more advanced functions
     with more extensive adoption and modification.

     MAST may be invoked at any time, before or during a transport
     association. 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 multihomed 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:     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 LIN6, and a similar
               approach, but uses a simpler protocol, with a
               somewhat narrower functional focus.


1.1. Terminology

     This proposal considers a method that will enable an endpoint
     (host) to use multiple addresses during single application
     associations (sessions).

     "Agent" refers to a forwarding service that represents an
     endpoint for multiaddressing. For mobility, the agent resides on
     the "home" network and relays datagrams to the endpoints actual
     location on the Internet.  The endpoints are modified to support
     this forwarding technique. For multihoming, an agent hides the
     presence of multiple addresses from the endpoint located on the
     local network.

     "Mobility" refers to the availability of different addresses over
     time. This may even include discontinuities, with no available
     addresses, at times. It also may include overlapping availability
     of addresses. Interestingly, this looks the same as multihoming.

     "Multihoming" refers to the availability of multiple addresses
     simultaneously. It is typically used to refer to multiple network
     attachments for a host, but works equally well for multiple
     upstream network attachments by the local network, when the
     different upstream addresses are visible to the host.
     Interestingly, multihomed environments often must support dynamic
     changes, such as when adding a new upstream provider. Therefore,
     multihoming can include mobility features and mobility can
     include multihoming features.

     "Path discovery" provides a sender with the means for learning
     about the addresses from which they can send.

     "Path selection" is required when more than one address is
     available to the sender. Although the sender is limited to
     specifying an address, rather than a path, it appears that
     thinking of it as path selection aid consideration of solutions.
     In effect, it formulates the selection task as being similar to
     the job of routers. Route formulation is mature technology, so
     that this aspect of multiaddress processing will be tractable, if
     not straightforward.

     "Rendezvous" permits a host that is initiating an association to
     find the target of the association, such as a client finding a
     server. "Finding" means obtaining a valid address for the target.
     A public process is required for rendezvous. The primary Internet
     mechanism for rendezvous has been the Domain Name Service (DNS).
     The DNS used long, variable-length strings (names) and is
     tailored for large-scale rendezvous with names and addresses
     (mappings) that change infrequently.


1.2. Discussion Venue

     Discussion and commentary are encouraged about the topics
     presented in this document. The preferred forum is the
     <mailto:multi6@ops.ietf.org> mailing list, for which archives and
     subscription information are available at
     <http://ietf.org/html.charters/multi6-charter.html>.


1.3. Document History

     -00      Initial proposal. Basic concepts. Heavy reliance
              on SCTP and DCCP for style of solutions and
              implied detail.

     -01            Substantial reorganization.
               Added more detail to MAST, including rendezvous
                    and agent, adjunct services
               Extended discussions about alternative proposals
                    and architectural issues, moved to -analysis-
                    draft.
               Removed explicit SCTP/DCCP usage.
               Removed NAT references from architecture
                    discussions.



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

     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 multiaddress mechanism.

     c)   The service must be resilient against classic, basic security
          threats, especially spoofing (association hijacking).

     d)   The service must operate across administrative and operational
          boundaries and across address translation boundaries (NAT).



3.   PROTOCOL

     This section discusses MAST operations between participating
     hosts.


3.1. Transaction model

     MAST uses a simple request/response. Each request receives a
     response. The response forms the basis of MAST transaction
     reliability.  A request is retransmitted when a response is not
     received.  Retransmission rules use the usual exponential
     backoff.

     <STATE        As guidance about the association
     DIAGRAM>      relationship between two participating MAST
                   hosts, SCTP Section 4, "SCTP Association
                   State Diagram" provides a useful, starting
                   framework. See [SCTPMOB] for discussion of
                   mobility enhancements that are applicable
                   to MAST.


3.2. Association Attributes

     An MAST association is between a pair of hosts, defined by
     endpoint identifiers, an association label and a transaction
     sequence identifier.

     It comprises a domain name double, an Association Nonce double,
     and a transaction sequence number (TSN) double:

          Endpoint       Globally unique, macro-labels
          identifiers:   comprising a domain name for each host

          Endpoint       Association nonce, with cryptographic
          association    protection against hijacking. It is an
          label:         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].

          Sequence       A Transaction Sequence Number (TSN)
          label:         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.


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

     The "init" operation includes:

          *    Sender and Receiver domain names
          *    Association Nonce
          *    TSN
          *    List of sender IPv4 and IPv6 addresses


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

     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.


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


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

     The "shut" operation includes:

          *    Association Nonce
          *    TSN
          *    Sender and Receiver domain names


3.7. The ERR Operation

     ERR elements are sent, in MAST, when there is an error.

     The "err" operation includes:

          *    Association Nonce
          *    TSN
          *    Error information



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

     A simple use of UDP will suffice, with MAST responses providing
     the needed transfer acknowledgement. The full specification will
     provide for retransmission controls.

     Security is built into the MAST protocol, rather than its
     transfer service.



5.   SOURCE VALIDATION

     The minimal level of implicit source validation that exists
     within existing transport services' use of IP is eliminated with
     multiaddressing.  This invites hijacking attacks.

     At the start of an association, MAST establishes association
     nonce that is used for later exchanges.  This nonce is created
     while only one address is in force.

     The method of establishing the nonce will follow the lines of
     PBK, SCTP or DCCP, as dictated by the limited security
     requirements to prevent hijacking.



6.   RENDEZVOUS

     How does one endpoint find another? The current answer is DNS.
     However multiaddressing introduces some challenges. Classic DNS
     use permits finding a set of addresses associated with a domain
     name. For finding a static, multihomed target, this is probably
     sufficient. The fact that the initiator is mobile can be
     communicated to the target by the initiator.

     However when the target is mobile, an additional support
     mechanism is needed. This section defines an adjunct service to
     finding mobile targets.


6.1. DNS

     Rendezvous with mobile targets is supported through a two-stage
     process.  A domain name is used as the stable, public EID.

     An SRV record is defined to reference a dynamic "presence"
     service through which an endpoint can register its current set of
     IP addresses.


6.2. Presence

     The requirement to discover current IP addresses for an endpoint,
     and to be notified when they change, suits existing presence
     service models rather nicely.

     MAST is defined to use the presence service available through
     [XMPP]. The definition of this mechanism will be for standard
     XMPP, with some addressing conventions to specify the target
     system's domain name at a particular presence server.

     Development of the detailed specification may lead to choosing a
     different service. However, dynamic rendezvous is an adjunct
     function for MAST.  Hence it is not essential to develop this
     capability for initial use of the service.



7.   PATH 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 Agent

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



APPENDIX


A.   Acknowledgements

     Funding for the RFC Editor function is currently provided by the
     Internet Society.

     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]. The
     core ideas for MAST were developed by the author a number of
     years ago.  Christian Huitema independently developed the same
     technical constructs, at the same time.

     When upper-layer mapping was first suggested, the most serious
     concern was for securing the exchange of additional address
     information, to prevent connection hijacking.  Purpose-Built Keys
     and the mechanisms in SCTP and DCCP nicely resolve this manner,
     without requiring a massive security infrastructure. As noted
     earlier in this document, recent work on HIP and LIN6 continue
     the core construct of an IP/transport wedge for mapping
     addresses.

     Commenters on this text include: Marcelo Bagnulo, Iljitsch van
     Beijnum, Vint Cerf, Spencer Dawkins, Robert Honore, James Kempf ,
     Eugene Kim, Eliot Lear, Pekka Nikander, Erik Nordmark, Tim
     Shepard, Randall R. Stewart, and Fumio Teraoka, Joe Hildebrand.


B.   References


     B.1. Normative

     [HIPARC]  Moskowitz, R., "Host Identity Protocol
               Architecture", < http://www.ietf.org/internet-
               drafts/draft-moskowitz-hip-arch-03.txt >

     [PBK]     Bradner, S., Mankin,  AS., Schiller, J.,  "A
               Framework for Purpose-Built Keys (PBK)",  draft-
               bradner-pbk-frame-06.txt, June 2003

     [RAND]    Eastlake, D., S. Crocker, J. Schiller. ,
               "Randomness Recommendations for Security", RFC
               1750, December 1994.

     [XMPP]    Saint-Andre, P., Miller, J., "XMPP Core", draft-
               ietf-xmpp-core-18, September 7, 2003


     B.2. Non-Normative

     [CHOICE]  Crocker, D., "Choices for Support of
               Multiaddressing", draft-crocker-mast-analysis-
               00.txt, September 16, 2003

     [DCCP]    Kohler, E., M. Handley, S. Floyd, J. Padhye,
               "Datagram Congestion Control Protocol (DCCP)",
               draft-ietf-dccp-spec-04.txt, 30 June 2003

     [EID]     Chiappa, J.N.,   "Endpoints and Endpoint Names:
               A Proposed Enhancement to the Internet
               Architecture",
               <http://users.exis.net/~jnc/tech/endpoints.txt>,
               1999

     [ETCP]    Zhang, B., Zhang, B.,  Wu,  I., "Extended
               Transmission Control Protocol (ETCP) Project--
               Extension to TCP for Mobile IP Support",
               <http://www.cs.ucla.edu/~bzhang/etcp/report.html
               >

     [HIP]     Moskowitz, R., "Host Identity Protocol
               Architecture", < http://www.ietf.org/internet-
               drafts/draft-moskowitz-hip-arch-03.txt >

               Moskowitz, R., "Host Identity Protocol", <ietf-
               id: draft-moskowitz-hip-07>

               Nikander, P., "End-Host Mobility and Multi-
               Homing with Host Identity Protocol", <
               http://www.ietf.org/internet-drafts/draft-
               nikander-hip-mm-00.txt>

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

     [LIN6]    Teraoka, F.,  Ishiyama, M.,  Kunishi, M., "LIN6:
               A Solution to Mobility and Multi-Homing in
               IPv6", draft-teraoka-ipng-lin6-02.txt, 24 June
               2003

     [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>

     [NAT]     Egevang, K., and P. Francis, "The IP Network
               Address Translator (NAT)", RFC1631, May 1994

     [NSRG]    Lear, E., Droms, R., "What's In A Name: Thoughts
               from the NSRG", draft-irtf-nsrg-report-09.txt,
               March 2003

     [MIP]     Perkins, C., "IP Mobility Support", RFC 2002,
               October 1996

               Johnson, D., Perkins, C., Arkko, J., "Mobility
               Support in IPv6", draft-ietf-mobileip-ipv6-
               24.txt, June 30, 2003

               Bagnulo, M., Garcia-Martinez, A., Soto, I.,
               "Application of the MIPv6 protocol to the multi-
               homing problem", draft-bagnulo-multi6-mnm-00,
               February 25, 2003

     [PRIV]    Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J.
               de Groot, and E. Lear, "Address Allocation for
               Private Internets", RFC 1918,  February 1996.

     [SCTP]    L. Ong, and J. Yoakum "An Introduction to the
               Stream Control Transmission Protocol (SCTP)",
               <http://ietf.org/rfc/rfc3286.txt?number=3286>,
               May 2002

               Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
               Schwarzbauer, H., Taylor, T., Rytina, I., Kalla,
               M., Zhang, L., Paxson, V., Stream Control
               Transmission Protocol", RFC 2960, October 2000

     [SCTPMOB  R. Stewart, et al, "Stream Control Transmission
     ]         Protocol (SCTP) Dynamic Address
               Reconfiguration", draft-ietf-tsvwg-addip-sctp-
               07.txt, February 26, 2003

     [TCPMH]   Matsumoto, A. Kozuka, M., Fujikawa, K., Okabe,
               Y., "TCP Multi-Home Options", draft-arifumi-tcp-
               mh-00.txt, 10 Sep 2003

     [TLS]     Dierks, T., C. Allen , "The TLS Protocol Version
               1.0", RFC 2246, January 1999.


C.   Author's Adress

     Dave Crocker
     Brandenburg InternetWorking
     675 Spruce Drive
     Sunnyvale, CA  94086  USA

     tel: +1.408.246.8253
     dcrocker@brandenburg.com


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

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/