Subject: RE: On the NECESSITY of MIP for LMM (was Re: [Mipshop] WG Last Ca ll comments ...)

From: "Bound, Jim" <[email-masked]>
Date: Thu, 6 Nov 2003 10:43:27 -0500

I don't agree with you that security does not work.  It RR and IPsec in
fact do work and seeing it work now.  What "security" are you talking
about and was that comment related to mipshop issues or mipv6?  

/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Pekka Nikander
> Sent: Thursday, October 30, 2003 7:32 AM
> To: Soliman Hesham
> Cc: [email-masked]; [email-masked]
> Subject: Re: On the NECESSITY of MIP for LMM (was Re: 
> [Mipshop] WG Last Ca ll comments ...)
> 
> 
> Soliman Hesham wrote:
> > There are clear benefits in _reusing_ existing SW though.
> > And many years ago we went through this discussion and
> > the WG decided that it was more beneficial to solve this 
> exercise with 
> > MIP. It sounds like you disagree, right?
> 
> I would not like to make the same mistake some people are 
> doing in the IPv6 ML in repetitiously repeating themselves, 
> but maybe this ML can bare one more take on this.  :-)
> 
> Yes, I disagree with the chartering of this WG.  In my humble 
> (or not) opinion it is foolish to base LMM on MIP.
> 
> I don't disagree with the SW reuse argument, but I think that 
> people often use it even before they have implemented 
> anything. For example, the early drafts for HIP used the DNS 
> encoding, until it became clear that having a better encoding 
> not only reduced the total amount of code but also simplified 
> the solution.  (The reason for DNS encoding was claims about 
> software reuse -- claims that could not be realized.)
> 
> As I have umpteen times written, in my opinion MIPv6 is 
> flawed. MIPv4 had good reasons for its design, that is fine.  
> But carrying over the exactly same design to IPv6 was a big 
> technical mistake.  Maybe I will write a paper about this sometime.
> 
> But leaving that aside, what I am seeing happening is a 
> multitude of (roughly) IP layer mobility mechanisms that 
> could benefit from LMM.  MIP and HIP are only two of those; 
> others include the new initiatives of including some mobility 
> functions to IKEv2, the work on multi6 group such as MAST, 
> and the new approaches on the research side like FARA, I^3, etc.
> 
> All of these would benefit from LMM.  Basing LMM 
> unnecessarily on MIP may, IMHO, may bring package that will 
> not be needed.
> 
> What comes to the SW reuse benefits of reusing MIP for both 
> macro mobility and LMM, I will believe when I see complete 
> code, together with the required security solutions.  The 
> fact that we are still lacking proper security is, IMHO, a 
> clear indication that the current solutions may be far from 
> optimal ones.
> 
> 
> I am not really saying that the current proposals should not
> be completed and published as Experimental.  Indeed, I think 
> that they definitely should.  (If for nothing else, just to 
> get them recorded and out of the way :-)  What I am worried 
> about are the requirements, as we apparently are producing those.
> 
> Unnecessarily tying requirements to something that is 
> strictly not needed is technically bad.  It may be 
> politically right, but given the very clear charter of this 
> WG I don't see any real dangers in making the requirements 
> more broadly scoped.
> 
> --Pekka Nikander
> 
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 

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

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 6 Nov 2003 10:45:53 -0500

I see no flaws in HMIPv6 or Fast Handovers and both IMO are ready for PS
not Experimental. These are fine technically.  I think we need to do
some "working code" experiments but vendors are not going to invest in
that without PS.

I support both of these going to PS as is after extensive technical
review with caveat some of this I can't tell if it will work till we get
multiple implementations but that should not hold up going to PS.
HMIPv6 and Fast Handovers are done.  IMO.

/jim

