From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Amir Herzberg <amir.lists@gmail.com>
Thread-Topic: WG Adoption call for draft-sriram-sidrops-spl-verification -
 ENDS 06/03/2024 (June 3 2024)
Thread-Index: AQHasTnAcFP43j6AjkKmS47h4yUB6bGtEWCg
Date: Tue, 28 May 2024 20:37:31 +0000
Message-ID: 
 <SA1PR09MB814214B4946E15E7296570E984F12@SA1PR09MB8142.namprd09.prod.outlook.com>
References: 
 <SA1PR09MB8142978FC5DFD478E40B54D884F12@SA1PR09MB8142.namprd09.prod.outlook.com>
 <SA1PR09MB814286463D99E5327EEDF3B184F12@SA1PR09MB8142.namprd09.prod.outlook.com>
 <SA1PR09MB8142749B4309DCBDFFEED34784F12@SA1PR09MB8142.namprd09.prod.outlook.com>
In-Reply-To: 
 <SA1PR09MB8142749B4309DCBDFFEED34784F12@SA1PR09MB8142.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?s0Cq+T0B7YwnacVgPKmO4ZmsOSbHe1B/v6j3VOYDlfd6TOfjphNmqGqE6elv?=
 =?us-ascii?Q?mfOg9LsDj+npWsQvEMqIaagdmLqooBUGOlIxPWl9frzJrm+Vhn6ib/HI8yVJ?=
 =?us-ascii?Q?OCywP6aVHE9+LVVUC9jXR/aQbHkOzCyiauHOgvt5PmQ2cLKlODeX3TZ4+n19?=
 =?us-ascii?Q?5HxY0tAjHJryNGDg1DgMXtateRc71iCLV7eSlNNrSabzSnUr5ZZkYEWhEj2u?=
 =?us-ascii?Q?88zu2dWk1PyIvyGHmYGLyZgtvna7kQOta4Wj+Q71T4KTQ5azHIsSzwCD67OB?=
 =?us-ascii?Q?5VTyQh8zZNkb/h1ghNnQY9AmD/LTEVjG/AkP7+ASPScVxhAq6YXDTUjmERKr?=
 =?us-ascii?Q?HngeUXV0RBLbwlum+VyewqrcJZmudpOpYOmyVXUPkYvTKKf4jSHvn9DNaY7+?=
 =?us-ascii?Q?QRL9wt9Q59ELGS/iaE6p+SGig1nQVENF0JdQeiwgcNjd6jS+N7gz+MeSAoAx?=
 =?us-ascii?Q?ME4c5EvKXlM8jaUXDQw4jk0fEN8YEuQVV0UK8M3HWEEAiFbkhE09lenqIFpb?=
 =?us-ascii?Q?u9oSUQWWUGqRy2wXct6ZA8ItXDlvxOdyxIFdAJ9i8WH8QLpqyJeHp2RJrhjD?=
 =?us-ascii?Q?W/IbH0Ew1BbsbuNOpvCBfaS3SBbslFQAeB+ROpIsVZHH2ljWQ8dV4YMzCwh0?=
 =?us-ascii?Q?FieRQF7a3eaXcnX10rtfmZW+R4ueaFD1G+djbnKqeACaH19h63ryUHOYmwDr?=
 =?us-ascii?Q?uKm+s2n4piFJoEzyq4AsQwCMwKTyTG0asNk6uRFx6Ode5y0Zz+TRswnAtK36?=
 =?us-ascii?Q?XNlNXSGB8fnJBSvnMlopT1m+7kanl4O8WpbQL4pu3wIib43VpcTNgITeL0BR?=
 =?us-ascii?Q?H8E1zOlVYTr1ZpYFK8VANXbv/AW0IpxHYPog1924CrDur2EWqJjKyoGkfwke?=
 =?us-ascii?Q?3Pq5D4imbyUz7Y150ty8dazufc96Rxegey4dnyI6Sxed//98yfZyQCIlxawP?=
 =?us-ascii?Q?hw6qNLtuOkjwmowyhLcGAE2FLCgUcgQyunO61x/FKHwNshd0VXiQY6VWkTXF?=
 =?us-ascii?Q?JlbKaaKEqdsHOo6zQNx/4wvtExX046jYobhcEZyvbSpWBube5gq9+MuVzDS/?=
 =?us-ascii?Q?4u5RICquVFLtp+sFd/tD8nFKtSiJhYWiqSpB/UX3MzZod7I9rmLyI9As3JHb?=
 =?us-ascii?Q?ftZ1gMV8cd9OJOHz4Xf78O46inPWSVHkBXMmT7aK3iLeZiffKEMu/E/xPP6o?=
 =?us-ascii?Q?Y+69DUgBchlsQihvAlm6ogNJgh6h7P2E/OxMjXml5nJEjh5neOQaW9mb4kg/?=
 =?us-ascii?Q?tt+EMpn1yvv+8kVz4dLf2Get1ro3xnJxPk2pUl5sgNjOr6TIrobrBbp9DlMh?=
 =?us-ascii?Q?0fI8YVr6MiOFs0DHiN8BXAHO0++iyTLdczc56ynU3qCY+9+gYsdr6bKanafS?=
 =?us-ascii?Q?F0Nw9CJNKIhyVDJi+YG3h+BmHql/dDTm36mMpMJNZeIcoGRnOvzEoHN3q5P7?=
 =?us-ascii?Q?22B+JMQIt6jrrGcCByfuu+y5OvC2h6Ok5WM/Mu1mW7MU9G692Ua0KVRKTCTV?=
 =?us-ascii?Q?5hnqx3ExiG5BZnJck81JLeVf70Z1S2S1SVD/HOm7LzQZtbTvB/dMocxAiz0m?=
 =?us-ascii?Q?xGaiArZ1Ep9x0W7633c=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR09MB8142.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 8332c2c7-46c0-4f18-efc3-08dc7f55ff76
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2024 20:37:31.4330
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR09MB10553
Message-ID-Hash: ZSBOUNAPP6PIAIWOTW7KPIIQYNMONKZM
X-Message-ID-Hash: ZSBOUNAPP6PIAIWOTW7KPIIQYNMONKZM
X-MailFrom: kotikalapudi.sriram@nist.gov
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
CC: "sidrops@ietf.org" <sidrops@ietf.org>,
 "draft-sriram-sidrops-spl-verification@ietf.org"
 <draft-sriram-sidrops-spl-verification@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: =?utf-8?q?=5BSidrops=5D_Re=3A_WG_Adoption_call_for_draft-sriram-sidrops-spl-?=
 =?utf-8?q?verification_-_ENDS_06/03/2024_=28June_3_2024=29?=
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/sidrops/OkgnFIIp7-on8B58hvNIKNejPck>
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>

