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

"Xialiang (Frank)" <frank.xialiang@huawei.com> Fri, 13 November 2015 09:28 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F701A86EC; Fri, 13 Nov 2015 01:28:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYRLQtGzcSJR; Fri, 13 Nov 2015 01:28:35 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E791A86EB; Fri, 13 Nov 2015 01:28:33 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAG93144; Fri, 13 Nov 2015 09:28:31 +0000 (GMT)
Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 13 Nov 2015 09:28:29 +0000
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.77]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Fri, 13 Nov 2015 17:28:18 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: Dhruv Dhody <dhruv.dhody@huawei.com>, Dhruv Dhody <dhruv.ietf@gmail.com>
Thread-Topic: secdir review of draft-ietf-teas-rsvp-te-domain-subobjects-03
Thread-Index: AdEavbx10LBa4DqQRhy7hQBNRVDkOwC1fOAAABZnt5D//4lagP//eTFw
Date: Fri, 13 Nov 2015 09:28:18 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12AE934C6@SZXEMA502-MBS.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F12AE924D3@SZXEMA502-MBS.china.huawei.com> <CAB75xn7BfBGMK4e-ST4xiqHT=7csUofu4L-WPC555i_itDhouA@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F12AE93493@SZXEMA502-MBS.china.huawei.com> <23CE718903A838468A8B325B80962F9B8C445C86@BLREML509-MBX.china.huawei.com>
In-Reply-To: <23CE718903A838468A8B325B80962F9B8C445C86@BLREML509-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.135.43.91]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AE934C6SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5645AD3F.016B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.77, 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/w1LXq3YQq8OHmyXREYS6GkfEqNU>
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>, "iesg@ietf.org" <iesg@ietf.org>, "pce-chairs@tools.ietf.org" <pce-chairs@tools.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 09:28:37 -0000

Hi Dhruv,
Thanks for your detailed explanation and quick problem solving.

B.R.
Frank

发件人: Dhruv Dhody
发送时间: 2015年11月13日 17:24
收件人: Xialiang (Frank); Dhruv Dhody
抄送: draft-ietf-teas-rsvp-te-domain-subobjects.all@tools.ietf.org; iesg@ietf.org; secdir@ietf.org; Tobias Gondrom; teas-chairs@ietf.org; pce-chairs@tools.ietf.org
主题: RE: secdir review of draft-ietf-teas-rsvp-te-domain-subobjects-03

Hi Frank,

See inline [Dhruv2].

<snip>
Comment:
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.

[Dhruv2]: The fixed length check for existing sub-object type is already in place via RFC3209. So this error handling you mention is already in place.

Question:
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?

[Dhruv2]: Ack

<snip>

The working copy diff is attached for reference (includes IANA, Gen-ART, Sec-Dir reviews).

Regards,
Dhruv​