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

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Sat, 16 May 2020 06:36 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 C379B3A07D0 for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 23:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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 8E_ljvrF0W00 for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 23:36:32 -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 5A1D53A07D6 for <6man@ietf.org>; Fri, 15 May 2020 23:36:32 -0700 (PDT)
Received: from lhreml736-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B558EA85C4CA40F63AA7; Sat, 16 May 2020 07:36:29 +0100 (IST)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml736-chm.china.huawei.com (10.201.108.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 16 May 2020 07:36:28 +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, 16 May 2020 14:36:26 +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, 16 May 2020 14:36:26 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: Tom Herbert <tom@herbertland.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
CC: qinfengwei <qinfengwei@chinamobile.com>, Bob Hinden <bob.hinden@gmail.com>, "Darren Dukes (ddukes)" <ddukes@cisco.com>, 6man <6man@ietf.org>
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/+48oA
Date: Sat, 16 May 2020 06:36:26 +0000
Message-ID: <891ccad03b484c7386ab527d89143f8c@huawei.com>
References: <23488ea0d4eb474c9d7155086f940dae@huawei.com> <006c01d62aa1$8c195520$a44bff60$@com> <DM6PR05MB634863122645FD4981B97F71AEBD0@DM6PR05MB6348.namprd05.prod.outlook.com> <CALx6S35thGuTgTmCFozU=3MULW8V95OwA5GdqQ7OGrA-agR7Hw@mail.gmail.com>
In-Reply-To: <CALx6S35thGuTgTmCFozU=3MULW8V95OwA5GdqQ7OGrA-agR7Hw@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.163.108]
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/Ndgzd0CTcoTZuwf70AnzikBAQMo>
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: Sat, 16 May 2020 06:36:34 -0000

<...snip the redundant text, see the in-line reply marked with [XJR]>
Hi!

That raises an interesting question. Can a protocol specification have a normative MUST requirement for correctness or security that is dependent on completely external properties? If this is saying that the ACLs are implemented as part of the CRH datapath then tht might be reasonable, but if this is saying that ACLs must be deployed at every possible edge node outside of the CRH processing that doesn't seem like it could be a MUST in a protocol specification (and this might be coming close to the general but effectively useless requirement that the underlying network MUST be secure and correct for the protocol to be secure and correct).

[XJR] Good catch that "ACLs must be deployed at every possible edge node outside of the CRH processing" makes it difficult to deployable.
[XJR] But If this "MUST" is weaken to any extent, I am afraid the said RFC5095 attack could be from Internet.

Also, I think you might want to mention that AH should be used to protect the routing header when security is a concern. AH is part of the protocol suite and doesn't depend on external factors other than what's happening at the end points. Normative requirements are appropriate for security via AH.

[XJR] Agreed that AH could help to ensure the Source is from a legitimate source as RFC8754 HMAC does. But there is no mandatory AH/HMAC in this draft.
[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.

Thanks
Jingrong

Tom