From nobody Tue Mar 3 17:56:00 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 84FDD3A0ADE; Tue, 3 Mar 2020 17:55:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Keyur Patel via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, nathalie@ripe.net, warren@kumari.net, sidrops-chairs@ietf.org, sidrops@ietf.org, keyur@arrcus.com Message-ID: <158328695852.7683.1025873526884618292@ietfa.amsl.com> Date: Tue, 03 Mar 2020 17:55:58 -0800 Archived-At: Subject: [Sidrops] Publication has been requested for draft-ietf-sidrops-ov-egress-00 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: Wed, 04 Mar 2020 01:55:59 -0000 Keyur Patel has requested publication of draft-ietf-sidrops-ov-egress-00 as None on behalf of the SIDROPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ From nobody Tue Mar 3 18:02:29 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 7C1B93A0B68; Tue, 3 Mar 2020 18:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 kzQ-ZADiCGmT; Tue, 3 Mar 2020 18:02:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 6DD763A0B66; Tue, 3 Mar 2020 18:02:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1j9JMc-0002BE-Vn; Wed, 04 Mar 2020 02:02:23 +0000 Date: Tue, 03 Mar 2020 18:02:20 -0800 Message-ID: From: Randy Bush To: Keyur Patel via Datatracker Cc: sidrops@ietf.org In-Reply-To: <158328695852.7683.1025873526884618292@ietfa.amsl.com> References: <158328695852.7683.1025873526884618292@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Publication has been requested for draft-ietf-sidrops-ov-egress-00 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: Wed, 04 Mar 2020 02:02:27 -0000 thanks, keyur (and chris) directorate and iesg reviews should be fun randy From nobody Wed Mar 4 00:56:04 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 5E4FE3A0946; Wed, 4 Mar 2020 00:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=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 wq6pWTymYMtL; Wed, 4 Mar 2020 00:55:52 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 ED9DE3A0941; Wed, 4 Mar 2020 00:55:51 -0800 (PST) Received: from [IPv6:2a04:b904::f045:1a86:3b91:e0fc] (unknown [IPv6:2a04:b904::f045:1a86:3b91:e0fc]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id B8F0416D0B; Wed, 4 Mar 2020 09:55:46 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=pass (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=pass smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1583312146; bh=jAdna7eZ+Zc7SHSbWxfNQq4R9wXeQUMehxdUvz+rttg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=qwunnNQTwp7EPzS9ftlhJLHJLEeyR7JHkezxUNoEcqXfs3+dAe0uocVyatXawi+iX mEUqMFOtnNVHWGXK/8CLCv02r/auMu4Phatv98YPyLUsBLUHHkd4ZFtVXEZcIBnqvR qrOHpZhgePNYnHG8AMjYmUL9QjJaAZzLn9BJj+XE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: Date: Wed, 4 Mar 2020 09:55:42 +0100 Cc: Christopher Morrow , SIDR Operations WG , i-d-announce@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <920CAE43-E94A-45A1-AD2C-86095F396E96@nlnetlabs.nl> References: <157914534015.22379.11024327123542212494@ietfa.amsl.com> To: George Michaelson X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-05.txt 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: Wed, 04 Mar 2020 08:56:04 -0000 Hi, I believe that we should discuss the concerns raised by Rob. Whether = that is in the context of a working group last call or not.. I don't = really mind the process. What is indeed important is that we ask ourselves what issue this draft = solves, and what complexity, and which risks are introduced. We should = ask the same questions about alternative paths and/or doing nothing. The issue that motivated me to invest time in this, is that without = automation you will lose RPs when there is a change in the TAL. People = will just not update until they find that suddenly a TA they had = configured disappears - and they may not notice this for a while. In the = context of ROV the landing is relatively soft: things become 'not = found', but it is a landing nonetheless. I saw Ben Cox present a data plane analysis at the nlnog day 2018, and = again 2019. He found that there is a significant number of people who do = not enable the ARIN Tal, presumable simply because it could not be = included. See slide 44 (!) of this presentation: = https://nlnog.net/static/nlnogday2018/8_Measuring_RPKI_ben_NLNOG_2018.pdf Regarding the RPA, I am afraid that it too will be problematic w.r.t. = renewals. Nowadays one can ship the actual file, but users still need to = take action to accept. It is not clear to me whether this implies that = they can accept an updated TAL without interacting (beyond updating the = software). In any event the difference in drops between RIPE invalids and ARIN = invalids in that presentation exemplify how many users would be unaware = of an issue. And could be late updating. We could, of course, accept all of the above. We could decide that the = complexity and other risks introduced by this draft are simply not worth = it. Do not get me wrong, I co-authored, but I have no fatherly feelings = that stop me from having the discussion. I expressed earlier that I believe that this document can be simplified = if we limit the amount of simultaneous keys to two. It could be = simplified even further if we only allowed forward rolls. Whether that = is the right choice depends on what we are trying to solve. With regards to risks introduced. It is undeniably true that simply by = having two keys, only one of them needs to be subverted to end up in a = bad place. The attack surface is increased. However, most TA operators = use HSMs and M/N processes in signing, which in my mind provide enough = protection against key theft, and key abuse. So it was a deliberate = choice that this draft does not even try to solve those issues, and = accepts that it is itself vulnerable to such issues.=20 The main motivation here is forward rolls from one HSM vendor to = another. The secondary motivation is to protect against key loss (card = set lost, broken HSM, people no longer with us). The latter is why the = complexity regarding aborting a roll to key 'b' and introducing a new = key 'c' was introduced. What if you plan to go to 'b' but you lost = access to it. On the whole I am still in favour of the automation, but I welcome a = healthy discussion where pros and cons are weighed :) Tim > On 27 Feb 2020, at 23:30, George Michaelson wrote: >=20 > I'd like it if we could go WGLC. I think it takes a stronger signal of > commit and contentment in the WG. Our author discussion on "where > next" is a bit cold right now, because there isn't much to do, but we > don't have words for what there is to do. >=20 > How about we put that to the ML or F2F? Which I guess, is what you = just did. >=20 > I stole the edit token. I'd be happy to let my esteemed co-authors and > the WG tell me what they want here. Probably, confusion in my part put > it to WGLC but if it is there, why don't we treat it seriously and ask > if its ready? >=20 > We need a mechanism to signal intent to change TAL. Automation is a > "step too far" for some people, Rob Kisteleki has spoken to the > inherent risks, and the concern it does not "fix" risks some people > think it may, because an ability to subvert the TAL implies an ability > to subvert the signature over the TAL, and so force communities to > inherit a new TAL, of bad intent. The DNS root process with in-band > signal is a different world. We can learn from it, but it may not show > what general X509 PKI models think is a good way to do this. >=20 > Rob suggested we consider why browsers ship TA changes by updating > code. That moves the burden to a body who agrees what TAL need to be > shipped, and liaison with the Validator authors and release processes. >=20 > Or, a hand-run process to use this mechanism. >=20 > Or, a signalling mechanism to flag "this TAL needs to change" but the > actual decision to change, is hand-managed buy the RP. >=20 > Basically, I don't know why it flagged WGLC but I think it is not far > off, and I would like it to close. >=20 > -G >=20 > On Fri, Feb 28, 2020 at 4:33 AM Christopher Morrow > wrote: >>=20 >> Howdy WG Peepls! >> This document got marked somewhere in the datatracker as: "WGLC"... >> which seems awesome, but I didn't see/remember actually doing that :( >>=20 >> Do the authors feel this document is ready for WGLC? If so we can get >> that started :) If not I'll go re-set the status in datatracker. >>=20 >> On Wed, Jan 15, 2020 at 10:29 PM wrote: >>>=20 >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>> 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. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ >>>=20 >>> 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 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-signed-tal-05 >>>=20 >>>=20 >>> 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. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=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 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Mar 4 12:28:57 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 126923A07C2 for ; Wed, 4 Mar 2020 12:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=kumari-net.20150623.gappssmtp.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 Fcgfba8WC7w5 for ; Wed, 4 Mar 2020 12:28:54 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 9B4F83A07B5 for ; Wed, 4 Mar 2020 12:28:54 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id u124so3009066qkh.13 for ; Wed, 04 Mar 2020 12:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Gkl8F78/ejH/adFDQ6PTbNfvt/Fn3Ran0x0ScMpbgJ8=; b=rZhRSQbAuJYkxFCAcso+7j2BhZG8rgI+SHz9otlVy7/MA0bixo9xjjI3d5B5nkZtOP FJ31sc7ieIjqA33qnwtkWaQupUKkaBtGFO8erm3PrJC3gyPJyD5Y3mVrL9Bn1qaNMyMS mgETOaYNta7QLdLwBYdAgsb7Q+MwhbQ2qhogywQ3eswSVARn7WMPH5vuYL59HycDPwGy xZTRWk1QtLinICf0tcPStUWfIhN+1XV84vFqPS/DSMJoqFopZrvr71M1GKee780z3vFM Wy3SJIaSNcovqXo+cDN41BUyV1qcPtTal1XasxV2litpe5gVgfOmFsH0Vc4WVBeKXAIX 2igA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Gkl8F78/ejH/adFDQ6PTbNfvt/Fn3Ran0x0ScMpbgJ8=; b=eqiVvhN2MEl01kev6ucbH7n8YDKtIo9hYEbcAysqxcPOWxhqoAc9SmRZioS9dhbtyq X5YUZhuvjH5UPniM5V/o0lnOSFEhpACwbFUJIxKKVgQ2/br6IlXgOcEZjT4/GS/nGvc8 sY4TduDd4nZm7fGnX6p/yze23XesZulKFLICjIkIoFsRBjbCn0qFnh0giah8FZkxQTPz nPIiZiDd4hhNe0oxmKKmffXnQkTJldgQx8E/K5Gv8Or77eUNp02mEtqKzMBbHhtpQUNy Q047bTBoUYmsmNU6tXiRt9cw4BjBqAqrXPbOlcwbiBfazMCt7ZlH2yaRsAQF8mBbAdrj aw2A== X-Gm-Message-State: ANhLgQ0mEiP4sCxJXNmnUSyhyUFMWfvOlpwt/fLfy9SH9VOBXeWIoI+L /Ee8qOEblaYNDhCs1biz8X9n0WoywBAM5bKs6PsEXbpeX9o= X-Google-Smtp-Source: ADFU+vsk38PWWpTvkqytBL8lMo2NpM/fOl7pPGXoOPP/3pilGKOc+yQAxa3EX97DJwpIFBd6enpQFhFGt4JhTylnnhY= X-Received: by 2002:a37:9f42:: with SMTP id i63mr3585726qke.192.1583353733184; Wed, 04 Mar 2020 12:28:53 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Wed, 4 Mar 2020 15:28:16 -0500 Message-ID: To: SIDR Operations WG , draft-ietf-sidrops-ov-egress@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] AD review of draft-ietf-sidrops-ov-egress. 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: Wed, 04 Mar 2020 20:28:56 -0000 Thank you for this (short!) document. The basic idea seems like obviously a win -- however, in order to progress it there are some changes I'd like to see made - most of these fall into the process wonkey category, but addressing them now will help prevent people starting to fuss, and then getting all wrapped around the axle... 1: The document says: Updates: 6811 (if approved) please add a sentence to the Abstract saying how / what it updates in 6811. Something like: "This document updates RFC6811 by clarifying that implementations must use the effective origin AS to determine the Origin Validation state when applying egress policy". 2: Please use the updated (RFC8174) requirements language - I've included it below for easy copy-n-paste. 3: Please include an index - assuming you are using xml2rfc, should do it for you.... 4: Help my understand / justify why this is Standards Track and not BGP or Informational. The Shepherd writeup just says Standards Track with no explanation as to *why*. I suspect that the "Updates: 6811" might be the justification/ Apologies for the process wonkery, W "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here." -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Mar 4 12:47:25 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 BAEAF3A0841; Wed, 4 Mar 2020 12:47:22 -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.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <158335484269.29305.14161766948758530968@ietfa.amsl.com> Date: Wed, 04 Mar 2020 12:47:22 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-ov-egress-01.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: Wed, 04 Mar 2020 20:47:23 -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 : BGP RPKI-Based Origin Validation on Export Authors : Randy Bush Ruediger Volk Jakob Heitz Filename : draft-ietf-sidrops-ov-egress-01.txt Pages : 5 Date : 2020-03-04 Abstract: A BGP speaker may perform RPKI origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification uses the effective origin AS of the processed route, which may specifically be altered by the commonly available knobs such as removing private ASs, confederation handling, and other modifications of the origin AS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-ov-egress-01 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-ov-egress-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-ov-egress-01 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 Wed Mar 4 12:47:48 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 01C183A087E for ; Wed, 4 Mar 2020 12:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 6gim_hiAtHJd for ; Wed, 4 Mar 2020 12:47:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4C5813A0863 for ; Wed, 4 Mar 2020 12:47:38 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1j9avY-00052Y-Oy; Wed, 04 Mar 2020 20:47:36 +0000 Date: Wed, 04 Mar 2020 12:47:36 -0800 Message-ID: From: Randy Bush To: Warren Kumari Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] AD review of draft-ietf-sidrops-ov-egress. 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: Wed, 04 Mar 2020 20:47:47 -0000 > 1: The document says: Updates: 6811 (if approved) please add a > sentence to the Abstract saying how / what it updates in 6811. stole your text, tyvm, but added to intro not abstract > 2: Please use the updated (RFC8174) requirements language - I've > included it below for easy copy-n-paste. sure > 3: Please include an index - assuming you are using xml2rfc, toc="yes" ?> should do it for you.... you are welcome for the now less short document > 4: Help my understand / justify why this is Standards Track and not > BGP or Informational. The Shepherd writeup just says Standards Track > with no explanation as to *why*. I suspect that the "Updates: 6811" > might be the justification/ ask warren. he might have a good explanation. :) but i do not believe this belongs in the document. whack me otherwise. -01 published randy From nobody Wed Mar 4 13:49:40 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 AD68D3A09BA for ; Wed, 4 Mar 2020 13:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=kumari-net.20150623.gappssmtp.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 zGW--g3OO5FS for ; Wed, 4 Mar 2020 13:49:36 -0800 (PST) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 1B0B03A09B9 for ; Wed, 4 Mar 2020 13:49:36 -0800 (PST) Received: by mail-qv1-xf29.google.com with SMTP id m2so1509709qvu.13 for ; Wed, 04 Mar 2020 13:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eg4f3EpH+AsiyMW3JpfFxif0pQYWVIYONbCTwaJtjVs=; b=n3x1B7ybQqu7jpPFlCdUaLamyDfsJBxQ37kMADXc21B5Mx8fPk+7iwBWWPsrsfjZGa 6YFtf1qBePw//2Bf13moX1cQN2Hv1OTaSlsQ5xhh1ju2L/kixGzK8wPDaycYIeTEDhVi hliHDljAzRqAzUhpNYdVgycqS7Oi3fg8zdUC+4zqzEmDKEZ09lofD/DrvMJI0m/hTbT1 zahxigjS/CXBgUDeUXDHthFCsNXyYpPfb5vPPeJ6+V6whNxSTfSJZ2z4FuG4niFZ8Feu Sxp0MtpWaKXWR0J8dz32l/nsUcxXwgxr2zkZg0RT5itgQIA4uIsxaP9a7dPMBeEhIamA ziBQ== 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=eg4f3EpH+AsiyMW3JpfFxif0pQYWVIYONbCTwaJtjVs=; b=EbFE6d0gXTXZQcir9ebD0m3Jvo+CSJLg7mtemop6WAAa485tT9PZ/dOfiDaY5a2ssE E8CGdRwVW92UCNgIB9ADMaXErYM6dXhW84PgHQyvrBacY6pa4ITlETc/hNv5rdFX+5oc O+aoaKXERV36zXH12bcZ40lxojAiJB8UNnShOnFPSuLojxFd746arDT9zuQ5WdBwvXZB WMj9Sy3qUtSW4/U23XkBymamh1ANml1tOEoxRuivtmSEwjr1iaJ71H2RYnLZb75pLYqZ ADXBFbpHXeUg+kF2GkBo6mn6prGbY1/GSMhJfQTMaxKt/3EO94EiMMmWE1+LR7neGA3l k/1Q== X-Gm-Message-State: ANhLgQ0e9uBA/2wIIM58l4Ys6RVLkVAwBbFHQEwdG7qc0ozn3xSDdC26 mxN1ygvJcg5m9byisYVOB3DR9bnMv+7KXirWGIC1pMk7 X-Google-Smtp-Source: ADFU+vvdRTx/PKduLls/X3jliNhSnZqYb0UnKmvGuUC6alr9Tbzda9N13/88K1j2yYprrLjjIZiHfLS21MQcE8u+HQI= X-Received: by 2002:a05:6214:1784:: with SMTP id ct4mr3929797qvb.62.1583358574860; Wed, 04 Mar 2020 13:49:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Wed, 4 Mar 2020 16:48:58 -0500 Message-ID: To: Randy Bush Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000683c3105a00e656a" Archived-At: Subject: Re: [Sidrops] AD review of draft-ietf-sidrops-ov-egress. 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: Wed, 04 Mar 2020 21:49:38 -0000 --000000000000683c3105a00e656a Content-Type: text/plain; charset="UTF-8" On Wed, Mar 4, 2020 at 3:47 PM Randy Bush wrote: > > 1: The document says: Updates: 6811 (if approved) please add a > > sentence to the Abstract saying how / what it updates in 6811. > > stole your text, tyvm, but added to intro not abstract > > > 2: Please use the updated (RFC8174) requirements language - I've > > included it below for easy copy-n-paste. > > sure > > > 3: Please include an index - assuming you are using xml2rfc, > toc="yes" ?> should do it for you.... > > you are welcome for the now less short document > > > 4: Help my understand / justify why this is Standards Track and not > > BGP or Informational. The Shepherd writeup just says Standards Track > > with no explanation as to *why*. I suspect that the "Updates: 6811" > > might be the justification/ > > ask warren. he might have a good explanation. :) but i do not believe > this belongs in the document. whack me otherwise. > Ah, I was meaning just let me know via email, not in the document - apologies for not being clear. > > -01 published > Thanks, I'll kick off IETF LC. W > > randy > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000683c3105a00e656a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Mar 4, 2020 at 3:47 PM Randy= Bush <randy@psg.com> wrote:
=
> 1: The documen= t says: Updates: 6811 (if approved) please add a
> sentence to the Abstract saying how / what it updates in 6811.

stole your text, tyvm, but added to intro not abstract

> 2: Please use the updated (RFC8174) requirements language - I've > included it below for easy copy-n-paste.

sure

> 3: Please include an index=C2=A0 - assuming you are using xml2rfc, <= ;?rfc
> toc=3D"yes" ?> should do it for you....

you are welcome for the now less short document

> 4: Help my understand / justify why this is Standards Track and not > BGP or Informational. The Shepherd writeup just says Standards Track > with no explanation as to *why*. I suspect that the "Updates: 681= 1"
> might be the justification/

ask warren.=C2=A0 he might have a good explanation. :)=C2=A0 but i do not b= elieve
this belongs in the document.=C2=A0 whack me otherwise.

Ah, I was meaning just let me know via email, not in the docume= nt - apologies=C2=A0for not being clear.
=C2=A0

-01 published

Thanks, I'll kick off IETF= LC.=C2=A0
W

=C2=A0

randy


--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--000000000000683c3105a00e656a-- From nobody Wed Mar 4 14:59:11 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 7FBE53A0B4E; Wed, 4 Mar 2020 14:59:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk CC: sidrops@ietf.org, keyur@arrcus.com, draft-ietf-sidrops-ov-egress@ietf.org, warren@kumari.net, nathalie@ripe.net, sidrops-chairs@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158336274444.29483.18238070064182080116@ietfa.amsl.com> Date: Wed, 04 Mar 2020 14:59:04 -0800 Archived-At: Subject: [Sidrops] Last Call: (BGP RPKI-Based Origin Validation on Export) to Proposed Standard 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: Wed, 04 Mar 2020 22:59:05 -0000 The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'BGP RPKI-Based Origin Validation on Export' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-03-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A BGP speaker may perform RPKI origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification uses the effective origin AS of the processed route, which may specifically be altered by the commonly available knobs such as removing private ASs, confederation handling, and other modifications of the origin AS. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Mar 5 10:16:16 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 D21033A0883 for ; Thu, 5 Mar 2020 10:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 JRBYZJ4gnW1t for ; Thu, 5 Mar 2020 10:16:13 -0800 (PST) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 552C93A0890 for ; Thu, 5 Mar 2020 10:16:12 -0800 (PST) Received: by mail-wm1-f42.google.com with SMTP id j1so6765806wmi.4 for ; Thu, 05 Mar 2020 10:16:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=MiQyvcrgCS+EXraXm23MgiD40+O9mgJLDHHHSeIY6oI=; b=BU275HvZkAPiGEuyluOAPkm6Jx184truScPff+OAWrbse2dHRipSov1GT7nX83DrD8 v9m+GO2puVgHERAtN8qY5y9IaWpHw7EApOQtQE7Q7ij6tvdqRAk2bvA7HVWzDOPW/5sr 5GAPfNnLwij5hCLwlPsKhRLSb27m4Xu+ru7KZGehpG4KYW8yEtA03YfqNRNUL3do1Xq/ x+TIj+KP58oDxdqdGnE1ImI2y55NwgtpoDNAJEKDabqdFyGRUKJV8t2UW/F8keuZgfSS E+RYiMWvRLiQ1dNcChZWtKtcRgaPKAJqT3RM13BKNZFz99/c5qU+vZ3iogT+WAbZqWXk YdsQ== X-Gm-Message-State: ANhLgQ2Y2Z0Ar/BaY0h7C8pYIjSNi5YdHYL13LCIPyZp/aU1PHrKa9+K VaATr6r4aj4mKwTmZcPposWhYQEPAf2jyw== X-Google-Smtp-Source: ADFU+vt4BROIlqCFIbtJYTSkrblp7f0oVATK95vEUXH07SO/RxghPQPaFI9wpIPbXQs7bQanVPQswA== X-Received: by 2002:a7b:c257:: with SMTP id b23mr80411wmj.70.1583432170647; Thu, 05 Mar 2020 10:16:10 -0800 (PST) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id h10sm11241643wml.18.2020.03.05.10.16.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2020 10:16:10 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 33e0b30e; Thu, 5 Mar 2020 18:16:09 +0000 (UTC) Date: Thu, 5 Mar 2020 18:16:08 +0000 From: Job Snijders To: George Michaelson Cc: SIDR Operations WG Message-ID: <20200305181608.GG72556@vurt.meerval.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] AS0 testbed at APNIC 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, 05 Mar 2020 18:16:15 -0000 On Wed, Feb 26, 2020 at 04:27:39PM +1000, George Michaelson wrote: > If people would like to look at an AS0 state, > > APNIC's AS0 testbed TAL: > > https://registry-testbed.apnic.net/as0-test-ta.tal > > APNIC's AS0 testbed SLURM file: > > https://registry-testbed.apnic.net/as0-test-slurm.json > > ~3500 objects, we do not publish one ROA per prefix to avoid a large > object set, we do not publish one ROA for all AS0 to avoid a single > large object parsing burden. > > ~65000 prefixes, because of sparse V6 allocation outcomes fragmenting > the allocation spaces. OpenBSD's rpki-client seems to be able to work with this: job@vurt rpki$ doas ftp https://registry-testbed.apnic.net/as0-test-ta.tal Trying 203.119.106.17... Requesting https://registry-testbed.apnic.net/as0-test-ta.tal 454 bytes received in 0.00 seconds (1.99 MB/s) job@vurt rpki$ doas rpki-client -v -t as0-test-ta.tal rpki-client: registry-testbed.apnic.net/as0-test: loading rpki-client: period stats: 1 pending repos rpki-client: period stats: 1 pending entries rpki-client: period stats: 1 pending repos rpki-client: period stats: 1 pending entries rpki-client: period stats: 1 pending repos rpki-client: period stats: 1 pending entries rpki-client: period stats: 1 pending repos rpki-client: period stats: 1 pending entries rpki-client: period stats: 1 pending repos rpki-client: period stats: 1 pending entries rpki-client: period stats: 1 pending repos rpki-client: period stats: 1 pending entries rpki-client: registry-testbed.apnic.net/as0-test: loaded rpki-client: all files parsed: generating output rpki-client: Route Origin Authorizations: 3525 (0 failed parse, 0 invalid) rpki-client: Certificates: 3 (0 failed parse, 0 invalid) rpki-client: Trust Anchor Locators: 1 rpki-client: Manifests: 3 (0 failed parse, 0 stale) rpki-client: Certificate revocation lists: 3 rpki-client: Repositories: 1 rpki-client: VRP Entries: 62315 (62315 unique) job@vurt rpki$ grep -cv :: /var/db/rpki-client/openbgpd 1399 job@vurt rpki$ grep -c :: /var/db/rpki-client/openbgpd 60918 job@vurt rpki$ doas du -sh /var/cache/rpki-client/registry-testbed.apnic.net/ 20.9M /var/cache/rpki-client/registry-testbed.apnic.net/ Kind regards, Job From nobody Thu Mar 5 14:17:46 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 9D5DD3A0D5D for ; Thu, 5 Mar 2020 14:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.20150623.gappssmtp.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 FdQaLX91r9Bj for ; Thu, 5 Mar 2020 14:17:35 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 A94633A0D66 for ; Thu, 5 Mar 2020 14:17:35 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id u17so111408iog.11 for ; Thu, 05 Mar 2020 14:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=87A84aY5A6E3AtbUjgmEbzOT97eYrOx+pT2S1oirpY4=; b=zI0IEAbCczDsh8J6aF7CXK4d5tRCYfbTXLRz7Y3933OeccyZ3nNru/tq2ey1FHnHhC n7JuLwIJz1RVIAksWgKnNey39B5xgDYhfAgLLiba99/UbgCP/fy4LbyJXl74Yk9lKBz4 PsCw2S8IoGl7Z/J59zIz6gYewCFFI2v961vOkSjjWz2q+gpTwc/DjwXOeWQ2yLVTINqT M+6JHVy+DCBmaM9fk+ypJzRCnloA3eiVbQumU5Hm0pa3ssk1Esc1p7PS6A9mnkP0Lxsg hYdCwtwuTyVT81VweBbCM8PdQ4CpuElwlMTd9Fc1NcKwnnyb/u1U0m47viE5iPV9XSXj 7fJA== 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=87A84aY5A6E3AtbUjgmEbzOT97eYrOx+pT2S1oirpY4=; b=pvDq4wMgA//M5G6nbYNOW9UNwdgMT563k+R/2J0K+aQtFkGilkjN1CmnzTELeYsYNf N826O+Z0lAPdkH5IiNhimpFBa2S6HKbafyezvT+mj16p52r6iVeRbpVpXwmnXbbp+LZv vp9KH7BrXach3SM9/Ox71rstAl1Zia+UkyA9a89L8rYpBZ3pQhaUd86Ncfi0KvYZwTrc IhjQ+mUT6p0W15TYKpmRqTIpWvTcqiydblaxgergwyaGebFXBb+w7kyimNimIeRZefPS 0Bu8WmV5zrqaVBLMJGHL7EF1/4bxf59ytqLBK3rsXH8GpWKZ0sOHotzAncKIHC12PvnF R0mA== X-Gm-Message-State: ANhLgQ3rCkjHV7WavrM/ud843U8aAmZvtNJVK1/Q8Kc3ZDtwCryZX3Hc 9RthKuwtyeGRz1O3zBk4pHN1jVR2DRjXm13+9cg16XVU X-Google-Smtp-Source: ADFU+vsdTq61p3YqS23cdqGSE7GD68JztLOMMxXDNhVZqn2PUONWbb6tFAHjwxnKEdY3nOlEkDUIw73OiTgyD3QPKcE= X-Received: by 2002:a5d:8f06:: with SMTP id f6mr494686iof.137.1583446654733; Thu, 05 Mar 2020 14:17:34 -0800 (PST) MIME-Version: 1.0 References: <20200305181608.GG72556@vurt.meerval.net> In-Reply-To: <20200305181608.GG72556@vurt.meerval.net> From: George Michaelson Date: Fri, 6 Mar 2020 08:17:23 +1000 Message-ID: To: Job Snijders Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] AS0 testbed at APNIC 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, 05 Mar 2020 22:17:45 -0000 Thanks. Much appreciated. -G From nobody Fri Mar 6 04:01:37 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 794BD3A0DB5 for ; Fri, 6 Mar 2020 04:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 nT2V7v7drruM for ; Fri, 6 Mar 2020 04:01:32 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 4B0B93A0DB3 for ; Fri, 6 Mar 2020 04:01:31 -0800 (PST) Received: from glaurung.nlnetlabs.nl (unknown [IPv6:2a04:b904::a2c5:89ff:feb5:e311]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 891171A75E; Fri, 6 Mar 2020 13:01:29 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Fri, 6 Mar 2020 13:01:29 +0100 From: Martin Hoffmann To: Randy Bush Cc: SIDR Operations WG Message-ID: <20200306130129.59c888c1@glaurung.nlnetlabs.nl> In-Reply-To: References: <158274065310.22955.10729466847169070546.idtracker@ietfa.amsl.com> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt 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: Fri, 06 Mar 2020 12:01:35 -0000 Randy Bush wrote: > A new version of I-D, draft-ymbk-8210bis-00.txt has been successfully > submitted by Randy Bush and posted to the IETF repository. I=E2=80=99d like to bring up my earlier proposal to exchange the ASPA conte= nts as pairs rather than lists again. In this case, the ASPA Payload would look like this: 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | 2 | 11 | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | | | | Flags | zero | | | | +-------------------------------------------+ | | | Customer Autonomous System Number | | | +-------------------------------------------+ | | | Provider Autonomous System Number | | | ~-------------------------------------------~ Much like all the prefixes on a ROA, there would be one ASPA Payload PDU for each provider ASN in the ASPA RPKI object. The main reason for proposing this is that this will bring handling of ASPA PDUs in line with all the other payload PDUs in that the combined payload is treated as a set: Each payload unit forms its own key for lookups. Which is what makes the current announce/withdraw model work. The ASPA PDU proposed in the draft works like a map: The key is the customer ASN and the list of provider ASNs is the value. Having two different ways of dealing with payload increases complexity, both in the standard and in the implementations. Splitting up the ASPA RPKI object would increase the overall size of the response to a RTR reset query, but on the other hand decreases the overall size of serial queries. Given that RTR sessions are very long-lived, I think (without any actual evidence), that there might even be an overall advantage in data size. * * * As a separate note, ASPA in its current form includes the address family, ie., it has different ASPA objects for v4 and v6. This is missing from the proposed ASPA RTR payload PDU, but luckily there is enough zero space to include it. Kind regards, Martin From nobody Fri Mar 6 06:18:06 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 96A613A079A for ; Fri, 6 Mar 2020 06:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 WMVzmYyBMG0B for ; Fri, 6 Mar 2020 06:18:03 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 27F383A0799 for ; Fri, 6 Mar 2020 06:18:03 -0800 (PST) Received: from [193.0.23.13] (helo=bufobufo.ripe.net) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jADnd-00070B-Qc for sidrops@ietf.org; Fri, 06 Mar 2020 15:18:01 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::3d6]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1jADnd-00080Z-OM for sidrops@ietf.org; Fri, 06 Mar 2020 15:18:01 +0100 References: <157914534015.22379.11024327123542212494@ietfa.amsl.com> <920CAE43-E94A-45A1-AD2C-86095F396E96@nlnetlabs.nl> From: Robert Kisteleki Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd Organization: RIPE NCC To: SIDR Operations WG Message-ID: Date: Fri, 6 Mar 2020 15:18:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <920CAE43-E94A-45A1-AD2C-86095F396E96@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274e6c7dc57edf436d7ebefba7eeb876f18 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-05.txt 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: Fri, 06 Mar 2020 14:18:05 -0000 On 2020-03-04 09:55, Tim Bruijnzeels wrote: > Hi, > > I believe that we should discuss the concerns raised by Rob. Whether that is in the context of a working group last call or not.. I don't really mind the process. Hi, Thank you Tim for your thoughts. I do agree that more discussion is warranted about pros/cons for this approach. Perhaps a wider threat modelling would be useful. Speaking for myself only: I believe that at the end of the day the in-band approach the draft proposes has more downsides than upsides. YMMV. Now, if there weren't alternative approaches, then I'd also say "it addresses a perceived problem so why not?" -- but there *are* real-life alternatives. George reiterated a few: >> Rob suggested we consider why browsers ship TA changes by updating >> code. That moves the burden to a body who agrees what TAL need to be >> shipped, and liaison with the Validator authors and release processes. >> >> Or, a hand-run process to use this mechanism. (BTW I did not suggest this :-) >> Or, a signalling mechanism to flag "this TAL needs to change" but the >> actual decision to change, is hand-managed buy the RP. My ordering would put (3) on top, closely followed by (1). (3) has many upsides: it can warn the operator if there's a TAL change *even if* the software is otherwise not upgraded. This allows the operator to do a manual double-check if that's desired. It even allows an automatic update (I imagine it can be a RP software option). In other words, it makes it the operators' decision to do the update in-band or not. (1) is an example of how a mechanism for achieving comparable outcomes works really well in a different context, on a much bigger scale. It also leaves the operator in full control, if that's desired. All in all, I'm not against this draft per se. But I do want to make sure we consider if it provides the best approach to the problem. Robert From nobody Fri Mar 6 10:42:04 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 2105F3A0366 for ; Fri, 6 Mar 2020 10:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NzsBRWKUoMUt for ; Fri, 6 Mar 2020 10:41:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 38AC93A03EC for ; Fri, 6 Mar 2020 10:41:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jAHv1-0002Xt-Af; Fri, 06 Mar 2020 18:41:55 +0000 Date: Fri, 06 Mar 2020 10:41:54 -0800 Message-ID: From: Randy Bush To: Robert Kisteleki Cc: SIDR Operations WG In-Reply-To: References: <157914534015.22379.11024327123542212494@ietfa.amsl.com> <920CAE43-E94A-45A1-AD2C-86095F396E96@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-05.txt 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: Fri, 06 Mar 2020 18:42:02 -0000 automatic modification of trusted credentials is scary. but assuming the folk who understand the bgp and server configurations have not moved to marrakesh is na=EFve. as to pre-notification of an upcoming automatic change; i suspect very few who are not in this 'room' actually monitor rpki caches in any way. this will not improve. will such dilemmas drive us toward centralised cache services at google, yandex, ...? and then we will have serious transport security issues. i wanna go back to 1996. randy From nobody Fri Mar 6 13:06:58 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 ACF5D3A0A93; Fri, 6 Mar 2020 13:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 I3jq8854XtqF; Fri, 6 Mar 2020 13:06:54 -0800 (PST) Received: from relay.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8593A0A92; Fri, 6 Mar 2020 13:06:51 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 783A13C228D; Fri, 6 Mar 2020 21:06:50 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 331BD3BB; Fri, 6 Mar 2020 21:06:50 +0000 (UTC) Date: Fri, 06 Mar 2020 21:06:50 +0000 Message-ID: <87sgilgplh.wl-morrowc@ops-netman.net> From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] Meeting in Vancouver 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: Fri, 06 Mar 2020 21:06:57 -0000 Howdy WG folks, The chairs are unsure of their attendance status at this point in time. Given that we're going to ask to cancel our WG session at the in-person venue and seek advice on timing / need for a Virtual Interim Meeting in April as a replacement. So, dont' travel on our account (we aren't for your account!) see you either virtually in April-ish, or in Madrid in July. -chris co-chair From nobody Fri Mar 6 13:15:31 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 D5C703A0AB8 for ; Fri, 6 Mar 2020 13:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iEoFsK05F1cR for ; Fri, 6 Mar 2020 13:15:27 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A866E3A0AC0 for ; Fri, 6 Mar 2020 13:15:27 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jAKJZ-0002tW-2A; Fri, 06 Mar 2020 21:15:25 +0000 Date: Fri, 06 Mar 2020 13:15:24 -0800 Message-ID: From: Randy Bush To: Martin Hoffmann Cc: SIDR Operations WG In-Reply-To: <20200306130129.59c888c1@glaurung.nlnetlabs.nl> References: <158274065310.22955.10729466847169070546.idtracker@ietfa.amsl.com> <20200306130129.59c888c1@glaurung.nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt 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: Fri, 06 Mar 2020 21:15:29 -0000 > ASPA in its current form includes the address family, ie., it has > different ASPA objects for v4 and v6. This is missing from the > proposed ASPA RTR payload PDU, but luckily there is enough zero space > to include it. a point to be settled between aspa and rpk-rtrv2. do we really see significant divergence between ipv4 and ipv6 topologies? if so, is this a good thing which should be supported at the cost of two tables in the router? thanks for raising the issue. randy From nobody Fri Mar 6 13:30:12 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 65FDC3A0B09; Fri, 6 Mar 2020 13:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Pr5Y-ZwtEp2b; Fri, 6 Mar 2020 13:30:10 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2C0DE3A0B0B; Fri, 6 Mar 2020 13:30:10 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jAKXo-0002ve-MD; Fri, 06 Mar 2020 21:30:09 +0000 Date: Fri, 06 Mar 2020 13:30:08 -0800 Message-ID: From: Randy Bush To: Chris Morrow Cc: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org In-Reply-To: <87sgilgplh.wl-morrowc@ops-netman.net> References: <87sgilgplh.wl-morrowc@ops-netman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Meeting in Vancouver 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: Fri, 06 Mar 2020 21:30:12 -0000 i am sure of my non-attendance i would like to learn more about o aspa and rpki-rtrv2 o tal migration magic o manifest and crl lifetimes and dealing with errors o draft-yan-sidrops-roa-considerations should imiho progress randy From nobody Fri Mar 6 15:51:18 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 5EFCD3A0DC8; Fri, 6 Mar 2020 15:51:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk CC: sidrops-chairs@ietf.org, nathalie@ripe.net, warren@kumari.net, sidrops@ietf.org, Nathalie Trenaman , draft-ietf-sidrops-rp@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158353867228.2192.16622456423428062751@ietfa.amsl.com> Date: Fri, 06 Mar 2020 15:51:12 -0800 Archived-At: Subject: [Sidrops] Last Call: (Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties) to Informational RFC 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: Fri, 06 Mar 2020 23:51:13 -0000 The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-03-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI) in the context of securing Internet routing. It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 6 18:59:50 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 27FEE3A10DF for ; Fri, 6 Mar 2020 18:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 fSJ5MCMZojiJ for ; Fri, 6 Mar 2020 18:59:46 -0800 (PST) Received: from smtpbgau1.qq.com (smtpbgau1.qq.com [54.206.16.166]) (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 B63853A10DE for ; Fri, 6 Mar 2020 18:59:43 -0800 (PST) X-QQ-mid: bizesmtp24t1583549972tw1huahs Received: from [192.168.3.24] (unknown [117.100.110.112]) by esmtp10.qq.com (ESMTP) with id ; Sat, 07 Mar 2020 10:59:30 +0800 (CST) X-QQ-SSF: 00400000002000N0ZI80B00A0000000 X-QQ-FEAT: F8xs2aWDdZhf99NVpDa5SPRyAETGFBfvmuooGhpL16HpgKM6tK9ILt3PTV92M Hull1ltltIlAtgwwgn4ebCQJkuD0FiY7EcIYfqYMT1LypwfYoxNi1wdQl5QJJ0oQL6URGUm Zf3RWH6fW4IU/w85F+LqHndOzXFtsjO0sZTjyqZt/rTcd5rxM2IXV3WgUmVfWkpQf2WGsw4 xGEE517MgtPKabXSUWUMe12/76uYK4zu5037zy5HFJmq0xv7UUF+IAPjiUxyWoqEwZaVX2Y CEGWczVMeEiRLZunAZCJ3/8NNnrGb4RmBBK3OVQrkNpw6ZfbWtucylVcb7mj+PWlZdk58Xf mkURmrKhcYjUybrzuY= X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Di Ma In-Reply-To: Date: Sat, 7 Mar 2020 10:59:30 +0800 Cc: Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <210B997D-67FC-4688-A1EC-7B46DD50BA22@zdns.cn> References: <87sgilgplh.wl-morrowc@ops-netman.net> To: Randy Bush X-Mailer: Apple Mail (2.3608.60.0.2.5) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign6 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] Meeting in Vancouver 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: Sat, 07 Mar 2020 02:59:49 -0000 I really look forwards to discussions on manifest and CRL lifetimes and = dealing with errors. Di > 2020=E5=B9=B43=E6=9C=887=E6=97=A5 05:30=EF=BC=8CRandy Bush = =E5=86=99=E9=81=93=EF=BC=9A >=20 > i am sure of my non-attendance >=20 > i would like to learn more about > o aspa and rpki-rtrv2 > o tal migration magic > o manifest and crl lifetimes and dealing with errors > o draft-yan-sidrops-roa-considerations should imiho progress >=20 > randy >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 From nobody Sun Mar 8 16:31:28 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 B2A673A0B6B for ; Sun, 8 Mar 2020 16:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 nUye79Ylt4NJ for ; Sun, 8 Mar 2020 16:31:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 7A1973A0B6C for ; Sun, 8 Mar 2020 16:31:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jB5OF-0000Lj-JP for sidrops@ietf.org; Sun, 08 Mar 2020 23:31:23 +0000 Date: Sun, 08 Mar 2020 16:31:23 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] Validation violations 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: Sun, 08 Mar 2020 23:31:27 -0000 http://valid.rg.net:8080/trust-anchors is not ideal From nobody Sun Mar 8 16:38:15 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 0DE503A0B93 for ; Sun, 8 Mar 2020 16:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GojNqs8eEmf4 for ; Sun, 8 Mar 2020 16:38:12 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228D23A0B92 for ; Sun, 8 Mar 2020 16:38:11 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 028Nc8mD027711 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Mar 2020 23:38:08 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Randy Bush Cc: SIDR Operations WG References: From: Nick Hilliard Message-ID: Date: Sun, 8 Mar 2020 23:38:07 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.12 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] Validation violations 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: Sun, 08 Mar 2020 23:38:14 -0000 Randy Bush wrote on 08/03/2020 23:31: > http://valid.rg.net:8080/trust-anchors is not ideal a commitment to long-term stability? Overwhelming weariness because changing root certs is such a drag? Something else? Nick From nobody Sun Mar 8 16:46:16 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 0FCB63A0BA7 for ; Sun, 8 Mar 2020 16:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=virtualized-org.20150623.gappssmtp.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 J8qE3BSfV8AQ for ; Sun, 8 Mar 2020 16:46:12 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 E29393A0BA6 for ; Sun, 8 Mar 2020 16:46:12 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id gv19so3586566pjb.5 for ; Sun, 08 Mar 2020 16:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XPsvVpWacqbb3jDFJlAInBICY617iP/y8CliCSS6OL0=; b=GsbAmhkx6ua1Hu7fTXVcePU3scPtO+y5txpCcyBgXT5ojftic8aojrmd902WHLAFCD ZoB2oTzsL2BND7emcuSrWVGkwZLZWurPVRosKlqTblbhyOAOQ5sh3y38Lp433iQIysak 3Yctu5VklejQAqm2hWCVcJwQwvDfd7JIFyH09aDrpkCrT2de4ykFQfmjLKacewmMDqLQ Ke+DPh4iWwLduMNKMS63ANiUFAlTeYRku2CL48KlEwS7nBsi5VOMEb2Yim7GDite1HLt +ziDxcIxevWauTa1TPC07InK+WnKhDVqj92Jot7hGCCKbVSZ+kz/vJP8HoEt3NrOhsOd fIOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XPsvVpWacqbb3jDFJlAInBICY617iP/y8CliCSS6OL0=; b=nP0+r2VGLf9ctTtn5fXr4Km4gTLh+R2ZK3zx0BpKUMMdU1o5P1ijukMHKIuNFWRfgj mJL/BJLspcgsma6nmHUh90TYh8r9wHCHD3DYOxBDqAIeKLw3qOxWaD43oLL0DTSp6irL qB0cNNUl1Q6fs8uLauYyIrM70nQNkaTl2F4jJnDvHiT98xGGXuNCOvvYl8UB70VxH+n4 3x7l7+xPGJYu75RvCBpQs67ncNxB7Md/oJd0Me9IzVZpZvPGkJTk6Cfkkoz7dFpFPFgB 2weTw50ovDA2xP8n6bpGAt7FZiJuM7FulbkIQEkIFUQB4Mkmv0qfP4Mf18sTXmyL1Sp7 fNuw== X-Gm-Message-State: ANhLgQ2GXU65o0eTKgwiu/efYFeethdjt7hVU26Nj411AAghZV+LPJto 0w8+CW5jzOh5C3//88i9fjkJ5g== X-Google-Smtp-Source: ADFU+vuDpBO514ENlPItf8J97I58EJDXOyVG9NOlDdCO6BndLQca2zgMQMOQMB55rblvPgDMZjQ6oA== X-Received: by 2002:a17:90a:bf81:: with SMTP id d1mr16093691pjs.21.1583711172122; Sun, 08 Mar 2020 16:46:12 -0700 (PDT) Received: from ?IPv6:2606:6000:62c7:9900:3d0c:7c1b:8e30:d3d8? ([2606:6000:62c7:9900:3d0c:7c1b:8e30:d3d8]) by smtp.gmail.com with ESMTPSA id e189sm37974074pfa.139.2020.03.08.16.46.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Mar 2020 16:46:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: David Conrad In-Reply-To: Date: Sun, 8 Mar 2020 16:46:05 -0700 Cc: Randy Bush , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nick Hilliard X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] Validation violations 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: Sun, 08 Mar 2020 23:46:14 -0000 One might make a comparison to the expiration of the DNSSEC root trust = anchor=E2=80=A6 Regards, -drc > On Mar 8, 2020, at 4:38 PM, Nick Hilliard wrote: >=20 > Randy Bush wrote on 08/03/2020 23:31: >> http://valid.rg.net:8080/trust-anchors is not ideal >=20 > a commitment to long-term stability? >=20 > Overwhelming weariness because changing root certs is such a drag? >=20 > Something else? >=20 > Nick >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Sun Mar 8 17:21:48 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 3F73B3A0C4E for ; Sun, 8 Mar 2020 17:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 sgSJHENWRNjA for ; Sun, 8 Mar 2020 17:21:44 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 8FE753A0C4D for ; Sun, 8 Mar 2020 17:21:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jB6Av-0000W3-Ua for sidrops@ietf.org; Mon, 09 Mar 2020 00:21:42 +0000 Date: Sun, 08 Mar 2020 17:21:41 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Validation violations 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: Mon, 09 Mar 2020 00:21:47 -0000 > http://valid.rg.net:8080/trust-anchors is not ideal yes, alex; that's an old version. :) i just give the grad stuents a vm; not control it. randy From nobody Sun Mar 8 17:53:21 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 88AC13A0CE1 for ; Sun, 8 Mar 2020 17:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 847vajxlgSkI for ; Sun, 8 Mar 2020 17:53:06 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 359B63A0CDD for ; Sun, 8 Mar 2020 17:53:00 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.93) with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from ) id 1jB6et-001OmO-As; Mon, 09 Mar 2020 01:52:39 +0100 Received: from x4dbf388b.dyn.telefonica.de ([77.191.56.139] helo=mw-x1.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1jB6et-002XDT-4E>; Mon, 09 Mar 2020 01:52:39 +0100 Date: Mon, 9 Mar 2020 01:52:38 +0100 From: Matthias Waehlisch To: Randy Bush cc: SIDR Operations WG , "Thomas C. Schmidt" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (WNT 404 2020-02-06) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Originating-IP: 77.191.56.139 Archived-At: Subject: Re: [Sidrops] Validation violations 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: Mon, 09 Mar 2020 00:53:20 -0000 I can update tomorrow (even though i'm not sure whether this is only a sw update problem). we run the old version because my impression was that Validator 3.x was less stable than previous versions. anyhow, think about the other deployments ... fixing one version doesn't help to improve the ecosystem. Cheers matthias On Sun, 8 Mar 2020, Randy Bush wrote: > > http://valid.rg.net:8080/trust-anchors is not ideal > > yes, alex; that's an old version. :) > > i just give the grad stuents a vm; not control it. > > randy > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From nobody Sun Mar 8 17:59: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 A0C923A0CFC for ; Sun, 8 Mar 2020 17:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 QwHNjDwWcwBv for ; Sun, 8 Mar 2020 17:59:30 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 934B33A0D01 for ; Sun, 8 Mar 2020 17:59:15 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id f5so7146728ilq.5 for ; Sun, 08 Mar 2020 17:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9eKJcCpznDC28wWnEjdnYlRuyUCyoXD+7w7F1i3ayW8=; b=n0JHFmaZMpzLY9VPgApQOq0CPRtXP1S4c03v/MY3fzCzf4AJJQF0VZbzZCzd/UDkO0 JtYYKfr8RkSfA9fPVnbkGQ2pL5JRVAjUlBtCGCvDVgnVVoZFIAPdT002pf4bBfaOiKb4 XU/UtYsCMlEJFuhDrHSi5zJ5ZcvuEyc81o1SR2qbk/FK7uCToVFbWXizlik5hLyq0snJ JhdCrVIWh3zSDGXJCS1SizjZIeR5tGwb+bxQ1jtFMcOvEap9oQYz/G4qzVnY28iiuBlH 3gDlWUVgoyOUSOIxIxc41a7zXG2ocNka1YuNnit722wNV3mR1ZuUQxHDrsiBM0tVvSYA IhEA== 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=9eKJcCpznDC28wWnEjdnYlRuyUCyoXD+7w7F1i3ayW8=; b=oDxJBqLFPNj/Eo+Q3TFK9o4QUJW++s2htvnL+ihRlESqNFgcUt7k9UZMPeUhOzkIt2 z4FdDAqK+cOpz6vnYmm6M6lj9MTQ72MJXCaHhUlGVRQw87K9IwB5c3mS1HE8x5FkjFSw wa9j3VZFgifdoy8VXG7NrRZ9HqeLnh6Sy8HvGPPw/nCizcyiu5Im18M4aY45XXUK4C23 fAVjZCJn5H6/ZQBzlJ1A3P9aPmD2eGbutMVXl9OZtAQV7CMUaXIIDRJpsENuAlWHr59i btBr/VSNez7B3siki2X3qikqETQi+q1R43wXrrIKMIMgPf3NN55KlsvKLyBctEBMGNe/ vbvQ== X-Gm-Message-State: ANhLgQ0OsU4qIIdZ/FMDmPXOCpy83obYEJZ35RHaOteZBxAN+4HUd+rs 7CSSKD8fqQqw6VU19Rz+vo80fd4Zvvi6ndg/7zMyFw== X-Google-Smtp-Source: ADFU+vv9KEQZwhMYQ/6leKMCqehH3hHszVfyZnYZD3IoxDQuHhH+NpveE2xPiMDH7Cfxrk5AOxSKTGaULYfClcLKVSA= X-Received: by 2002:a92:5c0a:: with SMTP id q10mr8866463ilb.65.1583715551782; Sun, 08 Mar 2020 17:59:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: George Michaelson Date: Mon, 9 Mar 2020 10:59:00 +1000 Message-ID: To: Matthias Waehlisch Cc: Randy Bush , "Thomas C. Schmidt" , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] Validation violations 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: Mon, 09 Mar 2020 00:59:42 -0000 Upgrading to 3.1 is sensible. its a better codebase. But, not all of the problems go away simply by updating: Some of this is down to what I call 'incoherent' state in the publish cycle. Being able to fetch a manifest and CRL which don't align in time with the repository state is not good. -G On Mon, Mar 9, 2020 at 10:56 AM Matthias Waehlisch wrote: > > > I can update tomorrow (even though i'm not sure whether this is only a > sw update problem). we run the old version because my impression was > that Validator 3.x was less stable than previous versions. anyhow, think > about the other deployments ... fixing one version doesn't help to > improve the ecosystem. > > > Cheers > matthias > > On Sun, 8 Mar 2020, Randy Bush wrote: > > > > http://valid.rg.net:8080/trust-anchors is not ideal > > > > yes, alex; that's an old version. :) > > > > i just give the grad stuents a vm; not control it. > > > > randy > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > > > > -- > Matthias Waehlisch > .. Freie Universitaet Berlin, Computer Science > ... http://www.cs.fu-berlin.de/~waehl > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Mar 9 01:46:35 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 107FC3A0A5F for ; Mon, 9 Mar 2020 01:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OpLaLO55-Cie for ; Mon, 9 Mar 2020 01:46:32 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 128073A0A5E for ; Mon, 9 Mar 2020 01:46:31 -0700 (PDT) Received: from [193.0.23.13] (helo=bufobufo.ripe.net) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jBE3R-0009SJ-9R; Mon, 09 Mar 2020 09:46:29 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::70c]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jBE3R-0004KX-72; Mon, 09 Mar 2020 09:46:29 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Nathalie Trenaman In-Reply-To: Date: Mon, 9 Mar 2020 09:46:28 +0100 Cc: Matthias Waehlisch , Randy Bush , "Thomas C. Schmidt" , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <48A08EF5-F932-4249-93EC-CE0E9ED7784E@ripe.net> References: To: George Michaelson X-Mailer: Apple Mail (2.3608.60.0.2.5) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a32ea8d8bdda6d470268b6989c0abb388 Archived-At: Subject: Re: [Sidrops] Validation violations 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: Mon, 09 Mar 2020 08:46:34 -0000 +1 for upgrading to 3.1. As for the problematic repos in the RIPE = region, we do try to chase them to fix things. Not sure if we should = though.=20 Nathalie > Op 9 mrt. 2020, om 01:59 heeft George Michaelson = het volgende geschreven: >=20 > Upgrading to 3.1 is sensible. its a better codebase. >=20 > But, not all of the problems go away simply by updating: Some of this > is down to what I call 'incoherent' state in the publish cycle. Being > able to fetch a manifest and CRL which don't align in time with the > repository state is not good. >=20 > -G >=20 > On Mon, Mar 9, 2020 at 10:56 AM Matthias Waehlisch > wrote: >>=20 >>=20 >> I can update tomorrow (even though i'm not sure whether this is only = a >> sw update problem). we run the old version because my impression was >> that Validator 3.x was less stable than previous versions. anyhow, = think >> about the other deployments ... fixing one version doesn't help to >> improve the ecosystem. >>=20 >>=20 >> Cheers >> matthias >>=20 >> On Sun, 8 Mar 2020, Randy Bush wrote: >>=20 >>>> http://valid.rg.net:8080/trust-anchors is not ideal >>>=20 >>> yes, alex; that's an old version. :) >>>=20 >>> i just give the grad stuents a vm; not control it. >>>=20 >>> randy >>>=20 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>>=20 >>=20 >>=20 >> -- >> Matthias Waehlisch >> .. Freie Universitaet Berlin, Computer Science >> ... http://www.cs.fu-berlin.de/~waehl >>=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 From nobody Mon Mar 9 02:41:02 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 00E563A0B8A for ; Mon, 9 Mar 2020 02:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (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 3FVdu8Wz-tnE for ; Mon, 9 Mar 2020 02:40:58 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 BA3AE3A0B88 for ; Mon, 9 Mar 2020 02:40:56 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:c965:e681:e9b3:284c] (unknown [IPv6:2001:981:4b52:1:c965:e681:e9b3:284c]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 61FD01D8A4; Mon, 9 Mar 2020 10:40: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=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1583746854; bh=zGEc9UFgS0fgxklVkueLuwldmDOkfYs5FO4hF4e2x2M=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=TFAblSGkEc4i0+ciLKvEmYU3NfY/Zz2OGKfM9HNVRokRTTbm2rrKcd2Q/MHtjDfqO zMfy6SQQM/zl4zE0838Qyem9041BgAXRRoH1XdmAhv+tNxgTaPogFt8Vy2RfH+234U 5oEqFbSjYPm8dZ1VzT0NrCM8Pb5WTmpvU2f2GeTg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: <48A08EF5-F932-4249-93EC-CE0E9ED7784E@ripe.net> Date: Mon, 9 Mar 2020 10:40:52 +0100 Cc: George Michaelson , Randy Bush , "Thomas C. Schmidt" , SIDR Operations WG , Matthias Waehlisch Content-Transfer-Encoding: quoted-printable Message-Id: References: <48A08EF5-F932-4249-93EC-CE0E9ED7784E@ripe.net> To: Nathalie Trenaman X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] Validation violations 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: Mon, 09 Mar 2020 09:41:00 -0000 Hi, So, Nathalie, I think you are now referring to the issues listed on this = page under the TAs, which are actually issues with CAs in the tree of a = TA. To the casual reader they look like they are the responsibility of that = TA, and I guess I am partly to blame for that, going back to working I = did on this page at RIPE NCC. But, this raises questions that I would like to ask sidrops: Do people = think that parent CAs should actively monitor delegated CAs? In case = they produce errors and don't fix them.. should any action be desired? = Ultimately the parent can reach out only so much, and then come to a = point where they can only revoke a child - which is rather drastic. I = think a lot of this comes down to agreements between the parent and the = child as well. I am not sure that we force this as a technical = community. So, while these things stick out, we may have to accept that unreachable = repositories, and unmaintained (stale as well as expired) publications = by CAs, are a reality in delegated RPKI. Personally I think that parent CAs, especially the RIRs should seek to = provide publication services to others, so that the number of = repositories and repositories with issues can be managed. But with more delegated CAs popping up I found that there are other = things that should be considered, like: - maybe we should extend the publication protocol to be able to enforce = limits (size and number of objects, possibly even only allow = syntactically correct RPKI objects) - maybe parents should monitor for children who make millions of ROAs, = or delegations, or which try to create validation loops. (e.g. in their = own repository) I think that in spirit the parent CAs keep an eye on these things, and = they can revoke reactively. I am not even sure that we can dictate good = parenting practice in this forum. But, I do think it's a discussion that = we need to have. Tim > On 9 Mar 2020, at 09:46, Nathalie Trenaman wrote: >=20 > +1 for upgrading to 3.1. As for the problematic repos in the RIPE = region, we do try to chase them to fix things. Not sure if we should = though.=20 >=20 > Nathalie >=20 >> Op 9 mrt. 2020, om 01:59 heeft George Michaelson = het volgende geschreven: >>=20 >> Upgrading to 3.1 is sensible. its a better codebase. >>=20 >> But, not all of the problems go away simply by updating: Some of this >> is down to what I call 'incoherent' state in the publish cycle. Being >> able to fetch a manifest and CRL which don't align in time with the >> repository state is not good. >>=20 >> -G >>=20 >> On Mon, Mar 9, 2020 at 10:56 AM Matthias Waehlisch >> wrote: >>>=20 >>>=20 >>> I can update tomorrow (even though i'm not sure whether this is only = a >>> sw update problem). we run the old version because my impression was >>> that Validator 3.x was less stable than previous versions. anyhow, = think >>> about the other deployments ... fixing one version doesn't help to >>> improve the ecosystem. >>>=20 >>>=20 >>> Cheers >>> matthias >>>=20 >>> On Sun, 8 Mar 2020, Randy Bush wrote: >>>=20 >>>>> http://valid.rg.net:8080/trust-anchors is not ideal >>>>=20 >>>> yes, alex; that's an old version. :) >>>>=20 >>>> i just give the grad stuents a vm; not control it. >>>>=20 >>>> randy >>>>=20 >>>> _______________________________________________ >>>> Sidrops mailing list >>>> Sidrops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidrops >>>>=20 >>>=20 >>>=20 >>> -- >>> Matthias Waehlisch >>> .. Freie Universitaet Berlin, Computer Science >>> ... http://www.cs.fu-berlin.de/~waehl >>>=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 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Mar 9 04:22:10 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 E7C5C3A0D30 for ; Mon, 9 Mar 2020 04:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Lcf5k7v95mme for ; Mon, 9 Mar 2020 04:22:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 79B613A0D2D for ; Mon, 9 Mar 2020 04:22:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jBGTz-00020s-8q; Mon, 09 Mar 2020 11:22:03 +0000 Date: Mon, 09 Mar 2020 04:22:02 -0700 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: SIDR Operations WG In-Reply-To: References: <48A08EF5-F932-4249-93EC-CE0E9ED7784E@ripe.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Validation violations 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: Mon, 09 Mar 2020 11:22:08 -0000 [ cc:s trimmed as everyone is on the ml ] tim, > Do people think that parent CAs should actively monitor delegated CAs? should i test dns delegations for lameness, bad keying, ...? you betcha. > come to a point where they can only revoke a child different question. what to do with various forms of breakage. but if a child is causing a public problem, yes, dire measures may be needed. > So, while these things stick out, we may have to accept that > unreachable repositories, and unmaintained (stale as well as expired) > publications by CAs, are a reality in delegated RPKI. i am not so comfortable with this. > Personally I think that parent CAs, especially the RIRs should seek to > provide publication services to others, so that the number of > repositories and repositories with issues can be managed. when designing this stuff, we assumed that the number of CAs would be anaologous to the number of IRR instances, O(100), if that asumption does not hold, then we will have a management and correctness problem. > - maybe we should extend the publication protocol to be able to > enforce limits (size and number of objects, possibly even only allow > syntactically correct RPKI objects) uh, yes. i think that was assumed. if it is not stated in the rfc, save it for the bis. > - maybe parents should monitor for children who make millions of ROAs, > or delegations, or which try to create validation loops. (e.g. in > their own repository) i.e. we need to prepare to deal with malicious CAs. > I think that in spirit the parent CAs keep an eye on these things, and > they can revoke reactively. I am not even sure that we can dictate > good parenting practice in this forum. But, I do think it's a > discussion that we need to have. yep randy From nobody Mon Mar 9 09:49:28 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 7259D3A1455 for ; Mon, 9 Mar 2020 09:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uAfXeIVgEVwF for ; Mon, 9 Mar 2020 09:49:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 0D2F43A1404 for ; Mon, 9 Mar 2020 09:49:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jBLag-0002nJ-T0 for sidrops@ietf.org; Mon, 09 Mar 2020 16:49:19 +0000 Date: Mon, 09 Mar 2020 09:49:18 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] New Version Notification for draft-ymbk-sidrops-8210bis-00.txt 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: Mon, 09 Mar 2020 16:49:27 -0000 [ adds a flag for AFI, thanks martin ] co-chairs, can we please call to adopt? randy A new version of I-D, draft-ymbk-sidrops-8210bis-00.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Name: draft-ymbk-sidrops-8210bis Revision: 00 Title: The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 Document date: 2020-03-09 Group: Individual Submission Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-ymbk-sidrops-8210bis-00.txt Status: https://datatracker.ietf.org/doc/draft-ymbk-sidrops-8210bis/ Htmlized: https://tools.ietf.org/html/draft-ymbk-sidrops-8210bis-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-ymbk-sidrops-8210bis Abstract: In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document updates RFC 8210. 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. The IETF Secretariat From nobody Mon Mar 9 13:04:01 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 D7F433A164B for ; Mon, 9 Mar 2020 13:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 On63jkuK2-EO for ; Mon, 9 Mar 2020 13:03:57 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2072.outbound.protection.outlook.com [40.107.94.72]) (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 1E56E3A1222 for ; Mon, 9 Mar 2020 13:03:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S43HdVUWUkEwO6y+cQbzdzy3WzS3OrHY155tBO5zz9vIbHmsvVFsEzyyQZwPiqoybbgAo0Lb2/XFgsPka6DLy32kXDOkFAEL48LNnXt4TkpyAzKLW8nxOhTWUb7csgpy1ZGGyBje63s4ut5JvrNQuInUenxoq6cPyFRvVIPmUr9iEC66O5aXIsuwKiX0Z5P7WOIfZErTkTuevHkhWKNAGurnuHOW6KCcr7YAd0m7yRRLdBMYIa4nYtdUVEKd4vvH0BYFvqQK6O/h1h2qo2I1tT7a/5nUY8G94/zltHJQWS+rlms51QpHO7W9pwBkm9qod75wod/yTQERg3DE5YicBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7SdDthWf0uxBzJzoYNr+B+LstkscOFoEWTly5YfsJNM=; b=eTxkO+c/HIxkT02pCKwrS7MQp11NTVXWKofvU9CUbhLtRcZwV7ZPyAl7NKFP39ht+8tnUayGboqwzxxr24p2YiGAw+vkH7K4o4kRH8U0P3FFn5xHvDtUX3sn3reyfbEEU4HhD19b65h8c06BFsL2zBioyM1ea54Ja8eq1JWm7Ts7vfvL/k31cQjAwwFndeJNr2ihEHu2RKkEiDwHpO1hXoNAcEbD9Hw5ITWN6KGcqeyBN+uCef5yzDqan+88A2dq/5Qlgh3D3xGIZg7e3TSoBunJoPk8HmE4bb0IownG1EHmoPrqLs104/QUpvQ9/Uk1HYnFqHkXSEY9GPErx8Xz0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7SdDthWf0uxBzJzoYNr+B+LstkscOFoEWTly5YfsJNM=; b=t9wqoF5byeqppLNXqZBYUvC3yXfTJ+Re8DPcctKpBuW/y2ICryEWHVDtw6S63ID77/N62MeNkT+RaxaODn4l69S62z+cBszZbFFOYSFRZhjx81yxFsknCLyI0gWm+EhaHVJx3qAuw4Cm9YlHQypXL0i+uFRjtKm9ShLj7ufb0og= Received: from BYAPR18MB2856.namprd18.prod.outlook.com (2603:10b6:a03:10e::30) by BYAPR18MB2998.namprd18.prod.outlook.com (2603:10b6:a03:136::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.15; Mon, 9 Mar 2020 20:03:55 +0000 Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05%4]) with mapi id 15.20.2793.013; Mon, 9 Mar 2020 20:03:55 +0000 From: Keyur Patel To: SIDR Operations WG Thread-Topic: WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24) Thread-Index: AQHV9k3dG6VaK9VoVUiQBn27Bv4nUw== Date: Mon, 9 Mar 2020 20:03:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c448efb2-8ea5-4034-739b-08d7c464ff85 x-ms-traffictypediagnostic: BYAPR18MB2998: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3173; x-forefront-prvs: 0337AFFE9A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(366004)(39830400003)(376002)(396003)(189003)(199004)(66574012)(2616005)(6486002)(71200400001)(86362001)(5660300002)(6512007)(81166006)(81156014)(8676002)(9326002)(6916009)(8936002)(26005)(558084003)(186003)(6506007)(66556008)(478600001)(33656002)(316002)(36756003)(64756008)(76116006)(966005)(66476007)(66446008)(2906002)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2998; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UgomYy8eW8VIT1mevcCjBwKp8eFHy9Q5MLonVOANJO/J6EPhwxIWyE5anOBxcNStTJCi2yxxNRwT4ckTBqPbse9CQNqTKMyYc/xn5iWrXb56bANSFVqUim/CTc5oK6Alvfe58ggbCX9gsoyjoETeVEB0pSwdRwdeCF/RT+DMFwA9EYCMnMUFDgVAw40kXlR6TZrVdDSpiD8iS+12gA2rkilu1Y+3oPWGoU041giklh+Nt7cLNPvFiSZXOYLtxMsOPBZLpXkiZIxIvEqDRKmO84m60HKQKqoDIyS/wywog8Q46dez3ZISNMrJxVum0klAQo1uT+jUCFitZcKNQUQM+MtN+UdVlAsRyNIE0saJEEPG6tRyMu5JN0yqsHaT4B/s6LknLG8ym5tLK3SQ/O4auNKf0eH1ik/Gd589foXQqrpFQ9XGzC9MlkmhhnNVxMUYKgbTLtrybg5AMYuO40n1WXM/2Btq2ib0vvPZMrisOJrrpr8eMZn8159DRK16OU7c x-ms-exchange-antispam-messagedata: ogks1ZLjEnNnQse71OhfEcngFznzI0IEMR9kNLjS7pq6eXKaZbBjp+59blrCnjQFCfy5zjkyvIsEZGiRFaUkX1qnbMctRN6BEyO4Y2a9dMiyZg3UaLYlxZbVs5JRsYw3Xnx4FF1/VEbuDQHygJCaeQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_E44D2381720B49978448C3BF0E3B2318arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: c448efb2-8ea5-4034-739b-08d7c464ff85 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2020 20:03:55.8514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5VnUvrujeUd7kTnq3kwMTYZIIr71kyQFRETMTvnhGH0ef5JII1m5AlJBTpqFlGCyNDhqD5flPLUukBmtAaBYXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2998 Archived-At: Subject: [Sidrops] WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24) 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: Mon, 09 Mar 2020 20:03:59 -0000 --_000_E44D2381720B49978448C3BF0E3B2318arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNCg0KDQpUaGUgYXV0aG9ycyBoYXZlIHJlcXVlc3RlZCBTSURST1BTIHdvcmtp bmcgZ3JvdXAgYWRvcHRpb24gY2FsbCBvZiDigJxSUEtJIHRvIFJvdXRlciBQcm90b2NvbCBWZXJz aW9uIDLigJ0sICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteW1iay04MjEwYmlz LTAwLg0KDQoNCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdC4gVGhpcyBh ZG9wdGlvbiBjYWxsIHdpbGwgY29uY2x1ZGUgb24gTWFyY2ggMjQsIDIwMjAuDQoNCg0KDQpSZWdh cmRzLA0KDQpOYXRoYWxpZSwgQ2hyaXMgJiBLZXl1cg0KDQoNCg== --_000_E44D2381720B49978448C3BF0E3B2318arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDMgOCA0IDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPkhpIEZvbGtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2Nv bG9yOiMyMTI1MjkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPlRo ZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVkIFNJRFJPUFMgd29ya2luZyBncm91cCBhZG9wdGlvbiBj YWxsIG9mIOKAnFJQS0kgdG8gUm91dGVyIFByb3RvY29sIFZlcnNpb24gMuKAnSwgJm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXltYmstODIxMGJpcy0wMCI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXltYmstODIxMGJpcy0wMDwvYT4uPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVu bG87Y29sb3I6IzIxMjUyOSI+UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdC4g VGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgY29uY2x1ZGUgb24gTWFyY2ggMjQsIDIwMjAuPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87 Y29sb3I6IzIxMjUyOSI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 Ij5OYXRoYWxpZSwgQ2hyaXMgJmFtcDsgS2V5dXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E44D2381720B49978448C3BF0E3B2318arrcuscom_-- From nobody Mon Mar 9 13:45:38 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 AB9453A1749 for ; Mon, 9 Mar 2020 13:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=netorgft1331857.onmicrosoft.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 3eFTyXQmYUm2 for ; Mon, 9 Mar 2020 13:45:28 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750059.outbound.protection.outlook.com [40.107.75.59]) (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 4A2D13A1767 for ; Mon, 9 Mar 2020 13:45:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iunHdUmEB+Jc5XDf5xm1I9UypDyLvJFBRGiWrXODfUmaOSsmyVoAiLdTCs85Bg8sPLifMm3p+760/GBkpSmvNrjgFIIug42fMvHnADtwaDXs7s2i6UsJ6lF2BhJ0cNwZ7uhYS0fOfj0ZkC5YJaaAygZQodbBhsusCc39vtUKUi5/aTFhx+a/pxXN2mR/UczdpxPtfW0nh3ODet9jLK5OMQuqd03px0kqgRD2zWNw4+a96xSqdfLEvIbOGbLtURmPv+DK+cQR1tEHcETFiPqsoCD8v9vvko4l+47whsqkx+5YrqlKP7LxcZVHEND3F8vELGiOcl96PKdusgb5EXVwTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SatEP0mE1LyW4eusxgpZW12Y3u4YalgtiqzNMv+RsPY=; b=jRWVQ/+QZEzd75cGNd+JfMjLkKfD751J4iIUY2YxNTYV0+42MFv0em+UFU45jTO4E5aLN+wFN0hlWj0WtgKMjWn7duGQaPmcDwDD6Fjg5RbKqV1jTH9EwXoKdN2tAQoGAvF+l9+9jtqt3z60tMYeXqyUHkxCF+hhouelkIqbvTQWkerHKsK3aLXcboxXDJtewWq2qmj9BCdP6QM2NbokE2cZfVffNwZkR3CL17CP1jgQ1jYBSIVpioUHaagnNJVjGwpi4nnLb+TzJf+WogfOMoVF5sdsephkhc9sv6cJnb3bQaodCflxNYeBsGhw3/+kEpGmj+hYoKHkYl9nnKy+ag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SatEP0mE1LyW4eusxgpZW12Y3u4YalgtiqzNMv+RsPY=; b=H8+bJzyoo0PP/vWPy43QhYwGqybXpwbXX3dWLso2x+7EMJ21ZE+3Okry+BZl0ZcEpyI/PsQi/HPZ5UKh2xYgeneANKT5pAkm4r6+rXWRyKJgY6W81f0IbU0c5io/ebJO7l4d7Qd/QJwifpZtzxp65FPDN9NZ7JvSXYkD4+mhAvo= Received: from BYAPR18MB2856.namprd18.prod.outlook.com (2603:10b6:a03:10e::30) by BYAPR18MB2423.namprd18.prod.outlook.com (2603:10b6:a03:132::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Mon, 9 Mar 2020 20:45:26 +0000 Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05%4]) with mapi id 15.20.2793.013; Mon, 9 Mar 2020 20:45:26 +0000 From: Keyur Patel To: SIDR Operations WG Thread-Topic: Welcome to Nathalie Trenaman as SIDROPS WG Secretary! Thread-Index: AQHV9lOpW932A+4CtUq/miRZIVeckw== Date: Mon, 9 Mar 2020 20:45:26 +0000 Message-ID: <17188DA3-7EA6-4317-B878-F687958C7EBB@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42aacece-06f4-4af0-a03a-08d7c46acbf5 x-ms-traffictypediagnostic: BYAPR18MB2423: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0337AFFE9A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39830400003)(346002)(136003)(396003)(366004)(189003)(199004)(66556008)(66946007)(6486002)(76116006)(66476007)(66446008)(2616005)(6916009)(26005)(5660300002)(6506007)(186003)(6512007)(64756008)(33656002)(2906002)(81156014)(81166006)(478600001)(8936002)(86362001)(71200400001)(8676002)(36756003)(316002)(4744005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2423; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /DckHyFuMGx6OXBuj/9rkFwFcKX9JkQDwgzfT3EI3ZpV1SlJakws99DatuuR6s3bCLcrAtlapMWpwnnPv2LVwcy+R46Xse+KSooXYXnZupKTRd0/oZCm8cwQzWyY7C0AAIdm2KweuAgcAjZvVq8/uPbL/UgH8z8SbNnHBJ67Iu9yvrv0GBKAdgkXoA/lyCUN1vD5+h/U1Z38YOe0+ZXxVfXmxaPCFGgUaBSqR8wd7FA2Lzodj3iuRt+Dran2HjDs25GlmuXWm26M58UAgRCxNgRN7j0NtrQeK+YN6C6Ef52HdNN5P21HKkWbrFHXhqVgBAcySi+kAoiarjuIHex9sAQktbffRjkqb88LUGRUx+1CoPaXTgLMygbelzbWeoi1oCwBBwSAeSmIglbNNUu8DaSHZL8DP7P4onLd6XpfyCcC2nW3donPIVzI7RVQ9p5Y x-ms-exchange-antispam-messagedata: NxeUwllLM466qxAkKg0dCXtbDkqcu3ORtBbCKRImDd4lgAEQ59JQkmAPYrLZduW7xNmm3gHSiqYImwNDkuDzVCxw66DE0+dKpq4xsyL17sp9iXtrijR0t02HuNyX6Pb/PzBzoCk+r+n/XYcHNYczXw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_17188DA37EA64317B878F687958C7EBBarrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42aacece-06f4-4af0-a03a-08d7c46acbf5 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2020 20:45:26.3084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wqWfleR5rHqwEB8jS3lbgPrghOpv0Zf3f+jmLpzCgAAIKHoAfKrDEpR1Wphuw2qrSQTQjFvmdxJ97E9gjB8gRQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2423 Archived-At: Subject: [Sidrops] Welcome to Nathalie Trenaman as SIDROPS WG Secretary! 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: Mon, 09 Mar 2020 20:45:38 -0000 --_000_17188DA37EA64317B878F687958C7EBBarrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U0lEUk9QUyBXRzoNCg0KTmF0aGFsaWUgVHJlbmFtYW4gaGFzIGFncmVlZCB0byBiZSB0aGUgU0lE Uk9QUyBXRyBzZWNyZXRhcnkuICBOYXRoYWxpZSBpcyBSb3V0aW5nIFNlY3VyaXR5IFByb2dyYW0g TWFuYWdlciBmb3IgdGhlIFJJUEUgTkNDLiBTaGUgaXMgcmVzcG9uc2libGUgZm9yIGFsbCBSb3V0 aW5nIFNlY3VyaXR5IHJlbGF0ZWQgbWF0dGVycywgaW5jbHVkaW5nIFJQS0kgYW5kIElSUi4gU2hl IGlzIGFsc28gdGhlIGNoYWlyIG9mIE5MTk9HLiBZb3UgY2FuIGZpbmQgaGVyIG9uIElSQ25ldCBh cyBOYXRoYS4NCg0KUGxlYXNlIHdlbGNvbWUgTmF0aGFsaWUgdG8gdGhpcyBuZXcgcG9zaXRpb24u DQoNClJlZ2FyZHMsDQpDaHJpcyAmIEtleXVyDQoNCg0K --_000_17188DA37EA64317B878F687958C7EBBarrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlNJRFJPUFMgV0c6Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOmJsYWNrIj5OYXRoYWxpZSBUcmVuYW1hbiBoYXMgYWdyZWVkIHRvIGJlIHRo ZSBTSURST1BTIFdHIHNlY3JldGFyeS4gJm5ic3A7TmF0aGFsaWUgaXMgUm91dGluZyBTZWN1cml0 eSBQcm9ncmFtIE1hbmFnZXIgZm9yIHRoZSBSSVBFIE5DQy4gU2hlJm5ic3A7aXMgcmVzcG9uc2li bGUgZm9yIGFsbCBSb3V0aW5nIFNlY3VyaXR5IHJlbGF0ZWQgbWF0dGVycywgaW5jbHVkaW5nDQog UlBLSSZuYnNwO2FuZCBJUlIuIFNoZSBpcyBhbHNvIHRoZSBjaGFpciBvZiBOTE5PRy4gWW91IGNh biBmaW5kIGhlciBvbiBJUkNuZXQgYXMgTmF0aGEuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5QbGVhc2Ug d2VsY29tZSBOYXRoYWxpZSB0byB0aGlzIG5ldyBwb3NpdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2si PlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6YmxhY2siPkNocmlzICZhbXA7IEtleXVyPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_17188DA37EA64317B878F687958C7EBBarrcuscom_-- From nobody Mon Mar 9 13:56:21 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 1F2AA3A170A for ; Mon, 9 Mar 2020 13:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_SINGLE_WORD=1.298, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 PaMCCdLz5FlL for ; Mon, 9 Mar 2020 13:56:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2CAE83A1709 for ; Mon, 9 Mar 2020 13:56:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jBPRf-0003Jr-JO; Mon, 09 Mar 2020 20:56:15 +0000 Date: Mon, 09 Mar 2020 13:56:15 -0700 Message-ID: From: Randy Bush To: Keyur Patel Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24) 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: Mon, 09 Mar 2020 20:56:20 -0000 thanks From nobody Mon Mar 9 13:56:44 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 977E03A1711 for ; Mon, 9 Mar 2020 13:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gDKg1Ov233c2 for ; Mon, 9 Mar 2020 13:56:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 687183A170E for ; Mon, 9 Mar 2020 13:56:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jBPS3-0003K6-W7; Mon, 09 Mar 2020 20:56:40 +0000 Date: Mon, 09 Mar 2020 13:56:39 -0700 Message-ID: From: Randy Bush To: Keyur Patel Cc: SIDR Operations WG In-Reply-To: <17188DA3-7EA6-4317-B878-F687958C7EBB@arrcus.com> References: <17188DA3-7EA6-4317-B878-F687958C7EBB@arrcus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Welcome to Nathalie Trenaman as SIDROPS WG Secretary! 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: Mon, 09 Mar 2020 20:56:43 -0000 > Please welcome Nathalie to this new position. yay! From nobody Mon Mar 9 14:31:01 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 EAAA53A17D5 for ; Mon, 9 Mar 2020 14:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 BkIQ4cdoX_2N for ; Mon, 9 Mar 2020 14:30:48 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 75B113A1788 for ; Mon, 9 Mar 2020 14:30:48 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id du17so4531706qvb.12 for ; Mon, 09 Mar 2020 14:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:embedded-html; bh=N71dw4JCtqD5qZ8FejlN1KRNvNwkizIAChGSu9QTdI4=; b=MySI+HJzkD6/FtlZgq01d5O1fDtcV6ln0NGNEFLeQx1UayQbKOlyiY38IZyAxE/zjj yTsZ6rWS76RhTkKa9RJ0KJHSYX8/N179DmFkWxtnir/Dw+RouCsDvZOSqbC0qh4Vxe6f 7Y9tfWyn1Mb9wbX0JibWFFUEdE7AmK5Vqn9sDMFY1Atju4OzcqVwjgxA8uowDKInjD2X LAOu4DnYSJsgdjhY2iNTC1MDoZHmGwXnxe7rdL79M97MToh6gUXuManmPTqfO+d4/gVQ mccg5BiGFHodSaf+ZKPsxLOlSeSshP732Xi+L0Cvw1Ij7CqMRTaMgwNdgtB1qzU5DC/I up/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:embedded-html; bh=N71dw4JCtqD5qZ8FejlN1KRNvNwkizIAChGSu9QTdI4=; b=pXHMKNK3CY6Suwb5mzuuSE8WKV4dP2mQFtg41zzY5hFTqAZlbCHiYsrsXz+KutJ8RD xvj96Zn1/C1sQgBD/WawTu30xqYwXqbwYqEpHy2qt7O9NaFB34MVnbIGGvr7VYI0LkRb OZe2FruWpJl8+C/EfoNp7zOd6pKw+WWNalm2ItBcBME3647yvLpq2ikd6NWGxM2Tk57n fdzWAlpQN6eW5HtUy0cIfB+swKEVZ0G7gkGHFxFJkWhxVH7U23O7OQGBD0s6BELcI7/I yTlHjj715/idHgrL7ru0dlUx6QBK6pjghpvyTlfCPGfPWP/bBwZwZQGmD8hEsUjwc4jx D08Q== X-Gm-Message-State: ANhLgQ33jpa7CdfEQCRI3cP00q0H1FB55WldiEMsak6sXISbN5De5D+X OJaov2ssJvVKJpJziNvkqgsSn0SAb5M= X-Google-Smtp-Source: ADFU+vta1kuSPOA3mW2YZ0olpvhGAWJaF38XtuK7sbCqJuo710liXEw4ruUTbQGn+UNfMKvNZ2eQaw== X-Received: by 2002:ad4:5909:: with SMTP id ez9mr10346275qvb.56.1583789447447; Mon, 09 Mar 2020 14:30:47 -0700 (PDT) Received: from [192.168.89.11] ([2800:a4:2868:1300:41e5:247f:2cc6:1a9b]) by smtp.gmail.com with ESMTPSA id k66sm10315739qke.10.2020.03.09.14.30.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2020 14:30:46 -0700 (PDT) From: "Carlos M. Martinez" To: "Keyur Patel" Cc: "SIDR Operations WG" Date: Mon, 09 Mar 2020 18:30:44 -0300 X-Mailer: MailMate Trial (2.0BETAr6146) Message-ID: <0E50CDA6-6B7F-4039-936A-FB9AA0501B47@gmail.com> In-Reply-To: <17188DA3-7EA6-4317-B878-F687958C7EBB@arrcus.com> References: <17188DA3-7EA6-4317-B878-F687958C7EBB@arrcus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4B743DDB-6EF9-47F3-AE0D-1FC290E4D9C4_=" Embedded-HTML: [{"HTML":[277, 1680], "plain":[67, 374], "uuid":"EAD6A887-1882-4E81-BA95-933A9CD7506C"}] Archived-At: Subject: Re: [Sidrops] Welcome to Nathalie Trenaman as SIDROPS WG Secretary! 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: Mon, 09 Mar 2020 21:30:59 -0000 --=_MailMate_4B743DDB-6EF9-47F3-AE0D-1FC290E4D9C4_= Content-Type: text/plain; format=flowed Welcome Nathalie ! On 9 Mar 2020, at 17:45, Keyur Patel wrote: > SIDROPS WG: > > Nathalie Trenaman has agreed to be the SIDROPS WG secretary. Nathalie > is Routing Security Program Manager for the RIPE NCC. She is > responsible for all Routing Security related matters, including RPKI > and IRR. She is also the chair of NLNOG. You can find her on IRCnet as > Natha. > > Please welcome Nathalie to this new position. > > Regards, > Chris & Keyur > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --=_MailMate_4B743DDB-6EF9-47F3-AE0D-1FC290E4D9C4_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Welcome Nathalie !

On 9 Mar 2020, at 17:45, Keyur Patel wrote:

SIDRO= PS WG: 

 = ;

Natha= lie Trenaman has agreed to be the SIDROPS WG secretary.  Nathalie is= Routing Security Program Manager for the RIPE NCC. She is responsib= le for all Routing Security related matters, including RPKI and IRR. She is also the chair of NLNOG. You can find her on I= RCnet as Natha.

 = ;

Pleas= e welcome Nathalie to this new position.

 = ;

Regar= ds,

Chris= & Keyur

 = ;

 =

________________________________= _______________
Sidrops mailing list
Sidrops@ietf.org
https://www.iet= f.org/mailman/listinfo/sidrops

--=_MailMate_4B743DDB-6EF9-47F3-AE0D-1FC290E4D9C4_=-- From nobody Mon Mar 9 14:48:55 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 73D933A077F; Mon, 9 Mar 2020 14:48:42 -0700 (PDT) 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.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <158379052239.5659.12668049496762971246@ietfa.amsl.com> Date: Mon, 09 Mar 2020 14:48:42 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-02.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: Mon, 09 Mar 2020 21:48:50 -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 : A Profile for Autonomous System Provider Authorization Authors : Alexander Azimov Eugene Uskov Randy Bush Keyur Patel Job Snijders Russ Housley Filename : draft-ietf-sidrops-aspa-profile-02.txt Pages : 9 Date : 2020-03-09 Abstract: This document defines a standard profile for Autonomous System Provider Authorization in the Resource Public Key Infrastructure. An Autonomous System Provider Authorization is a digitally signed object that provides a means of verifying that a Customer Autonomous System holder has authorized members of Provider set to be its upstream providers and for the Providers to send prefixes received from the Customer Autonomous System in all directions including providers and peers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-aspa-profile-02 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-aspa-profile-02 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 Mon Mar 9 14:51: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 AF59E3A0365; Mon, 9 Mar 2020 14:51:34 -0700 (PDT) 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.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <158379069464.5639.465678744189015817@ietfa.amsl.com> Date: Mon, 09 Mar 2020 14:51:34 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-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: Mon, 09 Mar 2020 21:51:42 -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 : Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization Authors : Alexander Azimov Eugene Bogomazov Randy Bush Keyur Patel Job Snijders Filename : draft-ietf-sidrops-aspa-verification-04.txt Pages : 12 Date : 2020-03-09 Abstract: This document defines the semantics of an Autonomous System Provider Authorization object in the Resource Public Key Infrastructure to verify the AS_PATH attribute of routes advertised in the Border Gateway Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-04 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-aspa-verification-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 Mon Mar 9 15:28:26 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 44A343A07AE for ; Mon, 9 Mar 2020 15:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.20150623.gappssmtp.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 Fg3IW1IGv8aF for ; Mon, 9 Mar 2020 15:28:21 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 12E9E3A07AF for ; Mon, 9 Mar 2020 15:28:20 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id h131so10140979iof.1 for ; Mon, 09 Mar 2020 15:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z40Kc9W9y7vTeTqR8WXKpzSdw2cIgjNIeSzklObPIQ4=; b=DWbE66FyYOf/xwkmrmtl9cxjbfW64CcKBC9H506l4BAVWkKzOzco/3Vy+VcTw3GID6 94G2ylNeBD4+rElvBwlAwJB5VV8DuDbqJhrESK7544ng0TLbEsyCAjI0dCd96hLm2xzT x6KNA6BITiOQeZGh0T8dJyb131ZinLv0EIhhJgw07GlTxfqAWCR+mFcAvUxhoDaDYVN5 L+9zMO/8gL/zMnyw734x8Zzf25it5JWp0q7j7m9cWuBCMCygzDh3J8iZT76qTAYtDGbF q1S4lnnB8+t7a6rSIVB4J8/SK/GXT4MmNQg/sibJ62SnRYeXzUcqqeHWEtzc2KLcmYqH Sx8w== 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=Z40Kc9W9y7vTeTqR8WXKpzSdw2cIgjNIeSzklObPIQ4=; b=i30NH7TG+Cm0P0NsKAp1Q2d70oJHfQo8Nffv6qp0hwFxdefO+D8HMe3JNoDb97gabM +1Ukp5dQZZeKikq/B0FEue6oIIhtfJU1O6nxeuMHhYH1pkcR3g4H+32iu8Xjvln27ibQ Rdv/hvtVAhh05sF2+7I3TtNTfy/RkqmTyXCOCZNx4m1Hx5vs5DaEvuEf/eHURVgH9ETT 0D9pcJmR7Tq2pqKTIi6ngavYQoOaveM/Y8wU/f8y3lD+8i7UkwjZm2PW6eYB9mwG9CBG aQ/1Jq/yO8qZV1/x1WXH0e+WPrBCjJGpAubs7qK5B9w3IRLKqScCSvlPeRAvl59k6OsK mwGw== X-Gm-Message-State: ANhLgQ3ladXnD73Q7s7UQyk+X9FhcoAZUI83LBiJjc88Ps5Lq/9/9RdZ U6H6cdkzxbl8e1huuNi3uhm4y/YgQf45NL9kvHrlYQ== X-Google-Smtp-Source: ADFU+vsVAwy7/aCV2g8tnF4YpOnu6uQiC1oRasf6a9J0d78zYmA9QQI/nMuLOGA03Vc6PWt5LdOhBxub2udwoId00Qk= X-Received: by 2002:a6b:5a0c:: with SMTP id o12mr9487950iob.137.1583792900136; Mon, 09 Mar 2020 15:28:20 -0700 (PDT) MIME-Version: 1.0 References: <48A08EF5-F932-4249-93EC-CE0E9ED7784E@ripe.net> In-Reply-To: From: George Michaelson Date: Tue, 10 Mar 2020 08:28:08 +1000 Message-ID: To: Tim Bruijnzeels Cc: Nathalie Trenaman , Randy Bush , "Thomas C. Schmidt" , SIDR Operations WG , Matthias Waehlisch Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] Validation violations 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: Mon, 09 Mar 2020 22:28:23 -0000 We reach out to child CA's regularly. The responsiveness is a function of leave and other factors getting in the way of remediation. Asking them whats up and asking for a re-publication feels like the best we can do because telling them to do things or else is simply not in our role. Cryptographic/Validation invalidity makes things invalid that are harmful. The rest is confusing. I don't think all problems stem from operator confusion: I believe a lot of the MFT/CRL mismatch is coming from engines which do in-place publication and so create downloadable states which are not in the collection list or the repudation list. I think doing work in a side directory and a single (semi atomic) mv is probably better from a coherence point of view, but even between RRDP and rsync there are disagreements about state and they are not publishing the same physical on-disk filestate, even if they are assertions about the same signing events. (I say this observing how things exist in the tree when I run code) -If the code bases actually do the clone-dir mv trick then I guess it must be something else. The "time of day went backward" thing I think is lack of clock sync between operational nodes. Do we need to work on some granularity like 5min or do we obligate NTP time sync? I obviously believe in the latter but even NTP consists of de-cohered islands of time. There might be some time dither we need to live with. A minute? There is a persisting overclaim on the edge of the tree rooted in APNIC, under a sub-CA. I am talking to them about this, why it persists. It should not persist. That it does worries me, because no CA code I know of will sign over a child certificate which has overclaim in the 3779 so it must be persisting state in a child which hasn't re-synced in up-down, to operate with an overclaim (or, long lived product which is not being repudiated) I run two validator instances locally, same codebase, and they do not agree much of the time about the intermittent states of invalidity. It might only be single digit variances, but none the less, two fetches within 1-2 minutes of each other do not always get the same state, which them persists for up to 3600 seconds. From nobody Mon Mar 9 19:43:02 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 3290C3A0DEC for ; Mon, 9 Mar 2020 19:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 qRcD3kslNeoT for ; Mon, 9 Mar 2020 19:42:52 -0700 (PDT) Received: from out20-195.mail.aliyun.com (out20-195.mail.aliyun.com [115.124.20.195]) (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 F04553A0DDD for ; Mon, 9 Mar 2020 19:42:49 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.4382215|-1; BR=01201311R121S70rulernew998_84748_2000303; CH=blue; DM=||false|; DS=CONTINUE|ham_system_inform|0.0507015-0.00238632-0.946912; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03311; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.GyuO6lD_1583808152; Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.GyuO6lD_1583808152) by smtp.aliyun-inc.com(10.147.42.197); Tue, 10 Mar 2020 10:42:34 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Di Ma In-Reply-To: <17188DA3-7EA6-4317-B878-F687958C7EBB@arrcus.com> Date: Tue, 10 Mar 2020 10:42:31 +0800 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <17188DA3-7EA6-4317-B878-F687958C7EBB@arrcus.com> To: Keyur Patel X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] Welcome to Nathalie Trenaman as SIDROPS WG Secretary! 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, 10 Mar 2020 02:43:00 -0000 Welcome Nathalie:-) Di > 2020=E5=B9=B43=E6=9C=8810=E6=97=A5 04:45=EF=BC=8CKeyur Patel = =E5=86=99=E9=81=93=EF=BC=9A >=20 > SIDROPS WG:=20 > =20 > Nathalie Trenaman has agreed to be the SIDROPS WG secretary. Nathalie = is Routing Security Program Manager for the RIPE NCC. She is responsible = for all Routing Security related matters, including RPKI and IRR. She is = also the chair of NLNOG. You can find her on IRCnet as Natha. > =20 > Please welcome Nathalie to this new position. > =20 > Regards, > Chris & Keyur > =20 > =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Mar 9 20:22:31 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 7B53D3A0B56 for ; Mon, 9 Mar 2020 20:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no 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 fJ54YEwHg-cL for ; Mon, 9 Mar 2020 20:22:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4CDB63A0E54 for ; Mon, 9 Mar 2020 20:22:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jBVSr-0004M1-Eg; Tue, 10 Mar 2020 03:21:53 +0000 Date: Mon, 09 Mar 2020 20:21:51 -0700 Message-ID: From: Randy Bush To: Martin Hoffmann Cc: SIDR Operations WG In-Reply-To: <20200306130129.59c888c1@glaurung.nlnetlabs.nl> References: <158274065310.22955.10729466847169070546.idtracker@ietfa.amsl.com> <20200306130129.59c888c1@glaurung.nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt 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, 10 Mar 2020 03:22:29 -0000 > As a separate note, ASPA in its current form includes the address > family, ie., it has different ASPA objects for v4 and v6. This is > missing from the proposed ASPA RTR payload PDU, but luckily there is > enough zero space to include it. i believe this is addressed in the draft out today; though not exactly in the way you suggest. thanks again for pointing this out. randy From nobody Mon Mar 9 22:54:19 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 B87723A0774 for ; Mon, 9 Mar 2020 22:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iBRjaIc4erAY for ; Mon, 9 Mar 2020 22:54:14 -0700 (PDT) Received: from smtpbgau1.qq.com (smtpbgau1.qq.com [54.206.16.166]) (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 04AF23A076E for ; Mon, 9 Mar 2020 22:54:13 -0700 (PDT) X-QQ-mid: bizesmtp3t1583819638twli3xdhe Received: from [192.168.3.24] (unknown [117.100.110.112]) by esmtp6.qq.com (ESMTP) with SMTP id 0 for ; Tue, 10 Mar 2020 13:53:57 +0800 (CST) X-QQ-SSF: 01400000000000N0ZI80B00A0000000 X-QQ-FEAT: wwCaZOIcf2uZBmF1e5CS3r9zuBUsg91yYp6/Qp6FRVOxX8Bt8hjmxnGLunv5Q PjcysPZ8dk7ubMJMWcfZOzxRZ5KFUZ1YixLd65ZcK7A3md+UybI7seOz3MdQfhtUWJUzhKO Ti5RZPUAfMKB90VWcr8ktC0b9hrYNf7MEwlysGseD5tqRmzRxIkpMwWip1EsDBhpEcX7kaj YCiBIh8Uh2J/mST1w0NRgFVBFfJvqM5JV9CLqU7aocZM7kVFh5CIxIT5WXkVy3XA7CPog6i RkOaRPhsCVXgW71v8s1ZbxjC3E+KKyl1K+124zVRClwoVmtgd1sbkcdGoYrQ+d6Ae1BeEh9 CGDluAP X-QQ-GoodBg: 2 From: Di Ma Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: <10BE796C-0BF7-4F3D-943F-79CB6EF6F9C2@zdns.cn> Date: Tue, 10 Mar 2020 13:53:56 +0800 To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.60.0.2.5) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign6 X-QQ-Bgrelay: 1 Archived-At: Subject: [Sidrops] APNIC Routing Security SIG 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, 10 Mar 2020 05:54:18 -0000 Hi, folks, APNIC community has formed a new SIG for Routing Security after APNIC = meeting 49. And the mailing list has been just created. Welcome to the APNIC "SIG Routing Security" mailing list! Di as co-chair of this SIG From nobody Mon Mar 9 22:57:23 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 0660F3A077F for ; Mon, 9 Mar 2020 22:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-1.463, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 shmp1i5yVFYJ for ; Mon, 9 Mar 2020 22:57:19 -0700 (PDT) Received: from smtpbguseast3.qq.com (smtpbguseast3.qq.com [54.243.244.52]) (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 8542D3A077E for ; Mon, 9 Mar 2020 22:57:18 -0700 (PDT) X-QQ-mid: bizesmtp5t1583819828t3uxjs84c Received: from [192.168.3.24] (unknown [117.100.110.112]) by esmtp6.qq.com (ESMTP) with id ; Tue, 10 Mar 2020 13:57:06 +0800 (CST) X-QQ-SSF: 00400000000000N0ZI80B00A0000000 X-QQ-FEAT: gzzt0UMLGp7ag316TUglb3Fbp1dUTEwcZFCY0rIZia1IACy3xoxRo2xSBPDzY pcsHgUfb6ofVQTJ9hORtCibfCieKZ3nBkxAVjajoOge+vuywTESMLXK8A0d9rvlMAvBdKdQ e2H+dHBZIDKH1GmNoNAxiHawnUoiVzi1Ck964Fo29SsGJ9AgyKsjeuogR2+0op7qhYJbqPS mM1SGotx6lAxZW70vBff2W96RQd9sc+HWFBr8A8I9CNza1MNHSH/iw49uQi45ZtVib/E+kO SdCruFWhPY9uQTjic5IhPtw5A/qJxzetow6v4hDLcjZbUQXQrtaq5hBny1R8/coWEn3G02l a5tCZrSUS8HoXyEMMuLmo+bgZxzYGlliTwIA/L4 X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Di Ma In-Reply-To: <10BE796C-0BF7-4F3D-943F-79CB6EF6F9C2@zdns.cn> Date: Tue, 10 Mar 2020 13:57:06 +0800 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <10BE796C-0BF7-4F3D-943F-79CB6EF6F9C2@zdns.cn> To: Di Ma X-Mailer: Apple Mail (2.3608.60.0.2.5) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign7 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] APNIC Routing Security SIG 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, 10 Mar 2020 05:57:22 -0000 Sorry for missing the subscription Web UI. https://www.apnic.net/community/participate/sigs/routing-security-sig/ > 2020=E5=B9=B43=E6=9C=8810=E6=97=A5 13:53=EF=BC=8CDi Ma = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Hi, folks, >=20 > APNIC community has formed a new SIG for Routing Security after APNIC = meeting 49. >=20 > And the mailing list has been just created. >=20 > Welcome to the APNIC "SIG Routing Security" mailing list! >=20 > Di > as co-chair of this SIG >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Mar 10 00:30:27 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 8051E3A0C92 for ; Tue, 10 Mar 2020 00:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 S8lYfJSdJoGh for ; Tue, 10 Mar 2020 00:30:24 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4043A0C90 for ; Tue, 10 Mar 2020 00:30:23 -0700 (PDT) Received: (qmail 30376 invoked by uid 1000); 10 Mar 2020 07:30:18 -0000 Date: Tue, 10 Mar 2020 08:30:18 +0100 From: Claudio Jeker To: sidrops@ietf.org Message-ID: <20200310073018.GF4288@diehard.n-r-g.com> References: <48A08EF5-F932-4249-93EC-CE0E9ED7784E@ripe.net> 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] Validation violations 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, 10 Mar 2020 07:30:27 -0000 On Tue, Mar 10, 2020 at 08:28:08AM +1000, George Michaelson wrote: > We reach out to child CA's regularly. The responsiveness is a function > of leave and other factors getting in the way of remediation. Asking > them whats up and asking for a re-publication feels like the best we > can do because telling them to do things or else is simply not in our > role. Cryptographic/Validation invalidity makes things invalid that > are harmful. The rest is confusing. > > I don't think all problems stem from operator confusion: I believe a > lot of the MFT/CRL mismatch is coming from engines which do in-place > publication and so create downloadable states which are not in the > collection list or the repudation list. I think doing work in a side > directory and a single (semi atomic) mv is probably better from a > coherence point of view, but even between RRDP and rsync there are > disagreements about state and they are not publishing the same > physical on-disk filestate, even if they are assertions about the same > signing events. (I say this observing how things exist in the tree > when I run code) -If the code bases actually do the clone-dir mv trick > then I guess it must be something else. > > The "time of day went backward" thing I think is lack of clock sync > between operational nodes. Do we need to work on some granularity like > 5min or do we obligate NTP time sync? I obviously believe in the > latter but even NTP consists of de-cohered islands of time. There > might be some time dither we need to live with. A minute? Please do not add specifc workarounds to RPKI X509 checking that is not part of X509 itself. When writing a validator we depend on using the X509 validators that are well tested and used for SSL/TLS. Not being able to use the default validation function is a source of major bugs since X509 validitation is complex and fragile. The publisher of RPKI resources can solve this issue by issuing certs, crls, etc with timespans that include a bit of extra time. So just reduce the 'Not Before' time by Xmin and increase the 'Not After' time by Xmin. > There is a persisting overclaim on the edge of the tree rooted in > APNIC, under a sub-CA. I am talking to them about this, why it > persists. It should not persist. That it does worries me, because no > CA code I know of will sign over a child certificate which has > overclaim in the 3779 so it must be persisting state in a child which > hasn't re-synced in up-down, to operate with an overclaim (or, long > lived product which is not being repudiated) > > I run two validator instances locally, same codebase, and they do not > agree much of the time about the intermittent states of invalidity. It > might only be single digit variances, but none the less, two fetches > within 1-2 minutes of each other do not always get the same state, > which them persists for up to 3600 seconds. -- :wq Claudio From nobody Tue Mar 10 01:02:31 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 686143A0D26 for ; Tue, 10 Mar 2020 01:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (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 DWZ73C1ABCcT for ; Tue, 10 Mar 2020 01:02:27 -0700 (PDT) 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 2938F3A0D25 for ; Tue, 10 Mar 2020 01:02:26 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:e835:7167:3a49:a27d] (unknown [IPv6:2001:981:4b52:1:e835:7167:3a49:a27d]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id AA5871F5D4; Tue, 10 Mar 2020 09:02:24 +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=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1583827344; bh=Bxj/WjoZm5hX1JiEpsloFs5WQoznzqYlGRaLzomTjO4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=k9LftUTk+dp2u3WVLNgxK6HzcjD9XR1UmDqbwr+AGbeLkvlM3I/wntvTtha2mtG13 fmJjcpeTozghQ+GbGMpnq2gX/o+eaON2ZJIFyAbd8HM4a7NZ9TZqSXyZBvrgB1dJv2 pYGkZ4a9aqKjWvkOcc5+oEtOFjgPXludva1/o9BI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: <20200310073018.GF4288@diehard.n-r-g.com> Date: Tue, 10 Mar 2020 09:02:24 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <48A08EF5-F932-4249-93EC-CE0E9ED7784E@ripe.net> <20200310073018.GF4288@diehard.n-r-g.com> To: Claudio Jeker X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] Validation violations 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, 10 Mar 2020 08:02:30 -0000 Hi > On 10 Mar 2020, at 08:30, Claudio Jeker = wrote: >=20 > On Tue, Mar 10, 2020 at 08:28:08AM +1000, George Michaelson wrote: >> The "time of day went backward" thing I think is lack of clock sync >> between operational nodes. Do we need to work on some granularity = like >> 5min or do we obligate NTP time sync? I obviously believe in the >> latter but even NTP consists of de-cohered islands of time. There >> might be some time dither we need to live with. A minute? >=20 > Please do not add specifc workarounds to RPKI X509 checking that is = not > part of X509 itself. When writing a validator we depend on using the = X509 > validators that are well tested and used for SSL/TLS. Not being able = to > use the default validation function is a source of major bugs since = X509 > validitation is complex and fragile. The publisher of RPKI > resources can solve this issue by issuing certs, crls, etc with > timespans that include a bit of extra time. > So just reduce the 'Not Before' time by Xmin and increase the 'Not = After' > time by Xmin. I am not sure that George suggested that the workaround should be in the = validation code. For what it's worth Krill uses 5 minutes before now when issuing things just to be safe. We = expect that people use NTP. It's not as not as perfect as we would hope, = and five minutes should be ample to accommodate for it. I am not sure what other CA implementers do, but I would expect that at = least some of them already do this as well. Tim= From nobody Tue Mar 10 07:20: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 283D03A13BF for ; Tue, 10 Mar 2020 07:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 j__tzkz-pnQZ for ; Tue, 10 Mar 2020 07:20:01 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 7B2E73A13BE for ; Tue, 10 Mar 2020 07:20:00 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (unknown [IPv6:2a04:b904::a2c5:89ff:feb5:e311]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id A08A01FD60; Tue, 10 Mar 2020 15:19:58 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Tue, 10 Mar 2020 15:19:57 +0100 From: Martin Hoffmann To: Keyur Patel Cc: SIDR Operations WG Message-ID: <20200310151957.5680f8d4@glaurung.nlnetlabs.nl> In-Reply-To: References: Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24) 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, 10 Mar 2020 14:20:03 -0000 Keyur Patel wrote: >=20 > The authors have requested SIDROPS working group adoption call of > =E2=80=9CRPKI to Router Protocol Version 2=E2=80=9D, > https://tools.ietf.org/html/draft-ymbk-8210bis-00. I support adoption of this document. Kind regards, Martin From nobody Tue Mar 10 08:13:10 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 857343A1454 for ; Tue, 10 Mar 2020 08:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aelmans-eu.20150623.gappssmtp.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 jrUaWhF8QYAa for ; Tue, 10 Mar 2020 08:13:06 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 761483A1448 for ; Tue, 10 Mar 2020 08:13:06 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id a5so1836154wmb.0 for ; Tue, 10 Mar 2020 08:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aelmans-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RN7XaMWQAo3vOOHdjiS1Gc+FXvgeIVfLNZDRJGZVtuQ=; b=yoWQM8zTRSZ4i8W0Qmqbs2dxl2QJBmMpUL+kPWHegXq3pXnRr7+RfMeJxMx2ouiuZe CK1r8uAyJwKgHZBY9hWvS6Vh9uM9ABWBkAaM1xF6yBPQE5KlhzD8tRqeDCJm1RR/Jkpc EY92gnhzvVxNxGVQeN6XgZcg8r093yWWvYmUiqnL6npP1TCf4eKerY5OySfycW2nnGcj Ph5sEjuTr5FUOgedc+gY/VCHeSHgVLTWsJBx3Tf8fc9JkWS8hyvvCkivhNZcZBOhrFSY ECKiutYJj2JF1NZ/6pmTLgn4CzfGTkTHdXfojX2HvlFgalGf/YctyRWMXbqzEJQzKmSn kH9A== 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=RN7XaMWQAo3vOOHdjiS1Gc+FXvgeIVfLNZDRJGZVtuQ=; b=Fv8mA7DrwcIrenMF8f5jKtn/ekO3f1fqdEXSvLjUr1lF4XZK+h/Xug89BgQIOUkM+J Jjxb7XPGTT2ekMjaQxwZ3uSiZTRi0ZDNvl5F5OLttgvf5a4tdpEbDTe40Otz8C1Ffru4 D6fVZ0dpoFYAEOxKkhkvWK5Qib3h4vsOb+f1gaZ/7VP13PM1DD5yW6onJvKVc8eBq+hB HyOql3RXvlFbYMxdhofkWQ7mPe6Es7YykjlLF4oIXfFX6E+zIE48jZ2y7z+AVNsFbEcP TbbkceQbi7nFcpz0EHQ6G96uo2WAY7Z14z7HYlzQp5A7tTXaBdzhywQx4BHogRBRXYSt BeLg== X-Gm-Message-State: ANhLgQ2JDyyZGq+j3aEK/NA/farG3eThSAJyE5Rjg2J6CzMTjOSeL0dt qtO0o2kzCDFEc70ky8jYINDnjE15IV3qdGBldw4wZs6b83twPw== X-Google-Smtp-Source: ADFU+vtgFAG0hcaYw98cw/9nzOw0Atj+cS7mtmTjI+pvcdnHoSZgRjQZYdpffATZoGmhZuugWzX7d8FW0vLcCUVuac4= X-Received: by 2002:a1c:13:: with SMTP id 19mr2669131wma.183.1583853184579; Tue, 10 Mar 2020 08:13:04 -0700 (PDT) MIME-Version: 1.0 References: <17188DA3-7EA6-4317-B878-F687958C7EBB@arrcus.com> In-Reply-To: <17188DA3-7EA6-4317-B878-F687958C7EBB@arrcus.com> From: Melchior Aelmans Date: Tue, 10 Mar 2020 16:12:53 +0100 Message-ID: To: Keyur Patel Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="00000000000071973b05a0818eb5" Archived-At: Subject: Re: [Sidrops] Welcome to Nathalie Trenaman as SIDROPS WG Secretary! 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, 10 Mar 2020 15:13:09 -0000 --00000000000071973b05a0818eb5 Content-Type: text/plain; charset="UTF-8" Congrats!!! You couldn't have found a better one :-) On Mon, Mar 9, 2020 at 9:46 PM Keyur Patel wrote: > SIDROPS WG: > > > > Nathalie Trenaman has agreed to be the SIDROPS WG secretary. Nathalie is > Routing Security Program Manager for the RIPE NCC. She is responsible for > all Routing Security related matters, including RPKI and IRR. She is also > the chair of NLNOG. You can find her on IRCnet as Natha. > > > > Please welcome Nathalie to this new position. > > > > Regards, > > Chris & Keyur > > > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --00000000000071973b05a0818eb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Congrats!!! You couldn't have found a better one :-)
On= Mon, Mar 9, 2020 at 9:46 PM Keyur Patel <keyur@arrcus.com> wrote:

SIDROPS W= G:=C2=A0

=C2=A0

Nathalie = Trenaman has agreed to be the SIDROPS WG secretary.=C2=A0 Nathalie is Routi= ng Security Program Manager for the RIPE NCC. She=C2=A0is responsible for a= ll Routing Security related matters, including RPKI=C2=A0and IRR. She is also the chair of NLNOG. You can find her on IRC= net as Natha.

=C2=A0

Please we= lcome Nathalie to this new position.<= /u>

=C2=A0

Regards,<= /span>

Chris &am= p; Keyur

=C2=A0

=C2=A0<= /span>

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--00000000000071973b05a0818eb5-- From nobody Tue Mar 10 09:21:06 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 89F5F3A150B; Tue, 10 Mar 2020 09:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 g6_H0CX0Eduj; Tue, 10 Mar 2020 09:21:02 -0700 (PDT) Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id D4EA53A15DE; Tue, 10 Mar 2020 09:21:01 -0700 (PDT) Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id 4834A87CA; Tue, 10 Mar 2020 16:21:00 +0000 (UTC) Received: by oz.mt.att.com (Postfix, from userid 1000) id 117D6A41087; Tue, 10 Mar 2020 12:21:00 -0400 (EDT) X-Mailer: emacs 24.3.1 (via feedmail 11-beta-1 I); VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24167.48743.731651.508059@oz.mt.att.com> Date: Tue, 10 Mar 2020 12:20:55 -0400 From: Jay Borkenhagen To: Di Ma Cc: Randy Bush , Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-ads@ietf.org In-Reply-To: <210B997D-67FC-4688-A1EC-7B46DD50BA22@zdns.cn> References: <87sgilgplh.wl-morrowc@ops-netman.net> <210B997D-67FC-4688-A1EC-7B46DD50BA22@zdns.cn> Reply-To: Jay Borkenhagen X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Archived-At: Subject: Re: [Sidrops] Meeting in Vancouver 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, 10 Mar 2020 16:21:05 -0000 I agree that's a worthwhile discussion to have. Presumably https://www.ietf.org/id/draft-ietf-sidrops-rp-06.txt would eventually be updated to reflect whatever consensus might be reached regarding manifest and crl lifetimes and dealing with errors. Speaking of that draft: I urge the authors to go through it again to disambiguate the document's use of the term "RP". In some places it seems to refer to a piece of software that needs to be configured, in others it's a running, configured instance of such software, and in still others it seems to refer to the operators, the humans who have decided that running such software is in the best interests of their network. Thanks. =09=09=09=09=09=09Jay B. Di Ma writes: > I really look forwards to discussions on manifest and CRL lifetimes = and dealing with errors. >=20 > Di >=20 >=20 > > 2020=E5=B9=B43=E6=9C=887=E6=97=A5 05:30=EF=BC=8CRandy Bush =E5=86=99=E9=81=93=EF=BC=9A > >=20 > > i am sure of my non-attendance > >=20 > > i would like to learn more about > > o aspa and rpki-rtrv2 > > o tal migration magic > > o manifest and crl lifetimes and dealing with errors > > o draft-yan-sidrops-roa-considerations should imiho progress > >=20 > > randy > >=20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > >=20 >=20 >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Mar 10 16:03:17 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 13A5B3A0850 for ; Tue, 10 Mar 2020 16:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5gVl3vGWBogM for ; Tue, 10 Mar 2020 16:03:13 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 5C3823A0831 for ; Tue, 10 Mar 2020 16:03:13 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.93) with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from ) id 1jBntz-000RMJ-OI; Wed, 11 Mar 2020 00:03:07 +0100 Received: from x4dbf6690.dyn.telefonica.de ([77.191.102.144] helo=mw-x1.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.93) with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from ) id 1jBntz-000oY5-BB; Wed, 11 Mar 2020 00:03:07 +0100 Date: Wed, 11 Mar 2020 00:03:08 +0100 From: Matthias Waehlisch To: Martin Hoffmann cc: Keyur Patel , SIDR Operations WG In-Reply-To: <20200310151957.5680f8d4@glaurung.nlnetlabs.nl> Message-ID: References: <20200310151957.5680f8d4@glaurung.nlnetlabs.nl> User-Agent: Alpine 2.22 (WNT 404 2020-02-06) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="42716267-24439-1583881388=:10824" X-Originating-IP: 77.191.102.144 Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24) 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, 10 Mar 2020 23:03:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --42716267-24439-1583881388=:10824 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT +1. cheers matthias On Tue, 10 Mar 2020, Martin Hoffmann wrote: > Keyur Patel wrote: > > > > The authors have requested SIDROPS working group adoption call of > > “RPKI to Router Protocol Version 2”, > > https://tools.ietf.org/html/draft-ymbk-8210bis-00. > > I support adoption of this document. > > Kind regards, > Martin > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl --42716267-24439-1583881388=:10824-- From nobody Tue Mar 10 19:49:07 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 2677E3A0FBA for ; Tue, 10 Mar 2020 19:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 e5mIRvk5Iom4 for ; Tue, 10 Mar 2020 19:49:03 -0700 (PDT) Received: from smtpbguseast2.qq.com (smtpbguseast2.qq.com [54.204.34.130]) (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 043D73A0FBF for ; Tue, 10 Mar 2020 19:49:02 -0700 (PDT) X-QQ-mid: bizesmtp19t1583894928tvvi0c59 Received: from [192.168.3.24] (unknown [117.100.110.112]) by esmtp10.qq.com (ESMTP) with id ; Wed, 11 Mar 2020 10:48:47 +0800 (CST) X-QQ-SSF: 00400000002000N0ZI80B00A0000000 X-QQ-FEAT: F8xs2aWDdZhf99NVpDa5SKhYVV79CnK8TKkKEG33ZZmpou6uS3EwLGsfJ5fAM P1L9CS2ozFtVc9iwuESzFZ5k7G5jsEy5EcZqgq5z05eecD+6xmwT5W36Fd/rzSbM3JJThZn WxWeEeSSOj8HqNqIgmtSAVjKwehRTOm2tVERs6srIDFAKTxO92/cTlGb/kPYowCDG9QQRAx PI+Vjdse8URfztWeMM1hLmF30QyNGFlUULlMh2xwDF87SFULS4rvhkZ0tsNJFZU77fjgb0v 2YTb5mPmJYGSAyTflvqoRw+HGY6CTTu2be4cRHA4v2gFaikFzSHzIVulzYjNqBcDYB4qyoT tnwHIPb X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Di Ma In-Reply-To: <24167.48743.731651.508059@oz.mt.att.com> Date: Wed, 11 Mar 2020 10:48:45 +0800 Cc: Randy Bush , Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87sgilgplh.wl-morrowc@ops-netman.net> <210B997D-67FC-4688-A1EC-7B46DD50BA22@zdns.cn> <24167.48743.731651.508059@oz.mt.att.com> To: Jay Borkenhagen X-Mailer: Apple Mail (2.3608.60.0.2.5) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign6 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] Meeting in Vancouver 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: Wed, 11 Mar 2020 02:49:06 -0000 Jay, > Speaking of that draft: I urge the authors to go through it again to > disambiguate the document's use of the term "RP". In some places it > seems to refer to a piece of software that needs to be configured, in > others it's a running, configured instance of such software, and in > still others it seems to refer to the operators, the humans who have > decided that running such software is in the best interests of their > network. >=20 You are making sense here and we authors will look into that and try to = give a better wording. As far as I can tell, I see the term =E2=80=98RP=E2=80=99 a running, = configured instance of some software that can work together to meet the = requirements described in this draft. Di= From nobody Wed Mar 11 00:34:48 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 464243A140D for ; Wed, 11 Mar 2020 00:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (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 apwJaDMF5d6j for ; Wed, 11 Mar 2020 00:34:38 -0700 (PDT) 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 63F833A1405 for ; Wed, 11 Mar 2020 00:34:38 -0700 (PDT) Received: from [10.87.1.124] (unknown [145.15.244.30]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 6EEDF20FFD; Wed, 11 Mar 2020 08:34:34 +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=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1583912075; bh=wyLVh/aNYMrMLZnDA4PvfvYA6gtleHDSa0/K/DT6Jl0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=jxvyYdMJDtrDlshno1FDmmpwaaUfzxDeaQFgpylEwZGDeCZyb4+t49OJvgueKvFuG E245F5wbuqg73hSyLrVkwBu/DB9huR9FM8f8jWc60omQrnvOLkTGuoPrLUAwnAXTIQ p/+e9YwEaIeula9658C6/sHoLBOLztu0Oi9ahDU8= 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 In-Reply-To: Date: Wed, 11 Mar 2020 08:34:00 +0100 Cc: Martin Hoffmann , Keyur Patel , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <42E2B139-BA27-48B3-BF35-6B32986E4B47@nlnetlabs.nl> References: <20200310151957.5680f8d4@glaurung.nlnetlabs.nl> To: Matthias Waehlisch X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24) 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: Wed, 11 Mar 2020 07:34:47 -0000 I support adoption > On 11 Mar 2020, at 00:03, Matthias Waehlisch = wrote: >=20 >=20 > +1. >=20 >=20 > cheers > matthias >=20 > On Tue, 10 Mar 2020, Martin Hoffmann wrote: >=20 >> Keyur Patel wrote: >>>=20 >>> The authors have requested SIDROPS working group adoption call of >>> =E2=80=9CRPKI to Router Protocol Version 2=E2=80=9D, >>> https://tools.ietf.org/html/draft-ymbk-8210bis-00. >>=20 >> I support adoption of this document. >>=20 >> Kind regards, >> Martin >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >=20 >=20 > --=20 > Matthias Waehlisch > .. Freie Universitaet Berlin, Computer Science > ... = http://www.cs.fu-berlin.de/~waehl_________________________________________= ______ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Mar 11 02:34:21 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 40E403A15B6 for ; Wed, 11 Mar 2020 02:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 6ScxFH93YIXO for ; Wed, 11 Mar 2020 02:34:17 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60048.outbound.protection.outlook.com [40.107.6.48]) (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 94A653A158E for ; Wed, 11 Mar 2020 02:34:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ND41boaOxKpgtCqKOGVvT48V1s5vYnkwj/zjm4NjDq8Bjx4G6ioevVfd9Nnvo4A5dOQswlUer+2c50catGqPGRMhO0iOYnQKYBeuM4jVX+q51CZ/I0ktwKfCGjI41QUjVhAJUlj9N+Ecld/0zhhUOpkmwArHICGcRXGIUjzigfkRsGk0hZCv+eVAFqF74OAdKs9RVgJNUCZc9qKli94MZO66DAkRf5qrc/S1vPmHL9vPsGgCl4E5C7A9vqUrlArduu8IqK8nD2Vslf46d0K2bniFKV4BBpMovL7Uq2lXXHPWm8SpNArYd8xU8esiEnEbwKqG9gmUzM+xecHQU2YxPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ogSURUeEfcxoSes0keDeG5MwMM9Lko8y5vC0gF2c5Ow=; b=nXvmF/dn8WmxU9GSFLtiIuJthC46CjcmapkVKh1m09xwQ1Nmehkklq/8RPkWypU1qo9T7we0Am24JHxPgr0uzrucYG0abmpWFXiLCGTgrXhY4ifW2Y0f3VXY4v9DyC0kDAb/axCI4vT1BrTol4Q9hAEJ/CFVeVvCJVpVkT6BpLh4t1qGqs5fxcE+21xAMNaQhVtMuGnZ26TmxXGEvVbfVgrrO6j7SZJ+BjcvEjnMz0PLRusPXSXnsZAaHTpZvc9yyBpwCXroyypZTkjs1Y7vA/tfL5FskA4O1bB8rnJ7kfrAqjkxcF5rgxFil2gRG9OnQ9FU2Wvc5mwt0GtS85Jkkg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ogSURUeEfcxoSes0keDeG5MwMM9Lko8y5vC0gF2c5Ow=; b=pznKCAwG8NH7egC+UAYUzMdrx+sve7YbmcdcsaBk+KsDofHDqjn5mxsDyKxM4zMrmiuCvfvKvA2b68FnI/VrLQc9I83NHRZ0zOTFNvjY1feIFTjTJ88k6nYI38wBb/JGJJ0XHMK5rpjPpiiVnU2J6zGDP+v/lnaghf2/aU6iu6k= Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (52.135.56.21) by AM7P190MB0759.EURP190.PROD.OUTLOOK.COM (52.135.56.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.16; Wed, 11 Mar 2020 09:34:14 +0000 Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252%7]) with mapi id 15.20.2793.018; Wed, 11 Mar 2020 09:34:14 +0000 From: Ben Maddison To: "keyur@arrcus.com" , "sidrops@ietf.org" Thread-Topic: [Sidrops] WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24) Thread-Index: AQHV9k3dG6VaK9VoVUiQBn27Bv4nU6hDI9EA Date: Wed, 11 Mar 2020 09:34:14 +0000 Message-ID: <8d49c22eb5e9e969c0a6a8b07db68669e952be1d.camel@workonline.africa> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa; x-originating-ip: [160.119.236.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 44870a50-3f55-4d38-5073-08d7c59f5cfe x-ms-traffictypediagnostic: AM7P190MB0759: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2733; x-forefront-prvs: 0339F89554 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39840400004)(136003)(376002)(366004)(396003)(199004)(6486002)(71200400001)(2616005)(966005)(66556008)(8936002)(64756008)(508600001)(66574012)(5660300002)(76116006)(66446008)(26005)(86362001)(91956017)(66946007)(6506007)(66476007)(2906002)(110136005)(186003)(6512007)(8676002)(81156014)(81166006)(558084003)(316002)(46492006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P190MB0759; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: exhbFAxVFxrlkd7RipYfJ2pdA9vRzFnelrkZfn2OtiH0BqsJzcneOCVJ4b8MZHhFI7tWAL2RUVF88PKZ58cpvumojGzUhl1dxi/dgKUpNfMZGSuowzyO0z4pag6Lql0s8WNmloc/rLp8XqEB9g0+qfMpfIXXxylTXIGwK+OszBFF3ECKK4MkB6SdCmQi/HZ3Fzx50XnijisHr23rEtwrNK1Mg17s5uK5LpkVYEw1/qKhXyoycEBuLLfFvzs8flFhVoKRetQUtwy7S+8pg5Mb6TvZyDG3D5mQVkkgCnJMWpDvIWZPXpUOUcrcXx22tP8Q/lkvWMHyz4BtGAh3QrExa5GT38QNsNfj3pJUBXsLrBWFOe8ePWchvWtRw5suu9Ausj/ywAglRzRJwmH9kbWofM6MKW+NP08DhO2+oL29r7yMGJjbbDuRY/HJDK059zFx8RLpUMt8i87R/732kAUSUbX1PFu8H6hp0zJix/5NZJgELHNc97DL8JC2eHp0WOQD0HOe9tnwWzx6NBjfAK7CQFXUT/vMOpNFPtGdJjdOwWSDkS9br+dLwWRFID+/B3Qc x-ms-exchange-antispam-messagedata: qfIMPe16buqvRlsAHHU7WUvGfWvhuuK5ki0QNaPRps3TmrCsij2RQmnachvCKHIWBfm8SIwCfXRQQ7OEkarR4Kn15SsubnGPzjl3g8/tHbn07SyQDV/08b+bDr65fIxiraDr8Xkx2RdbCnAYLONIag== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0A06D45B19ADFA45A7598A6D2938D68C@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 44870a50-3f55-4d38-5073-08d7c59f5cfe X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2020 09:34:14.5891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7aRdv9Eq0k9ajVBlJPkEOCd191jB3Tjm+3zUt0vev+m1RTv4ggWCtXmnteccK8vtB60rBWYwH2YXiiWpiIk02Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0759 Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24) 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: Wed, 11 Mar 2020 09:34:20 -0000 SGkgYWxsLA0KDQpPbiBNb24sIDIwMjAtMDMtMDkgYXQgMjA6MDMgKzAwMDAsIEtleXVyIFBhdGVs IHdyb3RlOg0KPiBIaSBGb2xrcywNCj4gDQo+IFRoZSBhdXRob3JzIGhhdmUgcmVxdWVzdGVkIFNJ RFJPUFMgd29ya2luZyBncm91cCBhZG9wdGlvbiBjYWxsIG9mDQo+IOKAnFJQS0kgdG8gUm91dGVy IFByb3RvY29sIFZlcnNpb24gMuKAnSwgIA0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQteW1iay04MjEwYmlzLTAwLg0KPiANCkkgc3VwcG9ydA0KDQpDaGVlcnMsDQoNCkJlbg0K DQo= From nobody Wed Mar 11 06:32:06 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 6C9553A18B5 for ; Wed, 11 Mar 2020 06:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 oTw13AeRK0sG for ; Wed, 11 Mar 2020 06:32:00 -0700 (PDT) Received: from smtpbguseast2.qq.com (smtpbguseast2.qq.com [54.204.34.130]) (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 C50DB3A12B6 for ; Wed, 11 Mar 2020 06:31:59 -0700 (PDT) X-QQ-mid: bizesmtp26t1583933514tqjodp0s Received: from [192.168.3.24] (unknown [117.100.110.112]) by esmtp10.qq.com (ESMTP) with id ; Wed, 11 Mar 2020 21:31:51 +0800 (CST) X-QQ-SSF: 00400000002000N0ZI80000A0000000 X-QQ-FEAT: FtiPHz2NrtXW94eGKE8lUzZwHx5HkkTg6TnyrWsFMZajNN2/FtkRGnR80bBgu hzM5x5sUJkUX/eueO88p8vkDiqgCdeYl9jCYdZov4T8NOGqnOBxGOX/Cv0ydnsm+p0P/bz8 nUlZS/+WYYLiIEMMwu1wJOf+Qq0IEnUU0m01EHMBkl1AdXVjCKj8ntswTFM6GhzND2gu1xI BkfHE+oG7Bl4Yhp305nCqKTtns4De3ULsKacRkmGUcXyyCQxMW90NY8f+8wIlY9Om9tRInm DhhLp0invMh4W0KyyWwgiGV8SWdKv3HmwLnw6ZjE85yOx//asFH2GT3Wtmq0b0KAZXzAf8R SulXjyVc2wBo/v1UBgGle4eh/NxgxLZgK48C2CDL49vUXi3RvI= X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Di Ma In-Reply-To: Date: Wed, 11 Mar 2020 21:31:50 +0800 Cc: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87sgilgplh.wl-morrowc@ops-netman.net> <210B997D-67FC-4688-A1EC-7B46DD50BA22@zdns.cn> <24167.48743.731651.508059@oz.mt.att.com> To: Jay Borkenhagen X-Mailer: Apple Mail (2.3608.60.0.2.5) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign6 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] Meeting in Vancouver 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: Wed, 11 Mar 2020 13:32:05 -0000 Jay, After my second thought and discussion with co-author Dr. Stephen Kent, = the term "relying party" technically refers to a person or organization, = so when we mean to refer to the software they employ, just add the word = "software" to the text.=20 Generally there is no need to distinguish whether the software is to be = configured vs. whether it is running. And we authors will review this draft and make necessary update as per = your concern when IETF last call and IESG evaluation are complete. Di > 2020=E5=B9=B43=E6=9C=8811=E6=97=A5 10:48=EF=BC=8CDi Ma = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Jay, >=20 >> Speaking of that draft: I urge the authors to go through it again to >> disambiguate the document's use of the term "RP". In some places it >> seems to refer to a piece of software that needs to be configured, in >> others it's a running, configured instance of such software, and in >> still others it seems to refer to the operators, the humans who have >> decided that running such software is in the best interests of their >> network. >>=20 >=20 > You are making sense here and we authors will look into that and try = to give a better wording. >=20 > As far as I can tell, I see the term =E2=80=98RP=E2=80=99 a running, = configured instance of some software that can work together to meet the = requirements described in this draft. >=20 > Di >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Mar 11 08:32:02 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 4F3ED3A094D for ; Wed, 11 Mar 2020 08:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ZxPbKJdWY78b for ; Wed, 11 Mar 2020 08:31:58 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 883633A0931 for ; Wed, 11 Mar 2020 08:31:58 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jC3Kv-0000BL-7i for sidrops@ietf.org; Wed, 11 Mar 2020 16:31:57 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::97a]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jC3Kv-0001Z1-34; Wed, 11 Mar 2020 16:31:57 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Oleg Muravskiy In-Reply-To: Date: Wed, 11 Mar 2020 16:31:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <603F22AC-E2DB-4AEA-8242-F0A021869B5B@ripe.net> References: To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.60.0.2.5) X-ACL-Warn: Delaying message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b743bf3ba384056235c7e0da5ac6fc7d400 Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24) 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: Wed, 11 Mar 2020 15:32:01 -0000 On 9 Mar 2020, at 21:03, Keyur Patel wrote: >=20 > Hi Folks, > =20 > The authors have requested SIDROPS working group adoption call of = =E2=80=9CRPKI to Router Protocol Version 2=E2=80=9D, = https://tools.ietf.org/html/draft-ymbk-8210bis-00. > =20 > Please send your comments to the list. This adoption call will = conclude on March 24, 2020. Support Oleg From nobody Thu Mar 12 02:04:16 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 54D2F3A13B9 for ; Thu, 12 Mar 2020 02:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 f155zWYUAYlA for ; Thu, 12 Mar 2020 02:04:13 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::624]) (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 CA2E23A13B7 for ; Thu, 12 Mar 2020 02:04:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VTSYbssGgyFzQKeIFaVL6QJbXdSHUbNiItP+1j2VQPQvUGxvHIZIviDsr9HmLLD/FHc42oCaewfmJ3fMEQX/2EgkwKVcUN35OkhtKLcLJcOFNbFR425+gRTLfi+2UpgXjQNq4wHWmV5+Sl6Rtf00FBE/Ove5VbPq1CsCsBVnkudebwjyUjYztEhShsZQ0JcKwRFEo5CrjpRVF6OLMo8gFA4jnDHPB2+k/QThRjpp3LK+TIhPEPP7pLXhlORye23U0Zb6Nb0luLLbYbIfpbwTnNutS6ekrQcB+tn7dxaDyvjRAG5fsoSf2GgudnjjWM6LexkEMcuMO18XDwOPFLeddA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9QTpOgt7kFJud/51RcJVWEK8ezTLPd2iefchn3X7QLY=; b=ZR7NfdvX5SQEfZCh9+6m7OwSSZH3YCYJ6oyZrybRv6TfmJd92Mgi1ixbOG86hdOtgTekHhQXCkhJbtNslhKLDaxERWFDw4mixRBLCCm8yAp7LeeUNVZlPT9sNRvOv5ELwvp6FzY9Ya4Pxn3oAzkUWgAsZgZO0Kg8jMdXsXXox9B/Eb+hAtaJjl8IlVz3nRoDZ17b0WU8O7t7DT660BNGlzyjwFxzwcjfVNga8zUV5aaTPYMvoGcxV1Oqml2ATcNgLUS2LxrvFkiW9N+YzX6R+rHCiDr68ULhPq6Z+6P1XsACg8Nklpi6bk4Icc0LD/XoXW6/C2+Pw3bLlZdNwvRmgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9QTpOgt7kFJud/51RcJVWEK8ezTLPd2iefchn3X7QLY=; b=PHMqL12lqy28eLWqDUI6Qf9VrVX0tAiuxKEsvHnsOBaBZ0ZA/y7NYLXlYjwrB5aOktpxWP2z0j1JkPOQdDoNfqYI5CgksS1N67NFjHT3q5LupPr0RtuuZDR6zhUYfsfKcnPj6d2yHNLtutOOUS1kd1372ULd+Psi4VUQ51o+aTo= Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (52.135.56.21) by AM7P190MB0711.EURP190.PROD.OUTLOOK.COM (52.135.57.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11; Thu, 12 Mar 2020 09:04:08 +0000 Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252%7]) with mapi id 15.20.2793.018; Thu, 12 Mar 2020 09:04:08 +0000 From: Ben Maddison To: "sidrops@ietf.org" Thread-Topic: ROV with ATOMIC_AGGREGATE Thread-Index: AQHV+E0wwUyxqbDFp0uB5piITHtFQg== Date: Thu, 12 Mar 2020 09:04:08 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa; x-originating-ip: [105.28.114.163] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1519375d-eaca-4e96-6d85-08d7c6645317 x-ms-traffictypediagnostic: AM7P190MB0711: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0340850FCD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39840400004)(376002)(396003)(366004)(199004)(8676002)(6486002)(2906002)(91956017)(66946007)(66556008)(6512007)(76116006)(6916009)(5660300002)(66476007)(64756008)(2616005)(66446008)(186003)(508600001)(26005)(81156014)(81166006)(7116003)(8936002)(71200400001)(86362001)(316002)(4744005)(6506007)(46492006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P190MB0711; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RGZK7M9NnrhvitxO3R8/pFDNjAi9IFHg/Qp1OBHhPGQNaoX5OEVxN+iSJ6aWiSIBodBjaz88Oflf+oBK7242b+YKiFtFt9eVfAVS+lhAiCV02KldvjCEEQOQVJoxBdGE7DnSbOUT7Hfxh5hYiYcHCfkYe2lRnZz2paSVYNCEHV/jMxgYfKIp79ujkigPYsiQOpvJmLd0pQUapyceyJbmmLXHYIO3eCtjxc02AnL7idpxnIqAiJOlXtnBOQLvccAV3fe8fdc6I8lWyhsyGUplbcFYchdfpkoGaIwFC9CXQHnw9lmA0OScKBeEli3M1cl3Rzv58qqIni9/P3SgytbjeEzixv5EZvB9yRCj4K4zZ8YEAAXKiiOo6wy9tTTuOdqFeE0LLtNW+FJM9o+TPQ2wda3QfvGlnNdp4yhY0b3+5AolrDvbFLz7HG3Z63cCBShZV6KftEE6vw3CHfMM2rFsT4xKDMVyc05MFOV3AUuoxqA= x-ms-exchange-antispam-messagedata: TlVIJYEjE6ylFX14H3u2PsaZTodBoPn8HQAo26GvXYk/6T3/+YsjOqL/gIJvMUErSJVzfwddYhlsEBQ++vGW6/4y7PCqVhixjE0nAS0vZ6/5DPW3QaSI08AC3+BsGFCoqGvBGAeOgc5X/zVNbOeGmA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7A6FB8E01813BF4A93E8FA5DF5AB9632@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 1519375d-eaca-4e96-6d85-08d7c6645317 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 09:04:08.8372 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sbi5GvvPVCtGoBGi+7A9BMO0JAD802xWqJihw5vmfme4uo6lJwfinJdVM0Pvw/hm8P3xSaJo10HvZOJSw8TS/w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0711 Archived-At: Subject: [Sidrops] ROV with ATOMIC_AGGREGATE 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, 12 Mar 2020 09:04:15 -0000 SGkgYWxsLA0KDQpJJ20gY3VycmVudGx5IHdvcmtpbmcgd2l0aCBvbmUgb2Ygb3VyIHZlbmRvcnMg b24gZ2V0dGluZyB0aGVpciBpbml0aWFsDQpST1YgaW1wbGVtZW50YXRpb24gcmVhZHkgdG8gc2hp cC4NCg0KSW4gdGhlaXIgY3VycmVudCBjb2RlIHRoZXkgYXJlIHNldHRpbmcgdmFsaWRhdGlvbiBz dGF0ZSBvZiBhIHJvdXRlIHRvDQpJbnZhbGlkIGlmOg0KMS4gVGhlIHJvdXRlIGhhcyB0aGUgQVRP TUlDX0FHR1JFR0FURSBhdHRyaWJ1dGUgc2V0OyBhbmQNCjIuIFRoZSByb3V0ZSBpcyBjb3ZlcmVk IGJ5IGFueSB2YWxpZCBST0EuDQoNCk5vdGUgdGhhdCB0aGV5IGFyZSBhbHNvLCBjb3JyZWN0bHks IHNldHRpbmcgc3RhdGU9SW52YWxpZCBpZiB0aGUgZmluYWwNCnNlZ21lbnQgb2YgQVNfUEFUSCBp cyBhbiBBU19TRVQgKGFuZCB0aGUgcm91dGUgaXMgY292ZXJlZCBieSBhIFJPQSkuDQpUaGlzIGlz IGluZGVwZW5kZW50IG9mIHRoZSBhYm92ZSBiZWhhdmlvci4NCg0KVGhlcmUgYXBwZWFycyB0byBt ZSB0byBiZSBjbGVhcmx5IHdyb25nLiBJIGNhbiBmaW5kIG5vdGhpbmcgaW4gYW55DQpyZWxldmFu dCBSRkMgdGhhdCByZXF1aXJlcyB0aGUgdmFsaWRhdGluZyBCR1Agc3BlYWtlciB0byBjb25zaWRl ciB0aGUNCkFUT01JQ19BR0dSRUdBVEUgYXR0cmlidXRlIG9uZSB3YXkgb3IgYW5vdGhlci4NCg0K SSdkIGxpa2UgdG8gYXNrIHRoZSBXRyB0byBjb3JyZWN0IG1lIGluIGNhc2UgSSBoYXZlIG1pc3Nl ZCBzb21ldGhpbmcsDQpiZWZvcmUgSSB0ZWxsIHRoZSB2ZW5kb3IgdG8gZ28gZml4IHRoaXMsIHBs ZWFzZT8NCg0KQ2hlZXJzLA0KDQpCZW4NCg0K From nobody Thu Mar 12 04:07: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 4C7CD3A0CA2 for ; Thu, 12 Mar 2020 04:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 t8zq1SilxGKR for ; Thu, 12 Mar 2020 04:07:38 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AC6673A0C99 for ; Thu, 12 Mar 2020 04:07:35 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id A5C391E2D3; Thu, 12 Mar 2020 07:13:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Jeffrey Haas In-Reply-To: Date: Thu, 12 Mar 2020 07:07:34 -0400 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ben Maddison X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Sidrops] ROV with ATOMIC_AGGREGATE 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, 12 Mar 2020 11:07:40 -0000 I am massively behind in my IETF mail, but the subject line caught my = eye. > On Mar 12, 2020, at 5:04 AM, Ben Maddison = wrote: >=20 > Hi all, >=20 > I'm currently working with one of our vendors on getting their initial > ROV implementation ready to ship. >=20 > In their current code they are setting validation state of a route to > Invalid if: > 1. The route has the ATOMIC_AGGREGATE attribute set; and > 2. The route is covered by any valid ROA. >=20 > Note that they are also, correctly, setting state=3DInvalid if the = final > segment of AS_PATH is an AS_SET (and the route is covered by a ROA). > This is independent of the above behavior. >=20 > There appears to me to be clearly wrong. I can find nothing in any > relevant RFC that requires the validating BGP speaker to consider the > ATOMIC_AGGREGATE attribute one way or another. >=20 > I'd like to ask the WG to correct me in case I have missed something, > before I tell the vendor to go fix this, please? ATOMIC_AGGREGATE is the remaining fig leaf of proper aggregation. Many = implementations didn't check the resultant AS_PATH to see if it was = truncated or not as part of aggregation, and simply sets the flag. And, = since this is showing up in some cases as part of private-as aggregation = steps as well you might not have a good belief that it is improperly = being set depending on the point it's injected into the Internet tables. If the origin AS, sans sets, is correct - the implementation should = believe it. If you want path validation, we need bgpsec. -- Jeff From nobody Thu Mar 12 05:54:59 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 802E53A0407 for ; Thu, 12 Mar 2020 05:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 DyaU2lM3axp6 for ; Thu, 12 Mar 2020 05:54:55 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80045.outbound.protection.outlook.com [40.107.8.45]) (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 0C22D3A00D9 for ; Thu, 12 Mar 2020 05:54:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kI4AF475zX+M9NGzVgWI56FpxjMwJbDABJVeltD93RyAAXkphPGvyxeMW47rcXI0qjnNuidMQeuWvAzY2MUHM4RxeIlg8CjzVsSVAECWrFd7+es/EjdocfSNEoCWbDIeX9sr850ZMCwMwqaM1rimh7Tz2dW++0N5Hf87OocsamMZmXo40MDINOe9ppSxCyDgpaBn1+HU2X1yFBLeLAUvlBdXAfKZwWbHDjaVJPs3x/BLAXdqveT7YzGQPJYeAZyqCljpYABUSuiRvB+vgnfdbN4LTiwQFMJt4SxtMsudnAt3gF/1/ZG/yL742Abb2cRvXoCGGqlOSKmbC8Nh2j/Fkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nqo3Fwl/U/TFVeLg7j9XKG3L3NM10Afcx2kK2+dEpB0=; b=H0b1L4+wNQTd5m0htZZ+D5/LQaUGjsOh696No7ZYIDPzhchExL/tVmrFkRQ/Gt5JErs7dBfrwbcPFj4y2HaliprUyRZ1XtksbhZw6P4cx1LCdaRsQNz+3rTZMF/WDfVI7arGdV4MfNEAeaOMH63QKEaSk/x0Hz/wu/XS1JQejGIosXRqEkHt7Vbo1PJRYWnAwj1GegdfglF7n2RZflJMUt2bM7XZOPZqnLPG/LbhnmI6GrfrDmS2viW4SfbyXAkMd8VadmaLQ0608PkVcheg2ZM8dOu/U82UkCLLJW5l/j9JiSZbHPfYK0fwueKlRE0BDAi6ojjxTFsPkR45m6hocw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nqo3Fwl/U/TFVeLg7j9XKG3L3NM10Afcx2kK2+dEpB0=; b=ibh+vKYM4Qjd9Ym9Op8g6J/oR32Vt0PYIs70x2XQtmnAo2j1fKDnbQ1Cb6x53qIW0aCdgK7fTAXgUPGVj3onYSUf/oeYOaDDmu8aApJNaUjEYbM0HQU4frFGJY329abu/Se/e6YxJPOuRFMQ2glYUo+WjmFI+YHlass21GwhC34= Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (52.135.56.21) by AM7P190MB0629.EURP190.PROD.OUTLOOK.COM (52.135.58.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Thu, 12 Mar 2020 12:54:52 +0000 Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252%7]) with mapi id 15.20.2793.018; Thu, 12 Mar 2020 12:54:51 +0000 From: Ben Maddison To: "jhaas@pfrc.org" , "benm=40workonline.africa@dmarc.ietf.org" CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] ROV with ATOMIC_AGGREGATE Thread-Index: AQHV+E0wwUyxqbDFp0uB5piITHtFQqhEzEIAgAAd+AA= Date: Thu, 12 Mar 2020 12:54:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa; x-originating-ip: [41.71.103.227] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b08fe14-ecde-4438-e2b2-08d7c6848e2f x-ms-traffictypediagnostic: AM7P190MB0629: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0340850FCD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39840400004)(346002)(376002)(136003)(396003)(199004)(91956017)(66476007)(76116006)(66946007)(508600001)(4326008)(81166006)(26005)(6486002)(81156014)(4744005)(186003)(5660300002)(71200400001)(55236004)(86362001)(6512007)(110136005)(316002)(6506007)(8676002)(2616005)(8936002)(62860400002)(66446008)(64756008)(66556008)(2906002)(46492006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P190MB0629; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: i7MrkyyaqqkobqVMxQVYTec3w6sqV+Pzai4YWa3Z0gYrN0ETCRAePkQvy7XG3cY3IwK9wVM5vmwxGDMepDR324A0XdjhDI0tJUCp7sL/lhnweFXNYV3M5d41SnnYAxFrrpuaSbxMTqy3UkGPSOr4TwB2eDiCFjsQDskPAI9NZPrRIHoBnHweu5Nm0ueFdYv9StwUYudKYu4AwsC0IXJIjMtIhlKzcssiKkHkwxYxIogL+QkD8zeJtvIF8voJpRx9ZAWR1lk2/YW0lC/aKE3AObXbEq8SktQ+tmj5wMo6sUe+UaAqXnU6PYdRZUVfGdPaU87bKV8G5vb/98xwbrHDaXmNVoeLZZqyU6B2EEecJJXSokbqQLroZT27Tn/J85xZq5B62BJCgX2OeNHDYPxelcxTf+gY1dohqVhXW/XEpmdKREf6IXXwgutypyV1AiLkkPpjAvABMM7Y24P5cmgWngM976BN/prATX1abyTJXDG4cSF0gLPkF48GMY8Ot/gq0DNnz4OaOmM6tJvxwNOUEMd20aGEBfdphOjI0mfyDZi6H3DtZ59Hc3/VusrUbE8f x-ms-exchange-antispam-messagedata: XAeC86k94eY3JVaeOM2Ap+4LWsop6rBCvBZ1wSfPUHhcUNxkUWxwcx/pUK3aN2rg0fYVFojIICJvyyzVnkrvWTuhF1TlF6n7R/GhM0pmHnR3md10d/3ltdJrLW99IVnbeyK6vLuEsFCZHKKU2Y3lxw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <556607EC87D21B419D2A38F21B914C7F@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 8b08fe14-ecde-4438-e2b2-08d7c6848e2f X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 12:54:51.8316 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: B4d9ioNcl86DlD9OEvf+P7itnXqh85lnNbR8kCKJh+G8KccdfOUqaBqV2T+vg8OQvhBt1n4PZXrxTCv0WwdO1w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0629 Archived-At: Subject: Re: [Sidrops] ROV with ATOMIC_AGGREGATE 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, 12 Mar 2020 12:54:58 -0000 VGhhbmtzIEplZmYsDQoNCllvdSBjYW4gYmUga2luZGEgaGFyZCB0byBwYXJzZSBzb21ldGltZXMh DQoNCk9uIFRodSwgMjAyMC0wMy0xMiBhdCAwNzowNyAtMDQwMCwgSmVmZnJleSBIYWFzIHdyb3Rl Og0KPiANCj4gSWYgdGhlIG9yaWdpbiBBUywgc2FucyBzZXRzLCBpcyBjb3JyZWN0IC0gdGhlIGlt cGxlbWVudGF0aW9uIHNob3VsZA0KPiBiZWxpZXZlIGl0Lg0KPiANCllvdSdyZSBzYXlpbmcgdGhh dDoNCg0KYGBgDQogICBvICBSb3V0ZSBPcmlnaW4gQVNOOiBUaGUgb3JpZ2luIEFTIG51bWJlciBk ZXJpdmVkIGZyb20gYSBSb3V0ZSBhcw0KICAgICAgZm9sbG93czoNCg0KICAgICAgKiAgdGhlIHJp Z2h0bW9zdCBBUyBpbiB0aGUgZmluYWwgc2VnbWVudCBvZiB0aGUgQVNfUEFUSCBhdHRyaWJ1dGUN CiAgICAgICAgIGluIHRoZSBSb3V0ZSBpZiB0aGF0IHNlZ21lbnQgaXMgb2YgdHlwZSBBU19TRVFV RU5DRSwgb3INCg0KICAgICAgKiAgdGhlIEJHUCBzcGVha2VyJ3Mgb3duIEFTIG51bWJlciBpZiB0 aGF0IHNlZ21lbnQgaXMgb2YgdHlwZQ0KICAgICAgICAgQVNfQ09ORkVEX1NFUVVFTkNFIG9yIEFT X0NPTkZFRF9TRVQgb3IgaWYgdGhlIEFTX1BBVEggaXMNCmVtcHR5LA0KICAgICAgICAgb3INCg0K ICAgICAgKiAgdGhlIGRpc3Rpbmd1aXNoZWQgdmFsdWUgIk5PTkUiIGlmIHRoZSBmaW5hbCBzZWdt ZW50IG9mIHRoZQ0KICAgICAgICAgQVNfUEFUSCBhdHRyaWJ1dGUgaXMgb2YgYW55IG90aGVyIHR5 cGUuDQpgYGANCihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjgxMSNzZWN0aW9uLTIp DQoNCkFwcGxpZXMsIGFzIGlzLCBpcnJlc3BlY3RpdmUgb2YgdGhlIHBvc3NpYmxlIHByZXNlbmNl IG9mDQpBVE9NSUNfQUdHUkVHQVRFLCByaWdodD8NCg0KQ2hlZXJzLA0KDQpCZW4NCg0KPiBJZiB5 b3Ugd2FudCBwYXRoIHZhbGlkYXRpb24sIHdlIG5lZWQgYmdwc2VjLg0KPiANCkRlcGVuZGluZyBv biB3aGF0IHlvdSB3YW50IHRvIHZhbGlkYXRlIGl0ICphZ2FpbnN0KiwgeW91IG1heSBuZWVkIEFT UEEuDQpCdXQgdGhhdCdzIGEgZGlmZmVyZW50IGNvbnZlcnNhdGlvbi4NCg0KQ2hlZXJzLA0KDQpC ZW4NCg0K From nobody Thu Mar 12 07:56:58 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 C9D913A0941 for ; Thu, 12 Mar 2020 07:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 NnlK0eGSPRLK for ; Thu, 12 Mar 2020 07:56:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 26F503A096B for ; Thu, 12 Mar 2020 07:56:53 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 41F3D1E2D3; Thu, 12 Mar 2020 11:02:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Jeffrey Haas In-Reply-To: Date: Thu, 12 Mar 2020 10:56:51 -0400 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ben Maddison X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Sidrops] ROV with ATOMIC_AGGREGATE 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, 12 Mar 2020 14:56:57 -0000 Ben, > On Mar 12, 2020, at 8:54 AM, Ben Maddison = wrote: >=20 > Thanks Jeff, >=20 > You can be kinda hard to parse sometimes! Sorry, this was pre-coffee. >=20 > On Thu, 2020-03-12 at 07:07 -0400, Jeffrey Haas wrote: >>=20 >> If the origin AS, sans sets, is correct - the implementation should >> believe it. >>=20 > You're saying that: >=20 > ``` > o Route Origin ASN: The origin AS number derived from a Route as > follows: >=20 > * the rightmost AS in the final segment of the AS_PATH attribute > in the Route if that segment is of type AS_SEQUENCE, or >=20 > * the BGP speaker's own AS number if that segment is of type > AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is > empty, > or >=20 > * the distinguished value "NONE" if the final segment of the > AS_PATH attribute is of any other type. > ``` > (https://tools.ietf.org/html/rfc6811#section-2) >=20 > Applies, as is, irrespective of the possible presence of > ATOMIC_AGGREGATE, right? Exactly. ATOMIC_AGGREGATE these days[1] means that aggregation has been done at = some point in the life of the BGP AS_PATH for the NLRI in question. Once it has been added, subsequent aggregation could have been done, and = may have set elements added to it. In such cases, the current desired = behavior is that the route cannot be used for origin validation = purposes. However, similarly, subsequent aggregation may be done and further = information lost from the AS_PATH; we don't get more than one = ATOMIC_AGGREGATE marker and it has no counter. My general observations on aggregation with respect to origin validation = have been: - Parties that have the "right" to aggregate (prefix ownership, or owner = of prefix that more specifics have been delegated from) can aggregate = and it'd still match RPKI policies. - Proxy aggregation by other parties will fail RPKI policies. The first case means that ATOMIC_AGGREGATE ("brief") style aggregation = is fine and fits the intent of RPKI origin validation. The second case = doesn't fit the intent and will fail regardless fo whether there's a set = or not. It's this set of properties that has me being an objecting party to the = movement to completely kill set behaviors in BGP as-paths. it has more = than the usual incremental deployment issues to be conformant with = actual "deprecation" and doesn't help with the desired intent. I'm = quite happy to say "don't do that" and let RPKI slowly extinguish the = feature's use. >=20 > Cheers, >=20 > Ben >=20 >> If you want path validation, we need bgpsec. >>=20 > Depending on what you want to validate it *against*, you may need = ASPA. > But that's a different conversation. Indeed. Relevant to this particular conversation, if you're concerned = about truncated paths, which is what ATOMIC_AGGREGATE is intended to = help signal, you may care that the route's origin AS was actually = originated by that AS. -- Jeff [1] The ATOMIC_AGGREGATE feature in BGP is an interesting anatomical = vestige from the BGP-3 to BGP-4 transition that never got deployed = properly. The originally desired behavior for it was incorrect from the = start and unimplementable. It also made my nascent life in IETF work = unnecessarily interesting. From nobody Thu Mar 12 08:57:10 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 A124F3A0C76 for ; Thu, 12 Mar 2020 08:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 72cSjaibc-Rl for ; Thu, 12 Mar 2020 08:57:07 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0625.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::625]) (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 9DF5B3A084B for ; Thu, 12 Mar 2020 08:57:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bj2EwNoMmXf7hV+ud24UmXpjG/9H2EvMB09ycbeQPFKay+ADxt74PBEeRwN5VvkAOG15OQC322bXcAfkGAQA5daOxMe3d3sbq01j0TJH7wOptRs7tuMTtFYSEIcj07INEOvJpylRvUhRpgwYcw9kBWxjve5Q01fFte5/LCb1kj0x2okQWkQv/B5p3ExJ2hnHIYykO1gmV1BuzKDNRkFyEdWNeIwY1/MpVgDy9OQ564gsLKkFv3GxRQz9Ec4eU4yVfeFp0VuPXU5cEnUK15wGxAqDqa0s/i3tXFME2HYA0L3HkJaEpZWpX8fXKoipvK6CetFQaSCAHWz45j0uKwGkyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/sn2KoxvQnh/3EOz/stmblCM02a3+Qcrj92qCozVGPo=; b=Gc5V8L96kpMMnwvORGOfsz+BOQVKTtBJPCzj2CNzKImIiZXtZVW/xIyGPH1qiWekUKolGPFHxc0buHDQMhOajW7V95hnOx+CukwVI3LKD/vio0kdHi599wfXy6OSe0t2ychIxzDDnzCc171cIwC43JpaWOrGnk88b3yU4nq29J7xwgQabjOGFOw1SLZS7QoESeUUEsnMkymRAYEAkNkn1wxeLY/q/YPANKpLR+wakkNgliGrauXx0pE88pwyhPqRGs6IidySzR7JdlOnHKiVWKCTWv883uHHIaE3be4nXQtan2JAYf5++I7ZqOngx6rVaQloKLJCrG2YpC0/vYOGow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/sn2KoxvQnh/3EOz/stmblCM02a3+Qcrj92qCozVGPo=; b=rPefkSnbCh3m7a6d2fu35VBwkU2U+DDYl3KU0xf2hkyB0nvAQZyDTns2H2Pd8EwAiGPEsWaVySWZZhLfBN7cho/gkrJbM8JMDcDYj+RyyxaWXWnYgRwi5HbhjuGy5+c3ihnoMT5jLLmuLqBglDDRsZhMCg57Dpw1XK/WQiUeVcw= Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (52.135.56.21) by AM7P190MB0613.EURP190.PROD.OUTLOOK.COM (52.135.56.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.14; Thu, 12 Mar 2020 15:57:03 +0000 Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252%7]) with mapi id 15.20.2793.018; Thu, 12 Mar 2020 15:57:03 +0000 From: Ben Maddison To: "jhaas@pfrc.org" CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] ROV with ATOMIC_AGGREGATE Thread-Index: AQHV+E0wwUyxqbDFp0uB5piITHtFQqhEzEIAgAAd+ACAACIYgIAAEM4A Date: Thu, 12 Mar 2020 15:57:02 +0000 Message-ID: <0460943d5eedd3b31b68659d2942adeff42f906f.camel@workonline.africa> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa; x-originating-ip: [41.13.220.201] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 287c54bf-a44e-4b7d-eedd-08d7c69e0197 x-ms-traffictypediagnostic: AM7P190MB0613: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0340850FCD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39840400004)(376002)(136003)(346002)(396003)(199004)(91956017)(66446008)(64756008)(76116006)(8676002)(66946007)(66476007)(4326008)(71200400001)(2616005)(66556008)(26005)(8936002)(186003)(316002)(62860400002)(2906002)(81156014)(81166006)(508600001)(55236004)(6506007)(6916009)(53546011)(6486002)(5660300002)(6512007)(86362001)(46492006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P190MB0613; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZkD5JH3ZA9zyYcXX3xnwvYMd7gpZ3y3tbJt2oUBxHddX6TioYvP0tzfcGi+BvomgRFGnNkg5e0h/GfEkuJC2kzWQkkNBlxy2r8WnDXVHwuo7EPk46zymxzYv6Y6GGS1K+tfsgZjQpXwEtzLPoIEEmn3tfJIhw/7S3juu1A5pm5mseDPJNYTBwM1UK95xF/lndtEILiLyju/QaXeevAe4YQSevhcLIjy9OlUoHST1A5SgcAWn5SRDtF8tieVvAZp9Cppxawo//4FafNfcC9u44L8mJbBE1wzGFcB0ZQeHKE2kktua93WdoLq8eo+evrBLBMSYis0ZPRMl6skfSnG56BQmmfFqP5g6rcgluQIUmlmGmOcbolO1xjhR8rQYkX4j6XI6detU4DxcYfo06sNMwr/FcROdVGTtf++xZwV49dNP7X/qWRALa1D8gI6UZHTBQ0a+OBe4A47+NTs1gRGIcHXo967vLy3Ygix5wVqWHNCOzVx4B9BCfkEn+SPnB3Hj6FI8wY9Sljj21tQL4SED0DeSmSEPtmZeK32CUyR/31ldW5nAh3Ly1vmNXPQ1gslE x-ms-exchange-antispam-messagedata: u+yt393ZpeOvdRahJXEVA/T+J+qZVhLWyTNeNOHqTXNoMi8oeIpX6NGHb/gkQ6LSROavlWKZxwEdL/1xdpIMSjv7aPKfOUqqexLpf+p1FUO4IC6MMj37gH7PRPj4T5TCqgrC/P9JF537o2AQFFFDRg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <49E923CF25AE3B498955A17B95BDE968@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 287c54bf-a44e-4b7d-eedd-08d7c69e0197 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 15:57:02.9055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kU9abVseqftGaKh3X1yAP8TrFnbzkXEvGAkk4yKNU1H8x0wzWVEbEWusbNFE9mKjMMG39JgVQRuAvLAKaONp9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0613 Archived-At: Subject: Re: [Sidrops] ROV with ATOMIC_AGGREGATE 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, 12 Mar 2020 15:57:10 -0000 SGkgSmVmZiwNCg0KT24gVGh1LCAyMDIwLTAzLTEyIGF0IDEwOjU2IC0wNDAwLCBKZWZmcmV5IEhh YXMgd3JvdGU6DQo+IEJlbiwNCj4gDQo+IA0KPiA+IE9uIE1hciAxMiwgMjAyMCwgYXQgODo1NCBB TSwgQmVuIE1hZGRpc29uIDwNCj4gPiBiZW5tPTQwd29ya29ubGluZS5hZnJpY2FAZG1hcmMuaWV0 Zi5vcmc+IHdyb3RlOg0KPiA+IA0KPiA+IFRoYW5rcyBKZWZmLA0KPiA+IA0KPiA+IFlvdSBjYW4g YmUga2luZGEgaGFyZCB0byBwYXJzZSBzb21ldGltZXMhDQo+IA0KPiBTb3JyeSwgdGhpcyB3YXMg cHJlLWNvZmZlZS4NCj4gDQo6LSkNCg0KPiA+IA0KPiA+IE9uIFRodSwgMjAyMC0wMy0xMiBhdCAw NzowNyAtMDQwMCwgSmVmZnJleSBIYWFzIHdyb3RlOg0KPiA+ID4gDQo+ID4gPiBJZiB0aGUgb3Jp Z2luIEFTLCBzYW5zIHNldHMsIGlzIGNvcnJlY3QgLSB0aGUgaW1wbGVtZW50YXRpb24NCj4gPiA+ IHNob3VsZA0KPiA+ID4gYmVsaWV2ZSBpdC4NCj4gPiA+IA0KPiA+IA0KPiA+IFlvdSdyZSBzYXlp bmcgdGhhdDoNCj4gPiANCj4gPiBgYGANCj4gPiAgIG8gIFJvdXRlIE9yaWdpbiBBU046IFRoZSBv cmlnaW4gQVMgbnVtYmVyIGRlcml2ZWQgZnJvbSBhIFJvdXRlIGFzDQo+ID4gICAgICBmb2xsb3dz Og0KPiA+IA0KPiA+ICAgICAgKiAgdGhlIHJpZ2h0bW9zdCBBUyBpbiB0aGUgZmluYWwgc2VnbWVu dCBvZiB0aGUgQVNfUEFUSA0KPiA+IGF0dHJpYnV0ZQ0KPiA+ICAgICAgICAgaW4gdGhlIFJvdXRl IGlmIHRoYXQgc2VnbWVudCBpcyBvZiB0eXBlIEFTX1NFUVVFTkNFLCBvcg0KPiA+IA0KPiA+ICAg ICAgKiAgdGhlIEJHUCBzcGVha2VyJ3Mgb3duIEFTIG51bWJlciBpZiB0aGF0IHNlZ21lbnQgaXMg b2YgdHlwZQ0KPiA+ICAgICAgICAgQVNfQ09ORkVEX1NFUVVFTkNFIG9yIEFTX0NPTkZFRF9TRVQg b3IgaWYgdGhlIEFTX1BBVEggaXMNCj4gPiBlbXB0eSwNCj4gPiAgICAgICAgIG9yDQo+ID4gDQo+ ID4gICAgICAqICB0aGUgZGlzdGluZ3Vpc2hlZCB2YWx1ZSAiTk9ORSIgaWYgdGhlIGZpbmFsIHNl Z21lbnQgb2YgdGhlDQo+ID4gICAgICAgICBBU19QQVRIIGF0dHJpYnV0ZSBpcyBvZiBhbnkgb3Ro ZXIgdHlwZS4NCj4gPiBgYGANCj4gPiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4 MTEjc2VjdGlvbi0yKQ0KPiA+IA0KPiA+IEFwcGxpZXMsIGFzIGlzLCBpcnJlc3BlY3RpdmUgb2Yg dGhlIHBvc3NpYmxlIHByZXNlbmNlIG9mDQo+ID4gQVRPTUlDX0FHR1JFR0FURSwgcmlnaHQ/DQo+ IA0KPiBFeGFjdGx5Lg0KPiANClRoYW5rcyENCg0KPiBBVE9NSUNfQUdHUkVHQVRFIHRoZXNlIGRh eXNbMV0gbWVhbnMgdGhhdCBhZ2dyZWdhdGlvbiBoYXMgYmVlbiBkb25lDQo+IGF0IHNvbWUgcG9p bnQgaW4gdGhlIGxpZmUgb2YgdGhlIEJHUCBBU19QQVRIIGZvciB0aGUgTkxSSSBpbg0KPiBxdWVz dGlvbi4NCj4gDQo+IE9uY2UgaXQgaGFzIGJlZW4gYWRkZWQsIHN1YnNlcXVlbnQgYWdncmVnYXRp b24gY291bGQgaGF2ZSBiZWVuIGRvbmUsDQo+IGFuZCBtYXkgaGF2ZSBzZXQgZWxlbWVudHMgYWRk ZWQgdG8gaXQuICBJbiBzdWNoIGNhc2VzLCB0aGUgY3VycmVudA0KPiBkZXNpcmVkIGJlaGF2aW9y IGlzIHRoYXQgdGhlIHJvdXRlIGNhbm5vdCBiZSB1c2VkIGZvciBvcmlnaW4NCj4gdmFsaWRhdGlv biBwdXJwb3Nlcy4NCj4gDQo+IEhvd2V2ZXIsIHNpbWlsYXJseSwgc3Vic2VxdWVudCBhZ2dyZWdh dGlvbiBtYXkgYmUgZG9uZSBhbmQgZnVydGhlcg0KPiBpbmZvcm1hdGlvbiBsb3N0IGZyb20gdGhl IEFTX1BBVEg7IHdlIGRvbid0IGdldCBtb3JlIHRoYW4gb25lDQo+IEFUT01JQ19BR0dSRUdBVEUg bWFya2VyIGFuZCBpdCBoYXMgbm8gY291bnRlci4NCj4gDQo+IE15IGdlbmVyYWwgb2JzZXJ2YXRp b25zIG9uIGFnZ3JlZ2F0aW9uIHdpdGggcmVzcGVjdCB0byBvcmlnaW4NCj4gdmFsaWRhdGlvbiBo YXZlIGJlZW46DQo+IC0gUGFydGllcyB0aGF0IGhhdmUgdGhlICJyaWdodCIgdG8gYWdncmVnYXRl IChwcmVmaXggb3duZXJzaGlwLCBvcg0KPiBvd25lciBvZiBwcmVmaXggdGhhdCBtb3JlIHNwZWNp ZmljcyBoYXZlIGJlZW4gZGVsZWdhdGVkIGZyb20pIGNhbg0KPiBhZ2dyZWdhdGUgYW5kIGl0J2Qg c3RpbGwgbWF0Y2ggUlBLSSBwb2xpY2llcy4NCj4gLSBQcm94eSBhZ2dyZWdhdGlvbiBieSBvdGhl ciBwYXJ0aWVzIHdpbGwgZmFpbCBSUEtJIHBvbGljaWVzLg0KPiANCj4gVGhlIGZpcnN0IGNhc2Ug bWVhbnMgdGhhdCBBVE9NSUNfQUdHUkVHQVRFICgiYnJpZWYiKSBzdHlsZQ0KPiBhZ2dyZWdhdGlv biBpcyBmaW5lIGFuZCBmaXRzIHRoZSBpbnRlbnQgb2YgUlBLSSBvcmlnaW4NCj4gdmFsaWRhdGlv bi4gIFRoZSBzZWNvbmQgY2FzZSBkb2Vzbid0IGZpdCB0aGUgaW50ZW50IGFuZCB3aWxsIGZhaWwN Cj4gcmVnYXJkbGVzcyBmbyB3aGV0aGVyIHRoZXJlJ3MgYSBzZXQgb3Igbm90Lg0KPiANCj4gSXQn cyB0aGlzIHNldCBvZiBwcm9wZXJ0aWVzIHRoYXQgaGFzIG1lIGJlaW5nIGFuIG9iamVjdGluZyBw YXJ0eSB0bw0KPiB0aGUgbW92ZW1lbnQgdG8gY29tcGxldGVseSBraWxsIHNldCBiZWhhdmlvcnMg aW4gQkdQIGFzLXBhdGhzLiAgaXQNCj4gaGFzIG1vcmUgdGhhbiB0aGUgdXN1YWwgaW5jcmVtZW50 YWwgZGVwbG95bWVudCBpc3N1ZXMgdG8gYmUNCj4gY29uZm9ybWFudCB3aXRoIGFjdHVhbCAiZGVw cmVjYXRpb24iIGFuZCBkb2Vzbid0IGhlbHAgd2l0aCB0aGUNCj4gZGVzaXJlZCBpbnRlbnQuICBJ J20gcXVpdGUgaGFwcHkgdG8gc2F5ICJkb24ndCBkbyB0aGF0IiBhbmQgbGV0IFJQS0kNCj4gc2xv d2x5IGV4dGluZ3Vpc2ggdGhlIGZlYXR1cmUncyB1c2UuDQo+IA0KSSdtIGluIGFncmVlbWVudCB3 aXRoIGFsbCBvZiB0aGlzLCBleGNlcHQgdGhhdCBJJ20gbm90IHN1cmUgdGhhdCBJIHNlZQ0KaG93 IHRoZSBhcmd1bWVudCBhZ2FpbnN0IGRlcHJlY2F0aW9uIGZvbGxvd3MuDQpTdXJlbHkgdGhlICJU cmVhdC1hcy13aXRoZHJhdyIgaGFuZGxpbmcgaXMganVzdCBhIHN0cm9uZ2VyICJkb24ndCBkbw0K dGhhdCIgc2lnbmFsLiBJbiBmYWN0LCBpbiBhbiBpbWFnaW5hcnkgc3RyaWN0LVJPVi1ldmVyeXdo ZXJlLXdvcmxkLA0KdGhleSBjb21lIGRvd24gdG8gdGhlIHNhbWUgdGhpbmcuIEV4Y2VwdCB0cmVh dC1hcy13aXRoZHJhdyBpcyBwcm9iYWJseQ0KZWFzaWVyIHRvIHRyb3VibGVzaG9vdC4NCg0KPiA+ IA0KPiA+IENoZWVycywNCj4gPiANCj4gPiBCZW4NCj4gPiANCj4gPiA+IElmIHlvdSB3YW50IHBh dGggdmFsaWRhdGlvbiwgd2UgbmVlZCBiZ3BzZWMuDQo+ID4gPiANCj4gPiANCj4gPiBEZXBlbmRp bmcgb24gd2hhdCB5b3Ugd2FudCB0byB2YWxpZGF0ZSBpdCAqYWdhaW5zdCosIHlvdSBtYXkgbmVl ZA0KPiA+IEFTUEEuDQo+ID4gQnV0IHRoYXQncyBhIGRpZmZlcmVudCBjb252ZXJzYXRpb24uDQo+ IA0KPiBJbmRlZWQuICBSZWxldmFudCB0byB0aGlzIHBhcnRpY3VsYXIgY29udmVyc2F0aW9uLCBp ZiB5b3UncmUNCj4gY29uY2VybmVkIGFib3V0IHRydW5jYXRlZCBwYXRocywgd2hpY2ggaXMgd2hh dCBBVE9NSUNfQUdHUkVHQVRFIGlzDQo+IGludGVuZGVkIHRvIGhlbHAgc2lnbmFsLCB5b3UgbWF5 IGNhcmUgdGhhdCB0aGUgcm91dGUncyBvcmlnaW4gQVMgd2FzDQo+IGFjdHVhbGx5IG9yaWdpbmF0 ZWQgYnkgdGhhdCBBUy4NCj4gDQpJJ20gbW9zdGx5IGludGVyZXN0ZWQgaW4gdGhlIH4xMmsgZmFs c2UtSW52YWxpZHMgdGhhdCBJJ20gY3VycmVudGx5DQpzZWVpbmcgb24gdGhlIGltcGxlbWVudGF0 aW9uIHRoYXQgSSdtIHRlc3RpbmcgYW5kIG5lZWQgdG8gZGVwbG95IQ0KDQpJZiBhbnlvbmUgZWxz ZSB0aGlua3MgdGhhdCBJIHNob3VsZG4ndCB0ZWxsIG15IHZlbmRvciB0aGF0IHRoZXkndmUNCndy aXR0ZW4gYSBidWcsIHBsZWFzZSBzYXkgd2h5LCBzb29uPw0KDQpDaGVlcnMsDQoNCkJlbg0K From nobody Thu Mar 12 09:10:48 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 C2A3B3A0D33 for ; Thu, 12 Mar 2020 09:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 pxXxvbNMrA3s for ; Thu, 12 Mar 2020 09:10:32 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 560B33A0D1A for ; Thu, 12 Mar 2020 09:10:32 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id CB7AA1E2D3; Thu, 12 Mar 2020 12:16:34 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AD14DB4B-7091-4F87-8C04-33F4D3D39186" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Jeffrey Haas In-Reply-To: <0460943d5eedd3b31b68659d2942adeff42f906f.camel@workonline.africa> Date: Thu, 12 Mar 2020 12:10:30 -0400 Cc: "sidrops@ietf.org" Message-Id: <123B852A-61B3-4618-B048-F2E03A52F719@pfrc.org> References: <0460943d5eedd3b31b68659d2942adeff42f906f.camel@workonline.africa> To: Ben Maddison X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Sidrops] ROV with ATOMIC_AGGREGATE 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, 12 Mar 2020 16:10:37 -0000 --Apple-Mail=_AD14DB4B-7091-4F87-8C04-33F4D3D39186 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ben, > On Mar 12, 2020, at 11:57 AM, Ben Maddison = wrote: > I'm in agreement with all of this, except that I'm not sure that I see > how the argument against deprecation follows. > Surely the "Treat-as-withdraw" handling is just a stronger "don't do > that" signal. In fact, in an imaginary strict-ROV-everywhere-world, > they come down to the same thing. Except treat-as-withdraw is probably > easier to troubleshoot. The original "deprecation" text involved trying to remove the code = points for sets and all of the implications that has. We've largely evolved past that in the current proposal. -- Jeff --Apple-Mail=_AD14DB4B-7091-4F87-8C04-33F4D3D39186 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ben,


On Mar = 12, 2020, at 11:57 AM, Ben Maddison <benm=3D40workonline.africa@dmarc.ietf.org> = wrote:
I'm in agreement with all of this, except that I'm not sure = that I see
how the = argument against deprecation follows.
Surely the "Treat-as-withdraw" handling is just a stronger = "don't do
that" signal. = In fact, in an imaginary strict-ROV-everywhere-world,
they come down to the same = thing. Except treat-as-withdraw is probably
easier to = troubleshoot.

The = original "deprecation" text involved trying to remove the code points = for sets and all of the implications that has.

We've largely evolved past that in the current = proposal.

-- Jeff


= --Apple-Mail=_AD14DB4B-7091-4F87-8C04-33F4D3D39186-- From nobody Fri Mar 13 08:16:32 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 D16EB3A0A96; Fri, 13 Mar 2020 08:16:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158411258778.3418.757369789772046254@ietfa.amsl.com> Reply-To: Robert Sparks Date: Fri, 13 Mar 2020 08:16:27 -0700 Archived-At: Subject: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Fri, 13 Mar 2020 15:16:28 -0000 Reviewer: Robert Sparks Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sidrops-ov-egress-01 Reviewer: Robert Sparks Review Date: 2020-03-13 IETF LC End Date: 2020-03-18 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as a Proposed Standard RFC Very minor nit - feel free to ignore - This sentence slowed me down when reading: As the origin AS may be modified by outbound policy, policy semantics based on RPKI Origin Validation state MUST be able to be applied separately on distribution into BGP and on egress. I suggest something like: As the origin AS may be modified by outbound policy, a BGP speaker MUST be able to apply policy semantics based on RPKI Origin Validation state separately on distribution into BGP and on egress. From nobody Tue Mar 17 14:53: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 BAA503A0856; Tue, 17 Mar 2020 14:53:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: sidrops@ietf.org, last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158448201565.32201.9748655174984394118@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Tue, 17 Mar 2020 14:53:35 -0700 Archived-At: Subject: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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, 17 Mar 2020 21:53:37 -0000 Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Ops area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document claims that it highlights an important use case of origin validation in eBGP egress policies, explaining specifics of correct implementation in this context. But I don't see where the "Use Case" is described. It seems to me that the document should have more sections to describe the Use Case and the procedure of Egress Export of the RPKI validated Origins. Section 3 Egress Processing only has one sentence stating that "When applied to egress policy, validation state MUST be determined using the effective origin AS of the route as it will (or would) be announced to the peer." What other choices there are ? Are there any routers that support RFC 6480 RPKI not performing this step? how? My two cents. Linda Dunbar From nobody Tue Mar 17 17:11:56 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 65F1A3A0BAC; Tue, 17 Mar 2020 17:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 SV9fGz9WdDkh; Tue, 17 Mar 2020 17:11:52 -0700 (PDT) Received: from relay.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D670A3A0C3C; Tue, 17 Mar 2020 17:11:48 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 48D013C1ED8; Wed, 18 Mar 2020 00:11:47 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 1D3613BB; Wed, 18 Mar 2020 00:11:47 +0000 (UTC) Date: Wed, 18 Mar 2020 00:11:46 +0000 Message-ID: <87d09av7wd.wl-morrowc@ops-netman.net> From: Chris Morrow To: Linda Dunbar Cc: , sidrops@ietf.org, last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org In-Reply-To: <158448201565.32201.9748655174984394118@ietfa.amsl.com> References: <158448201565.32201.9748655174984394118@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 00:11:54 -0000 Just sniping a reply... which may be out to left (or right!) field :) On Tue, 17 Mar 2020 21:53:35 +0000, Linda Dunbar via Datatracker wrote: > > Reviewer: Linda Dunbar > Review result: Not Ready > > I have reviewed this document as part of the Ops area directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the Ops area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > The document claims that it highlights an important use case of origin > validation in eBGP egress policies, explaining specifics of correct > implementation in this context. But I don't see where the "Use Case" is > described. It seems to me that the document should have more sections to > describe the Use Case and the procedure of Egress Export of the RPKI validated > Origins. > > Section 3 Egress Processing only has one sentence stating that > "When applied to egress policy, validation state MUST be determined using the > effective origin AS of the route as it will (or would) be announced to the > peer." What other choices there are ? Are there any routers that support RFC > 6480 RPKI not performing this step? how? > I think the sense of this sentence is really: "Your router may have configured ASXXX and present itself (confedaration) as ASYYY to peer1 and ASBBB to peer2 (merger/acquisition issues). Please make sure that you validate the origin accordingly" There are a few example networks in the real world where this sort of thing could be super relevant. Particularly look at recent 'network that merges a bunch' Level3/CenturyLink/Savvis/GlobalCrossing/etc... AS3356/AS209/AS/AS3459/AS3549. A single edge device terminating customers on the 3356 backbone may plausibly have customers that haven't swapped over to 3356 and are actually expecting the remote peer to be any of 6 or more ASN. It's important that the 'i originated this prefix, I'm 3356, wait 3549, want 3459...' decision is backed up in ROA content as well as validation logic. Looking at the abstract to maybe dig a little deeper: "For egress policy, it is important that the classification uses the effective origin AS of the processed route, which may specifically be altered by the commonly available knobs such as removing private ASs, confederation handling, and other modifications of the origin AS." So somewhere deep in my network, bb01.pop01 has: 192.0.2.0/24 staticly routed, redistributed in BGP and marked for external announcement (community/etc). That route, internally has an origin-AS of: 65507 because that's one of the several private ASN that make up my confederation: ASBAR. So, when I announce: 192.0.2.0/24 - origin 65507 I need to both swap the origin in the bgp announcement and validate against the local-as the peer sees me as. 192.0.2/0/24 - origin 3356 192.0.2.0/24 - origin 3549 ...etc... This will require me to make ROA for all of these origins, as well. I think anyway that's the goal of the document, really. though, also, I could have missed the forest for the trees here. -chris > My two cents. > > Linda Dunbar > > From nobody Tue Mar 17 17:44:44 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 CDCFF3A0CE7; Tue, 17 Mar 2020 17:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vtPEvtt6bo6M; Tue, 17 Mar 2020 17:44:40 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0B43A0CE4; Tue, 17 Mar 2020 17:44:39 -0700 (PDT) X-Envelope-To: ops-dir@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 02I0iV2T070529 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Mar 2020 00:44:32 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Linda Dunbar Cc: ops-dir@ietf.org, last-call@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org References: <158448201565.32201.9748655174984394118@ietfa.amsl.com> From: Nick Hilliard Message-ID: <624bd5c7-5459-64c2-5694-b77dde5835a6@foobar.org> Date: Wed, 18 Mar 2020 00:44:29 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.12 MIME-Version: 1.0 In-Reply-To: <158448201565.32201.9748655174984394118@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 00:44:43 -0000 Linda Dunbar via Datatracker wrote on 17/03/2020 21:53: > Section 3 Egress Processing only has one sentence stating that > "When applied to egress policy, validation state MUST be determined using the > effective origin AS of the route as it will (or would) be announced to the > peer." What other choices there are ? Are there any routers that support RFC > 6480 RPKI not performing this step? how? jumping the gun on the authors here, there's a mismatch between what coders implemented and what operators figured would be workable in terms of how policy semantics need to be handled on production routers. This is a fancy way of saying that some router vendors ticked the ROV tickbox, but the way they did it was too limited for real life. RPKI provides a policy management mechanism. The ID says that this needs to be hooked into the three major policy application points which are implemented in most, if not all, bgp rib engines. These points are: 1. bgp ingress, i.e. at the point between the adj-rib-in and loc-rib 2. on redistribution to other routing protocols 3. bgp egress, i.e. at the point between the loc-rib and adj-rib-out This didn't happen for ROV on all vendor stacks. It's kinda obvious to operators that it should have been. Also, it's not the first time that this sort of feature lapse has happened in the history of routing management. There's been a bit of a history of this sort of thing happening over the years. Nick From nobody Tue Mar 17 18:16:24 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 B1B9B3A0D55; Tue, 17 Mar 2020 18:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 xvJ2SPO8tZ9Q; Tue, 17 Mar 2020 18:16:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 C6C613A0D58; Tue, 17 Mar 2020 18:16:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jENJT-00070l-Bh; Wed, 18 Mar 2020 01:16:03 +0000 Date: Tue, 17 Mar 2020 18:16:02 -0700 Message-ID: From: Randy Bush To: Linda Dunbar via Datatracker Cc: , sidrops@ietf.org, last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org In-Reply-To: <158448201565.32201.9748655174984394118@ietfa.amsl.com> References: <158448201565.32201.9748655174984394118@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 01:16:11 -0000 linda, thanks for the review > Section 3 Egress Processing only has one sentence stating that ... the lack of more words was not an accident; a feature not a bug. :) > "When applied to egress policy, validation state MUST be determined > using the effective origin AS of the route as it will (or would) be > announced to the peer." What other choices there are ? Are there any > routers that support RFC 6480 RPKI not performing this step? how? unfortunately yes. see nick's and chris's emails. first, too many implementations do not even apply rov policy on locally originated routes, routes from ibgp, etc. second, for rov processing, many, maybe most, implementations use the 'global' AS of the router (as if there was one giving multi-AS knobs). chris's email kinda explains that last one pretty clearly. the purpose of this draft is to explain that the problem exists and to make the minimal statement of what implementations should do. i believe the text (i need to read robert's email three more times) is well understood by rov implementors, and even serious bgp/rov ops. randy From nobody Tue Mar 17 18:26:53 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 2D0653A0DC7 for ; Tue, 17 Mar 2020 18:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no 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 Jp5mf_bkLylq for ; Tue, 17 Mar 2020 18:26:40 -0700 (PDT) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 E970E3A0DC5 for ; Tue, 17 Mar 2020 18:26:39 -0700 (PDT) Received: by mail-wr1-f46.google.com with SMTP id h6so7893518wrs.6 for ; Tue, 17 Mar 2020 18:26:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=K5TqNyHfuQ3UO8dsk8IHy6u4F1B7kP95jluKX0UQL4M=; b=HmLb2WUnoYnjKtzQQYFDRyn9yxkmevQ+9tcJtsPp5TD1seKmlCnSgWThtNhv2g1uNe CFosVZW/reHaLC+n9P6OkZJXcaaILAtQoqSQnyGV/TVWf9xH5D6T2JKCbiTZ6mkxeXuD gUdvD6KUho63yEeS0HtCe0r7LZQNzv8VQ0/QSqHjAHF2ivTc8mTIG4172F6TrcTTl4M0 i4QXNja0GuM3PhXldjGRnCfFlCPCkD32e0m5CiLm8YpymnLw8LS5yYie8jvp3Xg+NHa2 WxTqXrg9AuAP8w5DcvpaGEA0WWt1tKLqmFkVZlrcMF8tiQWDeCEH0EyGEPgiDJHhZQiO ExVQ== X-Gm-Message-State: ANhLgQ1Va60QjuHdP/1Lydk8i5IuDHkLMVMMbqGgdb5Y+eI6MUm2n/J7 7NujDOHb4Sw2sJ5aygVc4opjmsciyWc= X-Google-Smtp-Source: ADFU+vsmjFtukD94cb2TpRG43rAxz5RiLhH72ChJDj1BEzKM6XlTokhzphaZC6EeZk6ZAPYqSAnfIg== X-Received: by 2002:adf:aa92:: with SMTP id h18mr2013766wrc.139.1584494797413; Tue, 17 Mar 2020 18:26:37 -0700 (PDT) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id w19sm1572822wmi.0.2020.03.17.18.26.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 18:26:36 -0700 (PDT) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 7fc24496; Wed, 18 Mar 2020 01:26:35 +0000 (UTC) Date: Wed, 18 Mar 2020 01:26:35 +0000 From: Job Snijders To: Nick Hilliard Cc: Linda Dunbar , last-call@ietf.org, ops-dir@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org Message-ID: <20200318012635.GE77479@vurt.meerval.net> References: <158448201565.32201.9748655174984394118@ietfa.amsl.com> <624bd5c7-5459-64c2-5694-b77dde5835a6@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <624bd5c7-5459-64c2-5694-b77dde5835a6@foobar.org> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 01:26:42 -0000 On Wed, Mar 18, 2020 at 12:44:29AM +0000, Nick Hilliard wrote: > Linda Dunbar via Datatracker wrote on 17/03/2020 21:53: > > Section 3 Egress Processing only has one sentence stating that "When > > applied to egress policy, validation state MUST be determined using > > the effective origin AS of the route as it will (or would) be > > announced to the peer." What other choices there are ? Are there > > any routers that support RFC 6480 RPKI not performing this step? > > how? > > jumping the gun on the authors here, there's a mismatch between what > coders implemented and what operators figured would be workable in > terms of how policy semantics need to be handled on production > routers. > > This is a fancy way of saying that some router vendors ticked the ROV > tickbox, but the way they did it was too limited for real life. > > RPKI provides a policy management mechanism. The ID says that this > needs to be hooked into the three major policy application points > which are implemented in most, if not all, bgp rib engines. These > points are: > > 1. bgp ingress, i.e. at the point between the adj-rib-in and loc-rib > 2. on redistribution to other routing protocols 3. bgp egress, i.e. at > the point between the loc-rib and adj-rib-out > > This didn't happen for ROV on all vendor stacks. Perhaps: OLD: It might be affected by removal of private AS(s), confederation, AS migration, etc. If there are any AS_PATH modifications resulting in origin AS change, then these MUST be taken into account. NEW: BGP implementations have to take removal of private AS(s), confederation, AS migration, etc into consideration. If there are any AS_PATH modifications resulting in an Origin AS change, then these MUST be taken into account and only the final Origin AS is to be used as input into the Origin Validation procedure. Kind regards, Job From nobody Tue Mar 17 18:34:08 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 3B9E73A0DDF; Tue, 17 Mar 2020 18:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 9IqeIH2oBjYt; Tue, 17 Mar 2020 18:34:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 8916F3A0DDB; Tue, 17 Mar 2020 18:34:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jENas-00074M-8n; Wed, 18 Mar 2020 01:34:02 +0000 Date: Tue, 17 Mar 2020 18:34:01 -0700 Message-ID: From: Randy Bush To: Robert Sparks Cc: , last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org, sidrops@ietf.org In-Reply-To: <158411258778.3418.757369789772046254@ietfa.amsl.com> References: <158411258778.3418.757369789772046254@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 01:34:06 -0000 thanks for review robert, > This sentence slowed me down when reading: > > As the origin AS may be modified by outbound policy, policy semantics > based on RPKI Origin Validation state MUST be able to be applied > separately on distribution into BGP and on egress. > > I suggest something like: > > As the origin AS may be modified by outbound policy, a BGP speaker > MUST be able to apply policy semantics based on RPKI Origin Validation > state separately on distribution into BGP and on egress. am i correct that you point is to make clear that this applies to the BGP speaker? i need to think. clearly, the speaker will be applying the policy. but is it not the op configuring the policy which is deciding? or is it that you really want to MUST the application, a la As the origin AS may be modified by outbound policy, a BGP speaker MUST apply ROV policy semantics using the My Autonomous System number in the BGP OPEN message (see RFC 4271 section 4.2) issued to the peer to which the UPDATE is being sent. randy From nobody Tue Mar 17 18:37:00 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 6949C3A0DF7; Tue, 17 Mar 2020 18:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 d9_j0DRs2Fwr; Tue, 17 Mar 2020 18:36:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 24F583A0DFE; Tue, 17 Mar 2020 18:36:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jENdA-00074r-KC; Wed, 18 Mar 2020 01:36:24 +0000 Date: Tue, 17 Mar 2020 18:36:23 -0700 Message-ID: From: Randy Bush To: Job Snijders Cc: Nick Hilliard , Linda Dunbar , last-call@ietf.org, ops-dir@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org In-Reply-To: <20200318012635.GE77479@vurt.meerval.net> References: <158448201565.32201.9748655174984394118@ietfa.amsl.com> <624bd5c7-5459-64c2-5694-b77dde5835a6@foobar.org> <20200318012635.GE77479@vurt.meerval.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 01:36:54 -0000 > BGP implementations have to take removal of private AS(s), > confederation, AS migration, etc into consideration. and the winds of summer. we do not need to enumerate all knobs, as if we could. randy From nobody Tue Mar 17 20:27:18 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 2B9673A0FA4; Tue, 17 Mar 2020 20:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 RssGFY5t0aQ7; Tue, 17 Mar 2020 20:26:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 C13713A0FA6; Tue, 17 Mar 2020 20:26:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jEPLs-0007RK-Br; Wed, 18 Mar 2020 03:26:40 +0000 Date: Tue, 17 Mar 2020 20:26:36 -0700 Message-ID: From: Randy Bush To: Robert Sparks Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org, sidrops@ietf.org In-Reply-To: <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 03:27:07 -0000 > I wanted to avoid "be able to be" and have an explicit actor. I see > the difficulty you point to below. i am happy to change to the following >> As the origin AS may be modified by outbound policy, a BGP speaker >> MUST apply ROV policy semantics using the My Autonomous System number >> in the BGP OPEN message (see RFC 4271 section 4.2) issued to the peer >> to which the UPDATE is being sent. but, in my free opinion, as it is in IETF LC, the change is enough that it might require approval by chairs and/or AD. randy From nobody Tue Mar 17 20:54:02 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 723843A0F8C; Tue, 17 Mar 2020 20:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.274, T_SPF_HELO_PERMERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 8BHGsRLM_ve8; Tue, 17 Mar 2020 20:18:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8793A3A0F8E; Tue, 17 Mar 2020 20:18:45 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 02I3Ihlc005883 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 17 Mar 2020 22:18:44 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1584501524; bh=8vabLPbKYmmkS+B3RLKswqg9tGypK/Iag5gWwJuf48U=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ov/ypeW5zxG70QvIadIPNf81apXadyU/v4qqqXNuCVAofH+BEZnQUB36GoQNjJQmV CK7An25cai+Osawh/PMnjoFXaeWhv80BKv3w45hbEr8+igUhBNcL+GP5fMWj9PPVKz +YQM2Ay0fnsSh+wmVDHuOuiM6bCwcaDIJdMwPu6s= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Randy Bush Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org, sidrops@ietf.org References: <158411258778.3418.757369789772046254@ietfa.amsl.com> From: Robert Sparks Message-ID: <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> Date: Tue, 17 Mar 2020 22:18:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 17 Mar 2020 20:54:01 -0700 Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 03:18:54 -0000 On 3/17/20 8:34 PM, Randy Bush wrote: > thanks for review robert, > >> This sentence slowed me down when reading: >> >> As the origin AS may be modified by outbound policy, policy semantics >> based on RPKI Origin Validation state MUST be able to be applied >> separately on distribution into BGP and on egress. >> >> I suggest something like: >> >> As the origin AS may be modified by outbound policy, a BGP speaker >> MUST be able to apply policy semantics based on RPKI Origin Validation >> state separately on distribution into BGP and on egress. > am i correct that you point is to make clear that this applies to the BGP > speaker? Yes, mostly that. I wanted to avoid "be able to be" and have an explicit actor. I see the difficulty you point to below. > > i need to think. clearly, the speaker will be applying the policy. but > is it not the op configuring the policy which is deciding? or is it > that you really want to MUST the application, a la > > As the origin AS may be modified by outbound policy, a BGP speaker > MUST apply ROV policy semantics using the My Autonomous System > number in the BGP OPEN message (see RFC 4271 section 4.2) issued to > the peer to which the UPDATE is being sent. > > randy From nobody Tue Mar 17 20:54:06 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 E25473A0FB8; Tue, 17 Mar 2020 20:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.274, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 VqWv2JT9fiYo; Tue, 17 Mar 2020 20:37:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A26F43A0FAB; Tue, 17 Mar 2020 20:37:34 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 02I3bWxO009159 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 17 Mar 2020 22:37:33 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1584502654; bh=W68B+ZftaN/VXATgHsuyRKDB7bJVE6/6cNb7v60DODk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=eChwRzDuirgmFs0Rf63DK6ZVcloXLIb+j1zTsKRGXNhTihkx7NDHbUOLRTUZ8hl46 OGVjKUcCbk2copzO86VIRaLHHIu26vRl9e1OgAepCcpW7DHVNYk0SSmQLWDDu5EMS1 44x1YTq4kEr6CvgQoLZmeR7lyzM1oCfJQ9wYN2e0= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Randy Bush Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org, sidrops@ietf.org References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> From: Robert Sparks Message-ID: <0a489ae6-73cf-f0fd-5ab5-fec1984975aa@nostrum.com> Date: Tue, 17 Mar 2020 22:37:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 17 Mar 2020 20:54:01 -0700 Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 03:37:37 -0000 I like that and hope it's acceptable to the community. But it was a very small nit - if it turns out to be problematic, I'm ok leaving things as they were. RjS On 3/17/20 10:26 PM, Randy Bush wrote: >> I wanted to avoid "be able to be" and have an explicit actor. I see >> the difficulty you point to below. > i am happy to change to the following > >>> As the origin AS may be modified by outbound policy, a BGP speaker >>> MUST apply ROV policy semantics using the My Autonomous System number >>> in the BGP OPEN message (see RFC 4271 section 4.2) issued to the peer >>> to which the UPDATE is being sent. > but, in my free opinion, as it is in IETF LC, the change is enough that > it might require approval by chairs and/or AD. > > randy From nobody Tue Mar 17 20:56:17 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 729203A0FF7; Tue, 17 Mar 2020 20:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 zO7wF4mCbJjo; Tue, 17 Mar 2020 20:56:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 0D4D43A0FF2; Tue, 17 Mar 2020 20:55:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jEPoA-0007Vj-OC; Wed, 18 Mar 2020 03:55:54 +0000 Date: Tue, 17 Mar 2020 20:55:54 -0700 Message-ID: From: Randy Bush To: Robert Sparks Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org, sidrops@ietf.org In-Reply-To: <0a489ae6-73cf-f0fd-5ab5-fec1984975aa@nostrum.com> References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> <0a489ae6-73cf-f0fd-5ab5-fec1984975aa@nostrum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 03:56:08 -0000 > I like that and hope it's acceptable to the community. > > But it was a very small nit - if it turns out to be problematic, I'm > ok leaving things as they were. our illustrious AD is fond of specific references to RFCs and other formal wording. :) randy From nobody Tue Mar 17 22:10:09 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 B30A33A106C; Tue, 17 Mar 2020 21:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 S--dmjS2IWVo; Tue, 17 Mar 2020 21:28:18 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2131.outbound.protection.outlook.com [40.107.220.131]) (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 981D13A1066; Tue, 17 Mar 2020 21:28:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FdpJvgx8/kKLZLNhInPHeURfc9QB2MdR3xE4vRVOcTBJ/xYyXiH/aFnxqZ9+f1NIDyp7mEW0GM1K1U47UyMBiNL/gbHTpsfpgg9HMMUFsQYrEIHoQHr4pishNWjqBuv7BpwqtPKIbLHVHGaU1EdnvxbEQUu4dpecjTbVmvJB6FqfufUi4OCqEOuR+LqLIn1KxQ+dm8RsZrpKNLI83EyHxBAmB85iSW47kQZg0OrH7N1wsaWIGw2jgbeNQzgDxBiyOi92hK5SpGs0Kgucpevz0YVwkkxAB5Jw5+WKpLGQxLFaNwcPuWQ2TO9MyQHBK8TJZ+9dORAZ4Wk0cJhc9dUDvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KynJSnZ48srVISmtqizHo73MvQEvk1zQD3ZVOWeqoxw=; b=GmwCWs/UaIkS9pcx8SiF2UL0eIL8YDWOHGHhhpraKos4nXnWjpReg9a0CukS6LimQ9x6scXYKuEh64xJOYIAcPJGaf5eU7RJvkHMdkMCsKESu1sHWcJBZcnSj3gUzjswd0mtQDzwbPZSWL3tuvz2tb7x05KXHOHQGdR/YnxtI6EY9lbZPb9OOQp8TFfVPky1vyVdDk6EzeOTcgFiv/X+fbl3lY9lUjsxJ1faQFKRH3HdfULP3Wlf5zvsp7nRTuPYNJ/Yq16gxcrlyFBGAfoS5OoyxacTfXgSbMWMbmtoUtOz5eXSzKcCYxyEaHKIChonbgvxNhowpPI7oyI0SXqXKw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KynJSnZ48srVISmtqizHo73MvQEvk1zQD3ZVOWeqoxw=; b=ULgADkiAI9DMQv28ukZVPneTFSMsPa9vLp+7VyUph7xJVgbWJJ4cBZ+HifWtVq1BlVu0sYs3XubkXAzcM+fNmABvz3NTReZ9+SkODYmdbdV8MdH2cc+C/fTzNEmXtUobnpFY5Rvd7NxwvfAzA2UqFc3G5BQlNe2Hl8XjgBXtxIQ= Received: from MWHPR1301MB2096.namprd13.prod.outlook.com (2603:10b6:301:34::35) by MWHPR1301MB2206.namprd13.prod.outlook.com (2603:10b6:301:35::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.15; Wed, 18 Mar 2020 04:28:11 +0000 Received: from MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::e893:a912:1d3a:5a33]) by MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::e893:a912:1d3a:5a33%6]) with mapi id 15.20.2835.013; Wed, 18 Mar 2020 04:28:11 +0000 From: Linda Dunbar To: Chris Morrow CC: "ops-dir@ietf.org" , "sidrops@ietf.org" , "last-call@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-sidrops-ov-egress-01 Thread-Index: AQHV/LnTh9GYXgnyT0iT7Ib/ZTnNZKhNwJ8Q Date: Wed, 18 Mar 2020 04:28:11 +0000 Message-ID: References: <158448201565.32201.9748655174984394118@ietfa.amsl.com> <87d09av7wd.wl-morrowc@ops-netman.net> In-Reply-To: <87d09av7wd.wl-morrowc@ops-netman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=linda.dunbar@futurewei.com; x-originating-ip: [2605:6000:1526:d41e:b826:e203:150e:5d1e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 23f8966a-dcb2-413c-7ab6-08d7caf4c4a0 x-ms-traffictypediagnostic: MWHPR1301MB2206: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(366004)(346002)(39850400004)(396003)(136003)(199004)(9686003)(55016002)(71200400001)(6506007)(53546011)(66574012)(19627235002)(52536014)(5660300002)(8936002)(66556008)(81156014)(66446008)(81166006)(64756008)(8676002)(66476007)(76116006)(7696005)(66946007)(54906003)(86362001)(316002)(186003)(44832011)(478600001)(6916009)(4326008)(33656002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR1301MB2206; H:MWHPR1301MB2096.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yBbyPuJSUPr5JOAzztXU6UpOUtU0T312/1xcwKOcrTPWfC/zd5LRUZYFAvnHnxS4JDHzze72wm3Ckg/R10kjyAPKj8m/TWC/Sz5/cfIGuQH9AOWw7/utmW60/r/m/wo0F+AE4b9umNLv2bnuC96yvSgUHk1KIGqHT5/TqNYgP6z1TwEHpbHpav89Vju0r1Q89tSamuNXI2YconxzLWR2lRh/8swvfATjnrQ1VXd7QQH0yxs4TR5dCO9uCFmKmGYVboV1duE2hlpDIOUB1fUwsm1ezt2IaNbJ2LZ7swCus3wOrQliQr5Ymk6J2wccWPHgMwloTU3efs+ueOFuYP1t46YWi4Ju4NVr6ngv2RbgwFr8TLRMpJG/LmOkm8Q6e1iW+EU0UauID3Mzom49JR3wn33LS1hL28v1DOUhde4VG0K/1F0Oc1SuapCycw4LEMe5 x-ms-exchange-antispam-messagedata: eenwIzv7sj9lQ1mQkSu6GnNl1j9Uge577tENOlVW0JeCXJJ/xESBR1ZiyL4ugtTsZpZ8RKkNloGX75C4kHCIfdOaqJ4sN4Kdr2nEsr+GOaaGEi/RPBCwka0IRekbKYB+RHmI6zzFvppvrl5BxqMF7J4RWEidNaEFVI6WTKXWDWoTbnTJJj5dEB69+Q8G0MysqVID/voHhT9F5OibVbc8ZQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23f8966a-dcb2-413c-7ab6-08d7caf4c4a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2020 04:28:11.5377 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IAl9OYMJOuCpUniC6ZEFy/zIfIXt3fdZn1FInkBhij6TZXftGj/IGreP9V5XjLGxO6CE6S2t1pLSacU/ZAvtvw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1301MB2206 Archived-At: X-Mailman-Approved-At: Tue, 17 Mar 2020 22:10:08 -0700 Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 04:28:22 -0000 Chris,=20 Thank you very much for the explanation. Your explanation is what I was looking for.=20 It would be very nice to have your examples included (as Use Cases) in the = document.=20 Linda Dunbar -----Original Message----- From: Chris Morrow =20 Sent: Tuesday, March 17, 2020 7:12 PM To: Linda Dunbar Cc: ops-dir@ietf.org; sidrops@ietf.org; last-call@ietf.org; draft-ietf-sidr= ops-ov-egress.all@ietf.org Subject: Re: Opsdir last call review of draft-ietf-sidrops-ov-egress-01 Just sniping a reply... which may be out to left (or right!) field :) On Tue, 17 Mar 2020 21:53:35 +0000, Linda Dunbar via Datatracker wrote: >=20 > Reviewer: Linda Dunbar > Review result: Not Ready >=20 > I have reviewed this document as part of the Ops area directorate's=20 > ongoing effort to review all IETF documents being processed by the=20 > IESG. These comments were written primarily for the benefit of the Ops a= rea directors. > Document editors and WG chairs should treat these comments just like=20 > any other last call comments. >=20 > The document claims that it highlights an important use case of origin=20 > validation in eBGP egress policies, explaining specifics of correct=20 > implementation in this context. But I don't see where the "Use Case"=20 > is described. It seems to me that the document should have more=20 > sections to describe the Use Case and the procedure of Egress Export=20 > of the RPKI validated Origins. >=20 > Section 3 Egress Processing only has one sentence stating that "When=20 > applied to egress policy, validation state MUST be determined using=20 > the effective origin AS of the route as it will (or would) be announced t= o the > peer." What other choices there are ? Are there any routers that suppor= t RFC > 6480 RPKI not performing this step? how? > I think the sense of this sentence is really: "Your router may have configured ASXXX and present itself (confedaration) as ASYYY to peer1 and ASBBB to peer2 (merger/acquisition issues). Please make sure that you validate the origin accordingly" There are a few example networks in the real world where this sort of thing= could be super relevant. Particularly look at recent 'network that merges = a bunch' Level3/CenturyLink/Savvis/GlobalCrossing/etc... AS3356/AS209/AS/AS3459/AS3549. A single edge device terminating cu= stomers on the 3356 backbone may plausibly have customers that haven't swap= ped over to 3356 and are actually expecting the remote peer to be any of 6 = or more ASN. It's important that the 'i originated this prefix, I'm 3356, wait 3549, wan= t 3459...' decision is backed up in ROA content as well as validation logic= . Looking at the abstract to maybe dig a little deeper: "For egress policy, it is important that the classification uses the effective origin AS of the processed route, which may specifically be altered by the commonly available knobs such as removing private ASs, confederation handling, and other modifications of the origin AS." So somewhere deep in my network, bb01.pop01 has: 192.0.2.0/24 staticly routed, redistributed in BGP and marked for external announcement = (community/etc). That route, internally has an origin-AS of: 65507 because that's one of the several private ASN that make up my confederation: ASBAR. So, when I announce: 192.0.2.0/24 - origin 65507 I need to both swap the origin in the bgp announcement and validate against= the local-as the peer sees me as. 192.0.2/0/24 - origin 3356 192.0.2.0/24 - origin 3549 ...etc... This will require me to make ROA for all of these origins, as well. I think anyway that's the goal of the document, really. though, also, I could have missed the forest for the trees here. -chris > My two cents. >=20 > Linda Dunbar >=20 >=20 From nobody Wed Mar 18 11:05:53 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 8D8653A19A0; Wed, 18 Mar 2020 11:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 LEHYtFsr8qU0; Wed, 18 Mar 2020 11:05:32 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2082.outbound.protection.outlook.com [40.107.236.82]) (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 8ED7D3A19A3; Wed, 18 Mar 2020 11:05:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gs1OWTnoc8YMXDLSYW1jZgAtri9u9C0XbnDMN5krPlcqLkuwLCb+576bKBK0PRIgl/g54Lo6xIT0NhGqaXcHPiOhTO5pBnLtDa8WbdI10OsStLrZAnx4bIQ5+TemS4N9TsHdslulhO9k8E9EU/qTJhZTJr7zXi8MVRCr/NNeR51zn/xOnzeCo6g0yovfV3cTvngfV6sQjyQkE30hpVhlOcEEXqtnrqbXlwaBgSOWM7AlHOqvB/Oe2xfxC4vXPJTmuOrEWOMR/959u7aizDHfQDCZLBYstsZgAoYdwxZZRqQh2/I64h34L7QhIwRxEQefzAqoal0kiWGeig2JO4brJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+58V8zjp4v980Q2LNBQ5ckKnnByszUl0sCoKe4N1QP0=; b=Ql38ugH8C9w75cFeb4IE/NnPD2I21v7bUnzPVg6eiqOojJoE6NJN4Y1h2F/W2HHQ4tUpfBcID+KDp8J/w8uzXQExtpyPWKIXUkaqu2OlnuEyE6/9fdasA5yQ07yf721bwrtnXq5erOCAxjWrxS4OQDqQU91fy+/n5yfjlmg0L2w2ChDqDa2HRm7Axk3GngqMLNpb0NL1xlz2MXbctOPjlke6fX2pEVt0TrdrYA5SPUUSLt9TUIFttYKJMV0cZTJJD5mj4HJ9we1ideLlt1DzazEBPiDg8ssmrEwyiXnLIKgQI7Qwf3NlCOy4fr8GoEmykjQvTcoI8AG8cQvSwiF9AA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+58V8zjp4v980Q2LNBQ5ckKnnByszUl0sCoKe4N1QP0=; b=p2ENgsf/sPFq9FtoAp5CZ7tz9ucTWd9R/kF0/lwGdI5G3ouirRMDQ5HSHttz6a0GIAYtj9ZsMWXCBOqvXaSPPYhK25FXBJT/flecpSAAYPewvf5hJzKcJAgJfUq82VNzupxty2FOAfyzORE2FpmDvAL2QNCzlhN9t2YIXH0LQx4= Received: from BYAPR18MB2534.namprd18.prod.outlook.com (2603:10b6:a03:12e::29) by BYAPR18MB2935.namprd18.prod.outlook.com (2603:10b6:a03:10a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.18; Wed, 18 Mar 2020 18:05:28 +0000 Received: from BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::410:1331:ad08:f859]) by BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::410:1331:ad08:f859%7]) with mapi id 15.20.2814.021; Wed, 18 Mar 2020 18:05:28 +0000 From: Keyur Patel To: Randy Bush , Robert Sparks CC: "gen-art@ietf.org" , "last-call@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" , "sidrops@ietf.org" Thread-Topic: Genart last call review of draft-ietf-sidrops-ov-egress-01 Thread-Index: AQHV+Uph1zWgr+WNoEWHlzZmpUwEaqhNmAWAgAAdQYCAAAI0AIAAgDOA Date: Wed, 18 Mar 2020 18:05:28 +0000 Message-ID: <5A210359-FE01-40BF-9BAD-E0250BB31BFC@arrcus.com> References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [2601:646:8700:a6f0:559b:6b0a:731b:19d5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 02d64989-d6e5-4462-9591-08d7cb66f0e2 x-ms-traffictypediagnostic: BYAPR18MB2935: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(376002)(366004)(39830400003)(199004)(8676002)(81156014)(2616005)(316002)(8936002)(81166006)(6486002)(4744005)(186003)(54906003)(64756008)(66946007)(508600001)(66476007)(4326008)(36756003)(110136005)(86362001)(66446008)(66556008)(76116006)(6506007)(6512007)(2906002)(33656002)(71200400001)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2935; H:BYAPR18MB2534.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: V2lj6+i8X3L3yKTIv31x9btSCWp/Du1Z6EEzDz0junUF9jB7GliPaaDQpgxZKGNrns7rDxoAbv8NvvKyh5XqR79ml3T/f85arEKfGaACXDqfxJOkEdN/wZwn+Spb3NNmA4LocWrI8J1d8KVw1vemkzlLe/w5OdVHHfvG58KUI2u37jtwhN4DKHvnvrkYqzBjfhylkmedHH1PqvoZjz+N7tvPrOZrpvi4gkxzCVqwD/RIg2l2V08K5uEupRr1GOuMgeitCp9L2Mex2z/z0wshUoYvl9eGSYg5tlnFi6gbDQ3V3AYyzY+mpqY3BQa/n8otR1tGbCyClWvUb+6rL3e/E3Wzn4Yk7V1CGHcjUVTOoaQxmaNfGM/vDSHToq2pc2VwcVH4THbi2CI0RMnMF98RG7azCQhbI1yKg0ANzzxs5ARj7z0S7tpzDffR/dObOb5e x-ms-exchange-antispam-messagedata: rtPbdQcgsTKOtlo/cV3/y1N9navzCxQJ/JdSqgNKHvpXtGvtTvqjSVE3sf2nay+urdTN5mibP5iE7s3fXtN/4Nj+HHCFNZi3/4ih/nZN+b1FLub7noS/F1VsTppJbL4uTLneZCyVw9/nI4djtOoWTvJGfVcmJOXN95jJKboDGsTEkNYWacCMJjaYgxEgN57K5U+zpGjHgQHuTRp1Bxe7IA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 02d64989-d6e5-4462-9591-08d7cb66f0e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2020 18:05:28.2649 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IY4Qu7sLR7vb0mirKw4lEMZwutQK9JxoC1YgKl+dA8A03Nqu3pLX737GaFL4lVxSLiXHfqmfQ6ZHWp+KWiRxXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2935 Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 18:05:38 -0000 U3BlYWtpbmcgYXMgYSB3ZyBtZW1iZXIuDQoNClNob3VsZG7igJl0IHlvdSBiZSBjaGVja2luZyB0 aGUgIm15IGF1dG9ub21vdXMgc3lzdGVtIG51bWJlciIgaW4gdGhlIHVwZGF0ZSBtZXNzYWdlICh3 aGVuIHNlbmRpbmcgaXQgb3V0IHRvIHRoZSBlYmdwIHBlZXIpIGFzIG9wcG9zZWQgdG8gIm15IGF1 dG9ub21vdXMgc3lzdGVtIG51bWJlciIgaW4gdGhlIG9wZW4gbWVzc2FnZS4NCg0KUmVnYXJkcywN CktleXVyIA0KDQrvu79PbiAzLzE3LzIwLCA4OjI3IFBNLCAiUmFuZHkgQnVzaCIgPHJhbmR5QHBz Zy5jb20+IHdyb3RlOg0KDQogICAgPiBJIHdhbnRlZCB0byBhdm9pZCAiYmUgYWJsZSB0byBiZSIg YW5kIGhhdmUgYW4gZXhwbGljaXQgYWN0b3IuIEkgc2VlDQogICAgPiB0aGUgZGlmZmljdWx0eSB5 b3UgcG9pbnQgdG8gYmVsb3cuDQogICAgDQogICAgaSBhbSBoYXBweSB0byBjaGFuZ2UgdG8gdGhl IGZvbGxvd2luZw0KICAgIA0KICAgID4+IEFzIHRoZSBvcmlnaW4gQVMgbWF5IGJlIG1vZGlmaWVk IGJ5IG91dGJvdW5kIHBvbGljeSwgYSBCR1Agc3BlYWtlcg0KICAgID4+IE1VU1QgYXBwbHkgUk9W IHBvbGljeSBzZW1hbnRpY3MgdXNpbmcgdGhlIE15IEF1dG9ub21vdXMgU3lzdGVtIG51bWJlcg0K ICAgID4+IGluIHRoZSBCR1AgT1BFTiBtZXNzYWdlIChzZWUgUkZDIDQyNzEgc2VjdGlvbiA0LjIp IGlzc3VlZCB0byB0aGUgcGVlcg0KICAgID4+IHRvIHdoaWNoIHRoZSBVUERBVEUgaXMgYmVpbmcg c2VudC4NCiAgICANCiAgICBidXQsIGluIG15IGZyZWUgb3BpbmlvbiwgYXMgaXQgaXMgaW4gSUVU RiBMQywgdGhlIGNoYW5nZSBpcyBlbm91Z2ggdGhhdA0KICAgIGl0IG1pZ2h0IHJlcXVpcmUgYXBw cm92YWwgYnkgY2hhaXJzIGFuZC9vciBBRC4NCiAgICANCiAgICByYW5keQ0KICAgIA0KDQo= From nobody Wed Mar 18 11:43:42 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 B27C23A1A1C; Wed, 18 Mar 2020 11:43:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Yingzhen Qu via Datatracker To: Cc: last-call@ietf.org, sidrops@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158455699565.29645.13745916479393604486@ietfa.amsl.com> Reply-To: Yingzhen Qu Date: Wed, 18 Mar 2020 11:43:15 -0700 Archived-At: Subject: [Sidrops] Rtgdir last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 18:43:17 -0000 Reviewer: Yingzhen Qu Review result: Has Issues I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-sidrops-ov-egress Reviewer: Yingzhen Qu Review Date: March 17th, 2020 Intended Status: Standards Track Summary: This document is near ready for publication. It has some issues that should be at least considered prior to publication. This is a very concise document, and the goal is to provide clarifications on BGP origin validation when egress policies are used, especially when the effective origin AS is different from the origin AS. Major Issues: No major issue found. Minor Issues: I’d suggest to add a couple of examples to help understanding the document. In section 4: “Therefore it SHOULD be possible to specify an origin validation policy which MUST BE run after such non-deterministic policies.” My understanding is the origin AS might have been changed by egress policy, and in some complicated case, the effective origin AS is hard to predict, and an origin validation policy MUST be run. But how should this “possible” policy be specified? In section4: “An operator SHOULD be able to list what announcements are not sent to A peer because they were marked Invalid, as long as the router still has them in memory.” Is this the list of routes that were marked Invalid before egress policy? Routes that were validated using the origin AS. Nits: In section 4: “Therefore it SHOULD be possible to specify an origin validation policy which MUST BE run after such non-deterministic policies.” “MUST” instead of “MUST BE”? From nobody Wed Mar 18 12:57:11 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 60C663A1B11; Wed, 18 Mar 2020 12:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wqu1HvNZ4VOH; Wed, 18 Mar 2020 12:56:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 230503A1B0F; Wed, 18 Mar 2020 12:56:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jEenk-0004U4-PU; Wed, 18 Mar 2020 19:56:28 +0000 Date: Wed, 18 Mar 2020 12:56:28 -0700 Message-ID: From: Randy Bush To: Keyur Patel Cc: Robert Sparks , gen-art@ietf.org, last-call@ietf.org, draft-ietf-sidrops-ov-egress.all@ietf.org, SIDR Operations WG In-Reply-To: <5A210359-FE01-40BF-9BAD-E0250BB31BFC@arrcus.com> References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> <5A210359-FE01-40BF-9BAD-E0250BB31BFC@arrcus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 19:56:42 -0000 ( warning: quote depth errors and top posting. keyur's mta, well let's not get into that :) > Speaking as a wg member. and one of the first ROV implementors, tyvm. > Shouldn=E2=80=99t you be checking the "my autonomous system number" in the > update message (when sending it out to the ebgp peer) as opposed to > "my autonomous system number" in the open message. > > Regards, Keyur > > =EF=BB=BFOn 3/17/20, 8:27 PM, "Randy Bush" wrote: > >> I wanted to avoid "be able to be" and have an explicit actor. I see >> the difficulty you point to below. > > i am happy to change to the following > >>> As the origin AS may be modified by outbound policy, a BGP speaker >>> MUST apply ROV policy semantics using the My Autonomous System number >>> in the BGP OPEN message (see RFC 4271 section 4.2) issued to the peer >>> to which the UPDATE is being sent. > > but, in my free opinion, as it is in IETF LC, the change is enough that > it might require approval by chairs and/or AD. i think you're right. what counts for ROV is the origin AS in the UPDATE. open a hole to deviate from that and ... and we have to remember that, for these UPDATEs which are redistributed into BGP by this speaker, have their AS_PATH first created when sent to the peer. i.e. we can not (yet) speak of the origin AS in the AS_PATH. so maybe As the origin AS of a BGP UPDATE is decided by configuration and outbound policy of the BGP speaker, a validating BGP speaker MUST apply Route Origin Validation policy semantics against the origin Autonomous System number which it will put in the AS_PATH (see RFC 4271 4.3 Path Attributes:b) of the UPDATE to the peer. randy From nobody Wed Mar 18 16:55: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 970173A1E7A; Wed, 18 Mar 2020 16:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 liVf3S2ZKhW1; Wed, 18 Mar 2020 16:55:06 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2083.outbound.protection.outlook.com [40.107.237.83]) (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 4CE0C3A1E7B; Wed, 18 Mar 2020 16:55:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LrSypMZST6GpzA+fqcGvH4Zm+jkTztONF3EeWvB1HXqGT6Rvcmv2hZ9U/qq5sBBtj+7k/PE932UeoBQ7IjcNRpsuuvF5S9mWLucqZZr0lbD+25q788FuGnLdu1ACVaCJc2rlWbN0SmfQFCV5UHDuL4xOg1kZ8yJPRsNhnt2GmnQHapPs1NO8lZ2KXzamCqa9DLoSo0PN0ObViRbG5mA/i1pUfwDVYBfO5KTpF/ImpVfzULrViMm8FgIKqItdsWJ7TbhvbUr5/L1af8NsHMaK1OEp2F55UGYC0x3paXQyj610VM22MTd5Y/gOVt7hxtdphskdvCYVfYP9VOCG2y3Zvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m6G5G5cUqwuiTzA1JMeRyI4q064EEAVW560RIHnVd2k=; b=MdmEsu8ydyA15HY2YTFmeTaYPDWYpZ6hkg/e52GuSco5wuX8ebDHBJZskAvJoXxYFZXk0ojsM5c1GrsjTGoBWt3aGJ+ARi5f5cggx2lyenDjWn7GSoOQ6pMXhv/DW1hJWSGijIxYQ5dVVgMoP3Ak+pOF3u5Qdub98Jx4TRAW2iP6owapJsSbRW440sKAqLtl/f2neOG5W6KOisBJjfdO4mQHJpdiX0V4qKs3knGcZgoHQ56595OKuuaj19tUc9YnHehPA0UxsZDwjq0Ux4IdEZbdL6wGQW3gI1i9ywdpzN3t7f54fC5lXMgK+FiiW0kEdAikd5r2j1ZEDEt6UsNpww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m6G5G5cUqwuiTzA1JMeRyI4q064EEAVW560RIHnVd2k=; b=ofGNrr2iqtHl0MmUS0Uh1/IWcQF9AomBVbIKUb0HjDSoZSmnWO49zU9qMgT2UXCvmwfRShqvx4Ct2EYJ13/y9y1gk8hVv8PU8yWgLrMH0WxyOy5mkN4806KOmlreYVaD7QFDc6gvlrFOD6LFEpsAQvstZdwHAonn/tBTgmcCZNk= Received: from BYAPR18MB2534.namprd18.prod.outlook.com (2603:10b6:a03:12e::29) by BYAPR18MB2440.namprd18.prod.outlook.com (2603:10b6:a03:12f::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.22; Wed, 18 Mar 2020 23:55:01 +0000 Received: from BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::410:1331:ad08:f859]) by BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::410:1331:ad08:f859%7]) with mapi id 15.20.2814.021; Wed, 18 Mar 2020 23:55:01 +0000 From: Keyur Patel To: Randy Bush CC: Robert Sparks , "gen-art@ietf.org" , "last-call@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" , SIDR Operations WG Thread-Topic: Genart last call review of draft-ietf-sidrops-ov-egress-01 Thread-Index: AQHV+Uph1zWgr+WNoEWHlzZmpUwEaqhNmAWAgAAdQYCAAAI0AIAAgDOAgACUXQD//81QgA== Date: Wed, 18 Mar 2020 23:55:01 +0000 Message-ID: <9114C890-46E6-4D51-A01D-EE34E4D1022B@arrcus.com> References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> <5A210359-FE01-40BF-9BAD-E0250BB31BFC@arrcus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [2601:646:8700:a6f0:c83c:3627:eac7:4a8e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6471abe5-5591-47ff-503f-08d7cb97c596 x-ms-traffictypediagnostic: BYAPR18MB2440: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(136003)(396003)(376002)(346002)(366004)(199004)(54906003)(316002)(36756003)(66556008)(76116006)(66446008)(5660300002)(66946007)(66476007)(33656002)(508600001)(71200400001)(64756008)(2906002)(186003)(2616005)(6486002)(86362001)(8936002)(6512007)(81166006)(81156014)(8676002)(4326008)(53546011)(6506007)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2440; H:BYAPR18MB2534.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: atinopnwKv5FfWinIz8HfjR0WX/QoTkGUKzul8j3ca1HxyMgzy3inF+CuwcAOYbbTSgcukKn099VOYqM/D5JpQqxkwMuzJD5vy5mymmNz83ncKvY329BGWIzPAtez/cCkdwdBneuvXV/qsrJ8oboPUH0jhzsfEi5Iw3ywBjAlDELmtn3DjpqG0GcAoeyUXQzaPx+DAzcdvwKmYx2hnIczNDY7lnRU1M0KV/zM5ao31Rwk5ZdHSDeVJ81ltJAIHFSmKzEvNfzg0PhKh0R4X0o3GQApzar/hzo+U4tC7n5m6RX+iQaHlQpBTjwE+sXRHRpaBWPsMdynmh9l46i3/zkyFzJ5Md1wakQp52BI3unSN6p3rXiceRWdJcppwWG2x7O/AUTRi6LkYOZh3uebD1ZCA5KyLKzYeMjqySlVAdnUtwdnyXIMCRmE8HivxCSQBVa x-ms-exchange-antispam-messagedata: QKKJoVXbGAsQublRjTGRMK5zMo6SHkBW5yj1FrLPmkokXh4NJ0N4OpbLiGWvF+KScXdIMKjEiNgx6C8STsGx6akeg459pHoJUg2yq6I4ewGV4MjroilqUrCTbjymtXMCOJ5CrMBY9A7DQS8Q0DA6WDziA1TzVlgqssDFfsL1IPQhjOaALN5F9PeNaVqfnIAWIhg3W90b0t6PKa/2TitZ3g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2115718E3A6A264EB01B157B4BFD83F7@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6471abe5-5591-47ff-503f-08d7cb97c596 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2020 23:55:01.1007 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9FrQ5dmq3Q9xpI6h4HcxvLhVPeOkdyZokTt2//+sZevsHvIlWM2Bgq8FUqhR8q4o2C8rU8zOO9h/veZA227Zeg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2440 Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Wed, 18 Mar 2020 23:55:08 -0000 DQoNCu+7v09uIDMvMTgvMjAsIDEyOjU2IFBNLCAiUmFuZHkgQnVzaCIgPHJhbmR5QHBzZy5jb20+ IHdyb3RlOg0KDQogICAgKCB3YXJuaW5nOiBxdW90ZSBkZXB0aCBlcnJvcnMgYW5kIHRvcCBwb3N0 aW5nLiAga2V5dXIncyBtdGEsIHdlbGwgbGV0J3MNCiAgICBub3QgZ2V0IGludG8gdGhhdCA6KQ0K ICAgIA0KICAgID4gU3BlYWtpbmcgYXMgYSB3ZyBtZW1iZXIuDQogICAgDQogICAgYW5kIG9uZSBv ZiB0aGUgZmlyc3QgUk9WIGltcGxlbWVudG9ycywgdHl2bS4NCiAgICANCiAgICA+IFNob3VsZG7i gJl0IHlvdSBiZSBjaGVja2luZyB0aGUgIm15IGF1dG9ub21vdXMgc3lzdGVtIG51bWJlciIgaW4g dGhlDQogICAgPiB1cGRhdGUgbWVzc2FnZSAod2hlbiBzZW5kaW5nIGl0IG91dCB0byB0aGUgZWJn cCBwZWVyKSBhcyBvcHBvc2VkIHRvDQogICAgPiAibXkgYXV0b25vbW91cyBzeXN0ZW0gbnVtYmVy IiBpbiB0aGUgb3BlbiBtZXNzYWdlLg0KICAgID4NCiAgICA+IFJlZ2FyZHMsIEtleXVyDQogICAg Pg0KICAgID4gT24gMy8xNy8yMCwgODoyNyBQTSwgIlJhbmR5IEJ1c2giIDxyYW5keUBwc2cuY29t PiB3cm90ZToNCiAgICA+DQogICAgPj4gSSB3YW50ZWQgdG8gYXZvaWQgImJlIGFibGUgdG8gYmUi IGFuZCBoYXZlIGFuIGV4cGxpY2l0IGFjdG9yLiBJIHNlZQ0KICAgID4+IHRoZSBkaWZmaWN1bHR5 IHlvdSBwb2ludCB0byBiZWxvdy4NCiAgICA+DQogICAgPiBpIGFtIGhhcHB5IHRvIGNoYW5nZSB0 byB0aGUgZm9sbG93aW5nDQogICAgPg0KICAgID4+PiBBcyB0aGUgb3JpZ2luIEFTIG1heSBiZSBt b2RpZmllZCBieSBvdXRib3VuZCBwb2xpY3ksIGEgQkdQIHNwZWFrZXINCiAgICA+Pj4gTVVTVCBh cHBseSBST1YgcG9saWN5IHNlbWFudGljcyB1c2luZyB0aGUgTXkgQXV0b25vbW91cyBTeXN0ZW0g bnVtYmVyDQogICAgPj4+IGluIHRoZSBCR1AgT1BFTiBtZXNzYWdlIChzZWUgUkZDIDQyNzEgc2Vj dGlvbiA0LjIpIGlzc3VlZCB0byB0aGUgcGVlcg0KICAgID4+PiB0byB3aGljaCB0aGUgVVBEQVRF IGlzIGJlaW5nIHNlbnQuDQogICAgPg0KICAgID4gYnV0LCBpbiBteSBmcmVlIG9waW5pb24sIGFz IGl0IGlzIGluIElFVEYgTEMsIHRoZSBjaGFuZ2UgaXMgZW5vdWdoIHRoYXQNCiAgICA+IGl0IG1p Z2h0IHJlcXVpcmUgYXBwcm92YWwgYnkgY2hhaXJzIGFuZC9vciBBRC4NCiAgICANCiAgICBpIHRo aW5rIHlvdSdyZSByaWdodC4gIHdoYXQgY291bnRzIGZvciBST1YgaXMgdGhlIG9yaWdpbiBBUyBp biB0aGUNCiAgICBVUERBVEUuICBvcGVuIGEgaG9sZSB0byBkZXZpYXRlIGZyb20gdGhhdCBhbmQg Li4uDQogICAgDQogICAgYW5kIHdlIGhhdmUgdG8gcmVtZW1iZXIgdGhhdCwgZm9yIHRoZXNlIFVQ REFURXMgd2hpY2ggYXJlIHJlZGlzdHJpYnV0ZWQNCiAgICBpbnRvIEJHUCBieSB0aGlzIHNwZWFr ZXIsIGhhdmUgdGhlaXIgQVNfUEFUSCBmaXJzdCBjcmVhdGVkIHdoZW4gc2VudCB0bw0KICAgIHRo ZSBwZWVyLiAgaS5lLiB3ZSBjYW4gbm90ICh5ZXQpIHNwZWFrIG9mIHRoZSBvcmlnaW4gQVMgaW4g dGhlIEFTX1BBVEguDQogICAgDQogICAgc28gbWF5YmUNCiAgICANCiAgICAgICAgQXMgdGhlIG9y aWdpbiBBUyBvZiBhIEJHUCBVUERBVEUgaXMgZGVjaWRlZCBieSBjb25maWd1cmF0aW9uIGFuZA0K ICAgICAgICBvdXRib3VuZCBwb2xpY3kgb2YgdGhlIEJHUCBzcGVha2VyLCBhIHZhbGlkYXRpbmcg QkdQIHNwZWFrZXIgTVVTVA0KICAgICAgICBhcHBseSBSb3V0ZSBPcmlnaW4gVmFsaWRhdGlvbiBw b2xpY3kgc2VtYW50aWNzIGFnYWluc3QgdGhlIG9yaWdpbg0KICAgICAgICBBdXRvbm9tb3VzIFN5 c3RlbSBudW1iZXIgd2hpY2ggaXQgd2lsbCBwdXQgaW4gdGhlIEFTX1BBVEggKHNlZSBSRkMNCiAg ICAgICAgNDI3MSA0LjMgUGF0aCBBdHRyaWJ1dGVzOmIpIG9mIHRoZSBVUERBVEUgdG8gdGhlIHBl ZXIuDQoNCg0KTG9va3MgZ29vZCB0byBtZS4gX18gDQoNClJlZ2FyZHMsDQpLZXl1cg0KICAgIA0K ICAgIHJhbmR5DQogICAgDQoNCg== From nobody Thu Mar 19 14:25:48 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 99BF43A0FFE; Thu, 19 Mar 2020 14:25:41 -0700 (PDT) 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.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <158465314149.15781.13739513490316692044@ietfa.amsl.com> Date: Thu, 19 Mar 2020 14:25:41 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-ov-egress-02.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, 19 Mar 2020 21:25:42 -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 : BGP RPKI-Based Origin Validation on Export Authors : Randy Bush Ruediger Volk Jakob Heitz Filename : draft-ietf-sidrops-ov-egress-02.txt Pages : 5 Date : 2020-03-19 Abstract: A BGP speaker may perform RPKI origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification uses the effective origin AS of the processed route, which may specifically be altered by the commonly available knobs such as removing private ASs, confederation handling, and other modifications of the origin AS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-egress/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-ov-egress-02 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-ov-egress-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-ov-egress-02 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 Fri Mar 20 02:58:22 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 0CC463A078F; Fri, 20 Mar 2020 02:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 0OmaC5lT-Yem; Fri, 20 Mar 2020 02:57:48 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2055.outbound.protection.outlook.com [40.107.20.55]) (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 7F0433A078B; Fri, 20 Mar 2020 02:57:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yz1IsYeA3qJKFzRxQDGxQV/hacn4WL2tlDVwWetNs6Wrm9KdP+5QLljWwEdeh2DZg0uhTnLQEfDUaML81FSjH4Jd/GJlxm7mjj7isFw2qFwfpI0gdwBVX+brX7oj1Wg95h/tv1VEjViRmnPCWL3chuZsMDeZJzu2dQjVFvy1tB3fbOcxfL/gwZQ56Yf3QPjWkcqDcsBDGKgpzpcdbXyWnQ6tbpRHaivZv3kowBZsfNDwJhEHT0WzhokT0neczr0baFumKys6e0iRDe4LWROlHJ43sYZxaw/SQmyG6XfKN/7q7/aKOIfLh6Gp03pkF5ZM4Q1F19xOHBt4l02yhELB4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Ugj6gXYHUKtplooijKHxFFsqlQD1ubuULcjOzJRfd0=; b=Pta54QpIGndfHpJTvC4GfiJeq/b/zsAeCZTFVZZEGow3dEfF4h93gw4anmi5y/FV70lEAxQP1eGcucLRbsFjGJXFfYx45DmCVW3zJaiAywRDFjtJ1f9YEQ0bKHjEjoeLknn94Y5cY7OScDwFwk6xgERdI2+2YTFi4L21X3HcpJLYvaVGej1a8Cpmsnr5DCPGVHtWJaZVAL2arg475cfyjzFiWVI/D1qe9pVPJkAUEtT/Q4WRVMjqfnhT+F/EE5gfdLDVieOKqfNVb8KjEr7dycM8B8zRiXWqzOaRTvJPG01SbpJyZSGY4oeIOOC57HtBuHvEYuXwgV+OcwNLbzdSBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Ugj6gXYHUKtplooijKHxFFsqlQD1ubuULcjOzJRfd0=; b=Q+E+caF9yQLvcu09EzwHZD5ehAFwfc7A8bPOOZelUcMpk3wbibrlINveWEWxbpmJ4eYaIyOnIJu2e5e3GA9csc5XmVpm2tnFfa5a/i8PicjM2sgnMgmXfTQFsedeNca6diRnnwm8R5Kv6oDDey0biKXeHRONRaZOV7aZjnU5Gto= Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (52.135.56.21) by AM7P190MB0775.EURP190.PROD.OUTLOOK.COM (52.135.56.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.18; Fri, 20 Mar 2020 09:57:42 +0000 Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252%7]) with mapi id 15.20.2814.025; Fri, 20 Mar 2020 09:57:42 +0000 From: Ben Maddison To: "randy@psg.com" , "job@ntt.net" CC: "nick@foobar.org" , "last-call@ietf.org" , "ops-dir@ietf.org" , "linda.dunbar@futurewei.com" , "sidrops@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" Thread-Topic: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 Thread-Index: AQHV/Kb2XJdSWmlaN0iV0dnimUseQ6hNg3WAgAALw4CAAAK9gIADsLgA Date: Fri, 20 Mar 2020 09:57:42 +0000 Message-ID: <55f529777e4524b2ac2f6f94c0955611d04aa250.camel@workonline.africa> References: <158448201565.32201.9748655174984394118@ietfa.amsl.com> <624bd5c7-5459-64c2-5694-b77dde5835a6@foobar.org> <20200318012635.GE77479@vurt.meerval.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa; x-originating-ip: [165.0.73.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3d9784e5-79ee-4fca-65c9-08d7ccb521aa x-ms-traffictypediagnostic: AM7P190MB0775: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03484C0ABF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(396003)(39840400004)(346002)(199004)(6506007)(4326008)(81156014)(86362001)(6512007)(2616005)(8676002)(2906002)(8936002)(81166006)(4744005)(6486002)(91956017)(66946007)(76116006)(66556008)(66446008)(66476007)(64756008)(26005)(71200400001)(316002)(54906003)(508600001)(5660300002)(186003)(110136005)(46492006)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P190MB0775; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wXvDuq8RvoTRQO2nOXlSGX3ljKIAsjDYOeQ8wKPgTbJ0ox9mQLAicbUUB+W29zKu2cjCnntpsU5kkuYh21xx111FQsHtEoGx8Bm1BEFDaf8OOjBGry5rHeriicRTIKOxD4re9Sp5Fly7XvKTEQGgazEss/tIKeNcELj++LldiGETp5XsF/Lgju+sJDROC1mjKCu1Y+b3w6z+fws1bLysu9ZfwaWNGCFP6OD8m2BR6LTt/cNXcS7b+WAs1nBNuP3TyADGVtEriC/k99x9AT62pMQFDClxBpGl7fgOlVcpx9GvqT3NHnCa/1kaByA/16xV6eWRgnA1RGJOM7WM1Es4XtHvsKG8Q56IeuQeQdYB/E+dTbtzMu5vt3kol5Ecu1kYnHTwgaWIyDWvwvQIK5n0BoN+DtvtRSWJO9AZkiaQt97zkzsvwyxSu07BKoHumsQQkm/pzvRDno42XRjGCaf+6DeSGBdNv8hH9mImp01AZhCBv/iBadVXkpdKiJ3UJHXMbj87RQpByoHXEwUPXlXqIA== x-ms-exchange-antispam-messagedata: y/2IQqCuCvHr1qY4PO+fEDEhIGYAjyf2IJPipiBISCQZoCwbi4TSftB8G+pB3JyhelxIJprf/3P2uFU6Qvmvkv5o1vheELZgqpjp5t1Ix8a/56FCNnwVM4jgSEtOt6nVFNIR/rZskzV+Nhu1indYUQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2C5FA023C9EC814ABBD285E11B56E1ED@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 3d9784e5-79ee-4fca-65c9-08d7ccb521aa X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2020 09:57:42.1330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lhVrESVLSZCcG16P1gOe7yfvPtU069hwLLzeo4doBuno3xM94+rkkctBiz0R+dvwp8o3V5BushHuGmyHRqBd+A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0775 Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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: Fri, 20 Mar 2020 09:57:52 -0000 T24gVHVlLCAyMDIwLTAzLTE3IGF0IDE4OjM2IC0wNzAwLCBSYW5keSBCdXNoIHdyb3RlOg0KPiA+ IEJHUCBpbXBsZW1lbnRhdGlvbnMgaGF2ZSB0byB0YWtlIHJlbW92YWwgb2YgcHJpdmF0ZSBBUyhz KSwNCj4gPiBjb25mZWRlcmF0aW9uLCBBUyBtaWdyYXRpb24sIGV0YyBpbnRvIGNvbnNpZGVyYXRp b24uDQo+IA0KPiBhbmQgdGhlIHdpbmRzIG9mIHN1bW1lci4gIHdlIGRvIG5vdCBuZWVkIHRvIGVu dW1lcmF0ZSBhbGwga25vYnMsIGFzDQo+IGlmIHdlIGNvdWxkLg0KPiANCkJ1dCBlbnVtZXJhdGlu ZyAqc29tZSogaGVscHMgdGhlIHJlYWRlciB1bmRlcnN0YW5kIHRoZSBjb250ZXh0IGluIHdoaWNo DQp0aGlzIGlzIGltcG9ydGFudC91c2VmdWwuDQoNCkNoZWVycywNCg0KQmVuDQoNCg== From nobody Fri Mar 20 03:12:49 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 7D89A3A079E; Fri, 20 Mar 2020 03:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 4R12EA_3f2rB; Fri, 20 Mar 2020 03:11:46 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on20607.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1b::607]) (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 ED2673A079B; Fri, 20 Mar 2020 03:11:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Iw+uHZxexffmYyFAIkjfTMEm4bQfxJi/eWWxZUD7K296dh0uHReDsdlYBv000zeYNgkH/JDw4qEeYi8BSLII63zqtasVlele2c/PaZ/PSmHbRub4QC5VMlZaQijgt+ontOTe00GdkZ5girkvkG75u/SoyhDcbPAGKuq46RJ4Hv7RiNZq4hUqKEub0tvGfsYpDKtfzJ9nCmrK8p0rblv3ktvhFmftoAaS4Y/bbeqveOdBi1zhx71+FYX/rGW2rzd/iC9p1EcluUp+17dGiE71ACHjDXwDEsyGMiy+k5K61R0wXQ73rfZvnyDV7TqA6wd7zbJFzMYj9UwZYCIOQftlkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L9DrfwQkiJ/SKjCFZB4c76+SMCrNvkDwE0D16i62QDU=; b=Emgfg2MtF/VK6SCj0y0X+jVyRdWcDlOFrC27X694o1M92ZZ15Bvb9MFMbgo830xnn4EQE/qwk4/7SqVhaMUx4EfC/B2WBHVKpk11UWzKXOeTWjuL5WlRb4kLd8ho3jwi9NWETx3CjyG3B+8IpALKtPNO6yfocUhuAstwIUVOsXezMMr1LAad5op0V+vp+DF+eM/zVFBqghKwgJtGfkALUYI+gNjtqAMImxKfTmykpe8J/YzgzpHIyRc+ADo0SCVuStSIAARFLvZYLWC60FxaaRcbJbqwyounDZsmLzA8D45aClMClcMotae+Dw1hoDlljhniAtoC/DdDcTTsprk34Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L9DrfwQkiJ/SKjCFZB4c76+SMCrNvkDwE0D16i62QDU=; b=UyPlsPG1zm7ZFdkfuxgiIDWwzSIAbiYx8nQUXXuxXRmaguPUyxV/vXZzYOguqm+Frd4vuxMg0caRP6EC3E9sK5KQV5DPDm7EvdqQ9qApFHkFMjvPnNSuGPOARealOR24folXmsZ6J54IaKZMqsGufPLzM2bTBH7+Pds7KrMjQgI= Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (52.135.56.21) by AM7P190MB0695.EURP190.PROD.OUTLOOK.COM (52.135.56.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20; Fri, 20 Mar 2020 10:11:20 +0000 Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252%7]) with mapi id 15.20.2814.025; Fri, 20 Mar 2020 10:11:20 +0000 From: Ben Maddison To: "randy@psg.com" , "keyur@arrcus.com" CC: "last-call@ietf.org" , "rjsparks@nostrum.com" , "sidrops@ietf.org" , "gen-art@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" Thread-Topic: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 Thread-Index: AQHV/VAnBdRzgu0rVUGGU8YdM7o2yKhOw/8AgAKBKwA= Date: Fri, 20 Mar 2020 10:11:20 +0000 Message-ID: <37beff1136180992cc9b1a209cd5880a9db0dbff.camel@workonline.africa> References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> <5A210359-FE01-40BF-9BAD-E0250BB31BFC@arrcus.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa; x-originating-ip: [165.0.73.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 458a3855-7139-4135-7d4b-08d7ccb7096f x-ms-traffictypediagnostic: AM7P190MB0695: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03484C0ABF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(366004)(39840400004)(136003)(199004)(64756008)(2906002)(26005)(6512007)(6506007)(66946007)(76116006)(91956017)(5660300002)(8676002)(81156014)(2616005)(66446008)(81166006)(54906003)(4326008)(86362001)(66476007)(66556008)(71200400001)(6486002)(316002)(8936002)(186003)(110136005)(508600001)(46492006)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P190MB0695; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Wj2WRXok6wfCqhLpBleF1LyjRyRfRzybwWqQ5EckBdyHXGZ/KuJ3wc1rmwjyVcB7gpCz+BnyNTvtuR5aMWel75GBuRRR9C7QTbsCsgNUi5GXWK9uAZjynIP0NnX7Bhf0xNsjwIH8ebxXaHOpZjK2oVZu0iDdC8CE4TP+XdoRMf08aGeoW5CH4k3vMwui+F9xm7t7daulz+LUb0PDUjNE8FwJb44BB3et8bYojrPD8rlaNW8PNL3F83UdKnmdQ/dqe0EncMWhkknLQUo9WV+5b2SgVsZfTPzRaAijENFkQ2ea3AQdzQhKTnZpdgqWnKFGPXZd7jLPy6V1ZGYy0sbAyIfgAlYZemx1iVV/aYsVmyNU901ulSVPR0yIGhOmdlfTAmW+6SxJy7x/AcVMwowUV1YPGDVwmyqPVm0oRUKdkAIc1GebJzUmXgxsHpEMCVnyN/ZQYTEuZPFGExYlFF4yc50L1ireiId8aQzoFELhFBWML6sO2FfIgWPm5DlT4oxHNC74oyI3xFY+9UOTohjqGw== x-ms-exchange-antispam-messagedata: 0/8rLiH4CRtaIPDdZhWekZ0qHkZTfGyUnBCbBpf6j/HKyzbKujJwCu6jiKmDI/nbGMPPvovqSKZjQvGgC0y5LWYZulEHkyaEm3XJmzJ8tCaLYDrKxxLrJTC2fK1Iz7kzIeN9s8p5nyTfkgU+Gt+cfg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 458a3855-7139-4135-7d4b-08d7ccb7096f X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2020 10:11:20.4452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iT3ZZDZBwsPWg74MCBSoBXFWK1yGwXBFM/1HUCIHyHadBG0S/dqwEBP3aRMCBVTdiAeOtI0qDPOjfeXrKST9ww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0695 Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Fri, 20 Mar 2020 10:12:01 -0000 T24gV2VkLCAyMDIwLTAzLTE4IGF0IDEyOjU2IC0wNzAwLCBSYW5keSBCdXNoIHdyb3RlOg0KPiAo IHdhcm5pbmc6IHF1b3RlIGRlcHRoIGVycm9ycyBhbmQgdG9wIHBvc3RpbmcuICBrZXl1cidzIG10 YSwgd2VsbA0KPiBsZXQncw0KPiBub3QgZ2V0IGludG8gdGhhdCA6KQ0KPiANCj4gPiBTcGVha2lu ZyBhcyBhIHdnIG1lbWJlci4NCj4gDQo+IGFuZCBvbmUgb2YgdGhlIGZpcnN0IFJPViBpbXBsZW1l bnRvcnMsIHR5dm0uDQo+IA0KPiA+IFNob3VsZG7igJl0IHlvdSBiZSBjaGVja2luZyB0aGUgIm15 IGF1dG9ub21vdXMgc3lzdGVtIG51bWJlciIgaW4gdGhlDQo+ID4gdXBkYXRlIG1lc3NhZ2UgKHdo ZW4gc2VuZGluZyBpdCBvdXQgdG8gdGhlIGViZ3AgcGVlcikgYXMgb3Bwb3NlZCB0bw0KPiA+ICJt eSBhdXRvbm9tb3VzIHN5c3RlbSBudW1iZXIiIGluIHRoZSBvcGVuIG1lc3NhZ2UuDQo+ID4gDQo+ ID4gUmVnYXJkcywgS2V5dXINCj4gPiANCj4gPiDvu79PbiAzLzE3LzIwLCA4OjI3IFBNLCAiUmFu ZHkgQnVzaCIgPHJhbmR5QHBzZy5jb20+IHdyb3RlOg0KPiA+IA0KPiA+ID4gSSB3YW50ZWQgdG8g YXZvaWQgImJlIGFibGUgdG8gYmUiIGFuZCBoYXZlIGFuIGV4cGxpY2l0IGFjdG9yLiBJDQo+ID4g PiBzZWUNCj4gPiA+IHRoZSBkaWZmaWN1bHR5IHlvdSBwb2ludCB0byBiZWxvdy4NCj4gPiANCj4g PiBpIGFtIGhhcHB5IHRvIGNoYW5nZSB0byB0aGUgZm9sbG93aW5nDQo+ID4gDQo+ID4gPiA+IEFz IHRoZSBvcmlnaW4gQVMgbWF5IGJlIG1vZGlmaWVkIGJ5IG91dGJvdW5kIHBvbGljeSwgYSBCR1AN Cj4gPiA+ID4gc3BlYWtlcg0KPiA+ID4gPiBNVVNUIGFwcGx5IFJPViBwb2xpY3kgc2VtYW50aWNz IHVzaW5nIHRoZSBNeSBBdXRvbm9tb3VzIFN5c3RlbQ0KPiA+ID4gPiBudW1iZXINCj4gPiA+ID4g aW4gdGhlIEJHUCBPUEVOIG1lc3NhZ2UgKHNlZSBSRkMgNDI3MSBzZWN0aW9uIDQuMikgaXNzdWVk IHRvDQo+ID4gPiA+IHRoZSBwZWVyDQo+ID4gPiA+IHRvIHdoaWNoIHRoZSBVUERBVEUgaXMgYmVp bmcgc2VudC4NCj4gPiANCj4gPiBidXQsIGluIG15IGZyZWUgb3BpbmlvbiwgYXMgaXQgaXMgaW4g SUVURiBMQywgdGhlIGNoYW5nZSBpcyBlbm91Z2gNCj4gPiB0aGF0DQo+ID4gaXQgbWlnaHQgcmVx dWlyZSBhcHByb3ZhbCBieSBjaGFpcnMgYW5kL29yIEFELg0KPiANCj4gaSB0aGluayB5b3UncmUg cmlnaHQuICB3aGF0IGNvdW50cyBmb3IgUk9WIGlzIHRoZSBvcmlnaW4gQVMgaW4gdGhlDQo+IFVQ REFURS4gIG9wZW4gYSBob2xlIHRvIGRldmlhdGUgZnJvbSB0aGF0IGFuZCAuLi4NCj4gDQo+IGFu ZCB3ZSBoYXZlIHRvIHJlbWVtYmVyIHRoYXQsIGZvciB0aGVzZSBVUERBVEVzIHdoaWNoIGFyZQ0K PiByZWRpc3RyaWJ1dGVkDQo+IGludG8gQkdQIGJ5IHRoaXMgc3BlYWtlciwgaGF2ZSB0aGVpciBB U19QQVRIIGZpcnN0IGNyZWF0ZWQgd2hlbiBzZW50DQo+IHRvDQo+IHRoZSBwZWVyLiAgaS5lLiB3 ZSBjYW4gbm90ICh5ZXQpIHNwZWFrIG9mIHRoZSBvcmlnaW4gQVMgaW4gdGhlDQo+IEFTX1BBVEgu DQo+IA0KPiBzbyBtYXliZQ0KPiANCj4gICAgIEFzIHRoZSBvcmlnaW4gQVMgb2YgYSBCR1AgVVBE QVRFIGlzIGRlY2lkZWQgYnkgY29uZmlndXJhdGlvbiBhbmQNCj4gICAgIG91dGJvdW5kIHBvbGlj eSBvZiB0aGUgQkdQIHNwZWFrZXIsIGEgdmFsaWRhdGluZyBCR1Agc3BlYWtlciBNVVNUDQo+ICAg ICBhcHBseSBSb3V0ZSBPcmlnaW4gVmFsaWRhdGlvbiBwb2xpY3kgc2VtYW50aWNzIGFnYWluc3Qg dGhlIG9yaWdpbg0KPiAgICAgQXV0b25vbW91cyBTeXN0ZW0gbnVtYmVyIHdoaWNoIGl0IHdpbGwg cHV0IGluIHRoZSBBU19QQVRIIChzZWUNCj4gUkZDDQo+ICAgICA0MjcxIDQuMyBQYXRoIEF0dHJp YnV0ZXM6Yikgb2YgdGhlIFVQREFURSB0byB0aGUgcGVlci4NCj4gDQoNCkFsdGhvdWdoIGEgbGl0 dGxlIG1vcmUgdmVyYm9zZSwgcGVyaGFwcyB0aGUgZm9sbG93aW5nIGlzIG1vcmUgZXhwbGljaXQ/ DQoNCiAgICBBcyB0aGUgb3JpZ2luIEFTIG9mIGEgQkdQIFVQREFURSBpcyBkZWNpZGVkIGJ5IGNv bmZpZ3VyYXRpb24gYW5kDQogICAgb3V0Ym91bmQgcG9saWN5IG9mIHRoZSBCR1Agc3BlYWtlciwg YSB2YWxpZGF0aW5nIEJHUCBzcGVha2VyIE1VU1QNCiAgICBhcHBseSBSb3V0ZSBPcmlnaW4gVmFs aWRhdGlvbiBwb2xpY3kgc2VtYW50aWNzIGFnYWluc3QgdGhlIFJvdXRlDQogICAgT3JpZ2luIEFT TiBhcyBkZXRlcm1pbmVkIGJ5IGFwcGx5aW5nIHRoZSBwcm9jZWR1cmUgaW4gW1JGQzY4MTEsDQog ICAgU2VjdGlvbiAyXSB0byB0aGUgQVNfUEFUSCAoc2VlIFJGQyA0MjcxIDQuMyBQYXRoIEF0dHJp YnV0ZXM6YikgdGhhdA0KICAgIGl0IHdpbGwgc2VuZCBpbiB0aGUgVVBEQVRFIHRvIHRoZSBwZWVy Lg0KDQpDaGVlcnMsDQoNCkJlbg0KDQo= From nobody Fri Mar 20 09:10:59 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 31DAF3A0C4F; Fri, 20 Mar 2020 09:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no 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 pDXOJX6Z1INf; Fri, 20 Mar 2020 09:10:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 066113A0C6F; Fri, 20 Mar 2020 09:09:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jFKCc-0003jK-9i; Fri, 20 Mar 2020 16:08:54 +0000 Date: Fri, 20 Mar 2020 09:08:53 -0700 Message-ID: From: Randy Bush To: Ben Maddison Cc: "job@ntt.net" , "nick@foobar.org" , "last-call@ietf.org" , "ops-dir@ietf.org" , "linda.dunbar@futurewei.com" , "sidrops@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" In-Reply-To: <55f529777e4524b2ac2f6f94c0955611d04aa250.camel@workonline.africa> References: <158448201565.32201.9748655174984394118@ietfa.amsl.com> <624bd5c7-5459-64c2-5694-b77dde5835a6@foobar.org> <20200318012635.GE77479@vurt.meerval.net> <55f529777e4524b2ac2f6f94c0955611d04aa250.camel@workonline.africa> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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: Fri, 20 Mar 2020 16:10:58 -0000 >>> BGP implementations have to take removal of private AS(s), >>> confederation, AS migration, etc into consideration. >> >> and the winds of summer. we do not need to enumerate all knobs, as >> if we could. >> > But enumerating *some* helps the reader understand the context in which > this is important/useful. which is why When applied to egress policy, the effective origin AS MUST be used to determine the Origin Validation state. The effective origin AS is that which will actually be the origin AS in the announcement. It might be affected by removal of private AS(s), confederation, AS migration, etc. randy From nobody Fri Mar 20 09:34:07 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 3A3AF3A0CFA for ; Fri, 20 Mar 2020 09:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 iXJqwQagow6Y for ; Fri, 20 Mar 2020 09:33:58 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 99C933A0CFE for ; Fri, 20 Mar 2020 09:33:57 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id q19so7061761ljp.9 for ; Fri, 20 Mar 2020 09:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d4O1x5llrFNLPqJ5M5VP3E9wLcdE6cCnamQuvGRgtbI=; b=svqMef3cOA3we1m8qjEEymLbyB6ryxmbWUyDfuBv5NCsf55rGp3YQiShPXlBFua5SG w9xUpukyCTi3iHljTTNu0cCKjXDzJUB0OCmQnD0V6d1Md4SMnvIflWaXVfp0AQ+kTy5c GgtjnIcIyTaG3gq+4ORhjGJOyjguBUGLB7acn8wQhiIq/lzRxcU3PteoZzOcWawxQaAh BNpwsO+cx2ZqObZtQccBLcX2MR6WV2WitRHUkCtl/VTOgJqgHYHuWL/jjVvbSj9w4Ujn Aued39r8uouZ4rkK+BV/geJmodCi0D4ecWCcZiXfBlof+xGz2pJY3/n9meM/KAiIeBTs CU0g== 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=d4O1x5llrFNLPqJ5M5VP3E9wLcdE6cCnamQuvGRgtbI=; b=jgHD1mceauG9U4HkhFAUUHEcdnCKHABl+wUUKrK8eaE1TYEOwgvnBJuvd3y8c7XzwE 5udJ4OOODZA1QosjuAD2McoVeVCCOnUxCrXzF1m2SCFn/Jgh2YGuRxRzZSbQ48qU5hFf Lg9yrKMQsbWHeso3CHWwjge66UlXgcsvDb2QVyL8whbickK+zlcbojYwIy8vVL5SHaxO xgGbYBCG2o1ItJGFB0OnvCFYWBcGiOJnWkqXmozrHCxAxFWx1UUVwQVmehbmrD4r2+63 Qge4gboQyQMG3eJzq3J0TiwHeNwS+Ul75ze92KGg08isUTW7+2eXH42UHvpM1bUtA2QK 8pkg== X-Gm-Message-State: ANhLgQ39UVfgGqnz4UZohvusnpp5baiz/ZELgI1yNU/wS1Quo4C23NsA SrxHkN1lF8YW8u3iqihxdDN3Of+KLVZ3HCVkE+3Qe113Ws3kLQ== X-Google-Smtp-Source: ADFU+vuokWRlP94RT3BEm4Mwp7x2CE80KHB9mPYANfCsAswnD9YrDo2GEciEgYJFB5NVb0Bq+hii2bt8BBIkXALz4M8= X-Received: by 2002:a2e:a0cd:: with SMTP id f13mr5826171ljm.198.1584722035405; Fri, 20 Mar 2020 09:33:55 -0700 (PDT) MIME-Version: 1.0 References: <158448201565.32201.9748655174984394118@ietfa.amsl.com> <624bd5c7-5459-64c2-5694-b77dde5835a6@foobar.org> <20200318012635.GE77479@vurt.meerval.net> <55f529777e4524b2ac2f6f94c0955611d04aa250.camel@workonline.africa> In-Reply-To: From: Warren Kumari Date: Fri, 20 Mar 2020 12:33:19 -0400 Message-ID: To: Randy Bush Cc: Ben Maddison , "job@ntt.net" , "nick@foobar.org" , "last-call@ietf.org" , "ops-dir@ietf.org" , "linda.dunbar@futurewei.com" , "sidrops@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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: Fri, 20 Mar 2020 16:34:01 -0000 On Fri, Mar 20, 2020 at 12:11 PM Randy Bush wrote: > > >>> BGP implementations have to take removal of private AS(s), > >>> confederation, AS migration, etc into consideration. > >> > >> and the winds of summer. we do not need to enumerate all knobs, as > >> if we could. > >> > > But enumerating *some* helps the reader understand the context in which > > this is important/useful. > > which is why > > When applied to egress policy, the effective origin AS MUST be used > to determine the Origin Validation state. The effective origin AS is > that which will actually be the origin AS in the announcement. It > might be affected by removal of private AS(s), confederation, AS > migration, etc. > One of the things that I personally like most about this document is that it concise - it clarifies something for *implementors* to keep in mind / points out something where they might trip over something and hurt themselves. While I generally like examples and detail in RFCs, in this case it would be "teaching your grandmother to suck eggs"[0] - the readers in this case are folk who write BGP, the document basically says "Warning: sharp object, careful with fingers" - having too much detail decreases the utility in this case. Again, I generally agree that documents should enumerate all of the corner cases, have examples, etc - but in this case I think it would do more harm than good... W [0]: https://en.wikipedia.org/wiki/Teaching_grandmother_to_suck_eggs > randy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Mar 20 11:30:13 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 561AB3A0D9A; Fri, 20 Mar 2020 11:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 koaG9c0TsGyH; Fri, 20 Mar 2020 11:29:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 8DBE43A0DC9; Fri, 20 Mar 2020 11:29:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jFMOq-0004IO-Np; Fri, 20 Mar 2020 18:29:40 +0000 Date: Fri, 20 Mar 2020 11:29:39 -0700 Message-ID: From: Randy Bush To: Ben Maddison Cc: "keyur@arrcus.com" , "last-call@ietf.org" , "rjsparks@nostrum.com" , "sidrops@ietf.org" , "gen-art@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" In-Reply-To: <37beff1136180992cc9b1a209cd5880a9db0dbff.camel@workonline.africa> References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> <5A210359-FE01-40BF-9BAD-E0250BB31BFC@arrcus.com> <37beff1136180992cc9b1a209cd5880a9db0dbff.camel@workonline.africa> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Fri, 20 Mar 2020 18:30:02 -0000 > Although a little more verbose, perhaps the following is more explicit? > > As the origin AS of a BGP UPDATE is decided by configuration and > outbound policy of the BGP speaker, a validating BGP speaker MUST > apply Route Origin Validation policy semantics Against the Route > Origin ASN as determined by applying the procedure in [RFC6811, > Section 2] to the AS_PATH (see RFC 4271 4.3 Path Attributes:b) that > it will send in the UPDATE to the peer. i am torn about adding yet another 6811 ref. does it clarify anything? are there other possible "Route Origin Validation policy semantics?" if so, i might put it earlier, after "apply Route Origin Validation policy semantics". randy From nobody Fri Mar 20 11:39:16 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 8BEF93A0C0E; Fri, 20 Mar 2020 11:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 uwk5FbjEKIU3; Fri, 20 Mar 2020 11:38:18 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::624]) (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 4CDB43A0BF9; Fri, 20 Mar 2020 11:38:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KaAn8Q7C6PZdX3odYs+uEUAGt/JIcL2lECkwKT0rre1PcVmL9P58g5jFgOEcQC3i5lY83Xye1ZtXaaLws6xYmEJp9Al+/XylSAz61DXSQsF7Q2stVs+ZQc97KbI15OkSyuVsusJNxOln86CSKIEeLFhLDZg775Ql2xVxcZ1FWnMoXHVGWWZ+UdJP79uwR0oT9E/w5eO8HtlgdJQKMnSxqYq1EHVQzlMLNxXOi/L14j8VITNfG4oLonK6+R8UqfTbXv16L9ENJwfZViBIbb7gx7JXLVkI+6VYHvHhCl93CB1Aw50WL9rbF2nJZDa8ISr08sac3K3PdlHD2qA0Q9nMcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F+5gap2S2MVYlyZGFdpnAkBUxBt441iNznJvcdotVw4=; b=XSe+fqcPq9UKL6cD+qWcsu2UWriuLYUmddfjABEbkD2RI76ENtHhWmYJLFCJrLB6QTHWhXUp8bsSuAI15N7JwAX2CaPO/19RzHRSOMrCVI2loYGzChN6DaFn1C1hyvwHArD7ToWe85H3aNoLWlxghp59n8YBd1x+B58PvvZ9FtLIl/uhF2h/T1blirb83OmBSBcrq3i6X4TnFQm4KRDGOEQq+N/32Uj4pOANjbtDEJSVXyz/FukjYPecSC465+XlathMaHFsmC7JdJ/KpZSnxQjxitCPItHyIm3VS7EQ8R/QgkBYAgbImqc888fCV2fshgu+tL7nJCTbLFJBLvgoSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F+5gap2S2MVYlyZGFdpnAkBUxBt441iNznJvcdotVw4=; b=YB1VUNo9E+k57jGIJDI14a8z73Mb0Yqqy3haCI6BP60wpl6dPkhdUkQgQfd8XpdMAiEHq594HC/qcGTKgUG+zhyrTytzevJvqrOp4MqFI0dDqS5WL5j5bxOuk9DmH1fXwsPzheI8xCVGCV4xzhXcQAwad9XFgnfMYYAfViJ/tMs= Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (52.135.56.21) by AM7P190MB0645.EURP190.PROD.OUTLOOK.COM (52.135.59.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20; Fri, 20 Mar 2020 18:38:00 +0000 Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252%7]) with mapi id 15.20.2814.025; Fri, 20 Mar 2020 18:38:00 +0000 From: Ben Maddison To: Randy Bush CC: "keyur@arrcus.com" , "last-call@ietf.org" , "rjsparks@nostrum.com" , "sidrops@ietf.org" , "gen-art@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" Thread-Topic: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 Thread-Index: AQHV/VAnBdRzgu0rVUGGU8YdM7o2yKhOw/8AgAKBKwCAAIs9gIAAAKmn Date: Fri, 20 Mar 2020 18:38:00 +0000 Message-ID: References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> <5A210359-FE01-40BF-9BAD-E0250BB31BFC@arrcus.com> <37beff1136180992cc9b1a209cd5880a9db0dbff.camel@workonline.africa>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa; x-originating-ip: [160.119.236.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ab3d3bec-7a9d-4977-ba50-08d7ccfdd0ff x-ms-traffictypediagnostic: AM7P190MB0645: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 03484C0ABF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400004)(396003)(136003)(366004)(376002)(346002)(199004)(6506007)(186003)(26005)(52536014)(81166006)(7696005)(81156014)(8676002)(5660300002)(6916009)(4326008)(8936002)(54906003)(55016002)(33656002)(316002)(76116006)(9686003)(45080400002)(508600001)(53546011)(66446008)(64756008)(66556008)(66476007)(66946007)(2906002)(71200400001)(86362001)(91956017)(46492006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P190MB0645; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: enToL/VtZwqBrgUi++3SjygVosNiTg0qXTO9GFjHqOanZ9vcvQTyELfYg9xUJjUSWp0zu8eyc61nAtNa/+xWZ6zXsckDsOgExr0WKamc50djn0W8SGqVgkp+k3epqVrD5UK4QgQNqNUz3wUZPicYT5+kfWUl43JAy1TmtQCXHGWpUt1UG1pBu2jposY8yeXOBVCVyDYOA6WgiH6zjdo0Rv479ngsTGqyJ3RNU90uFUeemqjrHnqcsAt6v/29MzlCcoNSeiVnrQ5zNaxQLotyLqRmUXqRx9EYFgs91+WYKRhbx/bKxUfIjyD8z8NhRNz47Nxdcx3BROwEwXLs0XKNM7myDmNOAAD9F7+6h7EFgr8Nza1qvufcA/Ly/J9EqCg8SMW8KgVrcw5j8xrgkZ7iVzs49b8ZY8SlqaCLFWMc8UInGczUakgNfW2EVgtPiiapWl42GvhFa/OeuEML0LxEDeg2foe+Q0BiefPB2dHGNd5CH9h8EtjsWRe1ctrHlmjZuxVQpkQ2BwHQlagKojTh0WiU9ou8UBEN6Iv0OoJM3K1Dlj4IJQ0gPL4+UOV6KtVt x-ms-exchange-antispam-messagedata: S95VQm57MP8V5q+aQqM/qVC9QuSxCJEET/VmKs6h3JUrDpHbVxt/Gnyv59KSq1SGqXGWcrTH4nTSWQEveDch2jKZLcqtMxt6jYB/pHXZqJ75BKtoWg9h2CdZ7dDaSXVNuJiENNm0uUQ39/KPpWby+w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM7P190MB0583F202651B4DC877893D57C0F50AM7P190MB0583EURP_" MIME-Version: 1.0 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: ab3d3bec-7a9d-4977-ba50-08d7ccfdd0ff X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2020 18:38:00.0331 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6Bl24as8T2/0eK0X+AO97mFna407zkybSjE8yDTtK4Tka11sZ8zoXSmr/ZtkLaB97egagLDbXzC+RqpuT24uAA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0645 Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Fri, 20 Mar 2020 18:38:25 -0000 --_000_AM7P190MB0583F202651B4DC877893D57C0F50AM7P190MB0583EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It doesn't clarify anything for me, but then I happen to know where that al= gorithm is defined. Having spend the better part of last week stepping a vendor through exactly= these semantics, my current mood is that explicit and specific is better. The intent in having the ref where it is, is to point at the AS_PATH =3D> O= rigin As mapping procedure, rather than that section more generally. Cheers, Ben Get Outlook for Android ________________________________ From: Randy Bush Sent: Friday, 20 March 2020, 20:29 To: Ben Maddison Cc: keyur@arrcus.com; last-call@ietf.org; rjsparks@nostrum.com; sidrops@iet= f.org; gen-art@ietf.org; draft-ietf-sidrops-ov-egress.all@ietf.org Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egr= ess-01 > Although a little more verbose, perhaps the following is more explicit? > > As the origin AS of a BGP UPDATE is decided by configuration and > outbound policy of the BGP speaker, a validating BGP speaker MUST > apply Route Origin Validation policy semantics Against the Route > Origin ASN as determined by applying the procedure in [RFC6811, > Section 2] to the AS_PATH (see RFC 4271 4.3 Path Attributes:b) that > it will send in the UPDATE to the peer. i am torn about adding yet another 6811 ref. does it clarify anything? are there other possible "Route Origin Validation policy semantics?" if so, i might put it earlier, after "apply Route Origin Validation policy semantics". randy --_000_AM7P190MB0583F202651B4DC877893D57C0F50AM7P190MB0583EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It doesn't clarify anything for me, but then I happen to know where that al= gorithm is defined. 

Having spend the better part of last week stepping a vendor through exactly= these semantics, my current mood is that explicit and specific is better.&= nbsp;

The intent in having the ref where it is, is to point at the AS_PATH =3D>= ; Origin As mapping procedure, rather than that section more generally.&nbs= p;

Cheers, 

Ben

From: Randy Bush <randy@psg.c= om>
Sent: Friday, 20 March 2020, 20:29
To: Ben Maddison
Cc: keyur@arrcus.com; last-call@ietf.org; rjsparks@nostrum= .com; sidrops@ietf.org; gen-art@ietf.org; draft-ietf-sidrops-ov-egress.all@= ietf.org
Subject: Re: [Sidrops] Genart last call review of draft-ie= tf-sidrops-ov-egress-01

> Although a little more verbose, perhaps the f= ollowing is more explicit?
>
>     As the origin AS of a BGP UPDATE is decided by= configuration and
>     outbound policy of the BGP speaker, a validati= ng BGP speaker MUST
>     apply Route Origin Validation policy semantics= Against the Route
>     Origin ASN as determined by applying the proce= dure in [RFC6811,
>     Section 2] to the AS_PATH (see RFC 4271 4.3 Pa= th Attributes:b) that
>     it will send in the UPDATE to the peer.

i am torn about adding yet another 6811 ref.  does it clarify anything= ?
are there other possible "Route Origin Validation policy semantics?&qu= ot;

if so, i might put it earlier, after "apply Route Origin Validation policy semantics".

randy

--_000_AM7P190MB0583F202651B4DC877893D57C0F50AM7P190MB0583EURP_-- From nobody Fri Mar 20 11:43: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 75D013A0BF9; Fri, 20 Mar 2020 11:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 RAbJZklxXox3; Fri, 20 Mar 2020 11:42:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 27DD83A0BF6; Fri, 20 Mar 2020 11:42:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jFMbY-0004MS-K2; Fri, 20 Mar 2020 18:42:48 +0000 Date: Fri, 20 Mar 2020 11:42:47 -0700 Message-ID: From: Randy Bush To: Ben Maddison Cc: "keyur@arrcus.com" , "last-call@ietf.org" , "rjsparks@nostrum.com" , "sidrops@ietf.org" , "gen-art@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" In-Reply-To: References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> <5A210359-FE01-40BF-9BAD-E0250BB31BFC@arrcus.com> <37beff1136180992cc9b1a209cd5880a9db0dbff.camel@workonline.africa> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Fri, 20 Mar 2020 18:42:54 -0000 > Having spend the better part of last week stepping a vendor through > exactly these semantics while there is no proof of termination of clue insertion, that a BGP/ROV *implementor* did not get it, justifies the hack. As the origin AS of a BGP UPDATE is decided by configuration and outbound policy of the BGP speaker, a validating BGP speaker MUST apply Route Origin Validation policy semantics (see [RFC6811] Sec 2) against the origin Autonomous System number which will actually be put in the AS_PATH (see [RFC4271] 4.3 Path Attributes:b) of the UPDATE to the peer. From nobody Fri Mar 20 11:47:57 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 0EC983A0D8B; Fri, 20 Mar 2020 11:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 wDunwmgTKCFr; Fri, 20 Mar 2020 11:47:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 199BF3A0D58; Fri, 20 Mar 2020 11:47:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jFMgA-0004Nr-0V; Fri, 20 Mar 2020 18:47:34 +0000 Date: Fri, 20 Mar 2020 11:47:33 -0700 Message-ID: From: Randy Bush To: Ben Maddison Cc: "keyur@arrcus.com" , "last-call@ietf.org" , "rjsparks@nostrum.com" , "sidrops@ietf.org" , "gen-art@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" In-Reply-To: References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> <5A210359-FE01-40BF-9BAD-E0250BB31BFC@arrcus.com> <37beff1136180992cc9b1a209cd5880a9db0dbff.camel@workonline.africa> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Fri, 20 Mar 2020 18:47:51 -0000 > As the origin AS of a BGP UPDATE is decided by configuration and > outbound policy of the BGP speaker, a validating BGP speaker MUST > apply Route Origin Validation policy semantics (see [RFC6811] Sec 2) > against the origin Autonomous System number which will actually be > put in the AS_PATH (see [RFC4271] 4.3 Path Attributes:b) of the > UPDATE to the peer. actually, 8481 sec 4 might be a stronger hammer. whatcha think? From nobody Fri Mar 20 11:49:15 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 46F033A0BF0 for ; Fri, 20 Mar 2020 11:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no 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 1G79hNOOtXl2 for ; Fri, 20 Mar 2020 11:48:55 -0700 (PDT) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 107383A0DBE for ; Fri, 20 Mar 2020 11:48:54 -0700 (PDT) Received: by mail-wm1-f50.google.com with SMTP id 26so3705015wmk.1 for ; Fri, 20 Mar 2020 11:48:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ewXB2ta4CPdTI/xr6fbnEAUkekoBM2N3PnoOaMgDwwE=; b=gBXUgvXctdQ5znynQht0zp3FgeHfUCZ+qPpTUpssjVJIfmxj7jHCDJYHauqnBp66AH Yo3sY/RBg1pFRxfqIkbPJPv/TKvavL9Gam4D/8zk3yLYgNqUT4JmsoFLZh1w30dL9jqZ vS5PBuVLOml4FRX/JvqFMScnMMTa9chNlxCXHafD7u7S2otd/61/lNDQK0JyZzU5KHWZ tR6KNt1XUOWLLm/fLrMg7tkeM5L0pA24rrZXxMaMJlS1oMn/j4g35qV6knXt8qZG9Ct/ YkpHJQxdTXBDu76ZN0GYTrxtBCl7rr1Ptr6nica5HpckV4MhX5DxOIgp9uOGBGubzzy7 cr1Q== X-Gm-Message-State: ANhLgQ2rSSgONlP1LNld1Fa1kXL1AzxC94f4CvWwqxo8avxPwPkLuG6W doi2jDGtCx7mtw60mtgTcqo76E+J8Dg= X-Google-Smtp-Source: ADFU+vsSiGeuoa8QTrICOW6eo9htDfJ0aFnRDKSeXntYsn5rzg6sWb39kZK/PMaiUV8s6ppRK1Uvyw== X-Received: by 2002:a05:600c:2283:: with SMTP id 3mr10281423wmf.157.1584730132768; Fri, 20 Mar 2020 11:48:52 -0700 (PDT) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id o26sm8300367wmc.33.2020.03.20.11.48.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Mar 2020 11:48:52 -0700 (PDT) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 84c74268; Fri, 20 Mar 2020 18:48:51 +0000 (UTC) Date: Fri, 20 Mar 2020 18:48:51 +0000 From: Job Snijders To: Randy Bush Cc: Ben Maddison , "keyur@arrcus.com" , "sidrops@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" , "last-call@ietf.org" , "gen-art@ietf.org" , "rjsparks@nostrum.com" Message-ID: <20200320184851.GD17523@vurt.meerval.net> References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> <5A210359-FE01-40BF-9BAD-E0250BB31BFC@arrcus.com> <37beff1136180992cc9b1a209cd5880a9db0dbff.camel@workonline.africa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] [Last-Call] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Fri, 20 Mar 2020 18:49:08 -0000 On Fri, Mar 20, 2020 at 11:42:47AM -0700, Randy Bush wrote: > > Having spend the better part of last week stepping a vendor through > > exactly these semantics > > while there is no proof of termination of clue insertion, that a BGP/ROV > *implementor* did not get it, justifies the hack. > > As the origin AS of a BGP UPDATE is decided by configuration and > outbound policy of the BGP speaker, a validating BGP speaker MUST > apply Route Origin Validation policy semantics (see [RFC6811] Sec 2) > against the origin Autonomous System number which will actually be > put in the AS_PATH (see [RFC4271] 4.3 Path Attributes:b) of the > UPDATE to the peer. Looks good to me. Kind regards, Job From nobody Fri Mar 20 12:27:06 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 413B83A0D84; Fri, 20 Mar 2020 12:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 Z9Zz0-UoNGNI; Fri, 20 Mar 2020 12:26:48 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80057.outbound.protection.outlook.com [40.107.8.57]) (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 7B4A53A0D7C; Fri, 20 Mar 2020 12:26:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bWqJXxtO+c9mJRFupUrSF0LRAPP23wkPxf3k6afL5Abkcjfkocx/JlZk8ORHw8ASZ5YHE1W8DXgXs1CfE3z9IGArSikflxtUDyEqg3lWB05WllbUmzkTUiY/TNFup423pRChI5Wex+mDP6/9GZzcndojGN6ZIyjx7OJ78whGPi56tDiNdECOktrx368dqZL+7WvxYy+Kt6faSDMP2R9VF8tgX3+MCGCmu5jJFqGdAeiSqNNoSdHp8xNHRUJQm3+YfAoQ37+hzdeewf29LYWDWxtSw+56N84UtX0UH+yu5GOySML3Mw7JNdfFn57Bv3B2NPkXyXGjXS2FuqNgkWMI6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ep4Rjgt2OgbScGYfBlgG8j7rUEinZAS06N6dWVPQP4g=; b=oTznBKyyqddLxXND8zPRZt0nP2I/UaXQMl2rlGn372UYpL7gGBuB4/j2FB5CK2aVtPTwjv6jR69B0Gq2VhZ1eaX98meXIHRq2p9xYvWZHjskbYdwTnvKRFlpnQkOjWf3wbNH2/z3o567D7ZOtKl+s/qvOVos96ALhi7joHGPO05wKuGAkZvOomokICET9eIIrAqwF1dC7sI38ZCqwbeyjDuWlV3/GEUDtWp/3h9I6xdzPsj+91pzjdMKpKSweHGKkS+Sicm/e5C/IQn+8czdvVDCrUiqR5mzoULll9YmaHMhRR62IJSV/hICz3I1IYG6p1noONJqmv+Oc7+0eyK8Cg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ep4Rjgt2OgbScGYfBlgG8j7rUEinZAS06N6dWVPQP4g=; b=Y2zAgHF+IuVxwwP2iUTD0nQG9t5d2rbks91jaF2tmWtq7BsKbpRJ4G0y0EUBawqelw/B+OEaaAMKuqLUdJIG4wSQ1RQ+1P9zXG6K5e+0aedqktTABFoZaNFfGcHAbal0wEHWTHnPwxu/yCL+nW6e7McJ+qaXckTxOp6n8AvWEqQ= Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (52.135.56.21) by AM7P190MB0648.EURP190.PROD.OUTLOOK.COM (52.135.58.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20; Fri, 20 Mar 2020 19:26:37 +0000 Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252%7]) with mapi id 15.20.2814.025; Fri, 20 Mar 2020 19:26:36 +0000 From: Ben Maddison To: Randy Bush , Job Snijders CC: "keyur@arrcus.com" , "sidrops@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" , "last-call@ietf.org" , "gen-art@ietf.org" , "rjsparks@nostrum.com" Thread-Topic: [Last-Call] [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 Thread-Index: AQHV/VAnBdRzgu0rVUGGU8YdM7o2yKhOw/8AgAKBKwCAAIs9gIAAAKmngAADAoCAAAGygIAACaSa Date: Fri, 20 Mar 2020 19:26:36 +0000 Message-ID: References: <158411258778.3418.757369789772046254@ietfa.amsl.com> <933a9d0d-319e-f6fb-4d02-82e27bb00509@nostrum.com> <5A210359-FE01-40BF-9BAD-E0250BB31BFC@arrcus.com> <37beff1136180992cc9b1a209cd5880a9db0dbff.camel@workonline.africa> ,<20200320184851.GD17523@vurt.meerval.net> In-Reply-To: <20200320184851.GD17523@vurt.meerval.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa; x-originating-ip: [160.119.236.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4872ab2c-3504-45de-0ae7-08d7cd049b8f x-ms-traffictypediagnostic: AM7P190MB0648: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2657; x-forefront-prvs: 03484C0ABF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(39840400004)(136003)(366004)(199004)(5660300002)(6506007)(53546011)(55016002)(71200400001)(2906002)(9686003)(81166006)(81156014)(508600001)(66446008)(8936002)(45080400002)(64756008)(66556008)(91956017)(76116006)(86362001)(54906003)(26005)(186003)(110136005)(8676002)(316002)(66946007)(52536014)(4326008)(66476007)(7696005)(33656002)(46492006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P190MB0648; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2FjZ7Z6hdpbBoAL4CS5wyR1O1e/pOBU3mpvR8dlZJ6ZL/J+w4LUbutUcQuj0cfAp0RnBuj+SJT3ecrg2Zvqk74scnw5tCjAnuUibj+M20aHRtIsFol+JM2xlXnxq0IewwUNr2QIfBAvcnsVIxvDAiMT7LfDAOIdUMEo5Oavp+f8uRn/hlBJXiPA279ie8F9m/OddHuXmY7hDHU/JE/3JQHAW7hpE/uA6SgLrRVzpLqZsnFvMdkKfuS2MIWR4ZWIKPPwzIiPcZ7yARefCtCoWG+TWUnvgvaglxGH3QK+xEuo+pu9+f1ap+TxNsNr4vpyLL4FQgDC0cjHcAUJceZT56rybLcrlfkjuf87cmBoFhOaHeYuXWp/3z8jGkxGFfOoQqSeay3Q9f0Oobj3x6OlkOT7dNHmNRSPaioxoOanGk4Er2h5oOtf5kojmgZogVEn267pt4aHicL2dS4fRTFbSkpJep57sJke+I6peyQLBBj/Vdrjvwv8szUMLN6Jcvi1ncADsncXJmle5ailQqtqzLQII69+xthvWdnmtHugZJ9IhOn6vvt2Jvxwx2KYUieuv x-ms-exchange-antispam-messagedata: PdWzHvgi+J7m4/L661gX/IotXvVNY4C8/2Yf0UAqHQWGqaElqg6bJeZhUZIV/RQtaPLMdCANeGM3driy7MMYXIhNlFt+Mqyp6atG3ebEWduYBi401K0GJlfvf3oFIMmtZnEVZHCcNshAD+aUBQkIXQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM7P190MB058396E044389A306B8B5CAEC0F50AM7P190MB0583EURP_" MIME-Version: 1.0 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 4872ab2c-3504-45de-0ae7-08d7cd049b8f X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2020 19:26:36.9322 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wvKyHvCMgCN4eHoY2L7MNQ/himgvqEcTU9EOLnInUUHN/Q0ROWXFL90yjmuJUrF4nPY6jg+vGlW1isP+m5UIqg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0648 Archived-At: Subject: Re: [Sidrops] [Last-Call] Genart last call review of draft-ietf-sidrops-ov-egress-01 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: Fri, 20 Mar 2020 19:26:52 -0000 --_000_AM7P190MB058396E044389A306B8B5CAEC0F50AM7P190MB0583EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think 6811 is the right ref for this. 8481 is the one you put in an RFP ;= -) I still prefer my wording, but this should be sufficiently hard to misinter= pret. Get Outlook for Android ________________________________ From: Job Snijders Sent: Friday, March 20, 2020 8:48:51 PM To: Randy Bush Cc: Ben Maddison ; keyur@arrcus.com ; sidrops@ietf.org ; draft-ietf-sidrops-ov-egress.all@= ietf.org ; last-call@ietf.org ; gen-art@ietf.org ; rjsparks@nostrum.c= om Subject: Re: [Last-Call] [Sidrops] Genart last call review of draft-ietf-si= drops-ov-egress-01 On Fri, Mar 20, 2020 at 11:42:47AM -0700, Randy Bush wrote: > > Having spend the better part of last week stepping a vendor through > > exactly these semantics > > while there is no proof of termination of clue insertion, that a BGP/ROV > *implementor* did not get it, justifies the hack. > > As the origin AS of a BGP UPDATE is decided by configuration and > outbound policy of the BGP speaker, a validating BGP speaker MUST > apply Route Origin Validation policy semantics (see [RFC6811] Sec 2) > against the origin Autonomous System number which will actually be > put in the AS_PATH (see [RFC4271] 4.3 Path Attributes:b) of the > UPDATE to the peer. Looks good to me. Kind regards, Job --_000_AM7P190MB058396E044389A306B8B5CAEC0F50AM7P190MB0583EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I think 6811 is the right ref for this. 8481 is the one you put in an RFP ;= -)

I still prefer my wording, but this should be sufficiently hard to misinter= pret.

From: Job Snijders <job@= ntt.net>
Sent: Friday, March 20, 2020 8:48:51 PM
To: Randy Bush <randy@psg.com>
Cc: Ben Maddison <benm@workonline.africa>; keyur@arrcus.com &l= t;keyur@arrcus.com>; sidrops@ietf.org <sidrops@ietf.org>; draft-ie= tf-sidrops-ov-egress.all@ietf.org <draft-ietf-sidrops-ov-egress.all@ietf= .org>; last-call@ietf.org <last-call@ietf.org>; gen-art@ietf.org <gen-art@ietf.org>; rjsparks@nostrum.com <rjsparks@nostrum.com>= ;
Subject: Re: [Last-Call] [Sidrops] Genart last call review of draft-= ietf-sidrops-ov-egress-01
 
On Fri, Mar 20, 2020 at 11:42:47AM -0700, Randy Bu= sh wrote:
> > Having spend the better part of last week stepping a vendor throu= gh
> > exactly these semantics
>
> while there is no proof of termination of clue insertion, that a BGP/R= OV
> *implementor* did not get it, justifies the hack.
>
>    As the origin AS of a BGP UPDATE is decided by confi= guration and
>    outbound policy of the BGP speaker, a validating BGP= speaker MUST
>    apply Route Origin Validation policy semantics (see = [RFC6811] Sec 2)
>    against the origin Autonomous System number which wi= ll actually be
>    put in the AS_PATH (see [RFC4271] 4.3 Path Attribute= s:b) of the
>    UPDATE to the peer.

Looks good to me.

Kind regards,

Job
--_000_AM7P190MB058396E044389A306B8B5CAEC0F50AM7P190MB0583EURP_-- From nobody Sat Mar 21 00:59:41 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 1A21F3A0C34; Sat, 21 Mar 2020 00:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa 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 KvzAk3gWhYwj; Sat, 21 Mar 2020 00:59:19 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2075.outbound.protection.outlook.com [40.107.21.75]) (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 64A4C3A012A; Sat, 21 Mar 2020 00:59:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LEzmSYeVpyn+n0mxwiBcN77Ru8eje2iCbzweo7vwvTnk0YgRx3LRotd5h3B+zIt0WZ8/RRZzfQGc4huf2e912KlpC/lrzeY3fUM57BoLFF+r5OnG2l0KJBeJA8vK7YP18ny73st5I1bEk3bPWdAt3XFDYa6fbJdChgB7+NIrVeUD6PaoX0Ip+G44FTt14mcgzWPtgvgV0hGX8oM6xJ0RvT75MNmhFmItdl5ZeljQ+rTtfUeNbPORpzuY+md9jBRIb09J/6qPJLwiV8+lzy7R5O8hvZ95rdUY7ZBJ0uKHOTl7TNvXEtx7YxfA4yN9Nxe9/Bj9+N1nM0mXEmD06jnB3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M18C1WInZIKHJ+CeNUgbhX8KDrmHDEuzAHPYi8MODjY=; b=YYR9tUJ18SqOLprntv2awzhU2FA36EMD4KSEKR9oDFY4AGU2k/DsZBLiOeUarX+30jYHTK52YcBzswrUOBul4s8Ry+X8JBsMb1b3wmcv99ANEUPDb5FvRP/Hcj9PMM28FtqptuJ2DOfwnZq+4yw+mbBjkPNo8CmV5jvmgr+1HLcWtmuEWa6+hLtnXL9Xj1QAPF1o3IipV64vf3vcvB+FpxotoRIaTl5YwMmcdGVOyY+EQxQw+GsL9q3/VXuwVDIA0r7wCrIu8NRuPHBlQ0bOAWT+TxyFepB7p7490WEDtwnCbeU5tG9xePLHn6b/JapgyM4LGgHxY02esGE3JJKKoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M18C1WInZIKHJ+CeNUgbhX8KDrmHDEuzAHPYi8MODjY=; b=OtUiHThCFfTvv35TneTaYiociD9UZ3irgxckCE7JdyGntdKBtXNy2bCg+NbH+ttp/EdEbg9wv7bAZ3++9CtqsZdJjA9jOam2XS83v3HXs80s6CdfnHz+2kpyOcJP6+W5WtwUPh/HhTgYJCF0tN8L861/epAwKa5R9XNNGN/rSI8= Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (52.135.56.21) by AM7P190MB0742.EURP190.PROD.OUTLOOK.COM (52.135.59.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20; Sat, 21 Mar 2020 07:59:12 +0000 Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::994a:aedb:e28a:2252%7]) with mapi id 15.20.2814.025; Sat, 21 Mar 2020 07:59:12 +0000 From: Ben Maddison To: "randy@psg.com" , "warren@kumari.net" CC: "nick@foobar.org" , "job@ntt.net" , "last-call@ietf.org" , "ops-dir@ietf.org" , "linda.dunbar@futurewei.com" , "sidrops@ietf.org" , "draft-ietf-sidrops-ov-egress.all@ietf.org" Thread-Topic: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 Thread-Index: AQHV/Kb2XJdSWmlaN0iV0dnimUseQ6hNg3WAgAALw4CAAAK9gIADsLgAgABnuICAAAbTgIABAq2A Date: Sat, 21 Mar 2020 07:59:12 +0000 Message-ID: References: <158448201565.32201.9748655174984394118@ietfa.amsl.com> <624bd5c7-5459-64c2-5694-b77dde5835a6@foobar.org> <20200318012635.GE77479@vurt.meerval.net> <55f529777e4524b2ac2f6f94c0955611d04aa250.camel@workonline.africa> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa; x-originating-ip: [160.119.236.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 16d3c8e6-dbee-48dc-9b1f-08d7cd6dbe71 x-ms-traffictypediagnostic: AM7P190MB0742: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:295; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(39840400004)(366004)(136003)(199004)(6512007)(2906002)(91956017)(66476007)(66946007)(76116006)(64756008)(186003)(6486002)(81166006)(26005)(86362001)(81156014)(2616005)(8936002)(5660300002)(316002)(66556008)(66446008)(966005)(8676002)(4326008)(6506007)(53546011)(54906003)(71200400001)(508600001)(110136005)(46492006)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7P190MB0742; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bNsDblJK61+MxtqxhGIsnAaZz7MZ4Tn8IZ3qrXV04YQhsY0CicqhIO7cb6tlTEnvzHHPfGMTlM2VUxkShXBgQBwOCsbQT4wzvqFSofW4cixH/RoxxzHhoY8QTD2C4sbNVVYLTdFOUikr8vbIbS6KBp2zeTjVic0F6yQ7Rl+jK9GRvtKqP157xO/Hm5dHFOWNERiC4nkl4/OUSEq2bonxH2AeCPh7e4B24o6ngOznRAmuJwv6VwejFBbVYB0vBF9s1lj2PYUpr8x6W+ZL05kQswn7FXq+n5iRbVlrf0zFU2dZxZkvLMBeva27xir/jmYJRg1aDHTI7w0b/9PWA1XopMi5GLiaIAfgUhPnIf6jbmJcE+vgowWroY5+ZC54cp+NVgknhexAOq43iDzXqNyqVXTk0Vlnk4i55Q5eP2alfyDR1EUP+obBiIQ2NY2XofgQZPMI7UgDvl7MVQCaq6AuHs+OimX31hL0RNpdKu//bAXHqEe+6PEDZrD4h2AncvlGJpL6L/q1i9MwRnzXxo94C9TJhguOpDhgQfNsRkOwlVPReiM/h/0JvGgRl0iIDlSGouzcMldOJjXNETyZOFixyIkzqd/ADtP2P0y+IUrhROA= x-ms-exchange-antispam-messagedata: 2RIQDbTglov2NIEkTSGU9325wkGjI5cOJHYN5Y8OXVzTsqYBV9qR9J6D41ITu4rVHbzwLSE5rFZNAfQTjooM3SM9ybnpV+sc+GsGaRoqB4s48+CQPf//Tm6fcC/NsjsUc08IIoCYqVu4DZVJr4yI3g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0DE8DEBFE64AE946BE415DB98DE0CC59@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 16d3c8e6-dbee-48dc-9b1f-08d7cd6dbe71 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2020 07:59:12.4458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UzIviff3svCW4+Ovd+LApeNH1CBnCnCu6bDQ+Wim+HMU+f5/FTM7Pu+vdht+zT0GZTVsS2lXivLZU4krAw+2pA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0742 Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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: Sat, 21 Mar 2020 07:59:23 -0000 SGkgV2FycmVuLA0KDQpPbiBGcmksIDIwMjAtMDMtMjAgYXQgMTI6MzMgLTA0MDAsIFdhcnJlbiBL dW1hcmkgd3JvdGU6DQo+IE9uIEZyaSwgTWFyIDIwLCAyMDIwIGF0IDEyOjExIFBNIFJhbmR5IEJ1 c2ggPHJhbmR5QHBzZy5jb20+IHdyb3RlOg0KPiA+IA0KPiA+ID4gPiA+IEJHUCBpbXBsZW1lbnRh dGlvbnMgaGF2ZSB0byB0YWtlIHJlbW92YWwgb2YgcHJpdmF0ZSBBUyhzKSwNCj4gPiA+ID4gPiBj b25mZWRlcmF0aW9uLCBBUyBtaWdyYXRpb24sIGV0YyBpbnRvIGNvbnNpZGVyYXRpb24uDQo+ID4g PiA+IA0KPiA+ID4gPiBhbmQgdGhlIHdpbmRzIG9mIHN1bW1lci4gIHdlIGRvIG5vdCBuZWVkIHRv IGVudW1lcmF0ZSBhbGwNCj4gPiA+ID4ga25vYnMsIGFzDQo+ID4gPiA+IGlmIHdlIGNvdWxkLg0K PiA+ID4gPiANCj4gPiA+IA0KPiA+ID4gQnV0IGVudW1lcmF0aW5nICpzb21lKiBoZWxwcyB0aGUg cmVhZGVyIHVuZGVyc3RhbmQgdGhlIGNvbnRleHQgaW4NCj4gPiA+IHdoaWNoDQo+ID4gPiB0aGlz IGlzIGltcG9ydGFudC91c2VmdWwuDQo+ID4gDQo+ID4gd2hpY2ggaXMgd2h5DQo+ID4gDQo+ID4g ICAgV2hlbiBhcHBsaWVkIHRvIGVncmVzcyBwb2xpY3ksIHRoZSBlZmZlY3RpdmUgb3JpZ2luIEFT IE1VU1QgYmUNCj4gPiB1c2VkDQo+ID4gICAgdG8gZGV0ZXJtaW5lIHRoZSBPcmlnaW4gVmFsaWRh dGlvbiBzdGF0ZS4gIFRoZSBlZmZlY3RpdmUgb3JpZ2luDQo+ID4gQVMgaXMNCj4gPiAgICB0aGF0 IHdoaWNoIHdpbGwgYWN0dWFsbHkgYmUgdGhlIG9yaWdpbiBBUyBpbiB0aGUNCj4gPiBhbm5vdW5j ZW1lbnQuICBJdA0KPiA+ICAgIG1pZ2h0IGJlIGFmZmVjdGVkIGJ5IHJlbW92YWwgb2YgcHJpdmF0 ZSBBUyhzKSwgY29uZmVkZXJhdGlvbiwgQVMNCj4gPiAgICBtaWdyYXRpb24sIGV0Yy4NCj4gPiAN Cj4gDQo+IE9uZSBvZiB0aGUgdGhpbmdzIHRoYXQgSSBwZXJzb25hbGx5IGxpa2UgbW9zdCBhYm91 dCB0aGlzIGRvY3VtZW50IGlzDQo+IHRoYXQgaXQgY29uY2lzZSAtIGl0IGNsYXJpZmllcyBzb21l dGhpbmcgZm9yICppbXBsZW1lbnRvcnMqIHRvIGtlZXANCj4gaW4NCj4gbWluZCAvIHBvaW50cyBv dXQgc29tZXRoaW5nIHdoZXJlIHRoZXkgbWlnaHQgdHJpcCBvdmVyIHNvbWV0aGluZyBhbmQNCj4g aHVydCB0aGVtc2VsdmVzLg0KPiANCkkgb25seSBwYXJ0aWFsbHkgYWdyZWUuIEZvciB0aHJlZSBy ZWFzb25zOg0KDQotIE15IGV4cGVyaWVuY2Ugb3ZlciB0aGUgbGFzdCAxMiBtb250aHMgb2YgcnVu bmluZyBpbnZhbGlkPT1kZW55IGluDQpwcm9kdWN0aW9uIGlzIHRoYXQgc29tZSBpbXBsZW1lbnRv cnMgaGF2ZSBtYW5hZ2VkIHRvIHRha2UgZXZlcnkNCmFtYmlndWl0eSBpbiB0aGUgdmFyaW91cyBy b3YtcmVsYXRlZCBSRkNzIGFuZCB0cmFuc2xhdGUgaXQgaW50byBidWdzIG9yDQpmcmFnaWxlL2hv c3RpbGUgYmVoYXZpb3IuIEkgdGhpbmsgb3VyIGxlc3NvbiBzaG91bGQgYmUgdGhhdCBldmVuDQpv YnZpb3VzLXNlZW1pbmcgc3BlYyBnYXBzIG91Z2h0IHRvIGJlIGZpbGxlZCBpbiB0aGlzIGFyZWEu DQoNCi0gT3BlcmF0b3JzIHVzaW5nIGltcGxlbWVudGF0aW9ucyBvZiB0aGlzIGRyYWZ0IHdpbGwg b2JzZXJ2ZQ0KYmVoYXZpb3VyYWwgZGlmZmVyZW5jZXMgYmV0d2VlbiBzaW1pbGFyLXNlZW1pbmcg cG9saWN5IGFwcGxpZWQgYXQNCmRpZmZlcmVudCBhdHRhY2htZW50IHBvaW50cy4gVGhpcyBkb2N1 bWVudCBzaG91bGQgaGVscCB0aGVtIHVuZGVyc3RhbmQNCnRob3NlIGRpZmZlcmVuY2VzLg0KDQot IFdlIG1heSB2ZXJ5IHdlbGwgc2VlIHNvbWUgaW1wbGVtZW50YXRpb25zIHdpbmQgdXAgd2l0aCBz ZXBhcmF0ZQ0KcG9saWN5IGtub2JzIGZvciAiZW5hYmxlIHJwa2ktcm92IiBhbmQgImVuYWJsZSBy cGtpLXJvdi1lZ3Jlc3MiLiBBZ2FpbiwNCm9wZXJhdG9ycyB3aWxsIG5lZWQgYSBzcGVjIGFnYWlu c3Qgd2hpY2ggdG8gdmFsaWRhdGUgdGhhdCBmZWF0dXJlDQpiZWhhdmlvdXIgaWYgaXQgaXMgY2xh aW1pbmcgUkZDIGNvbXBsaWFuY2UuDQoNCj4gV2hpbGUgSSBnZW5lcmFsbHkgbGlrZSBleGFtcGxl cyBhbmQgZGV0YWlsIGluIFJGQ3MsIGluIHRoaXMgY2FzZSBpdA0KPiB3b3VsZCBiZSAidGVhY2hp bmcgeW91ciBncmFuZG1vdGhlciB0byBzdWNrIGVnZ3MiWzBdIC0gdGhlIHJlYWRlcnMgaW4NCj4g dGhpcyBjYXNlIGFyZSBmb2xrIHdobyB3cml0ZSBCR1AsIHRoZSBkb2N1bWVudCBiYXNpY2FsbHkg c2F5cw0KPiAiV2FybmluZzogc2hhcnAgb2JqZWN0LCBjYXJlZnVsIHdpdGggZmluZ2VycyIgLSBo YXZpbmcgdG9vIG11Y2gNCj4gZGV0YWlsDQo+IGRlY3JlYXNlcyB0aGUgdXRpbGl0eSBpbiB0aGlz IGNhc2UuDQo+IA0KPiBBZ2FpbiwgSSBnZW5lcmFsbHkgYWdyZWUgdGhhdCBkb2N1bWVudHMgc2hv dWxkIGVudW1lcmF0ZSBhbGwgb2YgdGhlDQo+IGNvcm5lciBjYXNlcywgaGF2ZSBleGFtcGxlcywg ZXRjIC0gYnV0IGluIHRoaXMgY2FzZSBJIHRoaW5rIGl0IHdvdWxkDQo+IGRvIG1vcmUgaGFybSB0 aGFuIGdvb2QuLi4NCj4gDQpJJ20gbm90IHN1Z2dlc3RpbmcgdHVybmluZyB0aGlzIGludG8gYSB1 c2UtY2FzZSBkb2MuIEJ1dCBlbm91Z2ggY29sb3INCnRvIG1ha2UgdGhlIG1lbnRhbCBsaW5rIGJl dHdlZW4gcmVhbC13b3JsZCBwb2xpY3kgYW5kIHByb3RvY29sIGNvbmNlcHRzDQppcyBuZWNlc3Nh cnksIGltaG8uDQoNCkNoZWVycywNCg0KQmVuDQoNCj4gVw0KPiBbMF06IGh0dHBzOi8vZW4ud2lr aXBlZGlhLm9yZy93aWtpL1RlYWNoaW5nX2dyYW5kbW90aGVyX3RvX3N1Y2tfZWdncw0KPiA+IHJh bmR5DQo+IA0KPiANCj4gDQo= From nobody Sat Mar 21 10:33:02 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 8CE943A0793; Sat, 21 Mar 2020 10:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 0RBzNsymY45d; Sat, 21 Mar 2020 10:32:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 CD7B43A078C; Sat, 21 Mar 2020 10:32:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jFhzR-0008Ot-Rp; Sat, 21 Mar 2020 17:32:54 +0000 Date: Sat, 21 Mar 2020 10:32:53 -0700 Message-ID: From: Randy Bush To: Ben Maddison Cc: last-call@ietf.org, ops-dir@ietf.org, sidrops@ietf.org In-Reply-To: References: <158448201565.32201.9748655174984394118@ietfa.amsl.com> <624bd5c7-5459-64c2-5694-b77dde5835a6@foobar.org> <20200318012635.GE77479@vurt.meerval.net> <55f529777e4524b2ac2f6f94c0955611d04aa250.camel@workonline.africa> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01 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: Sat, 21 Mar 2020 17:33:00 -0000 > I only partially agree. For three reasons: > > - My experience over the last 12 months of running invalid==deny in > production is that some implementors have managed to take every > ambiguity in the various rov-related RFCs and translate it into bugs or > fragile/hostile behavior. I think our lesson should be that even > obvious-seeming spec gaps ought to be filled in this area. > > - Operators using implementations of this draft will observe > behavioural differences between similar-seeming policy applied at > different attachment points. This document should help them understand > those differences. > > - We may very well see some implementations wind up with separate > policy knobs for "enable rpki-rov" and "enable rpki-rov-egress". Again, > operators will need a spec against which to validate that feature > behaviour if it is claiming RFC compliance. > ... > I'm not suggesting turning this into a use-case doc. But enough color > to make the mental link between real-world policy and protocol concepts > is necessary, imho. since we're not getting it clearly, so send a short paragraph or two randy From nobody Sat Mar 21 11:50:20 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 8C0763A08B1 for ; Sat, 21 Mar 2020 11:50:12 -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 MqUq1HFCE1sg for ; Sat, 21 Mar 2020 11:50:04 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 8FA203A08B0 for ; Sat, 21 Mar 2020 11:50:04 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id a49so9367706otc.11 for ; Sat, 21 Mar 2020 11:50:04 -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=4ukGHUKS5/9wEoV6JCNlgg7hWK+WcQfnyVmmfqJtVEY=; b=AMWLaM9nwFWwRDKK/+26CV0yA4XAjAqw4GOBEY9Q70kM6Eihpddh59L6O9HxkqFQnq DJIHbpc0VWUayv6xL5SCAZqq/PCAfEXn3zKdma1mY//EF3wSayGGVjTCoWtFdSDVIsCK PcI9Cdm4FZbV8O7zGzOcNv/vp9ONyNNiqrAR8WvAZRh3srR9ZvjCySAMryw0w/UWwV4O A1+r6tTvtVAaYzxennfajBDuHgIauU/wFzJjGIFG8IJClLgV0sKU228erN3WZUl4xq3A 7RXEZgmXlCrBhmPeMbWnctxLLukyMsrz5fX+/nf+XtbuEprYEYsbb3DJOJyxi5ux/gdJ Hb8w== 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=4ukGHUKS5/9wEoV6JCNlgg7hWK+WcQfnyVmmfqJtVEY=; b=Czp+l7liUOjl0v1IndOeui8XreyxUHtxPC3qkGsrE47NadN64yrP4hsjQBBDUlOw83 kqf55+Cb2usN0jp4WHYn6LmgJ+DVBIB5YnVWEk1N4Akf3c1ZnmdN/oSluDRdSpfSUuTx /2eoVJX9RFFuqxoo1Pekhzpgmdfoj06/lq+PjgcZ9LCuQLwraMAdmdWi6TLVFRM7fYds UWPQ6e9t9nMuDmeGbFKIF01nTm11JxnQSYNp/mLETPCP9KuptEXu+NZmcKfo8lGMPbnh Rr1jfGdUd/UGZJ59wZvBlXK0P4DQPDb5hdpCKVnFHI7Me5y+i8YLtlu/vURVRMAXvjFp +g1w== X-Gm-Message-State: ANhLgQ3Y1KFg83e7SVHuz0TH5ptM1oIOomxjF+NAyrP9ZAotccbSX7yM 99SgLoBsZC5w+uWj04BGSUPJEJAxSTsgZAIdDWA= X-Google-Smtp-Source: ADFU+vu+tAdsJ59tD9ZMIfaYe8e77DDZGjtQda7qxPQ4o0ZU9qJ4Rt5ySQ+i02uiAc3fT6NFSQ62X5tmXCNNiTs5Lx0= X-Received: by 2002:a9d:4810:: with SMTP id c16mr12425383otf.248.1584816603776; Sat, 21 Mar 2020 11:50:03 -0700 (PDT) MIME-Version: 1.0 References: <603F22AC-E2DB-4AEA-8242-F0A021869B5B@ripe.net> In-Reply-To: <603F22AC-E2DB-4AEA-8242-F0A021869B5B@ripe.net> From: Alexander Azimov Date: Sat, 21 Mar 2020 21:49:51 +0300 Message-ID: To: Oleg Muravskiy Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000b3cb5d05a161deed" Archived-At: Subject: Re: [Sidrops] WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24) 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: Sat, 21 Mar 2020 18:50:15 -0000 --000000000000b3cb5d05a161deed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Support adoption. =D1=81=D1=80, 11 =D0=BC=D0=B0=D1=80. 2020 =D0=B3. =D0=B2 18:32, Oleg Muravs= kiy : > On 9 Mar 2020, at 21:03, Keyur Patel wrote: > > > > Hi Folks, > > > > The authors have requested SIDROPS working group adoption call of =E2= =80=9CRPKI > to Router Protocol Version 2=E2=80=9D, > https://tools.ietf.org/html/draft-ymbk-8210bis-00. > > > > Please send your comments to the list. This adoption call will conclude > on March 24, 2020. > > Support > > > Oleg > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --=20 Best regards, Alexander Azimov --000000000000b3cb5d05a161deed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support adoption.

=D1=81=D1=80, 11 =D0=BC=D0=B0=D1=80. 2020= =D0=B3. =D0=B2 18:32, Oleg Muravskiy <= oleg@ripe.net>:
On 9 Mar 2020, at 21:03, Keyur Patel <keyur@arrcus.com> wrote:
>
> Hi Folks,
>=C2=A0
> The authors have requested SIDROPS working group adoption call of =E2= =80=9CRPKI to Router Protocol Version 2=E2=80=9D,=C2=A0 https://tools.ietf.org/html/draft-ymbk-8210bis-00.
>=C2=A0
> Please send your comments to the list. This adoption call will conclud= e on March 24, 2020.

Support


Oleg

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


--
Best regards,
Alexander Azi= mov
--000000000000b3cb5d05a161deed-- From nobody Sat Mar 21 12:19:30 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 A0E5D3A08F8 for ; Sat, 21 Mar 2020 12:18:15 -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=unavailable 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 Jb9sFv_RF6Yd for ; Sat, 21 Mar 2020 12:18:05 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 B81EE3A0902 for ; Sat, 21 Mar 2020 12:14:25 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id p125so10337930oif.10 for ; Sat, 21 Mar 2020 12:14:25 -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=C4zJeWrnQKSGR3KQ42t0NIMzt/9yQ41Cg5F9piWtfWA=; b=FOP1dzLpxk51sRi0MGLfuOWm6esK+iVc7NcAF50c020Mgex3KOCjROFhUknMM65z17 yrNIujizBuPvuiv80iFquK4AIzZ/Uw2CjROoYOgifx7rncGEspnyVhtIJ5Dc+Ydqa0h2 gU/ehjOYwAIBjfmaDBLMPjEEx3PYC3Wssq9hCCdw/NuhGRqYiHwLJX2tDw5W7t6M/Bh3 1npLm1h8KZXy0AcnEOoaE6tgWSo+Pv6WnQHoQW6EVzcKX1ysJMZ/Sqc5Q5vLMET+btrM 61+4G09YCIhzlNAqmrZk4HAjtE8t8RfPQwFjZPRNsDqarU+a7Lzu1u/xG2snu9aJ8y6H M8yQ== 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=C4zJeWrnQKSGR3KQ42t0NIMzt/9yQ41Cg5F9piWtfWA=; b=jbLfcbdkhWHq3mVsBW2YkBO/gr+QP8BEvr0fE1yo1NnxPzv2KU9hIRmEM4+eD9VGVp y+GKmH+LVwBMiCO/qz9d4dhV9u/aBT52kh3sBlshpoLnwrb32aUN+JZ6sGmtNH3C76xM ELBNj9hFrobQqvWIi7s4FlRJU8Gb5h8Olk0e+ZQR3QNiE4YAOKEk5Di91RV+ML6R8JOU OnhT5VPER6lwjmnkNyE6kcAJSjzaY95ihHmxIXhxDDdX/R5SsjqIk2hmWu1+HiI+9Mdb 3Io7duh1RzJ5tldVFJ38VrBMM/rvX55t75he0okw/ahSetoGzS/PZZuF9gQL3yECdbWw jaRw== X-Gm-Message-State: ANhLgQ2sEwzL3CfVjPUX+aKO4abfh5AnzXUyTISNT7JBhwPFBrUaxgRO NkvNFaoiGwQc3piqXC97koX6BL+pBDE402xzTE8= X-Google-Smtp-Source: ADFU+vucbF0cKD5xvns/Qbt2kOQ54DK/a+cZeIB/sV5xuEap411SxC+K2NBDS7opBhe47kGu8T4RaRvX/IUJvrbE4UM= X-Received: by 2002:aca:d11:: with SMTP id 17mr11760449oin.128.1584818064932; Sat, 21 Mar 2020 12:14:24 -0700 (PDT) MIME-Version: 1.0 References: <158274065310.22955.10729466847169070546.idtracker@ietfa.amsl.com> <20200306130129.59c888c1@glaurung.nlnetlabs.nl> In-Reply-To: From: Alexander Azimov Date: Sat, 21 Mar 2020 22:14:13 +0300 Message-ID: To: Randy Bush Cc: Martin Hoffmann , SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000cb43c405a16235c1" Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt 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: Sat, 21 Mar 2020 19:18:17 -0000 --000000000000cb43c405a16235c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The separated records for v4 and v6 ASPA were inspired by the previous research that showed a significant difference in the peering relations in v4 and v6 respectively. I did this research a couple of years ago, it will be interesting to check if the situation has significantly changed. I'd like to get the WG attention on the introduced update of ROA processing= . The current version of the RTR protocol related to ROAs is vulnerable to possible race conditions: if the prefix has multiple ROA records or it covering prefixes with different origin asn the state of the partial update may lead to invalidating of really valid prefixes. Here is fresh statistics= : - 16153 IPv4 prefixes with equal (5486) or more specific (11872) conflicts; - 2250 IPv6 prefixes with equal (1202) or more specific (1164) conflicts= . 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. =D0=B2=D1=82, 10 =D0=BC=D0=B0=D1=80. 2020 =D0=B3. =D0=B2 06:22, Randy Bush = : > > As a separate note, ASPA in its current form includes the address > > family, ie., it has different ASPA objects for v4 and v6. This is > > missing from the proposed ASPA RTR payload PDU, but luckily there is > > enough zero space to include it. > > i believe this is addressed in the draft out today; though not exactly > in the way you suggest. thanks again for pointing this out. > > randy > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --=20 Best regards, Alexander Azimov --000000000000cb43c405a16235c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The separated=C2=A0records for v4 and v6 ASPA were in= spired by the previous research that showed a significant difference in the= peering relations in v4 and v6 respectively.=C2=A0
I did this re= search a couple of years ago, it will be interesting to check if the situat= ion has significantly changed.

I'd like to= get the WG attention on the introduced update of ROA processing.
The current version of the RTR protocol related to ROAs is vulnerable=C2= =A0to possible race conditions: if the prefix has multiple ROA records or i= t covering prefixes with different origin asn=C2=A0the state of the partial= update may lead to invalidating of really valid prefixes. Here is fresh st= atistics:
  • 16153 IPv4 prefixes = with equal (5486) or more specific (11872) conflicts;
  • 2250 IPv6 prefixes with equal (1202) or more specific (1164) = conflicts.

The current proposal addresse= s=C2=A0this issue for ASPA and ROAs in a different way:
  • F= or ASPA a single PDU per customer AS is neveling the issue;
  • For ROA= s the draft introduces ordering of the updates=C2=A0+ suggests sending upda= tes with the same prefix back to back.
The way ROAs wil= l be processed decreases=C2=A0the chances that valid prefixes will be marke= d as invalid, but they are not zero. My thinking is, that since RTR protoco= l is negotiating its version at the start of the session there is no need t= o keep full backward compatibility with the way ROAs were processed previou= sly. Instead, we can change ROA RTR PDUs is the same fashion as it is intro= duced for ASPA: a single PDU for a selected prefix that replaces previous r= ecords.

=D0=B2=D1=82, 10 =D0=BC=D0=B0=D1=80. 2020 =D0=B3. =D0=B2 06:22, = Randy Bush <randy@psg= .com>:
&g= t; As a separate note, ASPA in its current form includes the address
> family, ie., it has different ASPA objects for v4 and v6. This is
> missing from the proposed ASPA RTR payload PDU, but luckily there is > enough zero space to include it.

i believe this is addressed in the draft out today; though not exactly
in the way you suggest.=C2=A0 thanks again for pointing this out.

randy

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


--
Best regards,
Alexander Azimov
--000000000000cb43c405a16235c1-- From nobody Mon Mar 23 03:34:50 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 CB5EA3A0746 for ; Mon, 23 Mar 2020 03:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Oe2W7zVnza3p for ; Mon, 23 Mar 2020 03:34:46 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 75AAE3A0404 for ; Mon, 23 Mar 2020 03:34:46 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jGKPs-0006WZ-Ni for sidrops@ietf.org; Mon, 23 Mar 2020 11:34:44 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::f50]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jGKPs-0000Uj-Jg for sidrops@ietf.org; Mon, 23 Mar 2020 11:34:44 +0100 From: Nathalie Trenaman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Mon, 23 Mar 2020 11:34:43 +0100 References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> To: SIDR Operations WG In-Reply-To: <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> Message-Id: X-Mailer: Apple Mail (2.3608.60.0.2.5) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a1cd9bfd5a623028df74a6498570934e6 Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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: Mon, 23 Mar 2020 10:34:49 -0000 Hi, > Op 27 feb. 2020, om 10:50 heeft Tim Bruijnzeels het = volgende geschreven: >=20 > Hi, >=20 >> On 27 Feb 2020, at 09:59, Robert Kisteleki wrote: >>=20 >>=20 >>=20 >> On 2020-02-26 18:39, Job Snijders wrote: >>> I think the entire repository should be considered invalid if a = single >>> file is missing but was referenced in the manifest. One can't = produce >>> rules based upon false or incomplete data, and one can't protect = against >>> hijacks using unsigned data. >>=20 >> I'm not sure that'd be wise. Knowing you're missing something does = not >> invalidate the other bits that you can verify. Exactly what you keep >> using can depend on what's missing (a CRL, a CA cert, a ROA, ...) = though. >=20 > I am not saying that I have the complete answer here, but I think it's = worthwhile to discuss this further - if the WG is willing to consider = updates to the manifest RFC. >=20 > It gets complicated. >=20 > ROAs at the parent level have the ability to invalidate announcements = by children that run delegated CAs. If their CA cert is missing, then = this can impact ROV to the point that announcements by children are = considered invalid. >=20 > In such cases it might be better to mark objects the ROA objects as = invalid so that ROV yields not found. It is probably okay to recurse any = other CA cert and use ROAs found under it. Probably, because probably = they are more specific, and ROAs there would not invalidate covering, = presumably, less specific announcements done by the parent (yes, lots of = assumptions here). For BGPSec certificates things get more complicated, = because at the MFT level they are indistinguishable from delegate CA = certificates. Also BGPSec does not have a soft-landing, so invalidating = certificates (rather than ROAs) might be quite harmful. >=20 > Note, I think this should be applied only to *missing* objects as that = indicates either a failure to publish things properly, or possibly a = partial withhold attack where the RP receives incomplete information. = And even then, there may be ways to recover if an RP still has prior = copies of all missing objects (check hash). >=20 > If objects are found and accounted for, but they turn out to be = invalid, then I believe that other objects should not be impacted. >=20 I would still welcome discussion on this. For our Validator, we = currently issue warnings if there is something wrong with the CRL. Some = other RP (validator tools) invalidate the chain, one ignores the CRL. = This is not a good situation.=20 =46rom the mailing list, I didn=E2=80=99t see a clear consensus (yet?) = for RP (validator tools). Any ideas? Thoughts? Did I miss something? Thanks, Nathalie=20 From nobody Mon Mar 23 05:56: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 9DF173A077A for ; Mon, 23 Mar 2020 05:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Vc2JggrXY0Ps for ; Mon, 23 Mar 2020 05:56:50 -0700 (PDT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2030E3A0766 for ; Mon, 23 Mar 2020 05:56:49 -0700 (PDT) Received: (qmail 41383 invoked by uid 1000); 23 Mar 2020 12:56:47 -0000 Date: Mon, 23 Mar 2020 13:56:47 +0100 From: Claudio Jeker To: sidrops@ietf.org Message-ID: <20200323125647.GA6421@diehard.n-r-g.com> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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: Mon, 23 Mar 2020 12:56:53 -0000 On Mon, Mar 23, 2020 at 11:34:43AM +0100, Nathalie Trenaman wrote: > Hi, > > > Op 27 feb. 2020, om 10:50 heeft Tim Bruijnzeels het volgende geschreven: > > > > Hi, > > > >> On 27 Feb 2020, at 09:59, Robert Kisteleki wrote: > >> > >> > >> > >> On 2020-02-26 18:39, Job Snijders wrote: > >>> I think the entire repository should be considered invalid if a single > >>> file is missing but was referenced in the manifest. One can't produce > >>> rules based upon false or incomplete data, and one can't protect against > >>> hijacks using unsigned data. > >> > >> I'm not sure that'd be wise. Knowing you're missing something does not > >> invalidate the other bits that you can verify. Exactly what you keep > >> using can depend on what's missing (a CRL, a CA cert, a ROA, ...) though. > > > > I am not saying that I have the complete answer here, but I think it's worthwhile to discuss this further - if the WG is willing to consider updates to the manifest RFC. > > > > It gets complicated. > > > > ROAs at the parent level have the ability to invalidate announcements by children that run delegated CAs. If their CA cert is missing, then this can impact ROV to the point that announcements by children are considered invalid. > > > > In such cases it might be better to mark objects the ROA objects as invalid so that ROV yields not found. It is probably okay to recurse any other CA cert and use ROAs found under it. Probably, because probably they are more specific, and ROAs there would not invalidate covering, presumably, less specific announcements done by the parent (yes, lots of assumptions here). For BGPSec certificates things get more complicated, because at the MFT level they are indistinguishable from delegate CA certificates. Also BGPSec does not have a soft-landing, so invalidating certificates (rather than ROAs) might be quite harmful. > > > > Note, I think this should be applied only to *missing* objects as that indicates either a failure to publish things properly, or possibly a partial withhold attack where the RP receives incomplete information. And even then, there may be ways to recover if an RP still has prior copies of all missing objects (check hash). > > > > If objects are found and accounted for, but they turn out to be invalid, then I believe that other objects should not be impacted. > > > > I would still welcome discussion on this. For our Validator, we > currently issue warnings if there is something wrong with the CRL. Some > other RP (validator tools) invalidate the chain, one ignores the CRL. > This is not a good situation. > From the mailing list, I didn’t see a clear consensus (yet?) for RP > (validator tools). Any ideas? Thoughts? Did I miss something? > I think the current discussion did show that RP tools should do the proper validations and not skip steps. As for rpki-client we still believe that doing strict checks of the certificates is the right thing. rpki-client will exclude certs and the data they protect if they do not validate (this includes not-valid before and after timestamps of both the certificate and the CRL (if any)). Additionally all hash values in mft files are verified and again objects failing validation are excluded. The result is that only fully valid VRP are exported and all others are skipped but a warning is logged. -- :wq Claudio From nobody Mon Mar 23 06:27:07 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 854433A0814 for ; Mon, 23 Mar 2020 06:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-1.463, 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=verizon.net 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 w2f978C6_7n5 for ; Mon, 23 Mar 2020 06:27:03 -0700 (PDT) Received: from sonic316-11.consmr.mail.bf2.yahoo.com (sonic316-11.consmr.mail.bf2.yahoo.com [74.6.130.121]) (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 607F93A0877 for ; Mon, 23 Mar 2020 06:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1584970022; bh=9KYn+VnbTNCRuxOTiR/4AIo7o+kpm5baKgOV8kZj7uM=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=hp5qI3WuBKM0gaCo0TO0yRCFmLoynDSTVuABOPh3t+Gdmbdxgr/Mo0jjVInhmQ4SZNOv60XyNH0Q2z4F+JuXHXofuwGxCwvFg5cTCPmFBpIcBes3M7y0p9XtkZhjslqp7g2UN64iH5pclFBJ4TxS6KcThnEdTuR2QmicjmPabbFPoZc6KW7X0b+Txq/lJduHlFGeFt2QDT1bWnwqF+44vzU7kbnCbWj4wCE1sNRmVA5FQBLEKEs/KWbVO9ADt8UMJgTkTQZO7tKM1FAjq2LMWFu/ChTHFDVyDfYErgZu4vv38R5WeXEjtgsRJiKl5oMJqQC8KOnoDb4q1CHzNLXNiw== X-YMail-OSG: Cz0woVMVM1lOMMDOnnlQNojd0d.jGrdaKWvFfS1hd5fF.iINv42qxIsJWFWr.Nn cqFdTrl5zxQP5MXYk8xyAiXRDsHkk0Lg0gKM2yy4EOcG84Xm18b.DqBYk0h9t735ikrKamxCOLji ZiffqTLLxfhxw8FNR2xORwu0RsAxF2Wj_3Qy226hFvSqcDwbd1gPiap06D__UPzR.LQRkjmQCeI4 VlGd4M66uz6kyVvXmVcovq1qWruL9OQpOBAdoxTPtR2YcS0CuR2l0AmhQVcJ4Y5GnNzsci0JfzPr NGWkvE6OZtyqXWjL3Wf2uAD_LFcQD5MdwHcdnPbCbz9hucM2zzC2ibBMB4PrJxZyaAjXUpm7gzZ. qKrXkxctjFYeUk3fKv34NFlAmrlkdAQzGLUaJgQEEi5lVcInWKwTJl_tpFuO6PGYm.OEFqNSHR4q .wVw9OXC8yujfo8vxFbOQEYeX.MReltY9_pAUJGxi89WvUUDht8TpjtmTQEwklNoukEAs9Tb5sr5 C5k9XvRqWOp7dXeblVzxCGl8ie8bayjonVgZ1M7qTQVmI0WhbmXPad7ieO6r0vbnDK3eY6TnIy4h 51i4eqGLxGvOwrTNs0D5Q3XIhPAzBLMS.j.awqa_71.1Ca7.VIUaKSj9ne3Jco9t9tSW6g8EdJhO nDLAb30Qy6KCyHLHSciNzgmo0S.R.N09SGeFDUnQKYCsTu_LX11sqPK4VNS3BY0o67IYk9XQ0tkj cSekRWAdMF6gVNUze6rl4esCef5tZ_uGosi0MBSsmYFRlQ6s4z4LukEFH8dWwNCQlq6wr36Qu.fO dsMpJvpdgyQ4At05yxv1vzffsJxixL0E.A2LRL2f6a9Oi4g4lpqZY8398d1LZ7yCD0itDTU5vhAk 0m4RETD1etWt8.dO3IdFqa9k7QT_uwWxhCZOfTsSC0RTLrjINH0uHmXthct36t_.NgnPOXo_L0Ry rv8LX694Me2HSRsB989TmPWeKVRI_7NZ7itXmYV1qnG1vc67h0f.vYgjfRihsYJDcFOIOKOyxroV VpKe3QQp56Z4bEZvjnxE4oZoqljYYypVjZXYpZEZGq1nrYRSVpnWiUG6PlBp12rf.Xq.a20IDZOX dp.Ymh48eIA.i.QwnZ_SJN5Uf99K.cahMqb0RVZtCXMgp9uqbQ66nv2mjlrPiX8zj6Qg9_h67d6G kZgTesx2uMv_uMrGR6ciaDzDdCOZLiuLS1o2FNTuQkP3ulJXD1bKMjKjv.HNvW6AFQnDWrN9w5Nq Fx1l6L9A_aVpy3qmdlQBWoSi.eNZ1AxBaJ79Gr5LtsUa06qF.Wov7bmd_gHdxxPDwlNw3qJRHxLe HmZ_uc9dQben5xgbBKGF66a90e2BnIdC.ohrhdA.mwEWm2DF2yL.gi1esW1JUezxN4lOBuohHAp3 7UJr.0WL7UUA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Mon, 23 Mar 2020 13:27:02 +0000 Received: by smtp403.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 85467086446c0f345856120ce7588e69; Mon, 23 Mar 2020 13:27:01 +0000 (UTC) To: sidrops@ietf.org References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net> <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl> From: Stephen Kent Message-ID: <75140927-0b8b-07ab-ad2e-952e32256df1@verizon.net> Date: Mon, 23 Mar 2020 09:27:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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: Mon, 23 Mar 2020 13:27:05 -0000 Nathalie, > I would still welcome discussion on this. For our Validator, we > currently issue warnings if there is something wrong with the CRL. I think that is a very appropriate action. > Some other RP (validator tools) invalidate the chain, that's a valid response, but one should remember that an out of date CRL is not invalid, it's just stale. Given the desire to balance robust operation security concerns, I think this may be overkill. > one ignores the CRL. not a good response, and not conformant with the applicable RFCs! > This is not a good situation. I agree that more uniform processing is desirable, but in the routing system the notion of local policy seems to be ingrained, so ... Steve From nobody Mon Mar 23 06:33:28 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 CBCC33A00AD for ; Mon, 23 Mar 2020 06:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 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, RCVD_IN_MSPIKE_H2=-1.463, 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=verizon.net 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 ryv1SdPh5G2M for ; Mon, 23 Mar 2020 06:33:25 -0700 (PDT) Received: from sonic316-11.consmr.mail.bf2.yahoo.com (sonic316-11.consmr.mail.bf2.yahoo.com [74.6.130.121]) (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 815D73A0028 for ; Mon, 23 Mar 2020 06:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1584970404; bh=BzoDYPxX86QWpBX8iBCnvDG/sgIjnByOMaPTpwRrf3E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=hlkmIhcdET1k3LdDCOibFGUnkMlc4lcjX+WZgt9CR5mvcuRV4Ey1r3U8p4E5fTrO1J80N6oaVxHOIMKmZYhy/daplASlX2uvDfH2fPFDZENVLJAfhfZMQjxFVUdBiEmSdvjsbsxJLOffZHZHOdEeF81je/7rHLf8+zsMBTtEBV5ZqzSWD3EWsB+54dSBnWzK4Gfad86eJ0eeve6CuOGkYk5rgkDmlmKbWEF/lQ8LAbX+5AbSV3AIGnV6UxKkqKAjwFyDQEBWQHPROIxyLQ2M4nHQIfNxF4orQFDPabTufCef+YvSf9dzbTIq2P5MjtKyd5fzu6JbYLOup+PUwGvWDQ== X-YMail-OSG: 97hby9MVM1k75S6U7BULOOxTRMA5TPPgSDRbAAlVCB1hA.4DgOPrNqpOFcslYLs wQUMn38A6o8sQ2sbkUtGg7Kd9U8ZlGirbcgZTCTXCSkwuyZyJ1B1UPmhhzUtYniQx93bVvOI.WFT e_1nDtpOLU7FuZ48hgritpHY9G7xeU182nevcmrGGzLtN6yTf.J9uuf0PTw96SKdjRsnNKUnvex_ KL3X5nouBBhP0OGUN4.ZP6P8.swLxGlZ9zL78BiN6pZufLKyTIPPNCRhnKya.qb0wejosMdZarFg QCgziWIKrwQENlaKlJLqTMEjECXewOc0DupsYS_IjZnTplw70PIXdgA3kkKjgBe53Hq7Zwp2978A fxQorwfcv9BxIZ4Pz5Ow8VDX7WwaX9qibMWjpJxo_F0ySixmMeqRdCLJ8cu5FrDyioHVo2VNiavS SS4gJc8UHTYqh7QOLONPwNMooM_NqR26D4pbZpGwQI7wVtBeBXOglJlr3DopvhF9rW1UDR4Q0ijY U6A3q441kXWH9FDkWpQpz9iYNOgJDtyNj8IGTm0KJ7PTR9iBsVwaTRF8d_v802GENk6jsxDfU0_M hYhUQLHxJPo.x4sWf0.PARnzC_G_1hzfRDmDMgX.SX8_uq_jOL74oMzFnUXJdWGUBqqYGLRnUilN fJoBLavI9qMbCfFdPPime7XyaQ3TBjN4XoyzwuVUQblSbPdGYo8WQ113UDTbjw6isqnWBUc7KEkF 5HIdQbmrL0j3WBoMVdv5HOHOnJBPLtojsLGHr08AoWMpmV.LrmmGEDy7r21WON8NJ9FLyo71cmDE yl35L6XBTxT2CdY7yXPg3Y02JwaQq71i6sZiAxNIhi9pVtCZccyo31AMN.Xxnu3kXd5pqYoTITBm 1yy5sDRcxSMs8ZsQinANqHBM4jwTYtUVOX53cyCMFMEvzE.jshG9KayJKYbseO_zcfDNhrJF.8hX hwYbEGZG8zLMoLJpAQUNkP0Lr8hWf_RLi2prWqhzVpbTy46Xjo_8mlVGExWaRxsy03Z2.DD.Cd4r TBTlF5xH0m3U2uhZmHMmwkYkx8xtBfOkkHo1MNckRQ7dLrFtG3sd6OC6sU3KsTSJuBKw.9aNaCFH 056wlKS_SZBVj34fZl9ub8PLlvLFjPvpetibVpjwF4YURXP0gWAQykQ.EBpNqKnDINvfRUmSopSK 8YJj6_I.7KHKWj7fsGHxHdY8Wo.1UTYhiHCUw0X0ILBphJI..g_WiWEh0iN6zq0Zieq2cpshPD_2 M2qr_oEVQ4mhP4NSextNYWhRVKGc80cw_sVmYiWL8hDOrNpLBsS.kCBGRisztO1gPKfPnlX0_NSH xTpdghRg03qbeGcC.dFo7sujdlHyKaqBwCrbgJeGcS4CucqDu9qj.7Kr_duP692oZj2wX7CqfqT3 gl4x11x8gViHb98UubulzBrVjjrII45tP5TAkJWNes3VYGyD1MNmZA6Q_g66jokFZ.hs- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Mon, 23 Mar 2020 13:33:24 +0000 Received: by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 48dcff255d0ccc7334654d01c4eb7cf5; Mon, 23 Mar 2020 13:33:20 +0000 (UTC) To: Tim Bruijnzeels Cc: SIDR Operations WG References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> From: Stephen Kent Message-ID: Date: Mon, 23 Mar 2020 09:33:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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: Mon, 23 Mar 2020 13:33:27 -0000 Tim, > In general I agree. Which is why I mentioned the example of objects > one might find published outside of the context of the RPKI > repository, and *not* listed on a manifest. Such objects have yet to > be invented but theoretically one can think of signed structures under > an existing RPKI CA cert (e.g. using their own embedded EE) - which is > shared out-of-band between parties. That's a very forward-looking perspective, one I had not considered. > What I am suggesting is that we *could* update 6486 and make validation more restrictive regarding manifests: > - all objects on a manifest must be present and accounted for (I agree with Job regarding partial withhold attacks) > - all objects on a manifest need to be validated > - objects that are not on a manifest can be considered invalid > > This is in-line with the specifications defined in RFC 6481 (A Profile for Resource Certificate Repository Structure), which essentially says that all current objects must be published, and that no invalid objects may be published. agree. > Then, if the manifest is already a signed statement of everything that is current, at least regarding the currently defined object types, as defined in RFC 6481, then what is gained by checking that CA was also capable of generating a CRL - using the same authoritative key and publication method - that confirms that the objects that are current according to the manifest are indeed not revoked? I agree that with strict Manifest processing, CRLs provide redundant info. But, by that argument, why bother checking to see if certs are expired, since that too is redundant in a strict Manifest processing scenario? > Requiring the CRLs just feels like unnecessary brittleness to me (again in the context of RFC 6486). It creates multiple loci for bugs in CA implementations, and complicated error conditions that need to be checked by RPs. This is what I meant with the perhaps poorly chosen word 'pedantic'. Maybe I should have used the word 'redundancy'. Redundancy may seem like a good idea in general, but in this case it really only allows for the possibility of two conflicting signed messages. Thus it seems that this does not increase security, but provides more ways for things to break. redundancy is often beneficial in security systems. it helps prevent a single error from having terrible consequences. But, this strategy works only if one is flexible when responding  to an inconsistency between redundant pieces of info. Steve From nobody Mon Mar 23 06:33:33 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 980033A02C1 for ; Mon, 23 Mar 2020 06:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 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, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 7DYrbLZ5bLch for ; Mon, 23 Mar 2020 06:33:25 -0700 (PDT) Received: from sonic316-11.consmr.mail.bf2.yahoo.com (sonic316-11.consmr.mail.bf2.yahoo.com [74.6.130.121]) (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 8599E3A0034 for ; Mon, 23 Mar 2020 06:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1584970404; bh=BzoDYPxX86QWpBX8iBCnvDG/sgIjnByOMaPTpwRrf3E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=hlkmIhcdET1k3LdDCOibFGUnkMlc4lcjX+WZgt9CR5mvcuRV4Ey1r3U8p4E5fTrO1J80N6oaVxHOIMKmZYhy/daplASlX2uvDfH2fPFDZENVLJAfhfZMQjxFVUdBiEmSdvjsbsxJLOffZHZHOdEeF81je/7rHLf8+zsMBTtEBV5ZqzSWD3EWsB+54dSBnWzK4Gfad86eJ0eeve6CuOGkYk5rgkDmlmKbWEF/lQ8LAbX+5AbSV3AIGnV6UxKkqKAjwFyDQEBWQHPROIxyLQ2M4nHQIfNxF4orQFDPabTufCef+YvSf9dzbTIq2P5MjtKyd5fzu6JbYLOup+PUwGvWDQ== X-YMail-OSG: 97hby9MVM1k75S6U7BULOOxTRMA5TPPgSDRbAAlVCB1hA.4DgOPrNqpOFcslYLs wQUMn38A6o8sQ2sbkUtGg7Kd9U8ZlGirbcgZTCTXCSkwuyZyJ1B1UPmhhzUtYniQx93bVvOI.WFT e_1nDtpOLU7FuZ48hgritpHY9G7xeU182nevcmrGGzLtN6yTf.J9uuf0PTw96SKdjRsnNKUnvex_ KL3X5nouBBhP0OGUN4.ZP6P8.swLxGlZ9zL78BiN6pZufLKyTIPPNCRhnKya.qb0wejosMdZarFg QCgziWIKrwQENlaKlJLqTMEjECXewOc0DupsYS_IjZnTplw70PIXdgA3kkKjgBe53Hq7Zwp2978A fxQorwfcv9BxIZ4Pz5Ow8VDX7WwaX9qibMWjpJxo_F0ySixmMeqRdCLJ8cu5FrDyioHVo2VNiavS SS4gJc8UHTYqh7QOLONPwNMooM_NqR26D4pbZpGwQI7wVtBeBXOglJlr3DopvhF9rW1UDR4Q0ijY U6A3q441kXWH9FDkWpQpz9iYNOgJDtyNj8IGTm0KJ7PTR9iBsVwaTRF8d_v802GENk6jsxDfU0_M hYhUQLHxJPo.x4sWf0.PARnzC_G_1hzfRDmDMgX.SX8_uq_jOL74oMzFnUXJdWGUBqqYGLRnUilN fJoBLavI9qMbCfFdPPime7XyaQ3TBjN4XoyzwuVUQblSbPdGYo8WQ113UDTbjw6isqnWBUc7KEkF 5HIdQbmrL0j3WBoMVdv5HOHOnJBPLtojsLGHr08AoWMpmV.LrmmGEDy7r21WON8NJ9FLyo71cmDE yl35L6XBTxT2CdY7yXPg3Y02JwaQq71i6sZiAxNIhi9pVtCZccyo31AMN.Xxnu3kXd5pqYoTITBm 1yy5sDRcxSMs8ZsQinANqHBM4jwTYtUVOX53cyCMFMEvzE.jshG9KayJKYbseO_zcfDNhrJF.8hX hwYbEGZG8zLMoLJpAQUNkP0Lr8hWf_RLi2prWqhzVpbTy46Xjo_8mlVGExWaRxsy03Z2.DD.Cd4r TBTlF5xH0m3U2uhZmHMmwkYkx8xtBfOkkHo1MNckRQ7dLrFtG3sd6OC6sU3KsTSJuBKw.9aNaCFH 056wlKS_SZBVj34fZl9ub8PLlvLFjPvpetibVpjwF4YURXP0gWAQykQ.EBpNqKnDINvfRUmSopSK 8YJj6_I.7KHKWj7fsGHxHdY8Wo.1UTYhiHCUw0X0ILBphJI..g_WiWEh0iN6zq0Zieq2cpshPD_2 M2qr_oEVQ4mhP4NSextNYWhRVKGc80cw_sVmYiWL8hDOrNpLBsS.kCBGRisztO1gPKfPnlX0_NSH xTpdghRg03qbeGcC.dFo7sujdlHyKaqBwCrbgJeGcS4CucqDu9qj.7Kr_duP692oZj2wX7CqfqT3 gl4x11x8gViHb98UubulzBrVjjrII45tP5TAkJWNes3VYGyD1MNmZA6Q_g66jokFZ.hs- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Mon, 23 Mar 2020 13:33:24 +0000 Received: by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 48dcff255d0ccc7334654d01c4eb7cf5; Mon, 23 Mar 2020 13:33:20 +0000 (UTC) To: Tim Bruijnzeels Cc: SIDR Operations WG References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> From: Stephen Kent Message-ID: Date: Mon, 23 Mar 2020 09:33:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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: Mon, 23 Mar 2020 13:33:28 -0000 Tim, > In general I agree. Which is why I mentioned the example of objects > one might find published outside of the context of the RPKI > repository, and *not* listed on a manifest. Such objects have yet to > be invented but theoretically one can think of signed structures under > an existing RPKI CA cert (e.g. using their own embedded EE) - which is > shared out-of-band between parties. That's a very forward-looking perspective, one I had not considered. > What I am suggesting is that we *could* update 6486 and make validation more restrictive regarding manifests: > - all objects on a manifest must be present and accounted for (I agree with Job regarding partial withhold attacks) > - all objects on a manifest need to be validated > - objects that are not on a manifest can be considered invalid > > This is in-line with the specifications defined in RFC 6481 (A Profile for Resource Certificate Repository Structure), which essentially says that all current objects must be published, and that no invalid objects may be published. agree. > Then, if the manifest is already a signed statement of everything that is current, at least regarding the currently defined object types, as defined in RFC 6481, then what is gained by checking that CA was also capable of generating a CRL - using the same authoritative key and publication method - that confirms that the objects that are current according to the manifest are indeed not revoked? I agree that with strict Manifest processing, CRLs provide redundant info. But, by that argument, why bother checking to see if certs are expired, since that too is redundant in a strict Manifest processing scenario? > Requiring the CRLs just feels like unnecessary brittleness to me (again in the context of RFC 6486). It creates multiple loci for bugs in CA implementations, and complicated error conditions that need to be checked by RPs. This is what I meant with the perhaps poorly chosen word 'pedantic'. Maybe I should have used the word 'redundancy'. Redundancy may seem like a good idea in general, but in this case it really only allows for the possibility of two conflicting signed messages. Thus it seems that this does not increase security, but provides more ways for things to break. redundancy is often beneficial in security systems. it helps prevent a single error from having terrible consequences. But, this strategy works only if one is flexible when responding  to an inconsistency between redundant pieces of info. Steve From nobody Mon Mar 23 07:23: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 F2B123A0863 for ; Mon, 23 Mar 2020 07:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 dn4nni1n8Rpn for ; Mon, 23 Mar 2020 07:23:37 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 305393A07ED for ; Mon, 23 Mar 2020 07:23:37 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jGNzL-00008E-F8 for sidrops@ietf.org; Mon, 23 Mar 2020 15:23:35 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::f0f]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1jGNzL-0000Dc-Cp for sidrops@ietf.org; Mon, 23 Mar 2020 15:23:35 +0100 To: SIDR Operations WG References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> From: Robert Kisteleki Autocrypt: addr=robert@ripe.net; prefer-encrypt=mutual; keydata= xsBNBEzFa6gBCADVASYXBbUF7v1D+Y9XR41SEEMiZUARlUWeP0NrFHZmRRGdR5nM/p6HguUd StIPRmdqMdyLDqBsV8XPVu6lvhcb4+ZFu/V1XFPVyPBH8U6iQ4PdGDeqFlBm3gxoDOGraGw8 bjojvASTz/Wk3ddLPm34Kb6oMI2MclC016UgrPgIj6A1Uu8qQeBDyWrk+OrWUPOUOKM7QhQg cpU4JwuaesthFvqdoPNQJi9QUfn94r14ZNDYmeJlchZiRHWO70Gwoy3ywfAM9Kyi1tx78Qc9 E5ZhGIw9qqlzqa6c6a0qhup2Zh/dhVBJ05jCDN7bUQT5tRiOV2icyX8Dsr4KaWYCsAOVABEB AAHNMVJvYmVydCBLaXN0ZWxla2kgKFJJUEUgTkNDIGtleSkgPHJvYmVydEByaXBlLm5ldD7C wHgEEwECACICGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJWUwoeAAoJEC0ZXiKtTC3+ 04UH/jlvSR0esDGFSponUVawru+/QF61KdsNrdH6/Vs2buQvczW2Uh+S6Dic2vr2H0B1YrvL F2XpL2WJUHBUDLTA7dYTslvnHpyZrR8Sfb+h+wJ8OynxEC5wMKxfYNx2fMSk5EIU5mRjMaYg X/VkssDcoQAznNwVVYeqHYUJDMcrJhAYh44VHO208VwjPjHUDRlC+BoMGjHJnWDOAstlES8j 0r3adj2MqIHdDEjSdEx1+rbV0iZlgcDbYDex3qulOYlcZL+PJvGHzD6CkNBa8SbSN7cO0yqR OJ2sgobITOJ0GbRIbIvkUe1Iqw717CuQV/u822dFISDYOAhGYmfWGJWmkezOwE0ETMVrqAEI AKazZ2Agrv0nNFPWV69l6fEout/FaqWfyAG5V414l4yr+qVShUYzS+txA2vC+ouHvdORZ/JG xwKf6HE+YvvWS+Oa+b6h+GZfA3G43XGpQlxXrFK019TeMjhHqWprZALL4w2k6TatYT1ZW369 rORtwSgtn5ZC4uNcpZeDQddQvCjyYoknqlZqAFf1pssuGPTE8GvhrZGEp52dALYYoDIf7y/z 8fCAcy72rhMhQV02rPB49UxOEh2FZJhST0743tuMtFemBkp06B/Mcx54QT0muG8zj19oMDG3 AAaGjNP6B3qzR6F8VczR/qVhQzRvNMr8A6+y/ew/x4+48P+O/4n/I50AEQEAAcLAXwQYAQIA CQIbDAUCVlMKHgAKCRAtGV4irUwt/mvlB/sFID7mlsWAS66UyrI+tGs4Xfl59vvhRRZ4ZKiR 8VEbWbLKh/b9SoYcKt9SLEfVxJE5ebWPgIIvUSdLS6f4n9uAJteDZ4w/AVfp5a6jbfvMm7JP AMW4HtnZ3YbNevRgXdGVXN+bTLZzXoVijOKu+xHDBRNaUswaG3glrDJfUGkPQtCXFn6m6Pdw dW1/ShzwQgfuE/NXa83jhJ175P+NoQ2KG7934vu2MZdrtIqPibKuaGWMPG0L5YzPotK9ONmd taJMnuk92qqZ6S9JPwRZmogRW/sX54XvGg6RzNpdHS5C+iN01tCNJTRTlOJ1X73+RrGokvKc dp6fdfc4PHHhpcMd Organization: RIPE NCC Message-ID: <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> Date: Mon, 23 Mar 2020 15:23:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274e7be08cb59dcce0bbde35ad5a64e6c53 Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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: Mon, 23 Mar 2020 14:23:41 -0000 On 2020-03-23 14:33, Stephen Kent wrote: >> What I am suggesting is that we *could* update 6486 and make >> validation more restrictive regarding manifests: >> - all objects on a manifest must be present and accounted for (I agree >> with Job regarding partial withhold attacks) >> - all objects on a manifest need to be validated >> - objects that are not on a manifest can be considered invalid >> >> This is in-line with the specifications defined in RFC 6481 (A Profile >> for Resource Certificate Repository Structure), which essentially says >> that all current objects must be published, and that no invalid >> objects may be published. > agree. As I wrote before, I believe that a single mistake (withheld / unpublished object or even a bit flip) invalidating a whole repository, and as a consequence everything that could be validated under it, is a way to high price to pay. It also makes attacks much easier: withholding one single object from a repo and poof, a whole subtree (forest...) is gone? I believe a more nuanced approach is needed, like if there's a problem on a particular validation path (a cert is missing or has an error) then invalidate that path, if a CRL is missing then warn but use a stale one, but leave the otherwise unaffected bits validated. Robert From nobody Mon Mar 23 08:27:44 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 29A863A0810 for ; Mon, 23 Mar 2020 08:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 p9FWJ5lZKoPS for ; Mon, 23 Mar 2020 08:27:40 -0700 (PDT) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [IPv6:2001:418:3ff:110::40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3087B3A0802 for ; Mon, 23 Mar 2020 08:27:40 -0700 (PDT) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 75ECD220138 for ; Mon, 23 Mar 2020 15:27:38 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id B52CA27C0058 for ; Mon, 23 Mar 2020 11:27:36 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Mon, 23 Mar 2020 11:27:36 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudegkedgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedflfhosgcuufhnihhjuggvrhhsfdcuoehjohgssehnthht rdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehjohgsodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqddutdegjeeludeh keegqddvfeeffeekfedvtddqjhhosgeppehnthhtrdhnvghtsehsohgsohhrnhhoshhtrd hnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3302AC200A6; Mon, 23 Mar 2020 11:27:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> In-Reply-To: <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> Date: Mon, 23 Mar 2020 16:27:16 +0100 From: "Job Snijders" To: sidrops@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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: Mon, 23 Mar 2020 15:27:43 -0000 Dear all, I'm observing the discussions in sidrops with increasing alarm. Taking stock of the current situation I see: 1) failure to produce consistent output across multiple validators based on the current specs 2) failure to produce software updates which address the reported MITM scenarios One can argue "well, the specs did not explicitly mentioned what to do in scenario X Y Z", but even if the specs don't give precise guidance on what to do, I do not believe that the specs anywhere specify that insecure behaviour is acceptable. And even /if/ the specs granted "permission" for sloppy validation strategies, I'd expect any software developer producing 'security software' to deviate from such specs and implement validation strategies which are as secure as possible. On Mon, Mar 23, 2020, at 15:23, Robert Kisteleki wrote: > On 2020-03-23 14:33, Stephen Kent wrote: > >> What I am suggesting is that we *could* update 6486 and make > >> validation more restrictive regarding manifests: > >> - all objects on a manifest must be present and accounted for (I agree > >> with Job regarding partial withhold attacks) > >> - all objects on a manifest need to be validated > >> - objects that are not on a manifest can be considered invalid > >> > >> This is in-line with the specifications defined in RFC 6481 (A Profile > >> for Resource Certificate Repository Structure), which essentially says > >> that all current objects must be published, and that no invalid > >> objects may be published. > > > agree. > > As I wrote before, I believe that a single mistake (withheld / > unpublished object or even a bit flip) invalidating a whole repository, Some nuance could be added: it depends on where the error in the tree exists. If a top level manifest or CRL is hosted, indeed everything underneath it should be tossed. But for instance when a manifest 'at 2 levels deep', references a file that doesn't exist, you only need to toss that specific manifest (at least). So, yes, errors in the repository should result in the repository (or parts of it) being considered inadmissible. RPKI started out on the premise that an unencrypted transport (rsync) was acceptable, because everything was signed and cryptographically verifiable. Now we are in a situation where the transport channel *is* insecure, and the data transmitted across it is not properly verified. Validators are *knowingly* proceeding to produce VRPs with incomplete, expired, and/or corrupted data. > and as a consequence everything that could be validated under it, is a > way to high price to pay. It also makes attacks much easier: withholding > one single object from a repo and poof, a whole subtree (forest...) is gone? I'd be very hesitant to use absolutes such as "the price is way too high". The alternative is to allow for a number of MITM attack vectors. What is the cost of those? I have MITM examples running in my lab with routinator, rpki-client, fort, and ripe ncc's validator where partial withholding attacks are trivial and successful. The result of those MITM attacks is hard-to-troubleshoot network outages. Strategically hiding a select few ROAs can easily result in large scale outages because the attacker can make "RPKI Valid" announcements flip to "RPKI Invalid": this is worse than if the validator would've thrown out the manifest (things would've gone from "Invalid" to "Not-Found"). Performing the RFC 6811 Origin Validation procedure on an *incomplete* set of data is worse than not doing RFC 6811 at all. If RPKI validators allow flipping announcements from Valid to Invalid, that goes against the premise under which we designed RPKI to be incrementally deployable. We taught this industry that deploying RPKI would be safe. > I believe a more nuanced approach is needed, like if there's a problem > on a particular validation path (a cert is missing or has an error) then > invalidate that path, if a CRL is missing then warn but use a stale one, > but leave the otherwise unaffected bits validated. I'm not sure you weigh the power of partial withholding attacks as severely as I do. As mentioned before: stricter validator on the RPKI Cache Validator side of the house will put the onus on RPKI CA Publication points to run a tight ship. I believe this to be appropriate because there are far less CA operators than there are RP operators. If the validators are not going to be strict, what motivation exists for the CA operators to clean up their act? If the validators are not going to be strict, are network operators supposed to just accept that the VRPs they feed into "invalid == reject" policies on their EBGP routers potentially are tainted? How will that convince anyone to deploy RPKI Origin Validation? Kind regards, Job From nobody Mon Mar 23 09:27:07 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 B0C243A0746 for ; Mon, 23 Mar 2020 09:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 RFn8IEXh7lUC for ; Mon, 23 Mar 2020 09:26:41 -0700 (PDT) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E31E3A048D for ; Mon, 23 Mar 2020 09:26:41 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-196-134.hsd1.ma.comcast.net [73.47.196.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id AF7E9139BA for ; Mon, 23 Mar 2020 16:26:39 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 9B8FA2013DD7D4 for ; Mon, 23 Mar 2020 12:26:38 -0400 (EDT) Date: Mon, 23 Mar 2020 12:26:38 -0400 From: Rob Austein To: sidrops@ietf.org In-Reply-To: <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Message-Id: <20200323162638.9B8FA2013DD7D4@minas-ithil.hactrn.net> Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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: Mon, 23 Mar 2020 16:27:05 -0000 Unsurprisingly, I agree with Steve on this, particularly: On Wed, 26 Feb 2020 12:03:33 -0500, Stephen Kent wrote: ... > There are more cases one can analyze, but I think the basic approach > is to stick with prior, validated CRLs and contact the CA that > issued the questionable CRL, until the matter can be resolved. As others have observed, there is no way the RP can know what the CA intended when the data are inconsistent. Furthermore, given that the code which generates the CRLs is usually right next to the code that generates manifests (they usually advance in lock-step), there's no particular reason to assume consistency problems would be limited to one or the other. Trying to make sense out of an incoherent world is always going to be part of the RP's job. Falling back to older valid data has always been part of the strategy for doing that in the RPKI, and at least the first generation of RPKI validators all did that. It's not perfect, but it's better than an RP trying to guess which part of the protocol to violate in an attempt to guess what a broken CA really meant. From nobody Tue Mar 24 04:26:13 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 D68383A0043 for ; Tue, 24 Mar 2020 04:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no 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 MuzF59KQtC-V for ; Tue, 24 Mar 2020 04:25:58 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 070203A0029 for ; Tue, 24 Mar 2020 04:25:43 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id B5291211F6; Tue, 24 Mar 2020 12:25:34 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Tue, 24 Mar 2020 12:25:34 +0100 From: Martin Hoffmann To: Alexander Azimov Cc: Randy Bush , SIDR Operations WG Message-ID: <20200324122534.1fc2041b@glaurung.nlnetlabs.nl> In-Reply-To: References: <158274065310.22955.10729466847169070546.idtracker@ietfa.amsl.com> <20200306130129.59c888c1@glaurung.nlnetlabs.nl> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt 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, 24 Mar 2020 11:26:11 -0000 Alexander Azimov wrote: > > I'd like to get the WG attention on the introduced update of ROA > processing. The current version of the RTR protocol related to ROAs > is vulnerable to possible race conditions: if the prefix has multiple > ROA records or it covering prefixes with different origin asn the > state of the partial update may lead to invalidating of really valid > prefixes. Can you elaborate a bit more on this issue? The only scenario I can think of is that diffs are not applied atomically by clients which feels to me like a bit of a bad implementation? Kind regards, Martin From nobody Tue Mar 24 06:42:53 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 13C5C3A0A4D for ; Tue, 24 Mar 2020 06:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (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 Fnrn-qTb3-mN for ; Tue, 24 Mar 2020 06:42:43 -0700 (PDT) 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 9AB1D3A0977 for ; Tue, 24 Mar 2020 06:42:43 -0700 (PDT) Received: from [192.168.1.6] (unknown [177.37.212.238]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 0B62621560; Tue, 24 Mar 2020 14:42:39 +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=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1585057360; bh=EeWj5ICVWWO06gnjrnMjdKoWl/ITTaZ/axteSpTN+U0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=F5pc80HF+/A2JRyHS0zVHAc6lFBdE3UpC2q+aNygL+jegnav+E31w+j9iyTvbHHTb Xl4pBl+ncgKcP8pGtm/3OoOp1swwEl091vxR1TNVpwb9rwQmKfKxlvy/FiKNTE18DX ETZcTrMuadMGXEosDE666S4ckZ3E2D3emhkoe6g0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> Date: Tue, 24 Mar 2020 10:42:37 -0300 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> To: Job Snijders X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 13:42:51 -0000 > On 23 Mar 2020, at 12:27, Job Snijders wrote: >=20 > Dear all, >=20 > I'm observing the discussions in sidrops with increasing alarm. Taking = stock of the current situation I see: >=20 > 1) failure to produce consistent output across multiple validators = based on the current specs > 2) failure to produce software updates which address the reported MITM = scenarios >=20 > One can argue "well, the specs did not explicitly mentioned what to do = in scenario X Y Z", but even if the specs don't give precise guidance on = what to do, I do not believe that the specs anywhere specify that = insecure behaviour is acceptable. And even /if/ the specs granted = "permission" for sloppy validation strategies, I'd expect any software = developer producing 'security software' to deviate from such specs and = implement validation strategies which are as secure as possible. >=20 > On Mon, Mar 23, 2020, at 15:23, Robert Kisteleki wrote: >> On 2020-03-23 14:33, Stephen Kent wrote: >>>> What I am suggesting is that we *could* update 6486 and make >>>> validation more restrictive regarding manifests: >>>> - all objects on a manifest must be present and accounted for (I = agree >>>> with Job regarding partial withhold attacks) >>>> - all objects on a manifest need to be validated >>>> - objects that are not on a manifest can be considered invalid >>>>=20 >>>> This is in-line with the specifications defined in RFC 6481 (A = Profile >>>> for Resource Certificate Repository Structure), which essentially = says >>>> that all current objects must be published, and that no invalid >>>> objects may be published. >>=20 >>> agree. >>=20 >> As I wrote before, I believe that a single mistake (withheld / >> unpublished object or even a bit flip) invalidating a whole = repository, >=20 > Some nuance could be added: it depends on where the error in the tree = exists. If a top level manifest or CRL is hosted, indeed everything = underneath it should be tossed. But for instance when a manifest 'at 2 = levels deep', references a file that doesn't exist, you only need to = toss that specific manifest (at least). So, yes, errors in the = repository should result in the repository (or parts of it) being = considered inadmissible. >=20 > RPKI started out on the premise that an unencrypted transport (rsync) = was acceptable, because everything was signed and cryptographically = verifiable. Now we are in a situation where the transport channel *is* = insecure, and the data transmitted across it is not properly verified. = Validators are *knowingly* proceeding to produce VRPs with incomplete, = expired, and/or corrupted data. With RRDP over HTTPS a lot of in transit / MITM issues are mitigated. = The RFC currently still says that invalid certificates should be = accepted though. The thought at the time was that we have object = security and people make too many mistakes configuring HTTPS. With = Letsencrypt I believe this argument no longer holds. >=20 >> and as a consequence everything that could be validated under it, is = a >> way to high price to pay. It also makes attacks much easier: = withholding >> one single object from a repo and poof, a whole subtree (forest...) = is gone? >=20 > I'd be very hesitant to use absolutes such as "the price is way too = high". The alternative is to allow for a number of MITM attack vectors. = What is the cost of those? I have MITM examples running in my lab with = routinator, rpki-client, fort, and ripe ncc's validator where partial = withholding attacks are trivial and successful. The result of those MITM = attacks is hard-to-troubleshoot network outages. >=20 > Strategically hiding a select few ROAs can easily result in large = scale outages because the attacker can make "RPKI Valid" announcements = flip to "RPKI Invalid": this is worse than if the validator would've = thrown out the manifest (things would've gone from "Invalid" to = "Not-Found"). >=20 > Performing the RFC 6811 Origin Validation procedure on an *incomplete* = set of data is worse than not doing RFC 6811 at all. If RPKI validators = allow flipping announcements from Valid to Invalid, that goes against = the premise under which we designed RPKI to be incrementally deployable. = We taught this industry that deploying RPKI would be safe. First off I agree with Job that it would be better to disregard = information that is known to be a partial version of the truth. As said above, RRDP with HTTPS + real certificates will help. At least = it will make it clear if data is being tampered with. Finally, I did not say that data must be disregarded if things cannot be = fetched. If the RP has all the objects in its local cache it can use = them. If the MFT and CRL are still current and valid and local copies = exist for all objects as identified by their hashes (such object change = far less frequently) then one can just use them. >=20 >> I believe a more nuanced approach is needed, like if there's a = problem >> on a particular validation path (a cert is missing or has an error) = then >> invalidate that path, if a CRL is missing then warn but use a stale = one, >> but leave the otherwise unaffected bits validated. >=20 > I'm not sure you weigh the power of partial withholding attacks as = severely as I do. As mentioned before: stricter validator on the RPKI = Cache Validator side of the house will put the onus on RPKI CA = Publication points to run a tight ship. I believe this to be appropriate = because there are far less CA operators than there are RP operators. >=20 > If the validators are not going to be strict, what motivation exists = for the CA operators to clean up their act? >=20 > If the validators are not going to be strict, are network operators = supposed to just accept that the VRPs they feed into "invalid =3D=3D = reject" policies on their EBGP routers potentially are tainted? How will = that convince anyone to deploy RPKI Origin Validation? I agree that a partial withhold incident (involuntary) or attack - if = detected should lead to disregarding things. If not one can cause = invalids with serious impact, whereas a disregard would also be painful = but it would lead to 'not found' instead. >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Mar 24 06:58: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 4F32D3A0BDE for ; Tue, 24 Mar 2020 06:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 KJDc58nghCth for ; Tue, 24 Mar 2020 06:58:34 -0700 (PDT) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) (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 EEC2F3A0BF0 for ; Tue, 24 Mar 2020 06:58:33 -0700 (PDT) Received: by mail-wr1-f68.google.com with SMTP id 65so4861716wrl.1 for ; Tue, 24 Mar 2020 06:58:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2foSOj8dqMAR246F2ElEnHLf4BtdvlzD5GnpFgFCO5M=; b=cfe7sodsUZW6/4JvZ6lM4gt4wGyvpxXjAtGgAxbCB54h09VGlR/7vAaF3QS2l0uRwW ANa6ANAft/ZrmaySDhSfOVNduGdbbQ23vrMQtTyZibKKpsCNtRZ2MmBoRBbiaeusQLWQ EmoP34/AoLX8yV/CyapE+Ewgt4YHrniRUkwFncStcqHa+nVvKO3fi10Po39k3/hbWRF/ K2INLJCxt8cELKbTHLYMKgM4si+fdAYyrTDNRlXJQ2ABmTc0k+W03jaz4JHPH9VavdKN 4etW6CxKjT3lo/PDfBwsXuB9c+AelzJahmnXS8oeKqSaLEN2Iif9SYzGcgi/+CLwq07C fywg== X-Gm-Message-State: ANhLgQ3xnpviLfHZMOaD/7PDGvVz5/PfjZ2O7Vwcswte9uWI0NlN+kFq +7jv6kybZwas7X9UdKdX2KPuozSnkRc= X-Google-Smtp-Source: ADFU+vvZS4n984eAQpGx5sDbDt8ErP8Cr3FxRToTWqdP2VmLggu/cYTvdv8hTfFL+VqZoTUVwVsCGw== X-Received: by 2002:a5d:6a01:: with SMTP id m1mr27701107wru.353.1585058310973; Tue, 24 Mar 2020 06:58:30 -0700 (PDT) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id f9sm29839203wro.47.2020.03.24.06.58.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2020 06:58:30 -0700 (PDT) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id c06c980c; Tue, 24 Mar 2020 13:58:29 +0000 (UTC) Date: Tue, 24 Mar 2020 13:58:28 +0000 From: Job Snijders To: Tim Bruijnzeels Cc: SIDR Operations WG Message-ID: <20200324135828.GG60268@vurt.meerval.net> References: <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 13:58:53 -0000 On Tue, Mar 24, 2020 at 10:42:37AM -0300, Tim Bruijnzeels wrote: > >> As I wrote before, I believe that a single mistake (withheld / > >> unpublished object or even a bit flip) invalidating a whole > >> repository, > > > > Some nuance could be added: it depends on where the error in the > > tree exists. If a top level manifest or CRL is hosted, indeed > > everything underneath it should be tossed. But for instance when a > > manifest 'at 2 levels deep', references a file that doesn't exist, > > you only need to toss that specific manifest (at least). So, yes, > > errors in the repository should result in the repository (or parts > > of it) being considered inadmissible. > > > > RPKI started out on the premise that an unencrypted transport > > (rsync) was acceptable, because everything was signed and > > cryptographically verifiable. Now we are in a situation where the > > transport channel *is* insecure, and the data transmitted across it > > is not properly verified. Validators are *knowingly* proceeding to > > produce VRPs with incomplete, expired, and/or corrupted data. > > With RRDP over HTTPS a lot of in transit / MITM issues are mitigated. I'm not sure I agree - routinator, fort and octorpki are trivially forced to use rsync if the attacker blocks TCP port 443. > The RFC currently still says that invalid certificates should be > accepted though. The thought at the time was that we have object > security and people make too many mistakes configuring HTTPS. With > Letsencrypt I believe this argument no longer holds. Yeah, I recall the discussions ~ a year ago about that section of the RFC. Unfortunately it turns out that we (as RP implementers) appear to lack some checks in the RP software to be able to say we have 'object security'. I also believe that the onus is on the CA operators to correctly configure their HTTPS service. A misconfiguration of HTTP TLS service of the RRDP publication point *should* result in the publication point being dismissed (and perhaps use the local cache for what its worth) > First off I agree with Job that it would be better to disregard > information that is known to be a partial version of the truth. An additional check is needed: if one of the .roa files a manifest references is corrupt (the MITM didn't delete strategically file, but instead filled a .roa file with garbage), the anything referenced in that manifest should be considered invalid. an example, on my MITM box I did 'echo XX > fIeCcC8KpdJQd-olU2APdxNZkyA.roa', so the .roa file exists, but the RP can see there is a mismatch between the hash in the manifest and the hash derive from the fIeCcC8KpdJQd-olU2APdxNZkyA.roa file. If a validator proceeds to output VRPs based on the remaining (parseble) .roa files, you end up with an incomplete set: job@anton ~$ grepcidr 80.128.0.0/11 /var/db/rpki-client/openbgpd 80.128.0.0/12 source-as 3320 80.128.0.0/11 source-as 0 80.128.0.0/11 source-as 3320 80.144.0.0/13 source-as 3320 80.152.0.0/14 source-as 3320 80.156.0.0/16 source-as 3320 80.157.0.0/16 source-as 3320 80.157.8.0/21 source-as 3320 80.157.16.0/20 source-as 3320 80.158.0.0/17 maxlen 24 source-as 34086 80.159.224.0/19 maxlen 24 source-as 2792 In the above eaxmple there should be ~ 19 VRPs in total, fIeCcC8KpdJQd-olU2APdxNZkyA.roa contained 8 VRPs. I suppose we must consider a 'partial withholding attack' equivalent to a 'partially corrupted attack'. In summary: If a manifests references a non-existing file, or if there is a mismatch between the hash listed in the manifest and the hash as derived from the .roa or .crl files, the RP MUST consider the whole manifest invalid and MUST not produce VRPs with the remaining .roa files. Kind regards, Job From nobody Tue Mar 24 07:02:47 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 9F10F3A043D for ; Tue, 24 Mar 2020 07:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 QswNhtc7CwYl for ; Tue, 24 Mar 2020 07:02:43 -0700 (PDT) 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 38CAA3A0407 for ; Tue, 24 Mar 2020 07:02:43 -0700 (PDT) Received: from [192.168.1.6] (unknown [177.37.212.238]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 4894C215EB; Tue, 24 Mar 2020 15:02:40 +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=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1585058560; bh=+Qyekgy53FHIaorZQLYVwErN8zH7Ll3GTDiNaTMKvmQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=VT8wRpLV8p3+aHiC0vISijhebJReU6QVKlEOagZW0ME6rQJ///HXw3NHb/Uc36wi5 EuoN1TQLHlbkEdcsjf2Qe5Yjnb3K3B+LmhJmX4hr5oRnmKmNVMeeOqlI2zaYokn7aJ ruKeqAOB1MTttjGdKFnp1nSbJBYleo91Nm8Vd2xI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 24 Mar 2020 11:02:38 -0300 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> To: Stephen Kent X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 14:02:45 -0000 > On 23 Mar 2020, at 10:33, Stephen Kent = wrote: >=20 > Tim, >> In general I agree. Which is why I mentioned the example of objects = one might find published outside of the context of the RPKI repository, = and *not* listed on a manifest. Such objects have yet to be invented but = theoretically one can think of signed structures under an existing RPKI = CA cert (e.g. using their own embedded EE) - which is shared out-of-band = between parties.=20 > That's a very forward-looking perspective, one I had not considered. >> What I am suggesting is that we *could* update 6486 and make = validation more restrictive regarding manifests: >> - all objects on a manifest must be present and accounted for (I = agree with Job regarding partial withhold attacks) >> - all objects on a manifest need to be validated >> - objects that are not on a manifest can be considered invalid >>=20 >> This is in-line with the specifications defined in RFC 6481 (A = Profile for Resource Certificate Repository Structure), which = essentially says that all current objects must be published, and that no = invalid objects may be published. > agree. >> Then, if the manifest is already a signed statement of everything = that is current, at least regarding the currently defined object types, = as defined in RFC 6481, then what is gained by checking that CA was also = capable of generating a CRL - using the same authoritative key and = publication method - that confirms that the objects that are current = according to the manifest are indeed not revoked? >=20 > I agree that with strict Manifest processing, CRLs provide redundant = info. But, by that argument, why bother checking to see if certs are = expired, since that too is redundant in a strict Manifest processing = scenario? >=20 >> Requiring the CRLs just feels like unnecessary brittleness to me = (again in the context of RFC 6486). It creates multiple loci for bugs in = CA implementations, and complicated error conditions that need to be = checked by RPs. This is what I meant with the perhaps poorly chosen word = 'pedantic'. Maybe I should have used the word 'redundancy'. Redundancy = may seem like a good idea in general, but in this case it really only = allows for the possibility of two conflicting signed messages. Thus it = seems that this does not increase security, but provides more ways for = things to break. >=20 > redundancy is often beneficial in security systems. it helps prevent a = single error from having terrible consequences. But, this strategy works = only if one is flexible when responding to an inconsistency between = redundant pieces of info. >=20 But, redundancy also introduces more moving parts which can break, and = corner conditions to check. Now it's fairly easy to get temporary inconsistencies. If CAs publish = objects one by one, or in case rsync is used as a fetch mechanism (I = believe that objects might change during an rsync 'session'). RRDP can = resolve this, but only if CAs indeed publish their change set as a = single delta. But even with all that, my inner engineer would like to see as few = moving parts as we safely get away with. Failing that I believe one agreed on way to deal with each possible = corner case between MFT and CRL is needed. > Steve >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Mar 24 07:05:19 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 9A4C23A047F for ; Tue, 24 Mar 2020 07:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 VhbpmQQ2xE-W for ; Tue, 24 Mar 2020 07:05:14 -0700 (PDT) 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 31C4D3A077D for ; Tue, 24 Mar 2020 07:05:13 -0700 (PDT) Received: from [192.168.1.6] (unknown [177.37.212.238]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 0A36A21600; Tue, 24 Mar 2020 15:05:10 +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=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1585058711; bh=TTA5Onb7ZxrBo7TCn+yV4oR80zqctl7vo6UKYdmR63k=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ij4lcYTBy8tPwf9wGpXtwPq7gcApPeNnTEMCJA6fH+9v1tmmuh9d2qIOH+HmVmbX6 ceH2pUPpr8vCBihIj/dIFeMNVM59K6O9PQeyYnypworeaobVrvednynKPknUXkzHAi BDtTeuY2OUn9AmcWnwQ66NWrMb+j6aKjgkrKJjxk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 24 Mar 2020 11:05:09 -0300 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <9860FAC3-5473-42EE-B2DC-BBBEF3E1A2FB@nlnetlabs.nl> References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> To: Stephen Kent X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 14:05:16 -0000 > On 24 Mar 2020, at 11:02, Tim Bruijnzeels wrote: >=20 >=20 >=20 >> On 23 Mar 2020, at 10:33, Stephen Kent = wrote: >>=20 >> Tim, >>> In general I agree. Which is why I mentioned the example of objects = one might find published outside of the context of the RPKI repository, = and *not* listed on a manifest. Such objects have yet to be invented but = theoretically one can think of signed structures under an existing RPKI = CA cert (e.g. using their own embedded EE) - which is shared out-of-band = between parties.=20 >> That's a very forward-looking perspective, one I had not considered. >>> What I am suggesting is that we *could* update 6486 and make = validation more restrictive regarding manifests: >>> - all objects on a manifest must be present and accounted for (I = agree with Job regarding partial withhold attacks) >>> - all objects on a manifest need to be validated >>> - objects that are not on a manifest can be considered invalid >>>=20 >>> This is in-line with the specifications defined in RFC 6481 (A = Profile for Resource Certificate Repository Structure), which = essentially says that all current objects must be published, and that no = invalid objects may be published. >> agree. >>> Then, if the manifest is already a signed statement of everything = that is current, at least regarding the currently defined object types, = as defined in RFC 6481, then what is gained by checking that CA was also = capable of generating a CRL - using the same authoritative key and = publication method - that confirms that the objects that are current = according to the manifest are indeed not revoked? >>=20 >> I agree that with strict Manifest processing, CRLs provide redundant = info. But, by that argument, why bother checking to see if certs are = expired, since that too is redundant in a strict Manifest processing = scenario? >>=20 >>> Requiring the CRLs just feels like unnecessary brittleness to me = (again in the context of RFC 6486). It creates multiple loci for bugs in = CA implementations, and complicated error conditions that need to be = checked by RPs. This is what I meant with the perhaps poorly chosen word = 'pedantic'. Maybe I should have used the word 'redundancy'. Redundancy = may seem like a good idea in general, but in this case it really only = allows for the possibility of two conflicting signed messages. Thus it = seems that this does not increase security, but provides more ways for = things to break. >>=20 One more thought.. specifically on this: >> redundancy is often beneficial in security systems. it helps prevent = a single error from having terrible consequences. It's the same engine that signs both CRLs and MFTs. I believe that this = increases the chance of bugs in signing, and orchestration of = publication. And a failure in any of these cases can lead to bad = results. >> But, this strategy works only if one is flexible when responding to = an inconsistency between redundant pieces of info. >>=20 >=20 > But, redundancy also introduces more moving parts which can break, and = corner conditions to check. >=20 > Now it's fairly easy to get temporary inconsistencies. If CAs publish = objects one by one, or in case rsync is used as a fetch mechanism (I = believe that objects might change during an rsync 'session'). RRDP can = resolve this, but only if CAs indeed publish their change set as a = single delta. >=20 > But even with all that, my inner engineer would like to see as few = moving parts as we safely get away with. >=20 > Failing that I believe one agreed on way to deal with each possible = corner case between MFT and CRL is needed. >=20 >=20 >=20 >=20 >> Steve >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Mar 24 07:20:23 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 368CF3A0822 for ; Tue, 24 Mar 2020 07:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=no autolearn_force=no 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 y73uRQZsNTOg for ; Tue, 24 Mar 2020 07:20:15 -0700 (PDT) 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 AB3283A0811 for ; Tue, 24 Mar 2020 07:20:13 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 1EDC12165A; Tue, 24 Mar 2020 15:20:10 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Tue, 24 Mar 2020 15:20:09 +0100 From: Martin Hoffmann To: Job Snijders Cc: Tim Bruijnzeels , SIDR Operations WG Message-ID: <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> In-Reply-To: <20200324135828.GG60268@vurt.meerval.net> References: <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 14:20:22 -0000 Job Snijders wrote: > On Tue, Mar 24, 2020 at 10:42:37AM -0300, Tim Bruijnzeels wrote: > > > > With RRDP over HTTPS a lot of in transit / MITM issues are > > mitigated. > > I'm not sure I agree - routinator, fort and octorpki are trivially > forced to use rsync if the attacker blocks TCP port 443. At least Routinator does not fall back to rsync once it has successfully completed accessing the repository via RRDP once. I am open to strengthen this to not ever use rsync if there is a RRDP URI in the certificate. Kind regards, Martin From nobody Tue Mar 24 08:11:28 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 BD3543A0B07 for ; Tue, 24 Mar 2020 08:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 DrSUXhvXPX4Y for ; Tue, 24 Mar 2020 08:11:06 -0700 (PDT) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 36DC33A0C16 for ; Tue, 24 Mar 2020 08:11:06 -0700 (PDT) Received: by mail-wm1-f45.google.com with SMTP id g62so3907297wme.1 for ; Tue, 24 Mar 2020 08:11:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=7hFy4NRASjK2KGeo+tpWuTDXDqOAlN6L6RWtsXtMP3k=; b=AhlpsmMdTcXFGAh948WJy01WDxtYhz53tTaH/9BjzoM4Q4c2CWgtk7UVNf8e0voPll WZfRT1aVDTnVKSONEuY/Rfc1S4OSOUNe9RRbdGJOj7xW+DPsSGxRkgvrjv6NK+hFDo9d GDHu3hfya8NPLXZNBOq7KZvpqv3yb2e3X8gDNHcPEdPjIwGCo/gdb2NxN1UV82gh5Bpc 0N9RqpsQQG7/Vp0qxX20CamKqkdIRh/I3uT9y2NN+RrLgbmbcqMJVS860TxuR2VRmBRC V/6T8TmeTLwTFXgIADZQ2vVYJaD2sS1R+cAWS/YNQkySqRAzUs5Z59DhpA9VcdapU15Z u4Sg== X-Gm-Message-State: ANhLgQ3gTHHoxqrFQ8wUl+g1rTUqDLaXOv9TMlRO7bOGBUxXEnvgyCKD G2xQwy7KlwxOJiIUNuZnIKaa8A== X-Google-Smtp-Source: ADFU+vsXWwpeZBmd4uIksAECPJe5txISC33I6LWujcn6UEkE0cBca8FEmdw3gBncryt1BziO8zArnw== X-Received: by 2002:a1c:9d0b:: with SMTP id g11mr6250261wme.77.1585062664407; Tue, 24 Mar 2020 08:11:04 -0700 (PDT) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id l83sm4682858wmf.43.2020.03.24.08.11.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2020 08:11:03 -0700 (PDT) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id cc8988db; Tue, 24 Mar 2020 15:11:02 +0000 (UTC) Date: Tue, 24 Mar 2020 15:11:01 +0000 From: Job Snijders To: Martin Hoffmann Cc: Tim Bruijnzeels , SIDR Operations WG Message-ID: <20200324151101.GH60268@vurt.meerval.net> References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 15:11:26 -0000 On Tue, Mar 24, 2020 at 03:20:09PM +0100, Martin Hoffmann wrote: > Job Snijders wrote: > > I'm not sure I agree - routinator, fort and octorpki are trivially > > forced to use rsync if the attacker blocks TCP port 443. > > At least Routinator does not fall back to rsync once it has > successfully completed accessing the repository via RRDP once. I am > open to strengthen this to not ever use rsync if there is a RRDP URI > in the certificate. I'm interpreting the willingness to attempt to make MITM attack slightly harder as an indicator that the described MITM partial withholding/corruption attack scenarios are valid and problematic. :-) I don't think a conclusion about the integrity of the DELTA snapshot can be derived from the fetch mechanism itself: just because it was retrieved over HTTPS doesn't mean there was no MITM attack. The diginotar situation comes to mind, and crazier things have existed in the wild. The hashes used in the RRDP file format provide a degree of integrity checking useful for the filetransfer itself, but don't seem to be meant to verify any authenticity. This to me means that after downloading and unpacking the RRDP snapshot, we still have to assume the data may have been meddled with and some strategic files might have been either corrupted or are missing. The decision tree I see currently as 'safer' would be as following: 1) are all files referenced in a given manifest present? 2) do the hashes as listed inside the manifest match the contents of the referenced files? 3) is the CRL present and valid? 4) are all of the relevant signatures from not-revoked keys? If the answer to any of the above questions is 'no', I think the leaf of the tree at hand should be considered invalid to prevent tainting the RFC 6811 validation procedure with incomplete data. Kind regards, Job From nobody Tue Mar 24 08:36:25 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 07BBE3A08B6 for ; Tue, 24 Mar 2020 08:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 frfXsak5jC7u for ; Tue, 24 Mar 2020 08:36:21 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 30DAE3A08B5 for ; Tue, 24 Mar 2020 08:36:21 -0700 (PDT) Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jGlbH-0006tx-LT; Tue, 24 Mar 2020 16:36:19 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::2aa]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jGlbH-0006aA-I2; Tue, 24 Mar 2020 16:36:19 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Oleg Muravskiy In-Reply-To: <20200324151101.GH60268@vurt.meerval.net> Date: Tue, 24 Mar 2020 16:36:19 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <3DE1004F-00BA-4A2F-AED2-D0900B4EF84E@ripe.net> References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> To: Job Snijders X-Mailer: Apple Mail (2.3608.60.0.2.5) X-ACL-Warn: Delaying message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b744451ee5fc64e9cd8f96750ed5f9ca6bd Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 15:36:24 -0000 > On 24 Mar 2020, at 16:11, Job Snijders wrote: >=20 > On Tue, Mar 24, 2020 at 03:20:09PM +0100, Martin Hoffmann wrote: >> Job Snijders wrote: >>> I'm not sure I agree - routinator, fort and octorpki are trivially >>> forced to use rsync if the attacker blocks TCP port 443. >>=20 >> At least Routinator does not fall back to rsync once it has >> successfully completed accessing the repository via RRDP once. I am >> open to strengthen this to not ever use rsync if there is a RRDP URI >> in the certificate.=20 >=20 > I'm interpreting the willingness to attempt to make MITM attack = slightly > harder as an indicator that the described MITM partial > withholding/corruption attack scenarios are valid and problematic. :-) >=20 > I don't think a conclusion about the integrity of the DELTA snapshot = can > be derived from the fetch mechanism itself: just because it was > retrieved over HTTPS doesn't mean there was no MITM attack. The > diginotar situation comes to mind, and crazier things have existed in > the wild. >=20 > The hashes used in the RRDP file format provide a degree of integrity > checking useful for the filetransfer itself, but don't seem to be = meant > to verify any authenticity. This to me means that after downloading = and > unpacking the RRDP snapshot, we still have to assume the data may have > been meddled with and some strategic files might have been either > corrupted or are missing. >=20 > The decision tree I see currently as 'safer' would be as following: >=20 > 1) are all files referenced in a given manifest present? > 2) do the hashes as listed inside the manifest match the contents of = the referenced files? > 3) is the CRL present and valid? > 4) are all of the relevant signatures from not-revoked keys? >=20 > If the answer to any of the above questions is 'no', I think the leaf = of > the tree at hand should be considered invalid to prevent tainting the > RFC 6811 validation procedure with incomplete data. >=20 > Kind regards, >=20 > Job Job, Your examples so far have showed that continuing with incomplete set of = ROAs after a withhold/manipulation on ROA objects might create dangerous = situation. Are there scenarios where withholding / making invalid a certificate, = for example, leads to a similar danger? I wonder if this is specific to ROA objects only, and whether we should = treat them differently. If it is, then we could =E2=80=9Cignore=E2=80=9D = all published ROAs at the specific publication point, but continue = validation to child certificates and their sub-trees. Oleg From nobody Tue Mar 24 08:38: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 2BD873A0C04 for ; Tue, 24 Mar 2020 08:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 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, RCVD_IN_MSPIKE_H2=-1.463, 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=verizon.net 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 L3w2TOkfCtj6 for ; Tue, 24 Mar 2020 08:38:22 -0700 (PDT) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (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 C4EBB3A0BDE for ; Tue, 24 Mar 2020 08:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585064300; bh=Fg86v8sRy9ntKDRW9e/U3Gx1Jo90nRVTE8JXA50sr+c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=efE30TX52EYTXMiHHgLonl+ucAUkfREGD74QxGWszivM+DR5UWYGoSWbV50YLcS1JEcxb+I7mUA6R2YW4pyDq910NGg/mMZqZLqDdUNE5NuvBo5d6M7spamuURjURfTqw9omwJ6nHOlPbuH1/Fl/7j/+obe0zNRQy7OqwOzD7H5pZtZwOWBn3iDGjna0Ulc/QXCkhFLBI52/wwHqdrzIhsR2iq22wXaXei4cJlKaJyCw+B7chCvx0jQoK8aU98MMWpRbV0fgbyUwzxUKpJYi2kDDPvfRtnQsqB5wxs762oGDOkss5Q1qSrHyu3Cvjgf9iZbd0+roRih8dnwqVdznjw== X-YMail-OSG: RPlqmw4VM1nOgL3kr1P5vzFf87pszgpMiEEnqfp1Ua4ZBsWPJ9cI8pBh4nLicOC n2930COyFMMxUEyxFgcQfq2d.AxGEH95FdffjC_jBb2eheZM2xMXkn3QWxmMGb8tL6l_hfwxQdd0 u5CCse8dS7yBoxGKaXhf7WYwZyzq4nSRxbboEy_Z0lBDfhF.hJAerjE3BurHqQ.gb3JYuNx7LOcT VN7rjrKTxHxpi0cS3AkFlsicVt44Wkg0lFQtH6FWEGqtEJ.tTN0fzo8v0jnWzok8.jX6RbVbm_jb vuCmCDeCxHHJT0cMLbzULnwaRqLSdI3e2jp.dO7QFAFPY7Apd7y5sGhdTGWY4uOzPAjJNT9K17iO .JYT6ZGgYItYa0eu00G8Wulwiza6ylWhpLXfYJhZgNUFdZdYhW0xhVnEzUE2SVaJlb4Qgec31LC_ Cthv6aRKW2jwBZH_HmIi5zmtfuJJ.mfjuiDqe49t18BrKvpQXtWhp1U138.oLaOqI3h.OZe_Co25 j.MbwS8w1z3V6GA9VsnBjUjlC8oz9JqOyc3dHbmA2oQad7ZD_xY7miYnFjS0C3qFcT7DMmOTY0vg Tkt5milznfDh7TN9z6DwliesrjIMKD7DYDAH_hoUGjYLCvIco1elLOF5DLsm6KGextFX1PG8ILlX C1d1aiuDlbsUVw5xcTTIN_7odDGx6SesbhexVvjGrtZkupM0a7tTUWUSZ4M2PI1p6Mu3wAJRL_uG u6miyA1LJzZqN8A3gk.D356rxfOvUHWYBsGsJCaqFSrqLbANYNe2EdDvvlb47rx0fq0cn3o5GVG0 AWnr4TvibJqwxryZ8zQp0r9q_EQfayFBL35xTSoQIpB3IrA60fYkuPdKctjALwYfY6PTMV9JzOwy 1UW5NVvkPcseXBhFhBgHJ6RpX5wX3nLiLkyrrzZv4u6BIObKj6q.1jAtM01Yy1KRhfvioVx7ImjI MwiW_hjjANIF4zab1mkzmXpwfYGnLc8C8wWGb_6QozSCYNmCzkKv255TgvrflyCvqt7Q_fesdGxP 1aKAc5U7SCPkBqLu763VoWF0zkbzpIyxOkeroaAiGKki8PDYl2Anu9vlaQ__lY3OjTzDN9Ln6ojW bwjsbrheWtCLn75.MUAL_.0qaf.jf5eu6zXO8ALHwBK4WNAGvC7Zqv8IrEAUjCntKFqfABO0ZtjH PLZpVbvY..5ucx9lBN9JVDbphDxn1JuB3Wg5MZjxNpycHnplTsGV2889bZKfTIkPzxXc7s_fbwc_ IueYnmwCUAY5GPKHD2dZfxn.3UmU5He2j8O0yHmk1yPJm_OErTNMXOEqAbdzPSTw5cJkd0RfF.3u hbEE2VF6zUBXY7InbU3cFLJi43TZ67Y_at7hl3ZBXXh8NJwp_0Nn_8HbZlTLidpgIs8cAuuP0Is_ TSuYPiWvlW3FYFL1CqCaRVJlJTiDOgw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Tue, 24 Mar 2020 15:38:20 +0000 Received: by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 98143ce3d8f924c6fb805513f9023641; Tue, 24 Mar 2020 15:38:18 +0000 (UTC) To: Tim Bruijnzeels Cc: SIDR Operations WG References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> From: Stephen Kent Message-ID: Date: Tue, 24 Mar 2020 11:38:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_242) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 15:38:40 -0000 Tim, > >> redundancy is often beneficial in security systems. it helps prevent a single error from having terrible consequences. But, this strategy works only if one is flexible when responding to an inconsistency between redundant pieces of info. >> > But, redundancy also introduces more moving parts which can break, and corner conditions to check. > > Now it's fairly easy to get temporary inconsistencies. If CAs publish objects one by one, or in case rsync is used as a fetch mechanism (I believe that objects might change during an rsync 'session'). RRDP can resolve this, but only if CAs indeed publish their change set as a single delta. yes, it is possible that a pub point may be updated during a sync operation, and thus an inconsistent set of objects will be retrieved. I would expect well-written RP code to detect this and try again, after a brief delay. For the rsynch case, one should create a new directory with all of the objects and then change the pub point to be the new directory, to make for a more "atomic" update procedure. > But even with all that, my inner engineer would like to see as few moving parts as we safely get away with.  if one changes to a model in which the Manifest is the sole arbiter of cert validity, i.e., if a cert is included in a current manifest and it's signature can be validated via cert path in the RPKI, the why bother with checking cert expiration? Same for ROAs. This is a slippery slope. > Failing that I believe one agreed on way to deal with each possible corner case between MFT and CRL is needed. How many corner cases are there? Steve From nobody Tue Mar 24 08:38:47 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 7527A3A0C16 for ; Tue, 24 Mar 2020 08:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 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, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 w1r7wWckq2zF for ; Tue, 24 Mar 2020 08:38:22 -0700 (PDT) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (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 C6E033A0C0D for ; Tue, 24 Mar 2020 08:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585064300; bh=Fg86v8sRy9ntKDRW9e/U3Gx1Jo90nRVTE8JXA50sr+c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=efE30TX52EYTXMiHHgLonl+ucAUkfREGD74QxGWszivM+DR5UWYGoSWbV50YLcS1JEcxb+I7mUA6R2YW4pyDq910NGg/mMZqZLqDdUNE5NuvBo5d6M7spamuURjURfTqw9omwJ6nHOlPbuH1/Fl/7j/+obe0zNRQy7OqwOzD7H5pZtZwOWBn3iDGjna0Ulc/QXCkhFLBI52/wwHqdrzIhsR2iq22wXaXei4cJlKaJyCw+B7chCvx0jQoK8aU98MMWpRbV0fgbyUwzxUKpJYi2kDDPvfRtnQsqB5wxs762oGDOkss5Q1qSrHyu3Cvjgf9iZbd0+roRih8dnwqVdznjw== X-YMail-OSG: RPlqmw4VM1nOgL3kr1P5vzFf87pszgpMiEEnqfp1Ua4ZBsWPJ9cI8pBh4nLicOC n2930COyFMMxUEyxFgcQfq2d.AxGEH95FdffjC_jBb2eheZM2xMXkn3QWxmMGb8tL6l_hfwxQdd0 u5CCse8dS7yBoxGKaXhf7WYwZyzq4nSRxbboEy_Z0lBDfhF.hJAerjE3BurHqQ.gb3JYuNx7LOcT VN7rjrKTxHxpi0cS3AkFlsicVt44Wkg0lFQtH6FWEGqtEJ.tTN0fzo8v0jnWzok8.jX6RbVbm_jb vuCmCDeCxHHJT0cMLbzULnwaRqLSdI3e2jp.dO7QFAFPY7Apd7y5sGhdTGWY4uOzPAjJNT9K17iO .JYT6ZGgYItYa0eu00G8Wulwiza6ylWhpLXfYJhZgNUFdZdYhW0xhVnEzUE2SVaJlb4Qgec31LC_ Cthv6aRKW2jwBZH_HmIi5zmtfuJJ.mfjuiDqe49t18BrKvpQXtWhp1U138.oLaOqI3h.OZe_Co25 j.MbwS8w1z3V6GA9VsnBjUjlC8oz9JqOyc3dHbmA2oQad7ZD_xY7miYnFjS0C3qFcT7DMmOTY0vg Tkt5milznfDh7TN9z6DwliesrjIMKD7DYDAH_hoUGjYLCvIco1elLOF5DLsm6KGextFX1PG8ILlX C1d1aiuDlbsUVw5xcTTIN_7odDGx6SesbhexVvjGrtZkupM0a7tTUWUSZ4M2PI1p6Mu3wAJRL_uG u6miyA1LJzZqN8A3gk.D356rxfOvUHWYBsGsJCaqFSrqLbANYNe2EdDvvlb47rx0fq0cn3o5GVG0 AWnr4TvibJqwxryZ8zQp0r9q_EQfayFBL35xTSoQIpB3IrA60fYkuPdKctjALwYfY6PTMV9JzOwy 1UW5NVvkPcseXBhFhBgHJ6RpX5wX3nLiLkyrrzZv4u6BIObKj6q.1jAtM01Yy1KRhfvioVx7ImjI MwiW_hjjANIF4zab1mkzmXpwfYGnLc8C8wWGb_6QozSCYNmCzkKv255TgvrflyCvqt7Q_fesdGxP 1aKAc5U7SCPkBqLu763VoWF0zkbzpIyxOkeroaAiGKki8PDYl2Anu9vlaQ__lY3OjTzDN9Ln6ojW bwjsbrheWtCLn75.MUAL_.0qaf.jf5eu6zXO8ALHwBK4WNAGvC7Zqv8IrEAUjCntKFqfABO0ZtjH PLZpVbvY..5ucx9lBN9JVDbphDxn1JuB3Wg5MZjxNpycHnplTsGV2889bZKfTIkPzxXc7s_fbwc_ IueYnmwCUAY5GPKHD2dZfxn.3UmU5He2j8O0yHmk1yPJm_OErTNMXOEqAbdzPSTw5cJkd0RfF.3u hbEE2VF6zUBXY7InbU3cFLJi43TZ67Y_at7hl3ZBXXh8NJwp_0Nn_8HbZlTLidpgIs8cAuuP0Is_ TSuYPiWvlW3FYFL1CqCaRVJlJTiDOgw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Tue, 24 Mar 2020 15:38:20 +0000 Received: by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 98143ce3d8f924c6fb805513f9023641; Tue, 24 Mar 2020 15:38:18 +0000 (UTC) To: Tim Bruijnzeels Cc: SIDR Operations WG References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> From: Stephen Kent Message-ID: Date: Tue, 24 Mar 2020 11:38:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_242) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 15:38:41 -0000 Tim, > >> redundancy is often beneficial in security systems. it helps prevent a single error from having terrible consequences. But, this strategy works only if one is flexible when responding to an inconsistency between redundant pieces of info. >> > But, redundancy also introduces more moving parts which can break, and corner conditions to check. > > Now it's fairly easy to get temporary inconsistencies. If CAs publish objects one by one, or in case rsync is used as a fetch mechanism (I believe that objects might change during an rsync 'session'). RRDP can resolve this, but only if CAs indeed publish their change set as a single delta. yes, it is possible that a pub point may be updated during a sync operation, and thus an inconsistent set of objects will be retrieved. I would expect well-written RP code to detect this and try again, after a brief delay. For the rsynch case, one should create a new directory with all of the objects and then change the pub point to be the new directory, to make for a more "atomic" update procedure. > But even with all that, my inner engineer would like to see as few moving parts as we safely get away with.  if one changes to a model in which the Manifest is the sole arbiter of cert validity, i.e., if a cert is included in a current manifest and it's signature can be validated via cert path in the RPKI, the why bother with checking cert expiration? Same for ROAs. This is a slippery slope. > Failing that I believe one agreed on way to deal with each possible corner case between MFT and CRL is needed. How many corner cases are there? Steve From nobody Tue Mar 24 08:41:28 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 EB7DE3A0C65 for ; Tue, 24 Mar 2020 08:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 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, RCVD_IN_MSPIKE_H2=-1.463, 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=verizon.net 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 FNCnb5IjmDVd for ; Tue, 24 Mar 2020 08:41:07 -0700 (PDT) Received: from sonic313-56.consmr.mail.ne1.yahoo.com (sonic313-56.consmr.mail.ne1.yahoo.com [66.163.185.31]) (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 8C5F33A0C0D for ; Tue, 24 Mar 2020 08:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585064466; bh=0dcjorPk4mjaTJBwbIFxFEZe9MgY0vPSYTQqP8aYQoI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=kPhyVyRXFf7dIBFYtpZIGTR3rChDOb6yY3YUUN2pkPNLt7DZk6qJP1X7DIJ3oqW0v4OJrvhn52NwcENnjwA+53aCQfKb+1gFEhXArHdpjJriifd0OKb4jHBs0KWBbV/vuwdDOZts78io2HLf9kuHLvOPh5bBXiRnzM1hpXfYsmnugtw3alTHS5IZ4AJOXKQVJorUbQXyXrG0XHkReYbA3WFoJcInUUagonaoXiDrqm6E3i4WjnSz9lMmxY1D+fjKbmti/L18V2g1B6ZUPJ1oGnMbqXei929y+da+xWb+IbGqTVNkPnSvgwdoTmSfvow9QrJxslJdIOszPiHW3GOudQ== X-YMail-OSG: IUlPje4VM1mFI9dYBvlp5_BA89p0Q.IlQsZ.mgbhETANyhKlxHm0_7EUY7BCXiN wVzojrkw64YZvrSb2BEOpTFIMMXr9j97Q2P9wj2AzxqMMTShGmCMbaHkCO54F3zjM9bofk6NTCzd vRFGY7SjIC9KxXyOsn8yVXSR_x4M1BV_w3n0dyYQ09j_WgV9HcACVqxyhcRRPF5yDJa1AapLoZ8o iN_LGgJ0lf97awOPn26w_kosN3mWTL.NdNjtANARhiNhkBVYo_K2gCeeqAXWQwKhhbVRTb4LPRRr EG1v4jbmHEhNMl.Io8bUjtmWwjhecnuUu1UapKzpoXZVTQFYEHe2FB0YIgWo2rg1ktxDI8Iwy5oB dwxCQiLkfJ5oS2Q_API.Askot1Sj7zWPAPetBXTQJ87iKVoeQLJjIABPIHEM24PHa1EObPeMHPn1 3E4zZT6K8jfdypwlqkq.dyYUfPsQEv9vJ_5.9M6vGnXMSKxkPK7l6Zj_PufneY4pvXEKk8jja_6H m56r0K23HxckjoVzFVYrnZhU4MzXi360MP9vYj74yey9QCxNx0sHRaDDfj0gxzRDaR3zjO.zsAL0 FIo8e9JAMpqW5kVEmvQEIP_QIM9nmFYkRHeZoPxC8bXyriLMCLAJCptdgS.HBQMLmfmyOLqX4BD1 6Mp893nMwmOG9OqHfTgyY4GAbIUP_YfTSjcgCYYXpyvOihs.lNrayQokCtFXf9aDil.IFKFEZzEu gP2TAteNqCTJoT3HL5agivTg5lSdmxwLzm8_663b6DDJFeCemqTGYtvo40L2KAHo.I82qmRH7h5V WQPZW1X6o8lgG099K0C7aEoO2We2HMGOzlfGR6FfF6T0m1Yi9.OV7yObzNUVlv5LbcAz0GKdjvOa evQgGBK5lhnmKEw1S05.DAjtXtckpNOydegk78HXeQs7oeQvXQx2JPVPo9aKllPbnxG15UeJE8HT vv1Q8HjerRxfVltxmKAWMXvYgwxYLd3M6shD.QMFTFEWmmwN0Jhr5r_Juxs9mxwZk8_xRr2_inv4 SOFn.gLxBaiU64J6A6gQ5JoArgpRHFpOtA22sIDO1JKPe2BN_t7XtZsNTnYpsAhD8EtEMdIiJNzJ UJFrkQP3LdF.z0WMG19suvUiGM07DcoZeTvEFB0Qj8MqsYIjIagOrqrv01Xo6L1fiYbPsw1jBD8c jc5UKQiRfUiX6Ao0XdomUsmfyllmgBkkPck1oLaAilwlkRoKsfCNugQDQyOBrJkw7e5O2bh.Nc7x CsQIG1QUEBEYY1xpxRreVbGPK00X2ydysFhxJtjGaW3C4tBHJmEFTG2Vh1FMPd6LbCz37Kh2T2CD q5U1QmGgzC4_tsW.bWUkhtFMfCyK1FuFXUssB8_h2baThDS3LI3PWck78FeDX95pJJfAiOsvVJ_z LR5rlhHKogNaSSuAWs7l728yW Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Tue, 24 Mar 2020 15:41:06 +0000 Received: by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bf34da7b2fec840e9019b28be4abebfc; Tue, 24 Mar 2020 15:41:05 +0000 (UTC) To: Tim Bruijnzeels Cc: SIDR Operations WG References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <9860FAC3-5473-42EE-B2DC-BBBEF3E1A2FB@nlnetlabs.nl> From: Stephen Kent Message-ID: <01560d7d-6378-eadd-0cc5-476a429cc3eb@verizon.net> Date: Tue, 24 Mar 2020 11:41:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <9860FAC3-5473-42EE-B2DC-BBBEF3E1A2FB@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_242) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 15:41:26 -0000 Tim, > > One more thought.. specifically on this: > >>> redundancy is often beneficial in security systems. it helps prevent a single error from having terrible consequences. > > It's the same engine that signs both CRLs and MFTs. I believe that this increases the chance of bugs in signing, and orchestration of publication. And a failure in any of these cases can lead to bad results. Any bugs in the software that manages MFTs and CRLs is of concern. If one cannot manage to do both jobs correctly then maybe one ought not be running an RPKI CA. Steve From nobody Tue Mar 24 08:41:33 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 B20713A0C3A for ; Tue, 24 Mar 2020 08:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 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, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 O7R0bH7In-cb for ; Tue, 24 Mar 2020 08:41:07 -0700 (PDT) Received: from sonic313-56.consmr.mail.ne1.yahoo.com (sonic313-56.consmr.mail.ne1.yahoo.com [66.163.185.31]) (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 834A13A08FB for ; Tue, 24 Mar 2020 08:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585064466; bh=0dcjorPk4mjaTJBwbIFxFEZe9MgY0vPSYTQqP8aYQoI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=kPhyVyRXFf7dIBFYtpZIGTR3rChDOb6yY3YUUN2pkPNLt7DZk6qJP1X7DIJ3oqW0v4OJrvhn52NwcENnjwA+53aCQfKb+1gFEhXArHdpjJriifd0OKb4jHBs0KWBbV/vuwdDOZts78io2HLf9kuHLvOPh5bBXiRnzM1hpXfYsmnugtw3alTHS5IZ4AJOXKQVJorUbQXyXrG0XHkReYbA3WFoJcInUUagonaoXiDrqm6E3i4WjnSz9lMmxY1D+fjKbmti/L18V2g1B6ZUPJ1oGnMbqXei929y+da+xWb+IbGqTVNkPnSvgwdoTmSfvow9QrJxslJdIOszPiHW3GOudQ== X-YMail-OSG: IUlPje4VM1mFI9dYBvlp5_BA89p0Q.IlQsZ.mgbhETANyhKlxHm0_7EUY7BCXiN wVzojrkw64YZvrSb2BEOpTFIMMXr9j97Q2P9wj2AzxqMMTShGmCMbaHkCO54F3zjM9bofk6NTCzd vRFGY7SjIC9KxXyOsn8yVXSR_x4M1BV_w3n0dyYQ09j_WgV9HcACVqxyhcRRPF5yDJa1AapLoZ8o iN_LGgJ0lf97awOPn26w_kosN3mWTL.NdNjtANARhiNhkBVYo_K2gCeeqAXWQwKhhbVRTb4LPRRr EG1v4jbmHEhNMl.Io8bUjtmWwjhecnuUu1UapKzpoXZVTQFYEHe2FB0YIgWo2rg1ktxDI8Iwy5oB dwxCQiLkfJ5oS2Q_API.Askot1Sj7zWPAPetBXTQJ87iKVoeQLJjIABPIHEM24PHa1EObPeMHPn1 3E4zZT6K8jfdypwlqkq.dyYUfPsQEv9vJ_5.9M6vGnXMSKxkPK7l6Zj_PufneY4pvXEKk8jja_6H m56r0K23HxckjoVzFVYrnZhU4MzXi360MP9vYj74yey9QCxNx0sHRaDDfj0gxzRDaR3zjO.zsAL0 FIo8e9JAMpqW5kVEmvQEIP_QIM9nmFYkRHeZoPxC8bXyriLMCLAJCptdgS.HBQMLmfmyOLqX4BD1 6Mp893nMwmOG9OqHfTgyY4GAbIUP_YfTSjcgCYYXpyvOihs.lNrayQokCtFXf9aDil.IFKFEZzEu gP2TAteNqCTJoT3HL5agivTg5lSdmxwLzm8_663b6DDJFeCemqTGYtvo40L2KAHo.I82qmRH7h5V WQPZW1X6o8lgG099K0C7aEoO2We2HMGOzlfGR6FfF6T0m1Yi9.OV7yObzNUVlv5LbcAz0GKdjvOa evQgGBK5lhnmKEw1S05.DAjtXtckpNOydegk78HXeQs7oeQvXQx2JPVPo9aKllPbnxG15UeJE8HT vv1Q8HjerRxfVltxmKAWMXvYgwxYLd3M6shD.QMFTFEWmmwN0Jhr5r_Juxs9mxwZk8_xRr2_inv4 SOFn.gLxBaiU64J6A6gQ5JoArgpRHFpOtA22sIDO1JKPe2BN_t7XtZsNTnYpsAhD8EtEMdIiJNzJ UJFrkQP3LdF.z0WMG19suvUiGM07DcoZeTvEFB0Qj8MqsYIjIagOrqrv01Xo6L1fiYbPsw1jBD8c jc5UKQiRfUiX6Ao0XdomUsmfyllmgBkkPck1oLaAilwlkRoKsfCNugQDQyOBrJkw7e5O2bh.Nc7x CsQIG1QUEBEYY1xpxRreVbGPK00X2ydysFhxJtjGaW3C4tBHJmEFTG2Vh1FMPd6LbCz37Kh2T2CD q5U1QmGgzC4_tsW.bWUkhtFMfCyK1FuFXUssB8_h2baThDS3LI3PWck78FeDX95pJJfAiOsvVJ_z LR5rlhHKogNaSSuAWs7l728yW Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Tue, 24 Mar 2020 15:41:06 +0000 Received: by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bf34da7b2fec840e9019b28be4abebfc; Tue, 24 Mar 2020 15:41:05 +0000 (UTC) To: Tim Bruijnzeels Cc: SIDR Operations WG References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <9860FAC3-5473-42EE-B2DC-BBBEF3E1A2FB@nlnetlabs.nl> From: Stephen Kent Message-ID: <01560d7d-6378-eadd-0cc5-476a429cc3eb@verizon.net> Date: Tue, 24 Mar 2020 11:41:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <9860FAC3-5473-42EE-B2DC-BBBEF3E1A2FB@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_242) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 15:41:27 -0000 Tim, > > One more thought.. specifically on this: > >>> redundancy is often beneficial in security systems. it helps prevent a single error from having terrible consequences. > > It's the same engine that signs both CRLs and MFTs. I believe that this increases the chance of bugs in signing, and orchestration of publication. And a failure in any of these cases can lead to bad results. Any bugs in the software that manages MFTs and CRLs is of concern. If one cannot manage to do both jobs correctly then maybe one ought not be running an RPKI CA. Steve From nobody Tue Mar 24 08:52:11 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 711333A0CE3 for ; Tue, 24 Mar 2020 08:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 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, RCVD_IN_MSPIKE_H2=-1.463, 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=verizon.net 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 TMORsIBed0JZ for ; Tue, 24 Mar 2020 08:51:51 -0700 (PDT) Received: from sonic304-21.consmr.mail.ne1.yahoo.com (sonic304-21.consmr.mail.ne1.yahoo.com [66.163.191.147]) (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 17D8E3A0CCD for ; Tue, 24 Mar 2020 08:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585065110; bh=AI0mD0HP9LwuPLkLuu124VrYThbTC/gq2SrcUzROm3Q=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=VEzNAMM1UdtAbvwgDAbSAJWeMHLMzUat8g+HG8ZxFFh2CAUOjMw9C2qeGebGmPYMhbZoCuExgvLjz9AfMjDgz2PpaiYsnEibET+UJm8FP39amRbrcghzdGG7kTgAfUzg4E4+UyC1hoOfYXYKhnTU55e/9IGn5uIXnnr+eJSyvrr4S1zLvtjxfFAXB2JUmHJNrPVkQ/gAb+aSBeK0sjpluleXUaGhu9Sgrq99sxrrciJFAvx50WgxxxZNtBL+PzXjZ5X3eLD98jxffAtuXjlI11OtNf+j5qSmIKlt0upuEhp+MasMETodikILTi9ui+uWFah2XJtZw9tNj97EFQLQog== X-YMail-OSG: sdVKdnYVM1nXA2CbmrLVjNNC.5Rx7dV7u6yaWJ28Q7NIwpTXu8zANmcH5PpQnJ0 Zeybr1jGKHvyiZqXxM77mqYrai4KWH2ckmz_zETPynFQe0myXuRPj0HSsmJs6KdsYvwsLOkHpp8b jY8FWht6d46efu40kAwnPlLrnjVC9SlQEVGzNL2gQEF_ykDOqZcsAg71p96rUoxgzwg5aeZb12s. EHBCipreMAmVUJ77hZPU0ru5_l7bQrYyi3xKRpqxND8qpt.YV3bpYPBmRYfvi8PVVUhv0wLtN.Tu 9USUdVDkje0LG3EmqX902X6xC16M__iaV_Lq12ujf7dj37JV9mY7cqFJOLHd882RJOqfiR6G8hO0 TQXcMXZB.ykdCmakru.51HqS.MFZwsouU2Yqqu4nMRThRTeEisDb8.UYl9cBBFBmQh7jKTCamXN5 0RXCK0Fnb4MoUZCT_9E0QgSzRDkfgb72.Dyil6TishqtTaTv3Q.qQ.MvOO82XErP1IQDvEkEeKB0 1zbPYi2RX0uz6WrOgYkMfC40M0xD7l30WkQFiOIljIdVM1OxPYhaNbFKxgeEchog4gvBau5ZFkHC Rb9sZdB6ZRdY_ikFa6LyydDDIeUGWmWdAHoW.o7X7xqinA.AY80RR.oMvD0RZHXQALoS7bSR6LSd zh4mQx.IPhauxM8BLGWRdb..AbViQHfdvTdJd.O2kwRItF.aakMxopvOEzEZTA413Q00X7Sr2pSS cMaO1NpQZ8If7dDK473xrNpYvh_K0CqwJGV7JChRPfyEI.n0og6WIo_Z6lrVAkfIkTkXq339Z338 nEXTCRpcX4T90U3j_nI6PBmh.HiKvhXAdan.Vx0tSf0z9iLsRkVY0sakwWsa8XHwaTINSID.JWuR bIJK7vLXetwejXB8c3ZPyahhtZnVGbDZBIiyga4OaNoO2qMnmO9ognX8GRhBHxH3yMQk9TdvzaoC jpXkWt62z20LpHaDDY4khi8QUxLJwtMPd7g9ETvFboqP5udfT0sFRjIxEGE3xy0xJJ5R0DWSK5BQ 0ifE0tTeGVttzWGcHV.TUJ0JvRph4ETXbBxHrYhYvX4vug3o9VT57yBGhEpxaPyaL3nwPmDnRtJP CHlmkXsj4_SybWTRNNypXdGmnJW47TyeSK65teFMbU_vCZbf0GvYAvMT0plyWHlc5lyTXm8_hadn rxXE0kGrmx.mva0K_P1wk_VoMaONuELq9b_oobbuEuVlx.rKBnJf8.jzljKHt4Yy6b9SCUNkou_m xkp4vxZbJTpEVu1jzyNDNWSJ4lI1mHlf22UlH5Ccn7Pmbdl5.sfJNm4HUps9GnrecPvwx_bzS2YA bVlzaA.BTjuWwqoYt6TEO341y38j1No_lM0mdrnoEYLzVLqc4OaxvLOADSjgzyI4pMvcfUL1fzPG 9ft8ifUlmFxER5A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Tue, 24 Mar 2020 15:51:50 +0000 Received: by smtp415.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f2bc0085698b5c9c6e4bbadeef970e5e; Tue, 24 Mar 2020 15:51:48 +0000 (UTC) To: sidrops@ietf.org References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> From: Stephen Kent Message-ID: <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> Date: Tue, 24 Mar 2020 11:51:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200324151101.GH60268@vurt.meerval.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_242) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 15:52:10 -0000 Job, > On Tue, Mar 24, 2020 at 03:20:09PM +0100, Martin Hoffmann wrote: >> Job Snijders wrote: >>> I'm not sure I agree - routinator, fort and octorpki are trivially >>> forced to use rsync if the attacker blocks TCP port 443. >> At least Routinator does not fall back to rsync once it has >> successfully completed accessing the repository via RRDP once. I am >> open to strengthen this to not ever use rsync if there is a RRDP URI >> in the certificate. > I'm interpreting the willingness to attempt to make MITM attack slightly > harder as an indicator that the described MITM partial > withholding/corruption attack scenarios are valid and problematic. :-) > > I don't think a conclusion about the integrity of the DELTA snapshot can > be derived from the fetch mechanism itself: just because it was > retrieved over HTTPS doesn't mean there was no MITM attack. The > diginotar situation comes to mind, and crazier things have existed in > the wild. Use of TLS, absent a CA compromise, protects against MITM attacks. The CA compromise you cited (DigiNotar) was serious because of the Web PKI model, in which any trust anchor can issue a cert for any EE. Today, with the use of cert pinning and cert transparency logs, the likelihood of such attacks has very dramatically decreased in the Web PKI environment. Can you provide an example of one of the "crazier things" (relevant to TLS and the Web PKI) hat have happened in the wild, and which are applicable here? Steve From nobody Tue Mar 24 09:10:10 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 4A8D33A0C92 for ; Tue, 24 Mar 2020 09:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 uYYb-6GPlQja for ; Tue, 24 Mar 2020 09:09:47 -0700 (PDT) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [128.241.192.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF713A0D45 for ; Tue, 24 Mar 2020 09:09:41 -0700 (PDT) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id 17261EE013C; Tue, 24 Mar 2020 16:09:41 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 937E827C0058; Tue, 24 Mar 2020 12:09:39 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Tue, 24 Mar 2020 12:09:39 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehuddgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedflfho sgcuufhnihhjuggvrhhsfdcuoehjohgssehnthhtrdhnvghtqeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohgsodhmvghsmhhtphgruhht hhhpvghrshhonhgrlhhithihqddutdegjeeludehkeegqddvfeeffeekfedvtddqjhhosg eppehnthhtrdhnvghtsehsohgsohhrnhhoshhtrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 16585C200A4; Tue, 24 Mar 2020 12:09:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <3DE1004F-00BA-4A2F-AED2-D0900B4EF84E@ripe.net> References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <3DE1004F-00BA-4A2F-AED2-D0900B4EF84E@ripe.net> Date: Tue, 24 Mar 2020 17:08:29 +0100 From: "Job Snijders" To: "Oleg Muravskiy" Cc: "SIDR Operations WG" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 16:10:07 -0000 Dear Oleg, On Tue, Mar 24, 2020, at 16:36, Oleg Muravskiy wrote: > Your examples so far have showed that continuing with incomplete set o= f=20 > ROAs after a withhold/manipulation on ROA objects might create=20 > dangerous situation. >=20 > Are there scenarios where withholding / making invalid a certificate,=20= > for example, leads to a similar danger? >=20 > I wonder if this is specific to ROA objects only, and whether we shoul= d=20 > treat them differently. If it is, then we could =E2=80=9Cignore=E2=80=9D= all published=20 > ROAs at the specific publication point, but continue validation to=20 > child certificates and their sub-trees. Good question. My intuition is that it is not entirely relevant what the= file type is. My examples are indeed all ROA and CRL specific as the co= nsequences are easier to demonstrate using the real Internet BGP tables = in examples. Treating ROAs differently than other types of files referenced in manife= sts may lead to pain somewhere down the road when it is discovered that = these problems in fact didn't just apply to only ROAs or CRLs. If there = happens to be a file type (now or in the future) where proceeding to ext= ract data from subtrees is a safe choice to make, I think /that/ should = be be the exception after it has proven to be a safe choice to do so. The RPKI data does not lend itself for some kind of Solomon-Reed error c= orrection. Manifests allow us to discover that /something/ is missing, b= ut we have no idea /what/ is missing. If we don't know /what/ is missing= , all bets are off. It is hard for me to imagine a scenario where the pu= blication point's own ROAs are hosed but it'll still be safe to continue= attempting to extract data from non-ROA objects from child certs / sub = trees. Should at some point there be 'business rule' interdependencies between = various object types that may exist in the RPKI, and exceptions were mad= e for ROAs but not for other file types - I suspect the complexity of th= e decision tree will become insurmountable. Kind regards, Job From nobody Tue Mar 24 09:55:06 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 D8BD93A0CF4 for ; Tue, 24 Mar 2020 09:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 EhjZyiNsqP6a for ; Tue, 24 Mar 2020 09:54:54 -0700 (PDT) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3573A0CE8 for ; Tue, 24 Mar 2020 09:54:35 -0700 (PDT) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 00E70220162; Tue, 24 Mar 2020 16:54:34 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 7043927C005A; Tue, 24 Mar 2020 12:54:32 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Tue, 24 Mar 2020 12:54:32 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehuddgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedflfhosgcuufhnihhjuggvrhhsfdcuoehjohgssehnthht rdhnvghtqeenucffohhmrghinhepiigunhgvthdrtghomhenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohgsodhmvghsmhhtphgruhhthhhp vghrshhonhgrlhhithihqddutdegjeeludehkeegqddvfeeffeekfedvtddqjhhosgeppe hnthhtrdhnvghtsehsohgsohhrnhhoshhtrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B67DCC200A5; Tue, 24 Mar 2020 12:54:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> In-Reply-To: <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> Date: Tue, 24 Mar 2020 17:54:09 +0100 From: "Job Snijders" To: "Stephen Kent" , sidrops@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 24 Mar 2020 16:55:00 -0000 Kent, On Tue, Mar 24, 2020, at 16:51, Stephen Kent wrote: > Use of TLS, absent a CA compromise, protects against MITM attacks. In a perfect world things are perfect? :-) > The CA compromise you cited (DigiNotar) was serious because of the Web > PKI model, in which any trust anchor can issue a cert for any EE. Today, > with the use of cert pinning and cert transparency logs, the likelihood > of such attacks has very dramatically decreased in the Web PKI environment. Yeah - I've seen tremendous improvements to Web PKI in the last few years. But still, CT logs are a reactive measure. In some countries operating systems may come with a compromised CA. A recent example: https://www.zdnet.com/article/kazakhstan-government-is-now-intercepting-all-https-traffic/ > Can you provide an example of one of the "crazier things" (relevant to > TLS and the Web PKI) hat have happened in the wild, and which are > applicable here? I think there is no shortage of examples where the safety that should've been provided by TLS, was compromised because of a software defects or a misunderstanding in an implementation. This recently hit the news too: https://www.zdnet.com/article/lets-encrypt-to-revoke-3-million-certificates-on-march-4-due-to-bug/ I don't think this thread is not about whether TLS is perfect or not. I think most of us agree it is great we have an improved replacement for rsync in the pipeline. However, RPKI (as I understand it) was designed around being "self-contained" and the promise sort of seemed to be that regardless of the security (or insecurity) of the retrieval mechanism, a RPKI repository can and must be verified. For the purpose discussion in SIDROPs, I think it is fair (and a necessity) to assume that MITMs are possible regardless of the repository retrieval mechanism in use. Kind regards, Job From nobody Tue Mar 24 12:02:33 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 5D2213A1268 for ; Tue, 24 Mar 2020 12:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 GTi7r5BD1pat for ; Tue, 24 Mar 2020 12:02:13 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 544343A124E for ; Tue, 24 Mar 2020 12:02:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jGooU-0006cd-PL; Tue, 24 Mar 2020 19:02:10 +0000 Date: Tue, 24 Mar 2020 12:02:10 -0700 Message-ID: From: Randy Bush To: Alexander Azimov Cc: SIDR Operations WG In-Reply-To: References: <158274065310.22955.10729466847169070546.idtracker@ietfa.amsl.com> <20200306130129.59c888c1@glaurung.nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt 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, 24 Mar 2020 19:02:31 -0000 > 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. 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. and ask folk such as mark how rov deployment is going on some of the more common platforms. randy From nobody Tue Mar 24 23:50:51 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 16CE73A09E3 for ; Tue, 24 Mar 2020 23:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 6hYXptUNgRos for ; Tue, 24 Mar 2020 23:50:29 -0700 (PDT) Received: from smtpbgsg3.qq.com (smtpbgsg3.qq.com [54.179.177.220]) (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 9CF4F3A09B8 for ; Tue, 24 Mar 2020 23:50:27 -0700 (PDT) X-QQ-mid: bizesmtp5t1585119017tkxvyr8yw Received: from [192.168.218.230] (unknown [202.173.9.210]) by esmtp6.qq.com (ESMTP) with id ; Wed, 25 Mar 2020 14:50:16 +0800 (CST) X-QQ-SSF: 00400000002000N0ZI80000A0000000 X-QQ-FEAT: Xi7/tbtoyXq4sMDxIbToUWgBGOEZwfq+ge/P18mOhQfR7RUgWUqRkMTtd2WOz 6mL+hqFdNMQL/OWjq1e/MhuaMsGLX3fP0pFncEG05Hw+zmUJkaAipAGS6Gza/LaChCbVrbB FI3pNS2j+T7HrCzAL6fRXTux/zd9n4Vzm8YiQZV4oxiy4wZmxIszHvKfHv5Ayfgk9ez9lZz BxsWULUpIMuPDx0X5eUnO0H6ZG7zwJOP2aOsj8ySeut973JLX/RCIy6fJvuWTvtcIUtOoTH 5RLQVV+xIXm1Z6phjbR0awnmvfi4H1+pKGw/gCyM6C6ScRjJqOlxjZmwPzFrIg9tE7HdSXJ xZ+2T19qdaisrkb9nkwfZqUIvRt38TLoEI6QO/u X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Di Ma In-Reply-To: <158500848027.2238.1787740663836199956@ietfa.amsl.com> Date: Wed, 25 Mar 2020 14:50:14 +0800 Cc: ops-dir@ietf.org, draft-ietf-sidrops-rp.all@ietf.org, SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <158500848027.2238.1787740663836199956@ietfa.amsl.com> To: Niclas Comstedt X-Mailer: Apple Mail (2.3608.60.0.2.5) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign6 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rp-06 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: Wed, 25 Mar 2020 06:50:51 -0000 Niclas, Thanks for your review. Please find our responses in-lines. > 2020=E5=B9=B43=E6=9C=8824=E6=97=A5 08:08=EF=BC=8CNiclas Comstedt via = Datatracker =E5=86=99=E9=81=93=EF=BC=9A >=20 > Reviewer: Niclas Comstedt > Review result: Has Nits >=20 > I have reviewed this document as part of the Operational directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = Document > editors and WG chairs should treat these comments just like any other = last call > comments. >=20 > I don't have any strong concerns or objections on it, and somewhat = limited > experience with parts of it. Which is partly why my first reaction is > wondering about the value of this draft in its current form. I can = see the > value of a checklist, given the same reasons that are outlined in the = intro. > But reading this I'm not sure this is the most effective way to = achieve that. > So with that background here are my comments and questions: >=20 > - The value of this is only relevant if its updated. I did notice the = last > sentence of section one (btw, should be =E2=80=9CThis document will be = updated=E2=80=9D, not > =E2=80=98update=E2=80=99) but given the importance in a document of = this type I would like to > understand how this will be ensured? It is a typo. The last sentence of section 1 should be =E2=80=9CThis = document will be updated to reflect new or changed requirements as these = RFCs are updated, or new, relevant RFCs are written.=E2=80=9D RFC = documents are updated or obsoleted as per new RFCs are published. So = this document will be updated if the referenced RFCs are updated or = obsoleted.=20 >=20 > - Should this follow normal practices and when it relaying specific = standard=E2=80=99s > guideline it should capitalize those? E.g. 4.2.4 why would it not be > =E2=80=9CAdditionally, the certificate MUST contain an AS Identifier = Delegation=E2=80=9D and so > on? I realize this is an informational, doesn=E2=80=99t specify the = usual terms section > in the beginning and the essence of RFC8174, but here it seems you = would want > the normal defined meaning no? Yes. We don=E2=80=99t use the capitalized keywords such as MUST because = this will be an informational RFC. If the wording =E2=80=98must not=E2=80=99= could bring about confusion we are fine with using =E2=80=9Crequired = to=E2=80=9D instead of =E2=80=9Cmust=E2=80=9D and =E2=80=9Cnot allowed = to=E2=80=9D instead of =E2=80=9Cmust not=E2=80=9D. >=20 > - How was the =E2=80=9Cdetail level=E2=80=9D of this document = determined? It seems at times, > probably partly because I=E2=80=99m not that familiar with many parts = of this, that its > quite circular or pointing to a RFC section that immediately points = elsewhere. > At times this has to do more with the docs it references (e.g. 2.5 and = it's > reference to 6461 with its section 5 vs. 3) but still seems like a key = question > for the usefulness of this document. >=20 The level of detail does vary in places. The variability is based on our = perception of what an implementor needs to be reminded of with regard to = different aspects of RPKI standards. I am leading a team that has = implemented RPKI RP software, and the co-author Dr. Steve Kent led a = team that developed the first RPKI RP software. He is also the author of = several RPKI RFCs. Based on our collective experiences, we have chosen = to place more emphasis on some areas vs. others, hence the variability = you noted. > - Inconsistent referencing, sometimes to the specific section (or even > paragraph in a section) while other times to a large section covering = more than > the point (e.g. 4.2.1 Manifest, =E2=80=9CSpecific checks for a = Manifest are described > in Section 4=E2=80=9D seems like it's specifically calling for 4.4 of = RFC6486) >=20 We have tried to be consistent in terms of referencing but, as we noted = above, our experiences in developing the RPKI standards, and in = developing software that implements the standards, motivates us to = provide varying levels of detail in different parts of the document. = This carries over to the references as well. Di From nobody Wed Mar 25 07:22:02 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 B090B3A077C for ; Wed, 25 Mar 2020 07:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 RqBHD0u5TqAE for ; Wed, 25 Mar 2020 07:21:50 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2098.outbound.protection.outlook.com [40.107.91.98]) (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 428BD3A07B6 for ; Wed, 25 Mar 2020 07:21:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KqAsBDmkfIyMD1+YZIB+5JqMC9sttylub+Uhellj+2SgVHpA88uaZc4Drmv15jvGKBwTMwV4Rt/RBzi+/9D9Tqd9ODODRXUNoswrUQspzmb1YdkTLkvmVxOIT6JBiM0Yi8xusv1y9ggP7/vv9ze/qi1g2pVFk06vgdJCf9wYzSjDWbftdVLN5OtxUVxoMbZg0tlxHr0vpiARRkLI3s+XIwIgSTuuOQYKV8L9UKnLzmXiSymJXs07OCvrCMKsXH3IqmplbAxjfv4pCneiwS2wRfSdYZ/ReejbvaYMIOn6WzGhgleyCutTd7yS2AECIoO/5aCVCyxAR8kKfvqsBKiygQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J+xMc6Hpv05d6UA2eg444Dn4bBuPO1nIK3xeccJi13o=; b=kWihzyNmXZdibSdylncVE0OlBL45j+1yvrXXB04agPYgGNGAQPtrIn9YiQSD+z42mqXpXRCBtG/7M56ChhlD0ktCW/pU2nGSfAjBzCPQi/zqaeA6EqO8v98W372q8ds1rAjnvnHGeei/50sF1tu7d/gOT/rHjE5UcAaws0v1NFkjuRjOhjhCiU8lfNE9GRdOqZn83BGip+D+YAIUTja/am4KibPe3x+1XnSS+2NZes+zzoBbbm3jyr9Ki+vwo5aPNhVsQtjQY7JVaAc6x8NVt768X907Ccx4VvASlNTwOYjbIz3ZihCPPU7VCKL1Ix5q9J3s3RlVw0S4r7aEI7Z/nw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J+xMc6Hpv05d6UA2eg444Dn4bBuPO1nIK3xeccJi13o=; b=JLyY1N7vbiKzfs1SVEBVchEPvUtIlgMdVJ4coN8b7yN2AMYDbLl0AqHA6nLgdocJB2TVUOnPmag4RKkDAFu1f4CLOiwq9b2uwPVyIt0QjA4ruLJyF616SLboJcwZza9r3htBNhf5nBCivA4cB6pCXb55MmoK7P7W6RjQq+KHkSQ= Received: from MN2PR09MB5114.namprd09.prod.outlook.com (2603:10b6:208:223::10) by MN2PR09MB3534.namprd09.prod.outlook.com (2603:10b6:208:3e::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.22; Wed, 25 Mar 2020 14:21:35 +0000 Received: from MN2PR09MB5114.namprd09.prod.outlook.com ([fe80::a895:107b:823a:1c49]) by MN2PR09MB5114.namprd09.prod.outlook.com ([fe80::a895:107b:823a:1c49%4]) with mapi id 15.20.2835.021; Wed, 25 Mar 2020 14:21:35 +0000 From: "Borchert, Oliver (Fed)" To: "sidrops@ietf.org" CC: "Borchert, Oliver (Fed)" Thread-Topic: Modification of draft-sidrops-bgpsec-validation-signaling Thread-Index: AQHV0sKQNcuQZlmpqEep2SHVIDTSTA== Date: Wed, 25 Mar 2020 14:21:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-originating-ip: [129.6.219.158] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f4accecc-4f23-4b92-fa6e-08d7d0c7d2eb x-ms-traffictypediagnostic: MN2PR09MB3534:|MN2PR09MB3534: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39850400004)(376002)(396003)(136003)(346002)(186003)(71200400001)(26005)(478600001)(6506007)(107886003)(6916009)(86362001)(6512007)(4326008)(6486002)(66946007)(64756008)(66476007)(8936002)(81156014)(36756003)(316002)(66446008)(66556008)(2906002)(2616005)(5660300002)(76116006)(8676002)(81166006)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR09MB3534; H:MN2PR09MB5114.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: U3umTbI3vzzbrKemBkUxFVSJ92dOd0DhMgkt8n4ggrLbWQg5YjwpL9uXGAfDSNLu5GpjZIEIKn+0TzHSWUT8EG1U1oRjyGFnDwqrP8PPMY7/48cqWCqtUzSTxNtXeIpusVhY7aJ6Z3xhxyUVT3dgYMdJBeK1lV84rFZtwFEbeyozasGEsB43oS5NP8Iy4ohyaGOGetU7/gjIYouTxHsfXn8Y3yWCf7+0ANWN9wfkIGh+p023QQdT99EjazlqjFMX1PZxK3lPtwYDZMaEdtXhIzpwkSW2ii2x//9Dncd+vnkZpuox044eCiFdKzyI7aH1kkppLe77whM5eB7f0+kJr+nNUXPqAYLqMQNRXfkaoQVP87Nr5JO5689GYIcAVRe+HwK5WAObwHVzLDQkbL7v7ZRJQISDFl03tUqtedbSQ94GNoDTpCVOEbIn7fzSibzmyM/Vu+shkwvwERdoQmcDwmzqmXsCsTzlZ+zybmigY2D7RQRb8gmQQWd/oFW64SVzVubS52+Ap7EwklQ90F7RFQ== x-ms-exchange-antispam-messagedata: V/Q1GNi70L0LQYy6Bku/+Gszq/FsuwpJxSnJyghEzQUcVJP3x5DImlSWjT5iPim/YQcZFrzqNiuf7UXReagS2MnGcsHo2gFEsyoLavJQmfRhEIVF0/04DnMs5BZWZPlx5ucImYv9X9x58hulelnlSA== Content-Type: multipart/alternative; boundary="_000_D382ACDBE4654075B8818B7C28E42DA8nistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: f4accecc-4f23-4b92-fa6e-08d7d0c7d2eb X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2020 14:21:35.0699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Pc49l29kKPnYC4kilmpYVDcMbaQgGpPk802YYXrDQQ9iTsYv7tJ5DcBNoXaio2ADqH9x15Y6MwOoPSSz03EHvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB3534 Archived-At: Subject: [Sidrops] Modification of draft-sidrops-bgpsec-validation-signaling 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: Wed, 25 Mar 2020 14:22:00 -0000 --_000_D382ACDBE4654075B8818B7C28E42DA8nistgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gYW5kIEkgaG9wZSBldmVyeW9uZSBpcyBkb2luZyB3ZWxsIHRoZXNlIHRpbWVzLg0KDQpJ IGtub3cgaXQgaXMgYWxyZWFkeSBzb21lIHRpbWUgYWdvIGJ1dCBkdXJpbmcgdGhlIHByZXNlbnRh dGlvbiBvZiB0aGUgZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmcgICho dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlv bi1zaWduYWxpbmctMDEpIGR1cmluZyBJRVRGIDEwNiBpbiBTaW5nYXBvcmUsIGEgZGlzY3Vzc2lv biBhcm91bmQgdGhlIGRyYWZ0IHN0YXJ0ZWQgdGhhdCB3aWxsIGNoYW5nZSB0aGUgY3VycmVudCBz dGF0ZSBvZiB0aGUgZHJhZnQgYW5kIHdpbGwgcmV2ZXJ0IGFsbCByZXF1ZXN0cyBzdGVtbWluZyBm cm9tIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IHRoYXQgd2VyZSBtYWRlIGR1cmluZyB0aGUg YWRvcHRpb24gY2FsbC4NCkJlZm9yZSBJIHN1Ym1pdCB0aGUgbW9kaWZpY2F0aW9uIEkgd2FudCB0 byBxdWVyeSB0aGUgbGlzdCBpZiB0aGUgY2hhbmdlcyB0byBiZSBtYWRlIGFyZSBpbiBzeW5jaCB3 aXRoIHRoZSB3b3JraW5nIGdyb3VwLg0KDQpUbyByZW1pbmQgeW91LCB0aGUgb3JpZ2luYWwgcHJv cG9zYWwgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3JjaGVydC1zaWRyb3Bz LWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMSkgd2FzIHRvIGFkZCBhIEJHUCBwYXRoIGF0 dHJpYnV0ZSBmb3Igc2lnbmFsaW5nIHRoZSB2YWxpZGF0aW9uIHJlc3VsdCBvZiBwYXRoIHZhbGlk YXRpb24gaW4gdGhlIHNhbWUgbWFubmVyIGFzIGRlc2NyaWJlZCBmb3IgcHJlZml4IG9yaWdpbiB2 YWxpZGF0aW9uIGFzIHNwZWNpZmllZCBpbiBSRkMgODA5Ny4gIER1cmluZyB0aGUgYWRvcHRpb24g Y2FsbCBhIGRpc2N1c3Npb24gc3RhcnRlZCB0byBpbnN0ZWFkIGNyZWF0aW5nIGEgbmV3IHBhdGgg YXR0cmlidXRlIHRvIGp1c3QgYWRkIHRoZSBwYXRoIHZhbGlkYXRpb24gaW5mb3JtYXRpb24gaW50 byB0aGUgcmVzZXJ2ZWQgZmxhZyBvZiBSRkMgODA5NyBhbmQgaGVuY2UgdXBkYXRpbmcgUkZDIDgw OTcuDQoNCkFmdGVyIHVwbG9hZGluZyB0aGUgZHJhZnQgMDAgd2hpY2ggcmVmbGVjdHMgdGhlIHZl cnNpb24gb2YgdGhlIGFkb3B0aW9uIGNhbGwsIHdlIHdlbnQgYWhlYWQgYW5kIGFkZGVkIHRoZSBt b2RpZmljYXRpb25zIGFzIHRoZXkgd2VyZSBkaXNjdXNzZWQgb24gdGhlIG1haWxpbmcgbGlzdCBk dXJpbmcgdGhlIGFkb3B0aW9uIGNhbGwuIFRoZSBjdXJyZW50IGZvcm0gb2YgdGhlIGRyYWZ0ICgw MSkgcmVmbGVjdHMgdGhlc2UgbW9kaWZpY2F0aW9uIGJ5IG5vdyB1cGRhdGluZyBSRkMgODA5NyB3 aGljaCBpbmNsdWRlZCB0aGUgbW9kaWZpY2F0aW9uIG9mIHRoZSBQRFUgYW5kIHN1YnNlcXVlbnRs eSB0aGUgbW9kaWZpY2F0aW9uIG9mIGVycm9yIGhhbmRsaW5nIGFuZCBjbGFyaWZpY2F0aW9uIGFu ZCByZW5hbWluZyB0aGUgYXR0cmlidXRlIGZpZWxkIG5hbWVzIHRvIHJlZmxlY3QgdGhlIGNvcnJl Y3QgbWVhbmluZy4gVGhlIHF1ZXN0aW9uIHRoYXQgY2FtZSB1cCBmcm9tIG91ciBzaWRlIGlmIHRo ZXNlIGNoYW5nZXMgd2FycmFudCB0byBvYnNvbGV0ZSBSRkMgODA5NyB3aGljaCB3b3VsZCBhbGxv dyBhIG11Y2ggY2xlYW5lciBhcHByb2FjaC4NCg0KRHVyaW5nIHRoZSBwcmVzZW50YXRpb24gaW4g U2luZ2Fwb3JlIHRob3VnaCBtdWx0aXBsZSBwYXJ0aWNpcGFudHMgc3Bva2UgdXAgaW4gZmF2b3Ig b2Ygbm90IHBlcnVzaW5nIHRoaXMgcGF0aCBhbmQga2VlcGluZyBwYXRoIHZhbGlkYXRpb24gYXMg d2VsbCBhcyAgcHJlZml4IG9yaWdpbiB2YWxpZGF0aW9uIHNpZ25hbGluZyBzZXBhcmF0ZS4gT25l IG1ham9yIHJlYXNvbiB0aGF0IHdhcyBtZW50aW9uZWQsIHdhcyBpbXBsZW1lbnRhdGlvbiByZWxh dGVkIHJlZ2FyZGluZyBtYXBwaW5nIHRoZSB6ZXJvIHZhbHVlIG9mIHRoZSByZXNlcnZlZCBmaWVs ZCBpbiBmaWx0ZXJzIHdoaWNoIHdvdWxkIG5vdCB3b3JrIGFueW1vcmUgaWYgd2UgYXJlIGNvbWJp bmluZyBib3RoIHZhbHVlcyBnb2luZyBmb3J3YXJkLiBPbiBhIHBlcnNvbmFsIHRob3VnaHQgcmVn YXJkaW5nIHRoYXQgaXNzdWUsIHRoZSBSRkMgY2xlYXJseSBzdGF0ZXMgdGhhdCB0aGUgcmVjZWl2 ZXIgTVVTVCBpZ25vcmUgdGhlIHJlc2VydmVkIGZpZWxkLCBzbyBmaWx0ZXJpbmcgb24gdGhlIHJl c2VydmVkIGZpZWxkcyB2YWx1ZSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBzaG9ydGN1dCB0aGF0IGJy ZWFrcyBjb25mb3JtYW5jZSB0byB0aGUgUkZDLg0KDQpTbywgYmVmb3JlIEkgZ28gYWhlYWQgYW5k IHJldmVydCB0aGUgY2hhbmdlcyB3aXRoaW4gdGhlIGRyYWZ0IGJhY2sgdG8gaXRzIDAwIHN0YXRl IGFuZCB0aGVyZWZvcmUgc2VwYXJhdGUgdGhlIHZhbGlkYXRpb24gc3RhdGUgc2lnbmFsaW5nIGJh Y2sgaW50byBpbmRlcGVuZGVudCBkb2N1bWVudHMgcmVzcGVjdGl2ZWx5IGFuZCBkZWFsaW5nIHdp dGggcGF0aCB2YWxpZGF0aW9uIG9ubHkgYXMgaW5pdGlhbGx5IHByb3Bvc2VkLCBJIGxpa2UgdG8g cXVlcnkgdGhlIGxpc3QgaWYgdGhlcmUgaXMgY29uc2Vuc3VzIGluIGRvaW5nIHNvLg0KDQpQbGVh c2UgbGV0IG1lIGtub3cgc28gSSBjYW4gZ28gYWhlYWQgYW5kIG1ha2UgdGhlIG5lY2Vzc2FyeSBt b2RpZmljYXRpb25zLA0KDQpUaGFua3MgYW5kIHN0YXkgc2FmZSwNCk9saXZlcg0K --_000_D382ACDBE4654075B8818B7C28E42DA8nistgov_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252 ZXJ0ZWQtc3BhY2U7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IZWxsbyBhbmQgSSBo b3BlIGV2ZXJ5b25lIGlzIGRvaW5nIHdlbGwgdGhlc2UgdGltZXMuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+SSBrbm93IGl0IGlzIGFscmVhZHkgc29tZSB0aW1lIGFnbyBidXQg ZHVyaW5nIHRoZSBwcmVzZW50YXRpb24gb2YgdGhlIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlk YXRpb24tc2lnbmFsaW5nICZuYnNwOyg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDEiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25h bGluZy0wMTwvYT4pPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPmR1cmluZw0KIElFVEYgMTA2IGluIFNpbmdhcG9yZSwgYSBkaXNjdXNzaW9uIGFyb3VuZCB0 aGUgZHJhZnQgc3RhcnRlZCB0aGF0IHdpbGwgY2hhbmdlIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRo ZSBkcmFmdCBhbmQgd2lsbCByZXZlcnQgYWxsIHJlcXVlc3RzIHN0ZW1taW5nIGZyb20gdGhlIGRp c2N1c3Npb24gb24gdGhlIGxpc3QgdGhhdCB3ZXJlIG1hZGUgZHVyaW5nIHRoZSBhZG9wdGlvbiBj YWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFu czogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5CZWZvcmUgSSBzdWJtaXQgdGhlIG1vZGlm aWNhdGlvbiBJIHdhbnQgdG8gcXVlcnkgdGhlIGxpc3QgaWYgdGhlIGNoYW5nZXMgdG8gYmUgbWFk ZSBhcmUgaW4gc3luY2ggd2l0aCB0aGUgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFy dDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRvIHJlbWluZCB5b3Us IHRoZSBvcmlnaW5hbCBwcm9wb3NhbCAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJvcmNoZXJ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAx Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm9yY2hlcnQtc2lkcm9wcy1iZ3Bz ZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDE8L2E+KSB3YXMgdG8gYWRkIGEgQkdQDQogcGF0aCBh dHRyaWJ1dGUgZm9yIHNpZ25hbGluZyB0aGUgdmFsaWRhdGlvbiByZXN1bHQgb2YgcGF0aCB2YWxp ZGF0aW9uIGluIHRoZSBzYW1lIG1hbm5lciBhcyBkZXNjcmliZWQgZm9yIHByZWZpeCBvcmlnaW4g dmFsaWRhdGlvbiBhcyBzcGVjaWZpZWQgaW4gUkZDIDgwOTcuICZuYnNwO0R1cmluZyB0aGUgYWRv cHRpb24gY2FsbCBhIGRpc2N1c3Npb24gc3RhcnRlZCB0byBpbnN0ZWFkIGNyZWF0aW5nIGEgbmV3 IHBhdGggYXR0cmlidXRlIHRvIGp1c3QgYWRkDQogdGhlIHBhdGggdmFsaWRhdGlvbiBpbmZvcm1h dGlvbiBpbnRvIHRoZSByZXNlcnZlZCBmbGFnIG9mIFJGQyA4MDk3IGFuZCBoZW5jZSB1cGRhdGlu ZyBSRkMgODA5Ny48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs O29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0 LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxp Z246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkFmdGVyIHVwbG9hZGluZyB0aGUgZHJhZnQgMDAgd2hpY2ggcmVmbGVj dHMgdGhlIHZlcnNpb24gb2YgdGhlIGFkb3B0aW9uIGNhbGwsIHdlIHdlbnQgYWhlYWQgYW5kIGFk ZGVkIHRoZSBtb2RpZmljYXRpb25zIGFzIHRoZXkgd2VyZSBkaXNjdXNzZWQgb24gdGhlIG1haWxp bmcgbGlzdCBkdXJpbmcgdGhlIGFkb3B0aW9uIGNhbGwuIFRoZSBjdXJyZW50IGZvcm0gb2YgdGhl IGRyYWZ0ICgwMSkgcmVmbGVjdHMNCiB0aGVzZSBtb2RpZmljYXRpb24gYnkgbm93IHVwZGF0aW5n IFJGQyA4MDk3IHdoaWNoIGluY2x1ZGVkIHRoZSBtb2RpZmljYXRpb24gb2YgdGhlIFBEVSBhbmQg c3Vic2VxdWVudGx5IHRoZSBtb2RpZmljYXRpb24gb2YgZXJyb3IgaGFuZGxpbmcgYW5kIGNsYXJp ZmljYXRpb24gYW5kIHJlbmFtaW5nIHRoZSBhdHRyaWJ1dGUgZmllbGQgbmFtZXMgdG8gcmVmbGVj dCB0aGUgY29ycmVjdCBtZWFuaW5nLiBUaGUgcXVlc3Rpb24gdGhhdCBjYW1lIHVwIGZyb20NCiBv dXIgc2lkZSBpZiB0aGVzZSBjaGFuZ2VzIHdhcnJhbnQgdG8gb2Jzb2xldGUgUkZDIDgwOTcgd2hp Y2ggd291bGQgYWxsb3cgYSBtdWNoIGNsZWFuZXIgYXBwcm9hY2guPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3Rh cnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5EdXJpbmcgdGhlIHBy ZXNlbnRhdGlvbiBpbiBTaW5nYXBvcmUgdGhvdWdoIG11bHRpcGxlIHBhcnRpY2lwYW50cyBzcG9r ZSB1cCBpbiBmYXZvciBvZiBub3QgcGVydXNpbmcgdGhpcyBwYXRoIGFuZCBrZWVwaW5nIHBhdGgg dmFsaWRhdGlvbiBhcyB3ZWxsIGFzICZuYnNwO3ByZWZpeCBvcmlnaW4gdmFsaWRhdGlvbiBzaWdu YWxpbmcgc2VwYXJhdGUuIE9uZSBtYWpvciByZWFzb24gdGhhdCB3YXMgbWVudGlvbmVkLA0KIHdh cyBpbXBsZW1lbnRhdGlvbiByZWxhdGVkIHJlZ2FyZGluZyBtYXBwaW5nIHRoZSB6ZXJvIHZhbHVl IG9mIHRoZSByZXNlcnZlZCBmaWVsZCBpbiBmaWx0ZXJzIHdoaWNoIHdvdWxkIG5vdCB3b3JrIGFu eW1vcmUgaWYgd2UgYXJlIGNvbWJpbmluZyBib3RoIHZhbHVlcyBnb2luZyBmb3J3YXJkLiBPbiBh IHBlcnNvbmFsIHRob3VnaHQgcmVnYXJkaW5nIHRoYXQgaXNzdWUsIHRoZSBSRkMgY2xlYXJseSBz dGF0ZXMgdGhhdCB0aGUgcmVjZWl2ZXIgTVVTVA0KIGlnbm9yZSB0aGUgcmVzZXJ2ZWQgZmllbGQs IHNvIGZpbHRlcmluZyBvbiB0aGUgcmVzZXJ2ZWQgZmllbGRzIHZhbHVlIGlzIGFuIGltcGxlbWVu dGF0aW9uIHNob3J0Y3V0IHRoYXQgYnJlYWtzIGNvbmZvcm1hbmNlIHRvIHRoZSBSRkMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNvLCBiZWZvcmUgSSBnbyBhaGVhZCBhbmQgcmV2 ZXJ0IHRoZSBjaGFuZ2VzIHdpdGhpbiB0aGUgZHJhZnQgYmFjayB0byBpdHMgMDAgc3RhdGUgYW5k IHRoZXJlZm9yZTwvc3Bhbj4gc2VwYXJhdGUgdGhlIHZhbGlkYXRpb24gc3RhdGUgc2lnbmFsaW5n IGJhY2sgaW50byBpbmRlcGVuZGVudCBkb2N1bWVudHMgcmVzcGVjdGl2ZWx5IGFuZCBkZWFsaW5n IHdpdGggcGF0aA0KIHZhbGlkYXRpb24gb25seSBhcyBpbml0aWFsbHkgcHJvcG9zZWQ8c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiwgSSBsaWtlIHRvIHF1ZXJ5IHRoZSBsaXN0IGlmIHRoZXJlIGlz IGNvbnNlbnN1cyBpbiBkb2luZyBzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87 LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5QbGVhc2UgbGV0IG1lIGtub3cgc28gSSBjYW4gZ28gYWhlYWQgYW5kIG1h a2UgdGhlIG5lY2Vzc2FyeSBtb2RpZmljYXRpb25zLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29y cGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNp emUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhhbmtzIGFuZCBzdGF5IHNhZmUs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBh dXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9saXZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D382ACDBE4654075B8818B7C28E42DA8nistgov_-- From nobody Wed Mar 25 07:25:40 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 466443A0C85; Wed, 25 Mar 2020 07:25:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman , nathalie@ripe.net X-Test-IDTracker: no X-IETF-IDTracker: 6.123.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <158514631626.31161.18087052787992685289@ietfa.amsl.com> Date: Wed, 25 Mar 2020 07:25:16 -0700 Archived-At: Subject: [Sidrops] Warren Kumari's Yes on draft-ietf-sidrops-rp-06: (with COMMENT) 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: Wed, 25 Mar 2020 14:25:21 -0000 Warren Kumari has entered the following ballot position for draft-ietf-sidrops-rp-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Notes for IESG reviewers: The requirements for relying party software is scattered throughout a bunch of different RFCs, and are sometimes buried and easy to overlook within these RFCs - they are generally more descriptive of how the system as a whole should work, not the responsibilities from each component's view. This has already caused a number of issues and inconsistencies between implementations, and so a document like this is needed. Like with other "Hitchhikers Guide to the XXX protocol" documents this would be a prime candidate for an "evolving document" type solution - but in the absence of such a thing, having an RFC is much better than a draft... From nobody Thu Mar 26 07:57:46 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 343443A0949 for ; Thu, 26 Mar 2020 07:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, 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=verizon.net 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 YckKAsjykEwA for ; Thu, 26 Mar 2020 07:57:39 -0700 (PDT) Received: from sonic302-21.consmr.mail.ne1.yahoo.com (sonic302-21.consmr.mail.ne1.yahoo.com [66.163.186.147]) (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 E69253A0C3D for ; Thu, 26 Mar 2020 07:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1585234635; bh=PDTNB4ESNjpijlyUg5T6ly507PM30Fz/0r2yqj4ctN0=; h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=GKOyO/d90v1pEGQLrxK3i/lB7Zq8cAN8vnzxn3uHD3NaIMq8/Lokz1+FLz3/HEkN35Uux1z5+L9wCQKo/Vd/nZH7vZYGxJ9qwlLXAlGEx7Fw2IxnrUqcEFa+KzElm4LqceHtP73d/t1oAmO8z62buWfwahF2Uj0JOC4lUsEFoaqn4HFo6Xms8H1iy84qifZqwAik0YbeWi0f6ydELWt7BKqvpoby29oqvRCq8nMZjGTqY02EVbwZzUGW9JaH5t0S2K/OFIDJ+s//tBBxQKnhhLrLhH+zITj+AC50PDHtlBcnkqtKet/7D+Y8uXDhgKEZ7o/IH+DGzn18YiMAoGClWw== X-YMail-OSG: 6CIsCI0VM1kjVQ9lo.NRUkiGrvvBNHbwwRyUZ7ORglthTXUEPs9owMwC1AvUEYN JW5HeNinDp1jlF.bs6IqLlQLDXvK1LQ1RsXIZfw1tZ8z5Xg.TS64sOeM5BWxRrrdx6dYgiMflKwu zVY8SRf5UIVT27GnzeHgMjhE7v0uKtTr.1X0ZNy1OhXMOjRHmBsteb2utVLOZuKNhUG5yfdbc0Fi dYhM8BAh3tKYMt_rz.DPBV3aKhNLG2wsQMLOQk6w2KMif2hboOpHYo8_1WFDBcHNYalmEpAp5AVn FeCih8nNUaYJzeHsl1NihfltF.f5KtMfSYwabpJ5CqRZNo8QGMwQ6qbuD4ibCBns1e0alYFJ6chT ..WrDDC7S_O_zOPa4135ZPxY67V2TG_16WtQP1ubexw3bnptXU933T7qNO_TEbVIjjmSTOEQc0P0 zwiX5BHcqrVJtyTdZYua3h9Zep9JHvL8d7VQW4yUDFmb_F8wKkVE52qKa2i.pNsS3aqHmBIA5UDb UyyXaFfmcTDu47fupqFksR1lP84qEuVLiv_CcCR8yVltMEiabExHy9S81_hBYkbMQy0SkFIyKm6A vU9FtNDBzm.w0M.LXFSyZklFB1DuzJcQ3KxkaMmGNWQwEQVqsUl.5dLJFM98BR8oAQ04fnGWYVYO 0hm3.tvGskuqayvTabK62hee3w7DbXHI2Sa84wG5n8d8lAcwu2hqT1WN31kCImC1rmQeAqEZvSrU F8KWtzEXKbeOM6PLciX3tggbVuKimEt7VyqxKujWuQZZLbwp5QU8PEt5_ENjCp6DJ4OBcNrw14QS slDpyS7h_TNJabV0oqQTG5CWdiVGmriLAlrq2EffrerYBRo3ZluvZP_hA7zteqHK6CcDQf_eXQRi 7ZXwjHdvMaMEtQMtnNE4wT_JFjakrSAMwV4_r9wK1O94OAe2_qckhKr8M8S3Jdk93G5SABgwPZ32 GHt5mJOfSwZDiVOOblHJZDnXo0ofdXoAhyLsxjBC8ZB2.Bqc2CMicBTWNes8EggM7yXJlYpNP.wD stdKxlppkRpzbfIYgXQBSDDROC5duuF.LfFZTvna3Yv0tr_ZuEjbLMk0RzqtNiVWdfKJiD8sgapH MknuFPDRsZiEEe2qoQrsw1N_24p7m0mI3hZStOYR7_uWuFggPIFDgQVAAwdrbN6dfq063nIO1ac. lgLHTDV.ljWbTQwGVTTApqWSkpnlBACxCbQooCwQu5b2xC7qiBlPgTw6rfC9pbAkZsDhp2O.48aM adUpWHIyyH_3Vyxi4Fi0fjkW7phcuj3NtAdbLjBzYsyEqdNoEqf0xn52oatbeGMSX_.IQQnqybPS 3iWd_cxxKBHTZ3.i0vWtMUnsKtuqpBCOmNIcWUfqQycLBS69LaL1sKj4qY3TP4jRe4iVUMnod3ML 2CrhDGY0pmPvWwDWyQ.ekjXAq7cqYrmpakhN7QD7DOtc6Y20Ib2hAvww0MEG.Ux5ia8M- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Thu, 26 Mar 2020 14:57:15 +0000 Received: by smtp418.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 77acc748d2d84cd880057f103eb5269c; Thu, 26 Mar 2020 14:57:12 +0000 (UTC) From: Stephen Kent To: Job Snijders , sidrops@ietf.org References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl> <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> Message-ID: Date: Thu, 26 Mar 2020 10:57:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------4F4B0A6EB0ACA061752E9B8F" Content-Language: en-US X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_242) Archived-At: Subject: Re: [Sidrops] what to do when the CRL is hosed? 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, 26 Mar 2020 14:57:43 -0000 This is a multi-part message in MIME format. --------------4F4B0A6EB0ACA061752E9B8F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/24/20 12:54 PM, Job Snijders wrote: > Kent, BTW, my first name is Steve. > On Tue, Mar 24, 2020, at 16:51, Stephen Kent wrote: >> Use of TLS, absent a CA compromise, protects against MITM attacks. > In a perfect world things are perfect? :-) Those of us who pose as security professionals distinguish between the security offered by a correct implementation of a protocol and associated crypto, vs.  buggy implementations, poor choice of crypto algs, etc.  If you are concerned about the security quality of a TLS implementation, then you should be _very_ concerned about the quality of the RPKI RP software, based on what we have been hearing! >> The CA compromise you cited (DigiNotar) was serious because of the Web >> PKI model, in which any trust anchor can issue a cert for any EE. Today, >> with the use of cert pinning and cert transparency logs, the likelihood >> of such attacks has very dramatically decreased in the Web PKI environment. > Yeah - I've seen tremendous improvements to Web PKI in the last few years. But still, CT logs are a reactive measure. In some countries operating systems may come with a compromised CA. A recent example:https://www.zdnet.com/article/kazakhstan-government-is-now-intercepting-all-https-traffic/ CT logs also are designed to deter mis-issuance by trust anchors, and facilitate remediation when mis-issuance is detected.  In that respect they seem to have been effective. Deterence is not reactive. (It's a pity that the authors of the CT docs have done a poor job of clearly explaining the purposes of the system, but ....) If you operate in a country where the government can tampoer with the version of the OS you use, then none of the security measures we can provide via the RPKI will prevent a wide range of attacks on the RPKI data retrieved or published by the ISPs in that country. So, that seems to be a red-herring in the context of this discussion. The ZDnet article your cite is analogous to the OS issue; the local government could act as a MITM for published and downloaded RPKI data. So, for downloaded data the local ISPs could be denied access to current RPKI data, or receive only partial RPKI data, which hurts them and their customers. For uploaded data, other ISPs could see only partial or old RPKI data from the affected, local ISPs. In that case the principal effect would seem to be to disadvantage the local ISPs and their customers.  So, again, if your local government is allowed to mess with you as an ISP, you're screwed, but their ability to adversely affect origin authentication info for other ISPs is ?? >> Can you provide an example of one of the "crazier things" (relevant to >> TLS and the Web PKI) hat have happened in the wild, and which are >> applicable here? > I think there is no shortage of examples where the safety that should've been provided by TLS, was compromised because of a software defects or a misunderstanding in an implementation. This recently hit the news too:https://www.zdnet.com/article/lets-encrypt-to-revoke-3-million-certificates-on-march-4-due-to-bug/ > not a great example, IMHO. The CA back end bug, if not quickly detected and remedied, would have caused web sites to not have up-to-date certs, which would have resulted in warnings to users (via their browsers). Again, this is not a TLS issue, per se, and it did not undermine the security afforded by TLS; it potentially caused some level of DoS for the affected servers, but DoS protection is NOT a security feature if TLS. > I don't think this thread is not about whether TLS is perfect or not. I think most of us agree it is great we have an improved replacement for rsync in the pipeline. However, RPKI (as I understand it) was designed around being "self-contained" and the promise sort of seemed to be that regardless of the security (or insecurity) of the retrieval mechanism, a RPKI repository can and must be verified. Well, as one of the principle architects of the RPKI, I can tell you that it was designed with the "principle of least privilege" as a major security feature.  In the RPKI context this     - limits the damage than any individual ISP can inflict as a result of local errors in generating certs and ROAs, whether due to software bugs, operator error, or local government influence     - limits the damage that can occur if a repository is attacked It also was intended to be independent of the Web PKI and its trust model. Using RRDP with certs issued by Web PKI trust anchors violates the last goal, but the effect seems to be equivalent to attacks on a repository. MFTs were designed (again, I was helped defined the concept of Manifests) to deal with active attacks on pub point data, irrespective of the mechanisms used to distribute that data. So, I think discussing MITM attacks is a distraction, unless we have examples of how such attacks can affect RPs in ways different from attacks on repositories. Maybe re-reading RFC 8211 would be useful, as it tries to analyze a range of possible "adverse actions"  by CAs or repository managers in the RPKI context, and discusses how RPKI mechanisms are intended to detect/counter these actions. Steve --------------4F4B0A6EB0ACA061752E9B8F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/24/20 12:54 PM, Job Snijders wrote:
Kent,
BTW, my first name is Steve.
On Tue, Mar 24, 2020, at 16:51, Stephen Kent wrote:

Use of TLS, absent a CA compromise, protects against MITM attacks.

In a perfect world things are perfect? :-)
Those of us who pose as security professionals distinguish between the security offered by a correct implementation of a protocol and associated crypto, vs.  buggy implementations, poor choice of crypto algs, etc.  If you are concerned about the security quality of a TLS implementation, then you should be very concerned about the quality of the RPKI RP software, based on what we have been hearing!
The CA compromise you cited (DigiNotar) was serious because of the Web 
PKI model, in which any trust anchor can issue a cert for any EE. Today, 
with the use of cert pinning and cert transparency logs, the likelihood 
of such attacks has very dramatically decreased in the Web PKI environment.

Yeah - I've seen tremendous improvements to Web PKI in the last few years. But still, CT logs are a reactive measure. In some countries operating systems may come with a compromised CA. A recent example: https://www.zdnet.com/article/kazakhstan-government-is-now-intercepting-all-https-traffic/

CT logs also are designed to deter mis-issuance by trust anchors, and facilitate remediation when mis-issuance is detected.  In that respect they seem to have been effective. Deterence is not reactive. (It's a pity that the authors of the CT docs have done a poor job of clearly explaining the purposes of the system, but ....)

If you operate in a country where the government can tampoer with the version of the OS you use, then none of the security measures we can provide via the RPKI will prevent a wide range of attacks on the RPKI data retrieved or published by the ISPs in that country. So, that seems to be a red-herring in the context of this discussion.

The ZDnet article your cite is analogous to the OS issue; the local government could act as a MITM for published and downloaded RPKI data. So, for downloaded data the local ISPs could be denied access to current RPKI data, or receive only partial RPKI data, which hurts them and their customers. For uploaded data, other ISPs could see only partial or old RPKI data from the affected, local ISPs. In that case the principal effect would seem to be to disadvantage the local ISPs and their customers.  So, again, if your local government is allowed to mess with you as an ISP,  you're screwed, but their ability to adversely affect origin authentication info for other ISPs is ??


      

        
Can you provide an example of one of the "crazier things" (relevant to 
TLS and the Web PKI) hat have happened in the wild, and which are 
applicable here?


      

      
I think there is no shortage of examples where the safety that should've been provided by TLS, was compromised because of a software defects or a misunderstanding in an implementation. This recently hit the news too: https://www.zdnet.com/article/lets-encrypt-to-revoke-3-million-certificates-on-march-4-due-to-bug/



    

    not a great example, IMHO. The CA back end bug, if not quickly
    detected and remedied, would have caused web sites to not have
    up-to-date certs, which would have resulted in warnings to users
    (via their browsers). Again, this is not a TLS issue, per se, and it
    did not undermine the security afforded by TLS; it potentially
    caused some level of DoS for the affected servers, but DoS
    protection is NOT a security feature if TLS.

    

      
I don't think this thread is not about whether TLS is perfect or not. I think most of us agree it is great we have an improved replacement for rsync in the pipeline. However, RPKI (as I understand it) was designed around being "self-contained" and the promise sort of seemed to be that regardless of the security (or insecurity) of the retrieval mechanism, a RPKI repository can and must be verified.

    

    
Well, as one of the principle architects of the RPKI, I can tell
      you that it was designed with the "principle of least privilege"
      as a major security feature.  In the RPKI context this

    

    
    - limits the damage than any individual ISP can inflict as a
      result of local errors in generating certs and ROAs, whether due
      to software bugs, operator error, or local government influence

    

    
    - limits the damage that can occur if a repository is
      attacked

    

    
It also was intended to be independent of the Web PKI and its
      trust model. Using RRDP with certs issued by Web PKI trust anchors
      violates the last goal, but the effect seems to be equivalent to
      attacks on a repository. MFTs were designed (again, I was helped
      defined the concept of Manifests) to deal with active attacks on
      pub point data, irrespective of the mechanisms used to distribute
      that data.

    
So, I think discussing MITM attacks is a distraction, unless we
      have examples of how such attacks can affect RPs in ways different
      from attacks on repositories. Maybe re-reading RFC 8211 would be
      useful, as it tries to analyze a range of possible "adverse
      actions"  by CAs or repository managers in the RPKI context, and
      discusses how RPKI mechanisms are intended to detect/counter these
      actions.

    

    
Steve

    

    

  


--------------4F4B0A6EB0ACA061752E9B8F--


From nobody Fri Mar 27 23:20:42 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 488223A0794; Fri, 27 Mar 2020 23:20:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Murray Kucherawy via Datatracker 
To: "The IESG" 
Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org,  Nathalie Trenaman 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.123.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy 
Message-ID: <158537641925.17606.5199067976726721275@ietfa.amsl.com>
Date: Fri, 27 Mar 2020 23:20:19 -0700
Archived-At: 
Subject: [Sidrops] Murray Kucherawy's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT)
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, 28 Mar 2020 06:20:20 -0000

Murray Kucherawy has entered the following ballot position for
draft-ietf-sidrops-rp-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4.3:

“A Manifest can be classified as either valid or invalid, and a valid Manifest
is either current and stale.”

That should be “...or stale”, right?




From nobody Mon Mar 30 09:11:04 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 8CFA63A18AA for ; Mon, 30 Mar 2020 09:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 WKBGNjc5vGHe for ; Mon, 30 Mar 2020 09:10:40 -0700 (PDT)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20608.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e8a::608]) (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 EC80F3A187D for ; Mon, 30 Mar 2020 09:10:39 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jx0xGocXA645VEouFP0+10rAfyCtyR8QvJvH8tflyvmp7aHE7ezuFm7vwLO/ywfF5ghJc+/IY4dS5plTiZJDTnBKtptnCtWkYl2YKHuku5f4s7pN/zjmUxUcTx6EQgmiIj52iucZm/uoigAp+aX21OcOM0iNlvao3gn6ADo3w9haDLUmeaK+lYBAw4ejgYZrrD65dp0/vJEEI+c5ecekYECrpUG1tlpXWLDkFxDi18BCQCd4NGffKS+H81Bav+Z1hQNSu7gqrOfd5V4bR7ZfQfBnhh1Op93vvTqgyzXUlW/IBGCRDWISjkhh/0gbb09/TpW4jigtHbRtP4BZ4t/i4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rAltF6mcT2/LVdSWRH9NV6Mtyw+W94LPpnb2tekfJbs=; b=CS97Niu1QQLs5rGy4sw6lAgfwUDvDf3VKQuQmUNOfmVFTvWy2ys6q6TGe/Ct9EeSqVVYDAjBBQV3uc2N34wJ4wV3AjIZ9aMWwHs1TUN0y1vYXFyvMLniwmJWMVGXg2n7jtpCRq0WyYQQkzFBtMosywFfpax9oXRNTKDjiFu6kUoXFL1UQ4Cm6PWLMkJIFnGwqjMPRmIsK+t+Xe4LoJHUZMsReAFtIAvzO7bGGgfNMJEinfKiNWjzq+XkkjiAOEUD3YyvVHwe1g2wY7izPFzWAqjV84umKZMxku+6xGgODSM/GvcmjfQ2a2YoF+zd+Timc+z/Fte8DY98nAPLZU/6KQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rAltF6mcT2/LVdSWRH9NV6Mtyw+W94LPpnb2tekfJbs=; b=LZDIKaC6FK5AYg8D56/xtlx0ALTajNvXEYeh2db/Vu1quXROITkVjpoEpFJV0UE1Lg+yeC7biahZgjAoY1MVG6lHU7ZX5s56OMpT+wV9ZxkxgINcK3ovh+MtLNJfJNveTr9liDne4stBV64JHLbnlpbMnHREUd939sa7mCWb54Y=
Received: from BYAPR18MB2534.namprd18.prod.outlook.com (2603:10b6:a03:12e::29) by BYAPR18MB2967.namprd18.prod.outlook.com (2603:10b6:a03:103::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Mon, 30 Mar 2020 16:10:38 +0000
Received: from BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::410:1331:ad08:f859]) by BYAPR18MB2534.namprd18.prod.outlook.com ([fe80::410:1331:ad08:f859%7]) with mapi id 15.20.2856.019; Mon, 30 Mar 2020 16:10:38 +0000
From: Keyur Patel 
To: SIDR Operations WG 
Thread-Topic: Closed - WG Adoption call for draft-ymbk-8210bis-00  (3/9-3/24)
Thread-Index: AQHWBq3Ap/43MNZIiEmG8oPpmuxECQ==
Date: Mon, 30 Mar 2020 16:10:37 +0000
Message-ID: <2F97B006-4E84-4C1C-B4B7-5A2B6500347A@arrcus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.22.0.200209
authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; 
x-originating-ip: [2601:646:8700:a6f0:6c01:4a89:5930:cb72]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5efae1c1-b3ed-4f0f-e59e-08d7d4c4e2e9
x-ms-traffictypediagnostic: BYAPR18MB2967:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:4125;
x-forefront-prvs: 0358535363
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BYAPR18MB2534.namprd18.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(10009020)(366004)(346002)(136003)(396003)(376002)(39830400003)(558084003)(966005)(5660300002)(6512007)(86362001)(6486002)(6506007)(6916009)(478600001)(316002)(81166006)(64756008)(8676002)(81156014)(8936002)(2906002)(186003)(66556008)(66946007)(9326002)(2616005)(76116006)(66446008)(33656002)(36756003)(66476007)(71200400001); DIR:OUT; SFP:1101; 
received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 19H2Dpb2dYr0apSe93plOg8D1JntkiKrdueCDHH1d70wHCCX0ZBHm/esak0YlfdfRPTaDZdEnKoiwI3BKoNf7Jm6h7Iwmreb80xD/ntgptJY+zM9EnpVWCC1+fAma1RHLxgSD4VHRgtMyFkddVqd/HJ9Jy4q2DKDiPbbUG1sUqpMlbsubAa4VG7xgI1ZznL7jZ8pfinwnAzuxoBRd4bgUKUgVGqfGDrcYHv5UdwI3ftcsOfsiGwqoTbsl03uayQP19Nl2hSSFgV8NMLCRwWeXCSIIPSPJ7oq1Kb3o0DOOZ9FMX7BL3dWOu0EHpG8eDVKi/x6hdmYZi17qMtAjwpwmySZfjkLXLwEYqKhygELtM9zqjkPk6+Lx1TKXLn0PWTHv/SjVZD6+RLwPUNAO8/fqgD1N1F5yQno/mCSksJGd+qFSvlBeqvDsCTzJmoB3/8GIX9xKZe7o7+Q5oVb167QU/oyJ5xJBxlaHmdmMdH9cpnHBldjiAoBVyTHPAb7p1kvZnigHMyxybkq0HrjyybvNQ==
x-ms-exchange-antispam-messagedata: ArxNzyOl8rfULUzhna9Yg6W1rjsEdtZFVd5Prz2Nh07omf90lm0Hn29YbFOfZ8UuYYXfS6fP0ah6iW2y8XBeEGwDAu43kFzXfhbh9kyvot0rOedFJdQ4SqXP8TmLkYgQ72IPnIVTmGv5ofnVeB2+lwF4MfFyDtm5D3TaIiNY3IQHgmucATtN5Rfo58jU5EsjvzZmJTKgWEtI6vIuDaHZdw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_2F97B0064E844C1CB4B75A2B6500347Aarrcuscom_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5efae1c1-b3ed-4f0f-e59e-08d7d4c4e2e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2020 16:10:37.9993 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bw01/9w7qOmxp2ovV1EM2VPuVYo3B+alBJ5X87zmNA68pvQSLCCGGb0DWdJLFA62GSS9wh3n8ZqLV8I4oO0k9A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2967
Archived-At: 
Subject: [Sidrops] Closed - WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24)
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: Mon, 30 Mar 2020 16:10:55 -0000

--_000_2F97B0064E844C1CB4B75A2B6500347Aarrcuscom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgRm9sa3MsDQoNClRoZSBXRyBoYXMgcmVhY2hlZCBjb25zZW5zdXMgdG8gYWRvcHRpb24gb2Yg
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXltYmstODIxMGJpcy0wMC4gVGhlIGF1
dGhvcnMgYXJlIHJlcXVlc3RlZCB0byBzdWJtaXQgdGhlIC0wMCB3ZyBkcmFmdC4NCg0KUmVnYXJk
cywNCk5hdGhhbGllLCBDaHJpcyAmIEtleXVyDQoNCg==

--_000_2F97B0064E844C1CB4B75A2B6500347Aarrcuscom_
Content-Type: text/html; charset="utf-8"
Content-ID: <133802E11EB22E4093F8841359818A30@namprd18.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvOw0K
CXBhbm9zZS0xOjIgMTEgNiA5IDMgOCA0IDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv
d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ
Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+SGkgRm9sa3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij5UaGUgV0cgaGFzIHJlYWNoZWQgY29uc2Vuc3VzIHRvIGFkb3B0aW9uIG9mDQo8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5
Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteW1iay04MjEwYmlz
LTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteW1iay04MjEwYmlzLTAwPC9h
Pi4gVGhlIGF1dGhvcnMgYXJlIHJlcXVlc3RlZCB0byBzdWJtaXQgdGhlIC0wMCB3ZyBkcmFmdC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOSI+UmVnYXJkcyw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1MjkiPk5hdGhhbGll
LCBDaHJpcyAmYW1wOyBLZXl1cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_2F97B0064E844C1CB4B75A2B6500347Aarrcuscom_--


From nobody Mon Mar 30 09:33:29 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 703BF3A1859 for ; Mon, 30 Mar 2020 09:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 kQw4nLso7-3Q for ; Mon, 30 Mar 2020 09:33:27 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 120F13A184F for ; Mon, 30 Mar 2020 09:33:26 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jIxLo-0002c7-52; Mon, 30 Mar 2020 16:33:24 +0000
Date: Mon, 30 Mar 2020 09:33:23 -0700
Message-ID: 
From: Randy Bush 
To: Keyur Patel 
Cc: SIDR Operations WG 
In-Reply-To: <2F97B006-4E84-4C1C-B4B7-5A2B6500347A@arrcus.com>
References: <2F97B006-4E84-4C1C-B4B7-5A2B6500347A@arrcus.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] Closed - WG Adoption call for draft-ymbk-8210bis-00 (3/9-3/24)
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: Mon, 30 Mar 2020 16:33:29 -0000

> The WG has reached consensus to adoption of
> https://tools.ietf.org/html/draft-ymbk-8210bis-00. The authors are
> requested to submit the -00 wg draft.

thanks

"The submission is pending approval by the group chairs."

randy


From nobody Mon Mar 30 09:42:20 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 100AD3A0D06; Mon, 30 Mar 2020 09:42:15 -0700 (PDT)
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.123.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: sidrops@ietf.org
Message-ID: <158558653498.6049.17060993879371239156@ietfa.amsl.com>
Date: Mon, 30 Mar 2020 09:42:15 -0700
Archived-At: 
Subject: [Sidrops] I-D Action: draft-ietf-sidrops-8210bis-00.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: Mon, 30 Mar 2020 16:42:15 -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           : The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2
        Authors         : Randy Bush
                          Rob Austein
	Filename        : draft-ietf-sidrops-8210bis-00.txt
	Pages           : 37
	Date            : 2020-03-30

Abstract:
   In order to verifiably validate the origin Autonomous Systems and
   Autonomous System Paths of BGP announcements, routers need a simple
   but reliable mechanism to receive Resource Public Key Infrastructure
   (RFC 6480) prefix origin data and router keys from a trusted cache.
   This document describes a protocol to deliver them.

   This document describes version 2 of the RPKI-Router protocol.  RFC
   6810 describes version 0, and RFC 8210 describes version 1.  This
   document updates RFC 8210.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-8210bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sidrops-8210bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis-00


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 Mar 31 08:26:55 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 AA5913A2301; Tue, 31 Mar 2020 08:26:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: morrowc@ops-netman.net, warren@kumari.net, sidrops-chairs@ietf.org, sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.123.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158566841353.28447.17169162404797640927@ietfa.amsl.com>
Date: Tue, 31 Mar 2020 08:26:53 -0700
Archived-At: 
Subject: [Sidrops] sidrops - New Interim Meeting Request
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, 31 Mar 2020 15:26:54 -0000

A new interim meeting request has just been submitted by Chris Morrow.

This request requires approval by the Area Director of the Operations and Management Area

The meeting can be approved here: 
https://datatracker.ietf.org/meeting/interim/request/interim-2020-sidrops-01



---------------------------------------------------------
Working Group Name: SIDR Operations
Area Name: Operations and Management Area
Session Requester: Chris Morrow

Meeting Type: Virtual Meeting

Session 1:

Date: 2020-04-28
Start Time: 16:00 Europe/Amsterdam
Duration: 02:00
Remote Participation Information: TBD - webex
Agenda Note: 

---------------------------------------------------------



From nobody Tue Mar 31 08:42:15 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 C8B8D3A2361 for ; Tue, 31 Mar 2020 08:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 PVI-SnBIVTah for ; Tue, 31 Mar 2020 08:42:12 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 90F483A236C for ; Tue, 31 Mar 2020 08:42:12 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id o10so23407315qki.10 for ; Tue, 31 Mar 2020 08:42:12 -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=4+O9Ehpbrxmd89fd93+rDxvo4m6q33p/OKzL6h6gHpI=; b=I65h0VSCWOu8ANeJKXaDPtbMsoKDlIQAdFvvn3rB7MoGzSnsEJsKKtn/DlsKzIEA2i 71cIegI6zTXZL6iJ7ir/b2Q+Tk0khbdG9oX3voSgIkixHuYX2VP49Q1+rN73RBfSt94i qMiEyAE/na2yXmk/2lTKEMILK0DcMSMaekwqWpjZlQsbDxj4sRHTOd9nvoS8ld2X40eJ DGXH2XSpzcxi6X4wnmNoP+bm1+8rwwP8TWO278DIKu9p0Z6o/w+PJL7x8w75eshRN6ln /QKnenAqSCDUdQYCIQp3YD5BkC8Rd3E6Q0WhOU26NQiIT+1uBrK0Ndk3RqRCguUJyDjx yVZw==
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=4+O9Ehpbrxmd89fd93+rDxvo4m6q33p/OKzL6h6gHpI=; b=SJv60xRwp+B8SjAzF60fkRGUd7Scm3S8ZBw4eWo5WFBNwkwCh+f09gvPl53JFZeaDq crt4Mo9KAEZyt05ej0DpyfmjxFVZ7TeXn/lqgOA4CH9opuvk4zCtpVP6Zi8laADZ/PR+ gSznnGAi2d1kBt83lMzUlW3cIzjc0GHGnEqKKQHCSZgdXDspACDrAT7FrCzbLqnoeiUb Pdtc0K6bqrjf1JXsnoJ/7++FnDGbepMykTX2+JTy8qZa3NnP8taZWnhe6gzMgp0b+twr wUtK8SEsF9D3Cl0BenZKH8+7KOGFeJTXHG2k/FouMs9Qw8ZqaLSEKA4Kp8f2Py8EiwW7 GUlA==
X-Gm-Message-State: ANhLgQ0kEIQSUapGTqFTzkx+GzJMrkIlx186RvfTHRnQQ/NojZrOeo9P qoWt74+sj7R9pz4rxn0nd8rzp5zmC5HeE0kU9BCsdH/q
X-Google-Smtp-Source: ADFU+vtOEw4XoyCkFdmNo/NEQalA/57g9HWG+Nmjqqn+19MiPAE4VvSqQsWSxAKcqtL9qAaPwbprPAf7mqnRy1eKJi8=
X-Received: by 2002:a37:a991:: with SMTP id s139mr4661097qke.116.1585669331363;  Tue, 31 Mar 2020 08:42:11 -0700 (PDT)
MIME-Version: 1.0
References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl>  <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com> 
In-Reply-To: 
From: Christopher Morrow 
Date: Tue, 31 Mar 2020 11:42:00 -0400
Message-ID: 
To: Stephen Kent 
Cc: Job Snijders , SIDR Operations WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Sidrops] what to do when the CRL is hosed?
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, 31 Mar 2020 15:42:14 -0000

first, apologies for getting back around to this so late :(

On Thu, Mar 26, 2020 at 10:57 AM Stephen Kent
 wrote:

> So, I think discussing MITM attacks is a distraction, unless we have examples of how
> such attacks can affect RPs in ways different from attacks on repositories. Maybe re-reading
> RFC 8211 would be useful, as it tries to analyze a range of possible "adverse actions"  by CAs or
> repository managers in the RPKI context, and discusses how RPKI mechanisms are intended to
> detect/counter these actions.

In the case of the incident which started this thread we ended up
publishing part of the content a
repository needs to publish such that the relying parties can verify
properly that the content in the
repository is correct/valid/usable. The discussion then went along a path like:
   1) "well... maybe we shouldn't have belt and suspenders?" (manifest AND crl)
   2) "what happens if we don't publish this pesky CRL? and rely only
on the manifest?"
   3) "what if we don't publish the manifest and only rely on the CRL?"
   4) "CRL + Manifest has made 'rp software' hard/buggy"

In the world where the protections specified for RPKI exist:
  1) self contained content protection (roa / ee-certs / etc are
packaged securely)
  2) crl signed and available in the repository for revocation actions
on objects in the repository
  3) manifest signed and listing all objects of interest in the repository

Steve (kent!) is right mitm is harder to see as a threat.
  "All objects you get are signed by a ca-cert which is signed by the
root.. which is in the list of TAL you have. You can't have missing
objects and you cant' remove objects without affecting the signed
manifest"

In a world where we remove one/some of the protections:
   A) no more manifest
   B) no more crl
   C) both

I think mitm problems are much harder to detect/deal with :(
It sounds like WG folk (RP users and RP/CA software authors) are
asking for guidance on handling the problem(s) discussed here.
It sounds, to me, like a chat at the upcoming interim meeting would be
a great place to start that with some slideware and a proposal to use
as kindling.

I think the shape of the conversation is roughly:
  "What would be the effect (on the routing system) for RelyingParties
if we decided to be less strict about CRL existence?"
  "What would be the effect (on the routing system) for Relying
Parties if we decided to be less strict about repository contents vs
Manifest contents?"
  "What happens to the routing system if the manifest and crl are
either/both 'broken' in a repository?"

I don't think it matters much to the routing system where the breakage
occurs (my repository or RIPE/ARIN/etc) certainly there's more fallout
from ARIN/RIPE/etc, but... you can't get to me either way :)
(possibly) until repair and propogation.

Thoughts on some slideware and discussion?
Did I about capture the meat of the sandwich here?

-chris
co-chair but asking as a regular chemical engineer at this party.


From nobody Tue Mar 31 11:51:24 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 02E503A26CB; Tue, 31 Mar 2020 11:51:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary 
To: "IETF-Announce" 
Cc: sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.123.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158568067894.28385.17648549447667105911@ietfa.amsl.com>
Date: Tue, 31 Mar 2020 11:51:19 -0700
Archived-At: 
Subject: [Sidrops] SIDR Operations (sidrops) WG Virtual Meeting: 2020-04-28
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, 31 Mar 2020 18:51:19 -0000

The SIDR Operations (sidrops) Working Group will hold
a virtual interim meeting on 2020-04-28 from 16:00 to 18:00 Europe/Amsterdam (14:00 to 16:00 UTC).

Agenda:
Agenda - Interim 04/2020

1) CRL ? Manifest ? Hashbrowns? - guidance for chefs
2) other ongoing work
3) punch and pie

Information about remote participation:
TBD - webex


From nobody Tue Mar 31 15:21:20 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 67F853A0BE9 for ; Tue, 31 Mar 2020 15:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.20150623.gappssmtp.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 HRW0lZUL-Fio for ; Tue, 31 Mar 2020 15:21:06 -0700 (PDT)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 2E03E3A0BEF for ; Tue, 31 Mar 2020 15:21:06 -0700 (PDT)
Received: by mail-il1-x129.google.com with SMTP id g15so21081909ilj.10 for ; Tue, 31 Mar 2020 15:21:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yIcHb0sEKOwt9NNclIumomimheVqH9C4jLsyubBYlOk=; b=jjNSJo/3WrcoW0PE9ZpWx80mFZRAWlgvtuSxNpPqXSibtA9Fbvmxlzq3aCn2FDX9Pi J4h/8GjRgNu+AqzubHm5nXPQyk3bvm7OehDDzgAthTvPynW6jXI5Hc/ipYqOboiGBz6D kqKL3lxn4JyXMEUre4Aug2hYyVqMSYoCvn33JEq2idRzGnkgLFLP7e2FYx7tcA4HvkoU woCUnYm6pTiayJr88IMLpgWY9S5MPKCyLD7+GKncTfk2ChzOdEVOSusDPoqqdDbtESm8 t+ht4WQFRpMFvEg0f//cjqYiCcc8p39qSPLA08VpRr2wxx8IXT55PefGOpccJHXPFnso NoKQ==
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=yIcHb0sEKOwt9NNclIumomimheVqH9C4jLsyubBYlOk=; b=d4aQz4CoFOl/z5ZBUZjoON02fhn3tPiOaxuJyYN6Wfb3RiqGfdlDGhqG4ogq03DAJb nVFkKUrmKb/tDUmaPsVOEkbLOAVKxLr9cTFA9wvhQHUp9bczIOWwkTiEcPwBVgrPz4H3 Vp3KjeukY7crdvLYKfP1RlYi6hOeQofYoLfnkPciE6ittoC8GxtevchEdMqOv9WHM9hk CVPpoVQwf/WFH/ByqTqwBoHSPHcHsqvasu3HvMtEYGDtDEKo1/69ZsXQPxtscI42cgp1 +GuPB7BbyZ3i6L7takrJOXBQO51XhUL1OP3mXKFFolBrupTqiBsz2d7Pt9QC3X5Jhp9k lhxA==
X-Gm-Message-State: ANhLgQ2KNuv4oeJckzyXM3p7OcVilriBV5NqmYKknL7YZqrB0qRFORoJ 4P54StjCNvuRlIBNpH7eES34PS0d/9cH5jfDpVyJsA==
X-Google-Smtp-Source: ADFU+vuDI+0kj5K5QgPJFfMH5koXJO1qCG2fNTkvFs241PXnV7UOm2kPFvK9p1FSk3YQyvNmWrP9lPIle02PeOgIGXA=
X-Received: by 2002:a92:8517:: with SMTP id f23mr19629731ilh.106.1585693265139;  Tue, 31 Mar 2020 15:21:05 -0700 (PDT)
MIME-Version: 1.0
References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl>  <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com>  
In-Reply-To: 
From: George Michaelson 
Date: Wed, 1 Apr 2020 08:20:53 +1000
Message-ID: 
To: Christopher Morrow 
Cc: SIDR Operations WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Sidrops] what to do when the CRL is hosed?
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, 31 Mar 2020 22:21:17 -0000

I think you did capture the spirit.

I would remind people that *all* the products in a repository are
signed objects. To arrive at a state where a manifest is "wrong"
demands two things: it doesn't reflect some real-world situation
regarding contents of the repository *and* its signed by keys you can
validate back to a trust anchor. If you cannot validate the manifest,
then its not "wrong" its forged, or invalid cryptographically.  To me,
a  "wrong" manifest checks out cryptographically but somehow is not
coherent with the state of the repository. If objects are on the
manifest but cannot be fetched, you are probably suffering either from
hiding of objects, or a transitional state of publication. If objects
can be found which are not on the manifest, you may be seeing
artifacts which are not defined as critical (must be found) or, the
manifest has not yet been updated.

There are potentially transitional states in the production of a large
repository under eventually consistent production (e.g. multiple
asynchronous cooperating processes, dual-redundant signing models)
where what can be fetched and what is on manifest do not align.  If we
wish to demand that the manifest and a given state of the repository
*always* align, we need to formalise that in a way which makes it
clear we publish repository state in as close to atomic-update as
possible. (copying a repo to a new dir, modifying the contents of the
new dir, and (re)publishing the change through the rename() call in
UNIX is one such model)

A missing manifest is not a "wrong" manifest -its a sign of data being
hidden from you either because of transitional effect in publishing
the repository, or for persisting state a problem in the repository
(diskfull?) or, production systems, or a MITM attack. Which do you
think is actually most likely at this current time? This is no
different to a missing CRL in that regard. Which do you think is the
most likely reason, because you cannot a-priori know that its a MITM
attack, or a failure in networks, or storage systems, or production
systems.

During the early design phases of the system, we determined that since
the products were all cryptographically signed, there was no strict
requirement for cryptographic protections on transport. If that
decision needs to be revised I think it should be done in standards
work, here, as a discussion. I do not yet see a document which says
that. I don't see formalisms which go to a normative change in SHOULD
to MUST on this.

So these comments aside, my plea is that people clearly state when
they say "wrong" or "bad" if they mean that it is cryptographically
valid, but does not align with some external reality, or some other
meaning. (Which btw, is complex because the part which none of this
can adequately capture is *intentionality* -Just because you think a
publication of RPKI state is nonsensical does not mean its not
intentional)

Attack models need to state clearly how they acheve the state. An
attack on the integrity of the manifest needs to explain coherently
how it creates a manifest which checks out cryptographically, and yet
hides or legitemates something which should not exist. They also need
to explain how the specific attack on the manifest in these situation
outweighs other considerations: If they have the keys, then surely the
attack vector is to make validly signed things which cannot be
detected as an attack?

-George

On Wed, Apr 1, 2020 at 1:42 AM Christopher Morrow
 wrote:
>
> first, apologies for getting back around to this so late :(
>
> On Thu, Mar 26, 2020 at 10:57 AM Stephen Kent
>  wrote:
>
> > So, I think discussing MITM attacks is a distraction, unless we have examples of how
> > such attacks can affect RPs in ways different from attacks on repositories. Maybe re-reading
> > RFC 8211 would be useful, as it tries to analyze a range of possible "adverse actions"  by CAs or
> > repository managers in the RPKI context, and discusses how RPKI mechanisms are intended to
> > detect/counter these actions.
>
> In the case of the incident which started this thread we ended up
> publishing part of the content a
> repository needs to publish such that the relying parties can verify
> properly that the content in the
> repository is correct/valid/usable. The discussion then went along a path like:
>    1) "well... maybe we shouldn't have belt and suspenders?" (manifest AND crl)
>    2) "what happens if we don't publish this pesky CRL? and rely only
> on the manifest?"
>    3) "what if we don't publish the manifest and only rely on the CRL?"
>    4) "CRL + Manifest has made 'rp software' hard/buggy"
>
> In the world where the protections specified for RPKI exist:
>   1) self contained content protection (roa / ee-certs / etc are
> packaged securely)
>   2) crl signed and available in the repository for revocation actions
> on objects in the repository
>   3) manifest signed and listing all objects of interest in the repository
>
> Steve (kent!) is right mitm is harder to see as a threat.
>   "All objects you get are signed by a ca-cert which is signed by the
> root.. which is in the list of TAL you have. You can't have missing
> objects and you cant' remove objects without affecting the signed
> manifest"
>
> In a world where we remove one/some of the protections:
>    A) no more manifest
>    B) no more crl
>    C) both
>
> I think mitm problems are much harder to detect/deal with :(
> It sounds like WG folk (RP users and RP/CA software authors) are
> asking for guidance on handling the problem(s) discussed here.
> It sounds, to me, like a chat at the upcoming interim meeting would be
> a great place to start that with some slideware and a proposal to use
> as kindling.
>
> I think the shape of the conversation is roughly:
>   "What would be the effect (on the routing system) for RelyingParties
> if we decided to be less strict about CRL existence?"
>   "What would be the effect (on the routing system) for Relying
> Parties if we decided to be less strict about repository contents vs
> Manifest contents?"
>   "What happens to the routing system if the manifest and crl are
> either/both 'broken' in a repository?"
>
> I don't think it matters much to the routing system where the breakage
> occurs (my repository or RIPE/ARIN/etc) certainly there's more fallout
> from ARIN/RIPE/etc, but... you can't get to me either way :)
> (possibly) until repair and propogation.
>
> Thoughts on some slideware and discussion?
> Did I about capture the meat of the sandwich here?
>
> -chris
> co-chair but asking as a regular chemical engineer at this party.
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Tue Mar 31 20:04:19 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 AA40C3A0791 for ; Tue, 31 Mar 2020 20:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 0ohK11e0Qb-4 for ; Tue, 31 Mar 2020 20:04:10 -0700 (PDT)
Received: from smtpbg519.qq.com (smtpbg516.qq.com [203.205.250.54]) (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 D47103A078C for ; Tue, 31 Mar 2020 20:04:09 -0700 (PDT)
X-QQ-mid: bizesmtp12t1585710179txnw3xs8
Received: from [192.168.3.24] (unknown [118.198.181.5]) by esmtp6.qq.com (ESMTP) with  id ; Wed, 01 Apr 2020 11:02:56 +0800 (CST)
X-QQ-SSF: 00400000002000N0ZI80B00A0000000
X-QQ-FEAT: ltIUYrhUXasIiri9BEXoIJS+6XiU2QTq45R2IF8/twKKVsD6fP3BdNl7mOuDQ 6XXvGF+MC0QLahHOU1OtGzN02nzzc3luTtu7C4gUychZ660DCym/05NSOE+V7T/kWrmN/0k VRaH5C/HC17Dcpjm7gWvrI96jgfXM0XO8utXZbBOqXczRG4Mc2ekbDpZivKr1TBNWBeZ+0e qLWazcdKvJBUplr8GG9sv6+4OJzbVTaEmjPslqJLU4Lbn31WE4tZyVRbHaVAvdfsUoPAFdJ 19tB0kZW2XLJaWU66SehFqFfqFSlzlJBz/+cZPAbLfyPR1xaQKxiPa56iN8sADj+GKW5kDR mm3eKdHaOIAxewKg/nVA7U1qMKOc5EomzXGtGnf
X-QQ-GoodBg: 2
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Di Ma 
In-Reply-To: 
Date: Wed, 1 Apr 2020 11:02:48 +0800
Cc: Christopher Morrow , SIDR Operations WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl>  <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net> <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com> <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl> <20200324135828.GG60268@vurt.meerval.net> <20200324152009.6e6a2c3f@glaurung.nlnetlabs.nl> <20200324151101.GH60268@vurt.meerval.net> <7f54a255-643f-cd2d-12c2-da19562bbffa@verizon.net> <7465c59f-fa10-4083-8e52-291cb47587f6@www.fastmail.com>   
To: George Michaelson 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:zdns.cn:qybgweb:qybgweb13
Archived-At: 
Subject: Re: [Sidrops] what to do when the CRL is hosed?
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: Wed, 01 Apr 2020 03:04:18 -0000

Yes.

Although the RPKI provides object-oriented security yet the validity of =
an object relies on a trust chain, any wrong node of which would cause =
failure.

So-called =E2=80=9Cwrong=E2=80=9D MFT will bring about trouble no matter =
it is rooted from transport or RPKI provisioning side.

Situations could be complicated as analyzed in section 2.2 of RFC 8211 =
in terms of adverse actions on MFT but RFC 6488 leaves much to RP to =
decide.

BTW, in RFC 8211 we authors differentiate if the attacker have got =
access to the private key of the INR holder, trying to give a threat =
mode.

So it is right time to reconsider the requirements posed on RP in case =
of =E2=80=9Cwrong=E2=80=9D MFT.=20

Di

> 2020=E5=B9=B44=E6=9C=881=E6=97=A5 06:20=EF=BC=8CGeorge Michaelson =
 =E5=86=99=E9=81=93=EF=BC=9A
>=20
> I think you did capture the spirit.
>=20
> I would remind people that *all* the products in a repository are
> signed objects. To arrive at a state where a manifest is "wrong"
> demands two things: it doesn't reflect some real-world situation
> regarding contents of the repository *and* its signed by keys you can
> validate back to a trust anchor. If you cannot validate the manifest,
> then its not "wrong" its forged, or invalid cryptographically.  To me,
> a  "wrong" manifest checks out cryptographically but somehow is not
> coherent with the state of the repository. If objects are on the
> manifest but cannot be fetched, you are probably suffering either from
> hiding of objects, or a transitional state of publication. If objects
> can be found which are not on the manifest, you may be seeing
> artifacts which are not defined as critical (must be found) or, the
> manifest has not yet been updated.
>=20
> There are potentially transitional states in the production of a large
> repository under eventually consistent production (e.g. multiple
> asynchronous cooperating processes, dual-redundant signing models)
> where what can be fetched and what is on manifest do not align.  If we
> wish to demand that the manifest and a given state of the repository
> *always* align, we need to formalise that in a way which makes it
> clear we publish repository state in as close to atomic-update as
> possible. (copying a repo to a new dir, modifying the contents of the
> new dir, and (re)publishing the change through the rename() call in
> UNIX is one such model)
>=20
> A missing manifest is not a "wrong" manifest -its a sign of data being
> hidden from you either because of transitional effect in publishing
> the repository, or for persisting state a problem in the repository
> (diskfull?) or, production systems, or a MITM attack. Which do you
> think is actually most likely at this current time? This is no
> different to a missing CRL in that regard. Which do you think is the
> most likely reason, because you cannot a-priori know that its a MITM
> attack, or a failure in networks, or storage systems, or production
> systems.
>=20
> During the early design phases of the system, we determined that since
> the products were all cryptographically signed, there was no strict
> requirement for cryptographic protections on transport. If that
> decision needs to be revised I think it should be done in standards
> work, here, as a discussion. I do not yet see a document which says
> that. I don't see formalisms which go to a normative change in SHOULD
> to MUST on this.
>=20
> So these comments aside, my plea is that people clearly state when
> they say "wrong" or "bad" if they mean that it is cryptographically
> valid, but does not align with some external reality, or some other
> meaning. (Which btw, is complex because the part which none of this
> can adequately capture is *intentionality* -Just because you think a
> publication of RPKI state is nonsensical does not mean its not
> intentional)
>=20
> Attack models need to state clearly how they acheve the state. An
> attack on the integrity of the manifest needs to explain coherently
> how it creates a manifest which checks out cryptographically, and yet
> hides or legitemates something which should not exist. They also need
> to explain how the specific attack on the manifest in these situation
> outweighs other considerations: If they have the keys, then surely the
> attack vector is to make validly signed things which cannot be
> detected as an attack?
>=20
> -George
>=20
> On Wed, Apr 1, 2020 at 1:42 AM Christopher Morrow
>  wrote:
>>=20
>> first, apologies for getting back around to this so late :(
>>=20
>> On Thu, Mar 26, 2020 at 10:57 AM Stephen Kent
>>  wrote:
>>=20
>>> So, I think discussing MITM attacks is a distraction, unless we have =
examples of how
>>> such attacks can affect RPs in ways different from attacks on =
repositories. Maybe re-reading
>>> RFC 8211 would be useful, as it tries to analyze a range of possible =
"adverse actions"  by CAs or
>>> repository managers in the RPKI context, and discusses how RPKI =
mechanisms are intended to
>>> detect/counter these actions.
>>=20
>> In the case of the incident which started this thread we ended up
>> publishing part of the content a
>> repository needs to publish such that the relying parties can verify
>> properly that the content in the
>> repository is correct/valid/usable. The discussion then went along a =
path like:
>>   1) "well... maybe we shouldn't have belt and suspenders?" (manifest =
AND crl)
>>   2) "what happens if we don't publish this pesky CRL? and rely only
>> on the manifest?"
>>   3) "what if we don't publish the manifest and only rely on the =
CRL?"
>>   4) "CRL + Manifest has made 'rp software' hard/buggy"
>>=20
>> In the world where the protections specified for RPKI exist:
>>  1) self contained content protection (roa / ee-certs / etc are
>> packaged securely)
>>  2) crl signed and available in the repository for revocation actions
>> on objects in the repository
>>  3) manifest signed and listing all objects of interest in the =
repository
>>=20
>> Steve (kent!) is right mitm is harder to see as a threat.
>>  "All objects you get are signed by a ca-cert which is signed by the
>> root.. which is in the list of TAL you have. You can't have missing
>> objects and you cant' remove objects without affecting the signed
>> manifest"
>>=20
>> In a world where we remove one/some of the protections:
>>   A) no more manifest
>>   B) no more crl
>>   C) both
>>=20
>> I think mitm problems are much harder to detect/deal with :(
>> It sounds like WG folk (RP users and RP/CA software authors) are
>> asking for guidance on handling the problem(s) discussed here.
>> It sounds, to me, like a chat at the upcoming interim meeting would =
be
>> a great place to start that with some slideware and a proposal to use
>> as kindling.
>>=20
>> I think the shape of the conversation is roughly:
>>  "What would be the effect (on the routing system) for RelyingParties
>> if we decided to be less strict about CRL existence?"
>>  "What would be the effect (on the routing system) for Relying
>> Parties if we decided to be less strict about repository contents vs
>> Manifest contents?"
>>  "What happens to the routing system if the manifest and crl are
>> either/both 'broken' in a repository?"
>>=20
>> I don't think it matters much to the routing system where the =
breakage
>> occurs (my repository or RIPE/ARIN/etc) certainly there's more =
fallout
>> from ARIN/RIPE/etc, but... you can't get to me either way :)
>> (possibly) until repair and propogation.
>>=20
>> Thoughts on some slideware and discussion?
>> Did I about capture the meat of the sandwich here?
>>=20
>> -chris
>> co-chair but asking as a regular chemical engineer at this party.
>>=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