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

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Fri, 22 May 2020 15:51 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 684393A0B95 for <ipv6@ietfa.amsl.com>; Fri, 22 May 2020 08:51:08 -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 zgjVVaMY1D1F for <ipv6@ietfa.amsl.com>; Fri, 22 May 2020 08:51:03 -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 89FDF3A0BA9 for <6man@ietf.org>; Fri, 22 May 2020 08:51:03 -0700 (PDT)
Received: from lhreml726-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3E50F8539D0F539953CF; Fri, 22 May 2020 16:51:02 +0100 (IST)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml726-chm.china.huawei.com (10.201.108.77) 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 16:51:01 +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; Fri, 22 May 2020 23:50:58 +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; Fri, 22 May 2020 23:50:58 +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/9kfwQA==
Date: Fri, 22 May 2020 15:50:58 +0000
Message-ID: <ab0b9d67d294464fb886b9cb5e7639a5@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>
In-Reply-To: <87E86EE4-7D6C-49A3-A965-317C3F95A346@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/xj0vMcCHxVATWFhh2H_63izON8w>
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 15:51:09 -0000

Hi John,
Please see my comment in-line below:

-----Original Message-----
From: John Scudder [mailto:jgs@juniper.net] 
Sent: Sunday, May 17, 2020 3:18 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

Hi Jingrong,

As far as I can tell, although 8754 S 5.1 is very nicely written, it boils down to “use border ACLs”. Specific to this:

[XJR] Yes RFC8754 boils down to "use border ACLs", but that kind of ACLs are truly available and thus make the deployment of SRH secure. The CRH border ACLs defined in current draft are not widely available, and thus make a huge surface for attacker.

On May 16, 2020, at 2:36 AM, Xiejingrong (Jingrong) <xiejingrong@huawei.com> wrote:
> 
> [XJR] Once an attack packet pass through the border router, there is no additional protection like the "complemented per-node protection" in RFC8754 section 5.1.

I think the “complemented per-node protection” in S 5.1 part 2 is not especially valuable, and may even be detrimental. The reasoning is as follows: if the border routers do correctly implement destination address filtering per part 1, attack traffic will already be stopped; there is no need for the source address filtering part 2 specifies. On the other hand, if the border routers do not correctly implement DA filtering, why on earth would we expect them to correctly implement SA filtering? If they don’t, then an attacker can craft their attack with forged SA to bypass SA filtering within the victim network. For this reason, I think the “complemented per-node protection” is of little value. It may be of negative value if it leads to a sense of complacency on the part of the victim.

[XJR] The "complemented per-node protection " is very useful for a layered security mode. Given the above weakness, the CRH may need the "complemented per-node protection" more than SRH. 

Thanks
Jingrong


Regards,

—John