Subject: [Mobopts] Re: [Mip6] Review Comments and Questions on draft-irtf-mobopts-ro-enhancemen ts-00.txt

From: Wassim Haddad <[email-masked]>
Date: Fri, 27 May 2005 09:56:48 -0400

Hello Vidya,

On 26-May-05, at 11:25 PM, Narayanan Vidya-CVN065 wrote:

> 3. One of the situations in which RO can be useful is when the RO  
> solution allows the MN and CN to continue communication during a  
> period of HA unavailability (failure, for e.g.). The current RR  
> solution does not achieve this, due to the necessity for short  
> lifetimes and hence the need for home address tests via the HA  
> every so often. It may be worthwhile adding this to the design  
> goals for the solution.

=> In OMIPv6, you need to do only *one* HoA test at the beginning.  
The shared secret, i.e., SKbm, lifetime is set to 24 hours so that  
you don't need to
exchange HoTI/HoT messages during this period.

Regards,

Wassim H.

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

---

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Thu, 26 May 2005 22:25:47 -0500

Here are some comments and questions I have from reviewing the draft. 
 
Thanks,
Vidya
 
1. The draft provides a good, comprehensive overview of the security aspects of RO and the solution space in general. However, given that there is already a draft on RO security, perhaps the security aspects should be integrated with that draft and this draft should attempt to cover the solution space alone? 
 
2. Need for "fast" RO - The draft mentions in a few places (including section 4) that one of the objectives for RO is latency optimization. I belong to the group that is yet to be convinced that there is a real need for "fast" RO. In my mind, there is a need for fast handoffs, but not necessarily fast RO. I don't think that RO is going to satisfy the latency requirements of real-time applications. Link layer mechanisms are defining methods to reduce the handoff latency to less than 100ms or so. Such enhancements are useful during inter-subnet handoffs only if the network layer latency can be reduced to adding very marginal latency on top of that. Do we really think RO is going to buy us that? Given that any design for RO cannot control the relative positions of the CN and the MN, it doesn't seem like any RO solution can claim that. The need for such applications really drives us towards FMIP-like approaches. 
 
I still think RO can be useful - when long periods of traffic exchange happens between an MN and CN, it may be better to get away from triangular routing. I noticed that James brought up the point of almost ubiquitous wireline bandwidth perhaps eliminating the need for RO. While that is a very valid argument against the real need for RO, I think it will still be good to design the support for RO, before widespread deployment of CNs that don't support it. 
 
I am only questioning the need for latency reduction as a design objective for an RO solution. 
 
3. One of the situations in which RO can be useful is when the RO solution allows the MN and CN to continue communication during a period of HA unavailability (failure, for e.g.). The current RR solution does not achieve this, due to the necessity for short lifetimes and hence the need for home address tests via the HA every so often. It may be worthwhile adding this to the design goals for the solution. 
 
4. Section 3.3 (last paragraph) mentions the fact that the current RR solution trades off protection against attacks on CN's processing capacity for protection against CN's memory. Perhaps an RO solution can be flexible enough to allow the CN to determine what trade off makes sense in a particular case? 
 
5. Section 6.2.1 talks about HMIP and FMIP-like proposals. I am not sure I understand how such proposals can replace RO. For e.g., the use of FMIP will remove stringent latency requirements on RO, but not provide a solution for RO itself, right?