Re: [Sidrops] Which 8210-bis error code should be used?

On Wed, Jun 07, 2023 at 03:02:25PM +0200, Tim Bruijnzeels wrote:
> Hi,
> 
> I have been trying to think through how dropping the AFI limit could
> negatively impact ASPA security. I.e. do I need the ability to express
> different authorisations here?

Please remember ASPA is not a security feature. It is there to prevent
route leaks via hairpins and leaky peerings. If you want security you need
bgpsec.

> The one scenario I can think of where this could have a slight impact is
> in case of partial ASPA deployment, where one of my providers that I
> only use for one AFI (say I only do v6 with them) did not deploy ASPA,
> and all my other providers where I do IPv4 do deploy ASPA. In that
> particular corner case I would be slightly better protected against
> (long) path spoofing for my v4 space if I could set the AFI limit to v6
> for that one provider. But.. I think this really is a corner case - it
> assumes that all my other (v4) providers do ASPA - if one of them does
> not, then having the limit makes no difference.

There are a fair amount of ifs packed into this. If you have a provider
that only does one AFI that does not do ASPA...
So this is really an edge case. Also the problem is not the v6 only
peering, the problem is the missing ASPA record for that provider.

> I would probably be better off to urge my (in this case v6 only)
> provider to deploy ASPA as well. Or look for another provider that
> would.
> 
> Because in the bigger picture the cost in complexity is significant. And
> I actually expect many more issues due misconfigurations and bugs
> because of that complexity compared to what would be improved in
> security by keeping the limit.

I very much agree with this.

> Tim
> 
> 
> 
> 
> > On 7 Jun 2023, at 14:41, Yangyang Wang <wangyy=40cernet.edu.cn@dmarc.ietf.org> wrote:
> > 
> > Hi all,
> > 
> > A little opposite opinion :)
> > 
> > I support " It is here but don't use it".
> > It can make the information more accurate for edge cases or some fake link hijacks.
> > All provider ASNs are listed (just like no afiLimit), and each provider AS is listed only once and is labeled with afiLimit  (just additional attribute information, if like).  Its values MUST be 0000 for ignored (not omitted), 0001 IPv4, 0002 IPv6.  If a customer-provider appears in IPv4 and IPv6 topology, no duplicated PDUs for IPv4 and IPv6, and no need to maintain two tables.
> > It is here. How to use (or not to use) it depends on uses (implementors, operators, etc). For example,  do not process afiLimit. But if users need this information, they can use them without protocol change.
> > 
> > Yangyang
> > 
> > 
> >> -----Original Message----
> >> From: sidrops-bounces@ietf.org [mailto:sidrops-bounces@ietf.org] On
> >> Behalf Of Hollyman, Michael
> >> Sent: 2023年6月2日 1:54
> >> To: sidrops@ietf.org
> >> Cc: draft-ietf-sidrops-aspa-verification@ietf.org
> >> Subject: Re: [Sidrops] Which 8210-bis error code should be used?
> >> 
> >> I tend to agree with Claudio and Martin here. I think the afiLimit should be
> >> removed from ASPA, if possible, or it will become just like max-length: "It is
> >> here but don't use it."  There shouldn't be any inference of intent in ASPA
> >> when one is published with an AFI and another without.
> >> 
> >> It appears to me that the spirit of ASPA is to simply list the provider ASes
> >> for a CAS. Keeping that simple and by AS, not by AFI, seems to be a logical
> >> choice.
> >> 
> >> Full path control is BGPSec. ASPA is an incremental step forward in
> >> preventing leaks and some hijacks.  Simplicity of ASPA should be the key in
> >> order to gain the most acceptance and usage.
> >> 
> >> Mike
> >> 
> >> On 5/24/23, 03:39, "Sidrops on behalf of Claudio Jeker" <sidrops-
> >> bounces@ietf.org <mailto:sidrops-bounces@ietf.org> on behalf of
> >> cjeker@diehard.n-r-g.com > <mailto:cjeker@diehard.n-r-g.com>> wrote:
> >> 
> >> 
> >>> I would love to remove the optional afiLimit from ASPA.
> >>> I brought this up a few times (well before there was any
> >>> implementation of any ASPA draft) and every time the answer of some of
> >>> the authors was no (without any particular reason).
> >> 
> >> 
> >>> As one of the developers of the first RP and only BGP implementation
> >>> handling ASPA I would enjoy to remove all the code required to handle
> >>> the afiLimit. We probably control most test deployments (RP and BGP
> >>> side) and are willing to make this change.
> >> 
> >> 
> >>> --
> >>> :wq Claudio
> >> 
> >> 
> >> _______________________________________________
> >> Sidrops mailing list
> >> Sidrops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/sidrops
> > 
> > _______________________________________________
> > Sidrops mailing list
> > Sidrops@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

-- 
:wq Claudio