Re: [netlmm] Issue: Auth Option support

Basavaraj Patil <basavaraj.patil@nsn.com> Fri, 07 September 2007 21:11 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 1ITl7P-0004b5-V3; Fri, 07 Sep 2007 17:11:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITl7O-0004b0-EX for netlmm@ietf.org; Fri, 07 Sep 2007 17:11:58 -0400
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITl7N-00049d-1z for netlmm@ietf.org; Fri, 07 Sep 2007 17:11:58 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l87LB7S1028687; Sat, 8 Sep 2007 00:11:46 +0300
Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Sep 2007 00:11:09 +0300
Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 16:11:04 -0500
Received: from 10.241.58.198 ([10.241.58.198]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Sep 2007 21:11:04 +0000
User-Agent: Microsoft-Entourage/11.3.6.070618
Date: Fri, 07 Sep 2007 16:11:33 -0500
Subject: Re: [netlmm] Issue: Auth Option support
From: Basavaraj Patil <basavaraj.patil@nsn.com>
To: Sri Gundavelli <sgundave@cisco.com>, 'Julien Laganier' <julien.IETF@laposte.net>, netlmm@ietf.org
Message-ID: <C30728B5.4290C%basavaraj.patil@nsn.com>
Thread-Topic: [netlmm] Issue: Auth Option support
Thread-Index: AcfxSsGFlDvDz/RAQJWYV4inKIWpywAJhYcQAAi0xVI=
In-Reply-To: <010801c7f171$f3997f30$d4f6200a@amer.cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 07 Sep 2007 21:11:04.0771 (UTC) FILETIME=[99E44930:01C7F193]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc:
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 Sri,

I do believe we need to specify a default security mechanism for the MAG/LMA
signaling messages. And for this purpose, IPsec is a good choice.
So IMO it is required that we state "Proxy MIP6 signaling messages between
the MAG and LMA MUST be secured by the use of an IPsec SA between the two
entities".

I think this does not limit the ability to adopt alternative security
solutions in the future.

-Raj


On 9/7/07 12:10 PM, "ext Sri Gundavelli" <sgundave@cisco.com> wrote:

> Hi Julien,
> 
>  
> 
>> -----Original Message-----
>> From: julien laganier [mailto:julien.laganier@gmail.com] On
>> Behalf Of Julien Laganier
>> Sent: Friday, September 07, 2007 5:29 AM
>> To: netlmm@ietf.org
>> Cc: Sri Gundavelli; 'Alper Yegin'
>> Subject: Re: [netlmm] Issue: Auth Option support
>> 
>> Hi Sri,
>> 
>> On Thursday 06 September 2007, Sri Gundavelli wrote:
>>> 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.
>> 
>> Somehow, "MUST implement" and "SHOULD use" together seems a bit
>> tautologic. 
>> 
>> To me "SHOULD use" is sufficient since it covers both of the two
>> possibles cases:
>> 
>> - deployment follows the SHOULD recommendation, it uses IPsec
>> to protect 
>> PMIPv6, in which case it supports it, since it's using it :), or
>> 
>> - deployment ignores the SHOULD recommendation, does not uses
>> IPSec, in 
>> which case it is useless to implement it since it's not used...
>> 
>> I'd prefer having "MUST protect integrity of signalling messages, and
>> SHOULD use IPsec ESP to protect integrity of those messages".
>> We might 
>> also add "MAY use IPsec AH".
>> 
> 
> 
> I agree. I'm not against allowing other approaches. I'm only concerned,
> if we can leave the draft saying, "MUST protect integrity of signalling
> messages", with out specifying IPsec or some other approach. If that
> will pass the security review. We may have to state that IPsec MUST be
> used or some other approach, say Auth-Option MUST be used. Not sure, if
> we can leave this blank.
> 
> 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