IETF Logo Mail Archive

Re: [v6ops] (IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 07 February 2023 13:39 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B50C14EB18 for <v6ops@ietfa.amsl.com>; Tue, 7 Feb 2023 05:39:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHpNR74efcaD for <v6ops@ietfa.amsl.com>; Tue, 7 Feb 2023 05:39:55 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB30CC1524DC for <v6ops@ietf.org>; Tue, 7 Feb 2023 05:39:55 -0800 (PST)
Received: from mscpeml100001.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4PB3zM6d5mz688Kc; Tue, 7 Feb 2023 21:35:27 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100001.china.huawei.com (7.188.26.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Tue, 7 Feb 2023 16:39:52 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2507.017; Tue, 7 Feb 2023 16:39:52 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: David Conrad <drc@virtualized.org>
CC: IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] (IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)
Thread-Index: AQHZOvdX79IU/78io0KXVOQDWMVDIq7DevJg
Date: Tue, 07 Feb 2023 13:39:51 +0000
Message-ID: <a32ce8b9574641cdba14708917fd4450@huawei.com>
References: <091075f1-033a-5577-60d9-3c6a009b3e21@si6networks.com> <55adf66d-23cb-0b2c-65d7-8f053a6f9298@si6networks.com> <eb2e613ce5154139a4e18eebff21b822@huawei.com> <A34ACF13-6599-4CB3-ACD2-8F6399C588C9@virtualized.org>
In-Reply-To: <A34ACF13-6599-4CB3-ACD2-8F6399C588C9@virtualized.org>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.153.78]
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/v6ops/6ag2vDiHu_1Mq-8h1FIWd9Zm2aM>
Subject: Re: [v6ops] (IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2023 13:39:59 -0000

All RIRs publish this information.
Something like: https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true&searchtext=2a00:1640::%2F32&source=RIPE
IRR is probably the best for aggregated view: https://www.radb.net/query?advanced_query=&keywords=2a00%3A1640%3A%3A%2F32&-T+option=&ip_option=&-i+option=
We do not want to ping all RIRs separately.

It is not important "who is".
It is more important "how large is the parent prefix".
It should be a really good reason to block something big.

But if not blocked - the offender may rotate inside the parent prefix indefinitely.

Heavy stat collection is needed to make a decision.

Eduard
-----Original Message-----
From: David Conrad [mailto:drc@virtualized.org] 
Sent: Tuesday, February 7, 2023 4:23 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] (IETF I-D): Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)

Eduard,

On Feb 6, 2023, at 11:17 PM, Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote:
> IMHO: it may sense to mention in the absent conclusion that "there is no reliable way to block only offender. If the offense is big enough, it is possible to block legal entity (consulting with RIRs registry).”


This suggests there is a reliable and programmatic way of determining who the legal entity is from the RIR. Is that actually the case?

Thanks,
-drc

v2.23.0 | Report a Bug | By Email