Hi Amir,

Thank you for your review and comments. My responses below.

> From: Amir Herzberg <amir.lists@gmail.com>
>
> 1. I think the draft doesn't clearly distinguish between (intentional)=20
> attacks and unintentional misconfigurations. I think that the authors=20
> really meant, mostly or always, to prevent unintentional=20
> misconfigurations, in which case, their use of the term `attack' is=20
> confusing. Changing the term should be easy.
>

I think you are right. We'll take a closer look and change 'attack' to 'ano=
maly' where it is appropriate.  I think the term 'attack' can be used when =
we talk about DoS/DDoS incidents. Also, the term "attack surface" is correc=
tly used in the context of forged-origin prefix hijacks (as you acknowledge=
d below). =20

>
> 2. An exception is the 4th reason, i.e., when a prefix owner publishes=20
> ROA for AS 7 and some prefix 1.2.3/24 but AS 7 doesn't announce 1.2.3/24.
> In this case, attacker could do origin hijack of 1.2.3/24 by=20
> announcing it with origin AS 7 (and itself as the next AS). I=20
> understand the motivation of supporting direct server return (DSR)=20
> using BAR-SAV, where we want a ROA to exist without announcing the prefix=
.

Yes, SPL helps in the DSR scenario for BAR-SAV.  Igor also observed that.
=20
> However, is SPV the best mechanism to deal with this?
> I think a better alternative would be an extension to the ROA=20
> mechanism. This extension will define a `conditional ROA'.
> This conditional ROA will also contain the result of a hash function=20
> 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.,=20
> it would be considered for BAR-SAV filtering.
>
> - with the preimage x, provided as a transitive BGP attribute or otherwis=
e:
> 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.

Sriram =20
 =20