From nobody Thu Jun 4 03:57: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 9DDD93A07E9 for ; Thu, 4 Jun 2020 03:57:17 -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 MS6dmhbgxxvf for ; Thu, 4 Jun 2020 03:57:15 -0700 (PDT) Received: from out20-61.mail.aliyun.com (out20-61.mail.aliyun.com [115.124.20.61]) (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 E43773A095E for ; Thu, 4 Jun 2020 03:57:11 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.08174563|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_social|0.0373861-0.00163755-0.960976; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03295; MF=madi@rpstir.net; NM=1; PH=DS; RN=1; RT=1; SR=0; TI=SMTPD_---.Hi3Q18E_1591268220; Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.Hi3Q18E_1591268220) by smtp.aliyun-inc.com(10.147.41.138); Thu, 04 Jun 2020 18:57:01 +0800 From: Di Ma Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <17C6C716-0D17-4AFA-8796-9F23EA18E4EE@rpstir.net> References: <159126752321.27626.9482196489134080033@ietfa.amsl.com> To: SIDR Operations WG Date: Thu, 4 Jun 2020 18:56:59 +0800 X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Sidrops] Fwd: New Version Notification for draft-madi-sidrops-rush-01.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: Thu, 04 Jun 2020 10:57:18 -0000 Hi, folks=EF=BC=8C We authors update the RUSH draft (-01 version). The major change is that we make the RUSH usecase an extra section, = especially adding the usage for AS0 SLURM file re discussions on the = policy proposal=20 =E2=80=98SLURM file for Unallocated and Unassigned RIPE NCC Address = Space=E2=80=99=20 Special thanks go to Melchior Aelmans for his help in retrofitting the = RUSH usecase clarification. Any comments will be appreciated.=20 Di > =E4=B8=8B=E9=9D=A2=E6=98=AF=E8=A2=AB=E8=BD=AC=E5=8F=91=E7=9A=84=E9=82=AE= =E4=BB=B6=EF=BC=9A >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org > =E4=B8=BB=E9=A2=98: New Version Notification for = draft-madi-sidrops-rush-01.txt > =E6=97=A5=E6=9C=9F: 2020=E5=B9=B46=E6=9C=884=E6=97=A5 GMT+8 18:45:23 > =E6=94=B6=E4=BB=B6=E4=BA=BA: "Di Ma" , "Hanbing Yan" = >=20 >=20 > A new version of I-D, draft-madi-sidrops-rush-01.txt > has been successfully submitted by Di Ma and posted to the > IETF repository. >=20 > Name: draft-madi-sidrops-rush > Revision: 01 > Title: RPKI validated cache Update in SLURM over HTTPs = (RUSH) > Document date: 2020-06-04 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-madi-sidrops-rush-01.txt > Status: = https://datatracker.ietf.org/doc/draft-madi-sidrops-rush/ > Htmlized: https://tools.ietf.org/html/draft-madi-sidrops-rush-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rush > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-madi-sidrops-rush-01 >=20 > Abstract: > This document defines a method for transferring RPKI validated cache > update information in JSON object format over HTTPs. >=20 >=20 >=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 > The IETF Secretariat >=20 >=20 >=20 From nobody Thu Jun 4 11:12:30 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 CD23E3A0C9B; Thu, 4 Jun 2020 11:12:27 -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: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159129434770.4548.6332626749429708287@ietfa.amsl.com> Date: Thu, 04 Jun 2020 11:12:27 -0700 Archived-At: Subject: [Sidrops] SIDR Operations (sidrops) WG Virtual Meeting: 2020-06-24 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, 04 Jun 2020 18:12:28 -0000 The SIDR Operations (sidrops) WG will hold a virtual interim meeting on 2020-06-24 from 16:00 to 17:30 Europe/Amsterdam (14:00 to 15:30 UTC). Agenda: RFC6486 update work Information about remote participation: https://ietf.webex.com/meet/sidrops From nobody Thu Jun 4 13:22:45 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 5A9F63A0F29; Thu, 4 Jun 2020 13:22:43 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YHs_fLjb0Xy; Thu, 4 Jun 2020 13:22:42 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 02F763A0F26; Thu, 4 Jun 2020 13:22:42 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id w3so7534778qkb.6; Thu, 04 Jun 2020 13:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YzSd+1vWbUVl2tC0wjxH2VwL+FetJ38XP1R59kQPPSE=; b=Ar8q1ZO1fSl3n4YH4ctP4p43IKbScEPfQRe5vX1NITudAKd/9KHogtZg0wLhl6fOnX 3UBu7VoBBfstukDhHsiRlhHqmWQgOP4++MsKmERPFISVcCha1sAEe4Ld7qcagauahhvX VwFhcfW0o4QqUwBKfBki6tFEPArzw9Hs/9lO7d8rIOu9YFecbdDlJFETFIhOcGuMJA/A XuqH7hoSkBoHPURvAz4McldlH4NtQqwVat4gmvI7km8klVoIKsbpV6rhGcN7Zn6+drTZ cq/z0F9aPG0LkLMSttxp8Yp+YUijBrlmJ1zdNp3PpUnTGYH/P4R1qR12dVSsd4CMC/CR caXQ== 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=YzSd+1vWbUVl2tC0wjxH2VwL+FetJ38XP1R59kQPPSE=; b=IUtioPyp6hFbPlDflzRvzMMM2izQ2HJEqHVoU+Mt/UIREqOw6u46IfEdH8yapKu1Zb 6H3BC9HbcbAIykKGjYZvmHfPGrewa4wgnfGd5Z2aIeMeSOiaMqkpqyYfkvofnTlQj/ES jDwdeNkRL3BrFM64CLAWd8GdH0aCZiUZdc2Ai1ReQmEanc1Chnz/kihsutMs8+E5U7CM uK3wmqlKwW1MRiDl0mupG4bINiQjEwfhw0BLNUAI8Mk6Qio6mctsKo+87PIvHFomCw4/ QvrNoCx6hHPLTACb0VZMTDGlqsmGJUosCjYe3zpIkBW76nO+faSAk5x2gc714ShyfkD3 J1qA== X-Gm-Message-State: AOAM533cYYg+auYMVg1WTk07tQh+2cudNhw+bJXiijpUVHVoAyztHBaX lF6HpHTOPrvQe8mAyuyxB644tHZjNBaG1wKAfCG1rvC+bIU= X-Google-Smtp-Source: ABdhPJxqDkNx7szeA2S1T0ln6nfp7rgaDxm4NvJO2SZ4vNC4aw30qszPy1dFj9N2hYpAEjS3TSOtYRQFelE3AXeLU4Y= X-Received: by 2002:a37:48c8:: with SMTP id v191mr6878056qka.268.1591302160848; Thu, 04 Jun 2020 13:22:40 -0700 (PDT) MIME-Version: 1.0 From: Christopher Morrow Date: Thu, 4 Jun 2020 16:22:30 -0400 Message-ID: To: SIDROps Chairs , SIDR Operations WG , sidrops-ads@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] [WGLC] draft-ietf-sidrops-signed-tal - ends 18/Jun/2020 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, 04 Jun 2020 20:22:44 -0000 Howdy WG folks! we have had a few discussions and starter-steps for: WGLC - draft-ietf-sidrops-signed-tal I think we never officially WGLC'd this document. I think it'd be terrific if we could get folk to re-read, and comment/assent/dissent (politely!:) ) on this topic now. Please have a read, the Abstract is thusly presented: "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." and I'd like to conclude Jun 18 2020 if t all possible :) Of course, if the authors are: "Yo! this is not ready! back to the easy-bake please!" that's also cool, just trying to force conversation and forward momentum I am! :) -chris co-chair-frog-smasher From nobody Thu Jun 4 21:48: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 3B78B3A1266; Thu, 4 Jun 2020 21:48:48 -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 ShLW9Mq9Bwxl; Thu, 4 Jun 2020 21:48:46 -0700 (PDT) Received: from relay.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe4c:9503]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5E23A1264; Thu, 4 Jun 2020 21:48:46 -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 CD4123C21CA; Fri, 5 Jun 2020 04:48:43 +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 9A4E9231; Fri, 5 Jun 2020 04:48:43 +0000 (UTC) Date: Fri, 05 Jun 2020 04:48:43 +0000 Message-ID: <87sgfa86dw.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] SIDROPS Interim Meeting - 24/June/2020 0700 PDT / 1000 EDT / 1600 CDT 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, 05 Jun 2020 04:48:48 -0000 Howdy SIDROPS Folks! I think we chatted at the end of the previous meeting about needing a follow-up regarding some of the pending changes to RFC6486 which were discussed at the last event. I believe we still need to do this, there seems to be some good energy and progress being made, let's meet and chat about that some more! We're putting in an Interim Meeting request for: June 24 2020 - 0700 PDT / 1000 EDT / 1600 CDT June 25 2020 - 0000 "Sydney Time" I would like to proctor a meeting with some slides about the current state of the discussion and a strawman to batter with a few lead pipes (maybe you all will agree with me, who knows!) and see if we can get to a reasonable answer. In the coming week or so I'll try to email a reasonable position and get some slides organized, I expect some in-meeting chat from the current Editors/Authors of the BIS document, provided they can all attend :) thanks! -chris co-chariot-rider-in-storms ps: https://datatracker.ietf.org/meeting/interim-2020-sidrops-02/session/sidrops From nobody Fri Jun 5 08:27:43 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 982533A07BB for ; Fri, 5 Jun 2020 08:27:42 -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 PHwmep3qJNol for ; Fri, 5 Jun 2020 08:27:41 -0700 (PDT) Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 4E1AB3A07B9 for ; Fri, 5 Jun 2020 08:27:41 -0700 (PDT) Received: by mail-oo1-xc2b.google.com with SMTP id 18so2055820ooy.3 for ; Fri, 05 Jun 2020 08:27:41 -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=nMCYwJoXuVsoJ/TLgKMyWWc5T7u6eLqOjjI6D9xSQbw=; b=qy20zaHT6AKxjQFhkw+RI7xdi5xvakrDuSJ/Ofw/8wJ5ZPXOZU9NR0ybz507zRqc1C OYGVwGaOp3d8sNaQZVV2Wk67FusNR95P0AUkQ4zH/bzu+jKGhmWZZBQi6C81yqJM070U wFB5h9wBpL1hmya7U7fpoJ7+5G8HEA/fk6t00SW6wFvl0WkF2jXbmoA68T/Jpqx12gmO 7Ym4SyCCt+NG2PW6+tfhS9RSYVvAfq1KEEp5W+oIp+7JGJlRI67b09nb3iUHBFOi6hxV 7xOzYdsg/sZy1OZXyKKD2fkgwCuFB7M720mEZxZ3AcPY0FgylBuCpjZ7XTkvv4w+/Qcw QVcA== 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=nMCYwJoXuVsoJ/TLgKMyWWc5T7u6eLqOjjI6D9xSQbw=; b=HJ2Wq4FYkqC4GHpk54fPok4W7YYdCIYHk1JXokgbQrAnH+YLO0nPjWL8OHGRC1JpsS OCRELe9JG3F+s7eeH6idotCa3l80tVfMv0ygsadjgFMMZW0HWzgTn5sGyqLSDPojDBzZ 2Rh9SX+KmV0kgxO57DWwDvX52sU/B7gIud61px830mxPqiKl8sqfPMmRWLRFwTYsMZve /uyqM/A4/bxyRhu3DY1xFdLZ6JHJCNGCis8nP7rQURkClCFLLrbx2VgeToEAsC+bC6ip vO1whtVE26jNdDw16wJw9uLp3uQU0+p8oYuPfOMtlItlH2dJ84fziSrCFtz+3NZhC5lw Ggeg== X-Gm-Message-State: AOAM531s02wG+GdWMWXZM0Iw9kxNpU8QCzuNYmCtWfgxe6ont9t7lL0u z5H4UsD/90fni+hTV8UJfswGpj698Xb76Rh10VQ= X-Google-Smtp-Source: ABdhPJyoIUhLfnW0OpEsA+jYgDdqoWl1h9OY5YOijc3RwhGI4xbu6wh0sZK5ZbGAez/qGjTJTD89jJilKrxm9amAHbg= X-Received: by 2002:a4a:e6d2:: with SMTP id v18mr8122127oot.34.1591370860488; Fri, 05 Jun 2020 08:27:40 -0700 (PDT) MIME-Version: 1.0 References: <24249.23930.126312.2484@oz.mt.att.com> In-Reply-To: From: Alexander Azimov Date: Fri, 5 Jun 2020 18:27:29 +0300 Message-ID: To: Guyunan Cc: Jay Borkenhagen , SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000d86b3c05a757e611" Archived-At: Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04 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, 05 Jun 2020 15:27:43 -0000 --000000000000d86b3c05a757e611 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yanun, sorry for the late response. Your suggestion to ignore the first ASN in the path if the prefix is received from IXP with its ASN in the path sounds reasonable for me. It will improve the quality of ingress filtering by IXP members. I will add it to the todo list for the next version. =D1=81=D1=80, 20 =D0=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=B2 10:53, Guyunan : > Alex, > > > > Please see inline. > > > > *From:* Alexander Azimov [mailto:a.e.azimov@gmail.com] > *Sent:* Friday, May 15, 2020 10:33 PM > *To:* Guyunan > *Cc:* Jay Borkenhagen ; SIDR Operations WG < > sidrops@ietf.org> > *Subject:* Re: [Sidrops] question on > draft-ietf-sidrops-aspa-verification-04 > > > > Jay, Yunan, > > > > Thank you for the suggestion. The mutual transit sounds good to me too. > > > > Yunan: All right, so let=E2=80=99s assume in one case, the IXP does not p= repend > its own ASN, meaning the RS and one of its RS clients receives the same > AS_Path, right? According to Section 5.1 (see below) and Section 5.2 (see > below), I=E2=80=99m wondering why the detection rules are different for t= his RS > (obeying Section 5.1) and this RS client (obeying Section 5.2) regarding > the same AS_Path. > > I think I got your point. You are asking why can't we process prefixes > from RS likewise prefixes from peers, right? > > > > Yunan: Right. > > > > The reason is that I've tried to describe the policy that will be > applicable in general, so it covers the worst-case scenario when IX place= s > it ASN in the path. It possible to say that we can apply one policy if IX > is present and another policy if it is not, but this will > introduce additional complexity with operational dependencies on IX > configuration. > > > > > Yunan: So let me try to clear things up here. Do you mean there are > possibly two cases: 1. IXP ASN is placed in the path 2. IXP ASN is not > placed in the path? For case 2, the handling is supposed to be the same a= s > processing prefixes from peers, right? For case 1, what is the possible > handing procedure? Removing the IXP ASN first and then treat like prefixe= s > from peers? > > > > > > -- > > Best regards, > > Alexander Azimov > --=20 Best regards, Alexander Azimov --000000000000d86b3c05a757e611 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yanun, sorry for the late response.

