Subject: RE: Comments Re: [seamoby] ct problem statement

From: "Gary Kenward" <[email-masked]>
Date: Mon, 4 Jun 2001 10:35:17 -0400

Hello Allison:

  There were no comments, that I took note of, on the email list.
There was some general debate within the ct dt around some of the issues,
including the ones you have raised. 

  I believe you are asking for some changes to the problem statement before
it can be submitted to the IESG. I will endeavour to make the changes, after
consulting with the wg. 

  Your first point makes sense to add - it would seem one of those
situations where we (the dt) all understood the circumstances for use of ct,
and did not think it needed expounding upon. The trick will be to put it
into general terms.

  The second point troubles me somewhat: ct is essentially an information
transfer operation. I do not understand (and I can only state this as my
being confusion) why it is not enough to say that this information transfer
must be secure. Why would a ct be any different from any other data transfer
that needs to be secured? 

  I personally don't see any new vulnerabilities; based upon my superficial
understanding of security, I read the examples you have provided as specific
instances of general security problems which I understood to have been
addressed. In other words, how are these scenarios not already addressed by
the existing security solutions?

  I am not against providing security for ct - not at all. However, I do
want to ensure that security remains an option to the operator (and is not
build into the protocol), the overhead imparted the ct can be minimized, and
the performance goals attained.
 
   I am sure the wg will have input on the security issue, and the security
section will be enhanced, I am uncomfortable with that idea that ct has
novel requirements.

Thank you for the response,
Gary

> -----Original Message-----
> From: Allison Mankin [mailto:[email-masked]]
> Sent: Friday, June 01, 2001 9:21 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'; 'Pat Calhoun'; [email-masked]
> Subject: Comments Re: [seamoby] ct problem statement
> 
> 
> 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: Michael Thomas <[email-masked]>
Date: Mon, 4 Jun 2001 08:33:06 -0700 (PDT)

> the performance goals attained.

   Anything that transfers keys of any kind cannot be
   done "at the operator's option". There are also
   privacy issues which must be preserved for the MN
   as well. At a base level, any transfer of context
   must be at least as secure the mechanisms the
   MN and AR used to create the original context. 
   Anything less is a breach to the MN.

	    Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 04 Jun 2001 09:00:09 -0700

Hello Gary,

> transfer operation. I do not understand (and I can only state this as my being
> confusion) why it is not enough to say that this information transfer

Some features (e.g., QoS or security associations) that might be handled
as part of the context transfer mechanism should be transferred only upon
assurance that the requester has at least some implicit authorization to
make the request.

Regards,
Charlie P.

>   I am not against providing security for ct - not at all. However, I do want
> to ensure that security remains an option to the operator (and is not build
> into the protocol), the overhead imparted the ct can be minimized, and the
> performance goals attained.
> 
> 
> section will be enhanced, I am uncomfortable with that idea that ct has novel
> requirements.
>