Re: [Mipshop] MIPSHOP discussion on new items and milestones

"James Kempf" <kempf@docomolabs-usa.com> Wed, 23 March 2005 21:42 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14873 for <mipshop-web-archive@ietf.org>; Wed, 23 Mar 2005 16:42:50 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEDiO-00065b-K0 for mipshop-web-archive@ietf.org; Wed, 23 Mar 2005 16:48:36 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEDNN-0007O4-84; Wed, 23 Mar 2005 16:26:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEDNL-0007Nu-5h for mipshop@megatron.ietf.org; Wed, 23 Mar 2005 16:26:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09303 for <mipshop@ietf.org>; Wed, 23 Mar 2005 16:26:48 -0500 (EST)
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEDSq-0004Fb-La for mipshop@ietf.org; Wed, 23 Mar 2005 16:32:35 -0500
Message-ID: <04cb01c52fef$2b276b20$0f6115ac@dcml.docomolabsusa.com>
From: James Kempf <kempf@docomolabs-usa.com>
To: gabriel montenegro <gab@sun.com>, mipshop@ietf.org
References: <4238786E.9040202@sun.com> <4241C03F.5050002@sun.com>
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones
Date: Wed, 23 Mar 2005 13:27:44 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Content-Transfer-Encoding: 7bit
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mipshop.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Sender: mipshop-bounces@ietf.org
Errors-To: mipshop-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Content-Transfer-Encoding: 7bit

Gab,

Here's a couple of suggestions to reduce the number of items:

1) I'd like to see some data first on proposed RO enhancements before
starting any PS work on anything other than simple enhancements to the
current RR protocol. I believe 3GPP2 has stated that they are happy with RR
as stands, so I see no tearing hurry to standardize alternatives at this
time. Since getting such data and comparing has been elusive in IETF, I
think this is still an IRTF item. I think the authors of the two contenders
could be encouraged to look at a combined design, and provide some data on
it once they have agreement.

2)  Of the security alternatives mentioned in the discussion for HMIP,
aggregate security is unacceptable because it does not provide the access
network with protection against a mobile node that obtains the certificate
of a roaming partner and presents itself as a client of  the roaming partner
when it is not. IKEv2 with EAP authentication using the network access
credentials would work, but only for a particular limited set of deployment
circumstances. CGA would work but only if address configuration uses CGA
(and there's the usual IPR considerations). So I think there's still need
for more work on this in MOBOPTS, until we get a draft or drafts like we've
got for FMIP.

My 0.02 yuan.

            jak







----- Original Message ----- 
From: "gabriel montenegro" <gab@sun.com>
To: <mipshop@ietf.org>
Sent: Wednesday, March 23, 2005 11:15 AM
Subject: Re: [Mipshop] MIPSHOP discussion on new items and milestones


> Folks,
>
> Thanks for the excellent exchange so far. At this point, based on what
I've
> seen, I'd like to share with you how I'm seeing things.
>
>
> MN-AR security
> seems like there is sufficient interest and this item is
> narrow enough to warrant further work on the SeND key
> reuse method as well as to develop a AAA-based solution.
> Whereas we believe there may be some IPR-issues to clarify
> with the SeND based approach (in spite of Jim's interpretation)
> we don't have the same clarity with respect to the AAA approach.
> Please come forward with your IPR disclosures on this. This is not
> optional.
>
> looking at 2 PS documents.
>
> FMIPv6 itself
> I'd postpone this item given that we don't have a clear understandiung
> of what the exact relationship with DNA, CARD, 802.21 and the forthcoming
> neighborhood discovery is (and heck, there's even a proposal for dhcp).
> I'm inclined not to include it for now
> until we know more, and look into it again until a few months have
> gone by and we have a better grasp of the security and the discovery
> portions. The former to continue here, the latter to continue elsewhere
> (e.g., mobopts).
>
> FMIP-over-cdma
> This experimental document is a useful exercise to better understand
> deployment considerations and the above issues. It's also good in that
> it encourages another SDO to seriously think about this, even if it is
> in a preliminary manner (I don't believe they have firms and urgent
> deployment plans). I have heard of at least two groups of folks in
> the working group interested in this. You know who you are, and you
> should work together on one document. Highly desirable: go through the
> regular channels (ietf liaisons) and produce a document from 3GPP2
> on this subject.
>
> looking at one informational document
>
> MN-MAP security for HMIPv6
> I'd like to think that such an item could be included, but we do need to
see
> a draft on this subject in very short order. Conceptually, it does not
seem
> a much more difficult problem than MN-AR security, so depending on how
quickly
> the relevant draft can be produced, this could be entertained. It seems to
me
> that without this piece in place, talking about other HMIP work in MIPSHOP
> is premature (but it should continue elsewhere). Like FMIP, other work
could
> be taken on later on.
>
> perhaps (if a first solid draft appears shortly) one PS document
>
> RO issues
> Not clear how much of EBU is new and how much is just further language on
> rfc 3775. At any rate, it does seem like a CGA-based scheme could be
> worked on (heck, the basic concept has been around for ages), using
> omip as a starting point. Highly desirable: go through the ietf channels
> and using the proper liaisons obtain a message from the SDOs reputedly
> interested in this item. This document would have the precondition for
> CBA (authenticated notification of CoA change to the CN). Ideally, we'd
> have a very simple CBA scheme in place as well.  Both of these mechanism
> would be optional (i.e., we're not in the business of replacing RR).
>
> looking at one PS document.
>
>
> This gives us a lot already, perhaps too much:
> (up to) 4 PS documents (perhaps 3)
> 1 informational document
>
> I don't think we want to take on any more load for now. As we complete
> items, we will look into it (as we are doing now).
>
> This may not be everybody's favorite list, but hopefully it works
reasonably well
> (or at least *maximizes the distribution of unhappiness*, as Brian put it
at the plenary).
>
> comments? close enough, way off?
>
> -gabriel
>
>
>
>
>
>
> _______________________________________________
> Mipshop mailing list
> Mipshop@ietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop
>



_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop