RE: [netlmm] Issue: Auth Option support

"Ahmad Muhanna" <amuhanna@nortel.com> Mon, 10 September 2007 18:08 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 1IUngP-0001Q3-GN; Mon, 10 Sep 2007 14:08:25 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUngN-0001Px-Kn for netlmm@ietf.org; Mon, 10 Sep 2007 14:08:23 -0400
Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUngM-0006pj-NT for netlmm@ietf.org; Mon, 10 Sep 2007 14:08:23 -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 l8AI5uA02224; Mon, 10 Sep 2007 18:05:56 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [netlmm] Issue: Auth Option support
Date: Mon, 10 Sep 2007 13:08:12 -0500
Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116A57C2B@zrc2hxm2.corp.nortel.com>
In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A13@FRVELSMBS12.ad2.ad.alcatel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netlmm] Issue: Auth Option support
Thread-Index: Acfzu9R6l4QFQXIEQAuS3CKNgDr0GgADN/XAAAMPMJA=
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><6FC4416DDE56C44DA0AEE67BC7CA4371169E8EDD@zrc2hxm2.corp.nortel.com> <46E55CA3.6040103@azairenet.com> <319D54578EAC3147BA8CC78DAB5467A501399A13@FRVELSMBS12.ad2.ad.alcatel.com>
From: Ahmad Muhanna <amuhanna@nortel.com>
To: DE JUAN HUARTE FEDERICO <Federico.De_Juan_Huarte@alcatel-lucent.fr>, Vijay Devarapalli <vijay.devarapalli@azairenet.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad
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

Hi Federico,

The issue of using a per-Node SA has been discussed long time ago and reached consensus. This thread is not about the use of Per-Node vs. Per-MN SA. It is about relaxing the mandate of the use IPsec to "MUST implement" and SHOULD use"
That is it.

I Hope this address your concern.

Regards,
Ahmad
 

> -----Original Message-----
> From: DE JUAN HUARTE FEDERICO 
> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] 
> Sent: Monday, September 10, 2007 12:44 PM
> To: Vijay Devarapalli; Muhanna, Ahmad (RICH1:2H10)
> Cc: netlmm@ietf.org
> Subject: RE: [netlmm] Issue: Auth Option support
> 
> Hi,
> 
> I am slowly catching up with NETLMM and I acknowledge that in 
> some aspects (e.g. security model) I'm definitely late
> 
> I understand from this email that, in this group it has 
> already been decided to go for a per-node security model I 
> followed the discussion about the security model in a PMIP 
> solution in a given forum (Wimax) some years ago, and then it 
> was considered that a per-node security model was was not 
> sufficient The main argument I remember is the threat of the 
> MAG being compromised and indiscriminately allocating 
> resources from the LMA This is especially worrisome when the 
> the MAG and the LMA belong to 2 different administrative 
> domains Has this problem been addressed in this group?
> 
> Thanks
> 
> federico
> 
> 
>  
> 
> -----Message d'origine-----
> De : Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]
> Envoyé : lundi 10 septembre 2007 17:03
> À : Ahmad Muhanna
> Cc : netlmm@ietf.org
> Objet : Re: [netlmm] Issue: Auth Option support
> 
> Ahmad,
> 
> I don't believe the security model of using just one security 
> association between the MAG and the LMA for protecting the 
> proxy BU and Proxy BAck changes irrespective of whether IPsec 
> or RFC 4285 is used. So
>   I don't agree with the suggested change.
> 
> Vijay
> 
> Ahmad Muhanna wrote:
> >  
> >> 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 mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm