Re: [v6ops] Possible issue with source address selection for ULAs...

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 19 January 2022 09:35 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 2F9023A15AA; Wed, 19 Jan 2022 01:35:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 F8j5t2DPuJwA; Wed, 19 Jan 2022 01:35:44 -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 0EB893A15A9; Wed, 19 Jan 2022 01:35:44 -0800 (PST)
Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Jf0qg0wy3z67x0m; Wed, 19 Jan 2022 17:35:27 +0800 (CST)
Received: from mscpeml500002.china.huawei.com (7.188.26.138) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 19 Jan 2022 10:35:40 +0100
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500002.china.huawei.com (7.188.26.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 19 Jan 2022 12:35:39 +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.2308.020; Wed, 19 Jan 2022 12:35:39 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Mark Smith <markzzzsmith@gmail.com>
CC: IPv6 Ops WG <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Thread-Topic: [v6ops] Possible issue with source address selection for ULAs...
Thread-Index: AQHX9vvvL+2CykGFBkehBNPC1FNlZaw+CgAAgABR1ACAAAaKgIAUpcsAgABEbQCAAC28AIAA/EaAgABEdoCAB8M9MIAL2J6AgAB1MDD//9M1gIAASSiAgADOAoCAAHi6wA==
Date: Wed, 19 Jan 2022 09:35:39 +0000
Message-ID: <c8d0722b122944c1ada74d81ca8bfffc@huawei.com>
References: <4DD59CC3-1BDB-4A1C-A33B-8CC3EDE622A8@chinaunicom.cn> <550d1375e15941199e23f3d7a309cb4d@huawei.com> <CAPt1N1mXK1nsJ=1wyKm-ToqLj=+j2hXrywAyNZmE0X67ipT89g@mail.gmail.com> <73353834-0DFD-4542-95B1-06BAD1F32D41@employees.org> <D4C144D3-4227-4102-A00C-10C2CB686AAE@gmail.com> <22084.1641333602@localhost> <16560b6f48ab4eb09a01ce2c64b423bc@boeing.com> <11213.1641397599@localhost> <641ed285-38bc-0789-d5b4-cab942da756a@gmail.com> <4e185b93fe494122a05c9ac5b0bd5473@huawei.com> <cc71e169-b5a3-2a46-092d-c4a8a169e258@edgeuno.com> <6ca68999e6344e3faccc7f187b1eda9d@huawei.com> <d5337869-1d50-cb65-dfb6-a88b457d1fd1@edgeuno.com> <4920e62aa783430d905bf130e9a43739@huawei.com> <CAO42Z2yY2ET16YU=uRLVYJGuXXXxuT-Eni51+0euEVs=EVfBNQ@mail.gmail.com>
In-Reply-To: <CAO42Z2yY2ET16YU=uRLVYJGuXXXxuT-Eni51+0euEVs=EVfBNQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.192.138]
Content-Type: multipart/alternative; boundary="_000_c8d0722b122944c1ada74d81ca8bfffchuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/kIGq2PQ-fL6ynumzCFHm-pIEowk>
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 19 Jan 2022 09:35:49 -0000

Hi Mark,
This is a good argument that ULA filtering is already activated by default on all interfaces. Hence, ULA is more secure for the closed domain.
Indeed, a Firewall is more secure because everything is “deny” by default. It is considered a big part of Firewall security.
The discussion about DDoS or other security problems (for example, all other types of attacks) could be much longer in this case - your list is not full.

But is it really the case?

Is this a mistake that people are trying to add “ULA deny” to the list of Martian’s deny?
https://6session.wordpress.com/2009/04/08/ipv6-martian-and-bogon-filters/
Why they are doing it for routers? You said that it is already there.

I have found a few references of different vendors that “ULAs are treated as regular global addresses. The router configuration filters ULA prefixes to prevent them from appearing in the public domain”.

I have found a discussion that ULA is good because one does not need to change the manual filter compared to the case of dynamic PA GUA
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula-usage-recommendations

Good comment about ULA not traversing many internet hops: (yet again, assuming someone in the path cares at least a bit about security)
https://blog.ipspace.net/2013/11/dont-use-ula-addresses-in-service.html

The administrator will configure the router ACLs to restrict IP addresses that contain any Unique Local Unicast addresses
https://www.stigviewer.com/stig/perimeter_router_juniper/2018-11-28/finding/V-14703

