[secdir] 答复: Secdir last call review of draft-ietf-6man-segment-routing-header-22

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Fri, 23 August 2019 01:06 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE0B120271; Thu, 22 Aug 2019 18:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 UXLJUe_L1EKZ; Thu, 22 Aug 2019 18:06:21 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658B5120168; Thu, 22 Aug 2019 18:06:21 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3D39039084C2D4F3F2D9; Fri, 23 Aug 2019 02:06:19 +0100 (IST)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 23 Aug 2019 02:06:19 +0100
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 23 Aug 2019 02:06:18 +0100
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Fri, 23 Aug 2019 02:06:18 +0100
Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.72]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Fri, 23 Aug 2019 09:06:14 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: "Darren Dukes (ddukes)" <ddukes@cisco.com>
CC: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-6man-segment-routing-header.all@ietf.org" <draft-ietf-6man-segment-routing-header.all@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-6man-segment-routing-header-22
Thread-Index: AQHVWDYYmP3iNe23R0OgF245icsplqcH7Spg
Date: Fri, 23 Aug 2019 01:06:13 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13E887343@dggemm511-mbx.china.huawei.com>
References: <156584039497.2287.2516898029582755543@ietfa.amsl.com> <4074EC87-36AB-4521-A415-DCDC621C4129@cisco.com>
In-Reply-To: <4074EC87-36AB-4521-A415-DCDC621C4129@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.159.76]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/BtgUH0CiHCbH-Ozmox88my-VP9g>
Subject: [secdir] =?utf-8?b?562U5aSNOiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBv?= =?utf-8?q?f_draft-ietf-6man-segment-routing-header-22?=
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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, 23 Aug 2019 01:06:24 -0000

Hi Darren,
Thanks for the response.
No more issues from my side.

B.R.
Frank

-----邮件原件-----
发件人: Darren Dukes (ddukes) [mailto:ddukes@cisco.com] 
发送时间: 2019年8月21日 23:35
收件人: Xialiang (Frank, Network Standard & Patent Dept) <frank.xialiang@huawei.com>;
抄送: secdir@ietf.org; draft-ietf-6man-segment-routing-header.all@ietf.org; ipv6@ietf.org; ietf@ietf.org
主题: Re: Secdir last call review of draft-ietf-6man-segment-routing-header-22

Thank you for the review.  Please see inline.

> On Aug 14, 2019, at 11:39 PM, Liang Xia via Datatracker <noreply@ietf.org>; wrote:
> 
> Reviewer: Liang Xia
> Review result: Has Issues
> 
> Some nits:
> 1. title of Section 4.3.2: /FIB Entry is a Local Interface/FIB Entry 
> Is A Local Interface
OK

> 2. title of Section 5.2: /SR Domain as a single system with delegation 
> among components/SR Domain as A Single System with Delegation among 
> Components

OK


> 3. Section 2.1.1: /There are two types of padding TLVs, pad1 and padN, 
> the following applies to both/There are two types of Padding TLVs, 
> pad1 and padN, the following applies to both

Ack, we’ll use Padding TLV capitalized as a name.

> 4. Section 2.1.2: "Alignment
> requirement: 8n". What is 8n? For better readability, can you give a 
> more clear clarification text?

Section 2.1 describes what an alignment requirement is and how it is documented, referencing RFC8200.

"All TLVs specify their alignment requirements using an xn+y format.
   The xn+y format is defined as per [RFC8200].  The SR Source nodes use
   the xn+y alignment requirements of TLVs and padding TLVs when
   constructing an SRH.”

Does this address your concern?

> 5. Section 4.1: /HMAC TLV may be set according to Section 7./HMAC TLV 
> may be set according to Section 2.1.2./?

Thanks, I’ve fixed the XML xref for the next revision.

> 6. Section 4.3: have a "*"
> before every item of "A FIB entry…”
> ?
> 

Sure, I expect that would make it more obvious they are individual line items.

> 1 issue:
> The Security Considerations Section mainly clarifies the security 
> protection based on the strict SR Domain boundary protection paradigm, 
> and the considerations of some identified attacks. They are valuable, 
> but maybe not complete in scope. I noticed 2 SR related security 
> consideration drafts
> (draft-perkins-sr-security-00 and
> draft-li-spring-srv6-security-consideration-00), which are trying to 
> summarize all the possible vulnerabilities in SR network. I personally 
> suggests the authors to review them and consider how to reference or 
> incorporate the valuable considerations from them.

Thank you for this suggestion, I’ve analyzed both the referenced documents:

draft-li-spring-srv6-security-consideration-01 concludes that there is no packet falsification, identity spoofing, packet replay, DOS/DDOS threat within an SR Domain.
It defines a security design following that documented in draft-ietf-6man-segment-routing-header-22.  I see nothing to add from this draft.

draft-perkins-sr-security-00 discusses a set of deployment scenarios, and SIDs that are not documented in draft-ietf-6man-segment-routing-header-22, and are therefore out of scope for draft-ietf-6man-segment-routing-header to consider.

However the discussions started with draft-perkins-sr-security-00 should continue in the context of the SPRING WG, as per its charter, for the technologies and documents it produces using the SRH.

Would this address your concern?

Darren