Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS

jouni korhonen <jouni.nospam@gmail.com> Wed, 04 January 2012 08:28 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2263621F86C8 for <dime@ietfa.amsl.com>; Wed, 4 Jan 2012 00:28:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGKD1aSnKuRt for <dime@ietfa.amsl.com>; Wed, 4 Jan 2012 00:28:02 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFC0D21F860C for <dime@ietf.org>; Wed, 4 Jan 2012 00:28:01 -0800 (PST)
Received: by laah2 with SMTP id h2so7102218laa.31 for <dime@ietf.org>; Wed, 04 Jan 2012 00:28:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FmwrQkqWiZCE6sG/g3x3gG0j1DZcpq+1jLwtMwN6YHg=; b=ITfIylOjfX/d1a/A2hcCQvPKOOQzf2seRZAjcDW4KXjSmFmmful8BYY8I+QCmS0Auv T92KRsnrnFSDBfUMTqBta4nZLIT/nJmeZP3dp5wm/ux3DmaSwAST9RIvKPDwm69SwBWE g65Qi0qG2qO5uCVsvB5hyduhEhn83g4RBbycc=
Received: by 10.152.136.39 with SMTP id px7mr44022692lab.2.1325665680857; Wed, 04 Jan 2012 00:28:00 -0800 (PST)
Received: from a83-245-210-48.elisa-laajakaista.fi (a83-245-210-48.elisa-laajakaista.fi. [83.245.210.48]) by mx.google.com with ESMTPS id is1sm12452321lab.1.2012.01.04.00.27.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 00:27:59 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <B11765B89737A7498AF63EA84EC9F577010E8953@ftrdmel1>
Date: Wed, 04 Jan 2012 10:27:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C272D860-A556-496C-AF10-7DAD45429FF7@gmail.com>
References: <9A2E9984-EA8E-41D7-9834-916F73DCF432@gmail.com> <C0E0A32284495243BDE0AC8A066631A80C1F3B00@szxeml526-mbs.china.huawei.com> <B11765B89737A7498AF63EA84EC9F577010E8953@ftrdmel1>
To: lionel.morand@orange.com
X-Mailer: Apple Mail (2.1084)
Cc: dime@ietf.org
Subject: Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2012 08:28:03 -0000

Hi,

On Jan 3, 2012, at 7:24 PM, <lionel.morand@orange.com> <lionel.morand@orange.com> wrote:

> OK with the direction of the proposal.
> Just too questions for clarification:
> - do we keep a priority order between 1/(D)TLS and 2/IPsec as currently documented in draft or is it also challenged by the Stephen's comment?

Stephen does not challenge the priority order. I would personally have a slight preference for IPsec as it is already there for other purposes but I am definitely OK having the current priority order the WG came up with.

> - Is it clear that mandating the possible use of IPsec to secure the connection does not mandate the peers to support of Diameter by the peers (e.g. use of IPsec GWs btw peers)?

This is a good point to emphasize. One known deployment that will rely on IPsec is 3GPP Rel-8. For example, GSMA recently put references to NDS into LTE roaming guideline IR.88 for securing Diameter connections.

In addition to Stephen's Section 13 change proposal also Section 2.2 sentence "If desired, alternative security mechanisms that are independent of Diameter, such as IPsec [RFC4301], can be deployed to secure connections between peers." needs to be changed to make it explicit that the alternative security mechanism is IPsec based.

- Jouni

> 
> Regards,
> 
> Lionel 
> 
> -----Message d'origine-----
> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Tina TSOU
> Envoyé : lundi 21 novembre 2011 09:49
> À : jouni korhonen; dime@ietf.org
> Objet : Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS
> 
> This solution works for me, though I think TLS is closer to what most of the vendors currently implement.
> 
> 
> Best Regards,
> Tina TSOU
> http://tinatsou.weebly.com/contact.html
> 
> -----Original Message-----
> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of jouni korhonen
> Sent: Monday, November 21, 2011 12:38 AM
> To: dime@ietf.org
> Subject: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS
> 
> Folks,
> 
> During the meeting we had a discussion on Stephen Farrell's discuss: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ballot/#stephen-farrell
> 
> Glen had a solution proposal that we follow what Stephen suggested i.e. mandate use of either IPsec or (D)TLS within the spec and leave out the "some security mechanism". This of course has some impact on product & deployment level as from now on either IPsec or (D)TLS must be used..
> 
> Any feedback?
> 
> - Jouni
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime