[Sidrops] Re: WG Adoption call for draft-sriram-sidrops-spl-verification - ENDS 06/03/2024 (June 3 2024)

Ties de Kock <tdekock@ripe.net> Mon, 03 June 2024 07:44 UTC

Return-Path: <tdekock@ripe.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5052C15155C for <sidrops@ietfa.amsl.com>; Mon, 3 Jun 2024 00:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net
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 j8nMdYGSDYej for <sidrops@ietfa.amsl.com>; Mon, 3 Jun 2024 00:44:03 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FB3C14F5E6 for <sidrops@ietf.org>; Mon, 3 Jun 2024 00:44:03 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a63359aaacaso505913366b.1 for <sidrops@ietf.org>; Mon, 03 Jun 2024 00:44:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripe.net; s=google1; t=1717400641; x=1718005441; darn=ietf.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4sueeNaCcCrBTMeG3QTI55MfGqop2145Zl2XH+uwsro=; b=Q0nfYCe6sB+QIECOcHgTbyUYtjcEvEx88cxWZiMHpHyWFNMmxy/KI1iIxq64VO/O/D DaR7T2krqwOabsPyfum1JYiby1hTMe0jg5WxypYTTA1ZaXZguzTOhcKrDY+EiGF0JkU2 7ubtp0nWcJUVkmQ/FD4WvQFbFjV19D++BwwMYTb0g/7W+zXmh0TtrTjAn7WV+7jhaHp1 WmuAAvDxoM1vEnTs1o5HdJshgc0eVjTldfjPdz+yY6McTFeMY9PuMOxaGEDy4zABo+Ai wfxU3JnzXgC2n3mdzUSU7Pq5qeEZqEFZzJ4hUailFMxKCBVbTEmZutZTFy2ZX16RIlRY lCXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717400641; x=1718005441; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4sueeNaCcCrBTMeG3QTI55MfGqop2145Zl2XH+uwsro=; b=KqNG0tSHRmXVoxqQOr8Mph7Yd3j6C653oZ75rdDm+Io4i8NhzqbT3p+wUrlDGIt74W qnavTXW6U+rDCOuGlki9RzmHugUurZWYqpcbJM+BGh5WgWUzXTPqHYXDt7MLyHLP1K/w YdMiR6qWLIrIa+SHWUwR2clzvTB93dkk9u0Zhbj2Vusr/Sz+vK9zTKBhZZyGjXU8KNY3 Y937Qf3O9cUetnIGT0FA3REhihRyf+C+0BzEm9c0GCc6l7/Rlb48nRoEROAyIEXfPQde 5q6EmKXQGKls6Br66HI4Iy05ZiHdnUT72DJ5W5eSIe8alLGogsAHp3loqz4//gAyU73Y rzmA==
X-Forwarded-Encrypted: i=1; AJvYcCWjkEicP054baArg5VWoczd0E4f8JumFtzVdhOLX3Dx9OsbU0KFRxamA8ZPejhxfOXcN9ArS0n6H/nqvkYM2lKf
X-Gm-Message-State: AOJu0Yzu3dTJbpvyvSQb+8BuhkjT8pho7Imz1ry4Bflvhyr2RQpmj2r4 pWCoRJy6enIRE9pHM3GKhqDQ6QAWZdoa5lRWp4o5wyIsVNTRrtE4tOT+fpRxo0AGTXLLlNeUa1H VlILb0Q6dXGqoTVqMgcyjQex66q8K+Owo9OTmtzpMDW3t9CojdDg=
X-Google-Smtp-Source: AGHT+IHADdKUPa27/+YUGlFjsmALi/dCKUJOj8269E/LzO2IQN6jj1wWD/D3W1ebBNTBdEpdoUcQpfGIp0QbFiqFE0s=
X-Received: by 2002:a17:906:3ec8:b0:a59:9a28:f1bd with SMTP id a640c23a62f3a-a6821f53499mr586574766b.66.1717400641386; Mon, 03 Jun 2024 00:44:01 -0700 (PDT)
MIME-Version: 1.0
References: <SA1PR09MB8142978FC5DFD478E40B54D884F12@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB814286463D99E5327EEDF3B184F12@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB8142749B4309DCBDFFEED34784F12@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB814214B4946E15E7296570E984F12@SA1PR09MB8142.namprd09.prod.outlook.com> <F62EB815-FEE2-45EB-8B67-FC93C3667619@ripe.net> <5752698325164c6aafffc131450b2859@huawei.com>
In-Reply-To: <5752698325164c6aafffc131450b2859@huawei.com>
From: Ties de Kock <tdekock@ripe.net>
Date: Mon, 03 Jun 2024 09:43:50 +0200
Message-ID: <CANPYmgiX10TVGvWGKTaQqyZ_wMA=9ZZ_VS5rZ1-xUVau1+jvZQ@mail.gmail.com>
To: "draft-sriram-sidrops-spl-verification@ietf.org" <draft-sriram-sidrops-spl-verification@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: CBEJHZMQNW7JPKMGF2FLOYUIF65IFTDT
X-Message-ID-Hash: CBEJHZMQNW7JPKMGF2FLOYUIF65IFTDT
X-MailFrom: tdekock@ripe.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-sidrops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Sidrops] Re: WG Adoption call for draft-sriram-sidrops-spl-verification - ENDS 06/03/2024 (June 3 2024)
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/7H5UFp4IqF6QTH78ckxgLRkBln8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Owner: <mailto:sidrops-owner@ietf.org>
List-Post: <mailto:sidrops@ietf.org>
List-Subscribe: <mailto:sidrops-join@ietf.org>
List-Unsubscribe: <mailto:sidrops-leave@ietf.org>

