Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <CAEGSd=CUJ9WEUAtgdbghgbCWd6xW_KLr4_pCoWAAen_j+iW-iA@mail.gmail.com>
Date: Mon, 4 May 2020 15:09:53 +0200
Cc: Job Snijders <job@sobornost.net>, Jay Borkenhagen <jayb@braeburn.org>,
 SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BC5FAFC-A5A3-4B67-82C1-C1BE90335C95@nlnetlabs.nl>
References: <87pnbrspdr.wl-morrowc@ops-netman.net>
 <24232.24434.41224.396200@oz.mt.att.com>
 <d7858280-d86f-4517-a7df-26fc64d3e7f7@www.fastmail.com>
 <12F90135-5597-490B-947F-F588C2ED3B48@nlnetlabs.nl>
 <CAEGSd=CUJ9WEUAtgdbghgbCWd6xW_KLr4_pCoWAAen_j+iW-iA@mail.gmail.com>
To: Alexander Azimov <a.e.azimov@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Aspk8cs2RpAlw1xyA8T_aV_c7CU>
Subject: Re: [Sidrops] ASPA duplicates
Precedence: list

Hi,

> On 2 May 2020, at 20:39, Alexander Azimov <a.e.azimov@gmail.com> =
wrote:
>=20
> Thank you all for comments.
>=20
> First of all, I'd like to address the reasons for that change at the =
side of RTR.
>=20
> And the comparison with ROA is important. The RTR documents don't say =
that "you MUST apply diff after receiving EOD", instead it is applied =
incrementally. So, the race in the updates for selected address space =
may invalidate the correct routes. One may say that finally, all data =
will become consistent and the router will make a proper marking. =
Unfortunately, it's not true for two reasons:
> 	=E2=80=A2 You never know when all data will arrive, there may be =
every kind of network issues between cache and router (and it's TCP =
after all);
> 	=E2=80=A2 Even if all updates finally arrives some routing =
software will keep the result of original verification. I'm not sure how =
it is covered with RFC, but I know that such implementations exist.
> As a result, we may end with hard to debug prefix propagation issues. =
These race conditions are partially addressed in the RFC8210bis by =
adding order to the ROA updates - from more specific to less specific =
routes. It solves the problem with less specifics, but issues for =
prefixes that have multiple records may still exist.
>=20
> In the ASPA, we are trying to prevent race conditions from happening. =
And the easiest way is to guarantee the atomicity of updates for each =
key-value pair. In our cases - to pack all ASPA records for the selected =
customer AS into one PDU. I hope this will make clear the motivation why =
ASPA PDU is different from what we have now for ROA. Btw, I will vote to =
update ROA too (and the update of RTR is a good time for such change, =
there is no requirement for compatibility between versions).
>=20
> The way new ASPA records are issued and the way they are received by =
RTR (rsync?) is another place for race conditions. And it seems native =
to guarantee consistency the same way - making a single ASPA object, =
thus preventing possible misconfigurations.

Ok, understood. Makes sense now.

> Now the question - what should be done if RTR cache receives multiple =
RTR records for ASPA? Let's discuss possible scenarios:
> 	=E2=80=A2 There is misfunction at the level of RPKI software =
that issued records;
> If we face a bug in the hosting RPKI software it should be gracefully =
processed, without effect on operations.
> 	=E2=80=A2 Tim's example with administrative domain splitting;
> The administrative domain splitting in RPKI doesn't seem to be a good =
idea, it significantly increases chances to get in the state with a =
partial set of customer-providers pairs with hardly predictable =
outcomes. =20
> 	=E2=80=A2 Transfer between RIRs.
> And the last seems to be on the same board - such semistate isn't =
safe, and one should keep one record at any point in time.
>=20
> Keeping in mind that the absence of ASPA record is less dangerous then =
inconsistent state my thinking is that if RPKI cache receives multiple =
ASPA records for selected customers AS it should ignore all of them. IMO =
looks like a fair good compromise: prevent race conditions and also do =
not have an effect on operations if something goes wrong.

This might not be easy for existing RPs - with ROAs the thought has also =
been that they are cumulative. Now you would need to keep much more =
state, and even check between all configured TAs - which until now could =
just be processed in parallel.

