[secdir] 答复: secdir review of draft-ietf-teas-rsvp-te-domain-subobjects-03

"Xialiang (Frank)" <frank.xialiang@huawei.com> Fri, 13 November 2015 08:39 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9D97C1A1B8F; Fri, 13 Nov 2015 00:39:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8Pbeu2EDqIQQ; Fri, 13 Nov 2015 00:39:48 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B03D1A1B84; Fri, 13 Nov 2015 00:39:47 -0800 (PST)
Received: from (EHLO lhreml404-hub.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAG87352; Fri, 13 Nov 2015 08:39:43 +0000 (GMT)
Received: from SZXEMA412-HUB.china.huawei.com ( by lhreml404-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Fri, 13 Nov 2015 08:39:40 +0000
Received: from SZXEMA502-MBS.china.huawei.com ([]) by SZXEMA412-HUB.china.huawei.com ([]) with mapi id 14.03.0235.001; Fri, 13 Nov 2015 16:39:14 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
Thread-Topic: secdir review of draft-ietf-teas-rsvp-te-domain-subobjects-03
Thread-Index: AdEavbx10LBa4DqQRhy7hQBNRVDkOwC1fOAAABZnt5A=
Date: Fri, 13 Nov 2015 08:39:14 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12AE93493@SZXEMA502-MBS.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F12AE924D3@SZXEMA502-MBS.china.huawei.com> <CAB75xn7BfBGMK4e-ST4xiqHT=7csUofu4L-WPC555i_itDhouA@mail.gmail.com>
In-Reply-To: <CAB75xn7BfBGMK4e-ST4xiqHT=7csUofu4L-WPC555i_itDhouA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AE93493SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5645A1D0.00F8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 41b99925240016efdc388af77c1e4041
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/uVmHBuWum-WqrJx6g_1D4C4z9V4>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-teas-rsvp-te-domain-subobjects.all@tools.ietf.org" <draft-ietf-teas-rsvp-te-domain-subobjects.all@tools.ietf.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, Dhruv Dhody <dhruv.dhody@huawei.com>, "pce-chairs@tools.ietf.org" <pce-chairs@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: [secdir] =?utf-8?b?562U5aSNOiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWll?= =?utf-8?q?tf-teas-rsvp-te-domain-subobjects-03?=
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 13 Nov 2015 08:39:51 -0000

Hi Dhruv,
Please see my comments inline:


发件人: dhruvdhody@gmail.com [mailto:dhruvdhody@gmail.com] 代表 Dhruv Dhody
发送时间: 2015年11月13日 13:47
收件人: Xialiang (Frank)
抄送: draft-ietf-teas-rsvp-te-domain-subobjects.all@tools.ietf.org; iesg@ietf.org; secdir@ietf.org; Tobias Gondrom; teas-chairs@ietf.org; Dhruv Dhody; pce-chairs@tools.ietf.org
主题: Re: secdir review of draft-ietf-teas-rsvp-te-domain-subobjects-03

Hi Frank,

Thank you for your review and sorry for the delay in the reply [ Diwali festivities in these neck of woods :) ]
Please see inline...

On Mon, Nov 9, 2015 at 12:40 PM, Xialiang (Frank) <frank.xialiang@huawei.com<mailto:frank.xialiang@huawei.com>> wrote:

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 experimental ID specifies new subobjects for RSVP-TE and GMPLS extensions to RSVP-TE to include or exclude 4-Byte Autonomous System (AS) and Interior Gateway Protocol (IGP) area during path setup.

The document appears in reasonably good shape.
Based on good existing security works on the RSVP-TE and GMPLS, such as [RFC3209], [RFC3473], [RFC4874] and [RFC5920], as well as only introducing some new subobjects for LSP path setup using the same process as before, this document does not introduce new risks in theory.
There are still several open issues (TBDs) in the document that need to be completed before publication.

Below a series of my own comments, questions for your consideration.

One side effect from the misbehaviors of trusted LSR I would suggest you to consider:
If the LSR includes the new defined subobjects with right AS-ID/IGP area id but still using the already existed Types, the legacy nodes will process its content wrongly, and vice versa. In this condition, the length filed checking is sometimes useful although not always;

​[Dhruv]: The already existing types are - http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp-parameters-25
- There is no way to include IGP area with existing types
- There exist 2-Byte AS number type, RFC3209 say the length of sub-object is fixed to 4 when Type is AS (32), this draft says the length is fixed 8 for the new subobject type for 4-Byte AS number. The fixed length takes care of it? Do you see a need to add any other text?​

[Frank]: In theory, there is possibility for the error handling condition that I mentioned. So, I suggest you to consider using the length field checking as a supplementary tool to avoid it.

For the inter-domain scenarios, is it possible that there is not authentication and data protection mechanisms between the two boundary nodes? Furthermore, if the connection between these two nodes are not hop-by-hop, how to guarantee the data integrity and mutual trust?

​[Dhruv]: This analysis is done at https://tools.ietf.org/html/rfc5920#section-8
Chairs, would you like to add anything else? ​

[Frank]: agree with your observations. Do you need to add some reference for this content in the security considerations section of your draft?

Editorial changes:
Section 6: the first sentence “Security considerations for MPLS-TE and GMPLS signaling are covered in [RFC3209] and [RFC3473].”, using the phrases like “MPLS-TE” and “GMPLS signaling” is not very accurate, suggesting to change to “Security considerations for RSVP-TE and GMPLS signaling RSVP-TE extensions are covered in [RFC3209] and [RFC3473]. ”

​[Dhruv]: Ack.

Thank you for your review and comments.


Thank you.