From nobody Sat Aug 4 10:06:38 2018 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 01AC0130E03; Sat, 4 Aug 2018 10:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 UMrelFE6LlhW; Sat, 4 Aug 2018 10:06:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 641E5130E36; Sat, 4 Aug 2018 10:06:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fm00N-0003er-BU; Sat, 04 Aug 2018 17:06:15 +0000 Date: Sat, 04 Aug 2018 10:06:14 -0700 Message-ID: From: Randy Bush To: Linda Dunbar Cc: , sidrops@ietf.org, ietf@ietf.org, draft-ietf-sidrops-rpki-tree-validation.all@ietf.org In-Reply-To: <153332707807.18413.5304119074828612207@ietfa.amsl.com> References: <153332707807.18413.5304119074828612207@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-rpki-tree-validation-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 04 Aug 2018 17:06:24 -0000 > why the implementation description has to be an RFC? clog up the RFCs because this is engineering, not academic research; no requirement for original contribution. having the workings of a protocol implementation well documented helps others interoperate, gives them ideas for their own implementations, ... we have a long trail of vendorX's implementation of coffee ice cream. it is helpful. < insert snark comparison to 342 'bright ideas' about how to get one's name on an rfc for useless work > randy From nobody Mon Aug 6 01:17:25 2018 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 301C5127598 for ; Mon, 6 Aug 2018 01:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs-nl.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 UA7ORu0bA25Z for ; Mon, 6 Aug 2018 01:17:18 -0700 (PDT) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (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 0330D130DFF for ; Mon, 6 Aug 2018 01:17:16 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id e19-v6so4688863edq.7 for ; Mon, 06 Aug 2018 01:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nlnetlabs-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ut2+G5gua7O0/Kwp8TZ/RGwwpA5fgOF622jsS1BuV1k=; b=bjv8gLJFKkF1bnRngUZjYSzFuXLsl57WdjBxMs3xvB7WwGGMMQE+9UxEi0UJjYsdIT v5E6vrCbKocRkVxxgYs45XuntFTnba1d5osEccAiRN186o0/I+dWSqR/d+NpXyDh7U3B d8f/+BN+iQjqgIfyW8jQAtANh9wJKFDgQKWzDhCSSws8bZwRsJCBU4BwGrmOMJDYeVMh oXkbnVtGOubdT2pugxB8A18upjusccSflniSfpbYjG5NgIgALQNAU6Djaf/UxDmyP21b YH2nqvyQButK2OaFqEZpJ95NQI5vyl3MWY6ihhPKMo/B5mOiHQVYHdJdIxn3uTQKQ9gY VtbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ut2+G5gua7O0/Kwp8TZ/RGwwpA5fgOF622jsS1BuV1k=; b=ab2hvQ3M3CDBWyFL9jgRJGECW6JCZsMg2zNmyIircjLzVg7TzOPJ4kWJ+0AT7AOJig PwvgK+GDOM/bvTupb17eMmj0p2yu6uRyeFlKcSmFPNzMIyANbh9pDYlTancK28g2jN8/ GtNPnQOs1VC9CAFjVcsbygUmPzKHEypxax95D8Dw5I+Uf66VWJZuFcRbgVdCvxbnD7pl deVerEg4v8rcBJjnWsukeg290xU87CIDwUs4IlHnlbboK6J6peOvkawyLxt69bi7J/wN /QmLEAK1LodYpniqjlJtS7KDjjaBVijRqIRJW3a3lX6Zpygdc4ZQSZP0srDyQaS+d28J 1xdg== X-Gm-Message-State: AOUpUlH4YB0AVoVbF3LlaB3RbmORIp0/XXeZIPaSoqK3bbbQAwc4GLHw pve+ci0nAnon7+ezoQMbTPz0Ew== X-Google-Smtp-Source: AAOMgpcgQFl5zLKZWyNkYq5mPj1IwKB9g3OfukqTJPX7xGx2tJbFwdg9M2AL3cYytRr8mZ6H0VEB7w== X-Received: by 2002:aa7:db09:: with SMTP id t9-v6mr17154897eds.277.1533543434545; Mon, 06 Aug 2018 01:17:14 -0700 (PDT) Received: from ?IPv6:2a04:b900::1:7cdd:3f51:b924:7877? ([2a04:b900:0:1:7cdd:3f51:b924:7877]) by smtp.gmail.com with ESMTPSA id p20-v6sm4478866edr.12.2018.08.06.01.17.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 01:17:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Tim Bruijnzeels In-Reply-To: <153332707807.18413.5304119074828612207@ietfa.amsl.com> Date: Mon, 6 Aug 2018 10:17:12 +0200 Cc: gen-art@ietf.org, sidrops@ietf.org, ietf@ietf.org, draft-ietf-sidrops-rpki-tree-validation.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153332707807.18413.5304119074828612207@ietfa.amsl.com> To: Linda Dunbar X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-rpki-tree-validation-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 06 Aug 2018 08:17:19 -0000 Hi Linda, We took this to the WG because we wanted a few things out of it: 1) get feedback and ensure that the algorithm used by our validator is = correct (even if it is not the only way to do this) 2) provide transparency to our users 3) provide a reference that other Relying Party implementers might find = useful I believe that these goals were achieved. We received valuable feedback = from the WG and had good discussions with other implementers. Note that I say =E2=80=98we=E2=80=99 because I was involved in this = while working at the RIPE NCC. By now I have a new position, and as such = I don=E2=80=99t mind removing myself from the author list possibly in = favour of someone who is going to be involved in the future of this = particular implementation. Personally really I don=E2=80=99t mind very = much whether this document becomes an RFC or not, it already served its = main purposes #1 and #2, but it seems a relatively small remaining step = to do and ensure #3 -> i.e. have a description of one implementation = that others may find useful. Having it as an RFC rather than an expired = draft, bundled with the software, will make it easier to find and it = shows that others reviewed the document for clarity and correctness. That said, it takes a lot of work and process from us, and everyone = else. And by definition this is a moving target. The implementation will = change (in fact v3 is just (about to be) released), and then the RFC is = outdated. So, I will not opt for this full (informational) RFC path = again for future implementations I am involved in. It would be nice if = there were a more light-weight document track that could be used for = this though! We really benefitted from the feedback and users have said = that they like the transparency. Kind regards, Tim Bruijnzeels > On 3 Aug 2018, at 22:11, Linda Dunbar wrote: >=20 > Reviewer: Linda Dunbar > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-sidrops-rpki-tree-validation-02 > Reviewer: Linda Dunbar > Review Date: 2018-08-03 > IETF LC End Date: 2018-08-10 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: > This draft describes one sample implementation of validating the = content of > RPKI certificate Tree. The description is clear, especially clearly = described > which section of RFC6487 are based for its implementation. >=20 > Major issues: > None. >=20 > Minor issues: > None. >=20 > Nits/editorial comments: > Section 9.1. the Hash Collisions is more of design in-complete instead = of > "Security Considerations". So is the section 9.2 In addition, why the > implementation description has to be an RFC? clog up the RFCs >=20 From nobody Mon Aug 6 07:20:00 2018 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 A84D5128BAC for ; Mon, 6 Aug 2018 07:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZonLlZj1tzlW for ; Mon, 6 Aug 2018 07:19:51 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 8060E130E59 for ; Mon, 6 Aug 2018 07:19:48 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id l2-v6so11713870wme.1 for ; Mon, 06 Aug 2018 07:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=j+lYwuprQIie40hI3gSKDGmw2Ho4PGJVZF63hoAReEM=; b=tNLPWqQcCDVI8cL4h+4EhqXKYuBUgoq8vZP8XlEFgdluAKGNAQP37NgMRqYkbkwaQA ejVJ1FSYgHrI0FW+Ff+2F1UOVkLmih7lhB4wra1so8ht8L4SgRHnEKlzBIj0kqeKLhAe vBuOywIi0ATy4nXtYnH6BtOUlVR9UVbF8extW7wjuoqo0xO1/OA6oG8gFyfk6Or1vRgN hYWLQXROuVw7xmeF2cmMhY8kR9zTMOc5DJ87dbTSg9rRCIVqcPUpN73MgajQBivzrp18 DoKdJDp1tKuOYWBPsrFtyNw8A8BIAq/7kEGbl+2ZPKCAo+V/3gGTOPDgHC+hOgauNr0h PtsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=j+lYwuprQIie40hI3gSKDGmw2Ho4PGJVZF63hoAReEM=; b=QW/9iLu0vETH7q+Y9mQMFSRSc9WX5zwcbcq71s3TCCVCQBiMHG323b2jENfslKdez1 QDKVDG/A3K01lDNtQD552/QQc3W/fQl7d7oIuHDcOS2+XEKnz7mZzMchSFojhT1GSyLs 992QofOEV+J+79wNMrYOy5ePxeTg4k4GGaRdeq46wN5SQTbLqIM9uK/8ZCl7HwcZrmX7 cHHnMiBsuOP6FisqPbOwtB4yPiZdokvheNMVKWhd2t6DQKmz1ckIwSikyUoyybR5TKt+ O8cWaMFYi40aDQ4poGHDKn0AYHCF74jt/YCZGC82pdxTDGpAtCUdzHY5MGABrn6yiTNj zjrg== X-Gm-Message-State: AOUpUlEF9o8hT1x3DfeOGsUpxIAVt2PnjfJY30haVraONE2XkJa1oAB0 1HYOiBD76kE+e9oeK/AqG1xdt2dainXzIolslY5e3Q== X-Google-Smtp-Source: AAOMgpfJv5M0knWlcGeZWnwmjdGwysVngQfgBKWWqN4VVDHuKiGCeiZF0y4SpSytHtC0s1ZfohSXWkk0KPWLJkM0WN0= X-Received: by 2002:a1c:87c9:: with SMTP id j192-v6mr11084921wmd.71.1533565186415; Mon, 06 Aug 2018 07:19:46 -0700 (PDT) MIME-Version: 1.0 References: <153332707807.18413.5304119074828612207@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Mon, 6 Aug 2018 10:19:09 -0400 Message-ID: To: tim@nlnetlabs.nl Cc: Linda Dunbar , General Area Review Team , sidrops@ietf.org, IETF Discuss , draft-ietf-sidrops-rpki-tree-validation.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-rpki-tree-validation-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 06 Aug 2018 14:19:53 -0000 On Mon, Aug 6, 2018 at 4:17 AM Tim Bruijnzeels wrote: > > Hi Linda, > > We took this to the WG because we wanted a few things out of it: > 1) get feedback and ensure that the algorithm used by our validator is co= rrect (even if it is not the only way to do this) > 2) provide transparency to our users > 3) provide a reference that other Relying Party implementers might find u= seful > > I believe that these goals were achieved. We received valuable feedback f= rom the WG and had good discussions with other implementers. > > Note that I say =E2=80=98we=E2=80=99 because I was involved in this while= working at the RIPE NCC. By now I have a new position, and as such I don= =E2=80=99t mind removing myself from the author list possibly in favour of = someone who is going to be involved in the future of this particular implem= entation. Personally really I don=E2=80=99t mind very much whether this doc= ument becomes an RFC or not, it already served its main purposes #1 and #2,= but it seems a relatively small remaining step to do and ensure #3 -> i.e.= have a description of one implementation that others may find useful. This is listed as an Informational document - from RFC2026, Section 4.2.2: An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3). I believe that having this sort of document, which describes how an implementation is, er, implemented is useful to the community - we have many "theoretical" type document, having more "and this is how it actually got implemented / works" seems well within the Informational series, and Ops Area mandate. W > Having it as an RFC rather than an expired draft, bundled with the softwa= re, will make it easier to find and it shows that others reviewed the docum= ent for clarity and correctness. > > That said, it takes a lot of work and process from us, and everyone else.= And by definition this is a moving target. The implementation will change = (in fact v3 is just (about to be) released), and then the RFC is outdated. = So, I will not opt for this full (informational) RFC path again for future = implementations I am involved in. It would be nice if there were a more lig= ht-weight document track that could be used for this though! We really bene= fitted from the feedback and users have said that they like the transparenc= y. > > Kind regards, > > Tim Bruijnzeels > > > > > > On 3 Aug 2018, at 22:11, Linda Dunbar wrote: > > > > Reviewer: Linda Dunbar > > Review result: Ready > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > . > > > > Document: draft-ietf-sidrops-rpki-tree-validation-02 > > Reviewer: Linda Dunbar > > Review Date: 2018-08-03 > > IETF LC End Date: 2018-08-10 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: > > This draft describes one sample implementation of validating the conten= t of > > RPKI certificate Tree. The description is clear, especially clearly des= cribed > > which section of RFC6487 are based for its implementation. > > > > Major issues: > > None. > > > > Minor issues: > > None. > > > > Nits/editorial comments: > > Section 9.1. the Hash Collisions is more of design in-complete instead = of > > "Security Considerations". So is the section 9.2 In addition, why the > > implementation description has to be an RFC? clog up the RFCs > > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Aug 6 20:59:19 2018 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 56111130E31; Mon, 6 Aug 2018 20:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 7WoOFip4cO0g; Mon, 6 Aug 2018 20:59:15 -0700 (PDT) Received: from mail-ua0-x242.google.com (mail-ua0-x242.google.com [IPv6:2607:f8b0:400c:c08::242]) (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 A5029130E1A; Mon, 6 Aug 2018 20:59:15 -0700 (PDT) Received: by mail-ua0-x242.google.com with SMTP id y10-v6so14655281uao.4; Mon, 06 Aug 2018 20:59:15 -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=h/CbWj7HRgqF/f2EnpSFc2QsroDPobf21pkIG8eUHdM=; b=GGoK0uUjodaomMDdfUoWkLQvHXnYsjKtnCLCWIZ7c/YmCyk82TCsLEyiXEjNQUa9v/ YRmnAoAhnt+aw/AVBQGaCxf9NurUTRivIvUAa2d3QTuOjTt6+v4DUI3u0lBdzU4SBwYE GdtDtQPbm3zV09DzTMFDSjmBU0Tz54tEWR/gUVpAovy7C2wKQhP3WqR1yt6vi9hMoNEs utbfAjJ4yXhiEj2WvL0h1H/5Ikc0nNHBOAhpRRM+3se11FiWw2CUBYY0+EhaSS+A4xhC DQwtrmbMfu3x+8embBaN+1T75Rwd25G8N6p+ZcushRWgiAtQY+H5ciTACVq6NZJN12H3 AGCQ== 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=h/CbWj7HRgqF/f2EnpSFc2QsroDPobf21pkIG8eUHdM=; b=kliDf8zcV80N4PCFq4JgQQET6I+KMjEk/BNpiQAJItBl5cL4tnWCCH1VNfEZWpczIC dHjpiILOV/GGs3POXbhiyLlVeO/urND7mWZ2gKzrt5+dS9+q6BuocffRVrf1W3TUJ0oj 6nJCWvqSgJ+roU3UDQsyh86dva1ljzSMJZwzo98cFXkxsedtFEVsEW2IAGpe/9tPuRVM mxbugSEZd6zbXtSpKmRrXEk2zZGU3Q53rQcj2Xa3PNFeiNLIS0iXf2bs7aes7kk63TfN i8WHV1Kl8XMadVZnRkkua0cVCpcShcWD7wLURcZ7GFl/CMa1yT+/plFnEW8XwbXGnnUG aoHw== X-Gm-Message-State: AOUpUlG0RR6LqRRvRk4xWk3Jcy1BgaoHHQnzXlgRtopIR/R66YMTEI8c m5lKOaIl3Mz5THQi9V2vdvXzQRdTG85SB1jAlheBhwRT X-Google-Smtp-Source: AAOMgpfVexFPABQER49hCEb40enkJ9SiVfkaUdwyEn0dKv28T1yPGcO6zAkPyfv20d27X6Ay0+u/VXzY2Gv3pFVqXrg= X-Received: by 2002:a1f:b449:: with SMTP id d70-v6mr11012789vkf.160.1533614354426; Mon, 06 Aug 2018 20:59:14 -0700 (PDT) MIME-Version: 1.0 From: Christopher Morrow Date: Mon, 6 Aug 2018 20:59:03 -0700 Message-ID: To: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org Content-Type: multipart/alternative; boundary="000000000000d170cd0572d06a1a" Archived-At: Subject: [Sidrops] WGLC: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis - ends 20-Aug-2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 03:59:18 -0000 --000000000000d170cd0572d06a1a Content-Type: text/plain; charset="UTF-8" Howdy WG Folken! Let's discuss the document: https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/ which has an abstract saying: "This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Special-Use Algorithm IDs and correcting the range of unassigned algorithms IDs to fill the complete range. This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures." Let's see if there are any items still to address here, and if not move this forward to publication. Last Call ends 20-aug-2018! thanks! -chris co-chair#2 --000000000000d170cd0572d06a1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy WG Folken!
Let's discuss the document:
=C2= =A0 https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpse= c-algs-rfc8208-bis/