You= r suggestion to ignore=C2=A0the first ASN in the path if the prefix is rece= ived from IXP with its ASN in the path sounds reasonable for me.=C2=A0
It will improve the quality of ingress filtering=C2=A0by IXP members.= I will add it to the todo list for the next version.

=D1=81=D1=80= , 20 =D0=BC=D0=B0=D1=8F 2020 =D0=B3. =D0=B2 10:53, Guyunan <guyunan@huawei.com>:

Alex,

=C2=A0

Please see inline.

=C2=A0

From: Alexander Azimov [mailto:a.e.azimov@gmail.com]
Sent: Friday, May 15, 2020 10:33 PM
To: Guyunan <guyunan@huawei.com>
Cc: Jay Borkenhagen <jayb@braeburn.org>; SIDR Operations WG <sidrops@ietf.org>
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verificat= ion-04

=C2=A0

Jay, Yunan,

=C2=A0

Thank you for the=C2=A0suggestion. The mutual transi= t=C2=A0sounds good to me too.

=C2=A0

Yunan: All right, so let=E2=80=99s assume in= one case, the IXP does not prepend its own ASN, meaning the RS and one of = its RS clients receives the same AS_Path, right? According to Section 5.1 (see below) and Section 5.2 (see below), I=E2=80= =99m wondering why the detection rules are different for this RS (obeying S= ection 5.1) and this RS client (obeying Section 5.2) regarding the same AS_= Path.=C2=A0

I think I got your point. You are asking why can'= ;t we process prefixes from RS likewise prefixes from peers,=C2=A0right?=

=C2=A0

Yunan: Right.

=C2=A0

The reason is that I've tried to describe the po= licy that will be applicable in general, so it covers the worst-case scenar= io when IX places it ASN in the path. It possible to say that we can apply = one policy if IX is present and another=C2=A0policy if it is not, but this will introduce=C2=A0additional complexity with oper= ational dependencies on IX configuration.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0

Yunan: So let me try to clear things up here= . Do you mean there are possibly two cases: 1. IXP ASN is placed in the pat= h 2. IXP ASN is not placed in the path? For case 2, the handling is supposed to be the same as processing prefixes= from peers, right? For case 1, what is the possible handing procedure? Rem= oving the IXP ASN first and then treat like prefixes from peers?<= /u>

=C2=A0

=C2=A0

--

Best regards,

Alexander Azimov



