Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021

["Borchert, Oliver (Fed)" <[e-mail]>]

The current version of the draft mentions a router only contains one single APSA object per customer. This assumes a specific form of implementation. I don't believe a protocol specification should do that. One can imagine an implementation that stores the data as link relations hence multiple internal objects per customer. Take 10 implementers and you might end up with 10 solutions.

I always read to keep things simple - Great I like simple. Though, as I outlined in my email from last week, the current specification introduces implicit withdrawals while announcing an ASPA object. That contradicts simplicity - it adds additional complexity to the router.

As I mentioned in my email as well as was mentioned in prior IETF's a router should never perform any validation on incomplete data. The moment the router starts updating the data, it most likely will encounter a break before make situation - at least when it comes to ROA's. Therefore the router should always wait until a complete update is processed prior acting upon it.

Therefore, "Keep it simple" should result in a PDU as I proposed with only a single Customer Provider. An ASPA object that contains 10 providers should result in 10 PDU's each with the customer and a single provider. Duplicates are treated as established, withdrawals are treated as established. No special handling required on the router's side.

--> Simple!


Oliver


-----------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Office) +1.301.975.4856
(GVoice) +1.240.668.4117
 

On 11/29/21, 6:18 AM, "Sidrops on behalf of Tim Bruijnzeels" <[e-mail] on behalf of [e-mail]> wrote:



    > On 28 Nov 2021, at 03:35, Randy Bush <[e-mail]> wrote:
    > 
    >> I think that a model similar to multiple ROA objects and resulting VRP
    >> PDUs is preferred.
    > 
    > From: Randy Bush <[e-mail]>
    > Subject: Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00
    > To: Alexander Azimov <[e-mail]>
    > Cc: SIDR Operations WG <[e-mail]>, Tim Bruijnzeels <[e-mail]>
    > Date: Sun, 06 Oct 2019 17:07:36 -0700
    > 
    > i have not thought deeply abut this.  but it seems to me that, as in
    > ROAs, one enters into and leaves relationship with a provider.  whacking
    > a multi-AS ROA or a multi-provider ASPA record seems ill advised.  for
    > example, what if there is a delay between delete and recreate?
    > 
    > keep things simple, please.
    > 

    I am all for simple, but you cannot assume there will only ever be one
    valid ASPA object for a customer AS.

    I know the profile text says the a CA MUST make a single ASPA for a customer,
    and I agree. But there are a number of reasons why RPs need to be prepared to
    see multiple valid ASPA objects in the RPKI:

    1 CA migration make before break

    Suppose that I want to change from one CA implementation to another, then
    I want to ask my parent to authorise my new CA and set up everything, ROAs,
    ASPAs etc before removing and breaking my old CA.

    2 Parent publishing ASPA

    A parent can publish an ASPA for my customer ASN, delegate the ASN to me,
    and then I can publish a second ASP?A. Ill advised indeed, but we cannot
    assume it won't happen.

    3 Multi TA

    ASPA objects for the same customer ASN can appear in different trees, at
    least in theory.

    4 (future) Local exceptions (SLURM)

    While this would not be an object as such, we can (and should) extend
    SLURM to allow for local ASPA filters / additions. This could also cause
    overlaps with actual objects.

    5 Algorithm Roll?

    I need to re-read this in detail (RFC 6916) but I think there may be
    duplicate objects in there as well, though I am not sure whether RPs
    are required to validate both for the same CA. But, there may be something
    here too.


    In short I think RPs should process all *valid* ASPA objects and then
    derive the *union* of all providers for a given customer ASN and AFI.

    Note that this is orthogonal to the question of whether that union should
    be presented to routers as a single PDU, or that single provider announcement/
    withdrawal PDUs could be used.


    > randy
    > 
    > 
    > From: Randy Bush <[e-mail]>
    > Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt
    > To: Alexander Azimov <[e-mail]>
    > Cc: SIDR Operations WG <[e-mail]>
    > Date: Tue, 24 Mar 2020 12:02:10 -0700
    > 
    >> The current proposal addresses this issue for ASPA and ROAs in a different
    >> way:
    >> 
    >>   - For ASPA a single PDU per customer AS is neveling the issue;
    >>   - For ROAs the draft introduces ordering of the updates + suggests
    >>   sending updates with the same prefix back to back.
    >> 
    >> The way ROAs will be processed decreases the chances that valid prefixes
    >> will be marked as invalid, but they are not zero. My thinking is, that
    >> since RTR protocol is negotiating its version at the start of the session
    >> there is no need to keep full backward compatibility with the way ROAs were
    >> processed previously. Instead, we can change ROA RTR PDUs is the same
    >> fashion as it is introduced for ASPA: a single PDU for a selected prefix
    >> that replaces previous records.
    > 
    > two dimensions of why not
    > 
    >  o the ASPA is a single atomic assertion signed by the only party who
    >    has the authority.  it's pretty simple.

    See above, there can be, and therefore RPs must assume there will be, more
    than one object.

    > 
    >  o ROAs for a range are not atomic and may be asserted by many parties.
    >    e.g. a /15 with two delegated /16s, each with delegated /whatevers.
    >    if a /29 down the subnet-chain changes, you have to re-do the whole
    >    shebang.
    > 
    >    a number of these are likely to be via CA delegation; more and more
    >    as alex's marketing engine revs up.  so they will arrive at a cache
    >    skewed in time.
    > 
    >    think what this does to the load on the router; and remember that
    >    one major goal here is to minimize router load so current hardwhere
    >    running on 6502s with 640k can route origin validate.

    I am all for reducing the load on routers.

    How is presenting a single PDU with a provider list that is supposed to
    replace the previous list better on routers than having multiple PDUs
    in a single update - i.e. before the end of data as Oliver mentioned?

    In the first case there is possible overhead in case lists get long,
    the second puts some burden on the router to build up its own new version
    of a list before replacing the one it had. I expect that burden to be
    low, but if router implementers can attest that it isn't then I would
    love to hear it.

    As I said, multi ASPA objects is orthogonal. If we MUST have a single
    PDU then the cache can send the union of providers in ASPA objects as
    a single PDU.

    > and ask folk such as mark how rov deployment is going on some of the
    > more common platforms.

    I don't know who you mean by mark and what you mean by this. If there
    are lessons to be shared, then please share specifics.

    > 
    > randy
    > 
    > _______________________________________________
    > Sidrops mailing list
    > [e-mail]
    > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=04%7C01%7Coliver.borchert%40nist.gov%7C70d048bf3e5b49ef79c008d9b329f3d8%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637737815033219650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=bbwNyYio7MY9HcS6y5c%2Fc%2F3be6thDWayfwQu77Vh7Dc%3D&amp;reserved=0

    _______________________________________________
    Sidrops mailing list
    [e-mail]
    https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=04%7C01%7Coliver.borchert%40nist.gov%7C70d048bf3e5b49ef79c008d9b329f3d8%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637737815033229605%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=YUOeX%2BFBPcBdcKEb5xGBSFu6kO0cBu1d73bixONq0fg%3D&amp;reserved=0