which has an abstract saying:
=C2=A0 &quo= t;This document specifies the algorithms, algorithm parameters,
=C2=A0 = =C2=A0asymmetric key formats, asymmetric key sizes, and signature formats=C2=A0 =C2=A0used in BGPsec (Border Gateway Protocol Security).=C2=A0 Thi= s document
=C2=A0 =C2=A0updates RFC 8208 ("BGPsec Algorithms, Key F= ormats, and Signature
=C2=A0 =C2=A0Formats") by adding Special-Use = Algorithm IDs and correcting the
=C2=A0 =C2=A0range of unassigned algori= thms IDs to fill the complete range.

=C2=A0 =C2=A0This document also= includes example BGPsec UPDATE messages as well as
=C2=A0 =C2=A0the pri= vate keys used to generate the messages and the certificates
=C2=A0 =C2= =A0necessary to validate those signatures."

Let's see if there are any items still to address here, and if = not move this forward to publication.

Last Call en= ds 20-aug-2018!

thanks!
-chris
co-chair#2
--000000000000d170cd0572d06a1a-- From nobody Tue Aug 7 11:26:09 2018 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 51C46130EE4; Tue, 7 Aug 2018 11:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8PI5wYt5Qdm; Tue, 7 Aug 2018 11:25:59 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A14D130DF0; Tue, 7 Aug 2018 11:25:59 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-66-30-20-66.hsd1.ma.comcast.net [66.30.20.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id D4B57E; Tue, 7 Aug 2018 18:25:57 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 0F9192007166DD; Tue, 7 Aug 2018 14:25:47 -0400 (EDT) Date: Tue, 07 Aug 2018 14:25:46 -0400 From: Rob Austein To: Linda Dunbar Cc: tim@nlnetlabs.nl, General Area Review Team , IETF Discuss , sidrops@ietf.org, draft-ietf-sidrops-rpki-tree-validation.all@ietf.org In-Reply-To: References: <153332707807.18413.5304119074828612207@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.1 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Message-Id: <20180807182547.0F9192007166DD@minas-ithil.hactrn.net> Archived-At: Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-rpki-tree-validation-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 18:26:01 -0000 Speaking as another person implementing these protocols: I found this document useful as a checklist of issues to think about, along with commentary on how one implementation handled them. As it happened, I ended up doing most things slightly differently (Tim and I were each on at least our third implementations by this point, and had talked about a lot of it as we went along), but I still found it useful. I suspect that a new implementor coming in cold would also find this valuable, for more obvious reasons. If this isn't enough to make a draft worthy of publication anymore, push the IETF over and bury it, we're done. From nobody Fri Aug 10 05:57:30 2018 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 00178130DF7; Fri, 10 Aug 2018 05:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 tJTTm6J5z_Ci; Fri, 10 Aug 2018 05:57:12 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632A9130DD5; Fri, 10 Aug 2018 05:57:12 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fo6yc-000BIh-V7; Fri, 10 Aug 2018 14:57:10 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::1a4]) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fo6yb-0001TS-QC; Fri, 10 Aug 2018 14:57:09 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Oleg Muravskiy In-Reply-To: <153384489210.28635.11096824147990448991@ietfa.amsl.com> Date: Fri, 10 Aug 2018 14:57:09 +0200 Cc: ops-dir@ietf.org, sidrops@ietf.org, ietf@ietf.org, draft-ietf-sidrops-rpki-tree-validation.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8ADEB215-45E2-43BA-95C8-1806D418B88E@ripe.net> References: <153384489210.28635.11096824147990448991@ietfa.amsl.com> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3445.9.1) X-ACL-Warn: Delaying message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74a2a3a688655120c4a128cf45ccaa8314 Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rpki-tree-validation-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 10 Aug 2018 12:57:14 -0000 Thanks, J=C3=BCrgen, We will update READMEs in both versions of the validator once this = document is published. Cheers, Oleg > On 9 Aug 2018, at 22:01, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder = wrote: >=20 > Reviewer: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder > Review result: Ready >=20 > This is an informational draft documenting a specific algorithm > used to validate RPKI certificate trees. The draft is well > written and appears to be technically sound. >=20 > The code of the RIPE NCC implementation can be found on github > (follow the reference [github] contained in the draft). The README > on github says that there is a newer rpki-validator-3 and it is > somewhat unclear whether the algorithm described in this I-D is also > used by rpki-validator-3 or whether this I-D documents an algorithm > used by a meanwhile "legacy" implementation. I understand that this > I-D took almost 6 years from the initial -00 version to IETF last > call. Anyway, it may help if the github READMEs will eventually refer > to the RFC version of this I-D and explain to what extend the code > follows the algorithm detailed in this document. So this is more a > comment to the RIPE NCC maintainers of the github repository. >=20 > Nits: >=20 > - draft-ietf-sidr-rpki-validation-reconsidered-10 is now RFC 8360 > - draft-ietf-sidr-delta-protocol-08 is now RFC 8182 >=20 >=20 From nobody Fri Aug 10 10:20:52 2018 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 294CA130DF4; Fri, 10 Aug 2018 10:20:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <153392164211.25493.7829785966906603742@ietfa.amsl.com> Date: Fri, 10 Aug 2018 10:20:42 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-ov-clarify-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 17:20:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : BGP RPKI-Based Origin Validation Clarifications Author : Randy Bush Filename : draft-ietf-sidrops-ov-clarify-04.txt Pages : 4 Date : 2018-08-10 Abstract: Deployment of Resource Public Key Infrastructure (RPKI) based BGP origin validation is hampered by, among other things, vendor mis- implementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those mis-implementations; and thus updates RFC6811 by clarifying that all prefixes should have their validation state set, and that policy must not be applied without operator configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-ov-clarify-04 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-ov-clarify-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-ov-clarify-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 10 10:21:54 2018 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 A9BE1130F12; Fri, 10 Aug 2018 10:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 rdhsfw-TEbPl; Fri, 10 Aug 2018 10:21:44 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 47B4C1286E3; Fri, 10 Aug 2018 10:21:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1foB6b-00076Y-Au; Fri, 10 Aug 2018 17:21:41 +0000 Date: Fri, 10 Aug 2018 10:21:40 -0700 Message-ID: From: Randy Bush To: Dhruv Dhody Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-sidrops-ov-clarify.all@ietf.org, sidrops@ietf.org, "dhruv.dhody@huawei.com" In-Reply-To: <72ee1d70-d135-a445-75df-65df06fda61a@gmail.com> References: <72ee1d70-d135-a445-75df-65df06fda61a@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-ov-clarify-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 10 Aug 2018 17:21:46 -0000 hi druv, review appreciated. > =C2=A0=C2=A0=C2=A0 - The text in RFC6811 uses the term =E2=80=9Clookup=E2= =80=9D and =E2=80=9Cvalidation > state=E2=80=9D, the > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 clarification uses the term =E2=80=9Cmark= =E2=80=9D. This might be a bit pedantic but > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wouldn=E2=80=99t it be better to state the= clarification in terms of > RFC6811? good catch > =C2=A0=C2=A0=C2=A0 - Since RFC4271 and RFC6480 are stated as mandatory re= ading to > understand > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this I-D in section 2, shouldn=E2=80=99t t= hey be normative references? i will be interested in others' feedback on this one. i take normative as needed to implement, not as needed to have clue :) > =C2=A0=C2=A0=C2=A0 - I agree with the Gen-ART review, that ask for BGP in= the title, > in fact > =C2=A0=C2=A0=C2=A0 =E2=80=9CPrefix Origin Validation=E2=80=9D in the titl= e would be better! as i said to a different reviews, it has been changed to "BGP-4 RPKI-Based Origin Validation Clarifications" oh bleep! WARNING: The inline string was truncated because it was too long: BGP-4 RPKI-Based Origin Validation Clarifications s/-4// > =C2=A0=C2=A0=C2=A0 - Expand RPKI in Abstract. acl > =C2=A0=C2=A0=C2=A0 - The Requirement language phrasing is little differen= t from RFC 8174. rfced will discuss i have pushed -04. i hope the diff does not cause heartburn to anyone. again, thanks! randy From nobody Fri Aug 10 11:26:22 2018 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 80DB5130E47; Fri, 10 Aug 2018 11:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 F_J_nZlpcCiw; Fri, 10 Aug 2018 11:26:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 DAB57130DF9; Fri, 10 Aug 2018 11:26:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1foC6y-00048w-4t; Fri, 10 Aug 2018 18:26:08 +0000 Date: Fri, 10 Aug 2018 11:26:07 -0700 Message-ID: From: Randy Bush To: Dhruv Dhody Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-sidrops-ov-clarify.all@ietf.org, sidrops@ietf.org, Dhruv Dhody In-Reply-To: References: <72ee1d70-d135-a445-75df-65df06fda61a@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-ov-clarify-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 10 Aug 2018 18:26:14 -0000 >>> - Since RFC4271 and RFC6480 are stated as mandatory reading to >>> understand >>> this I-D in section 2, shouldn=A2t they be normative references? >> >> i will be interested in others' feedback on this one. i take normative >> as needed to implement, not as needed to have clue :) > > I usually go by this IESG statement - > https://www.ietf.org/blog/iesg-statement-normative-and-informative-refere= nces/; > which says - "Normative references specify documents that must be read to > understand or implement the technology in the new RFC, or whose technology > must be present for the technology in the new RFC to work." Just FYI yes. i guess so. my broken mind-set. >> i have pushed -04. i hope the diff does not cause heartburn to anyone. > > I saw these nits in the diff - >=20 > OLD: > When a route is distributed into BGP, the origin validation state of > the is set to as NotFound, Valid, or Invalid per [RFC6811]. > NEW: > When a route is distributed into BGP, the origin validation state of > the prefix is set to as NotFound, Valid, or Invalid as per [RFC6811]. sigh. thanks will hold -5 for a few more reviews randy From nobody Sat Aug 11 14:20:03 2018 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 18734130FA8; Fri, 3 Aug 2018 13:11:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar To: Cc: sidrops@ietf.org, ietf@ietf.org, draft-ietf-sidrops-rpki-tree-validation.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153332707807.18413.5304119074828612207@ietfa.amsl.com> Date: Fri, 03 Aug 2018 13:11:18 -0700 Archived-At: X-Mailman-Approved-At: Sat, 11 Aug 2018 14:20:00 -0700 Subject: [Sidrops] Genart last call review of draft-ietf-sidrops-rpki-tree-validation-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 20:11:18 -0000 Reviewer: Linda Dunbar Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sidrops-rpki-tree-validation-02 Reviewer: Linda Dunbar Review Date: 2018-08-03 IETF LC End Date: 2018-08-10 IESG Telechat date: Not scheduled for a telechat Summary: This draft describes one sample implementation of validating the content of RPKI certificate Tree. The description is clear, especially clearly described which section of RFC6487 are based for its implementation. Major issues: None. Minor issues: None. Nits/editorial comments: Section 9.1. the Hash Collisions is more of design in-complete instead of "Security Considerations". So is the section 9.2 In addition, why the implementation description has to be an RFC? clog up the RFCs From nobody Sat Aug 11 14:20:08 2018 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 410D3130DE9; Sat, 4 Aug 2018 13:33:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir To: Cc: draft-ietf-sidrops-ov-clarify.all@ietf.org, sidrops@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153341478021.31715.18305969749704687082@ietfa.amsl.com> Date: Sat, 04 Aug 2018 13:33:00 -0700 Archived-At: X-Mailman-Approved-At: Sat, 11 Aug 2018 14:20:00 -0700 Subject: [Sidrops] Secdir last call review of draft-ietf-sidrops-ov-clarify-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 20:33:00 -0000 Reviewer: Yoav Nir Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document clarifies two things about RFC 6811: That all routes MUST be marked as Valid, Invalid, or NotFound unless policy specifically says not to do so. The original text in RFC 6811 said SHOULD (perform a lookup...) and MAY (provide configuration options...), so this interpretation seems to be already strongly implied by 6811. That policy (such as rejecting invalid routes) MUST NOT be applied unless the operator specifically configured it. RFC 6811 already says, "An implementation MUST NOT exclude a route from the Adj-RIB-In or from consideration in the decision process as a side effect of its validation state, unless explicitly configured to do so." so I believe this is already stated in RFC 6811. Still, the text says that some implementers got it wrong. So I think the claim in the security considerations section, that this document does not introduce any security considerations beyond those of 6811 is reasonable. The fact that the security policy suggested by RFC 6811 MUST NOT be turned on by default may have been pointed out more emphatically, but this perhaps should have to be done in 6811. From nobody Sat Aug 11 14:20:15 2018 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 25D78130EDA; Thu, 9 Aug 2018 13:01:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Cc: sidrops@ietf.org, ietf@ietf.org, draft-ietf-sidrops-rpki-tree-validation.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153384489210.28635.11096824147990448991@ietfa.amsl.com> Date: Thu, 09 Aug 2018 13:01:32 -0700 Archived-At: X-Mailman-Approved-At: Sat, 11 Aug 2018 14:20:00 -0700 Subject: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rpki-tree-validation-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:01:33 -0000 Reviewer: Jürgen Schönwälder Review result: Ready This is an informational draft documenting a specific algorithm used to validate RPKI certificate trees. The draft is well written and appears to be technically sound. The code of the RIPE NCC implementation can be found on github (follow the reference [github] contained in the draft). The README on github says that there is a newer rpki-validator-3 and it is somewhat unclear whether the algorithm described in this I-D is also used by rpki-validator-3 or whether this I-D documents an algorithm used by a meanwhile "legacy" implementation. I understand that this I-D took almost 6 years from the initial -00 version to IETF last call. Anyway, it may help if the github READMEs will eventually refer to the RFC version of this I-D and explain to what extend the code follows the algorithm detailed in this document. So this is more a comment to the RIPE NCC maintainers of the github repository. Nits: - draft-ietf-sidr-rpki-validation-reconsidered-10 is now RFC 8360 - draft-ietf-sidr-delta-protocol-08 is now RFC 8182 From nobody Sat Aug 11 14:20:21 2018 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 4B63C130DC8; Fri, 10 Aug 2018 06:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 KrjgfrGLSsk8; Fri, 10 Aug 2018 06:21:07 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 0FB9112F18C; Fri, 10 Aug 2018 06:21:07 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id a26-v6so4537606pfo.4; Fri, 10 Aug 2018 06:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=U4F1tIhDiRvaOBANXGNlZCBnZC2NqNEhPPVLTj65RHg=; b=H/p8c2Gyucbh7V/DOeG2IepO4Q6sUp1K4ixFtl9czmjWglBGn+G6aQwPn3AEUTIgJs WmLnSKI0w8f2zY/5gwA//OUMvAsNOdgaDkSuQXizzPIb650U4WHqv9yTXnGfgbpQeXCE sh/p1SN2UONZlRk14WuCORuvXgbsVQGuhdX+6aypLjTVvAgkjfPN1gNfsWNyny+kLIJd snfGv3s2zWVRKY9pniVoT8TE8UaxXzHOTNnQv03HpVZ+eXkGnu2NWZ1k4xk2cNy22HNQ Eeqd1yupHvxvRDBM8u3IBEmLE0nUYyDJNxjsS1uKy4afcGz9v8PaHxqfva/w1FsHduUa 8Qpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=U4F1tIhDiRvaOBANXGNlZCBnZC2NqNEhPPVLTj65RHg=; b=qIJt4gXvcWla0yL+r/g7Witxz5wn9EiUxv8idbpLOlbtsFR7XOZgmbGE95Ic5coASf U6+51O2broO7SNrIX+++sX9+pLj4zrIcpeZl3K76UBCrMbi477oSd+LbJ1uwA7E9wQRL T6gr42ZWS1nZ2yth4DygxdV80ZturrV8EHLzBG/aP+RRFPmNt3tD1B8bBvrvpAEnWcq9 2nMFN8PvjzBlgqS5qABgGYqahs/EnMZJJCPRlxbeW1GSQhxkOAnOy3ZeTUA0d4aDA9E9 Nu0cpiHcDzs59t/cepF83iJoRY0ycNdENWDAB0v8whb7PVTfCnVWfFOPvByhCbI1lkHq Yv1A== X-Gm-Message-State: AOUpUlHJzymHtGvyqpJUyVhdNg7j41oAAXJVhyrYXCIVolpBevOFiTQu DVTXnpi6NtivnEQIGR73aG8= X-Google-Smtp-Source: AA+uWPzOM5exQxxljBUlu+NauC7vX90HFs0QfIJBqD0v7H2YP1uyHPe/aRpicFv2auHYBPLFx1X3dw== X-Received: by 2002:a62:1089:: with SMTP id 9-v6mr6956756pfq.30.1533907266493; Fri, 10 Aug 2018 06:21:06 -0700 (PDT) Received: from [192.168.0.109] ([122.167.129.176]) by smtp.gmail.com with ESMTPSA id b18-v6sm12610634pgk.15.2018.08.10.06.21.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Aug 2018 06:21:05 -0700 (PDT) To: rtg-ads@ietf.org Cc: rtg-dir@ietf.org, draft-ietf-sidrops-ov-clarify.all@ietf.org, sidrops@ietf.org, "dhruv.dhody@huawei.com" From: Dhruv Dhody Message-ID: <72ee1d70-d135-a445-75df-65df06fda61a@gmail.com> Date: Fri, 10 Aug 2018 18:51:02 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-Mailman-Approved-At: Sat, 11 Aug 2018 14:20:00 -0700 Subject: [Sidrops] RtgDir review: draft-ietf-sidrops-ov-clarify-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 10 Aug 2018 13:21:13 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​ http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-sidrops-ov-clarify-03 Reviewer: Dhruv Dhody Review Date: 10 Aug 2018 IETF LC End Date: Unknown Intended Status: Standards Track Summary:     I have some minor concerns about this document that I think should be     resolved before publication. Comments:     This is a standards track draft that clarifies the behavior of Origin     Validation in BGP (and thus updates RFC 6811). It states that the origin     validation MUST be done for all routes, including the imported routes; where     as the RFC 6811 uses "SHOULD". This I-D further states that the policy is     applied only if explicitly configured by the operator. The clarifications     are clear and easy to follow. The I-D is technically sound and almost ready. Major Issues:     No major issues found. Minor Issues:     - The text in RFC6811 uses the term “lookup” and “validation state”, the       clarification uses the term “mark”. This might be a bit pedantic but       wouldn’t it be better to state the clarification in terms of RFC6811?     - Since RFC4271 and RFC6480 are stated as mandatory reading to understand       this I-D in section 2, shouldn’t they be normative references?     - I agree with the Gen-ART review, that ask for BGP in the title, in fact     “Prefix Origin Validation” in the title would be better! Nits:     - Expand RPKI in Abstract.     - The Requirement language phrasing is little different from RFC 8174. Thanks! Dhruv From nobody Sat Aug 11 14:20:28 2018 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 6C7A2130F9A; Fri, 10 Aug 2018 11:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mGrZVnwu4Xqf; Fri, 10 Aug 2018 11:16:37 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 56FB6130F6D; Fri, 10 Aug 2018 11:16:37 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id d10-v6so3794934itj.5; Fri, 10 Aug 2018 11:16:37 -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=q/BWxvin3p3Jy7YvaSLBNa7we9k5sSNU9GtI+cUd1zY=; b=rGzWdjY1A5QqWkS9s8W0lWj0zlQ2KHYe58cZG2VcoMFClBj+aFp2Gb236sbJMNoQ0t nOxyBmuczUjuPmd905nvLA+a0ikzWNhIadFPXAVNmvTljFoGv37uhyVHHyvaFWCh4EKn X9VZ6HWzfgL7Jjs9FkakqlkhKBp2toBa4lsSco25jWY4FBqwufi+G8UyD+1hg+wnE1mv iYMBpP06kYQtAlYiNZ6sRhT8dZZfw+2LOeMu9NrTf7PjTnp6w7N9EYRYJGCA5or7lnON j3PiVmMSD2dT1agmtQS+7AruTsHZtYoR1rVxI27SpsokarAS9yscllpee/0s7LXrfioO 7w6g== 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=q/BWxvin3p3Jy7YvaSLBNa7we9k5sSNU9GtI+cUd1zY=; b=X33WO/zm5vvIZW/l2/8XHHeigYuPt0IPOO6AWUGZNSPpzs7MPPYSATHSY1n22Je3RC sO74f95dpL6yTddd0qNcRqMT3+6Z+8AoZ5O7pdcG1lRqecH/e++t7Fxv+tSsyktP3lyk +ri+LIT4F8Gq6mfjawiFmwn4Rl6CdMG9WA70X/mXOYIu2BQ8DqD0To7oBCsSRCBsoEsA hy3n4MXSIc5wycFc6MQZWxkrKpIRT1Bb4is1/y4KILvdUhSYsvYWupJgwiopp2hdhIK+ 1JBWc6DL8EhTihadxNZrTKPqHPQvNIYhDi9t+1W/cFw/tbg16vMHf8vvLPAAoDuAGRod rb4w== X-Gm-Message-State: AOUpUlE+n8ZVn3pZUkO/xqAQ0RL+PsVFYsb593ZxU/S2pl4D1KEwpIHI /qRKHW4gi9hhnoUISht4z1q5gHN9Xp+YGe97+iw= X-Google-Smtp-Source: AA+uWPwHKHszuY7AP/N18UlSTU96MxJKis04DjTtW1wbGrob+tqwQINtKuYuC7xTjzRFus0LgzTdEZmFWZsadXkYYdM= X-Received: by 2002:a24:643:: with SMTP id 64-v6mr3303893itv.109.1533924996334; Fri, 10 Aug 2018 11:16:36 -0700 (PDT) MIME-Version: 1.0 References: <72ee1d70-d135-a445-75df-65df06fda61a@gmail.com> In-Reply-To: From: Dhruv Dhody Date: Fri, 10 Aug 2018 23:46:24 +0530 Message-ID: To: Randy Bush Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-sidrops-ov-clarify.all@ietf.org, sidrops@ietf.org, Dhruv Dhody Content-Type: multipart/alternative; boundary="00000000000084ca8f057318beee" Archived-At: X-Mailman-Approved-At: Sat, 11 Aug 2018 14:20:00 -0700 Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-ov-clarify-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 10 Aug 2018 18:16:44 -0000 --00000000000084ca8f057318beee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Randy, Thanks for your reply. I am sorry that my email client did something weird with the formating! On Fri, Aug 10, 2018 at 10:51 PM Randy Bush wrote: > > > - Since RFC4271 and RFC6480 are stated as mandatory reading to > > understand > > this I-D in section 2, shouldn=E2=80=99t they be normative refere= nces? > > i will be interested in others' feedback on this one. i take normative > as needed to implement, not as needed to have clue :) > > I usually go by this IESG statement - https://www.ietf.org/blog/iesg-statement-normative-and-informative-referenc= es/; which says - "Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work." Just FYI i have pushed -04. i hope the diff does not cause heartburn to anyone. > > I saw these nits in the diff - OLD: When a route is distributed into BGP, the origin validation state of the is set to as NotFound, Valid, or Invalid per [RFC6811]. NEW: When a route is distributed into BGP, the origin validation state of the prefix is set to as NotFound, Valid, or Invalid as per [RFC6811]. -- s/evaluation state/validation state/ -- Thanks Again! Regards, Dhruv --00000000000084ca8f057318beee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Randy,=C2=A0

Thanks= for your reply. I am sorry that my email client did something weird with t= he formating!=C2=A0

On Fri, Aug 10, 2018 at 10:51 PM Randy = Bush <randy@psg.com> wrote:
> =C2=A0=C2=A0=C2=A0 - Since RFC4271 and RFC6480 are stated as mandatory= reading to
> understand
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this I-D in section 2, shouldn=E2=80=99= t they be normative references?

i will be interested in others' feedback on this one.=C2=A0 i take norm= ative
as needed to implement, not as needed to have clue :)


I usua= lly go by this IESG statement -=C2=A0https://www.ietf.org/b= log/iesg-statement-normative-and-informative-references/; which says - = "Normative references specify document= s that must be read to understand or implement the technology in the new RF= C, or whose technology must be present for the technology in the new RFC to= work."=C2=A0 Just FYI=C2=A0


= i have pushed -04.=C2=A0 i hope the diff does not cause heartburn to anyone= .


I saw = these nits in the diff -=C2=A0

OLD:<= /div>
=C2=A0 =C2=A0When a route is distributed into BGP, the origin validat= ion state of
=C2=A0 =C2=A0the is set to as NotFound, Valid, or= Invalid per [RFC6811].
NEW:
=C2=A0 =C2=A0When a = route is distributed into BGP, the origin validation state of
<= div class=3D"gmail_default" style=3D"">= =C2=A0 =C2=A0the prefix is set to as NotFound, Valid, or Invalid as per [RF= C6811].=C2=A0

--

s/evaluation state/validation state/=C2=A0=C2=A0=

--

Thanks Again!=C2=A0

Regards,<= /div>
Dhruv
--00000000000084ca8f057318beee-- From nobody Mon Aug 13 09:28:50 2018 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 39B8F130F66; Mon, 13 Aug 2018 09:28:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-sidrops-ov-clarify@ietf.org, Keyur Patel , sidrops-chairs@ietf.org, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153417772922.25136.14541516067329705285.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2018 09:28:49 -0700 Archived-At: Subject: [Sidrops] Alvaro Retana's Yes on draft-ietf-sidrops-ov-clarify-04: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 16:28:49 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-sidrops-ov-clarify-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the clarifications!! I have just a couple of comments: (1) §3: "...the router SHOULD use the AS of the router's BGP configuration". If not ambiguous, when would it be ok to not use the ASN from the local configuration? IOW, why SHOULD and not MUST? (2) §1: s/the origin validation state of the is set to as NotFound/the origin validation state is set to NotFound (3) [nit] The language in the Introduction is very tentative for a Standards Track document. For example: "This document attempts to clarify...The implementation issues seem not to be about how to validate...The issues seem to be ..." Either this document clarifies or it doesn't; IOW, this is not an attempt at clarification. Also, I'm sure the issues are known. From nobody Mon Aug 13 10:23:05 2018 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 D1A95130FA3; Mon, 13 Aug 2018 10:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 jl4AEfSwhs2i; Mon, 13 Aug 2018 10:22:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 94E27130E00; Mon, 13 Aug 2018 10:22:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fpGYQ-0004oV-5V; Mon, 13 Aug 2018 17:22:54 +0000 Date: Mon, 13 Aug 2018 12:22:53 -0500 Message-ID: From: Randy Bush To: Alvaro Retana Cc: "The IESG" , draft-ietf-sidrops-ov-clarify@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org In-Reply-To: <153417772922.25136.14541516067329705285.idtracker@ietfa.amsl.com> References: <153417772922.25136.14541516067329705285.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] Alvaro Retana's Yes on draft-ietf-sidrops-ov-clarify-04: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 13 Aug 2018 17:22:58 -0000 > (1) =A73: "...the router SHOULD use the AS of the router's BGP > configuration". If not ambiguous, when would it be ok to not use the > ASN from the local configuration? IOW, why SHOULD and not MUST? ok. hacked. > (2) =A71: s/the origin validation state of the is set to as NotFound/the > origin validation state is set to NotFound yep. someone already dinged me on this one > (3) [nit] The language in the Introduction is very tentative for a > Standards Track document. For example: "This document attempts to > clarify...The implementation issues seem not to be about how to > validate...The issues seem to be ..." Either this document clarifies > or it doesn't; IOW, this is not an attempt at clarification. i am willing to harden the language. but this would seem to need support in the wg. your call. > I'm sure the issues are known. well, not if you ask your account rep :) will not push -05 until a few more comments come in. thanks for the review! randy From nobody Mon Aug 13 15:04:19 2018 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 31357126F72; Mon, 13 Aug 2018 15:04:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-sidrops-ov-clarify@ietf.org, Keyur Patel , sidrops-chairs@ietf.org, keyur@arrcus.com, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153419785019.25045.6300199280712430764.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2018 15:04:10 -0700 Archived-At: Subject: [Sidrops] Adam Roach's No Objection on draft-ietf-sidrops-ov-clarify-04: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 22:04:10 -0000 Adam Roach has entered the following ballot position for draft-ietf-sidrops-ov-clarify-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this. I have only minor typographical nits to suggest changes for; these don't warrant a new version of the document (as I'm sure they'll be caught in RFC Editor review), but should probably be corrected if a new version of the document is produced prior to advancing it: --------------------------------------------------------------------------- Abstract: > document is meant to clarify possible misunderstandings causing those > mis-implementations; and thus updates RFC6811 by clarifying that all Nit: "...RFC 6811..." --------------------------------------------------------------------------- §1: > Deployment of RPKI-based BGP origin validation is hampered by, among > other things, vendor mis-implementations in two critical areas, which Nit: "...areas: which..." --------------------------------------------------------------------------- §3: > neighbors about propagation of Invalid routes. For this reason, > [RFC6811] says Nit: "...says:" From nobody Mon Aug 13 18:36:58 2018 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 8AE6A12D949; Mon, 13 Aug 2018 18:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ayfc_e7JL3ga; Mon, 13 Aug 2018 18:36:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 1B4D9124C04; Mon, 13 Aug 2018 18:36:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fpOGL-0006Q5-5v; Tue, 14 Aug 2018 01:36:45 +0000 Date: Mon, 13 Aug 2018 20:36:44 -0500 Message-ID: From: Randy Bush To: Adam Roach Cc: "The IESG" , draft-ietf-sidrops-ov-clarify@ietf.org, Keyur Patel , sidrops-chairs@ietf.org, sidrops@ietf.org In-Reply-To: <153419785019.25045.6300199280712430764.idtracker@ietfa.amsl.com> References: <153419785019.25045.6300199280712430764.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] Adam Roach's No Objection on draft-ietf-sidrops-ov-clarify-04: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 01:36:51 -0000 > Abstract: >=20 >> document is meant to clarify possible misunderstandings causing those >> mis-implementations; and thus updates RFC6811 by clarifying that all >=20 > Nit: "...RFC 6811..." >=20 > -------------------------------------------------------------------------= -- >=20 > =A71: >=20 >> Deployment of RPKI-based BGP origin validation is hampered by, among >> other things, vendor mis-implementations in two critical areas, which >=20 > Nit: "...areas: which..." >=20 > -------------------------------------------------------------------------= -- >=20 > =A73: >=20 >> neighbors about propagation of Invalid routes. For this reason, >> [RFC6811] says >=20 > Nit: "...says:" fixed in my emacs buffer thanks randy From nobody Wed Aug 15 13:19:19 2018 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 E7154130DE3; Wed, 15 Aug 2018 13:19:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-sidrops-ov-clarify@ietf.org, Keyur Patel , sidrops-chairs@ietf.org, keyur@arrcus.com, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153436435194.3126.15474608226715103626.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 13:19:11 -0700 Archived-At: Subject: [Sidrops] Ben Campbell's No Objection on draft-ietf-sidrops-ov-clarify-04: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 20:19:12 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidrops-ov-clarify-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Benjamin beat me to the comment about the RFC 8174 boilerplate. From nobody Fri Aug 17 08:46:04 2018 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 6242B130DF7; Wed, 15 Aug 2018 07:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=i/S7DEYz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fi/YL6/m 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 fhX8zre3Vy8N; Wed, 15 Aug 2018 07:15:10 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490F5130EAC; Wed, 15 Aug 2018 07:15:10 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 352A02F4; Wed, 15 Aug 2018 10:15:09 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 15 Aug 2018 10:15:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=/2A6L8KX7P84aVb7gVxPg9sTjj6gG VXdtDrRDx3Ru0I=; b=i/S7DEYziHud+Z1Cyvhjom6FmKtWHa0USz2PKXnwXgddW LpaPxSaBy/AgwBqO81sOAQoqM6Bw8D0Ay5k23FFZvqpDPVWiu4LIhXR6PwghrPZ7 T1rfPtE7P+vcoCON08poQG6kBjuwq4qevqie6oGpgUAhjbby2usK9drznczD1ZHw 9Vp0RB8NLnJgjBUVtpR/lXX3fxLmF+CiNq5b4wmJNMdf4Ro14zjUVpeMAXtHXUGx 9sxkQ4KQUtvbUMGRT3gOhS9DA0oZl8A8UpoHrSMOpdqFdIKH5EAR+cyicz5zONk2 DcMAHRbqMVG74vPC3gVRP/xOwEFDwD9IuG+I5w3KQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=/2A6L8 KX7P84aVb7gVxPg9sTjj6gGVXdtDrRDx3Ru0I=; b=fi/YL6/m4qs2R0ngT+F9vF 2rnPRAZY26WqyofHOxmvoDTjYObYye1czxhyWwwoTaZp3asIGp4cW2V47OICd0kR cucnVEtkip0Yi/a7mj79d1PHr6FIn6kytmuM07WjVwkxf1JefDZkOtDU0JqX3Eit m3u71jDXB6sFwM7aKjeFuV30w/zY8b+WlHca0a94HMMuJkq/enMvjyC1LxGiLnxF YfKGvtQY1KH4O7jMcYQNIL1dh+sXEqZR4KlIaixsa5PxgOZh+fAScDgDH9O/rTJD ku7fITQosi5ITpP4CFPc5Q642xhPyxqfoVWsmA+rbdSGU5HMMC/v0WhToZp27vyQ == X-ME-Proxy: X-ME-Sender: Received: from dhcp-10-150-9-145.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id C45F610268; Wed, 15 Aug 2018 10:15:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <8a0fc2dc-b5ae-ccf5-68c4-2284b5229c8b@gmail.com> Date: Wed, 15 Aug 2018 10:15:06 -0400 Cc: Randy Bush , draft-ietf-sidrops-ov-clarify.all@ietf.org, gen-art@ietf.org, sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <996D127C-00EE-4B5B-83A3-C587071A7B8B@cooperw.in> References: <153300071561.7755.6509769097582818893@ietfa.amsl.com> <8a0fc2dc-b5ae-ccf5-68c4-2284b5229c8b@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-Mailman-Approved-At: Fri, 17 Aug 2018 08:46:02 -0700 Subject: Re: [Sidrops] [Gen-art] Genart last call review of draft-ietf-sidrops-ov-clarify-03 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 15 Aug 2018 14:15:13 -0000 Brian, thanks for your review. Randy, thanks for your response. I = entered a No Objection ballot. Alissa > On Jul 30, 2018, at 10:09 PM, Brian E Carpenter = wrote: >=20 > On 31/07/2018 13:35, Randy Bush wrote: >> thanks for review! >>=20 >>> Title would be more searchworthy if it read "BGP-4 Origin Validation = Clarifications" >>=20 >> ok. how about "BGP-4 RPKI-Based Origin Validation Clarifications?" >=20 > Sure >=20 > Brian >=20 >>=20 >>> Abstract: s/\"/./ >>=20 >> whoopsie. >>=20 >> will keep new xml in in emacs buffer until all reviews are in >>=20 >> randy >>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Fri Aug 17 08:46:11 2018 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 06A8B130EF9; Thu, 16 Aug 2018 04:04:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux To: "The IESG" Cc: draft-ietf-sidrops-ov-clarify@ietf.org, Keyur Patel , sidrops-chairs@ietf.org, keyur@arrcus.com, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153441745402.8018.2853179859722118564.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2018 04:04:14 -0700 Archived-At: X-Mailman-Approved-At: Fri, 17 Aug 2018 08:46:02 -0700 Subject: [Sidrops] Martin Vigoureux's No Objection on draft-ietf-sidrops-ov-clarify-04: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 11:04:14 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-sidrops-ov-clarify-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this work. I only have an editorial comment: Isn't the word 'Route' missing between 'the' and 'is': When a route is distributed into BGP, the origin validation state of the is set to as NotFound, Valid, or Invalid per [RFC6811]. From nobody Mon Aug 20 11:56:02 2018 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 49C5E129619; Mon, 20 Aug 2018 11:55:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-sidrops-ov-clarify@ietf.org, keyur@arrcus.com, sidrops@ietf.org, Keyur Patel , sidrops-chairs@ietf.org, warren@kumari.net, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153479134629.23155.1280503772304049084.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2018 11:55:46 -0700 Archived-At: Subject: [Sidrops] Protocol Action: 'BGP RPKI-Based Origin Validation Clarifications' to Proposed Standard (draft-ietf-sidrops-ov-clarify-04.txt) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 18:55:47 -0000 The IESG has approved the following document: - 'BGP RPKI-Based Origin Validation Clarifications' (draft-ietf-sidrops-ov-clarify-04.txt) as Proposed Standard This document is the product of the SIDR Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ Technical Summary Deployment of RPKI-based BGP origin validation is hampered by, among other things, vendor mis-implementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those mis-implementations; and thus updates RFC6811 by clarifying that all prefixes should be marked, and that policy must not be applied without operator configuration" Working Group Summary From the Document Shepherd report: 'WG discussion was solid, fun and filled with non-tears.' :-) Document Quality The document is very clear and easy to understand, even for those unfamiliar with the technology. It simply clarifies things. Personnel Chris Morrow is the DS Warren Kumari is RAD! From nobody Mon Aug 20 12:23:54 2018 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 8B5A6128CF3; Mon, 20 Aug 2018 12:23:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <153479303352.23176.8136446004394107371@ietfa.amsl.com> Date: Mon, 20 Aug 2018 12:23:53 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-ov-clarify-05.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 19:23:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : BGP RPKI-Based Origin Validation Clarifications Author : Randy Bush Filename : draft-ietf-sidrops-ov-clarify-05.txt Pages : 4 Date : 2018-08-20 Abstract: Deployment of Resource Public Key Infrastructure (RPKI) based BGP origin validation is hampered by, among other things, vendor mis- implementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those mis-implementations; and thus updates RFC 6811 by clarifying that all prefixes should have their validation state set, and that policy must not be applied without operator configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-ov-clarify-05 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-ov-clarify-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-ov-clarify-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 20 22:39:42 2018 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 BD5A3130E2D; Mon, 20 Aug 2018 22:39:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <153482997567.23006.1887664144428558597@ietfa.amsl.com> Date: Mon, 20 Aug 2018 22:39:35 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rp-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 05:39:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties Authors : Di Ma Stephen Kent Filename : draft-ietf-sidrops-rp-02.txt Pages : 11 Date : 2018-08-20 Abstract: This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI) in the context of securing Internet routing. It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rp-02 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rp-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 20 23:33:53 2018 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 EC636130E5D for ; Mon, 20 Aug 2018 23:33: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BfQrXpF3uwi1 for ; Mon, 20 Aug 2018 23:33:46 -0700 (PDT) Received: from out20-111.mail.aliyun.com (out20-111.mail.aliyun.com [115.124.20.111]) (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 4B144130E2A for ; Mon, 20 Aug 2018 23:33:44 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.07705789|-1; CH=green; FP=0|0|0|0|0|-1|-1|-1; HT=e01l07440; MF=madi@rpstir.net; NM=1; PH=DS; RN=1; RT=1; SR=0; TI=SMTPD_---.Cgaprie_1534833214; Received: from 192.168.101.71(mailfrom:madi@rpstir.net fp:SMTPD_---.Cgaprie_1534833214) by smtp.aliyun-inc.com(10.147.40.26); Tue, 21 Aug 2018 14:33:35 +0800 From: Di Ma Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 21 Aug 2018 14:33:33 +0800 References: <153482997567.23006.1887664144428558597@ietfa.amsl.com> To: sidrops@ietf.org In-Reply-To: <153482997567.23006.1887664144428558597@ietfa.amsl.com> Message-Id: <13BFE109-9850-44F5-BAD7-FE29D8488899@rpstir.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rp-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 06:33:51 -0000 Hi, folks, We authors just updated the document =A1=AERequirements for RPKI Relying = Parties=A1=AF. Among others, we have updated the references, for some of them have been = published as RFCs, and moved all the BCP RFCs to Informative REF of this = draft.=20 And we have also added an emphasis that the context of this document is = to secure Internet routing, not for SEND (rfc 6494) We would appreciate your comments. Thanks. Di > =D4=DA 2018=C4=EA8=D4=C221=C8=D5=A3=AC13:39=A3=ACinternet-drafts@ietf.or= g =D0=B4=B5=C0=A3=BA >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the SIDR Operations WG of the IETF. >=20 > Title : Requirements for Resource Public Key = Infrastructure (RPKI) Relying Parties > Authors : Di Ma > Stephen Kent > Filename : draft-ietf-sidrops-rp-02.txt > Pages : 11 > Date : 2018-08-20 >=20 > Abstract: > This document provides a single reference point for requirements for > Relying Party (RP) software for use in the Resource Public Key > Infrastructure (RPKI) in the context of securing Internet routing. > It cites requirements that appear in several RPKI RFCs, making it > easier for implementers to become aware of these requirements that > are segmented with orthogonal functionalities. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-rp-02 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rp-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-rp-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Aug 21 12:41:56 2018 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 A3425130E67 for ; Tue, 21 Aug 2018 12:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.743 X-Spam-Level: X-Spam-Status: No, score=-0.743 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=1.164, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 qpSiVwKK-coW for ; Tue, 21 Aug 2018 12:41:53 -0700 (PDT) Received: from sonic303-28.consmr.mail.ne1.yahoo.com (sonic303-28.consmr.mail.ne1.yahoo.com [66.163.188.154]) (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 0BAD2130DF0 for ; Tue, 21 Aug 2018 12:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1534880512; bh=JmxltznB/akulYOWqjAj3tOARR1Mqfw+0pCTpI73Mc4=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=gC6A3/H43g9zd43JvMWCk1MlMTypo3dJpIvBFSJWCpKqfeMBGXF6qefywIEI/ywVMA2IQtVDTEPUNN7oTueQcP/jIMjjVeZ8pJ9YsG0YzDSj803jsxxuYfY95fZkBzls5ELMhF+g8uZGp8ZjAklRRVnoYaDN+en1c1htSY2+zmmy5PwkQf+8MP7Ca+Q2ibQUNGADvq3eXRI6qIsS27FglHXyqqUqwIV6qMAAkGU4Gg26Fx4Dy2SaTzklpMSGSemblxtei4zWODnKsyQ7HSapCQrPyrkyPnTBbLWITUAmus0Uo2ysNKqTOQoR2oAjELMtMR/5bOkysPGGmytFn7n52g== X-YMail-OSG: hvhn9rUVM1ly57BJQt6RcIRMva1qHEwOMqpMMHUKpMdvXgF04_PQmZ8Fc5AFJdP B4FeFb0_NHa3OLpGuDkjrRDFVOiXF5HO7RZ1S8skbJjq.CJbiAZo_JlHfLYYlESnOqM7XceEJTqL PJI5zJyzIgANbh3XldhFu_nuh6hKV2fw742YdPczHdTEXPXJ1aWpk2wXsCOKZ.iPhiNRJZmsoxF8 DCjHrxNSsBubwTEU_bZ0l3C5ZBAE860EuQOa5DcCjvzehnb7kTnFcdvnNcKLgyCF.4FlR8kNvacs ZdkXYQFCSu8ltsvVPBxeY6gCEyjC2HgLW_2gwkBiRBy5JUjWwOEFO.ZL7rUcXweH4JI50aBVYfxQ ZQRJUkJLYBbA3BbDtJ5P4dASI9i0IX2jMUaQmCeRwZs8hU6hnEFSgC5Hiq_OYfQiRlXLxAo_aFIC BQaJ5y8p0BRbIs.7n24g6vP8dd44GFc2_orcmNVLUkGBJEdZ6EbPB_5ErJqIaClBEI9RCp.JtbdV iUHR64uGzAc.raZQkcVzM4ZV9v0qCK6r2qa7MrUVSjn.s63rCbJvBpn5LsB4VxoC_jbSS08PeJHD m2JcrY._3boj2224HHFajRIyIQ3um8YU4sAjF3BkMs0DvvI0gCUE8U3FLTXMGjCdjFf8RXcgjY.4 9bziv1nG4LQZqejdPNpUoc3R2LBbZrcm5dwaDopvzFXTV0rP9UXXiw0Hz8dmbrl0JEMCpIQNkOo6 inYuOGN2GKDj0JAuflPCOwGP_4m9S6tN6kiJrakWvMRgJvYSHUilzO1wQeJyVt2QPAU3o1yDhdLN 9oaJZcXCCv80.NXIdlfbxNqlVve4WbkxFDCkmZJMQ63ur48Evcux7zMPkhPyxwBHqQdS_PxzKW6J ojBVJ_5Rq1ysyJaITWR45lBeQDwnj5IaRSQAfGCk6nkcylLGBIVHyE65Yo81vOBlkMgYDy9MSThi TsIUQRPslgyc_GRynD0n3OvTMf46VGzXpPL8SC2y_XtTdvY2xHiriYrh1bDtaclD_fEqLaaRWYTx 3_5gjXYLUABEFQNQ6hbnWb06cpg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Tue, 21 Aug 2018 19:41:52 +0000 Received: from 67.159.150.85 (EHLO [192.168.1.5]) ([67.159.150.85]) by smtp422.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 81df566fdbe19a32d7e89fbeba50de0e; Tue, 21 Aug 2018 19:41:50 +0000 (UTC) User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Tue, 21 Aug 2018 12:41:42 -0700 From: Mehmet Adalier To: Christopher Morrow , , , Message-ID: Thread-Topic: [Sidrops] WGLC: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis - ends 20-Aug-2018 References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3617700110_110039559" Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis - ends 20-Aug-2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 19:41:55 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3617700110_110039559 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit As an implementer of BGPsec, I believe that this document is ready to be forwarded to publication. Mehmet Adalier Antara Teknik LLC From: Sidrops on behalf of Christopher Morrow Date: Monday, August 6, 2018 at 8:59 PM To: , , Subject: [Sidrops] WGLC: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis - ends 20-Aug-2018 Howdy WG Folken! Let's discuss the document: https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/ which has an abstract saying: "This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Special-Use Algorithm IDs and correcting the range of unassigned algorithms IDs to fill the complete range. This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures." Let's see if there are any items still to address here, and if not move this forward to publication. Last Call ends 20-aug-2018! thanks! -chris co-chair#2 _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://www.ietf.org/mailman/listinfo/sidrops --B_3617700110_110039559 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

As an implementer of BGPsec, I believe that this d= ocument is ready to be forwarded to publication.

 

Mehmet Adalier

<= p class=3DMsoNormal>Antara Teknik LLC

&n= bsp;

From: Sidrops= <sidrops-bounces@ietf.org> on behalf of Christopher Morrow <christ= opher.morrow@gmail.com>
Date: Monday, August 6, 2018 at 8:59 PM=
To: <sidrops@ietf.org>, <sidrops-chairs@ietf.org>, &l= t;sidrops-ads@ietf.org>
Subject: [Sidrops] WGLC: draft-ietf-sid= rops-bgpsec-algs-rfc8208-bis - ends 20-Aug-2018

<= div>

 

Ho= wdy WG Folken!
Let's discuss the document:
  https://d= atatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/
<= br>which has an abstract saying:
  "This document specifies the= algorithms, algorithm parameters,
   asymmetric key formats, a= symmetric key sizes, and signature formats
   used in BGPsec (B= order Gateway Protocol Security).  This document
   update= s RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature
  &n= bsp;Formats") by adding Special-Use Algorithm IDs and correcting the   range of unassigned algorithms IDs to fill the complete range.=

   This document also includes example BGPsec UPDATE messa= ges as well as
   the private keys used to generate the message= s and the certificates
   necessary to validate those signature= s."

 

Let's see if there are any items still to address here= , and if not move this forward to publication.

 

Last Call = ends 20-aug-2018!

 

thanks!

-chris

co-chair#2

________________________________= _______________ Sidrops mailing list Sidrops@ietf.org https://www.ietf.org/m= ailman/listinfo/sidrops

--B_3617700110_110039559-- From nobody Tue Aug 21 16:29:42 2018 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 E4EF5130F2A; Tue, 21 Aug 2018 16:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHkqTAiOPiCI; Tue, 21 Aug 2018 16:29:23 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd01::714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9003D130F5B; Tue, 21 Aug 2018 16:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XW4xAOj0n0LgVWL+eouzo1Rssvjnd2dW4fwajeenqT8=; b=HiYHz70XiI5uL47F/bQYBj/ylWXGwgme52stVMIYk4T7EmR/57/joddT1UZ8PKFEUJrliWGo5x6Y7I05YFzH3ruKUwPyoqo5o63QYyehAzX4FNll5QmluDWmV8lLH2ZJRK56d23h0bCy7cRMl3hkOEFFV4SNRh4Sivljh8vedXA= Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2368.namprd09.prod.outlook.com (52.132.116.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.21; Tue, 21 Aug 2018 23:29:21 +0000 Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::45c3:3d6:90f1:55d9]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::45c3:3d6:90f1:55d9%4]) with mapi id 15.20.1059.023; Tue, 21 Aug 2018 23:29:21 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "sidrops@ietf.org" CC: "sidrops-chairs@ietf.org" , "Borchert, Oliver (Fed)" , Sean Turner Thread-Topic: [Sidrops] WGLC: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis - ends 20-Aug-2018 Thread-Index: AQHUOaWEMFl1y2C5qUaChhCfFmfBLw== Date: Tue, 21 Aug 2018 23:29:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [74.213.254.196] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR0901MB2368; 6:kXl+ghgoEEz6Qm9A4tSfkYk9GGJTxiNRoqFQWUSAHxxht2HJyWaQt32nzz5c6OOhL5TEYyqxpO8sMuQ8qTAK2WJycLVTwgLRw7WPXRljCzxM7KDxq54PwD4UM0jf7UH5q+ta2EW/JOF3+LIATxCgbF5L8FGpw5W+Y/g531h9QlKJGMRSS83CruYyZCNtP03is4O3UO/hoRL260QQLu18csyvwGbr7hzhteww23wuxy3rusenlCKh3PYBu6NkLZ2K7ryQhp1Dxi8AFW064dntLeaoRu52bmTbKCy5Xb7b1khXlAleyqPttWCm4EIBj20u42rUJJB3UvmwzPXTbMcCFWOa8FZbdquDXVJCEP0/R4XZpHNyjiCBcswSszZ6dDOTwCMWeRQRQHFc7xWRzjWsg58lxyzHVv7kgE+Q+S1rbetaALOmQQGQ1kKMjt3A//X7mAtYnyVfrduGQQPBq08vLg==; 5:7ib2KYWscMA4DXSzmD9GuoneUbadtN3zQUl+zjLMeKALXeMHgwvJ5KyYttt4uAIO/E11N6uTwMrxl8fblXB7LulLKmihP2Zzq8HCB5SP/gUfe11y/becRHHy4lgT9Q1o252IdEBY6ct976gEhcP1AlK9oeexpmjAwxjkj2OjAt4=; 7:+1jNLONjunWeijnTyzxI+0a6bUqGQsxxSAKafVWCi3Og6YpPNYQF4OesNnKMblL5GFecbg/dNfnqYgBvAPjqC8ew5Ruay20Un8gwFxVxYGKnCU2x94cLmzytNhSTMHO+uyprdzvj9E+1IX9fI0ShwY9LDhrETzGR3oWhd++T15HLHWkxBeKYCEd/3eJJp/C0uGNYkDM63yUDW75uybMsI/jMpB0iK2922qK02eTC6+THDCffKOzU4CDNsQaS+Ih7 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 83066446-aa8d-4e60-6487-08d607bdec90 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2368; x-ms-traffictypediagnostic: SN6PR0901MB2368: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(823301075)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(201708071742011)(7699016); SRVR:SN6PR0901MB2368; BCL:0; PCL:0; RULEID:; SRVR:SN6PR0901MB2368; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(39860400002)(376002)(366004)(396003)(199004)(189003)(3846002)(8936002)(66066001)(81156014)(6116002)(26005)(81166006)(33656002)(1730700003)(97736004)(102836004)(86362001)(74316002)(305945005)(316002)(486006)(7696005)(5660300001)(8676002)(53546011)(2900100001)(54906003)(186003)(6506007)(229853002)(53936002)(7736002)(6246003)(966005)(9686003)(14444005)(476003)(256004)(99286004)(68736007)(2351001)(5250100002)(25786009)(105586002)(2501003)(478600001)(6436002)(106356001)(55016002)(2906002)(5640700003)(6916009)(4326008)(14454004)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2368; H:SN6PR0901MB2366.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: iL3zGOp2eYc4UoDGfTTqMQzkGcdSrF5u2Am8k6rJL0gtWh6uaUguCdVrKGebuqClRZXrqJmgLZ2FjBzxOBPz2MueNAOWSRhP1WokuClvoelXMAF4zgp28bk55RtTK6lXHrThH/UlnHpXhxTOuH1RTIiRmZYk0nS2F46ztYmZ3zEk9jNr+vESbAfphVQpCuHbJUwFJmUt7qyHr2dUq3E7eRityfUxIcAcjj2BoA1wCqqZCpHy+C8Nwx0C1ZpMdQH0Vp0GyZhwQDEVmJlzC+WKNkkNLRt2IWr4JwdfwmQOq0/Rf0le57/FmRr531flIRfsOn4QBWBVmbi/5QXjXHFzf6vQoJXGyEkWCWrFeqGWZlk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 83066446-aa8d-4e60-6487-08d607bdec90 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2018 23:29:21.7665 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0901MB2368 Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis - ends 20-Aug-2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 23:29:40 -0000 I support the publication of this draft. I have reread the draft carefully. It is well written.=20 Makes important and essential additions and corrections to RFC 8208. I found a few typos and minor edits which I have communicated to the author= s. Sriram ---------------------------------------------------------------------------= --------------------------------- From: Sidrops on behalf of Christopher Morrow= Date: Monday, August 6, 2018 at 8:59 PM To: , , Subject: [Sidrops] WGLC: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis - ends = 20-Aug-2018 Howdy WG Folken! Let's discuss the document: https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-b= is/ which has an abstract saying: "This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Special-Use Algorithm IDs and correcting the range of unassigned algorithms IDs to fill the complete range. This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures." Let's see if there are any items still to address here, and if not move thi= s forward to publication. Last Call ends 20-aug-2018! thanks! -chris co-chair#2= From nobody Wed Aug 22 07:52:17 2018 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 49834130E0F; Wed, 22 Aug 2018 07:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 099XDgqF0O2F; Wed, 22 Aug 2018 07:52:14 -0700 (PDT) Received: from mail-ua1-x943.google.com (mail-ua1-x943.google.com [IPv6:2607:f8b0:4864:20::943]) (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 AF809127333; Wed, 22 Aug 2018 07:52:14 -0700 (PDT) Received: by mail-ua1-x943.google.com with SMTP id o11-v6so1215598uak.5; Wed, 22 Aug 2018 07:52:14 -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=kfxcpMdldVLQU6rOsJqQQjLA3mSaO60MmPiirmfOYho=; b=UW4w0K3M4fbBbrxo34V90w2gCkuTTluspqf1dBfNog8pTJMvyKon1YbAG13o6zZU84 jHDfMlAZqp5YqnTaCACDykNRo1eCm73o3Tocp7phHE/11jbvgx5Vcnmk/omH1ZVTDh7V EEhaW740nKC5R0QUqiZ6jykw7j3L3Bnmc8Gj1eagmf4leHHsMrmTJ9JdYjbhZabatlYv 8s/ucZ0tCtpMTYPZXqYizHSJ5rRrPuhTZ9UTWdIttDYUq5xKadgF1VnAc+qDSaONaGXb e8rAS+VOL13FpKhpP8KrC7dQcprxGoNw9gOprMCW85/M9Ds836ly8oh3mud0sR/QeUyb sHiA== 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=kfxcpMdldVLQU6rOsJqQQjLA3mSaO60MmPiirmfOYho=; b=DIkK4q1Mwpy91216W8qLcC1j47EW3nkXQH3KD7KEAxtvjw4DahxfbaOzWH/TcoH4nC 3WnVmTrBjqmr4v1oR4XqNAr7UZUTwfHR+NyHdFk0Njw6/ROgkL6HRInGtXV5+OmG/Y+6 el6hFNwAONM2JNpXh3g1n7VPH2OOuYMbrlnIKiPyjeGk1lCMUWhe9dh8omZa7+YG1jbF KW7MctEK4LJPvr6wuvo2nDJAbC+p5JwDx9mHQhbqsg1NuLZYgLZyBym3Khzyw9At5kCG y0zLNZMButU7cwNfDY1c3qyP26sXIcj7BJrg/eFd5r3uC0fq8ro8I783Kgo2gDaRkUuP Bhbw== X-Gm-Message-State: AOUpUlGdaVkBLXnMhX5G/sEDi2AbhJfho45O3r1DgRSUvEaCTl/jW6HH /YT9dSv4El8PajQqWOQq2JTbjIq2vMj/xZ7k5HIkkigG X-Google-Smtp-Source: AA+uWPxzC32ir2A8n/UDzhOnk2FVJyOU/wAU7DHvu3m1UVt57+qyGZWjGY55oCzRYW73lsQEDpKOSaCeBQ4hgC9LPz8= X-Received: by 2002:ab0:502:: with SMTP id 2-v6mr35103484uax.51.1534949533365; Wed, 22 Aug 2018 07:52:13 -0700 (PDT) MIME-Version: 1.0 From: Christopher Morrow Date: Wed, 22 Aug 2018 10:52:02 -0400 Message-ID: To: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org Content-Type: multipart/alternative; boundary="000000000000af3b7f0574074921" Archived-At: Subject: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 14:52:16 -0000 --000000000000af3b7f0574074921 Content-Type: text/plain; charset="UTF-8" Howdy WG folk! The authors of: draft-ietf-sidrops-validating-bgp-speaker are thinking their draft is ready to move forward, there hasn't been significant conversation about this document since the last meeting in Montreal... so: Draft Abstract: "This document defines a new BGP transitive extended community, as well as its usage, to signal prefix origin validation results from an RPKI Origin validating BGP speaker to other BGP peers. Upon reception of prefix origin validation results, peers can use this information in their local routing decision process." Can we read/think/discuss this for the next ~2wks and decide if it's in shape for movement forward in the sausage factory which is the IETF? :) thanks! -chris co-chair --000000000000af3b7f0574074921 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy WG folk!
The authors of: draft-ietf-sidrops-vali= dating-bgp-speaker
are thinking their draft is ready to move forw= ard, there hasn't been significant conversation about this document sin= ce the last meeting in Montreal... so:

Draft Abstract:
=C2=A0 &qu= ot;This document defines a new BGP transitive extended community, as
<= div>=C2=A0 =C2=A0well as its usage, to signal prefix origin validation resu= lts from an
=C2=A0 =C2=A0RPKI Origin validating BGP speaker to ot= her BGP peers.=C2=A0 Upon
=C2=A0 =C2=A0reception of prefix origin= validation results, peers can use this
=C2=A0 =C2=A0information = in their local routing decision process."

Can= we read/think/discuss this for the next ~2wks and decide if it's in sh= ape for movement forward in the sausage factory which is the IETF? :)
=

thanks!
-chris
co-chair
--000000000000af3b7f0574074921-- From nobody Wed Aug 22 08:30:18 2018 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 EDF51130E5D; Wed, 22 Aug 2018 08:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zVzQuHu5a4PS; Wed, 22 Aug 2018 08:30:14 -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 821C9130E17; Wed, 22 Aug 2018 08:30:14 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id w7MFUAVJ076548 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2018 16:30:10 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Christopher Morrow Cc: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org References: From: Nick Hilliard Message-ID: Date: Wed, 22 Aug 2018 16:30:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.1 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] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 15:30:17 -0000 Christopher Morrow wrote on 22/08/2018 15:52: > Howdy WG folk! > The authors of: draft-ietf-sidrops-validating-bgp-speaker > are thinking their draft is ready to move forward, there hasn't been > significant conversation about this document since the last meeting in > Montreal... so: the issues brought up last feb have not been addressed: > https://mailarchive.ietf.org/arch/msg/sidrops/YV1WfoxQNiwfOjtKIY1d6YJjRxM Unfortunately, most of the issues discussed in this email are intrinsic to the core ideas of the draft, i.e. unclear whether it's possible to fix them :-( Nick From nobody Wed Aug 22 09:16:04 2018 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 CD5F012D7F8 for ; Wed, 22 Aug 2018 09:16:01 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI0PyGpbvJbF for ; Wed, 22 Aug 2018 09:15:57 -0700 (PDT) Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) (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 9E45B130DC5 for ; Wed, 22 Aug 2018 09:15:54 -0700 (PDT) Received: by mail-ed1-f67.google.com with SMTP id e19-v6so1737486edq.7 for ; Wed, 22 Aug 2018 09:15:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=9nxseYw+el/HLzIC9ptTyZX6fb1TdKo65/EOZPR2Tp0=; b=EkbiuMY6r3ZGxPqNvPPTKkrEULVQ6trSpUxdw2VesM9zxX4hK5c/GW6qgEFK6ynCUE uIn6cdZNXib3KwJvSuZELbFXg9Xg5ebBFD3qhcpEGArVlPcmMntr6ZGtCYOGt+J20nfk ZE4A3hBTd0lWiSFxRMe53m+UGkJDlYJ3V1ob+9sxEUrE+7NqPrkSwurFJlCLBKflsdLr q/Mi+6JZhr7z8lgP2Mh05N6dfWTPKwO4zvSW793cQMdCP9Fr+LDlg4jfyZhDnHtdUbQd G7CowvHoljjhzdnO3mddL9+TJxm8vaZ9XnhrKIk7LRLkeuwRYtbF6FGvaZtYycgKlPgY TxBw== X-Gm-Message-State: AOUpUlFgEw+7xab3lxYWHkB2zWcXLKOFA4anNNEBrl8RSteJX4fRCSuk HMRziAqUGMK/VruTrx27O0wIlg== X-Google-Smtp-Source: AA+uWPwNub/aDpra+kGfIhV+NDuynczhaQdIxZ8rsmlqhK5W/M7IFmXjrfeN2f/8Uly639rDmDHdqQ== X-Received: by 2002:a50:8f66:: with SMTP id 93-v6mr65511489edy.248.1534954552869; Wed, 22 Aug 2018 09:15:52 -0700 (PDT) Received: from localhost (hanna.meerval.net. [192.147.168.57]) by smtp.gmail.com with ESMTPSA id u3-v6sm912820edo.44.2018.08.22.09.15.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 09:15:51 -0700 (PDT) Date: Wed, 22 Aug 2018 18:15:49 +0200 From: Job Snijders To: Christopher Morrow Cc: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org Message-ID: <20180822161549.GA1021@hanna.meerval.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 16:16:02 -0000 On Wed, Aug 22, 2018 at 10:52:02AM -0400, Christopher Morrow wrote: > The authors of: draft-ietf-sidrops-validating-bgp-speaker are thinking > their draft is ready to move forward, there hasn't been significant > conversation about this document since the last meeting in Montreal... > so: > > Draft Abstract: > "This document defines a new BGP transitive extended community, as > well as its usage, to signal prefix origin validation results from an > RPKI Origin validating BGP speaker to other BGP peers. Upon > reception of prefix origin validation results, peers can use this > information in their local routing decision process." > > Can we read/think/discuss this for the next ~2wks and decide if it's > in shape for movement forward in the sausage factory which is the > IETF? :) I have reviewed the document (and also have reviewed draft-ietf-sidrops-route-server-rpki-light, and before that draft-ietf-sidr-route-server-rpki-light). I see a number of issues. In summary I'd rather see IETF focus its energy on promotion of "invalid == reject" at EBGP boundaries at both IXPs and ISPs rather than spend time on standardising this method. 1/ I think it is counter productive to propagate RPKI Invalid routes from one BGP domain to another BGP domain (aka across EBGP boundaries) under the premise "but we clearly labeled the route hijack with a transitive extended community!". The approach does nothing to dampen the negative effects of BGP hijacks or misconfigurations. 2/ Within the context of signaling within a single BGP domain there already is RFC 8097. I can't really see a justification to standardise the behavior and code-points described in draft-ietf-sidrops-validating-bgp-speaker. RFC 8097's design property so that the state communities cannot propagate outside the BGP domain are considered a characteristic of robustness and were a conscious decision as far as I understand. 3/ The first sentence of the document is opiniated and doesn't seen anchored in reality: "RPKI-based prefix origin validation [RFC6480] can be a significant operational burden for BGP peers to implement and adopt." Some anecdata: I have experience enabling RPKI origin validation in quite some ISPs and IXPs, and either the deployment is easy (thus draft-ietf-sidrops-validating-bgp-speaker is not needed), or the deployment is a burden by factors unrelated to what is described in draft-ietf-sidrops-validating-bgp-speaker. I've not encountered any situation where draft-ietf-sidrops-validating-bgp-speaker would make RPKI adoption any easier. 4/ Section 2 "EBGP Prefix Origin Validation Extended Community" describes new transitive extended communities, but not all BGP implementations support defining & matching arbitrary new extended communities. If the argument is that using new extended communities can help deploy origin validation on BGP speakers that don't have support for RFC 6810/8210; I don't believe that can be the case. By the time such implementations have been updated to support draft-ietf-sidrops-validating-bgp-speaker, chances are the platform will support actual Origin Validation and this kludge won't add value. 5/ As is well known in the operational community, "Simple Tagging" and "Prioritizing and Tagging" as described in section 3 do nothing for Internet's routing security posture. Fiddling with LOCAL_PREF is useless in the context of more-specific announcements. "Simply Tagging" is useless because the 'validating bgp speaker' is shifting the responsiblity of rejecting RPKI Invalid routes to the EBGP peer, who may or may not be able to act on this information. 6/ No explaination is offered why using locally significant BGP communities is not adequate. When locally significant communities are used, at least the operator of the 'validating bgp speaker' that is proapgating RPKI invalid routes knows the receipient took the effort to read and try to understand the implications of this insecure approach. The authors have already confirmed that they use locally significant communities today at their IXPs, and it appears this works fine. 7/ Section 7 'security considerations' is full of holes. The sentence "Therefore, a validating BGP speaker could be misused to spread malicious prefix origin validation results." should be rewritten to "Therefore, all BGP speakers can be misused to spread adversarial origin validation results. Peers have no method to reliably establish whether it was a validating BGP speaker that attached the EBGP Prefix Origin Validation Extended Community, or an adversery." 8/ Furthermore in section 7, it is stated: "AS operators SHOULD provide out-of-band means for peers to ensure that the ROA validation process has not been compromised or corrupted." but the document provides no guidance on how such an external ROA validation process can be used. There is no verifyable untainted end-to-end chain of custody. Amongst other issues related to CoC, BGP communities are not cryptographically signed or verifiable, so there is no way anyone, ever, can trust the validation results from a so called 'validating speaker'. 9/ The "While being under DDoS attacks" paragraph is entirely out of scope for this document. 10/ Since the document promotes propagating RPKI Invalid routes instead of rejecting those invalid announcements, (section 3 "A validating BGP speaker MUST support the Simple Tagging operation mode. Other modes of operation are OPTIONAL."). I think this approach is a disservice to the global community. Our organisation (NTT) is creating RPKI ROAs for its IP resources with the understanding that the RPKI is a method to globally publish what BGP Origin ASNs NTT authorised and what prefix lengths can be expected. We did not publish ROAs with the understanding that RPKI Invalid announcements (hijacks, misconfigurations) will merely be tagged with a BGP community and propagated. Kind regards, Job From nobody Wed Aug 22 19:20:46 2018 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 D774A130DCC for ; Wed, 22 Aug 2018 19:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 nc_440JUJXD1 for ; Wed, 22 Aug 2018 19:20:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 14978128C65 for ; Wed, 22 Aug 2018 19:20:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fsfEi-0001ix-KO; Thu, 23 Aug 2018 02:20:36 +0000 Date: Wed, 22 Aug 2018 19:20:36 -0700 Message-ID: From: Randy Bush To: Job Snijders Cc: SIDR Operations WG In-Reply-To: <20180822161549.GA1021@hanna.meerval.net> References: <20180822161549.GA1021@hanna.meerval.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.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] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 23 Aug 2018 02:20:43 -0000 > I have reviewed the document (and also have reviewed > draft-ietf-sidrops-route-server-rpki-light, and before that > draft-ietf-sidr-route-server-rpki-light). I see a number of issues. In > summary I'd rather see IETF focus its energy on promotion of "invalid > == reject" at EBGP boundaries at both IXPs and ISPs rather than spend > time on standardising this method. while i agree that deployment of origin validation is good and important work, imiho it is quite orthogonal to this draft. i.e. red herring alert. otoh, i have to agree with nick that there are serious problems with it, and appreciate his pointing them out. randy From nobody Fri Aug 24 07:33:10 2018 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 C342612D7EA for ; Fri, 24 Aug 2018 07:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 VhKKtja4xfNE for ; Fri, 24 Aug 2018 07:33:05 -0700 (PDT) Received: from de-cix.net (relay4.de-cix.net [46.31.121.24]) (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 2E035128CB7 for ; Fri, 24 Aug 2018 07:33:04 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.53,281,1531778400"; d="p7s'?scan'208"; a="2279731" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw014.de-cix.net with ESMTP; 24 Aug 2018 16:33:03 +0200 Received: from MS-EXCHANGE.for-the-inter.net (MS-EXCHANGE.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id CEC18B00B8 for ; Fri, 24 Aug 2018 16:33:02 +0200 (CEST) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 24 Aug 2018 16:33:02 +0200 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1367.000; Fri, 24 Aug 2018 16:33:02 +0200 From: Daniel Kopp To: SIDR Operations WG Thread-Topic: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 Thread-Index: AQHUOie94b+qhBJXv0aVQvhLDzuGmaTL0PCAgAMH8YA= Date: Fri, 24 Aug 2018 14:33:02 +0000 Message-ID: <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> References: <20180822161549.GA1021@hanna.meerval.net> In-Reply-To: <20180822161549.GA1021@hanna.meerval.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.6.18) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.141.121] Content-Type: multipart/signed; boundary="Apple-Mail=_1EA96B0F-55C8-4FA3-82A8-EA59FD1E9B94"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 24 Aug 2018 14:33:09 -0000 --Apple-Mail=_1EA96B0F-55C8-4FA3-82A8-EA59FD1E9B94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would like to give some feedback from the draft side. The draft was initialised from a meeting of a group of network operators = at an IXP around three years ago. As I remember, they told us that their routers are not capable of = performing RPKI validation,=20 a mechanism to tag routes from the route server would help them using = RPKI.=20 =46rom this, a group people from AMS-IX, DE-CIX and France-IX joined to = build this draft to find a unified way to do this at IXPs. I feel like this idea got lost on its way. By no means the draft is there to weaken or make people to replace = stronger security mechanisms.=20 It's should be there for those who can't perform RPKI origin validation = at an IXP by themselves. To give an answer to the latest arguments that Job brought up: 1/ & 2/=20 The idea was to use this mechanism in a "trusted=E2=80=9D environment at = an IXP from a route server.=20 We don't want the validation results to propagate beyond the IXP domain.=20= =46rom the technical discussions we had to generalize the draft to fit = the EBGP world.=20 There was a discussion with RFC 8097 to incorporate our needs, but the = decision was made to build an separate draft.=20 3/=20 Around 20 network operators met at DE-CIX on 12/2015.=20 They asked for what we are trying to accomplish here with this draft. Here are some of the comments from the operators when the idea was born: - The AS does not have to be in the BGP community - Well-known community should be defined - Extended community should be used in combination with a = non-transitive flag - It is expressed that DE-CIX is getting involved in standardisation 4/=20 Having new transitive communities was implemented from the discussion on = the mailing list.=20 But it's true, if routes don't support it, it doesn't help anybody in = addition to RFC 6810/8210.=20 So if this is the case, we should change this again. 5/=20 We describe different modes of operation to provide more opportunities = for the implementation at different IXPs (companies). Most important for the draft was, that we have a common mechanism on the = signaling.=20 With the modes, the idea was that different IXPs can decide on how = strict they wan't the "filtering" to be.=20 This might help in the adoption for IXP networks. 6/=20 Yes, we don't have an explanation why we don't use locally significant = BGP communities, thats true.=20 In technical aspects we already discussed and then included some of the = ideas,=20 but if other technical implementations are a better fit, we are open to = change them.=20 So you would propose local communities? 7/=20 The idea of the draft was to signal RPKI at an IXP from the route = server, not to be implemented globally on "all" routers.=20 We should discuss any tangible consideration and add them or rework the = security consideration section. 8/ "AS operators SHOULD provide out-of-band means for peers to ensure that the ROA validation process has not been compromised or corrupted." It's not the aim of the draft to provide cryptographic soundness over = BGP.=20 The message of that section should be that IXP operators have to ensure = that the validation process on their side is not compromised,=20 and provide an out-of-band indicator to the peers that the validation = process is not corrupted at the IXP side. =20 9/=20 Network operators often announce /32 prefixes when they use blackholing = for DDoS mitigation... this is just something to consider when using = RPKI and blackholing at IXPs.=20 10/=20 As said before, we wanted to have different modes of operation at = different IXPs.=20 Dropping invalids by default at the route server is an option,=20 if IXP operators and their networks a ready for it they are more then = welcome to do it. The initial idea for the draft came from network operators at IXPs. The idea of the draft is to help with the adoption of RPKI in the domain = of IXPs. The idea draft is not a replacement for RPKI validation or a global = distribution of RPKI validation results. The draft is there to help at IXPs till we all drop invalids by default = :) Best regards, Daniel > On 22. Aug 2018, at 18:15, Job Snijders wrote: >=20 > I have reviewed the document (and also have reviewed = draft-ietf-sidrops-route-server-rpki-light, > and before that draft-ietf-sidr-route-server-rpki-light). I see a = number > of issues. In summary I'd rather see IETF focus its energy on = promotion > of "invalid =3D=3D reject" at EBGP boundaries at both IXPs and ISPs = rather > than spend time on standardising this method. >=20 > 1/ I think it is counter productive to propagate RPKI Invalid routes > from one BGP domain to another BGP domain (aka across EBGP boundaries) > under the premise "but we clearly labeled the route hijack with a > transitive extended community!". The approach does nothing to dampen = the > negative effects of BGP hijacks or misconfigurations. >=20 > 2/ Within the context of signaling within a single BGP domain there > already is RFC 8097. I can't really see a justification to standardise > the behavior and code-points described in = draft-ietf-sidrops-validating-bgp-speaker. > RFC 8097's design property so that the state communities cannot > propagate outside the BGP domain are considered a characteristic of > robustness and were a conscious decision as far as I understand. >=20 > 3/ The first sentence of the document is opiniated and doesn't seen > anchored in reality: "RPKI-based prefix origin validation [RFC6480] = can > be a significant operational burden for BGP peers to implement and > adopt." >=20 > Some anecdata: I have experience enabling RPKI origin validation in > quite some ISPs and IXPs, and either the deployment is easy (thus > draft-ietf-sidrops-validating-bgp-speaker is not needed), or the > deployment is a burden by factors unrelated to what is described in > draft-ietf-sidrops-validating-bgp-speaker. I've not encountered any > situation where draft-ietf-sidrops-validating-bgp-speaker would make > RPKI adoption any easier. >=20 > 4/ Section 2 "EBGP Prefix Origin Validation Extended Community" > describes new transitive extended communities, but not all BGP > implementations support defining & matching arbitrary new extended > communities. If the argument is that using new extended communities = can > help deploy origin validation on BGP speakers that don't have support > for RFC 6810/8210; I don't believe that can be the case. By the time > such implementations have been updated to support > draft-ietf-sidrops-validating-bgp-speaker, chances are the platform = will > support actual Origin Validation and this kludge won't add value. >=20 > 5/ As is well known in the operational community, "Simple Tagging" and > "Prioritizing and Tagging" as described in section 3 do nothing for > Internet's routing security posture. Fiddling with LOCAL_PREF is = useless > in the context of more-specific announcements. "Simply Tagging" is > useless because the 'validating bgp speaker' is shifting the > responsiblity of rejecting RPKI Invalid routes to the EBGP peer, who = may > or may not be able to act on this information. >=20 > 6/ No explaination is offered why using locally significant BGP > communities is not adequate. When locally significant communities are > used, at least the operator of the 'validating bgp speaker' that is > proapgating RPKI invalid routes knows the receipient took the effort = to > read and try to understand the implications of this insecure approach. > The authors have already confirmed that they use locally significant > communities today at their IXPs, and it appears this works fine. >=20 > 7/ Section 7 'security considerations' is full of holes. The sentence > "Therefore, a validating BGP speaker could be misused to spread > malicious prefix origin validation results." should be rewritten to >=20 > "Therefore, all BGP speakers can be misused to spread adversarial > origin validation results. Peers have no method to reliably > establish whether it was a validating BGP speaker that attached the > EBGP Prefix Origin Validation Extended Community, or an adversery." >=20 > 8/ Furthermore in section 7, it is stated: "AS operators SHOULD = provide > out-of-band means for peers to ensure that the ROA validation process > has not been compromised or corrupted." but the document provides no > guidance on how such an external ROA validation process can be used. > There is no verifyable untainted end-to-end chain of custody. Amongst > other issues related to CoC, BGP communities are not cryptographically > signed or verifiable, so there is no way anyone, ever, can trust the > validation results from a so called 'validating speaker'. >=20 > 9/ The "While being under DDoS attacks" paragraph is entirely out of > scope for this document. >=20 > 10/ Since the document promotes propagating RPKI Invalid routes = instead > of rejecting those invalid announcements, (section 3 "A validating BGP > speaker MUST support the Simple Tagging operation mode. Other modes of > operation are OPTIONAL."). >=20 > I think this approach is a disservice to the global community. Our > organisation (NTT) is creating RPKI ROAs for its IP resources with the > understanding that the RPKI is a method to globally publish what BGP > Origin ASNs NTT authorised and what prefix lengths can be expected. We > did not publish ROAs with the understanding that RPKI Invalid > announcements (hijacks, misconfigurations) will merely be tagged with = a > BGP community and propagated. >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_1EA96B0F-55C8-4FA3-82A8-EA59FD1E9B94 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBjCCBkAw ggUooAMCAQICFHyxDwExx02H4STp1P4iVRvBZ68RMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMjAeFw0xNzExMjcxMzMyMjFaFw0yMjExMjcxMzMyMjFaMIGMMQsw CQYDVQQGEwJERTEfMB0GA1UEChMWREUtQ0lYIE1hbmFnZW1lbnQgR21iSDEfMB0GA1UECwwWUmVz ZWFyY2ggJiBEZXZlbG9wbWVudDElMCMGCSqGSIb3DQEJARYWZGFuaWVsLmtvcHBAZGUtY2l4Lm5l dDEUMBIGA1UEAxMLRGFuaWVsIEtvcHAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDk Jvo9dsDe4/cugYUYjg+L7qzCYJ2Z4OZKuzidzBMh/POQQOO/AA/pczvnkasmswAsPvESoQFih4EI 3i5VJozg81wGOSe1iDmaB8OJSyaA8dN2coOo4266Xmx7RPRvoU4cfGU+AOlYazzO76AWmMomgMc/ 7bWbuzFSB8RQ9FwVgNxqQXXIOPwYSXKA5z7f46S0uYfMxsxdf0cuwqI1uxPdKi6z+mG8MJOk7VVM Ru5eXVUSHbwCzi9aItNkHwu0kADYk9mAEY9dtuhIoE2ZgzAq0gRcEYVGpcZW8THhutqElE59z2at G9qbTIbIFkmIQUiSxkCssyKxXhViZL4PpP/pAgMBAAGjggLNMIICyTAhBgNVHREEGjAYgRZkYW5p ZWwua29wcEBkZS1jaXgubmV0MA4GA1UdDwEB/wQEAwIEsDATBgNVHSUEDDAKBggrBgEFBQcDBDAd BgNVHQ4EFgQU9G9KiD0soUVY6ZoVKSASO+LMWhswHwYDVR0jBBgwFoAU8MejMpG168q1WHcVp06+ Gl1hQyUwgf8GA1UdHwSB9zCB9DBHoEWgQ4ZBaHR0cDovL2NybC5zd2lzc3NpZ24ubmV0L0YwQzdB MzMyOTFCNUVCQ0FCNTU4NzcxNUE3NEVCRTFBNUQ2MTQzMjUwgaiggaWggaKGgZ9sZGFwOi8vZGly ZWN0b3J5LnN3aXNzc2lnbi5uZXQvQ049RjBDN0EzMzI5MUI1RUJDQUI1NTg3NzE1QTc0RUJFMUE1 RDYxNDMyNSUyQ089U3dpc3NTaWduJTJDQz1DSD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jh c2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwYQYDVR0gBFowWDBWBglghXQBWQED AQYwSTBHBggrBgEFBQcCARY7aHR0cDovL3JlcG9zaXRvcnkuc3dpc3NzaWduLmNvbS9Td2lzc1Np Z24tU2lsdmVyLUNQLUNQUy5wZGYwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlhodHRw Oi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkxQjVF QkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVyLXBl cnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRF QkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQCRy7o0H3gyfjNudjAi+zZltdsfYG27vYqQ fKHl32E3J383bMIGdyhFtBv+0qtQyIsz3QZnUb8PnJ72ap2x1e3zGhw2+vbd8K/1aROe1vd0wdVG /muRCLSUPn8K2+wzAxtvAWwJRORPkeTxkiMY0Cve5n6/qigvUyvbMFCO09Mp2NHzBxqKXyI027Zy b34iKso23ycueRREdG0PNTOd/CwX3XuS/Mr2A/mmsX9B7PWdcjbaE3qOPhg1p8mp0SImPuHAl7p0 UEVDqBt4XTOKJRZv6KJD/tdIonyFQdj/FgTYncl8N7BJLwO/qHxATlmKXogdLAe6Ifyam8DHeHgK 9mUMMIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNV BAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2ZXIg Q0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNIMRUw EwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2ZXIg Q0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJobzD g6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDvALLr EzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2Yru5 aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5rgtmQ DAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kVmJyU U8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQXoM3B 5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2ln bi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCBooaB n2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIzQkNC NDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAEWjBY MFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24u Y29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYIKwYB BQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2FkLzE3 QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0dHA6 Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZB ODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkdaI3K CNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsponPe l/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZVKIh jfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0wl+S 4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8u7mO lL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQwJtE QK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/mpaG /ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8N43x Hm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4Fg9q 2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uoxggL2MIIC8gIBATBuMFYxCzAJBgNVBAYTAkNIMRUwEwYD VQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0Eg MjAxNCAtIEcyMgIUfLEPATHHTYfhJOnU/iJVG8FnrxEwCQYFKw4DAhoFAKCCAV0wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwODI0MTQzMzAxWjAjBgkqhkiG9w0B CQQxFgQUJTUSDrcIF0vXTtdlitx/aKSK3aowfQYJKwYBBAGCNxAEMXAwbjBWMQswCQYDVQQGEwJD SDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMTAwLgYDVQQDEydTd2lzc1NpZ24gUGVyc29uYWwgU2ls dmVyIENBIDIwMTQgLSBHMjICFHyxDwExx02H4STp1P4iVRvBZ68RMH8GCyqGSIb3DQEJEAILMXCg bjBWMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMTAwLgYDVQQDEydTd2lzc1Np Z24gUGVyc29uYWwgU2lsdmVyIENBIDIwMTQgLSBHMjICFHyxDwExx02H4STp1P4iVRvBZ68RMA0G CSqGSIb3DQEBAQUABIIBAG6bd3voCGBLycpt2ITjW/O/6ZlRS/FWM+5Plcyz0Ird22hYW1ewP0Jp XCVNBZuhji/bu8AguOA22MWtF0EAVsnCbuBlibMvjo1SGkHdbYthm96An91TTMJyauk1z/NiKOoz gY4Fs51zNNGGfdNtuzZo+DD3/yAgY3JohsGITJziGBcx8V1HiFu7z+fxc/Yfaw/ovs6NDr4NtoAW FK7tczJTeeid4/IICf5j4FyCHkF9NZ9hPOZgESmYR96drykpb+MbbMOrhbEuKo2YMBHRUo/pf3oP HvJvL6W9ZTnoR7QyN9wxBqchL04PoqTuiC7sKeAzQ70fhk4QXvJiBNrI4zUAAAAAAAA= --Apple-Mail=_1EA96B0F-55C8-4FA3-82A8-EA59FD1E9B94-- From nobody Tue Aug 28 06:30:18 2018 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 C524F128BAC; Tue, 28 Aug 2018 06:30:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-sidrops-rpki-tree-validation@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153546301179.23822.10226950999996945537.idtracker@ietfa.amsl.com> Date: Tue, 28 Aug 2018 06:30:11 -0700 Archived-At: Subject: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-rpki-tree-validation-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 13:30:12 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-sidrops-rpki-tree-validation-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am happy that this document exists. Documenting how the RIPE validator works is important and valuable. I think that the content (maybe after getting feedback from the WG) would have been more appropriate as an Independent Submission...or even as simply documentation in the RIPE site. There is one point that bothers me -- as part of the answer to 'why are we publishing this document?' (paraphrasing from the GenArt review), one of the authors mentioned that "the implementation will change (in fact v3 is just (about to be) released), and then the RFC is outdated." [1] There is documentation about the rpki-validator-3 in the github repository [2] already -- I haven't taken the time to examine the differences, but the point about the short term value of this document makes me think about the value of publishing it as an RFC at all. I have also noticed the comments from the WG about the value of this document to implementors, both experienced and new. I am then balloting 'No Objection'. [1] https://mailarchive.ietf.org/arch/msg/ietf/pJzebXqz1mtdGAsFi2V3e-G_SYI [2] https://github.com/RIPE-NCC/rpki-validator-3/wiki From nobody Tue Aug 28 12:16:42 2018 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 49F31130DF9; Tue, 28 Aug 2018 09:35:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-sidrops-rpki-tree-validation@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153547412129.23827.3324575091222487462.idtracker@ietfa.amsl.com> Date: Tue, 28 Aug 2018 09:35:21 -0700 Archived-At: X-Mailman-Approved-At: Tue, 28 Aug 2018 12:16:41 -0700 Subject: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rpki-tree-validation-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 16:35:22 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sidrops-rpki-tree-validation-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document is Informational, so I will make my comments non-blocking, but I think that the security considerations could be improved. It currently does a good job talking about cases where the procedure can receive inconsistent inputs (and how it behaves in the face of those inputs), as well as some other considerations, and this is great! I think that the discussion could be more powerful if it also considered how those inconsistent inputs could be produced, in particular which capabilities an attacker could have. There seem to be roughly three classes of actors for active attacks -- an attacker in the network could modify the transferred content (including number of files and directory layout) over unecrypteed rsync or http, an attacker that compromises the webserver's certificate (or obtains a fraudulent one) could do the same over encrypted https, and an attacker that compromises the TA signing key could produce fake-but-"valid" manifests, CRLs, etc.. (Is there more that could be done with a compromised non-TA CA? The potential hazards to this algorithm don't seem to be noticably distinct, though.) Some consumers may be willing to trust in the TA's integrity or even the Web PKI and not worry about those risks. Though there is always risk of accidental error, of course, and the current coverage in this document seems adequate for that risk. Some additional section-by-section comments follow. Section 3.1 The key properties needed of cryptographic hash functions are either "collision resistance" or "second preimage resistance", depending on whether the attacker gets to pick both hash inputs (the first case) or only one of them (the second). Which one is needed here would probably depend on whether the CA/issuer is trusted to not be an attacker or not, but regardless, please use the more detailed terminology. Section 3.2 [...], or use all objects whose AKI extension matches the Subject Key Identifier (SKI) extension (Section 4.2.1 of [RFC5280]) of a CA certificate. "all objects" as discovered within what scope? Section 4.2 Please expand SIA on first usage. In bullet point 1, it might help the uninitiated reader to say something after "and pass it to the object fetcher" to note that "the fetcher will then fetch all objects available from that repository". In bullet point 3, please be more clear about which manifest is "this manifest object" that is used to continue validation processing. 4. Perform manifest entries discovery and validation as described in Section 4.2.2. nit: "manifest entry discovery" (singular "entry") (Note that this implementation uses the operator configuration to decide which algorithm to use for path validation. It applies selected algorithm to all resource certificates, rather than nit: "the selected algorithm" Please expand ROA on first usage. Section 5.1.1, 5.1.2 The syntactic verification performed here is done on what should be considered "untrusted input", which means that the verification code needs to be written in a robust manner. (Given the historical recurrences of, e.g., ASN.1 decoder security vulnerabilities, we probably need to explicitly state this in the security considerations.) Section 9.1 If I understand correctly, RFC 6485 allows for (and predicts the need for) hash agility in the file hash algorithm. In this case, it would probably be appropriate to say something about how "the security of the system as a whole is limited to that of the weakest hash function allowed by consumers, but the hash agility provided for by RFC 6485 allows new (stronger) hashes to be introduced and old hash functions phased out before they are critically broken". Section 9.2 In case of a mismatch described above this implementation will not exclude an object from further validation merely because it's actual nit: "its" (no apostrophe) Section 9.3 nit: Which behavior is allowed-but-not-required -- a CA signing things not listed in the manifest, or an RP ignoring things not listed in the manifest? I suggest "This RP behavior is allowed [...]". Section 9.4 This kind of behavior would be seen as an unacceptable vulnerability in a standards-track protocol, though since this document is only informational it does not block publication. Section 9.5 It might be useful to reference Section 5.1.1 and how we sometimes fetch the entire repository contents, not limited by a manifest listing. From nobody Tue Aug 28 21:30:48 2018 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 D2A09130E2A; Tue, 28 Aug 2018 21:30:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-sidrops-rpki-tree-validation@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153551704185.6204.3212357087443697078.idtracker@ietfa.amsl.com> Date: Tue, 28 Aug 2018 21:30:41 -0700 Archived-At: Subject: [Sidrops] Ben Campbell's No Objection on draft-ietf-sidrops-rpki-tree-validation-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 04:30:42 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidrops-rpki-tree-validation-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the clear description of the purpose of the document in section 1. From nobody Fri Aug 31 05:01:49 2018 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 55146130E30 for ; Fri, 31 Aug 2018 05:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 u-nYjo_Yo3Vq for ; Fri, 31 Aug 2018 05:01:44 -0700 (PDT) Received: from de-cix.net (relay4.de-cix.net [46.31.121.24]) (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 0B40B130E34 for ; Fri, 31 Aug 2018 05:01:43 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.53,311,1531778400"; d="p7s'?scan'208"; a="2304094" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw014.de-cix.net with ESMTP; 31 Aug 2018 14:01:42 +0200 Received: from MS-EXCHANGE.for-the-inter.net (MS-EXCHANGE.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id 6298BB00B8 for ; Fri, 31 Aug 2018 14:01:41 +0200 (CEST) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 31 Aug 2018 14:01:41 +0200 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1367.000; Fri, 31 Aug 2018 14:01:41 +0200 From: Daniel Kopp To: SIDR Operations WG Thread-Topic: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 Thread-Index: AQHUQSJg39wsMRvEgEGxfjXE/5oKMw== Date: Fri, 31 Aug 2018 12:01:40 +0000 Message-ID: <7BA3B99A-CB8E-4A0F-AC3C-9EFF7A888B62@de-cix.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.6.18) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.140.254] Content-Type: multipart/signed; boundary="Apple-Mail=_BA93A52E-ABCD-4CDC-B216-793E9BD663A5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 31 Aug 2018 12:01:47 -0000 --Apple-Mail=_BA93A52E-ABCD-4CDC-B216-793E9BD663A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello again, I want to follow up and hopefully revive the discussion by reviewing the = motivation for the draft. The idea is to signal the RPKI status from the route server, originally = we wanted to have this limited to the domain of an IXP. =46rom our point of view we see this as a soft start to use RPKI at IXPs = and=20 the trigger to work on this came from the IXP member side. Core discussion points on the mailing list are: 1. Route servers should filter out ROA invalid prefixes. That=E2=80=99s = what we want as well.=20 The draft is just an addition to signal the results and we also have = different modes of operation.=20 However, I think every IXP should be allowed to decide by themselves how = strict they setup their route server filtering.=20 2. Some concerns where about that this approach might pollute the DFZ = with validation results.=20 I don't think that is the case if we want the tagging to be limited to = the IXPs network. 3. About the comment that forwarding ROA invalids is useless without BGP = ADD-PATH, I think this was mentioned by Nick several times. The draft foresees the usage of ADD-PATH, *if* that becomes available = widely to EBGP. In that sense, the case for dropping ROA invalids becomes even weaker. 4. It was said that RPKI deployment is easy nowadays so why provide = another less secure method.=20 The draft is intended for networks that can't (technically) or won't = (politically) implement RPKI in their own networks,=20 but would use of the singling from the route server at an IXP.=20 If people can deploy RPKI themselves this is the best solution and we = strongly would encourage such deployments. Looking forward to have a discussion around this and maybe we can find a = way to make this work. Best regards, Daniel=20 --Apple-Mail=_BA93A52E-ABCD-4CDC-B216-793E9BD663A5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBjCCBkAw ggUooAMCAQICFHyxDwExx02H4STp1P4iVRvBZ68RMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMjAeFw0xNzExMjcxMzMyMjFaFw0yMjExMjcxMzMyMjFaMIGMMQsw CQYDVQQGEwJERTEfMB0GA1UEChMWREUtQ0lYIE1hbmFnZW1lbnQgR21iSDEfMB0GA1UECwwWUmVz ZWFyY2ggJiBEZXZlbG9wbWVudDElMCMGCSqGSIb3DQEJARYWZGFuaWVsLmtvcHBAZGUtY2l4Lm5l dDEUMBIGA1UEAxMLRGFuaWVsIEtvcHAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDk Jvo9dsDe4/cugYUYjg+L7qzCYJ2Z4OZKuzidzBMh/POQQOO/AA/pczvnkasmswAsPvESoQFih4EI 3i5VJozg81wGOSe1iDmaB8OJSyaA8dN2coOo4266Xmx7RPRvoU4cfGU+AOlYazzO76AWmMomgMc/ 7bWbuzFSB8RQ9FwVgNxqQXXIOPwYSXKA5z7f46S0uYfMxsxdf0cuwqI1uxPdKi6z+mG8MJOk7VVM Ru5eXVUSHbwCzi9aItNkHwu0kADYk9mAEY9dtuhIoE2ZgzAq0gRcEYVGpcZW8THhutqElE59z2at G9qbTIbIFkmIQUiSxkCssyKxXhViZL4PpP/pAgMBAAGjggLNMIICyTAhBgNVHREEGjAYgRZkYW5p ZWwua29wcEBkZS1jaXgubmV0MA4GA1UdDwEB/wQEAwIEsDATBgNVHSUEDDAKBggrBgEFBQcDBDAd BgNVHQ4EFgQU9G9KiD0soUVY6ZoVKSASO+LMWhswHwYDVR0jBBgwFoAU8MejMpG168q1WHcVp06+ Gl1hQyUwgf8GA1UdHwSB9zCB9DBHoEWgQ4ZBaHR0cDovL2NybC5zd2lzc3NpZ24ubmV0L0YwQzdB MzMyOTFCNUVCQ0FCNTU4NzcxNUE3NEVCRTFBNUQ2MTQzMjUwgaiggaWggaKGgZ9sZGFwOi8vZGly ZWN0b3J5LnN3aXNzc2lnbi5uZXQvQ049RjBDN0EzMzI5MUI1RUJDQUI1NTg3NzE1QTc0RUJFMUE1 RDYxNDMyNSUyQ089U3dpc3NTaWduJTJDQz1DSD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jh c2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwYQYDVR0gBFowWDBWBglghXQBWQED AQYwSTBHBggrBgEFBQcCARY7aHR0cDovL3JlcG9zaXRvcnkuc3dpc3NzaWduLmNvbS9Td2lzc1Np Z24tU2lsdmVyLUNQLUNQUy5wZGYwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlhodHRw Oi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkxQjVF QkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVyLXBl cnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRF QkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQCRy7o0H3gyfjNudjAi+zZltdsfYG27vYqQ fKHl32E3J383bMIGdyhFtBv+0qtQyIsz3QZnUb8PnJ72ap2x1e3zGhw2+vbd8K/1aROe1vd0wdVG /muRCLSUPn8K2+wzAxtvAWwJRORPkeTxkiMY0Cve5n6/qigvUyvbMFCO09Mp2NHzBxqKXyI027Zy b34iKso23ycueRREdG0PNTOd/CwX3XuS/Mr2A/mmsX9B7PWdcjbaE3qOPhg1p8mp0SImPuHAl7p0 UEVDqBt4XTOKJRZv6KJD/tdIonyFQdj/FgTYncl8N7BJLwO/qHxATlmKXogdLAe6Ifyam8DHeHgK 9mUMMIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNV BAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2ZXIg Q0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNIMRUw EwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2ZXIg Q0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJobzD g6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDvALLr EzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2Yru5 aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5rgtmQ DAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kVmJyU U8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQXoM3B 5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2ln bi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCBooaB n2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIzQkNC NDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAEWjBY MFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24u Y29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYIKwYB BQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2FkLzE3 QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0dHA6 Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZB ODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkdaI3K CNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsponPe l/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZVKIh jfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0wl+S 4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8u7mO lL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQwJtE QK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/mpaG /ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8N43x Hm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4Fg9q 2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uoxggL2MIIC8gIBATBuMFYxCzAJBgNVBAYTAkNIMRUwEwYD VQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0Eg MjAxNCAtIEcyMgIUfLEPATHHTYfhJOnU/iJVG8FnrxEwCQYFKw4DAhoFAKCCAV0wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwODMxMTIwMTQwWjAjBgkqhkiG9w0B CQQxFgQUhrOjfQw/GKvcemkwL7E23fQA9zcwfQYJKwYBBAGCNxAEMXAwbjBWMQswCQYDVQQGEwJD SDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMTAwLgYDVQQDEydTd2lzc1NpZ24gUGVyc29uYWwgU2ls dmVyIENBIDIwMTQgLSBHMjICFHyxDwExx02H4STp1P4iVRvBZ68RMH8GCyqGSIb3DQEJEAILMXCg bjBWMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMTAwLgYDVQQDEydTd2lzc1Np Z24gUGVyc29uYWwgU2lsdmVyIENBIDIwMTQgLSBHMjICFHyxDwExx02H4STp1P4iVRvBZ68RMA0G CSqGSIb3DQEBAQUABIIBAA6wUar+li/yk61G9Lh2bgYw81uJnEKkIE3NQPfvkJTDP7IUF5Ikf4np 4p/At7WlaFMqiFc7zn4uCTxret5D5ZizR5fSPcnQPeu+rbcKjmRz+PEc3V+VZ5z6mVjTctG8NlZ/ oF9MFf6K89scDZoVasEKzc7pBwke3u0RSrOb65h9NBYT2GBt1DuRehrC4y9c9G7Bw5WM+T8hagPP xIrzb7SKKF9tL6WFeef6zqu5x3q4XbKZdb2KQTuqo/PhbszGIVG4YRYB5U51JEsh0bl4vxFkpNI1 ymE9Qzk2CHWCTgs0zlC0Mrhk7w+S5qw94HqGegdCk6Y0GNHIwLzAwK7OzdEAAAAAAAA= --Apple-Mail=_BA93A52E-ABCD-4CDC-B216-793E9BD663A5-- From nobody Fri Aug 31 08:28:18 2018 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 C6A95130DE3 for ; Fri, 31 Aug 2018 08:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VeSgGUPCfDBV for ; Fri, 31 Aug 2018 08:28:15 -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 B9853130DD1 for ; Fri, 31 Aug 2018 08:28:14 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id w7VFS8Vl019753 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2018 16:28:09 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Daniel Kopp Cc: SIDR Operations WG References: <7BA3B99A-CB8E-4A0F-AC3C-9EFF7A888B62@de-cix.net> From: Nick Hilliard Message-ID: <0534686b-8132-37a0-ac6d-0f3b6099b6db@foobar.org> Date: Fri, 31 Aug 2018 16:28:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2 MIME-Version: 1.0 In-Reply-To: <7BA3B99A-CB8E-4A0F-AC3C-9EFF7A888B62@de-cix.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 31 Aug 2018 15:28:17 -0000 Hi Daniel, Daniel Kopp wrote on 31/08/2018 13:01: > The draft is intended for networks that can't (technically) or won't > (politically) implement RPKI in their own networks, If an organisation won't implement RPKI for policy reasons, then that is a decision that they are responsible for, and it is not really the job of the IETF to engineer around their layer 9 problems. Regarding the "can't technically" position that some networks find themselves in, this argument is evaporating quickly, as more bgp stacks implement RO validation. All the major vendors do this already on current equipment, so this is beginning to become a question of whether people are on current support contracts or not, which brings the issue back to a policy decision on their part, rather than strictly a technical decision. > maybe we can find a way to make this work This is the crux: in the context of ebgp and public exchange of NLRIs, the draft presents a methodology which is incompatible with good quality network engineering and product design. I don't believe this can be fixed. Nick From nobody Fri Aug 31 18:43:53 2018 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 5E185130E8B for ; Fri, 31 Aug 2018 18:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 p4eNMdt8YRBu for ; Fri, 31 Aug 2018 18:43:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 EAD45124BE5 for ; Fri, 31 Aug 2018 18:43:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fvux1-0004Rt-DN; Sat, 01 Sep 2018 01:43:47 +0000 Date: Fri, 31 Aug 2018 18:43:46 -0700 Message-ID: From: Randy Bush To: Daniel Kopp Cc: SIDR Operations WG In-Reply-To: <7BA3B99A-CB8E-4A0F-AC3C-9EFF7A888B62@de-cix.net> References: <7BA3B99A-CB8E-4A0F-AC3C-9EFF7A888B62@de-cix.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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, 01 Sep 2018 01:43:51 -0000 > 2. Some concerns where about that this approach might pollute the DFZ > with validation results. > I don't think that is the case if we want the tagging to be limited to > the IXPs network. considering the massive community mess in the dfz, this does not sound like major new damage. otoh, assuming non-propagation turns out (by measurement) to be quite na=EEve. randy