Re: [Sidrops] ASPA duplicates

Alexander Azimov <a.e.azimov@gmail.com> Tue, 05 May 2020 20:49 UTC

Return-Path: <a.e.azimov@gmail.com>
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 1632D3A0AB6 for <sidrops@ietfa.amsl.com>; Tue, 5 May 2020 13:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxWyYyX0ReWL for <sidrops@ietfa.amsl.com>; Tue, 5 May 2020 13:49:28 -0700 (PDT)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72CE3A0AAD for <sidrops@ietf.org>; Tue, 5 May 2020 13:49:28 -0700 (PDT)
Received: by mail-oi1-x235.google.com with SMTP id t199so3112188oif.7 for <sidrops@ietf.org>; Tue, 05 May 2020 13:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ytNN/1G8+1S+c2NUKrwnQ9cfKPwM02EgyH6X13KkwgI=; b=Aig0QLshoVeZ9CSGLkqXz/8ffeYqfNm42YawCBCrbAN9KRz5GWoUV4FvLdzr5kJ1Rl DPhZNa6IrZWnHYNr2+PaVILgJc8xJbPfmp5tb5yhSHSU1k+NOdxtUHZOT+wNX0rEOjjR lg3GTKl9EWmYU08xGokebXZ7xXMPukdSFmM+bI7gc8d/br3LIx81SrCazlPTgddyPPr0 we8PekohEEVnTre6r7a5qDlJPKmv4tdkzUHqPWxIiZRuMr3jXlL8vUp88pIlB7oGVDnm u8nYdw0O21Bl9WvRUb6sT4kVfJwsAfJhWKZ4q5BpesdOzPV3a9BQXrgSINodwQtFasgr Bjwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ytNN/1G8+1S+c2NUKrwnQ9cfKPwM02EgyH6X13KkwgI=; b=S5n10tbPIRriMd0zisEuSEKq90epWxYOaPGzB/1b7XAqH6vHrE1GV10f0BIl+jJJcU 61v9aFUlO007cNwuyGUQZYMqLL+3ikZa6f95XlKNXIa4mpXiPem8vJXBEoYs71x5Kw++ HUU10F7IIMmmNllwQZCXWNbwEhPjuyWS808A1ZI8nTgHEoTVVi8Gvcaz6/Z0kRbW2n6K BAg4etVcsGX02Q6EydNRFPeqWKdCDmD2ScasPAlNi0b2ebIrzls7D7fdYO6HZzM8vn8Z 78X8Hg7+GGPtRM+ZzFEsS9I0UVAN8Y3ZYz2PYw/7Seqjdb01TAA1rR5UMYS9IgsJDSB/ ochw==
X-Gm-Message-State: AGi0PuZ8FG+OGZEgmyfsqh9wihRGL5kX9zrnKavTmAnqEQ5iaEE+E7dM by68NF1bt/IrEE7+x6Ay5JBs9xT06dC7ag4BdpM=
X-Google-Smtp-Source: APiQypL6Ix0wTl3A/eFwe0imRsa+rYuvvduGtE0QdESyDWugr92LMNY04ndBeLz6E+yFGHSyOQwY9pfa5cH6vsGP8uY=
X-Received: by 2002:aca:2113:: with SMTP id 19mr367082oiz.128.1588711767800; Tue, 05 May 2020 13:49:27 -0700 (PDT)
MIME-Version: 1.0
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> <0BC5FAFC-A5A3-4B67-82C1-C1BE90335C95@nlnetlabs.nl> <m27dxrrf8p.wl-randy@psg.com> <ED27E260-93D6-4C1C-A769-72E8473C552A@nlnetlabs.nl>
In-Reply-To: <ED27E260-93D6-4C1C-A769-72E8473C552A@nlnetlabs.nl>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Tue, 5 May 2020 23:49:16 +0300
Message-ID: <CAEGSd=B5FsimPQmB4gxxrYR+ME+2rchJmuyJHMsJQb9=hTcT4Q@mail.gmail.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: Randy Bush <randy@psg.com>, SIDR Operations WG <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000091fdd505a4ecc821"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/9Z5eJTyv_zxGd8RwGmRyy2M5pQ0>
Subject: Re: [Sidrops] ASPA duplicates
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 05 May 2020 20:49:35 -0000