> On Behalf Of Soliman Hesham
> Sent: Thursday, October 30, 2003 8:10 AM
> To: 'Pekka Nikander'
> Subject: RE: On the NECESSITY of MIP for LMM (was Re: 
> Pekka, 
> Some of your comments seem like "rejection
> of realities" to me. For instance:
> 
> 
> 
>  > Yes, I disagree with the chartering of this WG.  In my 
> humble  > (or not) opinion it is foolish to base LMM on MIP.
> 
> => and
> 
> flawed.  > MIPv4 had good reasons for its design, that is 
> fine.  But  > carrying over the exactly same design to IPv6 
> was a big technical  > mistake.  Maybe I will write a paper 
> about this sometime.
> 
> => I'm not sure what you expect this WG to do. Did you raise 
> your objections to the charter before it was approved? 
> 
> multitude  > of (roughly) IP layer mobility mechanisms that 
> could benefit from  > LMM.  MIP and HIP are only two of 
> those; others include the new  > initiatives of including 
> some mobility functions to IKEv2,  > the work on multi6 group 
> such as MAST, and the new approaches  > on the research side 
> like FARA, I^3, etc.  > 
> unnecessarily  > on MIP may, IMHO, may bring package that 
> will not be needed.
> 
> => And it may bring a package that is needed, so where 
> does this leave us? you're not giving me much to understand 
> where you're coming from! We will _never_ produce a "future 
> proof" protocol. I think we can agree on that. 
> 
>  > What comes to the SW reuse benefits of reusing MIP for 
> both  > macro mobility and LMM, I will believe when I see 
> complete  > code, together with the required security 
> solutions.  The fact  > that we are still lacking proper 
> security is, IMHO, a clear  > indication that the current 
> solutions may be far from optimal ones.
> 
> => As an author of one of this WG's drafts I'd like to
> know what the security flaws in HMIPv6 are, i.e. additional 
> ones to MIPv6. I want to know this even if it's not in 
> the charter. So if you have comments please let us know.
> Until then, I can't agree with your assessment.
> 
> Hesham
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 6 Nov 2003 10:48:16 -0500

OK charter says Experimental.  Oh well.  To bad this will slow down this
work for real use just like MANET.  Thats too bad.  Sorry I could not
give input to the charter when it occured I was off doing other things.
THis is wrong and bad.  These specs are ready for PS.  Bummer.

/jim

> Sent: Thursday, October 30, 2003 8:26 AM
> To: Soliman Hesham
> > Did you raise  your objections to the charter before it was 
> approved?
> 
> I did rise my objections; I can dig up the messages if you 
> wish. But that wouldn't be useful.
> 
> > I'm not sure what you expect this WG to do.
> 
> I do expect this working group to fulfil its charter,
> at minimum.
> 
> What I am wishing is that some of the work done in this WG 
> would be useful also elsewhere or beyond the current charter. 
> This requirements work could be, but as it stands now, it 
> isn't.  But maybe this is wishful thinking and complete waste 
> of time.  Gab, please, your opinion?
> 
> I think this all discussion has been about why I would like
> the LMM requirements document to take a broader scope, and
> why I think that it would be possible even within the charter.
> 
> The charter is what we have.  I am not arguing with that.
> 
> >  > What comes to the SW reuse benefits of reusing MIP for both  > 
> > macro mobility and LMM, I will believe when I see complete  > code, 
> > together with the required security solutions.  The fact  > that we 
> > are still lacking proper security is, IMHO, a clear  > 
> indication that 
> > the current solutions may be far from optimal ones.
> > 
> > know what the security flaws in HMIPv6 are, i.e. additional ones to 
> > MIPv6. I want to know this even if it's not in the charter. 
> So if you 
> > have comments please let us know. Until then, I can't agree 
> with your 
> > assessment.
> 
> I have to confess that I haven't read the latest versions
> of HMIPv6 drafts.  However, those ones that I did read,
> were based on IPsec.  Requiring IPsec SAs, and hence IKE,
> for LMM, may be a bit _heavy_.  No security flaws.  Just 
> impractical performance expectations and bloat of code.
> 
> Our HIP implementatation, including security and mobility,
> is less than 15000 lines of code.  Take a typical IKE,
> racoon, with 40000 loc, and typical MIPv6, MIPL, with
> about 20000 loc.  Simplicity where, heh?  Besides, we do
> not necessarily need the complexity of HIP or IKE based 
> security for LMM.  Given operational requirements, both of 
> them are pretty bad fits.
> 
> But, Hesham, do we need to take all these detours?  I have 
> promised, time permitting, to produce a version of the LMM 
> draft that has a broader scope.  Once I have completed that 
> (if I do), we could continue, couldn't we?
> 
> --Pekka Nikander
> 
> 
> 
>