--
Best regards,
Alexander Azi= mov
--000000000000d86b3c05a757e611-- From nobody Fri Jun 5 09:43: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 A23903A090D for ; Fri, 5 Jun 2020 09:43:37 -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=[BAYES_20=-0.001, 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 JC0kGyTYat-3 for ; Fri, 5 Jun 2020 09:43:36 -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 7552F3A0929 for ; Fri, 5 Jun 2020 09:43:36 -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 1jhFRN-0006r8-RT; Fri, 05 Jun 2020 16:43:34 +0000 Date: Fri, 05 Jun 2020 09:43:33 -0700 Message-ID: From: Randy Bush To: Alexander Azimov Cc: SIDR Operations WG In-Reply-To: References: <24249.23930.126312.2484@oz.mt.att.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] question on draft-ietf-sidrops-aspa-verification-04 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, 05 Jun 2020 16:43:44 -0000 are there really still layer three ixen which put their as in the path? i thought that we finally stomped that out 15-20 years ago. randy From nobody Fri Jun 5 09:55: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 A5FBF3A08FC for ; Fri, 5 Jun 2020 09:55:21 -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 1ZzhvwbDuIMf for ; Fri, 5 Jun 2020 09:55:20 -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 EAEC23A08ED for ; Fri, 5 Jun 2020 09:55:19 -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 055GtFlC049879 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2020 17:55:16 +0100 (IST) (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: Alexander Azimov , SIDR Operations WG References: <24249.23930.126312.2484@oz.mt.att.com> From: Nick Hilliard Message-ID: <62d49f7b-d709-78c3-9eaf-1770a0d59495@foobar.org> Date: Fri, 5 Jun 2020 17:55:14 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.17 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04 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, 05 Jun 2020 16:55:22 -0000 Randy Bush wrote on 05/06/2020 17:43: > are there really still layer three ixen which put their as in the path? > i thought that we finally stomped that out 15-20 years ago. I've heard there's a handful of organisations still doing this, but it's a rarity and is dying out. It would not be productive to build this assumption into any new policy protocol development. Nick From nobody Fri Jun 5 10:07:52 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 BA8E23A0879 for ; Fri, 5 Jun 2020 10:07:50 -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, MIME_QP_LONG_LINE=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 5B_B21K8vcFU for ; Fri, 5 Jun 2020 10:07:47 -0700 (PDT) Received: from de-cix.net (relay3.de-cix.net [46.31.121.23]) (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 78B913A0878 for ; Fri, 5 Jun 2020 10:07:46 -0700 (PDT) IronPort-SDR: rLuum/Xlua1ewnvNNq7R08+Zxw26ZzjguY/65HzJcVZQmR3LkmkEUNFGyhQfoU+xkD3kHyiaRM 415mKq0ipXW+BWYL1CAbQerqULNZrZ2uQ4h4qhUUGE3fiOg9BB2EXCTKdF2m2ATveLSgWjCk7P QvVIoGeREHIuVi9EeUW1iRGW9eBtSSsXzMv5rz92fwyyaMGpUV2CUbowEtVArisr/mrUmnFxdj WTmfqp4J+TB+Do6m2dn6HJfk124gytqLwtVqafen2aYQlzMyn/jo3LwsG9/WZdqBV7M2n/Vomc bo8= X-IronPort-AV: E=Sophos;i="5.73,477,1583190000"; d="p7s'?scan'208";a="25079504" Received: from unknown (HELO smtp02.de-cix.net) ([192.168.65.11]) by mailgw013.de-cix.net with ESMTP; 05 Jun 2020 19:07:45 +0200 Received: from EX03.for-the-inter.net (ex03.for-the-inter.net [192.168.49.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp02.de-cix.net (Postfix) with ESMTPS id B884576; Fri, 5 Jun 2020 19:07:44 +0200 (CEST) Received: from EX02.for-the-inter.net (192.168.49.20) by EX03.for-the-inter.net (192.168.49.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 5 Jun 2020 19:07:44 +0200 Received: from EX02.for-the-inter.net ([fe80::1cb2:801e:f870:7df9]) by EX02.for-the-inter.net ([fe80::1cb2:801e:f870:7df9%4]) with mapi id 15.01.1913.010; Fri, 5 Jun 2020 19:07:44 +0200 From: Thomas King To: Nick Hilliard , Randy Bush CC: SIDR Operations WG , Alexander Azimov Thread-Topic: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04 Thread-Index: AQHWJzMspK1DECvmgkusy65qsSryTqiizLAAgAEcogCABTIogIAHbCuAgBmkE4CAABVAgIAAA0QAgAAlBIA= Date: Fri, 5 Jun 2020 17:07:44 +0000 Message-ID: <48E73C17-BB15-442A-B003-FDDE22E094F5@de-cix.net> References: <24249.23930.126312.2484@oz.mt.att.com> <62d49f7b-d709-78c3-9eaf-1770a0d59495@foobar.org> In-Reply-To: <62d49f7b-d709-78c3-9eaf-1770a0d59495@foobar.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.140.8] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3674228864_1156395410" MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04 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, 05 Jun 2020 17:07:51 -0000 --B_3674228864_1156395410 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable +1 I can't name a single IXP doing it, however, rumor has it that it still exi= sts. Probably some research on this topic would make sense to collect some f= acts? Best regards, Thomas =EF=BB=BFOn 05.06.20, 18:55, "Sidrops on behalf of Nick Hilliard" wrote: Randy Bush wrote on 05/06/2020 17:43: > are there really still layer three ixen which put their as in the pat= h? > i thought that we finally stomped that out 15-20 years ago. I've heard there's a handful of organisations still doing this, but it'= s=20 a rarity and is dying out. It would not be productive to build this=20 assumption into any new policy protocol development. Nick _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://www.ietf.org/mailman/listinfo/sidrops --B_3674228864_1156395410 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVAAYJKoZIhvcNAQcCoIIU8TCCFO0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghLAMIIGOTCCBSGgAwIBAgIUPzk7aHffZ/TcR4Cc7uXHjbt1nygwDQYJKoZIhvcNAQEL BQAwVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dp c3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDgxMzE0NTY0NloX DTI0MDgxMzE0NTY0NlowfDELMAkGA1UEBhMCREUxDzANBgNVBAgTBkhlc3NlbjEfMB0GA1UE ChMWREUtQ0lYIE1hbmFnZW1lbnQgR21iSDElMCMGCSqGSIb3DQEJARYWdGhvbWFzLmtpbmdA ZGUtY2l4Lm5ldDEUMBIGA1UEAxMLVGhvbWFzIEtpbmcwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDPXXDfbJ03MpxfmeYDUq9hHOUCZecLTMyI7vTCMchNwqJFgIpF32GAKRP3 NsLXuCRDJ8h5mep+EZCDt9uNe+BRiiED/jKVdrrNQVsfVVSGzDzvFJ2ab72w7hHZny7EHDDs m5y3YK8aw08GFZfIZtLf53DCdYIZjdhiZelJoE914N4n+dXqRFpKSZpAulllb2s7JdAW8H2P vUTedVb6FkHFPJRK4FmX92l2cn3EGssh0bsQv0mE1PEOnyqp9Zojq/lHKR9q52llRBNQqMIw Xvd7/ALZBx6NK0Zo4E5apG8dLBVfc6o6clyPjYaTPVeBuAaqMyJ2jaMykrxTjrQFuuAlAgMB AAGjggLXMIIC0zAhBgNVHREEGjAYgRZ0aG9tYXMua2luZ0BkZS1jaXgubmV0MA4GA1UdDwEB /wQEAwIEsDATBgNVHSUEDDAKBggrBgEFBQcDBDAdBgNVHQ4EFgQUDLJtg6dE03w8nTLwlRkS kwpUai0wHwYDVR0jBBgwFoAU8MejMpG168q1WHcVp06+Gl1hQyUwgf8GA1UdHwSB9zCB9DBH oEWgQ4ZBaHR0cDovL2NybC5zd2lzc3NpZ24ubmV0L0YwQzdBMzMyOTFCNUVCQ0FCNTU4Nzcx NUE3NEVCRTFBNUQ2MTQzMjUwgaiggaWggaKGgZ9sZGFwOi8vZGlyZWN0b3J5LnN3aXNzc2ln bi5uZXQvQ049RjBDN0EzMzI5MUI1RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNSUyQ089 U3dpc3NTaWduJTJDQz1DSD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0 Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwawYDVR0gBGQwYjBWBglghXQBWQEDAQswSTBH BggrBgEFBQcCARY7aHR0cDovL3JlcG9zaXRvcnkuc3dpc3NzaWduLmNvbS9Td2lzc1NpZ24t U2lsdmVyLUNQLUNQUy5wZGYwCAYGBACPegEDMIHZBggrBgEFBQcBAQSBzDCByTBkBggrBgEF BQcwAoZYaHR0cDovL3N3aXNzc2lnbi5uZXQvY2dpLWJpbi9hdXRob3JpdHkvZG93bmxvYWQv RjBDN0EzMzI5MUI1RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTBhBggrBgEFBQcwAYZV aHR0cDovL3NpbHZlci1wZXJzb25hbC1nMi5vY3NwLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5 MUI1RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTANBgkqhkiG9w0BAQsFAAOCAQEAeUZ9 vKHLtBNsBHNhP+y6z9z/+4R5fShxSaM5BOkLCMOi0HIyb90fP6XzgS89IApahLaO7fSxW2Tt XJlRVXNuseDny4PvW7jQoYcYhniRLekQ4ORrE26oJtxaBnCFj3qLiMQX8BcPMbOaCRL4G4Hf QzRObvNarVrMkNpP54RFXVir+16Zekl8WqO1DwbRuc2tBUFBZpgAco20bnX2M6YPVADwIxqG SZkT7gcoNdq5ETCfPhGk16lAW08gPqq534iwalr2SPXIQwbJ7rw+Pdg05uLIcPfNQbUTLbTh 8CkX/UHYl2XAZaIE4Qfpa04X1rv7Y7TcNhg8omOyPUBFWDelXTCCBr4wggSmoAMCAQICDwVE 1k6tHtM21TJAXQC5NjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMM U3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMTQw OTE5MjAzNjQ5WhcNMjkwOTE1MjAzNjQ5WjBWMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dp c3NTaWduIEFHMTAwLgYDVQQDEydTd2lzc1NpZ24gUGVyc29uYWwgU2lsdmVyIENBIDIwMTQg LSBHMjIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDLObE5hf76yaG8w4OpDkot hHIe/2jFp8Qd7A/XqIsTHrPRFotA3A9TbwE97OhktZfbg7yoqMCEOFheAxQr5sow7wCy6xM5 GZJHKiEA5XLNwjFiDsxWKv93xGOMmMJveNe1tszpfR8zppEFKv7RUtb07Jz+TUxqUuGFdmK7 uWjmUmP8wSGRkl0Z2NyA0RnjSRZXAg4ZRIWrKckv+sZtawqh9vf/a2E1FSaUlAJpJV1p971e a4LZkAwG+UMFIknrNtAgWmMQ4zgh1X8WK0GKRnryZ+ik0LoefyQndZiUSS1WxFQzkZ1i+dVf 3lupFZiclFPBgOkJFxW0G4ApMqHQrxOnAgMBAAGjggKWMIICkjAOBgNVHQ8BAf8EBAMCAQYw EgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU8MejMpG168q1WHcVp06+Gl1hQyUwHwYD VR0jBBgwFoAUF6DNweRBtjpbO8tFnb0cwpj6hlgwgf8GA1UdHwSB9zCB9DBHoEWgQ4ZBaHR0 cDovL2NybC5zd2lzc3NpZ24ubmV0LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0My OThGQTg2NTgwgaiggaWggaKGgZ9sZGFwOi8vZGlyZWN0b3J5LnN3aXNzc2lnbi5uZXQvQ049 MTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1OCUyQ089U3dpc3NTaWdu JTJDQz1DSD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JM RGlzdHJpYnV0aW9uUG9pbnQwYQYDVR0gBFowWDBWBglghXQBWQEDAQYwSTBHBggrBgEFBQcC ARY7aHR0cDovL3JlcG9zaXRvcnkuc3dpc3NzaWduLmNvbS9Td2lzc1NpZ24tU2lsdmVyLUNQ LUNQUy5wZGYwgcYGCCsGAQUFBwEBBIG5MIG2MGQGCCsGAQUFBzAChlhodHRwOi8vc3dpc3Nz aWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC8xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4ME4GCCsGAQUFBzABhkJodHRwOi8vb2NzcC5zd2lzc3Np Z24ubmV0LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwDQYJKoZI hvcNAQELBQADggIBAMN5p1e3e61RaPVEjEGVKAF8dNY7arxt76fXTTmZHWiNygjZ0HGxGTWT b4LGHEm4Ue5M+WwKb9il+/77MF4A0pSrxBJRuqqKq2rdGdcrSvcWsmtRz3RbKaJz3pf+2E8g IX1pDLBQ5Y1YjIAu5Rcc3WN6qu8F+cNpnuSMcWJcQu468s3gEu+LXOnOUygy7JULGVSiIY36 f1CnT7wZe7JrjCk/dz7KI8dpWkGdfWYxb3pxedqpZTrrf9cQ1QtfVBl8zjclJIRQ0K9ANMJf kuJ6kfMvQkcbnzxC+9lfpbxwRY7voDmQ9aF4bNfAZ1kZ4QDeXPx46E/du6yRLnKL/OpHb0Mo vLu5jpS++lDdUJMbTBi2dv/DRwpZtM1tVdhqtl/JL8GUNj6+rkA1BiDt4AJMLTRFDkOvovTY kBXl0MCbRECuPI+TUbyZaHNpe3VYmbfUBE/f8YJxER17/BMdd2VVY9dScnzdMUeGp5XYrCZx PSPmEjv0f5qWhv4r6qDzJg11xhaMMSDnEUeh56lqsKWygR7cPdCh427V8GamHH3XkohNAAcL cedz53PkVGVp/DeN8R5vcO6nbLNSRWdZ1gVIsSHplyjZ2fS0pqBnIza8YEcOXCh/XZOKMbqN MTYUx3pCnW8gwWwq+BYPatkAlDK7PVWxxcOhDbF5d1Qd4DOCfu7qMIIFvTCCA6WgAwIBAgII TxvUL1S7L0swDQYJKoZIhvcNAQEFBQAwRzELMAkGA1UEBhMCQ0gxFTATBgNVBAoTDFN3aXNz U2lnbiBBRzEhMB8GA1UEAxMYU3dpc3NTaWduIFNpbHZlciBDQSAtIEcyMB4XDTA2MTAyNTA4 MzI0NloXDTM2MTAyNTA4MzI0NlowRzELMAkGA1UEBhMCQ0gxFTATBgNVBAoTDFN3aXNzU2ln biBBRzEhMB8GA1UEAxMYU3dpc3NTaWduIFNpbHZlciBDQSAtIEcyMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEAxPGHf9N4Mfc4yfjDmUO8x/e8N+dOcbpLj6VzHVxumK4DV644 N0MvFz0fyM5oEMF4rhkDKxD6LHmD9ui5aLlV8gREpzn5/ASLHvGiTSf5YXu6t+WiE7brYT7Q bNHm+/pe7R20nqA1W6GSy/BJkv6FCgU+5tkL4k+73JU3/JHpMjUi0R86TieFnbAVlDLaYQ1H TWBCrpJH6INaUFjpiou5XaHc3ZlKHzZnu0jkg7Y360g6rw9njxcH6ATK72oxh9TAtvmUcXtn ZLi2kUpCe2UuMGoM9ZDulebyzYLs2aFK7PayS+VFheZteJMELpyCbTapxDFkH4aDCyr0NQp4 yVXPQbBH6TCfmb5hqAaEuSh6XzjZG6k4sIN/c8HDO0gqgg8hm7jMqDXDhBuDsz6+pJVpATqJ AHgE2cn0mRmrVn5bi4Y5FZGkECwJMoBgs5PAKrYYC51+jUnyEEp/+dVGLxmSo5mnJqy7jDzm DrxHB9xzUfFwZC8I+bRHHTBsROopN4WSaGa8gzj+ezku01DwH/teYLappvonQfGbGHLy9YR0 SslnxFSuSGTfjNFusB3hB48IHpmccelM2KX3RxIfdNFRnobzwqIjQAtz20um53MGjMGg6cFZ rEb65i/4z3GcRm25xBWNOHkDRUjvxF3XCO6HOSKGsg0PWEP3calILv3q1h8CAwEAAaOBrDCB qTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUF6DNweRBtjpb O8tFnb0cwpj6hlgwHwYDVR0jBBgwFoAUF6DNweRBtjpbO8tFnb0cwpj6hlgwRgYDVR0gBD8w PTA7BglghXQBWQEDAQEwLjAsBggrBgEFBQcCARYgaHR0cDovL3JlcG9zaXRvcnkuc3dpc3Nz aWduLmNvbS8wDQYJKoZIhvcNAQEFBQADggIBAHPGgeAn0i0P4JUw4ppBf1AsX19iYamGamkY DHRJ1l2E6kFSGG9YrVBWIGrGvShpWJHckRE1qTodvBqlYJ7YH39FkWnZfrt4csEGDyrOj4Vw YaygzQu4OSlWhDJOhrs9xCrZ1x9y7v5RoSJBsXECYxqCsGKrXlcSH9/L3XWgwF15kIwb4FDm 3jH+mHtwX6WQ2K34ArZv02DdQEsixT2tOnqfGhpHkXkzuoLcMmkDlm4fS/Bx/uNncqCxv1yL 5PqZIseEuRuNI5c/7SXgz2W79WEE790eslpBIlqhn10s6FvJbakMDHiqYMZWjwFaDGi8aRl5 xB9+lwW/xekkUV7U1UtT7dkjWjYDZaPBA61BMPNGG4WQr2W11bHkFlt4dR2Xem1ZqSqPe97D h4kQmUlzeMg9vVE1dCrV8X5pGyq7O70luJpaPXJhkGaH7gzWTdQRdAtq/gsD/KNVV4n+Ssuu WxcFyPKNIzFTONItaj+CuY0IavdeQXRuwxF+B6wpYJE/OMpXEA29MC/HpeZBoNquBYeaoKRl bEwJDIm6uNO5wJOKMPqN5ZprFQFOZ6raYlY+hAhm0sQ2fac+EPyI4NSA5QC9qvNOBqN6avli cuMJT+ubDgEj8Z+7fNzcbBGXJbLytGMU0gYqZ4yD9c7qB9iaah7s5Aq7KkzrCWA5zspi2C5u MYICBDCCAgACAQEwbjBWMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMTAw LgYDVQQDEydTd2lzc1NpZ24gUGVyc29uYWwgU2lsdmVyIENBIDIwMTQgLSBHMjICFD85O2h3 32f03EeAnO7lx427dZ8oMA0GCWCGSAFlAwQCAQUAoGkwLwYJKoZIhvcNAQkEMSIEIFiy5vSm +hKJW4cZ8UKvY0+BsO7m1hh+nEeY5UQWemKNMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTIwMDYwNTE3MDc0NFowDQYJKoZIhvcNAQEBBQAEggEAqVdyNKIR QLPf7vbgYMBMznDaE0yQO0f9s+tgUN64bpcnemu5R9a3fWzPh6wppHE0prFRoWqKSqO80Kcq IIVCdu7XwNTZdVZdNB/ktXR5l3a3vAc6E10B48TQO6It2KmfbGDFalN6JzpmHhA2UzyXowjS 43wExTxxWHS/seoxwcRZP+P0gPy/gWgIgiulPw9lYH9LrM8SaB3KADUq1AExsN/4G8fPDcE1 qrrmdIAoMcpZwV2MVKWEzwfKNADd1ykE6jRhPTAyHVzE4SwaniSbZq2I/p46fwPcZ5zwk+lz ROMeOly21EPeCYbHXQyTqQjhlM4lCNfdUCkh9nR62WQJEA== --B_3674228864_1156395410-- From nobody Fri Jun 5 10:16: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 65D133A093C for ; Fri, 5 Jun 2020 10:16:52 -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 9C33_2WSXO_Y for ; Fri, 5 Jun 2020 10:16:50 -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 AD99B3A096E for ; Fri, 5 Jun 2020 10:16:49 -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 1jhFxW-00072E-5L; Fri, 05 Jun 2020 17:16:46 +0000 Date: Fri, 05 Jun 2020 10:16:45 -0700 Message-ID: From: Randy Bush To: Nick Hilliard Cc: Alexander Azimov , SIDR Operations WG In-Reply-To: <62d49f7b-d709-78c3-9eaf-1770a0d59495@foobar.org> References: <24249.23930.126312.2484@oz.mt.att.com> <62d49f7b-d709-78c3-9eaf-1770a0d59495@foobar.org> 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] question on draft-ietf-sidrops-aspa-verification-04 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, 05 Jun 2020 17:16:52 -0000 >> are there really still layer three ixen which put their as in the >> path? i thought that we finally stomped that out 15-20 years ago. > > I've heard there's a handful of organisations still doing this, but > it's a rarity and is dying out. It would not be productive to build > this assumption into any new policy protocol development. then i suggest we not add complexity in the document for this dead corner case. randy From nobody Sat Jun 6 08:15: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 E9E1B3A0A68 for ; Sat, 6 Jun 2020 08:15:21 -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 mkxrKm1NGtHH for ; Sat, 6 Jun 2020 08:15:19 -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 42ADD3A0542 for ; Sat, 6 Jun 2020 08:15:18 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id v19so11050315wmj.0 for ; Sat, 06 Jun 2020 08:15:18 -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=HeRgb7PvQJH5PhDKUyJupfHk77dinm6CBBkAQLMu1h8=; b=U1E3visn03VMzR2w9uWY1uilhOCIg3aBhwrAEwM8FyMRa8NKLYH+FnBYIOKmH6syRJ WXESyto63tSIcMg/2jDX9cpG3k3kz4KxAo/tn32QiiwWwh1muGpzKuoQrAURbVhx0Hoh sUMUgbkkr2sCty4WO2tFjxVSEvdNzgI7xHhGA9dhBR13HmvxuLUGBlo9PiXykj1FUHG3 0ADRBmG/hf2yvBWkv2TXAzlcXVyDJcesRlfyk2UK/x8qZkdpfRpauWfObACY5QVVNqd0 Hr/tYClDDNhkQMeiT0kJ6AVSAvH+QaZ+aySGQC5KcB0Dn1+OM6btqc5RYthKDH8txClp mMvw== 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=HeRgb7PvQJH5PhDKUyJupfHk77dinm6CBBkAQLMu1h8=; b=Q7WvcmEUst2F2TlYjsRHSbvdiVFRGVWLUTkZL2wIwN934QGTCYtqhi8WfXYNznF36m tn77ZfrANwTGt+NSHllk+wpxX+TcF0hxFCHhRAghU8eyBJpLjUAnFa63UyEyoYpX0QaK 3akaR6jN/Db/2uYwk+mhdH4WqONzaJbXDdY1hyWfVswWActW0NnrEoSbewP5DVyMJD81 ZtLHpMwyJHvP2KhRL83BrotXQ/TMiYUHeohI2Cd3TiVlNSzDX7s7CER2QcgLXP28MQBV hWo91ihl+PIerPiGLzpNHTWPJWomrAbxJF6LvZ1fvYfBVOOYfMqZj7ZJJmvx+kzso6sr kSAA== X-Gm-Message-State: AOAM532HESOng9/h/TvF/4QVXDlXd/kCihtZDxj8oR3o3gmN4TjyLqI0 A+7cjwscNLRJeDhS/beYIkkyxIpCETxLUk7Ruted6w== X-Google-Smtp-Source: ABdhPJx77YK8snJBr25/Zezd268CoronbG5617lhximf/N7cTFsTzAj5+aOZpsLQU8hfQy/FfXI1WafgtLCOERM6NwE= X-Received: by 2002:a7b:ce15:: with SMTP id m21mr7833396wmc.117.1591456513406; Sat, 06 Jun 2020 08:15:13 -0700 (PDT) MIME-Version: 1.0 References: <24249.23930.126312.2484@oz.mt.att.com> <62d49f7b-d709-78c3-9eaf-1770a0d59495@foobar.org> In-Reply-To: From: Melchior Aelmans Date: Sat, 6 Jun 2020 17:15:02 +0200 Message-ID: To: Randy Bush Cc: Nick Hilliard , SIDR Operations WG , Alexander Azimov Content-Type: multipart/alternative; boundary="000000000000284d0405a76bd895" Archived-At: Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04 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, 06 Jun 2020 15:15:22 -0000 --000000000000284d0405a76bd895 Content-Type: text/plain; charset="UTF-8" Hi, On Fri, Jun 5, 2020 at 7:16 PM Randy Bush wrote: > >> are there really still layer three ixen which put their as in the > >> path? i thought that we finally stomped that out 15-20 years ago. > > > > I've heard there's a handful of organisations still doing this, but > > it's a rarity and is dying out. It would not be productive to build > > this assumption into any new policy protocol development. > > then i suggest we not add complexity in the document for this dead > corner case. > I'm not aware of any IXPs doing this so I would support not adding this. Cheers, Melchior --000000000000284d0405a76bd895 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 5, 2020 at 7:16 PM Randy B= ush <randy@psg.com> wrote:
>> are there re= ally still layer three ixen which put their as in the
>> path?=C2=A0 i thought that we finally stomped that out 15-20 years= ago.
>
> I've heard there's a handful of organisations still doing this= , but
> it's a rarity and is dying out.=C2=A0 It would not be productive t= o build
> this assumption into any new policy protocol development.

then i suggest we not add complexity in the document for this dead
corner case.

I'm not aware of any I= XPs doing this so I would support not adding this.

Cheers,
Melchior
--000000000000284d0405a76bd895-- From nobody Sat Jun 6 08:53: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 ABD8B3A0B84 for ; Sat, 6 Jun 2020 08:53:11 -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, 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 yR1O7ZJiMKqA for ; Sat, 6 Jun 2020 08:53:10 -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 8E2073A0B63 for ; Sat, 6 Jun 2020 08:53:10 -0700 (PDT) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 5FF35220134; Sat, 6 Jun 2020 15:53:08 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 50D5627C0054; Sat, 6 Jun 2020 11:53:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 06 Jun 2020 11:53:07 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeghedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdttd dttddtvdenucfhrhhomheplfhosgcuufhnihhjuggvrhhsuceojhhosgesnhhtthdrnhgv theqnecuggftrfgrthhtvghrnhephffhtdehteeiveehkedvuedtffeuieejtdetfeegie ffudfhkefhgeelvddtvdejnecukfhppeduledvrddugeejrdduieekrddutdejnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhhosgdomhgvsh hmthhprghuthhhphgvrhhsohhnrghlihhthidquddtgeejleduheekgedqvdeffeefkeef vddtqdhjohgspeepnhhtthdrnhgvthesshhosghorhhnohhsthdrnhgvth X-ME-Proxy: Received: from bench.sobornost.net (bench.sobornost.net [192.147.168.107]) by mail.messagingengine.com (Postfix) with ESMTPA id 9474D3280059; Sat, 6 Jun 2020 11:53:06 -0400 (EDT) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 73e446a8; Sat, 6 Jun 2020 15:53:05 +0000 (UTC) Date: Sat, 6 Jun 2020 15:53:04 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: <20200606155304.GA17909@bench.sobornost.net> References: <24249.23930.126312.2484@oz.mt.att.com> <62d49f7b-d709-78c3-9eaf-1770a0d59495@foobar.org> 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] question on draft-ietf-sidrops-aspa-verification-04 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, 06 Jun 2020 15:53:12 -0000 On Fri, Jun 05, 2020 at 10:16:45AM -0700, Randy Bush wrote: > >> are there really still layer three ixen which put their as in the > >> path? i thought that we finally stomped that out 15-20 years ago. What exactly was stomped out? > > I've heard there's a handful of organisations still doing this, but > > it's a rarity and is dying out. It would not be productive to build > > this assumption into any new policy protocol development. > > then i suggest we not add complexity in the document for this dead > corner cases. There is a number of them, such as IIX in Isreal. But how does this case exactly differ from any regular Transit ISP? Why would special accomodations need to be made? Kind regards, Job From nobody Sat Jun 6 09:39: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 BA8D73A0EBD for ; Sat, 6 Jun 2020 09:39:27 -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 Cc-IO1o1uwpX for ; Sat, 6 Jun 2020 09:39:26 -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 AB2553A0EBB for ; Sat, 6 Jun 2020 09:39:24 -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 056GdK5o036174 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jun 2020 17:39:21 +0100 (IST) (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: Job Snijders Cc: sidrops@ietf.org References: <24249.23930.126312.2484@oz.mt.att.com> <62d49f7b-d709-78c3-9eaf-1770a0d59495@foobar.org> <20200606155304.GA17909@bench.sobornost.net> From: Nick Hilliard Message-ID: <8ae14898-45d4-c005-5bd8-2dc4ab1822de@foobar.org> Date: Sat, 6 Jun 2020 17:39:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.17 MIME-Version: 1.0 In-Reply-To: <20200606155304.GA17909@bench.sobornost.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04 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, 06 Jun 2020 16:39:28 -0000 Job Snijders wrote on 06/06/2020 16:53: > What exactly was stomped out? route servers not being as-path transparent. > There is a number of them, such as IIX in Isreal. IIX is a router: https://en.isoc.org.il/iix/iix-tech-info i.e. not a traditional IXP: routing policy is controlled by the router operator rather than by the participants. Nick From nobody Sat Jun 6 10:19: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 D1AD13A0ED7 for ; Sat, 6 Jun 2020 10:19:55 -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 qsgRC_vku3ZX for ; Sat, 6 Jun 2020 10:19:54 -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 70F403A09C8 for ; Sat, 6 Jun 2020 10:19:54 -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 1jhcU0-0002Xc-DT; Sat, 06 Jun 2020 17:19:48 +0000 Date: Sat, 06 Jun 2020 10:19:47 -0700 Message-ID: From: Randy Bush To: Nick Hilliard Cc: Job Snijders , sidrops@ietf.org In-Reply-To: <8ae14898-45d4-c005-5bd8-2dc4ab1822de@foobar.org> References: <24249.23930.126312.2484@oz.mt.att.com> <62d49f7b-d709-78c3-9eaf-1770a0d59495@foobar.org> <20200606155304.GA17909@bench.sobornost.net> <8ae14898-45d4-c005-5bd8-2dc4ab1822de@foobar.org> 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] question on draft-ietf-sidrops-aspa-verification-04 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, 06 Jun 2020 17:19:56 -0000 >> What exactly was stomped out? > route servers not being as-path transparent.\ it was worse. for some years, pch/woody was pushing layer three exchanges in africa, using routers not switches. after some 'discussion' the light dawned. > IIX is a router: > https://en.isoc.org.il/iix/iix-tech-info > i.e. not a traditional IXP: routing policy is controlled by the router > operator rather than by the participants. OMG! we found a st00pid corner case. let's change the protocol. :) randy From nobody Fri Jun 12 13:13:43 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 2B9D23A0E46; Fri, 12 Jun 2020 13:13:42 -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: sidrops@ietf.org, warren@kumari.net, sidrops-chairs@ietf.org, keyur@arrcus.com X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159199282166.6982.14797238821982424613@ietfa.amsl.com> Date: Fri, 12 Jun 2020 13:13:42 -0700 Archived-At: Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 108 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, 12 Jun 2020 20:13:42 -0000 A new meeting session request has just been submitted by Keyur Patel, a Chair of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Keyur Patel Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: Conflicts to Avoid: Technology Overlap: rtgwg lsr mpls spring People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 13 12:21: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 01F853A108A for ; Sat, 13 Jun 2020 12:21:20 -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 DTpbw9Xxt2Jq for ; Sat, 13 Jun 2020 12:21:18 -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 A97BB3A1089 for ; Sat, 13 Jun 2020 12:21:18 -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 1jkBiM-0008HI-Ot for sidrops@ietf.org; Sat, 13 Jun 2020 19:21:14 +0000 Date: Sat, 13 Jun 2020 12:21:14 -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] six pages for rov issues 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, 13 Jun 2020 19:21:20 -0000 chris at the ever fantastic six has done a stunning bit of work to let six members see rpki/irr announcement issues https://www.seattleix.net/rs-drops randy From nobody Sat Jun 13 17:34:45 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 5F7EA3A0861 for ; Sat, 13 Jun 2020 17:34:44 -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 bp-qJVoL41qj for ; Sat, 13 Jun 2020 17:34:42 -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 DAA2C3A0860 for ; Sat, 13 Jun 2020 17:34:42 -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 1jkGbh-0000b3-FY for sidrops@ietf.org; Sun, 14 Jun 2020 00:34:41 +0000 Date: Sat, 13 Jun 2020 17:34: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] six pages for rov issues 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, 14 Jun 2020 00:34:44 -0000 > chris at the ever fantastic six has done a stunning bit of work to let > six members see rpki/irr announcement issues > https://www.seattleix.net/rs-drops de-cix also let's one see the data https://lg.de-cix.net/routeservers/rs1_fra_ipv4/protocols/R192_22/routes though differently, of course. i can not find history, but the diagmostic tool-tips are quite nice. randy From nobody Wed Jun 17 01:55: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 ADEE63A07E7 for ; Wed, 17 Jun 2020 01:55:42 -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_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 z_8FSpoZPnjf for ; Wed, 17 Jun 2020 01:55:41 -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 64A793A07D0 for ; Wed, 17 Jun 2020 01:55:40 -0700 (PDT) Received: from grisu.home.partim.org (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 44A6B21957; Wed, 17 Jun 2020 10:55:38 +0200 (CEST) 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: Wed, 17 Jun 2020 10:55:37 +0200 From: Martin Hoffmann To: Stephen Kent Cc: "sidrops@ietf.org" Message-ID: <20200617105537.36e9ee17@grisu.home.partim.org> In-Reply-To: <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net> References: <0365f842-ff05-b252-2fc7-f6f408fc52e3.ref@verizon.net> <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.3 (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] 6486 bis 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, 17 Jun 2020 08:55:43 -0000 Hello! I am curious what the plan forward is with regards to 6486-bis? We are looking into releasing a 1.0 version of Routinator soon-ish and would like to have the revised manifest validation rules included since they most definitely constitute breaking changes. While we don=E2=80=99t necessarily need to wait for the final RFC, it would= be good to at least have a relatively stable I-D to build upon. Kind regards, Martin From nobody Wed Jun 17 02:13: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 BF1F13A0826 for ; Wed, 17 Jun 2020 02:13:29 -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 QFAFpYwegO9x for ; Wed, 17 Jun 2020 02:13:28 -0700 (PDT) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::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 610603A0825 for ; Wed, 17 Jun 2020 02:13:28 -0700 (PDT) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id 95A49EE00FD for ; Wed, 17 Jun 2020 09:13:27 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 116EB27C0054 for ; Wed, 17 Jun 2020 05:13:26 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Wed, 17 Jun 2020 05:13:26 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejvddgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdflohgsucfunhhijhguvghrshdfuceojhhosgesnhht thdrnhgvtheqnecuggftrfgrthhtvghrnhepjeffieejtdehheefgfdtvedttddvleeuve euteevteduvdeggfekvdeltdejhfeinecuffhomhgrihhnpehivghtfhdrohhrghenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohgsodhmvg hsmhhtphgruhhthhhpvghrshhonhgrlhhithihqddutdegjeeludehkeegqddvfeeffeek fedvtddqjhhosgeppehnthhtrdhnvghtsehsohgsohhrnhhoshhtrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A342DC200A5; Wed, 17 Jun 2020 05:13:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-529-g3ee424a-fm-20200611.001-g3ee424a1 Mime-Version: 1.0 Message-Id: <94d312c7-befd-4326-9096-e99abcfcd534@www.fastmail.com> In-Reply-To: <20200617105537.36e9ee17@grisu.home.partim.org> References: <0365f842-ff05-b252-2fc7-f6f408fc52e3.ref@verizon.net> <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net> <20200617105537.36e9ee17@grisu.home.partim.org> Date: Wed, 17 Jun 2020 09:13:04 +0000 From: "Job Snijders" To: sidrops@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] 6486 bis 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, 17 Jun 2020 09:13:30 -0000 Dear Martin, others, To me the text that Stephen Kent shared with the group on May 8th is pro= bably the 'relatively stable I-D', the text is here https://mailarchive.= ietf.org/arch/msg/sidrops/04s5QYa_BdVNrfC6TH4Axr7izqs/ Someone needs to convert it to XML, it is not clear who the volunteer is= . I can try to work on it, but if someone else is already on it that wou= ld be good to know.=20 I started some XML in a similar direction https://tools.ietf.org/html/dr= aft-spaghetti-sidrops-rpki-manifest-validation-00 but it seems that didn= 't receive support to progress. Kind regards, Job On Wed, Jun 17, 2020, at 08:55, Martin Hoffmann wrote: > Hello! >=20 > I am curious what the plan forward is with regards to 6486-bis? We are= > looking into releasing a 1.0 version of Routinator soon-ish and would > like to have the revised manifest validation rules included since > they most definitely constitute breaking changes. >=20 > While we don=E2=80=99t necessarily need to wait for the final RFC, it = would be > good to at least have a relatively stable I-D to build upon. >=20 > Kind regards, > Martin >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > From nobody Wed Jun 17 04:44: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 CDE3F3A09D8 for ; Wed, 17 Jun 2020 04:44:49 -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 qzPgLaiiSrQM for ; Wed, 17 Jun 2020 04:44:48 -0700 (PDT) Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id F3C9F3A09D9 for ; Wed, 17 Jun 2020 04:44:44 -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 65D5E48611 for ; Wed, 17 Jun 2020 11:44:44 +0000 (UTC) Received: by oz.mt.att.com (Postfix, from userid 1000) id 58F615640E67; Wed, 17 Jun 2020 07:44:44 -0400 (EDT) X-Mailer: emacs 25.2.2 (via feedmail 11-beta-1 I); VM 8.2.0b under 25.2.2 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24298.552.280109.125463@oz.mt.att.com> Date: Wed, 17 Jun 2020 07:44:40 -0400 From: Jay Borkenhagen To: Martin Hoffmann Cc: In-Reply-To: <20200617105537.36e9ee17@grisu.home.partim.org> References: <0365f842-ff05-b252-2fc7-f6f408fc52e3.ref@verizon.net> <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net> <20200617105537.36e9ee17@grisu.home.partim.org> Reply-To: Jay Borkenhagen X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Archived-At: Subject: Re: [Sidrops] 6486 bis 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, 17 Jun 2020 11:44:50 -0000 Martin Hoffmann writes: > > I am curious what the plan forward is with regards to 6486-bis? Hi Martin, In addition to Job's comments, don't forget about the upcoming SIDROPS Interim meeting, merely one week from today, which was specifically called to discuss "some of the pending changes to RFC6486 which were discussed at the last event." https://mailarchive.ietf.org/arch/msg/sidrops/z9JmkXqDuvd31fLTtVzkQDT1-WI/ Hope to see you there! Jay B. From nobody Wed Jun 17 06:14: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 2426F3A0809 for ; Wed, 17 Jun 2020 06:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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=-0.001, 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 hLe8dfK1cSVn for ; Wed, 17 Jun 2020 06:14:19 -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 39FE63A07F4 for ; Wed, 17 Jun 2020 06:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1592399657; bh=UpnHagUU+E+p+ELThHtWofe8rTiFj9A72GXVcsFCuHs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=miNUQlw9iJ7bpHpvEmcE9/ZeFht8fFKeXepV+5iglx9EbsoJOHN+NsBFg1lWMLIUcbTd4K9E/9DN3ZVB06aG8SIGMKBfIZx+mwvX2WyqU9S0TW74ugiEjvbM22beh3wGrmzRKSq96mwuX9C3mEaR6fXNaYIRNatkNZ6f//6dkA6MP0Q6zrwnNol/A/n80wIg+Bf3bWTUjgreLZAex4OSuFLrhBrUR1xKekeQSav2w8lXhj42hcbMvfZF8qL8IuM3hKJdfEtFIMMu7jyGKdF+1Un52j/LqTN+kAKZ+GMOT9Dv9gnk6vqnTUd0nwdumyIBH6vSEvdvjVDcasnEHp/j4Q== X-YMail-OSG: Vxl3wl0VM1ki7rZMX5urbsK51cvGIyIN.aXpLB_xVbtHvjqtfaL4KQSs0g.n_cZ q6Pim9.VaJcqYUIi2PKaV67DC92_1VE2vQgQotd3jtimj_aT57c1sxn6TR4MBa28Q26tzAUq1afw aPCjkecncW27NWVRJA5_P3H2MN9GcxhVkkx51dSeuC_WbN7FtL669X0erpKhYUft9IdbpH6fAql3 vvkhUA5dhnBmKTF27zlT3Z8ieE.wtN6NYIEIg2e0pMdzZn0XUjhMXo6mUsxD9cWUC5bzkhKZNXEG 9auGGvyeCGMRtxDdDUNHS4Y1tnS3kA08NkBHgHW0Wm9rPYyI8lPlU_u22n0SxGFdAw9JVyGTmcQH DznNQCscZuOt99gYY5C5fJ7_197XT5_2XB4zRYtPVd5LBRFjdTV1cALahFS.7As5UpDO1jCPSIQI D.vjfJldDyuVNYn..ueRcBA9edxK42wLBli8SeYljpywhU4slKXIVevzYYXps3eno7Il7VVQBA0n JWDeYydOapqNeh.vwOr3RGXhGcy8aNl7S4ERA8jpTvw_fNdgRXFCrl0dZssspGWE7ZvFtCmB2i9e D9yqGcBSLG1mAPzPSPNNmDEV7CgBHF_dVIQBa4ltl3R9J9p2ZS63Sx9VzSSwuFnqnyGh1EJmv9WS _60GuwAFh.6r6PmSOeLV2gcDTxLeygGovTCxY1t8rUWqJCnuylqG1fyWLMGVmBaKVt3f_jR.pcbx cm81iPn0NDTmYD1uvmQHsmdD0cul90tjpR_9sNl9m3Mf7ddFjXvvgi6vmg9mNI10hcSVdj67aTgC 0wz3gz4Gy1zYs4rtYpvDP3pHesWx9VjVZ1QMlEB5Exex2A9qkVogoFUk8yLVctc9hRo2q3klCBK4 XeE1EAIIPC1CHFczUKwuF47SmPwW.dJv27aWDP0Ft3r1ofnNAWU_VSo_UgOzW.Wc4pjQ_zozCFnc W_GwHoew0O1IkCg5HpNXj0X4DXjOLY18.puZV57tjX_te0eC8sR5hlHxKxsGzOHjF6F39w1QnIQ. rI9JBbALWA12DQJ2lVbHmio.0zwGG6Y5eSTwNYnPxxCvaLf5V1SEkiHxr9MiEot3BQlBRQU07T2H fhR2JMyBULVURsU3iZTK6kGCg2daDnN17GUYpMYsK988NQaAFNoICW9kgU.O9LoXgAGORqzaMibB QNEzNOAw1wNjXn9bwfRlgfsAoeFIpHyCjf8oEUfzI2.w_ThBWczqSL0uL66hE.S7vNAUYSLo0ZPG uG8UEjSMiKUH0OPW0im1vn6D1yPDTneToFZpqb9RVLgZ3Ff8DpprEsru8JpLOdmivklC2AjOWeP7 Wo45b_LgK5uRKgqTnT2MKhGMdQPKQPCt_JnNcbK1v0FMTbmyfu1kPVHdqJ7guFMNE6AQRpOXTwTg puBDz9E0u1tFhy.4t6LBa.7ti988- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Wed, 17 Jun 2020 13:14:17 +0000 Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5cfe4de8573720e16f7063c22e2c0613; Wed, 17 Jun 2020 13:14:14 +0000 (UTC) To: Martin Hoffmann Cc: "sidrops@ietf.org" References: <0365f842-ff05-b252-2fc7-f6f408fc52e3.ref@verizon.net> <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net> <20200617105537.36e9ee17@grisu.home.partim.org> From: Stephen Kent Message-ID: Date: Wed, 17 Jun 2020 09:14:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200617105537.36e9ee17@grisu.home.partim.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.16119 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: Re: [Sidrops] 6486 bis 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, 17 Jun 2020 13:14:25 -0000 Martin, I assume the interim meeting scheduled for next week is intended to resolve any outstanding issues. I plan to revise the most recent version of the text I posted based on that meeting. Steve > Hello! > > I am curious what the plan forward is with regards to 6486-bis? We are > looking into releasing a 1.0 version of Routinator soon-ish and would > like to have the revised manifest validation rules included since > they most definitely constitute breaking changes. > > While we don???t necessarily need to wait for the final RFC, it would be > good to at least have a relatively stable I-D to build upon. > > Kind regards, > Martin From nobody Wed Jun 17 06:15: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 13BC13A07DE for ; Wed, 17 Jun 2020 06:15: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, RCVD_IN_MSPIKE_H2=-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=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 Y8MEkUdcb9QR for ; Wed, 17 Jun 2020 06:15:21 -0700 (PDT) Received: from sonic311-13.consmr.mail.bf2.yahoo.com (sonic311-13.consmr.mail.bf2.yahoo.com [74.6.131.123]) (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 C338A3A053F for ; Wed, 17 Jun 2020 06:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1592399719; bh=QZ9qkRSaO0UoWxpLs7rhdxEddOacLL7sGVq3dxYgGVA=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=q7LoFP0XQLN+p2Y+VQeAObosjqZVEz8KpnRnj9m8DTcu/O/0m0hcrzIisZxBYkobLl470kQsLTAztGyYJSOnK4MPjGhJZ6C1fP9E0d6vUGeYRtMJQr62mRhA7JVKJIBKJ/qx359mrWgVdu6xSmVnKmSgAAvZpIUEoEyg6Hy082uNmPLIZzqYXvyKQW+f0Ahjy9Xb2v02EgYlw0GZaxNcEdu9o4j7xEKgZFzOQs6qoqoA2g70/hWT5adR8r1dmgvuAoNebt3fPwyMDnY48yll+JuhKgDr8YONft5Vn+itFzB3Jic0Q283gXX1nq98ohcX3MJxL1szv/xV72eRo7MNOg== X-YMail-OSG: LPVEwj4VM1mizIGxqVsd3vXT_BMByWflGQM1IFL0Sv3kwh9Pe5eJphnndn.fMfe eHL3WEoWcRa_.dcUVryNsQNxtfA_3YGYMUEgeUpiPUQ4rfmnRfZWs5whveXKGzfv7zv6ypKaKieO Kq_klvhEECtuZ93xrqsInIOMhPH5zCsDwdZcesH1BTULW9VDdT1yY8jlWT6a0MUJznvH2yfBG1NP a9u0yGV7Zd9e1WSQjAoJUZbx5LGNMItcWtt3jJ_bXQ4tmL7_st3yX.WioxLy3kRljmgjbN9J9CiZ YR8nZk7vVQrKnhJ5Tnr45oqqwzXem54sPMpjyz9Fq_i7MQzUdXouDpXGqj8PUq4wiz2pnToiG0Vn g46e9UcJP_o7x5CfFkSe79CtAwa4TtN9lNYO4kb729byIxfQtaSESjzLAcheOkQD38CY_O7owfin ludz5kyixh7ufHQw9NJGugOukfu9D83S8GDgbCD_pKUs.iVxiLA3bL8srG8kGLlLocmtyc37Foi. BFdiyIJrBEOuVdVUoCRZ29.unimRXu3PSklcgsb7GAh1af7ARpKXgs4rcXr226gXp0hkFHEMxuPg be0BAT89.TN5t3Qpi3VfXydk4cV8tkp6EE3USUkjlFjPl0Yi8TB2vD2wasGzM3N8494yt2_yl5Yc 27W5SpdA7.lYy4cO1m2P8YL6FILGqLuxDHjhSyx0M38ehT3BJLvM.AGi.X9lzLJRmsejR_C6zbic mwBU8JQG60w.Pr4mRVQzNeXn1mnpbkGqdPGmIpI1FAKWe9AabfGFMDbRIPrtqEaia1brWJwryBvw Ipk2kx4bYVPN2EUHcObxG1TYCMKObqCNRZ_XYns_X4_r9_Q1cvj.aModsW4Tw3mav0gSXQC6DadH 0i7CWT1YsKKFsRsfJzjAfpGLDmLt6e1xnl7XmkIRZ_LFugr_4jhL8xEvtdJLc4oXO2MHC4R04N3E vGcFfCwxpKrmhtg1zRB0ioYy33JptPV01ZpEIzNIKuhUUYSYeJ83HyHJXs1lUcYcGMxHVUKJPcCz ZGMPwuSYOMibica_OzJqvSoI3XqL3DAN7DwucJt8Yl6z.FkVDl39uw..xH1PpX1FGNVKJG9k3yim uwr8J3U9lmZSqWT5MYIU075PUc7sGRS.f7s1nBfDivlrVSOljOCa9YL.VrkOyIpkdRvZxLJhyN1v o243sNdLQnxhng2zNNd7nL79zfLYht59dFS3zSrLK0yInbfSmHZv.tdqWT9yy5sKS3YyjDszy45s nU08cMhvyZSNNsItP3nZXBCw_ybhV6eENSxvtj1gEgBQpB.kk.xDtPnWzmOeX0irUesrAs4vQROJ RrpJLtjXxyr9EIbC8lGtBUM_EzPLv.U6Le6KxdG.WSJVpsZG7wZsTf53BFFAPw8uk2fedCwJ14XT wyJBxxlW9wzoYdv6rbwaeleGgcLW1KObv4Fc9.KS8coOkpF6uydtZui.pZc6BxTgJJZgZvTYCsbH njcTGDssLzH6jjrUyPM_HtXFw Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Wed, 17 Jun 2020 13:15:19 +0000 Received: by smtp406.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3ff08bd254c314acc556e21463168191; Wed, 17 Jun 2020 13:15:16 +0000 (UTC) To: sidrops@ietf.org References: <0365f842-ff05-b252-2fc7-f6f408fc52e3.ref@verizon.net> <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net> <20200617105537.36e9ee17@grisu.home.partim.org> <94d312c7-befd-4326-9096-e99abcfcd534@www.fastmail.com> From: Stephen Kent Message-ID: Date: Wed, 17 Jun 2020 09:15:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <94d312c7-befd-4326-9096-e99abcfcd534@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.16119 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: Re: [Sidrops] 6486 bis 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, 17 Jun 2020 13:15:22 -0000 Job, > Dear Martin, others, > > To me the text that Stephen Kent shared with the group on May 8th is probably the 'relatively stable I-D', the text is here https://mailarchive.ietf.org/arch/msg/sidrops/04s5QYa_BdVNrfC6TH4Axr7izqs/ > > Someone needs to convert it to XML, it is not clear who the volunteer is. I can try to work on it, but if someone else is already on it that would be good to know. > > I started some XML in a similar direction https://tools.ietf.org/html/draft-spaghetti-sidrops-rpki-manifest-validation-00 but it seems that didn't receive support to progress. > > Kind regards, > > Job I believe Randy has been generating an XML version of 6486-bis, but is waiting for the outcome of next week's interim meeting before proceeding. Steve From nobody Wed Jun 17 06:27: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 797413A07A5 for ; Wed, 17 Jun 2020 06:27:21 -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 zyd-51_5Vwz4 for ; Wed, 17 Jun 2020 06:27:20 -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 68A0D3A0797 for ; Wed, 17 Jun 2020 06:27:20 -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 88A6CEE00FD for ; Wed, 17 Jun 2020 13:27:19 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 1A34427C0054 for ; Wed, 17 Jun 2020 09:27:19 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Wed, 17 Jun 2020 09:27:19 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejvddgieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedflfhosgcuufhnihhjuggvrhhsfdcuoehjohgssehnthht rdhnvghtqeenucggtffrrghtthgvrhhnpeevffehleejleevlefghfeiveekieetkefhte ejveefhfduuefhgfffffdtteevjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehjohgsodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhith ihqddutdegjeeludehkeegqddvfeeffeekfedvtddqjhhosgeppehnthhtrdhnvghtsehs ohgsohhrnhhoshhtrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BA6D0C200A5; Wed, 17 Jun 2020 09:27:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-529-g3ee424a-fm-20200611.001-g3ee424a1 Mime-Version: 1.0 Message-Id: <846ddc4f-0dc7-48e0-9478-a4ff960d20b1@www.fastmail.com> In-Reply-To: References: <0365f842-ff05-b252-2fc7-f6f408fc52e3.ref@verizon.net> <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net> <20200617105537.36e9ee17@grisu.home.partim.org> <94d312c7-befd-4326-9096-e99abcfcd534@www.fastmail.com> Date: Wed, 17 Jun 2020 13:26:56 +0000 From: "Job Snijders" To: sidrops@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Sidrops] 6486 bis 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, 17 Jun 2020 13:27:33 -0000 On Wed, Jun 17, 2020, at 13:15, Stephen Kent wrote: > I believe Randy has been generating an XML version of 6486-bis, but is > waiting for the outcome of next week's interim meeting before proceeding. awesome, good to hear. Kind regards, Job From nobody Thu Jun 18 09:35: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 338103A095C for ; Thu, 18 Jun 2020 09:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 tKqhgKorxaNk for ; Thu, 18 Jun 2020 09:35:17 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 EAC033A093B for ; Thu, 18 Jun 2020 09:35:16 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id g11so3062421qvs.2 for ; Thu, 18 Jun 2020 09:35:16 -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=m1betLOOgJVa9h4TOSn9gTAWheAKL1Y1sI2tdvB94x8=; b=Mp94HTdXv3O/48FACMdDweklodHyiLoKzBx8MExhCXlZJqzLXYmuF3d+zhf2ajP4Ed lnszI+3/fAp7P1c7w/KRO5dRdme6s0R2FL+CqXZ9vhr4YvXE8eHplB0FbgPKyRZYu7/w Nf64MKqaDvfanJTxqIDB+Vfg7lq8kmQLwpSlTAgxm26GgIywaTOLy/ZF61vJLJXMQtsy ji4NeMjK3kAcuPTWuJhT/88BmI8iG00zYblS6jzBz5ThcWJqEvRItFCS+xpS8S2eXWji fnEVA17EEA0NBb8r7y0d31gw3dI4QZA6pC4Lm4lAXtgwIFx6stWjB/WidgzT9cDoFE8H staA== 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=m1betLOOgJVa9h4TOSn9gTAWheAKL1Y1sI2tdvB94x8=; b=lKUaPlfX4tFEmdpMc/1uo3Af3ec9VNdismzsmpdO9heluAeQv9d+QTtj3Z+Dp9QBNo TtTiMeeOId18ZoQ1Ly7Iybqs/kyR+WQaN6t/oBr50VmQUCwoYaefIfMzpFGpciau8qwW ug6F9hB51ijatQ0xpu4Ip5uYcLGHz8eMcZttvTpdPDTkph35/X58d+wuxxtQE7wHggbl 4ldCiujUQ+vJXYrla8TZhGurdoeE+MxRVEzfP651tH8MfenuCpJVN40m2TcL3Qr5EXH+ B0BaEzdMT+Ua3Ob4p5zgVX9qYETzMUk+ca+wQ10X5KxUG+rI23phHjbtRyd0AyafYP2w uO8g== X-Gm-Message-State: AOAM530AbzPN7PdaJUlOqah8MFGkdJX+rACubhM9DIbjZeXsvG+IVpdx bdLXSBKVKq6pR4X4oIlFEpWbGrmyzBI6ZPmlLsBuwg== X-Google-Smtp-Source: ABdhPJwvmq03E3lQK4knKzo2Z0rvM6tVOxIAUOtoe67HmPexbUCjHmxGzGDCS+N86SSUdqw01RHa0ejLWLFYcHEZ+8o= X-Received: by 2002:a0c:ffca:: with SMTP id h10mr4608263qvv.238.1592498115715; Thu, 18 Jun 2020 09:35:15 -0700 (PDT) MIME-Version: 1.0 References: <0365f842-ff05-b252-2fc7-f6f408fc52e3.ref@verizon.net> <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net> <20200617105537.36e9ee17@grisu.home.partim.org> In-Reply-To: From: Christopher Morrow Date: Thu, 18 Jun 2020 12:35:04 -0400 Message-ID: To: Stephen Kent Cc: Martin Hoffmann , "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] 6486 bis 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, 18 Jun 2020 16:35:18 -0000 On Wed, Jun 17, 2020 at 9:14 AM Stephen Kent wrote: > > Martin, > > I assume the interim meeting scheduled for next week is intended to > resolve any outstanding issues. I plan to revise the most recent version > of the text I posted based on that meeting. I hope to have some slideware out before monday for review and preparation as well :) Ideally it encapsulates the current state of the document and we can reach quick consensus there (and on-list) in order to get the text published before the 108 meeting timeslot. thanks for the folk who worked on the revised text so far, at least: stkent, randy, job, martin, jayb, timb, russ, smb (others I'm sure I missed along the way) -chris co-chairotorial. > Steve > > Hello! > > > > I am curious what the plan forward is with regards to 6486-bis? We are > > looking into releasing a 1.0 version of Routinator soon-ish and would > > like to have the revised manifest validation rules included since > > they most definitely constitute breaking changes. > > > > While we don???t necessarily need to wait for the final RFC, it would be > > good to at least have a relatively stable I-D to build upon. > > > > Kind regards, > > Martin > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Jun 23 20:41: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 1FA7C3A0781 for ; Tue, 23 Jun 2020 20:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 pMuJtNGzQp-H for ; Tue, 23 Jun 2020 20:41:46 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 CCA313A077A for ; Tue, 23 Jun 2020 20:41:45 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id x62so661741qtd.3 for ; Tue, 23 Jun 2020 20:41:45 -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=mwGOWkOLeDAwY14Dut+zxsUrXYc3MCMSW903QiNSjqw=; b=ntfkD/THKngU1Mlo8nnPdm6Lb+vPfq2vJi9v9hK5X1xca5f61M6X4FHhQQMMFvfRpL qfwnOezGWy2NVdPg0kxpttovpWomU122MGuPUyea8wMx0M/BKvHtQpL/lBEhGAL3SZFX QYLjLNUXdZhJ0CLnHYGReKkJI4mlK3++eXaOlGI2qgtlmjtmhlWG6ex7bx434/PL815T bnG2daBYqJoBSPvNAPGPRcbdivGb64WZg0WZdWVRmsDXzF5aQnun6JkhgIk4o9Yj9XeL mNLbDQ7zp85kkZF550ZwG4le7B1aMK4Q78oKPef1SAzMyVsTzgHY/N3e/2PruAGZBq/b XOXw== 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=mwGOWkOLeDAwY14Dut+zxsUrXYc3MCMSW903QiNSjqw=; b=VoxdRKlXrfieHh5p6Km1Iq3DbWYSieyiQ+r6sKgZcG38nzyPoCi8GT5jeVbVF8up7D WIbIwHhq2t6mwIpjLReiQwvyNEiJfn8Ppa9eTIgnONC9SIOldLRwn9etiApfwMuGzuiX 1KtI43rQvoWfh3W2+h2vQFSLiuXEnaeGMjboem4NDXyZJX4pZP3HIx0uW8ubWFRCgWkE ABt9+kGK/FGicDT151za7+w2r7wRjYwDtfmSeVasY9ApQZf26zb8dQyd8e0t61U7UfXl jCLE5hMBVX7Pxrz9H5j3N9ot4Z5kXUcgJ04pYSsUhCjdznYa6XYUjc6O07ezAWnfoEBw GNHA== X-Gm-Message-State: AOAM532ZiY7TuK82hADr6jtrVabtt935gIE8tkNhJZyVbjhuwkJKKDC9 8V44VmODcMX5T4Fd6NNGBpjBSiBF8Y1ISqdSoN8LlA== X-Google-Smtp-Source: ABdhPJxfZmnNJ+SWXfMJiJLfEcf/Y6QFokCTUSXkBnDkBsLJcWxvjlBuFh36gCzKXjw42U2RMuJ4ETRVmjvHOsopfWI= X-Received: by 2002:ac8:36d8:: with SMTP id b24mr140373qtc.315.1592970104438; Tue, 23 Jun 2020 20:41:44 -0700 (PDT) MIME-Version: 1.0 References: <0365f842-ff05-b252-2fc7-f6f408fc52e3.ref@verizon.net> <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net> <20200617105537.36e9ee17@grisu.home.partim.org> In-Reply-To: From: Christopher Morrow Date: Tue, 23 Jun 2020 23:41:33 -0400 Message-ID: To: Stephen Kent Cc: Martin Hoffmann , "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] 6486 bis 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, 24 Jun 2020 03:41:47 -0000 I am late, but there are slides now... again, thanks for the folk that did the hard work... I'm just making a summary and we(chairs) are hoping to guide the landing onto the proposed text :) See you all tomorrow! -chris On Thu, Jun 18, 2020 at 12:35 PM Christopher Morrow wrote: > > On Wed, Jun 17, 2020 at 9:14 AM Stephen Kent > wrote: > > > > Martin, > > > > I assume the interim meeting scheduled for next week is intended to > > resolve any outstanding issues. I plan to revise the most recent version > > of the text I posted based on that meeting. > > I hope to have some slideware out before monday for review and > preparation as well :) > Ideally it encapsulates the current state of the document and we can > reach quick consensus there (and on-list) > in order to get the text published before the 108 meeting timeslot. > > thanks for the folk who worked on the revised text so far, at least: > stkent, randy, job, martin, jayb, timb, russ, smb > (others I'm sure I missed along the way) > -chris > co-chairotorial. > > > Steve > > > Hello! > > > > > > I am curious what the plan forward is with regards to 6486-bis? We are > > > looking into releasing a 1.0 version of Routinator soon-ish and would > > > like to have the revised manifest validation rules included since > > > they most definitely constitute breaking changes. > > > > > > While we don???t necessarily need to wait for the final RFC, it would be > > > good to at least have a relatively stable I-D to build upon. > > > > > > Kind regards, > > > Martin > > > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Jun 24 04:39: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 6F8FA3A0D73 for ; Wed, 24 Jun 2020 04:39: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, 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 gLcECk5JVZcb for ; Wed, 24 Jun 2020 04:39:06 -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 CC5F13A0D70 for ; Wed, 24 Jun 2020 04:39:06 -0700 (PDT) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 9A9A622014C; Wed, 24 Jun 2020 11:39:05 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 8A25927C0058; Wed, 24 Jun 2020 07:39:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 24 Jun 2020 07:39:04 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekjedgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdttd dttddtvdenucfhrhhomheplfhosgcuufhnihhjuggvrhhsuceojhhosgesnhhtthdrnhgv theqnecuggftrfgrthhtvghrnhephffhtdehteeiveehkedvuedtffeuieejtdetfeegie ffudfhkefhgeelvddtvdejnecukfhppeduledvrddugeejrdduieekrddutdejnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhhosgdomhgvsh hmthhprghuthhhphgvrhhsohhnrghlihhthidquddtgeejleduheekgedqvdeffeefkeef vddtqdhjohgspeepnhhtthdrnhgvthesshhosghorhhnohhsthdrnhgvth X-ME-Proxy: Received: from bench.sobornost.net (bench.sobornost.net [192.147.168.107]) by mail.messagingengine.com (Postfix) with ESMTPA id A005A328005A; Wed, 24 Jun 2020 07:39:03 -0400 (EDT) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id b874688b; Wed, 24 Jun 2020 11:39:01 +0000 (UTC) Date: Wed, 24 Jun 2020 11:39:00 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: <20200624113900.GA87904@bench.sobornost.net> References: <0365f842-ff05-b252-2fc7-f6f408fc52e3.ref@verizon.net> <0365f842-ff05-b252-2fc7-f6f408fc52e3@verizon.net> <20200617105537.36e9ee17@grisu.home.partim.org> 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: [Sidrops] rpki-client implementation report (Was: 6486 bis) 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, 24 Jun 2020 11:39:08 -0000 Dear group, This is an implementation report based on my understanding of OpenBSD's current rpki-client's behavior. We've worked hard in the last few months to convince the community at large that there are important isues in how some implementations treated untrusted data. Please verify this yourself as well, I could be wrong! Other RPKI cache implementers who care about security may want to copy this template so we can more easily compare notes. <<< HOMEWORK >>> The "OK" in the below table means that *I* think rpki-client's understanding of the proposed internet-draft text is compliant with the source code. The "OK" does not mean good/bad, in some cases there might be reason to deviate from the specs (an implementation could be ahead of its time). The normative terms are where the money is, so by mapping normative terms to behavior we can more easily understand whether consensus is emerging in this group. The goal of this implementation report template is not to get as many OKs as possible, but to see which implementers are tracking this effort and where they currently stand. I know that routinator for instance will check 'NOPE' for some of these normative terms, but they already have plans to change that in the upcoming weeks. An '??' can mean that I didn't have the time to figure it out, don't understand the text, or don't understand the code. :-) Report - 2020-06-23 OpenBSD rpki-client 6.7-current || Stephen Kent's text ....an RP MUST ignore the data associated with the publication point ......: rpki-client OK ....all signed objects associated with the CA instance MUST be ignored ....: rpki-client OK ...signed objects associated with the CA instance MUST be ignored, because : rpki-client OK ....an RP MUST perform a series of tests to determine which signed object .: rpki-client OK ..._All_ of the files referenced by the manifest MUST be located at the ...: rpki-client OK ...the same publication point, an RP MUST *???* ...........................: rpki-client ?? ...A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be ...: rpki-client OK ....and matches the CRLDP, the first one encountered MUST be used .........: rpki-client ?? ...Any other .crl files MUST be ignored and a warning MUST be issued ......: rpki-client OK ..an RP SHOULD examine the most recent cached manifest ....................: rpki-client OK ...no access to a current manifest, processing stops and a warning MUST ...: rpki-client OK ...the RP SHOULD examine its cache to determine if these files ............: rpki-client OK ....the RP SHOULD use the cached files to replace those missing ...........: rpki-client OK ....then an RP SHOULD examine its local cache to determine ................: rpki-client OK ...The RP SHOULD use cached files to replace any ..........................: rpki-client OK ...then the out-of-scope entries MUST be disregarded ......................: rpki-client OK ...certificates (CA and EE) MUST be considered invalid ....................: rpki-client OK ..the RP MUST not try to acquire and validate _subordinate_ signed objects.: rpki-client OK If you develop RP software, please produce a similar report and share it with sidrops@ietf.org. We share implementation reports in IDR, and often this turns out to be a very valuable ritual. Kind regards, Job From nobody Wed Jun 24 09:04:55 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 ECCF83A0F29; Wed, 24 Jun 2020 09:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 O74WZAci4iaK; Wed, 24 Jun 2020 09:04:52 -0700 (PDT) Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) (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 DFE6F3A0E67; Wed, 24 Jun 2020 09:04:51 -0700 (PDT) Received: by mail-qv1-xf44.google.com with SMTP id dm12so1269740qvb.9; Wed, 24 Jun 2020 09:04:51 -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=cI7lz00TnR41lqVTKDagZOZb9zuihEaRgEPA5oEN+vY=; b=b6Sp0v3Q6X0fV/7kAyPoU/FpavSpzdGr+I0ta8lmAIIJaCPlYQQo42RQlf8oxlvtud kCeMm1i1JtFbYllBcaBmkbzcm4ETI/u/zJptBipR/0xBVWwq7ZD7sgRLfuDbwSZ7HH7n YAOwS9nxSyUxZuVRTQ8gAj81yK/v/FlcR/IMw8LhwdIS1z4ar2v1VPcn4e4bmbi0ys/+ O/31S0xTTEO3/BS+rMTwa0BU5oSGJmqQRkrcm/pwkYsyGTCwokoCaWIf3ti76Q2AOGVc mEflCVrEw4DI7UAvyjWOmizxodrp7+6GcRs2ardrm7IqsjZCwEE404oH9wEIyvNwwPrE 9nUw== 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=cI7lz00TnR41lqVTKDagZOZb9zuihEaRgEPA5oEN+vY=; b=rm1qsNATcpde7xYORYznrh6vVvhSTDIGzOtOj2iB8gbn249OcyBOMoRVwpjw9dtTss rsfIqiszKwuKmVgSYy1RZlT2WifMzruqMXvUiwxJRlxWFLtYSxxCvDmFu0OlZvYIfWcM CSTqnIxLUbTQkHKBfh+1h+iH+6YV/3+8j3Qce6+ZPLLaAxv0hTd79QG7eWflOVxjW6V0 5I11KGHi6S6Vxp7FxW+49yla+vL3aEUUvK3oUqv16A7UQec3YRbRw8brmCYPWP1Zl+j/ IibusF4B3SrwqQQSfBDmXA5mXwJ2aDLBFRsfLrJe1+leywXyvOAEzbjzdLTEWwMh5XV1 SUag== X-Gm-Message-State: AOAM533FAEzjot0/JKo9mKBpqhnUT8Oonk0zv1SQPKPwaM+y7szgPrKq gHzhRsUBWW/R6oF4nASCrTsCxSGsCpkzGYC7Wmg= X-Google-Smtp-Source: ABdhPJzQS4mKd0Bn7zfddZ8b3DD5cutqOaLBbL8VWpmCwOnEIIDUF4Lq69HTn6/Jo4u4CX9fKg0sjuf/Al9WfL1DRe0= X-Received: by 2002:ad4:4812:: with SMTP id g18mr3675235qvy.56.1593014690662; Wed, 24 Jun 2020 09:04:50 -0700 (PDT) MIME-Version: 1.0 References: <87sgfa86dw.wl-morrowc@ops-netman.net> In-Reply-To: <87sgfa86dw.wl-morrowc@ops-netman.net> From: Christopher Morrow Date: Wed, 24 Jun 2020 12:04:39 -0400 Message-ID: To: Chris Morrow Cc: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] SIDROPS Interim Meeting - 24/June/2020 0700 PDT / 1000 EDT / 1600 CDT 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, 24 Jun 2020 16:04:54 -0000 Howdy again! 1) Thanks for the participation today at the Interim meeting. I believe good progress was made and we expect an initial draft from the authors (skent@) in the next week or so. 2) I uploaded slide changes to include the cache conversation AND implementation data reported in the meeting. 3) I expect some conversation on list after the draft is posted and that we've got at least 2 topics to discuss at the upcoming f2f/video meeting: a) jhaas - what to do about inconsistent views at the router end of the pipelines? b) job/randy - alert/alarm when RP/CA conversations cease being polite thanks again! On Fri, Jun 5, 2020 at 12:48 AM Chris Morrow wrote: > > > Howdy SIDROPS Folks! > > I think we chatted at the end of the previous meeting about needing a > follow-up regarding some of the pending changes to RFC6486 which were > discussed at the last event. I believe we still need to do this, there > seems to be some good energy and progress being made, let's meet and > chat about that some more! > > We're putting in an Interim Meeting request for: > June 24 2020 - 0700 PDT / 1000 EDT / 1600 CDT > June 25 2020 - 0000 "Sydney Time" > > I would like to proctor a meeting with some slides about the current > state of the discussion and a strawman to batter with a few lead pipes > (maybe you all will agree with me, who knows!) and see if we can get > to a reasonable answer. In the coming week or so I'll try to email > a reasonable position and get some slides organized, I expect > some in-meeting chat from the current Editors/Authors of the BIS document, > provided they can all attend :) > > thanks! > -chris > co-chariot-rider-in-storms > > ps: https://datatracker.ietf.org/meeting/interim-2020-sidrops-02/session/sidrops > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Jun 25 05:47: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 0AB113A0A13 for ; Thu, 25 Jun 2020 05:47:49 -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 EpFDzKw55MVO for ; Thu, 25 Jun 2020 05:47:47 -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 BC98D3A0A3B for ; Thu, 25 Jun 2020 05:47:47 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:216c:1f5c:36e0:10c6] (unknown [IPv6:2001:981:4b52:1:216c:1f5c:36e0:10c6]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8609E2E4F3; Thu, 25 Jun 2020 14:47:45 +0200 (CEST) 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=1593089265; bh=ZUIMjZGYtVpmR15anc7FpWl6W8ChIMXvLYyZJccmEnU=; h=From:Date:Subject:To; b=qGGLqPn9QQcl+82V4LYZGocQ8/MUaju+mJhqtjNDaUfIlkRD6GdoRpqgTvtx71/vb Dx/DBwr9pOva5++W0z3XN+gPiyCb1je/u8lVX6hmGlFCEwz6YLqBMKvwPgapQYzh5a DhbCzt6fl6mHl5ZC7whvDcjNgxmjiBU2C2PzXDqA= From: Tim Bruijnzeels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 14:47:45 +0200 Message-Id: To: SIDR Operations WG X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Sidrops] RRDP and rsync URIs 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, 25 Jun 2020 12:47:50 -0000 Hi, As discussed yesterday I would send a commentary to the list regarding = rsync URIs in RRDP. The and elements in RRDP snapshot and delta files = include a 'uri' attribute which corresponds to the uri where the object = would have been found if rsync where used. But, these uris can be = anything, they do not need to correspond to the https uri of where the = snapshot or delta file was retrieved. I remember now that some hallway discussions occurred at least (can't = find stuff written right now) where this was considered to be a feature. = E.g. for RIPE NCC the RRDP files are hosted under 'rrdp.ripe.net' while = rsync uses a different hostname altogether: 'rpki.ripe.net'. However, this can lead to issues if RPs naively map the rsync uris to = files on disk and add / update / remove these files. In particular it's = possible for different RRDP servers to have the same (each other's) = rsync uris. There is some text in section 3.4.2 of RFC 8181 (RRDP) that = alludes to this: o When a Relying Party encounters a "withdraw" element, or a "publish" element where an object is replaced, in a delta that it retrieves from a Repository Server, it MUST verify that the object to be withdrawn or replaced was retrieved from this same Repository Server before applying the appropriate action. Failing to do so will leave the Relying Party vulnerable to malicious Repository Servers instructing it to delete or change arbitrary objects. There are several ways to deal with this. Routinator uses a strategy where each RRDP server (identified by its = notification.xml) gets a separate namespace on disk, and rsync uris are = mapped to files under these namespaces. When objects need to be = localized for a CA certificate which uses RRDP then both the = notification.xml uri and expected rsync uris are known. So, objects can = be found without issue. I believe that this is the simplest way to = approach the potential rsync uri collisions between RRDP servers. Other approaches include being more uri agnostic, i.e. find manifest = candidates by matching Key Identifiers, purge invalid / superceded = manifests, and find objects on manifests by hash. Dropping objects could = then be done when the reference count from ALL known manifests drops to = 0. That way I cannot include your object on my mft, then remove it, and = mislead you into dropping the object. I am sure that there are more ways. I do not think that we must define = the approach used to a single solution. But it is worth exploring = boundaries. Kind regards, Tim= From nobody Mon Jun 29 15:59: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 56AE33A0DE8 for ; Mon, 29 Jun 2020 15:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=oracle.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 h_TSu706c9LK for ; Mon, 29 Jun 2020 15:59:01 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 2C77D3A0DE5 for ; Mon, 29 Jun 2020 15:59:01 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05TMwECs118970 for ; Mon, 29 Jun 2020 22:59:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : mime-version : subject : message-id : date : to; s=corp-2020-01-29; bh=fPo9ThSxT88PTWsJWITwEmACkJ5+GRsVfVL9o8e+y2U=; b=V803VrnjEuxgjA2bHBdsJg1MU5Lyr9Y909pWXmGL9E50JI5wYWWlwHnxyQJNl28gnYyF i5BKxXu+s/1JztZskdvWGEgaFHvVrUjjM+4KKfkLrmru04mbHLS9dQ/urQU1Am1Lsze3 nAVXK8p7Q/3sk1GSyj+fRg29stgtdwLg8BCkR7WC8/5uRFLI8qBfpvwCnvNsHqWSKZ7Z 2PoD7CB/c5ayD9nXV7Fzz8HpFFEi0Vp6ofrcuWiSs58OqUu0veEmLXDCmkh/HDOZyiv7 GoAaOpH3zo9VgmAaSF9/Vmk62mgbjLG0qw5u094wXDT3HCCwq915mut3lAyP+6CJt9w1 AQ== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 31xx1dnygx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 29 Jun 2020 22:59:00 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05TMvhO3145170 for ; Mon, 29 Jun 2020 22:58:59 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 31xg1vs320-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 29 Jun 2020 22:58:59 +0000 Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 05TMwweJ019915 for ; Mon, 29 Jun 2020 22:58:58 GMT Received: from [192.168.0.22] (/73.68.37.24) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Jun 2020 22:58:58 +0000 From: Doug Madory Content-Type: multipart/alternative; boundary="Apple-Mail=_7F944BAF-D3C0-4EA3-ABD8-B3918E156320" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Message-Id: Date: Mon, 29 Jun 2020 18:58:56 -0400 To: sidrops@ietf.org X-Mailer: Apple Mail (2.3445.104.14) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9667 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006290146 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9667 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 clxscore=1011 adultscore=0 suspectscore=0 mlxlogscore=999 cotscore=-2147483648 lowpriorityscore=0 malwarescore=0 phishscore=0 impostorscore=0 mlxscore=0 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006290146 Archived-At: Subject: [Sidrops] draft-ietf-idr-bgp-open-policy-11 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, 29 Jun 2020 22:59:02 -0000 --Apple-Mail=_7F944BAF-D3C0-4EA3-ABD8-B3918E156320 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Route Leak Prevention using Roles in Update and Open messages] https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-11 = I would like to voice my support for this draft standard. In my opinion, = the measures outlined in the proposal would serve to reduce the = propagation of routing leaks - even with incomplete deployment. = Specifically, I think the establishment of BGP Roles would help network = operators to avoid exporting routes in a manner that results in the = routing leaks we see on nearly any given day. Respectfully, Doug Madory Director of Internet Analysis, Oracle @internetintel Hanover, NH +1 603-676-5067 --Apple-Mail=_7F944BAF-D3C0-4EA3-ABD8-B3918E156320 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
[Route Leak Prevention using Roles in Update = and Open messages]
https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-11

I would = like to voice my support for this draft standard. In my opinion, the = measures outlined in the proposal would serve to reduce the propagation = of routing leaks - even with incomplete deployment. Specifically, I = think the establishment of BGP Roles would help network operators to = avoid exporting routes in a manner that results in the routing leaks we = see on nearly any given day.

Respectfully,

Doug Madory
Director of Internet Analysis, = Oracle @internetintel
Hanover, NH       =                +1 = 603-676-5067

= --Apple-Mail=_7F944BAF-D3C0-4EA3-ABD8-B3918E156320--