Hi Tim,


вт, 5 мая 2020 г. в 10:45, Tim Bruijnzeels <tim@nlnetlabs.nl>nl>:

> Hi,
>
> > On 4 May 2020, at 15:39, Randy Bush <randy@psg.com> wrote:
> >
> >> 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).
> >
> > from draft-ietf-sidrops-8210bis
> >
> > 11.  ROA PDU Race Minimization
> >
> >   When a cache is sending ROA PDUs to the router, especially during an
> >   initial full load, two undesirable race conditions are possible:
> >
> >   Break Before Make:  For some prefix P, an AS may announce two (or
> >      more) ROAs because they are in the process of changing what
> >      provider AS is announcing P.  This is is a case of "make before
> >      break."  If a cache is feeding a router and sends the one not yet
> >      in service a significant time before sending the one currently in
> >      service, then BGP data could be marked invalid during the
> >      interval.  To minimize that interval, the cache SHOULD announce
> >      all ROAs for the same prefix as close to sequentially as possible.
> >
> >   Shorter Prefix First:  If an AS has issued a ROA for P0, and another
> >      AS (likely their customer) has issued a ROA for P1 which is a sub-
> >      prefix of P0, a router which receives the ROA for P0 before that
> >      for P1 is likely to mark a BGP prefix P1 invalid.  Therefore, the
> >      cache SHOULD announce the sub-prefix P1 before the covering prefix
> >      P0.
>
> Thanks for the pointer! It's unfortunate that there are no transactions,
> but I accept (already did) that this is what it is.
>
> However, my point which you quoted was about the suggestion that Alexander
> made that there MUST NOT be multiple ASPA objects for the same customer ASN
> in the RPKI, and that if there are they should all be ignored - even if
> they are all valid objects.
>
> At least that was my understanding of his intent. So that there is a
> simple model to deal with ASNs being present on multiple CA certificates in
> the RPKI (delegated or different TAs even) and the confusion and race
> conditions that may arise from managing ASPA objects with that ASN as
> customer ASN all together. Ignoring the objects provides a soft landing
> then.
>
> I am not against this per se, but I think *this* needs clarification in
> the ASPA doc, and possibly some more discussion here. I am sure that it's
> possible, but it requires that RPs keep more state than they do today.
>
I do agree. In this thread was raised the proper question which wasn't
covered by the current draft and we may have found the proper answer.
I'll add clarification with the next update.


> Furthermore, I see some advantage here (it's a simple model), but as a
> downside this provides a sort of denial attack where a parent CA can issue
> an ASPA object to essentially invalidate the object issued by the
> operational holder of the ASN. Worse, this can happen between TAs, so only
> one TA would need to be subverted in order to invalidate ASPA objects under
> any of the other TAs.
>
If we ignore duplicate object it can't be used for DoS. The draft doesn't
suggest any actions against 'unknown' paths.
The question of what happens if one TA issues invalid records for address
space/ASNs that are operated by another TA where such records do not exist,
should be discussed separately if we admit such an attack vector. IMO it is
highly unlikely, but if it happens can already lead to global connectivity
disruption.


> For ROAs the RPs just build a complete list of all VRPs found on all valid
> ROAs anywhere, and only then a set is made and duplicates are excluded when
> talking to the router. So VRPs appearing elsewhere do not have the power to
> force other VRPs to the 'ignore list'. For ROAs the advice is that parent
> CAs have a responsibility NOT to invalidate their children's announcements,
> and for inter RIR transfers make before break is at least theoretically
> possible. A similar model could also apply to ASPA objects.
>
I believe the operation requirements for address space transfer is
different from the ASN transfer from one RIR to another. But even in the
ROA scenario, different ROAs existing in two RIRs simultaneously might
cause problems.


> I know this is a political minefield as much as a technical issue.
> Nonetheless, I think we should make a clear decision which scenario is
> desired under today's operational reality.
>
The ASN transfers do happen, but as far as I know, it doesn't represent
common day-to-day operations. IMO the security reasoning should prevail for
ASPA and might be reconsidered for ROA.