Subject: RE: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 13 Jun 2001 13:30:49 -0500

Gary,

Thanks for the new revision.

I had two questions:

1- Does this mean we are ending DoS analysis?

2-Why are we concerned about Theft of service in a CT draft?

Thanks,
Madjid

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 9:40 AM
To: 'seamoby'
Cc: 'seamoby-context'; 'Allison Mankin'
Subject: [seamoby] draft-ietf-seamoby-context-transfer-problem-02.txt
Importance: High
Sensitivity: Confidential

Below is a revision of the second version of the problem statement draft.
I have tried to accommodate Allisons' wishes, as well as John's concern over
explicitly referring to DOS (I hope what I have provided is sufficient
John).

Bash away.

Gary

============================================================================

    Context and Micro-mobility Routing Working Group         O. H. Levkowetz
    Internet Draft                                                      ABNW
    draft-ietf-seamoby-context-transfer-problem-               P. R. Calhoun
    02.txt                                             Sun MicroSystems, Inc
    Expires: December 2001                                        G. Kenward
                                                                  H. M. Syed
                                                             Nortel Networks
                                                                   J. Manner
                                                      University of Helsinki
                                                                 M. Nakhjiri
                                                                    Motorola
                                                            G. Krishnamurthi
                                                                   R. Koodli
                                                                       Nokia
                                                                 K. S. Atwal
                                                            Zucotto Wireless
                                                                   M. Thomas
                                                                       Cisco
                                                                    M. Horan
                                                                     COM DEV
                                                                P. Neumiller
                                                                        3Com
                                                                   June 2001

          Problem Description: Reasons For Performing Context Transfers 
                    Between Nodes in an IP Access Network 
         
     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 (2001). All Rights Reserved. 
         
     Levkowetz et al.                                              [Page 1] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 
       
     Abstract 
         
        There are a large number of IP access networks that support mobility

        of hosts. For example, wireless Personal Area Networks (PANs), 
        wireless LANs, satellite WANs and cellular WANs. The nature of this 
        mobility is such that the communication path to the host changes 
        frequently and rapidly.  
         
        This Internet-Draft describes the problem encountered during 
        mobility that requires the exchange of IP context between different 
        forwarding nodes in an access network. 

     Table of Contents 
      
        1 Introduction...................................................2 
        2 Reference Definitions..........................................3 
        3 The Need for Context Transfer..................................4 
         3.1 Scope of the Context Transfer Solution .....................5 
         3.2 Reference Architectures ....................................6 
        4 A Description of Context.......................................6 
         4.1 Feature ....................................................6 
         4.2 Feature Context ............................................7 
         4.3 Microflow Context ..........................................7 
         4.4 Common Context .............................................7 
         4.5 Examples of Feature Context ................................8 
        5 Context Transfer and Mobility..................................8 
        6 Forwarding Node Capabilities...................................8 
        7 Inter-technology Context Transfers.............................8 
        8 Applicability..................................................9 
        9 Performance Considerations.....................................9 
        10 Security Considerations.......................................9 
        11 Recommendations..............................................10 

     1 Introduction 
         
        There are a large number of IP access networks that support hosts 
        that are mobile. For example, wireless Personal Area Networks 
        (PANs), wireless LANs, satellite WANs and cellular WANs. The nature 
        of this mobility is such that the communication path to a host may 
        change frequently and rapidly.  
         
        In networks where the hosts are mobile, the forwarding path through 
        the access network must often be redirected in order to deliver the 
        host's IP traffic to the new point of access. The success of a time 
        sensitive service such as VoIP telephony, video, etc., in a mobile 
        environment depends heavily upon the minimization of the impact of 
        this traffic redirection. In the process of establishing the new 
        forwarding path, the nodes along the new path must be prepared to 
        provide similar forwarding treatment to the IP packets.  
       
     Levkowetz et al.                                              [Page 2] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 

        The information required in support of a specific forwarding 
        treatment provided to IP traffic is part of the context for that 
        traffic. This context is comprised of configuration and state 
        information. To minimize the impact of a path change on an IP flow, 
        the context used at the forwarding nodes along the original path, 
        must be replicated at the forwarding nodes along the new path. 
         
        The transfer of context information may be advantageous in 
        minimizing the impact of host mobility on, for example, AAA, header 
        compression, QoS, Policy, and possibly sub-IP protocols and services

        such as PPP. Context transfer at a minimum will be used to replicate

        the configuration information needed to establish the respective 
        protocols and services. In addition, it may also provide the 
        capability to replicate state information, allowing stateful 
        protocols and services at the new node to be activated along the new

        path with less delay and less signalling overhead. 

     2 Reference Definitions 
         
        Mobile Node 
         
        An IP node capable of changing its point of attachment to the 
        network. The mobile node is usually an end user host, but may be a 
        forwarding node for a network that is itself mobile.  
         
        Forwarding Node 
         
        A node that supports IP forwarding within the access network. This 
        includes all routers, gateways, servers and other nodes within the 
        network that have IP protocol stacks and forward IP traffic to and 
        from a mobile node. 
         
        A forwarding node will be connected to one or more other forwarding 
        nodes. Some forwarding nodes will be connected to zero or more 
        mobile nodes. The forwarding nodes that connect to mobile nodes will

        do so through a layer two entity that supports wireless 
        communications.  
         
        Microflow 
         
        One useful definition for the fundamental unit of IP service is the 
        microflow. RFC 2475 [1] defines a microflow as: 
         
        A single instance of an application-to application flow of packets 
        destined to or originated from a mobile device (MN or MH), which is 
        identified by source address, source port, destination address, 
        destination port and protocol id. 

     Levkowetz et al.                                              [Page 3] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 
       
        RFC 2207 [2] provides a definition of a microflow that applies to 
        IPSec packets. It is based on the IPSec SPI found in the AH or ESP 
        headers. Other methods for identifying for IP microflows may be 
        defined in the future, e.g. the Ipv6 flow label. 

     3 The Need for Context Transfer 
         
        In networks where the hosts are mobile, the forwarding path through 
        the access network must often be redirected in order to deliver the 
        host's IP traffic to the new point of access. The success of a time 
        sensitive service such as VoIP telephony, video, etc., in a mobile 
        environment depends heavily upon the minimization of the impact of 
        this traffic redirection. In the process of establishing the new 
        forwarding path, the nodes along the new path must be prepared to 
        provide similar forwarding treatment to the IP packets.  
         
        Figure 1 and 2 below illustrate an example of a handover scenario. A

        mobile node, MN7, is shown attached to the Internet via an access 
        network. The forwarding nodes, FN1 through to FN7 comprise a portion

        of this access network. FN1 and FN7 are the last forwarding nodes 
        before the untethered link to MN7. This last link allows the nodes 
        to move while maintaining connectivity to the edge of the access 
        network - e.g. the last link is wireless. For simplicity, many 
        details of a real access network topology have been left out of the 
        diagrams. 
         
        Prior to handoff, the path for MN7's traffic traverses FN1 and FN2. 
        It is presumable that FN1 and FN2 have been configured to provide 
        specific forwarding services for MN7's traffic, and that some of 
        these services may require state information to be maintained. 

                                       MN7's traffic                      
                                   <------------------>                   
                              -------                 -------             
              [ MN7 ]<= = = =>| FN1 |=================| FN2 |========     
                              -------                /-------             
                                                    /                     
                                            -------/                      
                                            | FN4 |                       
                                           /-------\                      
                                          /         \                     
                                         /           \                    
                                 -------/             \-------            
                            - - -| FN7 |               | FN6 |----        
                                 -------               -------            
                                                                          
                         Figure 1: Path Prior to Handover                 

     Levkowetz et al.                                              [Page 4] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 
       
        When MN7's movement results in the link to FN1 to be replaced by a 
        link to FN7, MN7's traffic must be re-directed along a new 
        forwarding path, illustrated in Figure 2 as the path through FN7, 
        FN4 and FN2. In many mobile networks, this handover can occur 
        frequently, and sometimes with little or no warning. 
                               -------                -------             
                          - - -| FN1 |----------------| FN2 |========     
                               -------              //-------             
                                                   //   MN7's traffic     
                                            -------/    <----------->     
                                            | FN4 |                       
                                           //------\                      
                           MN7's traffic  //        \                     
                           <-----------> //          \                    
                                  -------/            \-------            
                  [ MN7 ]<= = = =>| FN7 |              | FN6 |----        
                                  -------              -------            
                                                                          
                 Figure 2: Path Re-Directed After Handover                

        If the forwarding treatment provided to MN7's traffic is to be 
        sustained, the support conditions at FN1 and FN2 must be reproduced 
        at FN7 and FN4. At the very least, this requires that FN7 and FN4 be

        configured to provide the appropriate support to the traffic flow. 
        However, establishing forwarding support along the new path through 
        the use of IP signalling protocols would be relatively time 
        consuming. In addition, given that some forwarding services may 
        maintain state information, simply configuring FN7 and FN4 would not

        circumvent disruption of the services. 
         
        Given that FN7 and FN4 support the same functionality as FN1, it 
        should be possible to reproduce the needed support along the new 
        forwarding path by capturing the salient information at FN1 as it 
        exists just prior to the handover, and then use that information to 
        replicate the state of FN1 at FN7 and FN4. 

     3.1 Scope of the Context Transfer Solution 
         
        The information required to produce the necessary forwarding 
        treatments at a node is referred to as the support "context". In 
        order to replicate the context of one forwarding node at another 
        forwarding node, an open, standard solution for context transfer 
        must be developed.  

     Levkowetz et al.                                              [Page 5] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 
       
        In addition, for a forwarding node to be able to interpret the 
        transferred context, both the syntax and the semantics of the 
        context information must be defined. Definition of the actual 
        context information will be specific to the support feature being 
        replicated, however, a generic container format of the payload of 
        context transfer messages is required for inter-operability. 

     3.2 Reference Architectures 
         
        The concept of the "forwarding node" is used here to describe the 
        general context transfer problem. In different networks, the actual 
        context transfer may take place between different entities within 
        the network. In some cases the preferred context transfer peers 
        might be the routers at the edge of the access network. In other 
        situations, it may be more appropriate to transfer context between 
        wireless access points that also support forwarding of IP packets. 
         
        The context transfer solution will be applicable to any nodes that 
        support forwarding of a mobile nodes IP traffic. 

     4 A Description of Context 
         
        The term `
                 `context'
                          ' pertains to all information required by a 
        forwarding node specific to supporting the IP traffic for a 
        particular mobile node.  
         
        The context for a mobile node can be partitioned into three 
        categories: 
         
                - information required to provide generally support to the  
                  mobile node; 
         
                - information required to provide common support to the 
                  mobile node's traffic; 
         
                - information required to support specific features of the 
                  forwarding treatment for an IP microflow. 

     4.1 Feature 
         
        A feature is an aspect of the IP forwarding treatment that is 
        instantiated for each mobile node, and which may support one or more

        of the mobile nodes microflows. A feature must include associated 
        configuration information: at the very least, some identification 
        information for the mobile node, such as the mobile node's IP 
        address. A feature may have associated state information. 

     Levkowetz et al.                                              [Page 6] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 
       
        In other words, for the purpose of supporting mobility the features 
        of interest all have context pertinent to the forwarding of a 
        specific mobile nodes IP packets. Examples of features include: 
        header compression, security, subscriber policy, and quality of 
        service. 
         
        Each feature is, in general, supported by an amalgamation of one or 
        more protocols and associated local support mechanisms. As an 
        example, header compression is a feature that consists of various 
        "mechanisms" such as IP/TCP header compression and IPv6/UDP/RTP 
        header compression, operating according to well-defined "protocols".

        Thus, an instance of a feature reflects the state associated with 
        protocols and the corresponding mechanisms. 

     4.2 Feature Context 
         
        Feature context is the condition or state of an instance of a 
        particular feature. It represents the current evolution of the 
        behaviour of that feature instance. At a given instant in time, 
        feature context is represented by the values of the associated data 
        elements. 
         
        Some of the data elements associated with a feature are time 
        invariant and, thus, represent the configuration of the feature 
        instance. Other data elements, which are often referred to as the 
        "state variables" for the feature instance, change value over time 
        as a consequence of the various operations performed in support of 
        the feature instance. 
         
        A feature context is believed to be the smallest indivisible unit of

        context that can be transferred between forwarding nodes. 

     4.3 Microflow Context 
         
        A microflow context is the collection of the various feature 
        contexts associated with a single IP microflow. It is the smallest 
        unit of context that must be transferred in order to re-establish 
        support for the microflow at a forwarding node. 

     4.4 Common Context 
         
        Some of the associated feature contexts may be applicable to more 
        then one of the IP microflows comprising the mobile node's traffic. 
        An example of this might be the authentication state for the mobile.

        This type of feature context is also required to support each 
        microflow, but because of the multiplicity of the relationship to 
        the mobile node's microflows, it would seem prudent to transfer one 
        instance of the context, independent of the microflow context. 
       
     Levkowetz et al.                                              [Page 7] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 

     4.5 Examples of Feature Context 
         
        Some examples of feature contexts that are candidates for context 
        transfer are given below. This list is provided solely to illustrate

        the nature of the context transfer problem domain. 
         
                - encryption context; 
                - authentication context; 
                - authorization context; 
                - accounting context; 
                - header compression context; 
                - quality of service context; 
                - policy enforcement context; 
                - multicast group membership; 
                - buffer state; 
                - sub-network layer context (e.g. PPP context). 

     5 Context Transfer and Mobility 
         
        Context transfer is an enhancement to a mobility solution that is 
        clearly most effective when used on a local scale between forwarding

        nodes within a subnetwork. However, with due consideration to the 
        nature of the context and the requirements for transfer of that 
        context, context transfer should be applicable between any two 
        similar forwarding nodes. 

     6 Forwarding Node Capabilities 
         
        Context transfer between two forwarding nodes is worthwhile only if 
        the receiving node's capabilities are similar enough to those of the

        sending node that the received context can be utilized. This does 
        not mean that the two nodes are identical in their implementation, 
        nor does it even imply that they must have identical capabilities. 
         
        A forwarding node that cannot make use of received context could, 
        and should, refuse the transfer. This would result in a situation no

        different then mobile handover without context transfer. 

     7 Inter-technology Context Transfers 
         
        The context transfer described here operates at the IP layer, and 
        should be applicable to situations where the forwarding nodes are 
        supporting different wireless link technologies.  

     Levkowetz et al.                                              [Page 8] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 
       
        An exception to this would be where sub-IP layer context is an 
        intrinsic part of the forwarding treatment. In this situation, an 
        interworking solution must be developed for sub-IP context transfer 
        between the two technologies. This issue is outside the scope of the

        Seamoby working group. 

     8 Applicability 
         
        The primary motivation for developing an IP context transfer assumes

        that service sustainment during handover is desirable. And yet, 
        there may be situations where either the user or the access network 
        would prefer to re-establish or re-negotiate a service or a service 
        feature. For example, if the mobile node crosses administration 
        domains where the operational policies change, negotiation of a 
        different level of service may be required by the respective 
        operators. 
         
        More important, the concept of context transfer also assumes that 
        the service is worth sustaining through a variety of handover 
        scenarios, and that context transfer is the best approach. The 
        former may not be true for certain types of service - for example,  
        multicast, "push" information services. In addition, even if service

        level sustainment is desirable, context transfer may not be the most

        cost efficient solution. 
         
        Alternatives to context transfer for sustaining services during 
        handover are out of scope for the Seamoby working group. The 
        possibility of other solutions is only noted here to emphasize that 
        context transfer is but one of possibly many approaches. 
         
        Finally, context transfer is an enhancement at the IP level to 
        improve upon the performance of a handover between IP forwarding 
        nodes. Many networks provide support for handover at the link layer,

        within and between subnetworks, and context transfer may not provide

        a significant improvement over the these link layer solutions. 

     9 Performance Considerations 
         
        The purpose of context transfer is to sustain the services being 
        provided to a mobile node's traffic during handover. It is 
        essentially an enhancement to a mobility solution that ultimately 
        must result in an improvement in handover performance. The various 
        aspects of performance must be a prime consideration in the 
        development of the context transfer solution. 

     10 Security Considerations 
         
        Some of the considerations for context transfer security include: 
       
     Levkowetz et al.                                              [Page 9] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 

                - information privacy: the context may contain information  
                  which the end user 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 forwarding node, and therefore 
                  could potentially affect the operation of the access 
                  network itself; the potential threats include denial of 
                  service and theft of service attacks; context transfer 
                  must only occur between forwarding nodes that have an  
                  established trust relationship. 
                 
                - security preservation: part of the context transfer may 
                  include information pertinent to a security association  
                  established between the mobile node 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 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.  
         
        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. 

     11 Recommendations 
         
        The Seamoby context transfer design team recommends the following: 
         
                - investigation into candidates for context transfer - in 
                  particular, feature context transfer, and an analysis 
                  of the transfer requirements for each candidate;  
         
                - the development of a framework and protocol(s) that will 
                  support the transfer of configuration and state context 
                  between the forwarding nodes of an IP network. 
         
        The context transfer solution must interwork with existing and 
        emerging IP protocols, in particular, those protocols supporting 
        mobility in an IP network. 

     References 

     Levkowetz et al.                                             [Page 10] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 
       
        [1] Blake, et al., "An Architecture for Differentiated Services", 
            RFC 2475, December 1998. 
         
        [2] Berger & O'Malley, "RSVP Extensions for IPSEC Data Flows", 
            RFC 2207, September 1997. 
         
     Authors' Addresses 
        O. Henrik Levkowetz 
        A Brand New World 
        Osterogatan 1 
        S-164 28 Kista   
        SWEDEN 
         
        Phone: +46 8 477 9942 
        EMail: [email-masked] 

        Pat R. Calhoun 
        Network and Security Research Center, Sun Labs 
        15 Network Circle 
        Menlo Park  CA 94025 
        USA 
         
        Phone: +1 650-786-7733 
        EMail: [email-masked] 

        Gary Kenward 
        Nortel Networks 
        3500 Carling Avenue 
        Nepean, Ontario  K2G 6J8 
        CANADA 
         
        Phone: +1 613-765-1437 
        EMail: [email-masked] 

        Hamid Syed 
        Nortel Networks 
        100 Constellation Crescent 
        Nepean  Ontario K2G 6J8 
        CANADA 
         
        Phone: +1 613 763-6553 
        EMail: [email-masked] 
         
        Jukka Manner 
        Department of Computer Science, University of Helsinki 
        P.O. Box 26 (Teollisuuskatu 23) 
        FIN-00014 Helsinki 
        FINLAND 
       
     Levkowetz et al.                                             [Page 11] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 

        Phone: +358-9-191-44210 
        EMail: [email-masked] 

        Madjid Nakhjiri 
        Motorola 
        1501 West Shure Drive 
        Arlington Heights  IL 60004 
        USA 
         
        Phone: +1 847-632-5030 
        EMail: [email-masked] 

        Govind Krishnamurthi 
        Communications Systems Laboratory, Nokia Research Center 
        5 Wayside Road 
        Burlington  MA 01803 
        USA 
         
        Phone: +1 781 993 3627 
        EMail: [email-masked] 

        Rajeev Koodli 
        Communications Systems Lab, Nokia Research Center 
        313 Fairchild Drive 
        Mountain View  CA 94043 
        USA 
         
        Phone: +1 650 625 2359 
        EMail: [email-masked] 

        Kulwinder S. Atwal 
        Zucotto Wireless Inc. 
        Ottawa  Ontario K1P 6E2 
        CANADA 
         
        Phone: +1 613 789 0090 
        EMail: [email-masked] 

        Michael Thomas 
        Cisco Systems 
        375 E Tasman Rd 
        San Jose  CA 95134 
        USA 
         
        Phone: +1 408 525 5386 
       
     Levkowetz et al.                                             [Page 12] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 
       
        EMail: [email-masked] 

        Mat Horan 
        COM DEV Wireless Group 
        San Luis Obispo  CA 93401 
        USA 
         
        Phone: +1 805 544 1089 
        EMail: [email-masked] 

        Phillip Neumiller 
        3Com Corporation 
        1800 W. Central Road 
        Mount Prospect  IL 60056 
        USA 
         
        EMail: [email-masked] 

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

     Levkowetz et al.                                             [Page 13] 

     Internet Draft                                                June 2001

               draft-ietf-seamoby-context-transfer-problem-02.txt 
       
        Funding for the RFC editor function is currently provided by the 
        Internet Society. 
       
     Levkowetz et al.                                             [Page 14]