rfc3374.txt

RFC 的详细文档！


RFC 3374           Context Transfer Problem Statement     September 2002


   subnets.  Layer 3 context transfer may not provide a significant
   improvement over Layer 2 solutions, even for Layer 3 context, if the
   handover is occurring between two subnets supporting the same Layer 2
   radio access technology.

6.0 Performance Considerations

   The purpose of context transfer is to sustain the context
   transfer-candidate services being provided to a mobile host's traffic
   during handover.  It is essentially an enhancement to IP mobility
   that ultimately must result in an improvement in handover
   performance.  A context transfer solution must provide performance
   that is equal to or better than re-initializing the context
   transfer-candidate service between the mobile host and the network
   from scratch.  Otherwise, context transfer is of no benefit.

7.0 Security Considerations

   Any context transfer standard must provide mechanism for adequately
   securely the context transfer process, and a recommendation to deploy
   security, as is typically the case for Internet standards.  Some
   general considerations for context transfer security include:

   - Information privacy: the context may contain information which the
     end user or network operator would prefer to keep hidden from
     unauthorized viewers.

   - Transfer legitimacy: a false or purposely corrupted context
     transfer could have a severe impact upon the operation of the
     receiving router, and therefore could potentially affect the
     operation of the access network itself.  The potential threats
     include denial of service and theft of service attacks.

    - Security preservation: part of the context transfer may include
     information pertinent to a security association established between
     the mobile host and another entity on the network.  For this
     security association to be preserved during handover, the transfer
     of the security context must include the appropriate security
     measures.

   It is expected that the measures used to secure the transport of
   information between peers (e.g., IPSEC [10]) in an IP network should
   be sufficient for context transfer.  However, given the above
   considerations, there may be reason to provide for additional
   security measures beyond the available IETF solutions.






Kempf                        Informational                      [Page 8]

RFC 3374           Context Transfer Problem Statement     September 2002


   Since context transfer requires a trust relationship between network
   entities, the compromise of only one of the network entities that
   transfer context may be sufficient to reduce the security of the
   whole system, if for example the context transferred includes
   encryption keying material.  When the host moves from the compromised
   network entity to an uncompromised network entity in the presence of
   context transfer, the compromised context may be used to decrypt the
   communication channel.  When context transfer is not used, a
   compromise of only one network entity only gives access to what that
   network entity can see.  When the mobile host moves to an
   uncompromised network entity in the absence of context transfer,
   security can be re-established at the new entity.  However, to the
   extent that context transfer happens primarily between routers, the
   security of context transfer will depend on the security of the
   routers.  Any compromise of security on a router that affects context
   transfer may also lead to other, equally serious disruptions in
   network traffic.

   The context transfer investigation must identify any novel security
   measures required for context transfer that exceed the capabilities
   of the existing or emerging IETF solutions.

8.0 Recommendations

   The following steps are recommended for Seamoby:

   - Investigation into candidate router-related services for context
     and an analysis of the transfer requirements for each candidate;

   - The development of a framework and protocol(s) that will support
     the transfer of context between the routing nodes of an IP network.

   The context transfer solution must inter-work with existing and
   emerging IP protocols, in particular, those protocols supporting
   mobility in an IP network.

9.0 Acknowledgements

   The editor would like to thank the Seamoby CT design team (listed at
   the end of the document as co-authors), who were largely responsible
   for the initial content of this document, for their hard work, and
   especially Gary Kenward, who shepherded the document through its
   initial versions.








Kempf                        Informational                      [Page 9]

RFC 3374           Context Transfer Problem Statement     September 2002


10.0 References

   [1]  Perkins, C., "IP Mobility Support", RFC 3220, January 2002.

   [2]  Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in
        Progress.

   [3]  Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication
        Protocol (EAP)", RFC 2284, March 1998.

   [4]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
        1661, July 1994.

   [5]  IEEE Std. P802.1X/D11, "Standard for Port based Network Access
        Control", March 2001.

   [6]  Perkins, C., and P. Calhoun, "AAA Registration Keys for Mobile
        IP", Work in Progress.

   [7]  Borman, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu,
        H., Jonsson, L., Hakenberg, R., Koren T., Le, K., Martensson,
        A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H.
        Zheng, "RObust Header Compression (ROHC): Framework and four
        profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.

   [8]  3GPP TR 25.936 V4.0.0, "Handovers for Real Time Services from PS
        Domain," 3GPP, March 2001.

   [9]  IEEE Std. 802.11f/D2.0, "Draft Recommended Practice for Multi-
        Vendor Access Point Interoperability via an Inter-Access Point
        Protocol Across Distribution Systems Supporting IEEE 802.11
        Operation," July 2001.

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

   [11] Aboba, B. and M. Moore, "A Model for Context Transfer in IEEE
        802", Work in Progress.













Kempf                        Informational                     [Page 10]

RFC 3374           Context Transfer Problem Statement     September 2002


11.0 Complete List of Authors' Addresses

   O. Henrik Levkowetz
   A Brand New World
   Osterogatan 1
   S-164 28 Kista
   SWEDEN

   Phone: [phone]
   EMail: [e-mail]


   Pat R. Calhoun
   Black Storm Networks
   110 Nortech Parkway
   San Jose  CA 95134
   USA

   Phone: [phone]
   EMail: [e-mail]


   James Kempf
   NTT DoCoMo USA Laboratories
   181 Metro Drive, Suite 300
   San Jose, CA 95110
   USA

   Phone: [phone]
   EMail: [e-mail]


   Gary Kenward
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2G 6J8
   CANADA

   Phone: [phone]
   EMail: [e-mail]











Kempf                        Informational                     [Page 11]

RFC 3374           Context Transfer Problem Statement     September 2002


   Hamid Syed
   Nortel Networks
   100 Constellation Crescent
   Nepean  Ontario K2G 6J8
   CANADA

   Phone: [phone]
   EMail: [e-mail]


   Jukka Manner
   Department of Computer Science
   University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)
   FIN-00014 Helsinki
   FINLAND

   Phone: [phone]
   EMail: [e-mail]


   Madjid Nakhjiri
   Motorola
   1501 West Shure Drive
   Arlington Heights  IL 60004
   USA

   Phone: [phone]
   EMail: [e-mail]


   Govind Krishnamurthi
   Communications Systems Laboratory, Nokia Research Center
   5 Wayside Road
   Burlington  MA 01803
   USA

   Phone: [phone]
   EMail: [e-mail]












Kempf                        Informational                     [Page 12]

RFC 3374           Context Transfer Problem Statement     September 2002


   Rajeev Koodli
   Communications Systems Lab, Nokia Research Center
   313 Fairchild Drive
   Mountain View  CA 94043
   USA

   Phone: [phone]
   EMail: [e-mail]


   Kulwinder S. Atwal
   Zucotto Wireless Inc.
   Ottawa  Ontario K1P 6E2
   CANADA

   Phone: [phone]
   EMail: [e-mail]


   Michael Thomas
   Cisco Systems
   375 E Tasman Rd
   San Jose  CA 95134
   USA

   Phone: [phone]
   EMail: [e-mail]


   Mat Horan
   COM DEV Wireless Group
   San Luis Obispo  CA 93401
   USA

   Phone: [phone]
   EMail: [e-mail]


   Phillip Neumiller
   3Com Corporation
   1800 W. Central Road
   Mount Prospect  IL 60056
   USA

   EMail: [e-mail]






Kempf                        Informational                     [Page 13]

RFC 3374           Context Transfer Problem Statement     September 2002


12.0 Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.

Acknowledgement

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



















Kempf                        Informational                     [Page 14]