From: "Lubashev, Igor" <ilubashe@akamai.com>
To: "Sriram, Kotikalapudi (Fed)"
	<kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>,
        "sidrops@ietf.org"
	<sidrops@ietf.org>
Thread-Topic: New Version Notification for
 draft-sriram-sidrops-spl-verification-00.txt
Thread-Index: AQHaeH6vmHgmOBuqakG5E4p8x4Z0crE8DLjAgGZ0bfA=
Date: Tue, 21 May 2024 20:12:51 +0000
Message-ID: <acec900085d74c048fe42f7be30d6fdd@akamai.com>
References: <171068884034.30156.2037237149778011860@ietfa.amsl.com>
 <SA1PR09MB81425CD1E67522C46F27C18A842E2@SA1PR09MB8142.namprd09.prod.outlook.com>
In-Reply-To: 
 <SA1PR09MB81425CD1E67522C46F27C18A842E2@SA1PR09MB8142.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID-Hash: NNPCBX5XAKQYPAN3MBLEIZAX7HYMORAY
Precedence: list
Subject: =?utf-8?q?=5BSidrops=5D_Re=3A_New_Version_Notification_for_draft-sriram-sidr?=
 =?utf-8?q?ops-spl-verification-00=2Etxt?=

Sriram, I am trying to wrap my head around the set of problems SPL wants to=
 solve that are not solved by ROA and ASPA.

I am focusing on section "6. BGP Security Threats Addressed by SPL-ROV".

Threats 1, 2, and 5 are "If someone is forging some announcement, do not le=
t them blame it on me".  Is this a big concern?  Protecting against threats=
 1 and 5 does not help protect any packets from being misrouted/hijacked (a=
nd no IP space is being hijacked in threat 2 to begin with), since the mali=
cious AS can pick any other ASN as the origin.  It is just about not lettin=
g my AS show up as the "origin", right?

Threats 2 and 4 can be mostly solved by ASPA (but only if providers also ma=
intain ASPA entries, transitively, so a tall order).

Threat 3 can be solved by ROA.  It is really an AS protecting against its o=
wn mistakes.

I see threat 4 as the real concern here without a widespread ASPA adoption.=
  It is especially important if we are recommending adding ASNs to ROA for =
direct server return use cases for SAV purposes (for algorithms like BAR-SA=
V).  Of course, we can be recommending using ASPA for these cases instead o=
f ROA -- BAR-SAV would be happy.

-Igor

-----Original Message-----
From: Sidrops <sidrops-bounces@ietf.org> On Behalf Of Sriram, Kotikalapudi =
(Fed)
Sent: Sunday, March 17, 2024 11:39 AM
To: sidrops@ietf.org
Cc: sidrops-chairs@ietf.org
Subject: Re: [Sidrops] New Version Notification for draft-sriram-sidrops-sp=
l-verification-00.txt

A new draft on "Signed Prefix List (SPL) Based Route Origin Verification an=
d Operational Considerations" was just uploaded.
Please see abstract and links below. Comments welcome.

Sriram

-----Original Message-----
From: internet-drafts@ietf.org <internet-drafts@ietf.org>=20
Sent: Sunday, March 17, 2024 11:21 AM
To: Montgomery, Douglas C. (Fed) <dougm@nist.gov>; Job Snijders <job@fastly=
.com>; Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>
Subject: New Version Notification for draft-sriram-sidrops-spl-verification=
-00.txt

A new version of Internet-Draft draft-sriram-sidrops-spl-verification-00.tx=
t
has been successfully submitted by Kotikalapudi Sriram and posted to the IE=
TF repository.

Name:     draft-sriram-sidrops-spl-verification
Revision: 00
Title:    Signed Prefix List (SPL) Based Route Origin Verification and Oper=
ational Considerations
Date:     2024-03-17
Group:    Individual Submission
Pages:    10
URL:      https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft=
-sriram-sidrops-spl-verification-00.txt__;!!GjvTz_vk!Rqtz9SFiM_7mFFSNrFAltM=
pe8V9CeiBq463vLSTOja1rcNN6FQqy8hQH25vCnkMuBR5qCkR2F1rptUyuL65O5giZTrLKXQ$ =
=20
Status:   https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draf=
t-sriram-sidrops-spl-verification/__;!!GjvTz_vk!Rqtz9SFiM_7mFFSNrFAltMpe8V9=
CeiBq463vLSTOja1rcNN6FQqy8hQH25vCnkMuBR5qCkR2F1rptUyuL65O5gjYaBU4Og$ =20
HTML:     https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft=
-sriram-sidrops-spl-verification-00.html__;!!GjvTz_vk!Rqtz9SFiM_7mFFSNrFAlt=
Mpe8V9CeiBq463vLSTOja1rcNN6FQqy8hQH25vCnkMuBR5qCkR2F1rptUyuL65O5gjvbPPYCA$ =
=20
HTMLized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html=
/draft-sriram-sidrops-spl-verification__;!!GjvTz_vk!Rqtz9SFiM_7mFFSNrFAltMp=
e8V9CeiBq463vLSTOja1rcNN6FQqy8hQH25vCnkMuBR5qCkR2F1rptUyuL65O5ggpbYIl9A$ =20

Abstract:

   The Signed Prefix List (SPL) is an RPKI object that attests to the
   complete list of prefixes which an Autonomous System (AS) may
   originate in the Border Gateway Protocol (BGP).  This document
   specifies an SPL-based Route Origin Verification (SPL-ROV)
   methodology and combines it with the ROA-based ROV (ROA-ROV) to
   facilitate an integrated mitigation strategy for prefix hijacks and
   AS forgery.  The document also explains the various BGP security
   threats that SPL can help address and provides operational
   considerations associated with SPL-ROV deployment.


The IETF Secretariat


_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sidrops__=
;!!GjvTz_vk!Rqtz9SFiM_7mFFSNrFAltMpe8V9CeiBq463vLSTOja1rcNN6FQqy8hQH25vCnkM=
uBR5qCkR2F1rptUyuL65O5gj4uCkJWQ$=20