From nobody Sat Jan 4 02:11:46 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0FC120019; Sat, 4 Jan 2020 02:11:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net, nathalie@ripe.net X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157813270574.14337.1626746638193840926.idtracker@ietfa.amsl.com> Date: Sat, 04 Jan 2020 02:11:45 -0800 Archived-At: Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 107 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2020 10:11:46 -0000 A new meeting session request has just been submitted by Nathalie Trenaman, a Secretary of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Nathalie Trenaman Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 70 Conflicts to Avoid: Chair Conflict: 6man idr grow lsvr rtgwg lsr mpls pim spring v6ops People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jan 6 16:52:35 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BDB120041; Mon, 6 Jan 2020 16:52:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <157835835372.8024.11002017458859903735@ietfa.amsl.com> Date: Mon, 06 Jan 2020 16:52:33 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 00:52:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : RPKI Signed Object for Trust Anchor Keys Authors : Carlos Martinez George G. Michaelson Tim Bruijnzeels Rob Austein Filename : draft-ietf-sidrops-signed-tal-04.txt Pages : 16 Date : 2020-01-06 Abstract: Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by Relying Parties in the RPKI to locate and validate Trust Anchor certificates used in RPKI validation. This document defines an RPKI signed object for Trust Anchor Keys (TAK), that can be used by Trust Anchors to signal their set of current keys and the location(s) of the accompanying CA certiifcates to Relying Parties, as well as changes to this set in the form of revoked keys and new keys, in order to support both planned and unplanned key rolls without impacting RPKI validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-04 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 9 03:46:14 2020 Return-Path: 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 9AA4E12011E for ; Thu, 9 Jan 2020 03:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 NY6XayoCKRgl for ; Thu, 9 Jan 2020 03:46:11 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B27120818 for ; Thu, 9 Jan 2020 03:46:11 -0800 (PST) Received: from localhost (unknown [IPv6:2a02:58:96:c501::10]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 831171C1EA for ; Thu, 9 Jan 2020 12:46:09 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=luuk@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1578570369; bh=0VQyb/vuqPpefKy9NjJTs/+VV8rPRUT0IDfsWGdGiq0=; h=Date:From:To:Subject; b=bBvG8QBbaQbeKzi8A+4WV0ISa5jSa3VqgUB2+dnuV7fWKI+zizFA4erphbUH95RN9 0uleX4Bb2F9zcXLEbDmYMMfwh2JXahfgD+IkQC7qyuUwtMW//9CVXNaKJjnSHGJZdt yjkHLW5QkswDYkjOUQJF7y3r94U1BJugDfGCkx8o= Date: Thu, 9 Jan 2020 12:46:09 +0100 From: Luuk Hendriks To: sidrops@ietf.org Message-ID: <20200109114608.GA24582@corley.shackle.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Sidrops] Clarification of draft-ietf-sidrops-aspa-verification-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 11:46:13 -0000 Hi all, Reading through draft-ietf-sidrops-aspa-verification-03 left me with some questions. I have not followed the entire evolution of this document, so apologies if I nag about things that have been discussed before. Especially with regards to the actual validation steps, I (or rather we, there has been a lot of discussion in our office) think we might be missing or misinterpreting some parts, and I'd like to get on the same page before diving into details. With regards to the upstream/downstream and allowing one Invalid to occur in the 'chain' so to say, we picture it as follows: +-----+ +--------> AS2 +--------+ | +-----+ | +-----+ +--v--+ +------->+ AS1 | | AS3 +--------+ | +-----+ +--^--+ | +-----+ +--v--+ | AS0 | | AS4 | +-----+ +-----+ | +--v--+ | AS5 | +-----+ Say, we are AS5, receiving an announcement with AS_PATH 4 3 2 1 0 , thus AS0 being the originating AS. The upstream part is AS0 -> AS1 -> AS2, the downstream part is AS2 -> AS3 -> AS4 . (Correct?) Then looking at the diagrams in the draft, there is an I++ when this allowed Invalid is observed. Does that mean that the relation between the ASes just after the upstream/downstream point (thus, whether AS2 is a provider of AS3) is not checked? If so, is that on purpose, and how does it not break the validation chain? Hopefully someone can clarify whether we are on the right track of understanding these concepts. Thanks, luuk From nobody Tue Jan 14 07:04:54 2020 Return-Path: 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 ED247120100 for ; Tue, 14 Jan 2020 07:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DDnMzl6whCK9 for ; Tue, 14 Jan 2020 07:04:47 -0800 (PST) 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 0068D1200FE for ; Tue, 14 Jan 2020 07:04:46 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id n16so12056585oie.12 for ; Tue, 14 Jan 2020 07:04:46 -0800 (PST) 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=f0AeCUPVlfNwD60k9WBh3QzwEq/0X2p1VRpl3QEK9qM=; b=IrBLzfbt+M/5FnLGFlYA7hukxDqfD6MaQ1VbOxkXXw7yBfP09S0UR3iXsOlpwQA4Lo NjakYjik6IenBsDxv0SnECFvNuMAWsnIte6MMgASqLZl5a+/OofoBkQ+41ZFNwGZZu+A 7RhbW63RDtliHxQVNAsqvfFMpfhxkJFfnWEajAZ91vmNKYNMFWb7iGwXAjQ5tPENUk9f Tgtvd+Dy3GG8TExNxxymN1fPveKl/YtUwk3WTrkc88ucEpUCMCjToErGaG0y6NlXr1vM R0FYnNT7VioqWyP9Mssnu47rVLS7+rHFiTNG6q/5qm+lQPQoyrJ6d3bJLdTinI1JwRiZ EZyw== 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=f0AeCUPVlfNwD60k9WBh3QzwEq/0X2p1VRpl3QEK9qM=; b=nBHPqggoncpJFi6Xc37yuN8ZVJZ1VApNMNvkKeX4z5LoHZVzgA8NoOl3m24X6mJnFm 7rOJkrfukR/kNw16AJpdbzchECKtbyLsiUrXVrZ0n3ElP63NLetqjrOxlWL3Q7Z8IOf+ njIRm7WRb6RdiH5Mb299r6nawnJP7+1HHl6RPsZWl1D444WwrctmCTUoge5yhWaQdVfM 2idP+TypQfWaSiU57RWBO9CWNjtqfpT1sHGyaRFxk479AFcvcBjiSrBHgMnTaPbG3imX aruONrtwhAAOCVV9e03bAoWLcydFpaRabfFikL8K6251/8006hkPa62mrc4u+3W8glMW UbpQ== X-Gm-Message-State: APjAAAV7+h78Ok3xHvU8mcScZS+FX7G+NmrcMvI98vieaMO1k/7hjnUW ZQ77X+f80lDNBbQ/HNvw60QibeVnswbh6kaIzcA= X-Google-Smtp-Source: APXvYqyvAcmFRz+uGSLwZgbK/PsgHNdqQjHhedM5W/QIRDwMVranDQEntKVd2G6aq3DffqPQNyddTyPZhlma2uJ4KPM= X-Received: by 2002:a05:6808:319:: with SMTP id i25mr17630530oie.128.1579014286134; Tue, 14 Jan 2020 07:04:46 -0800 (PST) MIME-Version: 1.0 References: <20200109114608.GA24582@corley.shackle.nl> In-Reply-To: <20200109114608.GA24582@corley.shackle.nl> From: Alexander Azimov Date: Tue, 14 Jan 2020 18:04:34 +0300 Message-ID: To: Luuk Hendriks Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="0000000000009ed3be059c1ae97c" Archived-At: Subject: Re: [Sidrops] Clarification of draft-ietf-sidrops-aspa-verification-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 15:04:52 -0000 --0000000000009ed3be059c1ae97c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Luuk, In the terms of the draft AS0->AS1->AS2 is an upstream path, while AS3->AS4 is a downstream path. The invalid state of (AS2, AS3) pair triggers the change of the 'direction', but the following downstream path verification procedure is not applicable to (AS3, AS2) since it can be a peering link, that's why I++ is used. =D1=87=D1=82, 9 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3. =D0=B2 14:46, Luuk Hendrik= s : > Hi all, > > Reading through draft-ietf-sidrops-aspa-verification-03 left me with > some questions. I have not followed the entire evolution of this > document, so apologies if I nag about things that have been discussed > before. Especially with regards to the actual validation steps, I (or > rather we, there has been a lot of discussion in our office) think we > might be missing or misinterpreting some parts, and I'd like to get on > the same page before diving into details. > > With regards to the upstream/downstream and allowing one Invalid to > occur in the 'chain' so to say, we picture it as follows: > > > +-----+ > +--------> AS2 +--------+ > | +-----+ | > +-----+ +--v--+ > +------->+ AS1 | | AS3 +--------+ > | +-----+ +--^--+ | > +-----+ +--v--+ > | AS0 | | AS4 | > +-----+ +-----+ > | > +--v--+ > | AS5 | > +-----+ > > > Say, we are AS5, receiving an announcement with AS_PATH 4 3 2 1 0 , thus > AS0 being the originating AS. The upstream part is AS0 -> AS1 -> AS2, > the downstream part is AS2 -> AS3 -> AS4 . (Correct?) > > Then looking at the diagrams in the draft, there is an I++ when this > allowed Invalid is observed. Does that mean that the relation between > the ASes just after the upstream/downstream point (thus, whether AS2 is > a provider of AS3) is not checked? If so, is that on purpose, and how > does it not break the validation chain? > > > Hopefully someone can clarify whether we are on the right track of > understanding these concepts. > > > Thanks, > luuk > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --=20 Best regards, Alexander Azimov --0000000000009ed3be059c1ae97c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Luuk,

In the terms of the draft AS0-= >AS1->AS2 is an upstream path, while AS3->AS4 is a downstream path= .
The invalid state of (AS2, AS3) pair triggers the change of= the 'direction', but the following downstream path verification pr= ocedure is not applicable to (AS3, AS2) since it can be a peering link, tha= t's why I++ is used.

=D1=87=D1=82, 9 =D1=8F=D0=BD=D0=B2. 2020 =D0= =B3. =D0=B2 14:46, Luuk Hendriks <l= uuk@nlnetlabs.nl>:
Hi all,

Reading through draft-ietf-sidrops-aspa-verification-03 left me with
some questions. I have not followed the entire evolution of this
document, so apologies if I nag about things that have been discussed
before.=C2=A0 Especially with regards to the actual validation steps, I (or=
rather we, there has been a lot of discussion in our office) think we
might be missing or misinterpreting some parts, and I'd like to get on<= br> the same page before diving into details.

With regards to the upstream/downstream and allowing one Invalid to
occur in the 'chain' so to say, we picture it as follows:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----= ----> AS2 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 +-----+=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--v--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +------->+ AS1 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| AS3 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----+=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--^--+=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+--v--+
=C2=A0 =C2=A0 =C2=A0| AS0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| AS4 |
=C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+-----+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--v--+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| AS5 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----+


Say, we are AS5, receiving an announcement with AS_PATH 4 3 2 1 0 , thus AS0 being the originating AS. The upstream part is AS0 -> AS1 -> AS2,=
the downstream part is AS2 -> AS3 -> AS4 . (Correct?)

Then looking at the diagrams in the draft, there is an I++ when this
allowed Invalid is observed. Does that mean that the relation between
the ASes just after the upstream/downstream point (thus, whether AS2 is
a provider of AS3) is not checked? If so, is that on purpose, and how
does it not break the validation chain?


Hopefully someone can clarify whether we are on the right track of
understanding these concepts.


Thanks,
=C2=A0luuk

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops


--
Best regards,
Alexander Azi= mov
--0000000000009ed3be059c1ae97c-- From nobody Wed Jan 15 19:29:05 2020 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAA012002F; Wed, 15 Jan 2020 19:29:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <157914534015.22379.11024327123542212494@ietfa.amsl.com> Date: Wed, 15 Jan 2020 19:29:00 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 03:29:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : RPKI Signed Object for Trust Anchor Keys Authors : Carlos Martinez George G. Michaelson Tom Harrison Tim Bruijnzeels Rob Austein Filename : draft-ietf-sidrops-signed-tal-05.txt Pages : 16 Date : 2020-01-15 Abstract: A Trust Anchor Locator (TAL) [I-D.ietf-sidrops-https-tal] is used by Relying Parties (RP) in the RPKI to locate and validate a Trust Anchor (TA) CA certificate used in RPKI validation. This document defines an RPKI signed object for a set of Trust Anchor Keys (TAK), that can be used by TA creators and publishers to signal their set of current keys and the location(s) of the accompanying CA certificates to RPs, as well as changes to this set in the form of revoked keys and new keys, in order to support both planned and unplanned key rolls without impacting RPKI validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-05 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 21 00:06:05 2020 Return-Path: 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 842F7120043 for ; Tue, 21 Jan 2020 00:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 c3cfAEUZcV28 for ; Tue, 21 Jan 2020 00:05:57 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF99120071 for ; Tue, 21 Jan 2020 00:05:56 -0800 (PST) Received: from localhost (unknown [IPv6:2a02:58:96:c501::10]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 258551BF61; Tue, 21 Jan 2020 09:05:54 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=luuk@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1579593954; bh=vWIvjAZ8n8xO+0+/BQVDZYTmU0kPKL+qirjtgzeIN3g=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=d7LCW73d4y9URd+BDfAZWLSlPog6bpNrbmPb2noRz8kAXES+SoHVdfsb620+DqP74 /mtBr9o7mq6h+K01PvkE+ytu7eLOd9Q0+U4wez7raPA4E6uEGvbwkUbRxVF1xdaxH9 eExP8x57uRXK8A48BsNDw8E6XZEE/OG5Qhkb4EGE= Date: Tue, 21 Jan 2020 09:05:53 +0100 From: Luuk Hendriks To: Alexander Azimov Cc: SIDR Operations WG Message-ID: <20200121080553.GA18351@corley.shackle.nl> References: <20200109114608.GA24582@corley.shackle.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Sidrops] Clarification of draft-ietf-sidrops-aspa-verification-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 08:06:03 -0000 Hi Alexander, all, On Tue 14 Jan 2020, 18:04, Alexander Azimov wrote: > In the terms of the draft AS0->AS1->AS2 is an upstream path, while AS3->AS4 > is a downstream path. > The invalid state of (AS2, AS3) pair triggers the change of the > 'direction', but the following downstream path verification procedure is > not applicable to (AS3, AS2) since it can be a peering link, that's why I++ > is used. Thanks for clarifying, it seems that we did interpret those parts of the draft correctly then. But we are still wondering whether skipping the check after the direction change is introducing a problem. (Again, this might be us not having much operational experience with actual routing, so please bear with me..) What if a bad actor, AS9, inserts itself in the path like this: +-----+ +--------> AS2 +--------+ | +--+--+ | +-----+ | +--v--+ +------->+ AS1 | | +----->| AS3 +--------+ | +-----+ | | +--^--+ | +-----+ +-v-+-+ +--v--+ | AS0 | | AS9 | | AS4 | +-----+ +-----+ +-----+ | +--v--+ | AS5 | +-----+ No valid (AS2, AS9) ASPA is found, so we assume it is a peering link (the I++). Direction is changed, so continuing, (AS3, AS9) and (AS4, AS3) are checked. Now, if and only if any of these yield Invalid, the final result will be Invalid. Otherwise, the result will be Valid or Unknown, even though there is a malicious AS in the path. In other words, is the draft in its current revision beneficial without (close to) 100% adoption? Or, is this situation not considered a problem in reality due to the longer AS_PATH and thus a lower preference anyway? Thanks, luuk From nobody Thu Jan 30 10:26:42 2020 Return-Path: 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 B7A42120255; Thu, 30 Jan 2020 10:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 DL05nhcWVRIW; Thu, 30 Jan 2020 10:26:38 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 A504A120251; Thu, 30 Jan 2020 10:26:30 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id 21so3917698qky.4; Thu, 30 Jan 2020 10:26:30 -0800 (PST) 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:content-transfer-encoding; bh=2Ed+azoRBPODsalBPQwoD0baUVHSTNpiOHWEP61vfKw=; b=ANDsFSRblK2e7axk+EfAK5Yks4C8Atz2R1+vI2e/TiubHfiYOTDShl0qfybXcHMkS7 7YK8Cj/yCaRMNA+EDlBXTB+eF11weMQ+6gJrT648/BfWXFXaMX5qin7G3L3xJNszX5Gw 5Q89/TBllJR6qqJMAZS5LP0qX0PUlzSL6U4RU5snZGdvb+LeTFMIzwk2JsvE2re6zg8D k6UNOh03vJgQzFe901SUuTjY9pLY2walXPYYOmke4d5QCp4xlhe/kj2zXmqmKQ33FoVo Li7peQMaQ5Z3l6Q+QR8wYYY+WtfnSzHexkW1QriZ+RpnhNH608jkqyKuVgigk6Zx864o FuEw== 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:content-transfer-encoding; bh=2Ed+azoRBPODsalBPQwoD0baUVHSTNpiOHWEP61vfKw=; b=s31NTaRz/gbCZCxcBBdbAjLTfQbBizTyJKAdAEJJgGD5CGn0k1gBnPvoje9XGiYBZX B0qpzzohlTF+TEb/KXz4Z1I72B8MC/tUogYOwUo3BI2tRiEIV8np5ZyK3wYuUoDyeLal zk3Ni6fDv/nOFkJK8bt6emgmwty8EGtWESbA8Aq2gELpXCVKKEoXWMnWwhL4CWg5vzMT oTW9hr/yUpkxohiwg6kLL/B+vVsTw7VpRLNTk8+FcWoJKbInQeQD5HC7vBLPuu8NG3sZ Wap2SG1fpy4n/qSfJpdHRUWODQ3Pd7JEvHZtO0BoW664aihWZfORHY9JZz6RjJG9qyxh swiQ== X-Gm-Message-State: APjAAAXKgOH7zpISbj8w95PUGu0b/VIvdFTTt0jOmOXlBeFp/OK1Dj3H QGiWiX4gAgcJ3eIRUH4z7MfRZytdPqex48SkIcdgog== X-Google-Smtp-Source: APXvYqyYgHR8EZAmy8R0WNRKbLuKo3I/zGrNSmvvEkW1zuDRyG4IVWVR6TmwH/SVf3Ejebqb4G92bsF9BXrjbPLJbIA= X-Received: by 2002:a37:6649:: with SMTP id a70mr6393395qkc.116.1580408789604; Thu, 30 Jan 2020 10:26:29 -0800 (PST) MIME-Version: 1.0 References: <19AB2A007F56DB4E8257F949A2FB9858E5E35F15@NKGEML515-MBX.china.huawei.com> In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858E5E35F15@NKGEML515-MBX.china.huawei.com> From: Christopher Morrow Date: Thu, 30 Jan 2020 13:26:18 -0500 Message-ID: To: Zhuangshunwan Cc: SIDROps Chairs , SIDR Operations WG , "sidrops-ads@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] WGLC draft-ietf-sidrops-rp-06 ends 12/17/2019 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 18:26:41 -0000 Howdy! time flew, but this LC did not :( I believe we believe this should move forward, so let's get a write up off to the IESG! :) -chris On Thu, Dec 19, 2019 at 7:47 PM Zhuangshunwan wr= ote: > > I support publication. > > Thanks, > Shunwan > > > -----Original Message----- > From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Christopher = Morrow > Sent: Wednesday, December 04, 2019 9:13 AM > To: SIDROps Chairs ; SIDR Operations WG ; sidrops-ads@ietf.org > Subject: [Sidrops] WGLC draft-ietf-sidrops-rp-06 ends 12/17/2019 > > howdy folks! > The authors of draft-ietf-sidrops-rp have made some changes related to p= revious comments/questions/etc and would like to move the document along pr= ovided issues are properly addressed. Let's take a 2wk period to read and r= eview, comment and raise concerns if there are any remaining. > > Thanks! > -chris > co-chairperson > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops