Subject: Re: [Seamoby] Candidate for New WG Draft

From: Charlie Perkins <[email-masked]>
Date: Fri, 27 Jun 2003 08:33:01 -0700

Hello Jukka,

I agree with you that security context transfer is a most
useful feature.  We have indeed defined a security context
profile type.  It is known that transferring security contexts
does work as advertised and quickly.  However, I was
advised that putting any sort of security work into the
seamoby process would raise a lot of concerns.  I guess
this stems from a more general problem within the IETF.

Regards,
Charlie P.

Jukka MJ Manner wrote:

>Hi,
>
>just to clarify one thing: I didn't talk about QoS contexts. I would
>believe defining those would be really-really though and time consuming. I
>was talking about IPsec and AAA contexts, to my understanding somewhat
>simpler and more straight-forward.
>
>In my email, I said that MM and QoS seem to work, but the hard problem is
>having security in place before the handover. For example, I have worked
>with RSVP and mobility for some time now and to me it seems that MM and
>QoS can be coupled and work adequately, but there is still a problem with
>securing all this signaling. So, having a how-to on transferring
>security-related contexts from pAR to nAR would be the next important
>thing.
>
>Of course, QoS contexts are very important, too, but at least to me it 
>seems that having the security contexts transferred before a handover is 
>even more important.
>
>Regards,
>Jukka
>
>On Fri, 27 Jun 2003 [email-masked] wrote:
>
>  
>
>>Charlie & Jukka,
>>
>>I see the need for this, too.  I think that there is interest in
>>finishing the existing Seamoby work, though.  One solution is
>>to have an individual draft working on QoS Context transfers,
>>with discussion on the Seamoby / NSIS mailing lists.  Not 
>>everything needs to be a WG draft, as long as there are people
>>interested in the subject.  However, this would be a good 
>>thing to discuss in Vienna & get buy-in from the WG chairs
>>and ADs.
>>
>>John
>>
>>    
>>
>>>-----Original Message-----
>>>From: ext Charlie Perkins [mailto:[email-masked]]
>>>Sent: 27 June, 2003 08:46
>>>To: Jukka MJ Manner
>>>Cc: Seamoby Working Group
>>>Subject: Re: [Seamoby] Candidate for New WG Draft
>>>
>>>
>>>
>>>Hello Jukka,
>>>
>>>I agree with you that QoS context transfer is a crucial piece.
>>>In fact, in a way the QoS support was one of my main
>>>motivating factors for working on this problem.  I'm happy
>>>to say that we have achieved a certain degree of success
>>>with our prototype.
>>>
>>>However, it may be procedurally impossible to publish a document
>>>towards that goal within seamoby.  I would definitely support
>>>putting this work item on the charter, but it seems to me that the
>>>goal of the authority structures surrounding seamoby is to shut
>>>down the working group, for whatever reason (I do not understand).
>>>
>>>Maybe the work should proceed in another working group exactly
>>>like seamoby, but with more enthusiastic IESG support.  I'm not sure
>>>how to engender that result, though.
>>>
>>>Regards,
>>>Charlie P.
>>>
>>>
>>>
>>>Jukka MJ Manner wrote:
>>>
>>>      
>>>
>>>>Hi,
>>>>
>>>>I have tried for the last years to figure out how
>>>>seamless/smooth/fast/[your favorite term here] handovers 
>>>>        
>>>>
>>>with QoS support
>>>      
>>>
>>>>can in real life be accomplished. I personally have come to 
>>>>        
>>>>
>>>the conclusion
>>>      
>>>
>>>>that although QoS and mobility management mechanisms seem to 
>>>>        
>>>>
>>>be somewhat
>>>      
>>>
>>>>in order, a CT framework would be the "final blow" in the 
>>>>        
>>>>
>>>whole system.
>>>      
>>>
>>>>More specifically, being able to do CT for IPSec and AAA is 
>>>>        
>>>>
>>>THE key, well,
>>>      
>>>
>>>>to me at least.
>>>>
>>>>Thus, I would like to see a WG guide on how you do IPSec and 
>>>>        
>>>>
>>>AAA CT, and 
>>>      
>>>
>>>>how you couple that with the applications using the security 
>>>>        
>>>>
>>>mechanisms, 
>>>      
>>>
>>>>for example, RSVP and a given mobility management mechanism.
>>>>
>>>>To go to the point, finaly, I would like the see the 
>>>>        
>>>>
>>>mentioned Seamoby
>>>      
>>>
>>>>"user guide" for CT, but it should also include the mentioned two
>>>>additional use cases. I know that Seamoby is trying to close 
>>>>        
>>>>
>>>the work, but
>>>      
>>>
>>>>I think it might still be a good idea to try to write such an
>>>>informational document.
>>>>
>>>>My 2 cents,
>>>>Jukka
>>>>
>>>>On Thu, 26 Jun 2003, James Kempf wrote:
>>>>
>>>> 
>>>>
>>>>        
>>>>
>>>>>Jukka
>>>>>
>>>>>   
>>>>>
>>>>>          
>>>>>
>>>>>>I haven't reviewed the draft yet, but it might be a good 
>>>>>>            
>>>>>>
>>>idea to have in
>>>      
>>>
>>>>>>Seamoby something like the DCCP User Guide draft. 
>>>>>>            
>>>>>>
>>>Something that tells
>>>      
>>>
>>>>>>more than RFC3374.
>>>>>>     
>>>>>>
>>>>>>            
>>>>>>
>>>>>I took a very quick look at 
>>>>>          
>>>>>
>>>draft-ietf-dccp-user-guide-00.txt and I could
>>>      
>>>
>>>>>see some benefit in a similar document for CTP, though, 
>>>>>          
>>>>>
>>>since the intent is
>>>      
>>>
>>>>>to take CTP to experimental (unlike DCCP) I don't think 
>>>>>          
>>>>>
>>>such a document is
>>>      
>>>
>>>>>needed right now. Remember, the intent of the header 
>>>>>          
>>>>>
>>>compression CT draft is
>>>      
>>>
>>>>>to provide a concrete example of real value that would come 
>>>>>          
>>>>>
>>>out of CT, since
>>>      
>>>
>>>>>some people (and in particular some IESG members and some 
>>>>>          
>>>>>
>>>members of the
>>>      
>>>
>>>>>Seamoby CT review board) are skeptical. A User's Guide 
>>>>>          
>>>>>
>>>assumes that people
>>>      
>>>
>>>>>already see the value of the protocol, and is primarily 
>>>>>          
>>>>>
>>>about how to use it.
>>>      
>>>
>>>>>What do other people think?
>>>>>
>>>>>   
>>>>>
>>>>>          
>>>>>
>>>>>>Still, the document should talk about more than one use
>>>>>>case, though.
>>>>>>
>>>>>>     
>>>>>>
>>>>>>            
>>>>>>
>>>>>I'm not quite sure I understand. Are you proposing that 
>>>>>          
>>>>>
>>>specifications for
>>>      
>>>
>>>>>multiple different kinds of contexts should be included 
>>>>>          
>>>>>
>>>into one draft? If
>>>      
>>>
>>>>>yes, this sounds a bit impractical to me. If I am, say, 
>>>>>          
>>>>>
>>>interested in
>>>      
>>>
>>>>>implementing context transfer for header compression, why 
>>>>>          
>>>>>
>>>should I have to
>>>      
>>>
>>>>>wade through a document that describes context transfer for 
>>>>>          
>>>>>
>>>AAA, and IPsec,
>>>      
>>>
>>>>>and... Small, focussed specifications tend to do better in 
>>>>>          
>>>>>
>>>IETF, and they
>>>      
>>>
>>>>>are also easier to review and achieve concensus on 
>>>>>          
>>>>>
>>>approval. Although we
>>>      
>>>
>>>>>want the header compression CT document as a concrete 
>>>>>          
>>>>>
>>>example, it will also
>>>      
>>>
>>>>>serve as the (experimental) reference specification for 
>>>>>          
>>>>>
>>>implementing a
>>>      
>>>
>>>>>header compression context and will be used for that purpose.
>>>>>
>>>>>           jak
>>>>>
>>>>>
>>>>>   
>>>>>
>>>>>          
>>>>>
>>>>_______________________________________________
>>>>Seamoby mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/seamoby
>>>> 
>>>>
>>>>        
>>>>
>>>
>>>_______________________________________________
>>>Seamoby mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/seamoby
>>>
>>>      
>>>
>
>  
>

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 27 Jun 2003 10:56:14 +0300 (EEST)

Hi,

Regards,
Jukka