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

Mark Smith <markzzzsmith@gmail.com> Wed, 19 January 2022 20:59 UTC

Return-Path: <markzzzsmith@gmail.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 2507A3A1BAE; Wed, 19 Jan 2022 12:59:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.182
X-Spam-Level:
X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.781, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5KT_dFI_eFl0; Wed, 19 Jan 2022 12:58:57 -0800 (PST)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72303A1BAF; Wed, 19 Jan 2022 12:58:57 -0800 (PST)
Received: by mail-il1-x12b.google.com with SMTP id i14so3285975ila.11; Wed, 19 Jan 2022 12:58:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5jDpvT5jZp6NUj5dyZDc/xFQJjRr/Q112CCCijkSx+Q=; b=hjdRrVMAOx1fml/X/QKtWIeLeSyi3nXfWp1+IDylOnpBlJ34chmJqZh0a0OhEzN9HT zhz6E1z/NAdZyaONiQ8kx6dy9n28Z5Ik2Pc9WxduTGUd7uoK5TwaLko5FTzvS0c7Jphi vqRS6a8m+8zEHtnBm5jMuxzvJOhfczIvubw2bbFrLmPifxnJgFles7wlYcGoI3NsyUDJ TI/N6bGR7SFWLiWRmiz3b9yfMB597rtoCt6cNIA2JVqYgR2NWJL2HfuZi/KiYqO5S0kR 5lyuNEg44N+W0GdLi/aKdTcVB87MSQJ79FZE+8WTN4n+UMnxqR9/KkwklEAwVuxM7AK0 cEdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5jDpvT5jZp6NUj5dyZDc/xFQJjRr/Q112CCCijkSx+Q=; b=15JEHgR5MOgpQwZJwoWK7FafocEHFBIq3Z5BLP+V1NVLGsT3El47obeAseh3LjVZWK iiq6eJiY8QVQjz4y4TBpFhSEWoREzTUZNelvs+ns9XyqVOHSnfFRPmruIu6ggDpeZqO1 dvPprEZibUBrFBbF0SMXO20OBxG10TVQOuhzpvpHqo3tsDs77D6F7mSzYmBimoyVY8NF 8pClOAGUJkNbg6jnPrSzSnrsCicZD4PEVWYiZbDzqy1nqHVvTeMlVzhtYdd8AL7B1u2o UsR/Q3Zy6xrHZGdjEbxdvUbPyJJpxJjH9OhIwCkGFjMx8AYcJKGImFt6rnaAkUQwWXUq UAjA==
X-Gm-Message-State: AOAM532VUsFgJLx3FIAEObXSGLc+ZJsWDBIGoXTm+D34+fuhV5WW6x9o 6yD0i+/f/icm74cjJLh6SZYpAIDx8vXHw53YiuOEo/D2
X-Google-Smtp-Source: ABdhPJxakM6uCLyh3CrBSGncDhoCpf3QwCQaoEDW45Fd08FRDZCnEV07kbLMdALKsQDUkmXSaavwvDvAIoN07EMb34c=
X-Received: by 2002:a05:6e02:1102:: with SMTP id u2mr16269740ilk.210.1642625935334; Wed, 19 Jan 2022 12:58:55 -0800 (PST)
MIME-Version: 1.0
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> <c8d0722b122944c1ada74d81ca8bfffc@huawei.com>
In-Reply-To: <c8d0722b122944c1ada74d81ca8bfffc@huawei.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 20 Jan 2022 07:58:29 +1100
Message-ID: <CAO42Z2y7MPFbu8xtrjKRciX9RaqBTtWQ=SyeZ9rQEhQOhOmi_g@mail.gmail.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: IPv6 Ops WG <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/62iR2ddN-iXTy-VM23yR5THsvgc>
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 20:59:06 -0000

Hi Eduard,

On Wed, 19 Jan 2022 at 20:35, Vasilenko Eduard
<vasilenko.eduard@huawei.com> wrote:
>
> 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.
>

All I have to do to disprove your argument that ULAs aren't useful for
carriers is provide a use case where they are. I have done that.

Which is the better operational situation, providing highest service
robustness and reliability:

- receive DDoS traffic from the Internet to a GUA address on an
infrastructure service, and then have to configure filters to drop it

- not receive DDoS traffic from the Internet to a ULA address on an
infrastructure service in the first place, because the Internet by its
nature doesn't route the ULA address space.

Erasmus answered this question 500 years ago - prevention is better than cure.

>
>
> But is it really the case?
>

Yes.

>
>
> 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 did not say it was already there, although RFC4193 actually requires
it, see 4.1.

I said that ULAs aren't intended to be routed over the Internet. The
default nature of the Internet (as in the default nature of the
majority of ASes that make up the Internet) is not to route ULAs,
either the prefixes or packets with them as SAs and DAs. This is
because many network operators filter routes and also filter packets.
They're not trying to actively make ULAs work over the Internet,
unlike the GUA space.

Most network operators know that vendors don't always implement what
they should, so we put in place things like martin and bogon filters
against route announcements. That's far easier to do with IPv6 -
permit  route announcements in 2000::/3, drop everything else.

>
> 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.
>

You forgot, "in my opinion".

I work for a carrier (and have worked for a number of them), ULAs are
useful to us for the reasons explained. (Many carriers have used
RFC1918s for internal only services, so this is far from a new idea).

Regards,
Mark.

>
>
> 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> 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=40edgeuno.com@dmarc.ietf.org]
> Sent: Tuesday, January 18, 2022 2:38 PM
> To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; 6man WG <ipv6@ietf.org>
> Cc: IPv6 Ops WG <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 about the unintended receipt of this electronic message and delete it.”
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------