Re: [secdir] secdir review of draft-ietf-mpls-hsmp-04

"Lizhong Jin" <lizho.jin@gmail.com> Mon, 02 December 2013 03:00 UTC

Return-Path: <lizho.jin@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A33F1AE31C; Sun, 1 Dec 2013 19:00:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.45
X-Spam-Level:
X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y72Oa6VmmXTa; Sun, 1 Dec 2013 19:00:13 -0800 (PST)
Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2671AE32E; Sun, 1 Dec 2013 19:00:13 -0800 (PST)
Received: by mail-pb0-f42.google.com with SMTP id uo5so17972858pbc.29 for <multiple recipients>; Sun, 01 Dec 2013 19:00:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=F2Wu2eSNWgW5eMig8+rvbnkfJb96mfyST6sHnwqTyLk=; b=R+PHo5eLf55r1prHh5qPnOZ0ztVm8YkqxJZQr60IYx/C7ABvWZcwHntXJDpDIIhCt9 DMJfwwBQh5vL7E1XG64CyoA0VIIgTC4J7sNrAjr9rFOnlrf9PQKYYNtEHU3o5kI9DkJM +p0qh4gtjxXStBGo8aYQQ5Q6FK34HXSTGqTTTYKRLb7HCSWAhPjfv4hh1fEJDXuOFp01 HoFS5NgxOEVEJkdBc3spKur3Me560W2MtCUv+0UKL+OqpCfHXFHc4JFwYdAR5tHT/Rxl HDkvZdiRh7loMWtEx0ShgffsUGUw7GwXl/xVQWv254GB+Ma+NAxXmku0FSgLgDsDvMzA XE6A==
X-Received: by 10.68.196.69 with SMTP id ik5mr28820154pbc.132.1385953210997; Sun, 01 Dec 2013 19:00:10 -0800 (PST)
Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id uf2sm118650051pbc.28.2013.12.01.19.00.08 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 01 Dec 2013 19:00:10 -0800 (PST)
From: Lizhong Jin <lizho.jin@gmail.com>
To: 'Charlie Kaufman' <charliek@microsoft.com>, secdir@ietf.org, iesg@ietf.org, draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org
References: <2b12ea7449014b53a4b4118929921b75@BL2PR03MB592.namprd03.prod.outlook.com>
In-Reply-To: <2b12ea7449014b53a4b4118929921b75@BL2PR03MB592.namprd03.prod.outlook.com>
Date: Mon, 02 Dec 2013 11:00:05 +0800
Message-ID: <022201ceef0a$9cc3c470$d64b4d50$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIHav6dMGoNhrLf258GkpHEMqzPNpnPNLAw
Content-Language: zh-cn
X-Mailman-Approved-At: Mon, 02 Dec 2013 08:00:47 -0800
Subject: Re: [secdir] secdir review of draft-ietf-mpls-hsmp-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 03:00:15 -0000

Hi Charlie,
Thank you for the review. See inline below.

Regards
Lizhong

-----Original Message-----
From: Charlie Kaufman [mailto:charliek@microsoft.com] 
Sent: 2013年12月1日 15:11
To: secdir@ietf.org; iesg@ietf.org;
draft-ietf-mpls-mldp-hsmp.all@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-mpls-hsmp-04

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document defines a new variation of MPLS for multipoint to multipoint
communication. The document does not state why anyone would prefer this new
variation over the existing one, though I can guess a few reasons. The new
variation is less efficient in that packets sent travel over many links
twice instead of once and packet delivery has longer latency in that most
packets travel over more links from their original source to ultimate
destination. The two advantages I can imagine are (1) in almost all cases,
all packets will arrive at all destinations in the same order (in the
original protocol, packets from different sources could arrive at different
destinations in different orders); and (2) the root of the multicast tree
could filter messages - for example, to throttle the total volume of
messages from a single source. A third possible use that seems to be
disavowed by the document is to allow members of the multicast group to
signal their status only to the root node. It would be nice if the document
was more explicit about what this protocol was for, but it doesn't affect
security considerations.
[Lizhong] The main function HSMP provided is the communication between leaf
and root in a hub & spoke network. If leaf to leaf communication is
required, I don't think HSMP is a suitable candidate. Applications which
require P2MP connection from root to every leaf and P2P connection from
every leaf to root could use HSMP LSP. During the AD review process, after
discussed with Adrian, in this 04 version, we decided to remove the
"Applications" section in 03 version
(http://www.ietf.org/mail-archive/web/mpls/current/msg10959.html)

The document correctly notes that there are no new security considerations
beyond those discussed in the protocol that this competes with. That
protocol  is defined in RFC6388 and RFC6425.

Nits:

Last sentence of abstract reads "The communication among the leaf nodes are
not allowed." I believe the grammar is incorrect, but more importantly I
believe it should read "Direct communication among the leaf nodes is not
allowed." because communication among the leaf nodes is supported by this
protocol with all packets being relayed by the root node.
[Lizhong] accepted for the new text. But we do not recommend for the root
node to do relay. If leaf to leaf communication is required, MP2MP LSP
(RFC6388) is recommended.

Near the end of the introduction  is the phrase "except that it follows the
node of reverse downstream path of the tree". I believe the word 'node' is
incorrect here, though I don't know what was intended.
[Lizhong] to make it more clearly, change to "except that it follows the
reverse direction of the downstream LSP".

Page 11: "In some scenario," should be "In some scenarios,"
[Lizhong] accepted.

	--Charlie