It is evident, that everybody assumes that ULA filtering is manual. It is difficult to search for a black cat in the black room.
Hence, could you reference the particular router that has “deny ULA” on some or all interfaces by default? (probably FC::)
Because in this case vendor should have a reminder not to forget to add a separate permit for the situation when ULA is needed (with probably a longer mask).
You may know the router that has put ULA in default deny. But it is very expensive for other people to find it.
I strongly suspect that the majority of routers have a default “permit” for ULA.

Hence, again: if one needs to filter infrastructure prefix manually then no advantage for ULA against GUA.
The same human mistake is the same probable.
ULA is good only because one does not need to go to RIR. It is not applicable for Carriers.

Eduard
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark Smith
Sent: Wednesday, January 19, 2022 7:17 AM
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
Cc: IPv6 Ops WG <v6ops@ietf.org>; Fernando Gont <fernando.gont=40edgeuno.com@dmarc.ietf.org>; 6man WG <ipv6@ietf.org>
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...


On Wed, 19 Jan 2022, 00:11 Vasilenko Eduard, <vasilenko.eduard=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote:
Hi Fernando,
Sorry, I do not understand why the filtering of 2 IPv6 prefixes has any difference.
Mask would be probably different for GUA (that Carrier devoted for infrastructure) and ULA (always /48),
but mask looks like not a problem.
The number of filters is the same (by the number of ports).
Why ULA segregation is better for Carrier? The Special GUA prefix looks the same effective.

It isn't.

ULAs aren't reachable from the Internet, that's they're default nature. Use ULAs for internal only infrastructure services, then they're Internet DDoS proof by default.

As RFC5505 says, "what can be configured can be misconfigured".

Filtering GUAs is trying to take away default Internet reachability, and there is room for misconfiguration.

With ULA addressing there is no default Internet reachability in the first place, and no configuration required to take away something that never existed.

We're about to use ULA addressing been our BNGs and DHCPv6 servers for the DHCPv6 traffic so the DHCPv6 service can't be DDoS'd from the Internet. We're also going to put in 2000::/3 only DA filters on customers so they can't DDoS them either (less of a risk because of the customers' vested interest in the service being available, however simple to do, so may as well.)

Everything doesn't have to be on the Internet just because you have enough address space to easily do so.

Regards,
Mark.


IMHO:
- the carrier has no problem reserving a special GUA prefix for infrastructure
- no difference for carrier what prefix to filter on the perimeter (if it is needed in principle).

Hence, I am questioning the only claimed advantage of ULA for Carrier's infrastructure.
For disadvantages, I have presented the list before.

ULA has an advantage for small entities that do not want to deal with RIR. These are not Carrier!
Eduard
-----Original Message-----
From: Fernando Gont [mailto:fernando.gont<mailto:fernando.gont>=40edgeuno.com@dmarc.ietf.org<mailto:40edgeuno.com@dmarc.ietf.org>]
Sent: Tuesday, January 18, 2022 2:38 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>; 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org>>
Cc: IPv6 Ops WG <v6ops@ietf.org<mailto:v6ops@ietf.org>>
Subject: Re: [v6ops] Possible issue with source address selection for ULAs...

Hi, Eduard,

On 18/1/22 08:24, Vasilenko Eduard wrote:
> I did not say about depreciation. For sure not.

What I mean is that there seems to be a group of people being very vocal about how bad ULAs are (which is probably the reason why we never got guidance on ULAs). But my take is that if they are so bad, they should be deprecated. But if they are not, guidance should be provided.


> ULA is good when a small company does not want to deal with RIR (it is not about big carriers).

And probably also good if you need/want stable addressing within your home network.


> ULA+NPT is the only currently working mechanism for small businesses to get redundancy from 2 PA Carriers.
> The context was about big Carrier infrastructure, not Enterprise, not Home network.

Sorry, I missed the context.  That said, as noted, it may be of use in cloud infrastructure.



> Fernando,
> Could you elaborate a bit more why in an attempt to emulate closed
> domain

That's exactly the point: when you use ULAs for certain services (say, some admin interfaces), you somewhat declare the part of a closed domain. And that's another layer of protection -- e.g., you're filters failed for some reason, but since you;re using GUAs, you are not fully exposed to the 'net.

Thanks,
--
Fernando Gont
Director of Information Security
EdgeUno
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531




“This communication is the property of EdgeUno or one of its group companies and/or affiliates. This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and if you are not the intended recipient be aware that any non-explicitly authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, and will be considered a criminal offense. Please notify legal@edgeuno.com<mailto:legal@edgeuno.com> about the unintended receipt of this electronic message and delete it.”
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------