IETF Logo Mail Archive

Re: [MSEC] Key Management protocol (GDOI - 6407) forward

Paul Lambert <paul@marvell.com> Fri, 27 September 2013 21:52 UTC

Return-Path: <paul@marvell.com>
X-Original-To: msec@ietfa.amsl.com
Delivered-To: msec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A84821F9D66 for <msec@ietfa.amsl.com>; Fri, 27 Sep 2013 14:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.264
X-Spam-Level:
X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
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 ibYeKjexNO-m for <msec@ietfa.amsl.com>; Fri, 27 Sep 2013 14:52:48 -0700 (PDT)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 38B1721F9CA5 for <msec@ietf.org>; Fri, 27 Sep 2013 14:52:47 -0700 (PDT)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r8RLqP1c028803; Fri, 27 Sep 2013 14:52:43 -0700
Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1f4d6da2fa-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Sep 2013 14:52:43 -0700
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 27 Sep 2013 14:52:43 -0700
From: Paul Lambert <paul@marvell.com>
To: "Herb Falk <herb@sisconet.com>" <Herb@sisconet.com>, "msec@ietf.org" <msec@ietf.org>
Date: Fri, 27 Sep 2013 14:52:43 -0700
Thread-Topic: [MSEC] Key Management protocol (GDOI - 6407) forward
Thread-Index: Ac67y+Q/muj4dKbwRZ+M8dFheo63vw==
Message-ID: <CE6B4BE4.23A05%paul@marvell.com>
In-Reply-To: <418E74FA535F654FAB3CAAE12902E2940156AA80@SISCO-SBS.sisconet.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CE6B4BE423A05paulmarvellcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-27_09:2013-09-27, 2013-09-27, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309270135
Cc: Jeff Gooding/SCE/EIX <Jeff.Gooding@sce.com>, "Maik Seewald (maseewal)" <maseewal@cisco.com>, "Andrew.Free@sce.com" <Andrew.Free@sce.com>, "Madani, Vahid" <VxM6@pge.com>, "Adamiak, Mark (GE Energy Management)" <mark.adamiak@ge.com>, "Novosel, Damir" <DNovosel@Quanta-Technology.com>, "Thanos, Daniel (GE Energy Management)" <Daniel.Thanos@ge.com>, "Alex Apostolov (alex.apostolov@omicronusa.com)" <alex.apostolov@omicronusa.com>
Subject: Re: [MSEC] Key Management protocol (GDOI - 6407) forward
X-BeenThere: msec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multicast Security List <msec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/msec>, <mailto:msec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/msec>
List-Post: <mailto:msec@ietf.org>
List-Help: <mailto:msec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/msec>, <mailto:msec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2013 21:52:54 -0000

IEC TC57 WG10 (61850) and IEC TC57 WG15 (Security) has been developing a technology/standard for use as a secure multicast for its use in power grid applications using synchrophasors and other technologies relevant to smartgrid deployments globally.

As part of the effort, some extensions to GDOI were identified.  The 6407 draft incorporates and improves some of the enhancements already identified.  IEC TC57 WG15 is waiting for the draft RFC to transition to an RFC so it can be referenced as a normative standard in IEC 62351-9.

There are several utility vendors and utilities, in particular SCE (Southern California Edison), that are awaiting this transition so that their cyber security frameworks can be updated.  Delays in the transition from draft to RFC will delay implementation of several projects and implementations.

Good to see such applications.  What encapsulation mode is specified for this multicast service?   Just curious since I have other industry requirements that are very similar and need better multicast security.

Thanks in advance,

Paul







Herbert Falk
Solutions Architect
SISCO, INC.
6605 19 1Ž2 Mile Rd.
Sterling Heights, MI 48314
(586) 254-0020 x-105
[cid:image001.png@01CEBB05.DAE71150]


"In matters of style, swim with the current;   in matters of principle, stand like a rock." [Thomas Jefferson]


NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have  received this communication in error, please do not print, copy, retransmit,  disseminate, or otherwise use the information. Also,  please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you.

________________________________

v2.23.0 | Report a Bug | By Email