IETF Logo Mail Archive

RE: Questions regarding the security mechanisms//RE: CRH and RH0

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Fri, 22 May 2020 16:16 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D9E3A0CC3 for <ipv6@ietfa.amsl.com>; Fri, 22 May 2020 09:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 alQ8-La849j2 for <ipv6@ietfa.amsl.com>; Fri, 22 May 2020 09:16:51 -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 C739F3A0CA5 for <6man@ietf.org>; Fri, 22 May 2020 09:16:40 -0700 (PDT)
Received: from lhreml729-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 579B323C21D6EA638EE4; Fri, 22 May 2020 17:16:36 +0100 (IST)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 22 May 2020 17:16:35 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 23 May 2020 00:16:33 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Sat, 23 May 2020 00:16:33 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: John Scudder <jgs@juniper.net>
CC: Tom Herbert <tom@herbertland.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, 6man <6man@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Subject: RE: Questions regarding the security mechanisms//RE: CRH and RH0
Thread-Topic: Questions regarding the security mechanisms//RE: CRH and RH0
Thread-Index: AdYqA0uTBELEk8r7RxOFOlq1QjWhwwAniBKgABOLx4D//5diAP/+48oAgAKNDoD/9kfwQIAS7taA//94U9A=
Date: Fri, 22 May 2020 16:16:33 +0000
Message-ID: <8a1355937f024458b7be31d7d64ca060@huawei.com>
References: <23488ea0d4eb474c9d7155086f940dae@huawei.com> <006c01d62aa1$8c195520$a44bff60$@com> <DM6PR05MB634863122645FD4981B97F71AEBD0@DM6PR05MB6348.namprd05.prod.outlook.com> <CALx6S35thGuTgTmCFozU=3MULW8V95OwA5GdqQ7OGrA-agR7Hw@mail.gmail.com>, <891ccad03b484c7386ab527d89143f8c@huawei.com> <87E86EE4-7D6C-49A3-A965-317C3F95A346@juniper.net>, <ab0b9d67d294464fb886b9cb5e7639a5@huawei.com> <592214BF-5340-40A6-86C8-430C87AC0171@juniper.net>
In-Reply-To: <592214BF-5340-40A6-86C8-430C87AC0171@juniper.net>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.189.60]
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/ipv6/YOo1KY5giOPVr8G0rs8vXCLolVk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2020 16:17:01 -0000

Hi John,
I have read the analysis you provided in previous message.
The "very helpful" is to the layered security mode: https://en.wikipedia.org/wiki/Layered_security
To the RH security problem we are discussing:
(1) the border ACLs may fail to deploy. For example, there may be 1 border router (among 1000) is not configured correctly.
(2) a border router may be compromised (RFC8279 "If a BFIR is compromised"), the ACLs on the border router may be modified.

Thanks
Jingrong

-----Original Message-----
From: John Scudder [mailto:jgs@juniper.net] 
Sent: Saturday, May 23, 2020 12:01 AM
To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>
Cc: Tom Herbert <tom@herbertland.com>; Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>; 6man <6man@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0

I’m not sure if it’s worth pursuing this much farther considering it’s not directly applicable to CRH as such. However:

On May 22, 2020, at 11:51 AM, Xiejingrong (Jingrong) <xiejingrong@huawei.com> wrote:
> 
> [XJR] The "complemented per-node protection " is very useful for a layered security mode.

I might be convinced if you have reasons for this that address the analysis I provided in my own message. However, a bald statement that it’s “very useful” without further support doesn’t seem too helpful. 

Regards,

—John

v2.23.0 | Report a Bug | By Email