Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

Martin Hoffmann <martin@nlnetlabs.nl> Fri, 28 April 2023 08:09 UTC

Return-Path: <martin@nlnetlabs.nl>
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 33C3CC151535; Fri, 28 Apr 2023 01:09:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=nlnetlabs.nl
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 3_Z2bk7Dfi75; Fri, 28 Apr 2023 01:08:57 -0700 (PDT)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a10:de80:1:4091:b9e9:2214:0:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 B3D45C151543; Fri, 28 Apr 2023 01:08:56 -0700 (PDT)
Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 4Q74xd6QvNz2Y; Fri, 28 Apr 2023 08:08:53 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4Q74xd4fMczQ5; Fri, 28 Apr 2023 08:08:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1682669333; bh=jSp1lyaVqWs0i3tNff4iyVPxC7ePPIvjyqghJ3nKPMk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fMc41dBbQmKJjNjEAMIvIP0EjD2Y3fMhHc2LgwAWUDvPhOnMixKcvT9ex1A4AT6am a/x28MFFO2YtS2zCPZpkzKJjVFfHLVEq2IuIOu7yUnqclw81OvJ4OaOvsSg2REf8nj GNV/n7xnQtSRm4fQLRTlRLK/h7+SFpA7cH8tTVCURir0Z3x74Hn1m3U611gHPVy2zi NR74hqjM4wTsDL5RCkyhJGuzayzyss+jF0wXF/6Rk052ePwkiBDmrBf2PqDkr/Sw7b c7ryYFh1q8ush/tqcHOQH8KB/3WhSgQGZyi3EK5S5Gp7epVOGgHOs+oGCuT96IweEO zhXlyekdzHMaQ==
Date: Fri, 28 Apr 2023 10:08:55 +0200
X-Soverin-Authenticated: true
From: Martin Hoffmann <martin@nlnetlabs.nl>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
Cc: "draft-ietf-sidrops-8210bis@ietf.org" <draft-ietf-sidrops-8210bis@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>, Claudio Jeker <cjeker@diehard.n-r-g.com>
Message-ID: <20230428100855.3450881e@glaurung.nlnetlabs.nl>
In-Reply-To: <SA1PR09MB81427668A874A3EEFDE61DAE846A9@SA1PR09MB8142.namprd09.prod.outlook.com>
References: <SA1PR09MB814241245D01E81BADE3ED0884CF9@SA1PR09MB8142.namprd09.prod.outlook.com> <ZBGqSVL9sSqnAiJc@diehard.n-r-g.com> <SA1PR09MB8142E9F71F250B83062C724884869@SA1PR09MB8142.namprd09.prod.outlook.com> <ZCGcYHJ9PyrjgR+V@diehard.n-r-g.com> <SA1PR09MB8142EA7F33880679E9B509D384889@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB81426E1BB66D6DF31860F26984889@SA1PR09MB8142.namprd09.prod.outlook.com> <ed0146b09da346b2b48cb9701240926c@akamai.com> <SA1PR09MB81427D28EF661F9DAB05FB9B84889@SA1PR09MB8142.namprd09.prod.outlook.com> <c62da49ce2a142999260371a0af7b673@akamai.com> <SA1PR09MB81428936A8B2BC30C04C4B2684629@SA1PR09MB8142.namprd09.prod.outlook.com> <88D8A314-0D17-4EA7-9E33-424021AF0FFF@vigilsec.com> <SA1PR09MB814232A57F80E8B92637ABF684639@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB8142A3F0D8E30F4F154863A084639@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB81427668A874A3EEFDE61DAE846A9@SA1PR09MB8142.namprd09.prod.outlook.com>
Organization: NLnet Labs
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/d70WkRs42PPbTsJFA0EjS2K_YgI>
Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Apr 2023 08:09:01 -0000

Hi Sriram!

Sriram, Kotikalapudi (Fed) wrote:
> Hi Martin,
> 
> >Now, from the split into two documents, I conclude that as someone
> >implementing an RPKI relying party software, you aren’t expected to
> >read the verfication draft -- and will likely miss this subtlety. So,
> >presumably, the conversion rules should be in the profile draft.  
> 
> We'll make sure that it is clear in the verification draft, and 
> also, some sections related to ASPA registration and VAP-SPAS 
> creation will be repeated in the profile draft so that 
> the latter is self-contained.
> 
> Regarding augmentation of VAP-SPAS with AS 0 SPAS for
> the case of a CAS that has neglected to include one of the
> AFIs in the ASPA, that is a thing that concerns the 
> verification algorithm. Keeping that in mind, do you feel that
> it might be OK if we simply take care of it on the router side
> after the RTR ASPA PDUs have been received? Details follow.

I don’t think that’s a good solution. The RTR payload format is as it
is now to make things as easy as possible for routers that implement
the most simple data structure. The RP software has to do merging of
multiple ASPAs, anyway, so it is quite easy for it to convert an empty
set into an AS0-only set.

My observation was mostly about the fact that this is (now: was) rather
quite hidden in the somewhat complex document structure. Calling it out
in the profile draft should be good enough for RP implementers to at
least be aware of something going on and having to read up on it some
more.

> If not, then we need to talk about changing the processing
> on the RTR cache server side or changing the RTR ASPA PDU format
> (like what Claudio has been talking about). That would call
> for a change in 8210-bis. 

While I think that redesigning the ASPA RTR PDU would be a good idea --
if there’s always one PDU per address family they might as well be
merged into one --, that draft is already in the publishing queue and
there is at least one released real world implementations (and someone
would need to yell “stop” real soon to avoid a second one), so I
suspect that ship has sailed.

  -- Martin