RE: [netlmm] Issue: Auth Option support

"Sri Gundavelli" <sgundave@cisco.com> Fri, 07 September 2007 21:42 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 1ITlb0-0006Ea-E1; Fri, 07 Sep 2007 17:42:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlay-0006Az-UT for netlmm@ietf.org; Fri, 07 Sep 2007 17:42:32 -0400
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.43) id 1ITlax-00054H-Mm for netlmm@ietf.org; Fri, 07 Sep 2007 17:42:32 -0400
X-IronPort-AV: E=Sophos;i="4.20,222,1186383600"; d="scan'208";a="521724618"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 Sep 2007 14:42:31 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l87LgVHD011460; Fri, 7 Sep 2007 14:42:31 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l87LgQ7R016280; Fri, 7 Sep 2007 21:42:31 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 14:42:26 -0700
Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 14:42:26 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: 'Basavaraj Patil' <basavaraj.patil@nsn.com>, 'Julien Laganier' <julien.IETF@laposte.net>, netlmm@ietf.org
References: <010801c7f171$f3997f30$d4f6200a@amer.cisco.com> <C30728B5.4290C%basavaraj.patil@nsn.com>
Subject: RE: [netlmm] Issue: Auth Option support
Date: Fri, 07 Sep 2007 14:42:25 -0700
Message-ID: <015101c7f197$fb0457b0$d4f6200a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <C30728B5.4290C%basavaraj.patil@nsn.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Thread-Index: AcfxSsGFlDvDz/RAQJWYV4inKIWpywAJhYcQAAi0xVIAAPT7EA==
X-OriginalArrivalTime: 07 Sep 2007 21:42:26.0123 (UTC) FILETIME=[FB43D1B0:01C7F197]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3189; t=1189201351; x=1190065351; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20<sgundave@cisco.com> |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Auth=20Option=20support |Sender:=20; bh=iYVpF5t1EeavYFy1KNGuFkXmF+CeENA7QtK+t4qOWK0=; b=uZcBGZaqGlfinJYHPGsRD+8H7ezqZ79d2uEpu3H1JuLC9sbCIG9toH57r16qp6l2SKu5+3Ab 61JW9X77BZkUJvAhbawaYDH/IPFnvLHuIIb7gVJbpJ4RvmuiBnm4Ob4/;
Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
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

Raj,

This is my view as well. Now, this will conflict with
"MUST implement and SHOULD use of IPsec". To be consistent,
it has to be "MUST implement and MUST use". Then Alper wont
like this...


Sri
 

> -----Original Message-----
> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] 
> Sent: Friday, September 07, 2007 2:12 PM
> To: Sri Gundavelli; 'Julien Laganier'; netlmm@ietf.org
> Subject: Re: [netlmm] Issue: Auth Option support
> 
> 
> 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