Subject: Comments Re: [seamoby] ct problem statement

From: Allison Mankin <[email-masked]>
Date: Fri, 01 Jun 2001 21:20:56 -0400

Hi, Gary,

> Pat: 
>  
>  I'm afraid to ask, but I must. What's up with the ct problem statement? 
>  
> Gary 

Since Pat said he'd consult the ADs to answer this:

I note that the WG last call on the CT problem statement ended two
days ago.  Were there issues brought up to any of the authors or
in the design team mailing list?  The working group list did not surface
any, that I saw, so I'll surface some that should be addressed before
we put the draft forward for advancement:

1. The draft is very concise and easy to read - you want to spoil
   us in the IESG by continuing this good trend by Seamoby (in the
   footsteps of the paging problem statement)?  [Needless
   to say, this is _not_ an issue :> ]

2. I would like to see some discussion of the problem space of
   how to evaluate when Internet CT makes sense and when it might
   not.  For instance, the point that if a feature context has
   information that took many exchanges and/or computation to set
   up, it is a better candidate.  Frequency of change of features
   would affect when CT is a good choice.   The goal is not
   to make any evaluations, but to give a problem space for the
   protocol design work to come.  

   How can the problem be described so that designers and eventual
   deployers can distinguish between optimizations that provide benefits
   only in narrowly constrained network circumstances and designs
   that provide broad enough benefits to be used at Internet level.

3. Security considerations - the point about the sensitivity of
   information carried in the CT is good, but the point about
   CT not raising new security concerns is too much of a leap.  
   Even with the good design point of having the MN work but just
   have a slower handoff when CT fails, there are risks to net and
   nodes.  Examples thought of quickly:  

     Malicious context transferrors that give incorrect but
     information that is not malformed, and damage/alter the MN's
     connectivity

     Malicious CT requests causing DoS to the Forwarding Nodes that
     have to process them.

   These are from quick thought.  A safer comment would be that CT 
   probably will have novel security and requirements and design will
   have to address.  Check out draft-rescorla-cons-03.txt for more
   ideas for the requirements phase.

Thanks,

Allison

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 5 Jun 2001 19:00:36 +0200

Hi,

	As a follow-up on Allison's comments on the CT problem statement
I've put together some text.

      I'm not fully certain I understand what Allison want added to
the problem statement, but still, (making a guess) here's a first
attempt.

      I would add this on to the existing section 8 of the CT problem
statement: 

--- 
      Performance also figures into eventual design and deployment of 
      networks using context transfer. There are several 
      problems which are associated with this, apart from the 
      problems which influence the protocol design itself: 

              - Which feature contexts merit transfer, and which not? 
                This could be based on how fast the context changes, 
                distance between forwarding nodes, the effort (in 
                terms of time, message exchanges and calculation) 
                required to set up context anew, and possibly other 
                parameters. Some of these may be network dependent, 
                rather than static. 

              - Under which network conditions are the use of context 
                transfer meaningful? Guidelines, or ways to calculate 
                or estimate the benefit of context transfer may be 
                needed in order to make sensible deployment of 
                context transfer possible. 

              - Is it possible during operation of a network to 
                determine  the usefulness of context transfer, in 
                terms of (for each node or pair of nodes) how many 
                changes in connectivity were assisted by context 
                transfer, and how many were not? 

              - Is it possible to set up parameters which guide the 
                operation of context transfer, in such a manner 
                that it can be sensibly and meaningfully adapted to 
                different network conditions and topologies? 

--- 

      Best, 
              Henrik