I understand your reasoning, but I think this warrants at least some =
normative wording in the document and discussion in the security =
section. And most importantly I am curious to learn what RP software =
implementers think (nowadays I do the CA side, which is much easier in =
this context).

Tim


>=20
>=20
> =D1=81=D1=80, 29 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 15:26, Tim =
Bruijnzeels <tim@nlnetlabs.nl>:
> Hi,
>=20
> > On 28 Apr 2020, at 19:03, Job Snijders <job@sobornost.net> wrote:
> >=20
> > On Tue, Apr 28, 2020, at 18:53, Jay Borkenhagen wrote:
> >> The current ASPA Verification draft:
> >>=20
> >> https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-04
> >>=20
> >> .... says in Section 3 "For a selected Customer AS MAY exist only
> >> single ASPA object."
> >>=20
> >> I concur that an ASPA object should list every authorized upstream =
ASN
> >> to avoid possible race conditions, and as such it makes sense for =
only
> >> a single ASPA object to exist at any point in time.
> >>=20
> >> But how is that uniqueness to be ensured?  What should RPs do if
> >> multiple validated ASPA objects are ever found to exist?
> >=20
> > Good question. What should it do?
>=20
> In my mind it's good to that CAs can create a single ASPA object for a =
customer ASN they hold for all their provider(*) ASNs.
>=20
> But, I think it may be better to cover that CAs SHOULD (or even MUST =
if you will) combine all provider ASNs on a single ASPA objects as a =
separate BCP, and leave a bit more flexibility in the profile and =
validation drafts. This makes it easier to change things, should we find =
that we need to change our minds on what is best.
>=20
> I don't think that RPs have to check whether the CA did indeed use a =
single ASPA object for a customer ASN. I think it should just validate =
all ASPA objects it finds, and build a list Verified Asn Relations <or =
insert alternate acronym here>. Furthermore, I think that  8210bis =
should then specify that the RP (cache) MUST exclude duplicates when =
sending these relations to routers.
>=20
> And veering a bit further into that document, I am not sure why those =
updates should be sent as a single PDU containing all current provider =
ASNs. I think it make sense to do the same as with ROAs where =
'announcement' (add) or 'withdraw' VRPs (excluding duplicates) are sent =
over RTR. I read the comment about race conditions, but I don't see how =
this is an issue when such PDUs are sent as a typical exchange (section =
8.2) between a Cache Response and End of Data PDUs.
>=20
> *) relations as defined in draft, not necessarily the business =
relation.
>=20
> > I expect such duplicates *will* exist if ASPA were to be deployed =
for real: in cases where an ASN is transferred from one RIR to another =
RIR and one wishes to make before break.
>=20
> Well in that case one would expect objects for the same customer ASN =
in different parts of the RPKI tree.
>=20
> But a similar issue could also come up if a parent issues the same ASN =
to multiple children. Which could be a working model if a large =
operation operates the same ASN globally, but has different teams =
managing it. In that case an organisation could chooses to run a =
delegated CA and issue certificates to child CAs in use by those teams. =
(I am not sure how likely this is, you have much more operational =
insight than I do, but it's definitely possible under the standards).
>=20
> In those cases any of those CAs can issue valid ASPA objects, and they =
should be combined as above.
>=20
> Furthermore, the security considerations (section 8) of the AS path =
verification draft can use some additional words to warn that this also =
means that any ASPA issuer can potentially invalidate other users of the =
same ASN if they exist.
>=20
> Maybe the idea of multiple parties operating the same ASN is =
ludicrous, but then I think it would be good to have words that =
discourage delegating the same ASN to multiple CAs, and similarly, =
discourage issuing ASPA for customer ASNs that are also delegated.
>=20
> Note that this issue is somewhat similar to ROAs for prefixes which =
are also (partially) delegated, or received by multiple organisations.
>=20
>=20
>=20
>=20
> >=20
> > Kind regards,
> >=20
> > Job
> >=20
> > _______________________________________________
> > Sidrops mailing list
> > Sidrops@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidrops
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>=20
>=20
> --=20
> Best regards,
> Alexander Azimov