I have read the draft and support adoption.

I think the use cases and deployment considerations for SPL need more
discussion.
SPL is the minimal proposal for this problem space so far. I feel that adopting
this document is the way to continue this discussion.

We are introducing multiple objects that can serve the same goal. SPLs overlaps
with both ROAs and ASPAs. To me, this is a downside, since each partial
mitigation makes perfect deployment of any other mitigation less likely.

Threats 1 and 2 will help prevent misattribution (and add non-repudiation for
legitimate announcements) for networks that actively participate in the
internet. That is a real benefit.

Scenario 5 slightly improves over an empty provider set for ASPA and will make
reclaiming unused ASNs easier.

However, I have questions about the other scenarios mentioned.

As I understand it, scenario 3 is mitigated if the originating AS has a ROA for
the original announcements.

Scenario 4 describes how minimal SPLs improve the situation where overly
permissive ROAs exist (or not all space is announced). I think that the
underlying assumption that operators will maintain a strict SPL while the ROAs
are overly permissive is unrealistic (e.g. it is likely operators would create
permissive SPLs). Section 7.4 also assumes the permissive pre-positioned ROA+SPL
for DDOS mitigation, contradicting this premise.

Minor comments:
  * Section 3: "For a given asID, ... does not originate any prefixes": This
    needs to be described on the level of validated SPL payload (which
is the union over
    1..n SPLs for an AS).

    The behaviour in the non-recommended case (multiple SPL) needs to
be unambiguously defined.

  * Section 6: It is implicit that SPL-ROV is valid for the described effects
    to exist. I would clarify this in the text.

Kind regards,
Ties

On Sat, 1 Jun 2024 at 12:51, gengnan
<gengnan=40huawei.com@dmarc.ietf.org> wrote:
>
> Hi,
>
> > I think new semantics are generally best done as separate, explicit, complementary types.
> Agreed.
>
> A new object for DSR prefixes is an optional solution. BAR-SAV can use BGP, ASPA, ROA, and DSR data to generate SAV rules.
>
> Another option is to use SPL to explicitly state DSR prefixes.
>
> "Implicit method" may induce some security risks and operational complexity.
>
> Best,
> Nan
>
> -----Original Message-----
> From: Tim Bruijnzeels <tbruijnzeels@ripe.net>
> Sent: Wednesday, May 29, 2024 4:14 PM
> To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>
> Cc: Amir Herzberg <amir.lists@gmail.com>; sidrops@ietf.org; draft-sriram-sidrops-spl-verification@ietf.org
> Subject: [Sidrops] Re: WG Adoption call for draft-sriram-sidrops-spl-verification - ENDS 06/03/2024 (June 3 2024)
>
>
> Hi,
>
> > On 28 May 2024, at 22:37, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org> wrote:
> >
> >>
> >> However, is SPV the best mechanism to deal with this?
> >> I think a better alternative would be an extension to the ROA
> >> mechanism. This extension will define a `conditional ROA'.
> >> This conditional ROA will also contain the result of a hash function
> >> h(x) over some random x. You can use the conditional ROA in two ways:
> >>
> >> - without the preimage x: such ROA will not make announcements for AS
> >> 7 and 1.2.3/24 valid. However, it could be used to allow DSR , i.e.,
> >> it would be considered for BAR-SAV filtering.
> >>
> >> - with the preimage x, provided as a transitive BGP attribute or otherwise:
> >> this turns the conditional ROA into regular ROA.
> >>
> >
> > Your proposal involves modifying the ROA to add a new field. Perhaps it can be taken up in the future by the WG as new work.  I'll be happy to discuss its the pros and cons off-list.
>
> I think discussion is good, but generally speaking I am not keen on changing the ROA format. We have a lot of deployment, CA implementations and UIs/APIs, RPs, best practices, documentation, etc.
>
> I think new semantics are generally best done as separate, explicit, complementary types. This way it’s also clear that the signer explicitly opted in to making a statement - rather than going with an implicit default which is what we might end up with if we had a next version ROA with optional extra bits.
>
> I support adopting SPL, my feeling is that some more discussion is needed before it’s done, but adopting it so we can have that discussion makes sense to me.
>
> Tim
> _______________________________________________
> Sidrops mailing list -- sidrops@ietf.org To unsubscribe send an email to sidrops-leave@ietf.org
> _______________________________________________
> Sidrops mailing list -- sidrops@ietf.org
> To unsubscribe send an email to sidrops-leave@ietf.org