RE: [netlmm] Issue: Auth Option support
"Ahmad Muhanna" <amuhanna@nortel.com> Mon, 10 September 2007 14:27 UTC
Return-path: <netlmm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkF2-0000jS-It; Mon, 10 Sep 2007 10:27:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkF1-0000jM-Ov for netlmm@ietf.org; Mon, 10 Sep 2007 10:27:55 -0400
Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUkF0-0007Bg-GL for netlmm@ietf.org; Mon, 10 Sep 2007 10:27:55 -0400
Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8AEPT102875; Mon, 10 Sep 2007 14:25:29 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [netlmm] Issue: Auth Option support
Date: Mon, 10 Sep 2007 09:27:40 -0500
Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371169E8EDD@zrc2hxm2.corp.nortel.com>
In-Reply-To: <46E4B02C.5010101@azairenet.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netlmm] Issue: Auth Option support
Thread-Index: AcfzVRKastzqW86cS12AQItlFqDoJwAVYavw
References: <Pine.GSO.4.63.0708070000100.13701@irp-view13.cisco.com> <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net> <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> <46E4B02C.5010101@azairenet.com>
From: Ahmad Muhanna <amuhanna@nortel.com>
To: Vijay Devarapalli <vijay.devarapalli@azairenet.com>, Sri Gundavelli <sgundave@cisco.com>, Alper Yegin <alper.yegin@yegin.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017
Cc: netlmm@ietf.org
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
Errors-To: netlmm-bounces@ietf.org
> Subject: Re: [netlmm] Issue: Auth Option support > > Sri, > > I agree with "SHOULD" for using IPsec and "MUST" for > supporting IPsec on the MAG and the LMA. > > If thats the consensus, we need to modify a few sentences in > the draft. > > In section 4, replace > > > The signaling messages, Proxy Binding Update and Proxy Binding > > Acknowledgement, exchanged between the mobile access > gateway and the > > local mobility anchor MUST be protected using IPsec > [RFC-4301] and > > using the established security association between them. The > > security association of the specific mobile node for which the > > signaling message is initiated is not required for > protecting these > > messages. > > with > > The signaling messages, Proxy Binding Update and Proxy Binding > Acknowledgement, exchanged between the mobile access > gateway and the > local mobility anchor MUST be protected using security > associations > established between them. The security association of the specific > mobile node for which the signaling message is initiated is not > required for protecting these messages. > > We need the MUST above since we have to say that the proxy BU > and proxy BAck must be protected, irrespective of whether > IPsec or some other mechanism is used. [Ahmad] Hi Vijay, As far as I remember, the whole security concept of using a per-Node SA for PMIPv6 was based on the use of IPsec. Although, I see why you proposed the text but I still see a problem here. For example, the above text allows the use of an authentication option similar to FA-HA AE to secure the P-BU/P-BA. Now, since allowing a per-Node SA to be used in PMIPv6 was based on the use of IPsec, I believe we clearly need to keep that as part of the spec text. What about the following slight modification to what you just proposed: The signaling messages, Proxy Binding Update and Proxy Binding Acknowledgement, exchanged between the mobile access gateway and the local mobility anchor MUST be protected using a security association established between them. If IPsec is used, the security association of the specific mobile node for which the signaling message is initiated is not required for protecting these messages. Thanks, Ahmad > > Add one sentence that says > > The mobile access gateway and the local mobility anchor MUST > implement IPsec for protecting the Proxy Mobile IPv6 signaling > messages [RFC-4301]. > > The paragraph that comes after already uses "SHOULD" for using ESP. > > > IPsec ESP [RFC-4303] in transport mode with mandatory integrity > > protection SHOULD be used for protecting the signaling messages. > > Confidentiality protection of these messages is not required. > > Hope that is sufficient. > > Vijay > > > Sri Gundavelli wrote: > > I want some comments on this issue raised by Alper. > > > > > > Also, if I interpret Sec 5.1 [3775], the IPSec is being > mandated, only > > the use of IPsec ESP is optional. > > > > -------- > > 5.1. Binding Updates to Home Agents > > > > The mobile node and the home agent MUST use an IPsec security > > association to protect the integrity and authenticity of > the Binding > > Updates and Acknowledgements. Both the mobile nodes and the home > > agents MUST support and SHOULD use the Encapsulating > Security Payload > > (ESP) [6] header in transport mode and MUST use a > non-NULL payload > > authentication algorithm to provide data origin authentication, > > connectionless integrity and optional anti-replay > protection. Note > > that Authentication Header (AH) [5] is also possible but > for brevity > > not discussed in this specification. > > ------- > > > > > > I'm confused, should the draft say > > > > "Both LMA and MAG MUST implement IPsec" and "all the signaling > > messages SHOULD be protected using IPSec". > > > > Will this ok, when reviewed by the security folks ? > > > > or mandate IPsec for this specification and let other draft > relax this > > in the presence of an alternative approach ? > > > > Please comment. > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >> Sent: Tuesday, August 07, 2007 1:41 AM > >> To: 'Sri Gundavelli'; netlmm@ietf.org > >> Subject: RE: [netlmm] Issue: Auth Option support > >> > >>> The issue was related to the use of MUST clause in specifying the > >>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was > >>> suggesting that we relax that requirement and potentially leave a > >>> room for Auth Option support in future. > >> Actually, I didn't mean it specifically for Auth Option. It can be > >> anything. > >> Given that the security is handled by a separate protocol, > why lock > >> it down to "IPsec", when some other protocol (Auth Option being one > >> example) cannot > >> be used. > >> > >>> But, as most people agreed and as supported by Jari, this can > >> My understanding was the opposite, especially about Jari's > statement. > >> > >>> always be changed in future when the support for new security > >>> mechanisms such as Auth Option are defined for Proxy > Mobile IPv6 and > >>> that specific document can always modify this requirement. > >>> So, no changes will be made to the document on this issue. > >> What if Auth Option is good enough as written? > >> What if a document in another SDO defines the alternative security > >> mechanism? > >> > >> For the type of interop we are seeking in IETF, "MUST > implement" is > >> good enough. "MUST use" is not necessary. > >> > >> Alper > >> > >> > >> > >> > >> > >>> > >>> Regards > >>> Sri > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm
- [netlmm] (no subject) LAI, SHOU WEN -HCHBJ
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- RE: [netlmm] Issue: Auth Option support Sri Gundavelli
- [netlmm] (no subject) Christian Vogt
- [netlmm] Re: your mail Sri Gundavelli
- [netlmm] Issue: Auth Option support Sri Gundavelli
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- Re: [netlmm] Issue: Auth Option support Christian Vogt
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- RE: [netlmm] Issue: Auth Option support Chowdhury, Kuntal
- RE: [netlmm] Issue: Auth Option support Sri Gundavelli
- Re: [netlmm] Issue: Auth Option support Alexandru Petrescu
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- Re: [netlmm] Issue: Auth Option support Alexandru Petrescu
- Re: [netlmm] Issue: Auth Option support Julien Laganier
- Re: [netlmm] Issue: Auth Option support Alexandru Petrescu
- Re: [netlmm] Issue: Auth Option support Julien Laganier
- Re: [netlmm] Issue: Auth Option support Alexandru Petrescu
- RE: [netlmm] Issue: Auth Option support Sri Gundavelli
- RE: [netlmm] Issue: Auth Option support Narayanan, Vidya
- Re: [netlmm] Issue: Auth Option support Basavaraj Patil
- RE: [netlmm] Issue: Auth Option support Sri Gundavelli
- Re: [netlmm] Issue: Auth Option support Basavaraj Patil
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- RE: [netlmm] Issue: Auth Option support Sri Gundavelli
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- Re: [netlmm] Issue: Auth Option support Julien Laganier
- RE: [netlmm] Issue: Auth Option support Ahmad Muhanna
- RE: [netlmm] Issue: Auth Option support Ahmad Muhanna
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- RE: [netlmm] Issue: Auth Option support DE JUAN HUARTE FEDERICO
- RE: [netlmm] Issue: Auth Option support Ahmad Muhanna
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- [netlmm] Question on security model DE JUAN HUARTE FEDERICO
- RE: [netlmm] Question on security model Sri Gundavelli
- [netlmm] RE: Question on security model Ahmad Muhanna
- Re: [netlmm] Question on security model Julien Laganier
- RE: [netlmm] Question on security model Alper Yegin
- [netlmm] (no subject) Lynoh MaGee