Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-16.txt

Job Snijders <> Tue, 29 August 2023 18:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF70CC15270B for <>; Tue, 29 Aug 2023 11:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 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_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aieDFXJFAQZp for <>; Tue, 29 Aug 2023 11:26:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::636]) (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 (Postfix) with ESMTPS id 1E958C15257C for <>; Tue, 29 Aug 2023 11:26:14 -0700 (PDT)
Received: by with SMTP id a640c23a62f3a-997c4107d62so610609166b.0 for <>; Tue, 29 Aug 2023 11:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1693333573; x=1693938373; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=WstdtXiNomuWhncIrtXkeQbaZjQ1g5T7eeoXRx6phe8=; b=ri8QEe5jYABPmgjEhG0G0gWaSonV/9DEBsMNnyqsdAaA97gON8E4Gvqsn/Uz5xQtme LRUx3NiydnMGbGdJ/tcQCEkhjcks9olKxNl/YAElSmIj7L7VkESzdnwHQ4n9QuticMPm xtK1lDXX787BgmsvqLC5AQ5HCujbKe36lYApY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1693333573; x=1693938373; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WstdtXiNomuWhncIrtXkeQbaZjQ1g5T7eeoXRx6phe8=; b=V4TuM7bYAenTBkRxOglG4YABRd+qvB5ieVBjgU/Dy1d1pqaNaOibk8niG+ewhjtnQb 3G4HJV6gqQ3V0BU9z2KWhoOBILrw6jiH2mvcq9hVDDCKTM16ULx7lgmP5y6l6f0z9TnO 0xl4YTfPvt3gAoC+RadGAnUU9FNdCdLD9P8Ee+epO31HB+DanMTMnLYVTiznvV9VEDC7 BIIxR3ns3C801SD2qAD1B5nw0wGl8H0fG8eMaGComO530SuyUvrq/B6alaDk3lTjRH3r CYkepTyyX3m0ZSH6foSTRFPGp3AOtAxBKjGAAwHiyLG4MDkCplN4aJr2khbvTTuoEyKp piYw==
X-Gm-Message-State: AOJu0YzjHgNyFyQhkLV+USZYO/4c61GffwcmwRy7A2eKWgSpMKOxfR/a Pf5Crq+ceFq81Q4bYoyOJRMpRw==
X-Google-Smtp-Source: AGHT+IFzCTUNfpBXEqYrDrnKMPqJO0VrkTqRt/8tAfMcRwMjQbFjXtbN9Kjjsk2QqHULqHRwwupfTQ==
X-Received: by 2002:a17:906:5190:b0:9a1:c4ba:c04c with SMTP id y16-20020a170906519000b009a1c4bac04cmr16059965ejk.31.1693333573032; Tue, 29 Aug 2023 11:26:13 -0700 (PDT)
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by with ESMTPSA id b22-20020a170906039600b0099c53c4407dsm6228584eja.78.2023. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Aug 2023 11:26:12 -0700 (PDT)
Date: Tue, 29 Aug 2023 20:26:11 +0200
From: Job Snijders <>
To: Nimrod Levy <>
Cc: "Sriram, Kotikalapudi (Fed)" <>, "" <>, "" <>
Message-ID: <ZO44QxWd6KBJyGrd@snel>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-16.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Aug 2023 18:26:19 -0000

On Tue, Aug 29, 2023 at 02:10:07PM -0400, Nimrod Levy wrote:
> On Tue, Aug 29, 2023 at 11:41 AM Sriram, Kotikalapudi (Fed)
> <> wrote:
> >
> > (2) Do not include ASPA path verification in IBGP either.
> > Reasons: Performing ASPA path verification and rejection of routes with
> > Invalid AS path at eBGP ingress is sufficient. The AS is expected to
> > maintain a consistent view of RPKI data across all its border routers.
> I agree that it should be sufficient to enforce validation on eBGP, but in
> practice this is not always possible.
> Adding validation on certain iBGP sessions (on RRs for example) can add
> security.
> Understanding that this does leave some gaps, this is still a better
> scenario than not enforcing validation at all.
> What problem do we solve by adding this restriction from validating on iBGP?

It isn't so much "adding a restriction", but more "deliberately not
specifying how to do something".

In order to be able to do ASPA validation on IBGP, this working group
would need to specify/standardize a means to signal (via IBGP) the exact
relationship between the far-end ASBR node and the remote EBGP peer.

    (reminder: in order to be able to perform the ASPA verification
     algorithm, the device at hand needs as input parameter the role of
     the remote EBGP peer - one of customer, provider, lateral peer,
     Route Server RS-client, or mutual-transit).

This working group, or IDR, in the future can take up the work to dot
all i's and cross all t's in order to standardize how to do ASPA
verification on IBGP, but I deem it best to first focus on EBGP, and
potentially later on specify how it all could work for IBGP.

This version of the draft does not close the door on future work to make
ASPA verification possible on IBGP.

Kind regards,