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

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Sat, 16 May 2020 06:44 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 891A43A07F7 for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 23:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 hn5M8nW-psL6 for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 23:44:30 -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 EE4F13A07E7 for <6man@ietf.org>; Fri, 15 May 2020 23:44:29 -0700 (PDT)
Received: from lhreml743-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C1D412CC2EEC64AB56E3; Sat, 16 May 2020 07:44:27 +0100 (IST)
Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml743-chm.china.huawei.com (10.201.108.193) 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:44:26 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml704-chm.china.huawei.com (10.98.57.158) 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:44:24 +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:44:24 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: Ron Bonica <rbonica@juniper.net>, Fernando Gont <fgont@si6networks.com>, qinfengwei <qinfengwei@chinamobile.com>, 'Bob Hinden' <bob.hinden@gmail.com>, "'Darren Dukes (ddukes)'" <ddukes@cisco.com>
CC: '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//4YZAIAAAWKA//7MOQA=
Date: Sat, 16 May 2020 06:44:24 +0000
Message-ID: <91723b56299e435a8debefab60ffb834@huawei.com>
References: <23488ea0d4eb474c9d7155086f940dae@huawei.com> <006c01d62aa1$8c195520$a44bff60$@com> <DM6PR05MB634863122645FD4981B97F71AEBD0@DM6PR05MB6348.namprd05.prod.outlook.com> <e4cfefa0-eeb4-22ee-6d9b-1abac21ce962@si6networks.com> <DM6PR05MB63486BC1056350B4E6B744FEAEBD0@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB63486BC1056350B4E6B744FEAEBD0@DM6PR05MB6348.namprd05.prod.outlook.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/HiodFFSNgvF203R-IHxdi9La8Y8>
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:44:31 -0000

Hi!
In my common sense, the security should not be dependent on any kind of assumption like "you can't guess out the mapping", or "you don't know the SID".
Is there any theory or IETF BCP to state such principle ?

Thanks
Jingrong


-----Original Message-----
From: Ron Bonica [mailto:rbonica@juniper.net] 
Sent: Saturday, May 16, 2020 4:21 AM
To: Fernando Gont <fgont@si6networks.com>; qinfengwei <qinfengwei@chinamobile.com>; Xiejingrong (Jingrong) <xiejingrong@huawei.com>; 'Bob Hinden' <bob.hinden@gmail.com>; 'Darren Dukes (ddukes)' <ddukes@cisco.com>
Cc: '6man' <6man@ietf.org>
Subject: RE: Questions regarding the security mechanisms//RE: CRH and RH0

Fernando,

Good point. In order to use CRH as an attack vector, the attacker would need to know something about CRH to IPv6 address mappings.

I am assuming that the attacker has this information, either from an inside source (e.g., a disgruntled employee) or from effective guesswork.

                                                                                                                                     Ron



Juniper Business Use Only

-----Original Message-----
From: Fernando Gont <fgont@si6networks.com> 
Sent: Friday, May 15, 2020 4:16 PM
To: Ron Bonica <rbonica@juniper.net>; qinfengwei <qinfengwei@chinamobile.com>; 'Xiejingrong (Jingrong)' <xiejingrong@huawei.com>; 'Bob Hinden' <bob.hinden@gmail.com>; 'Darren Dukes (ddukes)' <ddukes@cisco.com>
Cc: '6man' <6man@ietf.org>
Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0

[External Email. Be cautious of content]


Ron,

On 15/5/20 17:08, Ron Bonica wrote:
> Fengwei, Jingrong,
>
> Your raise excellent questions, and I will try to address them.
>
> In 2007,  security researchers demonstrated that Routing headers can be used attack vectors. See the following slide deck:
>
> - 
> https://urldefense.com/v3/__http://www.secdev.org/conf/IPv6_RH_securit
> y-csw07.pdf__;!!NEt6yMaO-gk!V5RFYkrbeopG4qEvGTKEn3T-EjmwQ85kbakl0Wbppt
> beU0S5zl5X7vOoMeAD5NxQ$
>
> Therefore, we conclude that if a network contains nodes that process the CRH, it MUST deploy ACLs at its edge. These ACLs:
>       - MUST be sufficiently restrictive to filter harmful packets
>       - SHOULD NOT be so restrictive that they filter harmless packets.

I have not read your CRH draft (hence my comments might be non-sense), but it would seem to me that if the labels/SIDs you employ in CRH need mappings in the routers, and/or this functionality is turned off by default (i.e., support for CRH needs to be explitly enabled on the devices expected to use CRH), this is already a major difference and win over RHT0.

The main issue behind RHT0 and, for instance, IPv4 SR is that such functionality was enabled by default, and that all Internet nodes were in the position to process these packets.

If this is not the case, me, as an attacker, would have a much harder time exploiting CRH because I wouldn't even be able to get packets containing a CRH past my CE Router.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492