Re: [Mip6] Summary of Justification for AlternativeAuthenticationOption
Gopal Dommety <gdommety@cisco.com> Sun, 26 September 2004 17:54 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 NAA20917 for <mip6-web-archive@ietf.org>; Sun, 26 Sep 2004 13:54:34 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBdLl-00055y-F6 for mip6-web-archive@ietf.org; Sun, 26 Sep 2004 14:02:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBdB5-0002Q9-KC; Sun, 26 Sep 2004 13:51:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBdAB-0002I5-GF for mip6@megatron.ietf.org; Sun, 26 Sep 2004 13:50:19 -0400
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 NAA20796 for <mip6@ietf.org>; Sun, 26 Sep 2004 13:50:18 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBdHd-00051H-QJ for mip6@ietf.org; Sun, 26 Sep 2004 13:58:02 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Sep 2004 11:02:44 +0000
X-BrightmailFiltered: true
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8QHnflr001366; Sun, 26 Sep 2004 10:49:42 -0700 (PDT)
Received: from gdommety-w2k04.cisco.com (sjc-vpn4-903.cisco.com [10.21.83.134]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AEQ89337; Sun, 26 Sep 2004 10:49:42 -0700 (PDT)
Message-Id: <4.3.2.7.2.20040926104610.02c04d18@mira-sjc5-d.cisco.com>
X-Sender: gdommety@mira-sjc5-d.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 26 Sep 2004 10:49:43 -0700
To: James Kempf <kempf@docomolabs-usa.com>
From: Gopal Dommety <gdommety@cisco.com>
Subject: Re: [Mip6] Summary of Justification for AlternativeAuthenticationOption
In-Reply-To: <004401c4a2db$6c3e0d40$576015ac@dcml.docomolabsusa.com>
References: <697DAA22C5004B4596E033803A7CEF4403B1BE7C@daebe007.americas.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
James, >I hope that makes my position clearer. I hope, in the future, that the WG >chairs will strive to be a little more accurate and objective when >performing concensus calls. The email I sent out was a summary of the discussion and not a summary of the consensus call. Next time I will be strive to be clearer. Thanks, -Gopal > jak > >----- Original Message ----- >From: <Basavaraj.Patil@nokia.com> >To: <kempf@docomolabs-usa.com>; <mip6@ietf.org>; <gdommety@cisco.com> >Sent: Friday, September 24, 2004 8:51 AM >Subject: RE: [Mip6] Summary of Justification for >AlternativeAuthenticationOption > > > >James, > >I disagree with the need for having such a mechanism in view of the fact >that an HA is expected to support both the authentication schemes >mandatorily. > >-BPa > > > > > Gopal, > > > > I believe you missed the need for some mechanism to allow an > > MN to determine > > which authentication technique to use. Without this, there is an > > interoperability problem, because the MN cannot infer simply from the > > failure of the signaling that it should try the other method. > > > > jak > > > > ----- Original Message ----- > > From: "Gopal Dommety" <gdommety@cisco.com> > > To: <mip6@ietf.org> > > Sent: Thursday, September 23, 2004 2:55 PM > > Subject: [Mip6] Summary of Justification for Alternative > > AuthenticationOption > > > > > > > Hello All, > > > > > > I am attaching a summary of the discussion > > that took place on > > > justification of an alternate authentication mechanism. > > Please let me > > know if > > > I have left out any important issue in the summary. I could > > have also > > mis-read > > > people opinions, so if there is a correction please let me > > know. I will > > > send a follow-up > > > email with the next steps. > > > > > > > > > Thanks, > > > -Gopal > > > > > > > > > Summary > > > ======= > > > > > > The WG has been engaged in a discussion over the last week on the > > > topic of standardizing an authentication date suboption based > > > mechanism for the purpose of registering an MN with its HA via the > > > BU/BAck messages. > > > To summarize the discussion in brief: > > > 1. The I-D draft-patil-mip6-whyauthdataoption-00.txt was used as the > > > baseline for the discussion > > > 2. Opinion was expressed that the I-D was more inclined in > > justifying > > > why the use of IKE was a problem for setting up the > > MN-HA IPsec SA > > > and not really providing sufficient justifications for an > > > alternative scheme to the use of IPsec for securing the > > signaling > > > messages between the MN and HA > > > 3. There were a few people who expressed strong views of > > keeping IPsec > > > as the only means for MIP6 security between MN and HA > > (Francis and > > > Hesham (?)) > > > 4. There were others who claimed the need for an alternate option to > > > MIP6 including one operator who plans to deploy the protocol in > > > their network (Raj, James Kempf, Alpesh, Gopal, Kuntal, > > Vijay, Michael > > Roe) > > > 5. There was also a note from an implementers perspective on the > > > challenges of integrating MIP6 with IPsec (Michael Roe) > > > 6. There was discussion about the problem of replay attacks and the > > > need for key refreshment > > > 7. IKEv2 is expected to provide a solution to the problem of setting > > > up dynamic SAs in networks that rely on AAA > > infrastructures. While > > > IKEv2 itself has been approved, the details of how IKEv2 is used > > > with MIP6 are still being worked out in an I-D that is not ready > > > yet. > > > 8. There was an opinion that the bootstrap work being done in the WG > > > would address the needs of the environment claimed in I-D > > > draft-patil-mip6-whyauthdataoption-00.txt > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6
- RE: [Mip6] Summary of Justification for Alternati… Basavaraj.Patil
- Re: [Mip6] Summary of Justification for Alternati… James Kempf
- Re: [Mip6] Summary of Justification for Alternati… Gopal Dommety
- Re: [Mip6] Summary of Justification for Alternati… Gopal Dommety