From nobody Sun Apr 1 14:02:58 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF131200A0; Sun, 1 Apr 2018 14:02:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152261657190.23824.4759371193986790926.idtracker@ietfa.amsl.com> Date: Sun, 01 Apr 2018 14:02:51 -0700 Archived-At: Subject: [sidr] Warren Kumari's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 21:02:52 -0000 Warren Kumari has entered the following ballot position for draft-ietf-sidr-slurm-07: Discuss 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-sidr-slurm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't understand the targeting as it related to domain/host names (and suspect that others will have the same issue). >From section 3.3: " If a "slurmTarget" element is present, an RP SHOULD verify that the target is an acceptable value, and reject this SLURM file if the "slurmTarget" element is not acceptable.... Accordingly, the SLURM file source needs to indicate which RP(s) should make use of the file by adding the domain name(s) of the RP(s) to the SLURM file target... Such a target value is a server name expressed in FQDN. "slurmTarget": [ { "hostname": "rpki.example.com", "comment": "This file is intended for RP server rpki.example.com" } ] So, if I want to target multiple RPs (rpki1.example.com, rpki2.example.com) can I do: "slurmTarget": [ { "hostname": "example.com", "comment": "This file is intended for RP server rpki.example.com" } ] ? The "domain names(s)" versus "hostname" vs "server name expressed in FQDN" text is handwavey. I'm assuming that I'd need to do: "slurmTarget": [ { "hostname": "rpki1.example.com", "comment": "This file is intended for RP server rpki1.example.com" }, { "hostname": "rpki2.example.com", "comment": "This file is intended for the RP server, rpki2.example.com" }, ]" Can you please make this clearer, and hopefully add more targets to the examples? This seems like an easy fix / clarification, happy to clear once it is, er, clear. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a few questions and editorial comments: 1: Section Abstract: ISPs can also be able to use the RPKI to validate the path of a BGP route. I think you meant "ISPs can also use the RPKI..." 2: Section 1. Introduction "However, an "RPKI relying party" (RP) may want to override some of the information expressed via putative Trust Anchor(TA) and the certificates downloaded from the RPKI repository system." I think this should be either "a putative Trust Anchor (TA)" or "putative Trust Anchors (TA)" (single vs plurals). I agree with others that "putative TA" is not a well known term - perhaps you can find a better one? Section 3.4.1. Validated ROA Prefix Filters In the "prefixFilters examples", I think it would be helpful to update the comments to be more explicit about what is being matched (e.g"All VRPs covered by 198.51.100.0/24 and matching AS 64497") From nobody Mon Apr 2 03:47:35 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A63421204DA; Mon, 2 Apr 2018 03:47:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152266604967.7312.10722440885591415777.idtracker@ietfa.amsl.com> Date: Mon, 02 Apr 2018 03:47:29 -0700 Archived-At: Subject: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 10:47:30 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-slurm-07: 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-sidr-slurm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Warren's DISCUSS. Additionally, one little, but important thing that I would like you to fix: In Section 3.4.2 and 3.5.2, when referencing Base64 [RFC4648], you need to specify which version you are using. I think you want to use the version in Section 4 (and not Section 5) of this document. It would also be useful to specify whether trailing "=" need to be present in base64 values. From nobody Mon Apr 2 09:56:23 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 243CE12D778; Mon, 2 Apr 2018 09:56:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152268817614.31085.6790269677708093564.idtracker@ietfa.amsl.com> Date: Mon, 02 Apr 2018 09:56:16 -0700 Archived-At: Subject: [sidr] Eric Rescorla's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 16:56:16 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-sidr-slurm-07: 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-sidr-slurm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- path of a BGP route. However, ISPs may want to establish a local view of the RPKI to control its own network while making use of RPKI data. The mechanisms described in this document provide a simple way Nit: their network the information expressed via putative Trust Anchor(TA) and the certificates downloaded from the RPKI repository system. For instances, [RFC6491] recommends the creation of ROAs that would I don't really understand this sentence. Why "putatve" operators are hereby called Simplified Local internet nUmber Resource Management with the RPKI (SLURM). It would help here to say that this includes filtering. In general, the primary output of an RP is the data it sends to routers over the rpki-rtr protocol. The rpki-rtr protocol enables routers to query an RP for all assertions it knows about (Reset citation for rpki-rtr plese. members that are not defined here MUST NOT be used in SLURM Files. An RP MUST consider any deviations from the specification an error. Future additions to the specifications in this document MUST use an Nit: errors. acceptable. Each "slurmTarget" element contains merely one "asn" or one "hostname". An explanatory "comment" MAY be included in each "slurmTarget" element so that it can be shown to users of the RP Is this exclusive or? Emergency Response Team Coordination, the SLURM file source may generate a SLURM file that is to be applied to only one specific RP. This file can take advantage of the "target" element to restrict the I am having trouble reading this sentence. Can you please rephrase. [RFC6487]. This is the value of the ASN.1 OCTET STRING without the ASN.1 tag or length fields. IMPORTANT: There is an opportunity for ambiguity here in case the SPKI was not DER-encoded. I assume you mean this must be taken directly from the cert? The following JSON structure represents an array of "prefixAssertions" with an element for each use case listed above: I guess that the semantics here are obvious, but perhaps you could state them explicitly, given that this is actually not exactly the same as an ROA. 3.5.2. BGPsec Assertions IMPORTANT: It seems even less obvious what the semantics are here for injecting BGPSec assertions. How do you reconstruct the BGPSec data. contained by any prefix in any or in file Z. OK, so you are going to error out even if there are assertions which are identical? From nobody Mon Apr 2 17:39:23 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC13612DA21; Mon, 2 Apr 2018 17:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq0aQkF8-FeB; Mon, 2 Apr 2018 17:39:13 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 168A712DA25; Mon, 2 Apr 2018 17:39:10 -0700 (PDT) X-AuditID: 1209190e-b1fff70000000cd8-bb-5ac2cd2cef9b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 9E.7D.03288.C2DC2CA5; Mon, 2 Apr 2018 20:39:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w330d3Nv031535; Mon, 2 Apr 2018 20:39:05 -0400 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w330cvHK001769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2018 20:39:00 -0400 Date: Mon, 2 Apr 2018 19:38:57 -0500 From: Benjamin Kaduk To: Di Ma Cc: The IESG , morrowc@ops-netman.net, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org Message-ID: <20180403003856.GY80088@mit.edu> References: <152243246452.20520.7968873255606309518.idtracker@ietfa.amsl.com> <0D527078-A80E-4B45-AD81-CA4F840686E9@rpstir.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0D527078-A80E-4B45-AD81-CA4F840686E9@rpstir.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixG6noqt79lCUwY5XfBaNF34xWcz4M5HZ onH1YkaLyws/sll8n3+B1WLZpPOMDmweS5b8ZPJ4MOkou8fqP4wBzFFcNimpOZllqUX6dglc GbPWL2IpWGNacevsTuYGxkOaXYycHBICJhJvzv5i72Lk4hASWMwkcWTCXnaQhJDABkaJk9sY IRJnmCQ+X9wNlmARUJGY+uwkK4jNBmQ3dF9mBrFFBKQlbk98wAbSwCzQxCgxc+o+sISwQLzE o3N9LCA2r4COxKtDq1ggpjYySnzZ9oINIiEocXLmE7AiZgF1iT/zLgE1cwDZ0hLL/3FAhOUl mrfOBpvJKWAn0Tn5LFi5qICyxN6+Q+wTGAVnIZk0C8mkWQiTZiGZtICRZRWjbEpulW5uYmZO cWqybnFyYl5eapGusV5uZoleakrpJkZQJHBK8u1gnNTgfYhRgINRiYe3wPVQlBBrYllxZe4h RkkOJiVR3kmHgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeM/tAcrxpiRWVqUW5cOkpDlYlMR5 F+3fGyUkkJ5YkpqdmlqQWgSTleHgUJLg9TsD1ChYlJqeWpGWmVOCkGbi4AQZzgM03Aukhre4 IDG3ODMdIn+KUVFKnNcJJCEAksgozYPrBSUqiez9Na8YxYFeEea1B6niASY5uO5XQIOZgAbb 5x0AGVySiJCSamA0FLkh7vdI3p+r99v/KMX5dVps195uui1RZ75GYJteZsuFNef3ahtNmZz6 KPVi9b93haULG15vPPLbvVXAiuWCuq3jjs2rrU/+uWsvKdXqaTUnq/voYvesT7J9HKu0OsM2 ngiYfNb3idchhRKW3BPBZzUN035wsZvv9bcOzJ3u4jrD6Pjhc7OUWIozEg21mIuKEwGjncd+ LwMAAA== Archived-At: Subject: Re: [sidr] Benjamin Kaduk's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 00:39:16 -0000 Hi Di, Thank you for the extra clarification. I think that my question is basically the same as in Warren's DISCUSS, so perhaps we should let this thread stop and just have the discussion on that thread. Having said that, I think my question was more about the case when there were two differet elements in the slurmTarget array, with different hostnames in them -- exactly as Warren lays out at the end of his DISCUSS. Thanks again, Benjamin On Sat, Mar 31, 2018 at 03:49:39AM +0800, Di Ma wrote: > Benjamin, > > Thanks very much for your comments. > > I will exchange notes with co-authors on your editorial suggestions. > > Yet as for your question about slurmTarget, here is the explanation. > > First of all, the FQDN is used by the SLURM file distributor to determine which RP will use this slurm file, noting that RP is identified by FQDN. > > People might think this design is sort of redundancy, arguing that if the SLURM file distributor does not want a specific RP to effect SLURM, just not do that, why bother to throw this file to that RP, indicating ’this file is not for you’. > > The reason why we do this is to provide the scalability for SLURM in operations. > > Given a SLURM file distributor service several RPs and SLURM file need to change at times to reflect local policy. > > An easy to do so is that all the registered RPs simply synchronize with SLURM file distributor, telling from the slurmTarget to decide whether to effect ‘a specific version’ of slurm file 'this time'. > > All in all, to answer your question, if the same SLURM file is provided to multiple RPs, those RPs identified by FQDN, will first to see whether ‘this version’ of slurm file is for itself 'this time'. > > And then an RP uses this slurm file to form different views for different BGP speakers as specified by slrumtarget ASN. > > BTW, as stated in the document, if the operator does not want to use slrumtarget ‘hostname’ to gain management granularity, just not put it into a slrumtarget element. > > I hope my clarification is making sense here. > > Di > > > > Does this mean that if the same SLURM file is > > provided to multiple RPs, those RPs both need to be "responsible > > for" all the ASNs and FQDNS contained therein? Would this present a > > limit on the ability to reuse SLURM files for multiple recipients > > within a single administrative domain (that may span multiple ASNs > > and FQDNs)? > > > > Di Ma > RPSTIR > https://bgpsecurity.net > > > 在 2018年3月31日，01:54，Benjamin Kaduk 写道： > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-sidr-slurm-07: 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-sidr-slurm/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > The directorate reviews have some good comments, especially about expanding > > acronyms/defining terms. > > > > I think Section 3.3 would benefit from greater clarity about individual > > components of the JSON array that is the value of the "slurmTarget" element, > > versus that element itself. (Also, slurmTarget appears to be mandatory, so > > talking about cases where it is present seems strange, and presumably a > > nonempty value being present is the desired criterion.) > > > > I'm also not entirely sure I understand the intended semantics -- > > when first introduced in Section 3.2, we say that "all targets MUST > > be acceptable to the RP". (Presumably that includes both ASN and > > FQDN entries.) Does this mean that if the same SLURM file is > > provided to multiple RPs, those RPs both need to be "responsible > > for" all the ASNs and FQDNS contained therein? Would this present a > > limit on the ability to reuse SLURM files for multiple recipients > > within a single administrative domain (that may span multiple ASNs > > and FQDNs)? > > > > Some editorial suggestions follow. > > > > Abstract: > > > > OLD: > > > > [...] ISPs can also be able to use the RPKI to validate the > > path of a BGP route. > > > > NEW: > > > > [...] ISPs can also use the RPKI to validate the > > path of a BGP route. > > > > Section 3.2 > > > > OLD: > > o A SLURM Version indication that MUST be 1 > > > > NEW: > > o A SLURM Version indication. This document specifies version 1. > > > > Also, in > > > > * Zero or more target elements. In this version of SLURM, there > > are two types of values for the target: ASN or Fully Qualified > > Domain Name(FQDN). If more than one target line is present, > > all targets MUST be acceptable to the RP. > > > > What's the difference between a target element and a target line? > > > > Section 3.5 (both subsections): > > > > "is locally configured with" does not mention SLURM at all as being > > involved in that configuration; perhaps it should. > > > > Section 4.2 > > > > [...] To do so, the RP MUST > > check the entries of SLURM file with regard to overlaps of the INR > > assertions and report errors to the sources that created these SLURM > > files in question. > > > > The "report errors to the sources" part seems ineligible for > > MUST-level requirement. > > > > Also, in case of conflict, does the "MUST NOT use them" apply to all > > SLURM files, only the ones with directly conflicting inputs, or only > > enough files to remove the conflict? > > > > Section 6 > > > > I'm always a little sad to see security-relevant functionality (such > > as the transport with authenticity and integrity protection of SLRUM > > files over the network) left as out of scope with no examples of > > reasonable usage given. > > > > I also wonder if we would benefit from a little discussion of the > > potential routing issues that could arise from using a "broken" (or > > deliberately adversarial) SLURM file, though I expect that the > > target audience is probably pretty familiar with these already. > > > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > From nobody Tue Apr 3 12:43:31 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3CD126DFF; Tue, 3 Apr 2018 12:43:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152278460436.22775.8518027666585390285.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 12:43:24 -0700 Archived-At: Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 19:43:24 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-slurm-07: 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-sidr-slurm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Major Comments: §6: I also agree with Benjamin's sadness about the security considerations. The section really should at least discuss the potential consequences of an adversary inserting a false slurm file, modifying one on the fly, or eavesdropping on one. Minor Comments: §1.1: The document contains at least a few lower case instances of "must". Please consider using the boilerplate from RFC 8174. §3.3, 1st paragraph: "RP SHOULD verify that the target is an acceptable value" What is the criteria for acceptability? §8.2, " [RFC4648]": The document requires Base64 encoding. Doesn't that make this a normative reference? Editorial Comments and Nits: [significant] Abstract (and throughout the document): I don't find the term "local view of the RPKI" to be descriptive. IIUC, we are talking about overriding assertions that come from the RPKI based on local (or possibly 3rd party) knowledge. This seems to me to be a different thing than providing a "local view of the RPKI", and I certainly would not have gotten a sense of that difference from the Abstract alone, and possibly not the introduction. §1, last paragraph: Please expand or define rpki-rtr on first mention. §3.4.1: Please expand SKI on first mention. (You do so in the second mention :-) ) From nobody Tue Apr 3 13:22:19 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CA412D86E; Tue, 3 Apr 2018 13:22: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-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152278693467.22763.5602862777410542764.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2018 13:22:14 -0700 Archived-At: Subject: [sidr] Martin Vigoureux's No Objection on draft-ietf-sidr-slurm-07 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:22:15 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-sidr-slurm-07: 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-sidr-slurm/ There are no remarks associated with this position. From nobody Wed Apr 4 11:00:44 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BFE126CD6; Wed, 4 Apr 2018 11:00:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152286484194.23960.17788058701508276433.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2018 11:00:41 -0700 Archived-At: Subject: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:00:42 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sidr-slurm-07: 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-sidr-slurm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please cite BCP 14 rather than RFC 2119, assuming you intend for normative keywords to have their normative meaning in uppercase only. From nobody Wed Apr 4 12:22:47 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D871200B9; Wed, 4 Apr 2018 12:22:45 -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-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152286976586.23998.1170348122023610014.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2018 12:22:45 -0700 Archived-At: Subject: [sidr] Adam Roach's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 19:22:46 -0000 Adam Roach has entered the following ballot position for draft-ietf-sidr-slurm-07: Discuss 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-sidr-slurm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. The mechanism seems useful. I'm concerned that the document doesn't describe the file format itself; rather, it relies on examples to provide vital, nonsupplemental information such as the names of JSON object members, expected encodings (e.g., strings versus numbers), and distinction between arrays and objects. I'm making this a DISCUSS because I think the ambiguity here -- and, in particular the ambiguity about IP address prefix notation -- will lead to non-interoperable implementations. Using section §3.2 as an example: > A SLURM file consists of: > > o A SLURM Version indication that MUST be 1 > > o A slurmTarget element (Section 3.3) consisting of: > > * Zero or more target elements. In this version of SLURM, there > are two types of values for the target: ASN or Fully Qualified > Domain Name(FQDN). If more than one target line is present, > all targets MUST be acceptable to the RP. > > o Validation Output Filters (Section 3.4), consisting of: > > * An array of zero or more Prefix Filters, described in > Section 3.4.1 > > * An array of zero or more BGPsec Filters, described in > Section 3.4.2 > > o Locally Added Assertions (Section 3.5), consisting of: > > * An array of zero or more Prefix Assertions, described in > Section 3.5.1 > > * An array of zero or more BGPsec Assertions, described in > Section 3.5.2 > As this is the normative description of the structure, I would have expected an indication that the file contains a JSON object (rather than, say, a JSON array), an indication that the version is to be encoded as a number (rather than a string), and clarification of what value members are expected to contain. For example, the following JSON object is in compliance with the preceding normative description (and, as far as I can tell, all other normative text in the document): ["1", ["65536", "rpki.example.com"], [ ["192.0.2.0/255.255.255.0", "All VRPs encompassed by prefix"], ["64496", "All VPRs maching ASN"], ["198.51.100.0/255.255.255.0", "64497", "All VRPs encompassed by prefix, matching ASN"] ], [ ["64496", "All keys for ASN"], ["Zm9v", "Key matching Router SKI"], ["64497", "YmFy", "Key for ASN 64497 matching Router SKI"], ], [ ["64496", "198.51.100.0/255.255.255.0", "My other important route"], ["64496", "2001:DB8::/FFFF:FFFF::", "48", "My other important de-aggregated routes"], ], [ ["64496", "My known key for my important ASN", "", ""] ] ] Fixing this should be pretty easy; the document simply needs text added that describes the JSON structure explicitly, with clear indications of how values are to be encoded. For example, the preceding text I quote becomes: A SLURM file consists of a single JSON object containing the following members: o A "slurmVersion" member that MUST be set to 1, encoded as a number o A "slurmTarget" member (Section 3.3) If more than one target line is present, all targets MUST be acceptable to the RP. The "slurmTarget" member is encoded as an array of zero or more objects. Each object in the array contains exactly one member. In this version of SLURM, the member may be named either: * "asn", in which case it contains an ASN, or * "hostname", in which case it contains a Fully Qualified Domain Name (FQDN). o A "validationOutputFilters" member (Section 3.4), whose value is an object. The object MUST contain exactly two members: * A "prefixFilters" member, whose value is described in Section 3.4.1 * A "bgpsecFilters" member, whose value is described in Section 3.4.2 o A "locallyAddedAssertions" member (Section 3.5), whose value is an object. The object MUST contain exactly two members: * A "prefixAssertions" member, whose value is described in Section 3.5.1 * A "bgpsecAssertions" member, whose value is described in Section 3.5.2 Gotchas to watch out for include: - If you're using the word "element" to describe something in a JSON object, you probably need to find a more specific word. This document, for example, uses "element" instead of "member" in most places. - Everywhere you use the word "structure," replace it with either "array" or "object," as appropriate. - When values can be encoded as either a number or a string (e.g., as with "slurmVersion" above, or with AS numbers), indicate which encoding is expected. - For IP prefixes, be clear about acceptable syntax. For example: is the RFC 950 syntax ("192.0.2.0/255.255.255.0") acceptable? My suggestion is to cite RFC 4632 §3.1 for prefix-length notation (both for IPv4 and IPv6), and RFC 5952 for the syntax of IPv6 addresses. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The remaining comments are in document order. --------------------------------------------------------------------------- Title: It seems odd to use the stylized capitalization (e.g., "nUmber") without following it by the "SLURM" acronym. Consider adding "(SLURM)" to the title. --------------------------------------------------------------------------- §3.1: > This document describes responses in the JSON [RFC8259] format. I don't think this means to say "responses," does it? It appears to be describing a JSON document rather than a request/response protocol. --------------------------------------------------------------------------- §3.3: > A SLURM file MUST specify a "slurmTarget" element that identifies the > environment in which the SLURM file is intended to be used. The > "slurmTarget" element MAY have an empty array as its value, which > means "applies to all". The meaning of the "slurmTarget" element, if > present, is determined by the user. If a "slurmTarget" element is > present, an RP SHOULD verify that the target is an acceptable value, > and reject this SLURM file if the "slurmTarget" element is not > acceptable. Each "slurmTarget" element contains merely one "asn" or > one "hostname". An explanatory "comment" MAY be included in each > "slurmTarget" element so that it can be shown to users of the RP > software. When reworking this paragraph in particular, please be careful to distinguish between the "slurmTarget" member and the elements in the array that constitutes its value. The preceding text calls both of these things '"slurmTarget" element,' which is very confusing. From nobody Wed Apr 4 12:33:21 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EE4126DCA; Wed, 4 Apr 2018 12:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sk4uX57NPj_F; Wed, 4 Apr 2018 12:33:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDB81200B9; Wed, 4 Apr 2018 12:33:14 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w34JXBOR047374 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Apr 2018 14:33:12 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local From: Adam Roach To: The IESG Cc: morrowc@ops-netman.net, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org, aretana.ietf@gmail.com References: <152286976586.23998.1170348122023610014.idtracker@ietfa.amsl.com> Message-ID: <90f50a1f-7104-cbad-a101-a1dbb28949a5@nostrum.com> Date: Wed, 4 Apr 2018 14:33:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <152286976586.23998.1170348122023610014.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [sidr] Adam Roach's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 19:33:16 -0000 I realized after I sent this that my suggested text has a couple of errors in t. On 4/4/18 2:22 PM, Adam Roach wrote: > > Fixing this should be pretty easy; the document simply needs text added that > describes the JSON structure explicitly, with clear indications of how values > are to be encoded. For example, the preceding text I quote becomes: > > A SLURM file consists of a single JSON object containing the following > members: > > o A "slurmVersion" member that MUST be set to 1, encoded as a number > > o A "slurmTarget" member (Section 3.3) If more than one target line is > present, all targets MUST be acceptable to the RP. The "slurmTarget" > member is encoded as an array of zero or more objects. Each object in the > array contains exactly one member. In this version of SLURM, the member > may be named either: I copied the "target line" language over without reading it carefully. I don't think "line" makes sense here. Perhaps:    o  A "slurmTarget" member (Section 3.3). The "slurmTarget" member is encoded       as an array of zero or more objects, each representing a target.  If       more than one target is present, all targets MUST be acceptable to the       RP.  Each object in the array contains exactly one member.  In this       version of SLURM, the member may be named either: > > * "asn", in which case it contains an ASN, or This should should say "...an ASN, encoded as a number." > > * "hostname", in which case it contains a Fully Qualified Domain > Name (FQDN). > > o A "validationOutputFilters" member (Section 3.4), whose value is an > object. The object MUST contain exactly two members: > > * A "prefixFilters" member, whose value is described in > Section 3.4.1 > > * A "bgpsecFilters" member, whose value is described in > Section 3.4.2 > > o A "locallyAddedAssertions" member (Section 3.5), whose value is an > object. The object MUST contain exactly two members: > > * A "prefixAssertions" member, whose value is described in > Section 3.5.1 > > * A "bgpsecAssertions" member, whose value is described in > Section 3.5.2 From nobody Wed Apr 4 21:21:23 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AA6128954; Wed, 4 Apr 2018 21:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDWqa6KDPvSe; Wed, 4 Apr 2018 21:21:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21924127369; Wed, 4 Apr 2018 21:21:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B585FB839F5; Wed, 4 Apr 2018 21:20:44 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidr@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180405042044.B585FB839F5@rfc-editor.org> Date: Wed, 4 Apr 2018 21:20:44 -0700 (PDT) Archived-At: Subject: [sidr] =?utf-8?q?RFC_8360_on_Resource_Public_Key_Infrastructure_?= =?utf-8?q?=28RPKI=29_Validation_Reconsidered?= X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 04:21:16 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8360 Title: Resource Public Key Infrastructure (RPKI) Validation Reconsidered Author: G. Huston, G. Michaelson, C. Martinez, T. Bruijnzeels, A. Newton, D. Shaw Status: Standards Track Stream: IETF Date: April 2018 Mailbox: gih@apnic.net, ggm@apnic.net, carlos@lacnic.net, tim@ripe.net, andy@arin.net, daniel@afrinic.net Pages: 29 Characters: 52125 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sidr-rpki-validation-reconsidered-10.txt URL: https://www.rfc-editor.org/info/rfc8360 DOI: 10.17487/RFC8360 This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features. The procedure specified in RFC 6487 requires that Resource Certificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing Certification Authority (CA) to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate. It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document. This choice is signaled by a set of alternative Object Identifiers (OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487. Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Apr 5 03:38:27 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F056B129BBF; Thu, 5 Apr 2018 03:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0LapdF0jN0I; Thu, 5 Apr 2018 03:38:17 -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 485B0127369; Thu, 5 Apr 2018 03:38:17 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1f42HV-0003kv-4f; Thu, 05 Apr 2018 12:38:14 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-103.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1f42HU-0000xs-Ix; Thu, 05 Apr 2018 12:38:12 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tim Bruijnzeels In-Reply-To: <152286976586.23998.1170348122023610014.idtracker@ietfa.amsl.com> Date: Thu, 5 Apr 2018 12:38:05 +0200 Cc: The IESG , Chris Morrow , draft-ietf-sidr-slurm@ietf.org, IETF SIDR , sidr-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1EFF9988-F988-4A4C-B860-B244C1A59A6E@ripe.net> References: <152286976586.23998.1170348122023610014.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.5.20) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719983d8f7763dc1396544427d90bd49203 Archived-At: Subject: Re: [sidr] Adam Roach's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 10:38:20 -0000 Dear Adam, all, Thank you for this feedback - indeed we struggled a bit with formally = specifying JSON and relied on examples. I believe that with your = suggestions we can improve this. As for IP address prefix notation - yes.. we should follow your = suggestion and cite RFC 4632 =C2=A73.1 for prefix-length notation (both = for IPv4 and IPv6), and RFC 5952 for the syntax of IPv6 addresses. I am = so used to doing it this way that it slipped my mind to specify this, = but of course it should be unambiguous. As I did most of the JSON text I will take it on me to re-work this text = and ask Di to merge it with the changes he is working on. There should = be a -08 version coming soon. Tim > On 4 Apr 2018, at 21:22, Adam Roach wrote: >=20 > Adam Roach has entered the following ballot position for > draft-ietf-sidr-slurm-07: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks to everyone who worked on this document. The mechanism seems = useful. >=20 > I'm concerned that the document doesn't describe the file format = itself; > rather, it relies on examples to provide vital, nonsupplemental = information > such as the names of JSON object members, expected encodings (e.g., = strings > versus numbers), and distinction between arrays and objects. I'm = making this a > DISCUSS because I think the ambiguity here -- and, in particular the = ambiguity > about IP address prefix notation -- will lead to non-interoperable > implementations. >=20 > Using section =C2=A73.2 as an example: >=20 >> A SLURM file consists of: >>=20 >> o A SLURM Version indication that MUST be 1 >>=20 >> o A slurmTarget element (Section 3.3) consisting of: >>=20 >> * Zero or more target elements. In this version of SLURM, there >> are two types of values for the target: ASN or Fully Qualified >> Domain Name(FQDN). If more than one target line is present, >> all targets MUST be acceptable to the RP. >>=20 >> o Validation Output Filters (Section 3.4), consisting of: >>=20 >> * An array of zero or more Prefix Filters, described in >> Section 3.4.1 >>=20 >> * An array of zero or more BGPsec Filters, described in >> Section 3.4.2 >>=20 >> o Locally Added Assertions (Section 3.5), consisting of: >>=20 >> * An array of zero or more Prefix Assertions, described in >> Section 3.5.1 >>=20 >> * An array of zero or more BGPsec Assertions, described in >> Section 3.5.2 >>=20 >=20 > As this is the normative description of the structure, I would have = expected an > indication that the file contains a JSON object (rather than, say, a = JSON > array), an indication that the version is to be encoded as a number = (rather than > a string), and clarification of what value members are expected to = contain. >=20 > For example, the following JSON object is in compliance with the = preceding > normative description (and, as far as I can tell, all other normative = text > in the document): >=20 > ["1", > ["65536", "rpki.example.com"], > [ > ["192.0.2.0/255.255.255.0", "All VRPs encompassed by prefix"], > ["64496", "All VPRs maching ASN"], > ["198.51.100.0/255.255.255.0", "64497", "All VRPs encompassed by = prefix, > matching ASN"] > ], > [ > ["64496", "All keys for ASN"], > ["Zm9v", "Key matching Router SKI"], > ["64497", "YmFy", "Key for ASN 64497 matching Router SKI"], > ], > [ > ["64496", "198.51.100.0/255.255.255.0", "My other important = route"], > ["64496", "2001:DB8::/FFFF:FFFF::", "48", > "My other important de-aggregated routes"], > ], > [ > ["64496", "My known key for my important ASN", > "", ""] > ] > ] >=20 > Fixing this should be pretty easy; the document simply needs text = added that > describes the JSON structure explicitly, with clear indications of how = values > are to be encoded. For example, the preceding text I quote becomes: >=20 > A SLURM file consists of a single JSON object containing the = following > members: >=20 > o A "slurmVersion" member that MUST be set to 1, encoded as a = number >=20 > o A "slurmTarget" member (Section 3.3) If more than one target line = is > present, all targets MUST be acceptable to the RP. The = "slurmTarget" > member is encoded as an array of zero or more objects. Each = object in the > array contains exactly one member. In this version of SLURM, the = member > may be named either: >=20 > * "asn", in which case it contains an ASN, or >=20 > * "hostname", in which case it contains a Fully Qualified Domain > Name (FQDN). >=20 > o A "validationOutputFilters" member (Section 3.4), whose value is = an > object. The object MUST contain exactly two members: >=20 > * A "prefixFilters" member, whose value is described in > Section 3.4.1 >=20 > * A "bgpsecFilters" member, whose value is described in > Section 3.4.2 >=20 > o A "locallyAddedAssertions" member (Section 3.5), whose value is = an > object. The object MUST contain exactly two members: >=20 > * A "prefixAssertions" member, whose value is described in > Section 3.5.1 >=20 > * A "bgpsecAssertions" member, whose value is described in > Section 3.5.2 >=20 >=20 > Gotchas to watch out for include: >=20 > - If you're using the word "element" to describe something in a JSON = object, > you probably need to find a more specific word. This document, for = example, > uses "element" instead of "member" in most places. >=20 > - Everywhere you use the word "structure," replace it with either = "array" or > "object," as appropriate. >=20 > - When values can be encoded as either a number or a string (e.g., as = with > "slurmVersion" above, or with AS numbers), indicate which encoding = is > expected. >=20 > - For IP prefixes, be clear about acceptable syntax. For example: is > the RFC 950 syntax ("192.0.2.0/255.255.255.0") acceptable? My = suggestion is > to cite RFC 4632 =C2=A73.1 for prefix-length notation (both for IPv4 = and IPv6), > and RFC 5952 for the syntax of IPv6 addresses. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The remaining comments are in document order. >=20 > = --------------------------------------------------------------------------= - >=20 > Title: >=20 > It seems odd to use the stylized capitalization (e.g., "nUmber") = without > following it by the "SLURM" acronym. Consider adding "(SLURM)" to the = title. >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A73.1: >=20 >> This document describes responses in the JSON [RFC8259] format. >=20 > I don't think this means to say "responses," does it? It appears to be > describing a JSON document rather than a request/response protocol. >=20 >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A73.3: >=20 >> A SLURM file MUST specify a "slurmTarget" element that identifies the >> environment in which the SLURM file is intended to be used. The >> "slurmTarget" element MAY have an empty array as its value, which >> means "applies to all". The meaning of the "slurmTarget" element, if >> present, is determined by the user. If a "slurmTarget" element is >> present, an RP SHOULD verify that the target is an acceptable value, >> and reject this SLURM file if the "slurmTarget" element is not >> acceptable. Each "slurmTarget" element contains merely one "asn" or >> one "hostname". An explanatory "comment" MAY be included in each >> "slurmTarget" element so that it can be shown to users of the RP >> software. >=20 > When reworking this paragraph in particular, please be careful to = distinguish > between the "slurmTarget" member and the elements in the array that = constitutes > its value. The preceding text calls both of these things = '"slurmTarget" > element,' which is very confusing. >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Apr 5 06:14:15 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6634D12751F; Thu, 5 Apr 2018 06:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHuQC25PvAah; Thu, 5 Apr 2018 06:14:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D804127241; Thu, 5 Apr 2018 06:14:07 -0700 (PDT) Received: from [172.18.0.15] (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w35DE5S9027181 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Apr 2018 08:14:06 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be [172.18.0.15] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Adam Roach X-Mailer: iPhone Mail (15D60) In-Reply-To: <1EFF9988-F988-4A4C-B860-B244C1A59A6E@ripe.net> Date: Thu, 5 Apr 2018 08:14:00 -0500 Cc: Chris Morrow , sidr-chairs@ietf.org, draft-ietf-sidr-slurm@ietf.org, The IESG , IETF SIDR Content-Transfer-Encoding: quoted-printable Message-Id: <520D0E60-3639-4ED3-B7C4-5FBDC8BCF0CE@nostrum.com> References: <152286976586.23998.1170348122023610014.idtracker@ietfa.amsl.com> <1EFF9988-F988-4A4C-B860-B244C1A59A6E@ripe.net> To: Tim Bruijnzeels Archived-At: Subject: Re: [sidr] Adam Roach's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 13:14:09 -0000 Thanks for your quick response! Feel free to reach out to me directly if you= find any particular part of the structure challenging to describe.=20 /a > On Apr 5, 2018, at 05:38, Tim Bruijnzeels wrote: >=20 > Dear Adam, all, >=20 > Thank you for this feedback - indeed we struggled a bit with formally spec= ifying JSON and relied on examples. I believe that with your suggestions we c= an improve this. >=20 > As for IP address prefix notation - yes.. we should follow your suggestion= and cite RFC 4632 =C2=A73.1 for prefix-length notation (both for IPv4 and I= Pv6), and RFC 5952 for the syntax of IPv6 addresses. I am so used to doing i= t this way that it slipped my mind to specify this, but of course it should b= e unambiguous. >=20 > As I did most of the JSON text I will take it on me to re-work this text a= nd ask Di to merge it with the changes he is working on. There should be a -= 08 version coming soon. >=20 > Tim >=20 >=20 >> On 4 Apr 2018, at 21:22, Adam Roach wrote: >>=20 >> Adam Roach has entered the following ballot position for >> draft-ietf-sidr-slurm-07: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> Thanks to everyone who worked on this document. The mechanism seems usefu= l. >>=20 >> I'm concerned that the document doesn't describe the file format itself; >> rather, it relies on examples to provide vital, nonsupplemental informati= on >> such as the names of JSON object members, expected encodings (e.g., strin= gs >> versus numbers), and distinction between arrays and objects. I'm making t= his a >> DISCUSS because I think the ambiguity here -- and, in particular the ambi= guity >> about IP address prefix notation -- will lead to non-interoperable >> implementations. >>=20 >> Using section =C2=A73.2 as an example: >>=20 >>> A SLURM file consists of: >>>=20 >>> o A SLURM Version indication that MUST be 1 >>>=20 >>> o A slurmTarget element (Section 3.3) consisting of: >>>=20 >>> * Zero or more target elements. In this version of SLURM, there >>> are two types of values for the target: ASN or Fully Qualified >>> Domain Name(FQDN). If more than one target line is present, >>> all targets MUST be acceptable to the RP. >>>=20 >>> o Validation Output Filters (Section 3.4), consisting of: >>>=20 >>> * An array of zero or more Prefix Filters, described in >>> Section 3.4.1 >>>=20 >>> * An array of zero or more BGPsec Filters, described in >>> Section 3.4.2 >>>=20 >>> o Locally Added Assertions (Section 3.5), consisting of: >>>=20 >>> * An array of zero or more Prefix Assertions, described in >>> Section 3.5.1 >>>=20 >>> * An array of zero or more BGPsec Assertions, described in >>> Section 3.5.2 >>>=20 >>=20 >> As this is the normative description of the structure, I would have expec= ted an >> indication that the file contains a JSON object (rather than, say, a JSON= >> array), an indication that the version is to be encoded as a number (rath= er than >> a string), and clarification of what value members are expected to contai= n. >>=20 >> For example, the following JSON object is in compliance with the precedin= g >> normative description (and, as far as I can tell, all other normative tex= t >> in the document): >>=20 >> ["1", >> ["65536", "rpki.example.com"], >> [ >> ["192.0.2.0/255.255.255.0", "All VRPs encompassed by prefix"], >> ["64496", "All VPRs maching ASN"], >> ["198.51.100.0/255.255.255.0", "64497", "All VRPs encompassed by prefix= , >> matching ASN"] >> ], >> [ >> ["64496", "All keys for ASN"], >> ["Zm9v", "Key matching Router SKI"], >> ["64497", "YmFy", "Key for ASN 64497 matching Router SKI"], >> ], >> [ >> ["64496", "198.51.100.0/255.255.255.0", "My other important route"], >> ["64496", "2001:DB8::/FFFF:FFFF::", "48", >> "My other important de-aggregated routes"], >> ], >> [ >> ["64496", "My known key for my important ASN", >> "", ""] >> ] >> ] >>=20 >> Fixing this should be pretty easy; the document simply needs text added t= hat >> describes the JSON structure explicitly, with clear indications of how va= lues >> are to be encoded. For example, the preceding text I quote becomes: >>=20 >> A SLURM file consists of a single JSON object containing the following >> members: >>=20 >> o A "slurmVersion" member that MUST be set to 1, encoded as a number >>=20 >> o A "slurmTarget" member (Section 3.3) If more than one target line is >> present, all targets MUST be acceptable to the RP. The "slurmTarget" >> member is encoded as an array of zero or more objects. Each object in= the >> array contains exactly one member. In this version of SLURM, the mem= ber >> may be named either: >>=20 >> * "asn", in which case it contains an ASN, or >>=20 >> * "hostname", in which case it contains a Fully Qualified Domain >> Name (FQDN). >>=20 >> o A "validationOutputFilters" member (Section 3.4), whose value is an >> object. The object MUST contain exactly two members: >>=20 >> * A "prefixFilters" member, whose value is described in >> Section 3.4.1 >>=20 >> * A "bgpsecFilters" member, whose value is described in >> Section 3.4.2 >>=20 >> o A "locallyAddedAssertions" member (Section 3.5), whose value is an >> object. The object MUST contain exactly two members: >>=20 >> * A "prefixAssertions" member, whose value is described in >> Section 3.5.1 >>=20 >> * A "bgpsecAssertions" member, whose value is described in >> Section 3.5.2 >>=20 >>=20 >> Gotchas to watch out for include: >>=20 >> - If you're using the word "element" to describe something in a JSON obje= ct, >> you probably need to find a more specific word. This document, for examp= le, >> uses "element" instead of "member" in most places. >>=20 >> - Everywhere you use the word "structure," replace it with either "array"= or >> "object," as appropriate. >>=20 >> - When values can be encoded as either a number or a string (e.g., as wit= h >> "slurmVersion" above, or with AS numbers), indicate which encoding is >> expected. >>=20 >> - For IP prefixes, be clear about acceptable syntax. For example: is >> the RFC 950 syntax ("192.0.2.0/255.255.255.0") acceptable? My suggestion= is >> to cite RFC 4632 =C2=A73.1 for prefix-length notation (both for IPv4 and= IPv6), >> and RFC 5952 for the syntax of IPv6 addresses. >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> The remaining comments are in document order. >>=20 >> -------------------------------------------------------------------------= -- >>=20 >> Title: >>=20 >> It seems odd to use the stylized capitalization (e.g., "nUmber") without >> following it by the "SLURM" acronym. Consider adding "(SLURM)" to the tit= le. >>=20 >> -------------------------------------------------------------------------= -- >>=20 >> =C2=A73.1: >>=20 >>> This document describes responses in the JSON [RFC8259] format. >>=20 >> I don't think this means to say "responses," does it? It appears to be >> describing a JSON document rather than a request/response protocol. >>=20 >>=20 >> -------------------------------------------------------------------------= -- >>=20 >> =C2=A73.3: >>=20 >>> A SLURM file MUST specify a "slurmTarget" element that identifies the >>> environment in which the SLURM file is intended to be used. The >>> "slurmTarget" element MAY have an empty array as its value, which >>> means "applies to all". The meaning of the "slurmTarget" element, if >>> present, is determined by the user. If a "slurmTarget" element is >>> present, an RP SHOULD verify that the target is an acceptable value, >>> and reject this SLURM file if the "slurmTarget" element is not >>> acceptable. Each "slurmTarget" element contains merely one "asn" or >>> one "hostname". An explanatory "comment" MAY be included in each >>> "slurmTarget" element so that it can be shown to users of the RP >>> software. >>=20 >> When reworking this paragraph in particular, please be careful to disting= uish >> between the "slurmTarget" member and the elements in the array that const= itutes >> its value. The preceding text calls both of these things '"slurmTarget" >> element,' which is very confusing. >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Fri Apr 6 06:15:44 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D931E126DEE for ; Fri, 6 Apr 2018 06:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N02TkKPKdXfn for ; Fri, 6 Apr 2018 06:15:37 -0700 (PDT) Received: from smtpbgsg2.qq.com (smtpbgsg2.qq.com [54.254.200.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2A81201FA for ; Fri, 6 Apr 2018 06:15:36 -0700 (PDT) X-QQ-mid: bizesmtp3t1523020529trpaq2833 Received: from [192.168.3.3] (unknown [118.247.2.33]) by esmtp4.qq.com (ESMTP) with id ; Fri, 06 Apr 2018 21:15:28 +0800 (CST) X-QQ-SSF: 00400000002000F0FG40000A0000000 X-QQ-FEAT: Me8Xob1wlXIWF7usFVt6LaGiJVBoJbT9Z+BdR2ZO5Qua/nW8Fj9QeOcIg+qA0 VgWhkAU7rWPv77tE6v61ifxmqQIctxqlho7Ug2zwT0FMInOcoheWW6DNs9wVsa926/zvKIg I5TseqbZaIPAzqg+pooot11cGxfA3SzSmByB0ro+9j9s2dKI6ISYvCaRszznfhXoAC+zhqm 7J4MwFgISdVSHNcxrmwnNTF3FYBVzf+Z57etZFm92n9FFNrooitdrFXEvDMAZfO+A3seuLP XREI3Yg0F9QiilCMFz8nTOhaZ1KHx8AHWruvtfaX2CqhCU X-QQ-GoodBg: 2 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: <152243246452.20520.7968873255606309518.idtracker@ietfa.amsl.com> Date: Fri, 6 Apr 2018 21:15:28 +0800 Cc: The IESG , morrowc@ops-netman.net, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <24005739-88B6-4D51-8ED5-217E141A2D23@zdns.cn> References: <152243246452.20520.7968873255606309518.idtracker@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign4 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] Benjamin Kaduk's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 13:15:43 -0000 Benjamin, Thanks very much for your comments. Please see my responses in lines. > =D4=DA 2018=C4=EA3=D4=C231=C8=D5=A3=AC01:54=A3=ACBenjamin Kaduk = =D0=B4=B5=C0=A3=BA >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-sidr-slurm-07: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The directorate reviews have some good comments, especially about = expanding > acronyms/defining terms. >=20 > I think Section 3.3 would benefit from greater clarity about = individual > components of the JSON array that is the value of the "slurmTarget" = element, > versus that element itself. (Also, slurmTarget appears to be = mandatory, so > talking about cases where it is present seems strange, and presumably = a > nonempty value being present is the desired criterion.) >=20 > I'm also not entirely sure I understand the intended semantics -- > when first introduced in Section 3.2, we say that "all targets MUST > be acceptable to the RP". (Presumably that includes both ASN and > FQDN entries.) Does this mean that if the same SLURM file is > provided to multiple RPs, those RPs both need to be "responsible > for" all the ASNs and FQDNS contained therein? Would this present a > limit on the ability to reuse SLURM files for multiple recipients > within a single administrative domain (that may span multiple ASNs > and FQDNs)? >=20 > Some editorial suggestions follow. >=20 > Abstract: >=20 > OLD: >=20 > [...] ISPs can also be able to use the RPKI to validate the > path of a BGP route. >=20 > NEW: >=20 > [...] ISPs can also use the RPKI to validate the > path of a BGP route. >=20 ACK. > Section 3.2 >=20 > OLD: > o A SLURM Version indication that MUST be 1 >=20 > NEW: > o A SLURM Version indication. This document specifies version 1. >=20 ACK. > Also, in >=20 > * Zero or more target elements. In this version of SLURM, there > are two types of values for the target: ASN or Fully Qualified > Domain Name(FQDN). If more than one target line is present, > all targets MUST be acceptable to the RP. >=20 > What=A1=AFs the difference between a target element and a target line? >=20 We authors have decided to drop the slurmTarget element completely.=20 Initially the implementation team was thinking that it would be useful = to have the ability to offer the same set of SLURM files to all RPs = deployed in a network, where local config of the RP would then evaluate = the applicability of each file. However, now that both implementations = progressed we reconsider and we feel that it would be better to deal = with this on the provisioning side. I.e. only offer the SLURM file(s) = relevant to each RP. > Section 3.5 (both subsections): >=20 > "is locally configured with" does not mention SLURM at all as being > involved in that configuration; perhaps it should. >=20 We authors are going to make changes as follows:=20 3.5.1: OLD: Each RP is locally configured with a (possibly empty) array of ROA Prefix Assertions. NEW: SLURM file(s) can be used to configure an RP with a (possibly empty) = array of ROA Prefix Assertions. And similarly in 3.5.2 OLD: Each RP is locally configured with a (possibly empty) array of BGPsec Assertions. NEW: SLURM file(s) can be used to configure an RP with a (possibly empty) = array of BGPsec Assertions. > Section 4.2 >=20 > [...] To do so, the RP MUST > check the entries of SLURM file with regard to overlaps of the INR > assertions and report errors to the sources that created these SLURM > files in question. >=20 > The "report errors to the sources" part seems ineligible for > MUST-level requirement. >=20 > Also, in case of conflict, does the "MUST NOT use them" apply to all > SLURM files, only the ones with directly conflicting inputs, or only > enough files to remove the conflict? There is a MAY in the first sentence after all. We will add in this section that =A1=AEThe RP gets multiple SLURM files = as a set, and the whole set MUST be rejected in case of any overlaps = between SLURM files.' >=20 > Section 6 >=20 > I'm always a little sad to see security-relevant functionality (such > as the transport with authenticity and integrity protection of SLRUM > files over the network) left as out of scope with no examples of > reasonable usage given. >=20 We authors intend to work on a proposed standard mechanism for updating = SLURM files through a secure API in the near future. The very proposal is intended to be in a separate draft for SIDROPS.=20 > I also wonder if we would benefit from a little discussion of the > potential routing issues that could arise from using a "broken" (or > deliberately adversarial) SLURM file, though I expect that the > target audience is probably pretty familiar with these already. >=20 Well, it has been stated in this document: 'Errors in the SLURM file used by an RP can undermine the security offered by the RPKI, to that RP. It could declare as invalid ROAs that would otherwise be valid, and vice versa. As a result, an RP must carefully consider the security implications of the SLURM file being used, especially if the file is provided by a third party.' It is not clear to us what more we should cover here. Di From nobody Fri Apr 6 07:02:56 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659D51270AB for ; Fri, 6 Apr 2018 07:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy8Xve-au5Cq for ; Fri, 6 Apr 2018 07:02:50 -0700 (PDT) Received: from smtpbg65.qq.com (smtpbg65.qq.com [103.7.28.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01FD4120726 for ; Fri, 6 Apr 2018 07:02:49 -0700 (PDT) X-QQ-mid: bizesmtp16t1523023363tiz7w29d Received: from [192.168.3.3] (unknown [118.247.2.33]) by esmtp4.qq.com (ESMTP) with id ; Fri, 06 Apr 2018 22:02:42 +0800 (CST) X-QQ-SSF: 00400000002000F0FH40B00A0000000 X-QQ-FEAT: 5gms5Di3ODi1oT/Z4FmmdHhtRzdiEY5SKy4L5fBCJH0yPQgj07BKU9iCiwoCT GivUz4cCopI83upytJZMK7apC1vFC5aPQa/hbhuO/eXyWZ043rwVWjaUSBWZuXGr2AbjO3W DqOwbcJpVKzWpm6vptYxScp1GtakkY0cC7sawW7DJW94jCjbBNgSU9xfcrrceshgCsrjmhh lMgdrGLo4jnYKMow7Ngf9euuRHoUUA/RbBl5ZG8JHpWJ7hf/FgJXaakC+qjA6cePG2XXpuB OclvkHtn2GjJHKUAs1E0aayThL8lGFtXdCgCemNW4EXMUB X-QQ-GoodBg: 2 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: <152261657190.23824.4759371193986790926.idtracker@ietfa.amsl.com> Date: Fri, 6 Apr 2018 22:02:20 +0800 Cc: The IESG , morrowc@ops-netman.net, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9958A258-44B0-4965-B1C9-5E76031198C2@zdns.cn> References: <152261657190.23824.4759371193986790926.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign1 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] Warren Kumari's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 14:02:55 -0000 Warren, Thanks very much for your comments. Please see my responses in lines. > =D4=DA 2018=C4=EA4=D4=C22=C8=D5=A3=AC05:02=A3=ACWarren Kumari = =D0=B4=B5=C0=A3=BA >=20 > Warren Kumari has entered the following ballot position for > draft-ietf-sidr-slurm-07: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I don't understand the targeting as it related to domain/host names = (and > suspect that others will have the same issue). >=20 >> =46rom section 3.3: > " If a "slurmTarget" element is > present, an RP SHOULD verify that the target is an acceptable value, > and reject this SLURM file if the "slurmTarget" element is not > acceptable.... Accordingly, the SLURM file > source needs to indicate which RP(s) should make use of the file by > adding the domain name(s) of the RP(s) to the SLURM file target... > Such a target value is a server name expressed in FQDN. >=20 > "slurmTarget": [ > { > "hostname": "rpki.example.com", > "comment": "This file is intended for RP server = rpki.example.com" > } > ] >=20 > So, if I want to target multiple RPs (rpki1.example.com, = rpki2.example.com) can > I do: >=20 > "slurmTarget": [ > { > "hostname": "example.com", > "comment": "This file is intended for RP server = rpki.example.com" > } > ] >=20 > ? > The "domain names(s)" versus "hostname" vs "server name expressed in = FQDN" text > is handwavey. I'm assuming that I'd need to do: >=20 > "slurmTarget": [ > { > "hostname": "rpki1.example.com", > "comment": "This file is intended for RP server = rpki1.example.com" > }, > { > "hostname": "rpki2.example.com", > "comment": "This file is intended for the RP server, = rpki2.example.com" > }, > ]" > Can you please make this clearer, and hopefully add more targets to = the > examples? This seems like an easy fix / clarification, happy to clear = once it > is, er, clear. >=20 >=20 We authors have decided to drop the slurmTarget element completely.=20 Initially the implementation team was thinking that it would be useful = to have the ability to offer the same set of SLURM files to all RPs = deployed in a network, where local config of the RP would then evaluate = the applicability of each file. However, now that both implementations = (RIPE NCC Validator and RPSTIR) progressed we reconsider and we feel = that it would be better to deal with this on the provisioning side. I.e. = only offer the SLURM file(s) relevant to each RP. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I have a few questions and editorial comments: >=20 > 1: Section Abstract: > ISPs can also be able to use the RPKI to validate the path of a BGP = route. > I think you meant =A1=B0ISPs can also use the RPKI..." ACK.=20 >=20 > 2: Section 1. Introduction > "However, an "RPKI relying party" (RP) may want to override some of = the > information expressed via putative Trust Anchor(TA) and the = certificates > downloaded from the RPKI repository system." I think this should be = either "a > putative Trust Anchor (TA)" or "putative Trust Anchors (TA)" (single = vs > plurals). I agree with others that "putative TA" is not a well known = term - > perhaps you can find a better one? >=20 We will use =A1=AEconfigured Trust Anchor(s)=A1=AF instead. > Section 3.4.1. Validated ROA Prefix Filters > In the "prefixFilters examples", I think it would be helpful to update = the > comments to be more explicit about what is being matched (e.g"All VRPs = covered > by 198.51.100.0/24 and matching AS 64497") >=20 >=20 ACK. And we will update JSON related content in this draft based on Adam=A1=AFs= suggestions.=20 Di= From nobody Fri Apr 6 07:08:14 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6770B1250B8 for ; Fri, 6 Apr 2018 07:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abYFv7FMuz7E for ; Fri, 6 Apr 2018 07:08:07 -0700 (PDT) Received: from smtpbgau2.qq.com (smtpbgau2.qq.com [54.206.34.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10FFA1201FA for ; Fri, 6 Apr 2018 07:08:06 -0700 (PDT) X-QQ-mid: bizesmtp7t1523023678tumusjr4f Received: from [192.168.3.3] (unknown [118.247.2.33]) by esmtp4.qq.com (ESMTP) with id ; Fri, 06 Apr 2018 22:07:57 +0800 (CST) X-QQ-SSF: 00400000002000F0FH40B00A0000000 X-QQ-FEAT: u9yQq91qdYUlvwcxYK7vDSrpdMxL8PSZJv9DwzQYA4XJp4KfAmCpR1he3Y72B 7xEXLG6kcoSAh3c1CrnewBw8D7jJujJIiIHTIEu6VQHO61r6JyTfpEWCMubsk1kihblhkBU Fn+8Jyi3z1dRmQ9GzgMVusJ/pgbrQji0muYyRE9bbdbwOxERlmUDGNanahNQpNcPxXyBEOv c3jrmaJ1ItQkmHQ5ktL/Fu9NrYBW2K0tuZF3fa2I4CLlqKsEvSsjZyRRp9fhqqi/1/fUDRo TSLvWI5sSEdknHR+xpiXxnMyFuvTKvBmt8eogkZq6l9t3i X-QQ-GoodBg: 2 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: <152266604967.7312.10722440885591415777.idtracker@ietfa.amsl.com> Date: Fri, 6 Apr 2018 22:07:35 +0800 Cc: The IESG , morrowc@ops-netman.net, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152266604967.7312.10722440885591415777.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign2 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 14:08:12 -0000 Alexey, Thanks very much for your comments. Please see authors' responses in lines. > =D4=DA 2018=C4=EA4=D4=C22=C8=D5=A3=AC18:47=A3=ACAlexey Melnikov = =D0=B4=B5=C0=A3=BA >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-sidr-slurm-07: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I agree with Warren's DISCUSS. >=20 > Additionally, one little, but important thing that I would like you to = fix: >=20 > In Section 3.4.2 and 3.5.2, when referencing Base64 [RFC4648], you = need to > specify which version you are using. I think you want to use the = version in > Section 4 (and not Section 5) of this document. It would also be = useful to > specify whether trailing "=3D" need to be present in base64 values. >=20 >=20 We authors think this is really a good point. We will say in next version:=20 The Router SKI is the Base64 encoding without trailing =A1=AE=3D=A1=AE = (Section 5 of RFC4648 ) of the certificate=A1=AFs Subject Public Key as = described in Section 4.8.2. of RFC6487.=20 Di From nobody Fri Apr 6 07:20:51 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA591270AE for ; Fri, 6 Apr 2018 07:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGNyrtlGkVB1 for ; Fri, 6 Apr 2018 07:20:45 -0700 (PDT) Received: from smtpbgsg1.qq.com (smtpbgsg1.qq.com [54.254.200.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9171D1201FA for ; Fri, 6 Apr 2018 07:20:44 -0700 (PDT) X-QQ-mid: bizesmtp16t1523024377tleov3lb Received: from [192.168.3.3] (unknown [118.247.2.33]) by esmtp4.qq.com (ESMTP) with id ; Fri, 06 Apr 2018 22:19:36 +0800 (CST) X-QQ-SSF: 00400000002000F0FH40B00A0000000 X-QQ-FEAT: 9MsTBLS6yXGj+PsKdj6vBAmVux/EjqH0Dwa/CsyXZQG5qFFBwBUixZpFZ7pAE Y7o2WXuRoy7H04jsGEJD/5DVTwOxtugAeFpFykJ1JP3HCCqyY4oqxYPkoYknWj0hTiwnasP yMhgKS3XZpFhm0KW2Ax2r8QQ3m8xbBI1tbAuLLuNEJzEExYLUYrO3mvSz8jwCYsODZoXJC7 sFVdI6DdClBq1Rc6q0E/4E5zlZPjZnlrXkX56O0agBnaxFGEUjsxBOjYzBSMcrOImod1mrh SKo2qdOPS+q6Eyx6SSwIHQyCkLZFrKr2fdMSRyp4PEqvDYqTTo5YS/bkM= X-QQ-GoodBg: 2 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: <152268817614.31085.6790269677708093564.idtracker@ietfa.amsl.com> Date: Fri, 6 Apr 2018 22:19:14 +0800 Cc: The IESG , morrowc@ops-netman.net, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152268817614.31085.6790269677708093564.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign4 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] Eric Rescorla's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 14:20:50 -0000 Eric, Thanks very much for your comments. Please see authors' responses in lines. > =D4=DA 2018=C4=EA4=D4=C23=C8=D5=A3=AC00:56=A3=ACEric Rescorla = =D0=B4=B5=C0=A3=BA >=20 > Eric Rescorla has entered the following ballot position for > draft-ietf-sidr-slurm-07: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > path of a BGP route. However, ISPs may want to establish a local > view of the RPKI to control its own network while making use of RPKI > data. The mechanisms described in this document provide a simple = way >=20 > Nit: their network >=20 > the information expressed via putative Trust Anchor(TA) and the > certificates downloaded from the RPKI repository system. For > instances, [RFC6491] recommends the creation of ROAs that would >=20 > I don't really understand this sentence. Why =A1=B0putatve" We authors will go with =A1=B0configured Trust Anchor(s) (TAs)=A1=B1 >=20 > operators are hereby called Simplified Local internet nUmber = Resource > Management with the RPKI (SLURM). >=20 > It would help here to say that this includes filtering. >=20 We will make changes as follows: OLD: This motivates creation of mechanisms that enable a network operator = to publish a variant of RPKI hierarchy (for its own use and that of its = customers) at its discretion. NEW: This motivates creation of mechanisms that enable a network operator = to publish exception to the RPKI in the form of filters and additions = (for its own use and that of its customers) at its discretion. > In general, the primary output of an RP is the data it sends to > routers over the rpki-rtr protocol. The rpki-rtr protocol enables > routers to query an RP for all assertions it knows about (Reset >=20 > citation for rpki-rtr plese. ACK.=20 >=20 > members that are not defined here MUST NOT be used in SLURM Files. > An RP MUST consider any deviations from the specification an error. > Future additions to the specifications in this document MUST use an >=20 > Nit: errors. >=20 ACK.=20 > acceptable. Each "slurmTarget" element contains merely one "asn" or > one "hostname". An explanatory "comment" MAY be included in each > "slurmTarget" element so that it can be shown to users of the RP >=20 > Is this exclusive or? >=20 > Emergency Response Team Coordination, the SLURM file source may > generate a SLURM file that is to be applied to only one specific RP. > This file can take advantage of the "target" element to restrict the >=20 > I am having trouble reading this sentence. Can you please rephrase. We authors have decided to drop slurmTarget element. >=20 > [RFC6487]. This is the value of the ASN.1 OCTET STRING without the > ASN.1 tag or length fields. > IMPORTANT: There is an opportunity for ambiguity here in case the SPKI = was not > DER-encoded. I assume you mean this must be taken directly from the = cert? >=20 Good point.=20 We will say in next version: The Router SKI is the Base64 encoding without trailing =A1=AE=3D=A1=AE = (Section 5 of RFC4648 ) of the certificate=A1=AFs Subject Public Key as = described in Section 4.8.2. of RFC6487.=20 The Router Public Key is router public key=A1=AFs subjectPublicKeyInfo = value, as described in RFC8208. This is the full ASN.1 DER encoding of = the subjectPublicKeyInfo, including the ASN.1 tag and length values of = the subjectPublicKeyInfo SEQUENCE. > The following JSON structure represents an array of > "prefixAssertions" with an element for each use case listed above: >=20 > I guess that the semantics here are obvious, but perhaps you could = state them > explicitly, given that this is actually not exactly the same as an = ROA. ACK.=20 And we will update JSON related content throughout this draft based on = your suggestion together with Adam=A1=AFs.=20 >=20 > 3.5.2. BGPsec Assertions > IMPORTANT: It seems even less obvious what the semantics are here for = injecting > BGPSec assertions. How do you reconstruct the BGPSec data. We will make changes as follows: OLD: Each RP is locally configured with a (possibly empty) array of BGPsec Assertions. This array is added to the RP's output. NEW: Each RP is locally configured with a (possibly empty) array of BGPsec Assertions. Each BGPSec Assertion contains the same data that would otherwise be extracted from a BGPSect Router Certificate [RFC8209] and communicated in the RPKI to Router Protocol version 1 protocol [RFC8210]. >=20 > contained by any prefix in any or > in file Z. >=20 > OK, so you are going to error out even if there are assertions which = are > identical? >=20 >=20 Duplicate assertions are idempotent, but the RPKI to Router Protocol explicitly filters out duplicates in the communication with the router. Di From nobody Fri Apr 6 07:24:53 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F100E1201FA for ; Fri, 6 Apr 2018 07:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 kCyvNqskmH3c for ; Fri, 6 Apr 2018 07:24:46 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 2AF031250B8 for ; Fri, 6 Apr 2018 07:24:45 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id 71-v6so1181049oie.12 for ; Fri, 06 Apr 2018 07:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CNfDE35ewgA6IGO8GHJJVYlzvUHfwgUmY/tNSDBxsPs=; b=0+IDNbBX/wnwaQi3qzOET8urbnGCx+BNQB3CwqqMotctsmvAX44sFM3ZKNIlvsxN6C 7YnzmM7kZsB3drTEyNmWokJgqgHNM9nd0uga0arKGMwVYDbEcteiSe18Ab/9ANzdb3WN pDUSO8DoFi48gYYJKEeKCSdGe8+iptBuzRbjK8es5Cg/HtvUE/0KwX2pZoFpbioAKkUV zEjSiTlcCaTa4R3W939o1NnAWE7AnTFsF5fKy3jcMz1yegsfxktujduuiQORZ+Ph+cYg l7KrYJHqyCKq1WCGo1k5CLSWPASK1KJSkUrgCicBgfx7bUaMBvulkL6kCn/B6Ag5QOMQ ktQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CNfDE35ewgA6IGO8GHJJVYlzvUHfwgUmY/tNSDBxsPs=; b=hCho2LJJpERG3Fe/8upsUDTogjYysMH2KVPmAa8ot51PxQuSkW5ybKHLxRIxIHKhPD A659bMvI7E5XDn6mn15MB96otai7UXjmEMdfGB0FU4234VkwZ0Z5/Cxrn3M8/teaAJW6 nZZ43rUttBtLPE8ZalJ+KQT2qjvHc38slapqbRBn56W2O9Ih3+bMTQlRSPsy3ad7dZJ0 Srphz3/PlwJ978qOUIKVsalWZGmgRysZP6dBlJyMvjtKve4bn+IkU4SKSTK3To0z5B7h mhQMvpGMIUGVn60y0ekz9kuaaeC/yBZ89uXUlA6bDkPyH6J5rJpBoiRRo+fIxWZMOe9I RvEQ== X-Gm-Message-State: ALQs6tALjpEau6eIkjTwViuAcTiqhAErWOnFBkuZQ0yE5orFnNeYSS2s y+FDcpVp+M0TxdAE+IKloPxLGsSLnGRgJPqXppUKX+hT X-Google-Smtp-Source: AIpwx499wdvu/OK3OBWqWb8+fg05KrH8Pk+7G3KHIb5lO0A8RNFShVeXQHJJOnPQ37/iSXomy/9mfYxMVEYImT8v8YM= X-Received: by 2002:aca:c592:: with SMTP id v140-v6mr16041411oif.92.1523024684593; Fri, 06 Apr 2018 07:24:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.18.130 with HTTP; Fri, 6 Apr 2018 07:24:04 -0700 (PDT) In-Reply-To: References: <152268817614.31085.6790269677708093564.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Fri, 6 Apr 2018 07:24:04 -0700 Message-ID: To: Di Ma Cc: The IESG , Chris Morrow , draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000004f47a405692ed1d8" Archived-At: Subject: Re: [sidr] Eric Rescorla's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 14:24:48 -0000 --0000000000004f47a405692ed1d8 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 6, 2018 at 7:19 AM, Di Ma wrote: > > > > contained by any prefix in any or > > in file Z. > > > > OK, so you are going to error out even if there are assertions which are > > identical? > > > > > > Duplicate assertions are idempotent, but the RPKI to Router Protocol > explicitly filters out duplicates in the communication with the router. > Hmm... That's not how I read this text. I read it rather that if the same exceptions in two files, it caused an error. So maybe some clarification needed. -Ekr > Di > > > > --0000000000004f47a405692ed1d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 6, 2018 at 7:19 AM, Di Ma <madi@zdns.cn> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 contained by any prefix in any <p= refixAssertions> or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <prefixFilters> in file Z.
>
> OK, so you are going to error out even if there are assertions which a= re
> identical?
>
>

Duplicate assertions are idempotent, but the RPKI to Router Protocol=
explicitly filters out duplicates in the communication with the router.
=

Hmm... That's not how I read this text= . I read it rather that if the same exceptions
in two files, it c= aused an error. So maybe some clarification needed.

-Ekr


Di




--0000000000004f47a405692ed1d8-- From nobody Fri Apr 6 07:30:00 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE70A1270AC for ; Fri, 6 Apr 2018 07:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNrcorHKozQd for ; Fri, 6 Apr 2018 07:29:53 -0700 (PDT) Received: from smtpbgau2.qq.com (smtpbgau2.qq.com [54.206.34.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277E21201FA for ; Fri, 6 Apr 2018 07:29:52 -0700 (PDT) X-QQ-mid: bizesmtp3t1523024985tvkpi2n95 Received: from [192.168.3.3] (unknown [118.247.2.33]) by esmtp4.qq.com (ESMTP) with id ; Fri, 06 Apr 2018 22:29:44 +0800 (CST) X-QQ-SSF: 00400000002000F0FH40B00A0000000 X-QQ-FEAT: Q4mUGnBphwP5vxxIvtVyWDRIkVc5kGzHc4w6SXX6eMc7HKXpiOq6oxe6GUh82 S6gVPILIa4kxXjS8Du9vKvIImlhHAIr4ZD4LA764yjU7lpoCuugJFmBJ3/Rw7v43I2K0BYt YcWOSCRB/lZlL+W5707RdUlgGHVrMuIVSkw7/pTfwmwFRcpeez470wFm6ZNOmoOH61Fxz6Z jmzmf7s/3C7LZNmSXHViLk4Nm3jc0faZkn7qooKco9eRzuFelrPy2T1TnTb8vC8yK0MLtuz Y4iqBpfhxu+tN9nLZ+mIaLJCzIcd+ZBR7o8obARywCGWBWCis7OZOtmfw= X-QQ-GoodBg: 2 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: <152278460436.22775.8518027666585390285.idtracker@ietfa.amsl.com> Date: Fri, 6 Apr 2018 22:29:44 +0800 Cc: The IESG , morrowc@ops-netman.net, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4339A019-F124-4B01-8554-88A8C085A430@zdns.cn> References: <152278460436.22775.8518027666585390285.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign4 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 14:29:59 -0000 Ben, Thanks very much for your comments. Please see authors' responses in lines. > =D4=DA 2018=C4=EA4=D4=C24=C8=D5=A3=AC03:43=A3=ACBen Campbell = =D0=B4=B5=C0=A3=BA >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-sidr-slurm-07: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Major Comments: >=20 > =A1=EC6: I also agree with Benjamin's sadness about the security = considerations. The > section really should at least discuss the potential consequences of = an > adversary inserting a false slurm file, modifying one on the fly, or > eavesdropping on one. We authors intend to work on a proposed standard mechanism for updating = SLURM files through a secure API in the near future. The very proposal is intended to be in a separate draft for SIDROPS.=20 >=20 > Minor Comments: >=20 > =A1=EC1.1: The document contains at least a few lower case instances = of "must". > Please consider using the boilerplate from RFC 8174. >=20 ACK.=20 > =A1=EC3.3, 1st paragraph: "RP SHOULD verify that the target is an = acceptable value" > What is the criteria for acceptability? As we authors have decided to drop slurmTarget element, this is no = longer an issue :-) >=20 > =A1=EC8.2, " [RFC4648]": The document requires Base64 encoding. = Doesn't that make > this a normative reference? But it has been listed as a normative reference.=20 >=20 > Editorial Comments and Nits: >=20 > [significant] Abstract (and throughout the document): >=20 > I don't find the term "local view of the RPKI" to be descriptive. = IIUC, we are > talking about overriding assertions that come from the RPKI based on = local (or > possibly 3rd party) knowledge. This seems to me to be a different = thing than > providing a "local view of the RPKI", and I certainly would not have = gotten a > sense of that difference from the Abstract alone, and possibly not the > introduction. We will make the change as follows: OLD: However, ISPs may want to establish a local view of the RPKI to = control its own network while making use of RPKI data. NEW: However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. Hopefully this will give context to the term =A1=AElocal view=A1=AF = throughout the document. >=20 > =A1=EC1, last paragraph: Please expand or define rpki-rtr on first = mention. ACK.=20 >=20 > =A1=EC3.4.1: Please expand SKI on first mention. (You do so in the = second mention > :-) ) >=20 >=20 ACK.=20 Di= From nobody Fri Apr 6 07:33:24 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01411270AE for ; Fri, 6 Apr 2018 07:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjSmZcEmHto8 for ; Fri, 6 Apr 2018 07:33:18 -0700 (PDT) Received: from smtpbgau2.qq.com (smtpbgau2.qq.com [54.206.34.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0061201FA for ; Fri, 6 Apr 2018 07:33:17 -0700 (PDT) X-QQ-mid: bizesmtp4t1523025190t2ssf5ngy Received: from [192.168.3.3] (unknown [118.247.2.33]) by esmtp4.qq.com (ESMTP) with id ; Fri, 06 Apr 2018 22:33:08 +0800 (CST) X-QQ-SSF: 00400000002000F0FH40B00A0000000 X-QQ-FEAT: v5tGZoxzs3GMOEL+URl79HkOcXcJGh8Tq+mmBQkGq+scWCqXd7SrjoW1qeAF1 nJyj/2dtV3Ctrvryg8fv4pntLHatzj+/1xgCKL8dzJ63UKAaUarqx55M4lwsmX4fZzRhQQP vM8no7wt8XuldxhQ2eVNeybj8ZGFsG4Q4hOtH6/CMs1NePaM7YA3QtLucP7h0g4cM1pLizW A9Cl5blY63i11Vc2T60Gf46fFAJXsIdHBPC0igHpfG4JMxG1CIu5r2+QtUyX6hECepNBHkp Bfq2wpnfyBue1rv5P/YzftB4jB8I2C3kHa2mgd5e25vhVAhxoVfqeEBbE= X-QQ-GoodBg: 2 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: <152286484194.23960.17788058701508276433.idtracker@ietfa.amsl.com> Date: Fri, 6 Apr 2018 22:33:08 +0800 Cc: The IESG , morrowc@ops-netman.net, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152286484194.23960.17788058701508276433.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign2 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 14:33:23 -0000 Alissa, Thanks very much for your comments. Is BCP 14 exactly the same document as RFC 2119? Di > =D4=DA 2018=C4=EA4=D4=C25=C8=D5=A3=AC02:00=A3=ACAlissa Cooper = =D0=B4=B5=C0=A3=BA >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-sidr-slurm-07: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Please cite BCP 14 rather than RFC 2119, assuming you intend for = normative > keywords to have their normative meaning in uppercase only. >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Apr 6 08:07:03 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17661271FD; Fri, 6 Apr 2018 08:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 AHzr2Q2D8SFc; Fri, 6 Apr 2018 08:06:54 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 931C0120726; Fri, 6 Apr 2018 08:06:54 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u15so449474ywg.8; Fri, 06 Apr 2018 08:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XhKCx/YjFAJ2MXEdfCePCS/GZtGhHmJRPmFB9V+MH20=; b=UJjCnnJZp/UkxQC2zRJoEb30m5q0BGQyiBt1SdiThJcDQsrUA9hHSSSrSyS/LWhO0m vpecDwa7lLRQxVoqHLfRpNBBqrQSULnIvLMEq1HBRw3A5OvM8lbImVaqAFp4HP57qCVX cBXkL7qQ/kraAb+0BszmtvzMa14HTIfjCqQIjIYF7OP9iItC4L8XBwITqTqkRUqdUtps Z2UWpgPTYVw/BVpWkwPDzwwD8KwK5Zsa9krRT5Jjd0RVvAKDR+hlEARofGK/TnkmeRA1 sbZBHAHpXCM1feeUctKAh+MXaNxESLCQhTG9nlgHTGgqzmihhBoBo4WlN+ePyqEt13ei aitw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XhKCx/YjFAJ2MXEdfCePCS/GZtGhHmJRPmFB9V+MH20=; b=AB0iLxzkIKqMCemb6rSP7a6hnDANFJBoiz8pDuF4WkBh6GPAnVoxz7dpHMZu8IOk+y FdnvoZjrdMdBb+oMmCuzcBPjvJADqUCyxFUW4j54ZcaqSXKcRGt6Fj4qM/5Rfj3xToaj mOOY/eif+svpxA1W0rFCJLPO9/Ed4KA5niAK7sqiA6YfdiMSbjvhCUTtXMc3zEbBVmLA QH/zVJDY5uR+g1sYIZLLiTkU93vL6usLm1QE5xfFeVB1/zY+J6jrptNbvAN8s/R1/5tq alfE5RyFKpybB1OComy8ho/RZY7mMzvT1mzIOJqsaBH4J0rcx1akojxT7HlQL4Ad2xUp pdsg== X-Gm-Message-State: ALQs6tDOCsdC41sElCdb9URltrsIAn+bfwrWNd8XTVnBeR/eOO2EIbnX yHSXE/um9e+RyZ6rVfa/zCKCeZ5ByLq2hVxC9nk= X-Google-Smtp-Source: AIpwx49wxNG3ZwUBGpvgSktSoKIBXpDklh5l5dTdngj3g8MFsayTToeLJ3rH2zSW/oDspxJQ4WovLQlCG3+5E479Og8= X-Received: by 10.13.223.10 with SMTP id i10mr7022090ywe.27.1523027209007; Fri, 06 Apr 2018 08:06:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:e757:0:0:0:0:0 with HTTP; Fri, 6 Apr 2018 08:06:48 -0700 (PDT) In-Reply-To: References: <152286484194.23960.17788058701508276433.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 6 Apr 2018 10:06:48 -0500 Message-ID: To: Di Ma Cc: Alissa Cooper , morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-slurm@ietf.org, The IESG , sidr wg list Content-Type: multipart/alternative; boundary="001a114e3f00c6b82a05692f6792" Archived-At: Subject: Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 15:06:57 -0000 --001a114e3f00c6b82a05692f6792 Content-Type: text/plain; charset="UTF-8" Hi, Di, On Fri, Apr 6, 2018 at 9:33 AM, Di Ma wrote: > Alissa, > > Thanks very much for your comments. > > Is BCP 14 exactly the same document as RFC 2119? It was, until https://tools.ietf.org/html/rfc8174 was added to BCP 14. That's the process doc that says readers don't have to figure out whether "must" is normative, etc. Spencer, who is not Alissa, but had a second to answer the question --001a114e3f00c6b82a05692f6792 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Di,

On Fri, Apr 6, 2018 at 9:33 AM, Di Ma <madi@zdns.cn> wrot= e:
Alissa,

Thanks very much for your comments.

Is BCP 14 exactly the same document as RFC 2119?

It was, until=C2=A0=C2=A0https://tools.ietf.org/html/rfc8174 was added to BCP 14. That's= the process doc that says readers don't have to figure out whether &qu= ot;must" is normative, etc.

Spencer, who is n= ot Alissa, but had a second to answer the question
--001a114e3f00c6b82a05692f6792-- From nobody Fri Apr 6 08:27:28 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E31F1272E1 for ; Fri, 6 Apr 2018 08:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSh2d95JmbCg for ; Fri, 6 Apr 2018 08:27:20 -0700 (PDT) Received: from smtpbgeu1.qq.com (smtpbgeu1.qq.com [52.59.177.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412921271FD for ; Fri, 6 Apr 2018 08:27:18 -0700 (PDT) X-QQ-mid: bizesmtp6t1523028431tms0jjer1 Received: from [192.168.3.3] (unknown [118.247.2.33]) by esmtp6.qq.com (ESMTP) with id ; Fri, 06 Apr 2018 23:27:09 +0800 (CST) X-QQ-SSF: 00400000002000F0FH40C00A0000000 X-QQ-FEAT: G7zn5EVW03LqLvyJloceqgRu5hMNGbSAgce/p91YaVIwGGtwzg4N02r7o8HzK t8dqRw7MaAx5OTBxe/somR2c8qSjKQrdxwdKajSmLCuiYjY0KZj5aS794RgtVv/MTJ2yDqm Xo0lm9Q4zgDso1/35nVcZClOCkw82yeUgTJ1Kro85GtxUAzN6ExKm06zCcw5OitMoNvTnoR nEI3S51Trli5gSb3YOj3lveH9EPjDgOsdOV/Sq2Kq/MCOPWlOrnsj+WqwigFWPKEAKk75MF 2z6SOwQUWZJmUiNC3t1HzAfkX9KzPdf2aKpm5CzsSFfY6v X-QQ-GoodBg: 2 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: Date: Fri, 6 Apr 2018 23:27:09 +0800 Cc: Alissa Cooper , morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-slurm@ietf.org, The IESG , sidr wg list Content-Transfer-Encoding: quoted-printable Message-Id: <89F21E77-61A3-4939-8C76-C55014C7CF96@zdns.cn> References: <152286484194.23960.17788058701508276433.idtracker@ietfa.amsl.com> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign2 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 15:27:27 -0000 Spencer, Thanks for your explanation.=20 Di > =D4=DA 2018=C4=EA4=D4=C26=C8=D5=A3=AC23:06=A3=ACSpencer Dawkins at = IETF =D0=B4=B5=C0=A3=BA >=20 > Hi, Di, >=20 > On Fri, Apr 6, 2018 at 9:33 AM, Di Ma wrote: > Alissa, >=20 > Thanks very much for your comments. >=20 > Is BCP 14 exactly the same document as RFC 2119? >=20 > It was, until https://tools.ietf.org/html/rfc8174 was added to BCP = 14. That's the process doc that says readers don't have to figure out = whether "must" is normative, etc. >=20 > Spencer, who is not Alissa, but had a second to answer the question From nobody Fri Apr 6 10:35:42 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CA3124D37; Fri, 6 Apr 2018 10:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q0cJ74N5cfd; Fri, 6 Apr 2018 10:35:38 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 126E212025C; Fri, 6 Apr 2018 10:35:37 -0700 (PDT) X-AuditID: 1209190d-b3fff70000003e45-82-5ac7afe84911 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 52.2A.15941.9EFA7CA5; Fri, 6 Apr 2018 13:35:37 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w36HZZAC008421; Fri, 6 Apr 2018 13:35:35 -0400 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w36HZUZG021161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Apr 2018 13:35:33 -0400 Date: Fri, 6 Apr 2018 12:35:30 -0500 From: Benjamin Kaduk To: Di Ma Cc: The IESG , morrowc@ops-netman.net, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org Message-ID: <20180406173529.GM80088@mit.edu> References: <152243246452.20520.7968873255606309518.idtracker@ietfa.amsl.com> <24005739-88B6-4D51-8ED5-217E141A2D23@zdns.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <24005739-88B6-4D51-8ED5-217E141A2D23@zdns.cn> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixCmqrfty/fEogzOzOCwaL/xispjxZyKz xb0nxRaXF35ks/g+/wKrxbJJ5xkd2DyWLPnJ5PFg0lF2j3ddnYwBzFFcNimpOZllqUX6dglc GSs/trAXvOSuWHGjm62BcRZnFyMnh4SAicSMP2eZuhi5OIQEFjNJLHl1mwXC2cAo8WrKTDYI 5wyTxNWp3ewgLSwCKhLrT99lArHZgOyG7svMXYwcHCICEhLXPvOC1DMLNDFKzJy6jxmkRlgg XuLRuT4WEJtXQEfi+vTDLCD1QgJ1EjcfqUCEBSVOznwCVsIsoC7xZ94lsJHMAtISy/9xQITl JZq3zgabyClgLTFv7hOwa0QFlCX29h1in8AoOAvJpFlIJs1CmDQLyaQFjCyrGGVTcqt0cxMz c4pTk3WLkxPz8lKLdI30cjNL9FJTSjcxgqNAkncH47+7XocYBTgYlXh4C7qPRwmxJpYVV+Ye YpTkYFIS5T1oDxTiS8pPqcxILM6ILyrNSS0+xCjBwawkwrv7z7EoId6UxMqq1KJ8mJQ0B4uS OO+i/XujhATSE0tSs1NTC1KLYLIyHBxKErzP1gENFSxKTU+tSMvMKUFIM3FwggznARp+fS1Q DW9xQWJucWY6RP4Uo6KUOO9ikGYBkERGaR5cLyhJSWTvr3nFKA70ijCvCTBlCfEAExxc9yug wUxAgyckHgEZXJKIkJJqYKwsu7Tntp6ZrcmyTv+sf3pLLwoaNTcrm1+QOtmwsZH3tdGVMvnd fGr1dansrAYbHdL+c6/iiu42zXgiIKS0Y7uOyRMttbVRQX2ur/e9Xqi3XmXJlaLHxae4n13c HsktNTnqgNKFFI7rsiKtfycfuDmjKqJuvqrXCsH12hy1afe+11/JdMuoU2Ipzkg01GIuKk4E ABkSmbotAwAA Archived-At: Subject: Re: [sidr] Benjamin Kaduk's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 17:35:40 -0000 On Fri, Apr 06, 2018 at 09:15:28PM +0800, Di Ma wrote: > Benjamin, > > Thanks very much for your comments. > > Please see my responses in lines. > > > > 在 2018年3月31日，01:54，Benjamin Kaduk 写道： > > [trimming lots of stuff that looks good] > > I also wonder if we would benefit from a little discussion of the > > potential routing issues that could arise from using a "broken" (or > > deliberately adversarial) SLURM file, though I expect that the > > target audience is probably pretty familiar with these already. > > > > Well, it has been stated in this document: > > 'Errors in the SLURM file used by an RP > can undermine the security offered by the RPKI, to that RP. It could > declare as invalid ROAs that would otherwise be valid, and vice > versa. As a result, an RP must carefully consider the security > implications of the SLURM file being used, especially if the file is > provided by a third party.' > > It is not clear to us what more we should cover here. I was wondering if you wanted to say anything about the specific operational consequences of the incorrectly handled ROAs -- for example, traffic getting redirected to an attacker or blackholed, or high levels of traffic directed to something not prepared to handle it. (Presumably there are others.) But if you think this is obvious to the intended audience, there is no need to add it just on my account. Thanks for the updates, Benjamin From nobody Sat Apr 7 08:38:32 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9671270AE for ; Sat, 7 Apr 2018 08:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, 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=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 WjlOS3PCcJjE for ; Sat, 7 Apr 2018 08:38:27 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 EDDA11270AC for ; Sat, 7 Apr 2018 08:38:26 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id i3so8004749wmf.3 for ; Sat, 07 Apr 2018 08:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=avtTBzXkEZyz9iPCBXNKSnUY57RBPg+sGUVIVz0uXeY=; b=L8f5PaqV9p1BcaXG6cA9Xq5xrazJ8F3IPcCIujkFcCEXohBMMIlxSwqbVWpsBm9um9 Xde1cqLvvPzkXTE0QU2gNXcVSKC5Uw0LkqD09NehzKirtVXUsp3zGxlH0lYtcnxn8dv8 x3Rx/OKWSG4ky3v9JTVED5Ka3bl6BIr+wpKJcXRP57Kiuf8GpM1jMqSZZSjx9ar+zNxX 1BVb2xGKffNQTeuyn0MLqvz9sOkOmvUf4n99D7Klk201PcMKiR5RJA7nJIRYr9Uho9NW MahVzTfjowZsweVmJiL5D/5W4lwT7sJwEMAjJHFKBNWhQ6Ku4voTy5/wdyHa4RWdtwZY 5+Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=avtTBzXkEZyz9iPCBXNKSnUY57RBPg+sGUVIVz0uXeY=; b=Z3rw7MjJYOyLU55Bro+v498eT0LcupYxX8kwpyXigjhmtkoFemeA2EUivLktK1QDaU WhkzbIfNArJSWbFy+fueiO72+ZTL5rBy0+SwqjPzdpxCsOTQPaDFsXI9XJJd1VW2pKR/ 3E3ydIh6wnab2BsLnIGs0SLDzk8y9tOmqfh8pwh3LzQ4nRTBe4zht1EN0HVJFtLlfKvn 0nHNZeIr0rc12Xow5/N6T8Dp1KnNmXSmd3UNhy5DpzujORz0xvClvUOykEVQ7yCLSWS2 EdvsHleW+07c/WNNqkW+iYAFXtLWanvL2LyxUpm2jd3Edql2r4TDLPelv3fe2M95v0KI pTuA== X-Gm-Message-State: AElRT7F2Ed04SuHchh32iAJ0xIkvet9NTbYHFjOwA01JgCaozvBmq06R AO/DquzBJBB6Hx2bWgRhoAQ2KLwNphDDhPCyZ6er/A== X-Google-Smtp-Source: AIpwx48hNjMOSsHQJZyWFq3xht6K0Ji4TnOcACN3xMthRQd1ApcJ4Dkjm4B1Ae3JtMJ//tJL9+biqz8gaZR4k+uUv7s= X-Received: by 10.28.139.18 with SMTP id n18mr15125219wmd.26.1523115504798; Sat, 07 Apr 2018 08:38:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.226.76 with HTTP; Sat, 7 Apr 2018 08:37:44 -0700 (PDT) In-Reply-To: <9958A258-44B0-4965-B1C9-5E76031198C2@zdns.cn> References: <152261657190.23824.4759371193986790926.idtracker@ietfa.amsl.com> <9958A258-44B0-4965-B1C9-5E76031198C2@zdns.cn> From: Warren Kumari Date: Sat, 7 Apr 2018 11:37:44 -0400 Message-ID: To: Di Ma Cc: The IESG , draft-ietf-sidr-slurm@ietf.org, Chris Morrow , sidr@ietf.org, sidr-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a11443d9a9da3fd056943f6d3" Archived-At: Subject: Re: [sidr] Warren Kumari's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 15:38:30 -0000 --001a11443d9a9da3fd056943f6d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 6, 2018 at 10:02 AM Di Ma wrote: > Warren, > > Thanks very much for your comments. > > Please see my responses in lines. > > > =E5=9C=A8 2018=E5=B9=B44=E6=9C=882=E6=97=A5=EF=BC=8C05:02=EF=BC=8CWarre= n Kumari =E5=86=99=E9=81=93=EF=BC=9A > > > > Warren Kumari has entered the following ballot position for > > draft-ietf-sidr-slurm-07: Discuss > > > > 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-sidr-slurm/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I don't understand the targeting as it related to domain/host names (an= d > > suspect that others will have the same issue). > > > >> From section 3.3: > > " If a "slurmTarget" element is > > present, an RP SHOULD verify that the target is an acceptable value, > > and reject this SLURM file if the "slurmTarget" element is not > > acceptable.... Accordingly, the SLURM file > > source needs to indicate which RP(s) should make use of the file by > > adding the domain name(s) of the RP(s) to the SLURM file target... > > Such a target value is a server name expressed in FQDN. > > > > "slurmTarget": [ > > { > > "hostname": "rpki.example.com", > > "comment": "This file is intended for RP server rpki.example.com" > > } > > ] > > > > So, if I want to target multiple RPs (rpki1.example.com, > rpki2.example.com) can > > I do: > > > > "slurmTarget": [ > > { > > "hostname": "example.com", > > "comment": "This file is intended for RP server rpki.example.com" > > } > > ] > > > > ? > > The "domain names(s)" versus "hostname" vs "server name expressed in > FQDN" text > > is handwavey. I'm assuming that I'd need to do: > > > > "slurmTarget": [ > > { > > "hostname": "rpki1.example.com", > > "comment": "This file is intended for RP server rpki1.example.com= " > > }, > > { > > "hostname": "rpki2.example.com", > > "comment": "This file is intended for the RP server, > rpki2.example.com" > > }, > > ]" > > Can you please make this clearer, and hopefully add more targets to the > > examples? This seems like an easy fix / clarification, happy to clear > once it > > is, er, clear. > > > > > > We authors have decided to drop the slurmTarget element completely. > That works for me =E2=80=8B.=E2=80=8B Please =E2=80=8B(explicitly and loudly!) =E2=80=8B let me know when the new version is =E2=80=8Bsubmitted =E2=80=8Band I'll remove my discuss. =E2=80=8BW=E2=80=8B > Initially the implementation team was thinking that it would be useful to > have the ability to offer the same set of SLURM files to all RPs deployed > in a network, where local config of the RP would then evaluate the > applicability of each file. However, now that both implementations (RIPE > NCC Validator and RPSTIR) progressed we reconsider and we feel that it > would be better to deal with this on the provisioning side. I.e. only off= er > the SLURM file(s) relevant to each RP. > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I have a few questions and editorial comments: > > > > 1: Section Abstract: > > ISPs can also be able to use the RPKI to validate the path of a BGP > route. > > I think you meant =E2=80=9CISPs can also use the RPKI..." > > > ACK. > > > > > 2: Section 1. Introduction > > "However, an "RPKI relying party" (RP) may want to override some of the > > information expressed via putative Trust Anchor(TA) and the certificate= s > > downloaded from the RPKI repository system." I think this should be > either "a > > putative Trust Anchor (TA)" or "putative Trust Anchors (TA)" (single vs > > plurals). I agree with others that "putative TA" is not a well known > term - > > perhaps you can find a better one? > > > > We will use =E2=80=98configured Trust Anchor(s)=E2=80=99 instead. > > > > Section 3.4.1. Validated ROA Prefix Filters > > In the "prefixFilters examples", I think it would be helpful to update > the > > comments to be more explicit about what is being matched (e.g"All VRPs > covered > > by 198.51.100.0/24 and matching AS 64497") > > > > > ACK. > > And we will update JSON related content in this draft based on Adam=E2=80= =99s > suggestions. > > Di > > --001a11443d9a9da3fd056943f6d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On F= ri, Apr 6, 2018 at 10:02 AM Di Ma <madi@zdns.cn> wrote:
Warren,

Thanks very much for your comments.

Please see my responses in lines.

> =E5=9C=A8 2018=E5=B9=B44=E6=9C=882=E6=97=A5=EF=BC=8C05:02=EF=BC=8CWarr= en Kumari <warren= @kumari.net> =E5=86=99=E9=81=93=EF=BC=9A
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-sidr-slurm-07: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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/dr= aft-ietf-sidr-slurm/
>
>
>
> ------------------------------------------------------------= ----------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> I don't understand the targeting as it related to domain/host name= s (and
> suspect that others will have the same issue).
>
>> From section 3.3:
> "=C2=A0 If a "slurmTarget" element is
>=C2=A0 =C2=A0present, an RP SHOULD verify that the target is an accepta= ble value,
>=C2=A0 =C2=A0and reject this SLURM file if the "slurmTarget" = element is not
>=C2=A0 =C2=A0acceptable.... Accordingly, the SLURM file
>=C2=A0 =C2=A0source needs to indicate which RP(s) should make use of th= e file by
>=C2=A0 =C2=A0adding the domain name(s) of the RP(s) to the SLURM file t= arget...
>=C2=A0 Such a target value is a server name expressed in FQDN.
>
>=C2=A0 =C2=A0"slurmTarget": [
>=C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"hostname": "rpki.example.com",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"comment": "This file is inte= nded for RP server rpki.example.com"
>=C2=A0 =C2=A0 =C2=A0}
> ]
>
> So, if I want to target multiple RPs (rpki1.example.com, rpki2.examp= le.com) can
> I do:
>
>=C2=A0 =C2=A0"slurmTarget": [
>=C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"hostname": "example.com",<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"comment": "This file is inte= nded for RP server rpki.example.com"
>=C2=A0 =C2=A0 =C2=A0}
> ]
>
> ?
> The "domain names(s)" versus "hostname" vs "s= erver name expressed in FQDN" text
> is handwavey. I'm assuming that I'd need to do:
>
>=C2=A0 =C2=A0"slurmTarget": [
>=C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"hostname": "rpki1.example.com= ",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"comment": "This file is inte= nded for RP server rpki1.example.com"
>=C2=A0 =C2=A0 =C2=A0},
> {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"hostname": "rpki2.example.com= ",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"comment": "This file is inte= nded for the RP server, rpki2.example.com"
>=C2=A0 =C2=A0 =C2=A0},
> ]"
> Can you please make this clearer, and hopefully add more targets to th= e
> examples? This seems like an easy fix / clarification, happy to clear = once it
> is, er, clear.
>
>

We authors have decided to drop the slurmTarget element completely.


That works for me
=E2=80=8B.=E2=80=8B

Please
=E2=80=8B(explici= tly and loudly!) =E2=80=8B
let me know when the new version is=C2=A0=E2=80=8Bsubmitted =E2=80=8Band I'll remove my discuss.


= =E2=80=8BW=E2=80=8B


Initially the implementation team was thinking that it would be useful to h= ave the ability to offer the same set of SLURM files to all RPs deployed in= a network, where local config of the RP would then evaluate the applicabil= ity of each file. However, now that both implementations (RIPE NCC Validato= r and RPSTIR) progressed we reconsider and we feel that it would be better = to deal with this on the provisioning side. I.e. only offer the SLURM file(= s) relevant to each RP.


> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I have a few questions and editorial comments:
>
> 1: Section Abstract:
> ISPs can also be able to use the RPKI to validate the path of a BGP ro= ute.
> I think you meant =E2=80=9CISPs can also use the RPKI..."


ACK.

>
> 2: Section 1.=C2=A0 Introduction
> "However, an "RPKI relying party" (RP) may want to over= ride some of the
> information expressed via putative Trust Anchor(TA) and the certificat= es
> downloaded from the RPKI repository system." I think this should = be either "a
> putative Trust Anchor (TA)" or "putative Trust Anchors (TA)&= quot; (single vs
> plurals). I agree with others that "putative TA" is not a we= ll known term -
> perhaps you can find a better one?
>

We will use =E2=80=98configured Trust Anchor(s)=E2=80=99 instead.


> Section 3.4.1.=C2=A0 Validated ROA Prefix Filters
> In the "prefixFilters examples", I think it would be helpful= to update the
> comments to be more explicit about what is being matched (e.g"All= VRPs covered
> by 198.51.100.0/24 and matching AS 64497")
>
>
ACK.

And we will update JSON related content in this draft based on Adam=E2=80= =99s suggestions.

Di

--001a11443d9a9da3fd056943f6d3-- From nobody Mon Apr 9 11:29:08 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAEB129C51; Mon, 9 Apr 2018 11:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNKy3iLn3umf; Mon, 9 Apr 2018 11:29:00 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9AD1273B1; Mon, 9 Apr 2018 11:28:59 -0700 (PDT) Received: from [10.0.1.91] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w39ISe0L028970 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 9 Apr 2018 13:28:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.91] From: Ben Campbell Message-Id: <5DE6E2DB-42D9-40ED-BE48-17544419A1FA@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_06DBA2B0-BD99-400E-B823-E285AB113F24"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 9 Apr 2018 13:28:38 -0500 In-Reply-To: Cc: Di Ma , draft-ietf-sidr-slurm@ietf.org, Alissa Cooper , morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , sidr wg list To: Spencer Dawkins at IETF References: <152286484194.23960.17788058701508276433.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 18:29:02 -0000 --Apple-Mail=_06DBA2B0-BD99-400E-B823-E285AB113F24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 6, 2018, at 10:06 AM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Di, >=20 > On Fri, Apr 6, 2018 at 9:33 AM, Di Ma wrote: > Alissa, >=20 > Thanks very much for your comments. >=20 > Is BCP 14 exactly the same document as RFC 2119? >=20 > It was, until https://tools.ietf.org/html/rfc8174 was added to BCP = 14. That's the process doc that says readers don't have to figure out = whether "must" is normative, etc. >=20 > Spencer, who is not Alissa, but had a second to answer the question Also not Alissa (or Spencer), but to extend the answer a bit: RFC 8174 = includes new boilerplate for treating only the upper case versions as = keywords. Thanks! Ben. --Apple-Mail=_06DBA2B0-BD99-400E-B823-E285AB113F24 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrLsNYACgkQgFZKbJXz 1A03lBAAwjL8B5IA6CDbxcX7qZEXKkFZ3C9c271qpWaa1TiIQW7G6e4MjEDEJHX9 at3fqYgh2BvZeQTW/rE+3G/ole53I8pVBFZOZrpJcH7VrwvHt4a1/Yg/rz/+SM5+ 2L5UBYoWOs3PERvjFtcg0njla2XhPEws219bov6Ft15XRAdK/AWjp9gWqdg+Mikj uJEBqF9swS4UPZbBLoYA2WV3yzn2XBBlk+feeJ7B7IxiR+2N7gsDGQ4oGBBIlSpE /tW2eIARQ+G5dA7BIJ82RFS3C9/J62tFROiRIYKCAgbFuGja8XFjzXB9esy2pMAB w/2d91ivqJx5QKEeT1lCtRvz6CsIoltvvSmKzqVWjhGrw9HDU/ms7NOpzTvzv2zS MkVueSVbY5LWMqMAoKu/RapPF2FGENJ5fBzORriTuuDyq8WEiEN9trOpwH4u24rV NAYMVe1wV1IeQBB7LrvJ/vxmIlj6fMbB5jEq/cV4pLe6RJ+b4gQn3W2AdlacOakM 4RUQje3uIDe5q80+zS0JCLQnC9ye3oDtqIAwq01mpqPj6B+4f6GBHjbUuJHpjNPE tfhh5LZt0HgLLmAmBxgj608lzCi7qI11rrr1Rnd8oHpMc/k6QLRmJxKZx4K1FZrU kjVDf1T2W0kGP0it8AuD+ir0KtBX7sJkw8ESVBeV6jLhbFK+Gzk= =kCLE -----END PGP SIGNATURE----- --Apple-Mail=_06DBA2B0-BD99-400E-B823-E285AB113F24-- From nobody Tue Apr 10 00:54:23 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758091200A0 for ; Tue, 10 Apr 2018 00:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9nyRR9dWUSF for ; Tue, 10 Apr 2018 00:54:15 -0700 (PDT) Received: from smtpbgeu2.qq.com (smtpbgeu2.qq.com [18.194.254.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDEEB12704A for ; Tue, 10 Apr 2018 00:54:12 -0700 (PDT) X-QQ-mid: bizesmtp7t1523346845tpbw8ruma Received: from [192.168.101.95] (unknown [218.241.119.117]) by esmtp4.qq.com (ESMTP) with id ; Tue, 10 Apr 2018 15:54:03 +0800 (CST) X-QQ-SSF: 00400000002000F0FH43000B0000000 X-QQ-FEAT: AU3gs7VM8fW/ZdA6Jc2dPvKnwxIjBRy4WFKlyNfKQ/EFcg4xwEEO8dtzBmYKe hB+Ouu8+GGDCFmvsyfjXRgThwa7RAxzy6Fx/UHdboksrARldeM9MfN8db8WSDhq0Ia/Ng2W 10R7KDSM2x6y/5sRoQFIbe2Ti8xuFRlzPUrP3zJpGBDC1dMFizJxAKqSY4EIUyBNVeEQqH6 HV/QCghcZEJNBgj2RnitlfHejo7t90Cvw7+S2E6wONqUc3SEzzHxrWGK0W7DUqyrHbXo3xm Zd8h0guni/qZySeV8Wn94opOdJ9gwRBOVWh9lX7yXX1/o3 X-QQ-GoodBg: 2 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Di Ma In-Reply-To: <5DE6E2DB-42D9-40ED-BE48-17544419A1FA@nostrum.com> Date: Tue, 10 Apr 2018 15:54:01 +0800 Cc: Spencer Dawkins at IETF , draft-ietf-sidr-slurm@ietf.org, Alissa Cooper , morrowc@ops-netman.net, sidr-chairs@ietf.org, The IESG , sidr wg list Content-Transfer-Encoding: quoted-printable Message-Id: References: <152286484194.23960.17788058701508276433.idtracker@ietfa.amsl.com> <5DE6E2DB-42D9-40ED-BE48-17544419A1FA@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.5.20) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign1 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 07:54:22 -0000 Hi, Ben, Thanks for reminding us:-) Di > =D4=DA 2018=C4=EA4=D4=C210=C8=D5=A3=AC02:28=A3=ACBen Campbell = =D0=B4=B5=C0=A3=BA >=20 >=20 >=20 >> On Apr 6, 2018, at 10:06 AM, Spencer Dawkins at IETF = wrote: >>=20 >> Hi, Di, >>=20 >> On Fri, Apr 6, 2018 at 9:33 AM, Di Ma wrote: >> Alissa, >>=20 >> Thanks very much for your comments. >>=20 >> Is BCP 14 exactly the same document as RFC 2119? >>=20 >> It was, until https://tools.ietf.org/html/rfc8174 was added to BCP = 14. That's the process doc that says readers don't have to figure out = whether "must" is normative, etc. >>=20 >> Spencer, who is not Alissa, but had a second to answer the question >=20 > Also not Alissa (or Spencer), but to extend the answer a bit: RFC 8174 = includes new boilerplate for treating only the upper case versions as = keywords. >=20 > Thanks! >=20 > Ben. From nobody Mon Apr 23 17:31:52 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F44128961; Mon, 23 Apr 2018 17:31:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152452990411.28831.7259442525018563009@ietfa.amsl.com> Date: Mon, 23 Apr 2018 17:31:44 -0700 Archived-At: Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-15.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 00:31:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing WG of the IETF. Title : Router Keying for BGPsec Authors : Randy Bush Sean Turner Keyur Patel Filename : draft-ietf-sidr-rtr-keying-15.txt Pages : 18 Date : 2018-04-23 Abstract: BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-15 https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-15 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 Apr 23 17:32:29 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5BC12DFE0 for ; Mon, 23 Apr 2018 17:32:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 mwXfpboJ4-R4 for ; Mon, 23 Apr 2018 17:32:23 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 0599812DB6F for ; Mon, 23 Apr 2018 17:32:15 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id z23-v6so19970618qti.5 for ; Mon, 23 Apr 2018 17:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mr6ohmjBMR6+dwoex+R/5EUVVwMcflhfsqQw4hb49Dc=; b=X1YrbKseoW5wQsTq/XZRbzqC6IjlEFonMRCc5WMFe9X2MRlaEmFuMKoRSjhR1VKoHu Eu+EXfT4/tH6l+7Il1ie+lTZIz+sfUIU6W1BciA3i23JsxKiTB6T/RSHiFrz514gfZN8 BZVg73eKAtN/8yOKYHcIUGeGBzoxh9RmYksEQ= 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=Mr6ohmjBMR6+dwoex+R/5EUVVwMcflhfsqQw4hb49Dc=; b=s6UAeYbr0F7dw43v2VqQRP04vpuQygKy6kthxTeMB8le5tdvTsznEnGhWKz9jRtD29 czzLsCs8NBtCbua15mNxNiRtoyHPc/NHtWDRn9zfWambxob5rgpx3G5I+lfofbnr9TM7 XqYe6fdrRnabgs32G8SLGrBoZeCyvDEGCOATbwkQl3lU+vrXZ4kJHoDw/v4Ew0tDAvpK j/mbM/DAXQecx99Ae/goSMf1IXYGYC2dtBegCZpf6QtVMcTwJwWpgo5AFWdVQS6pPsvz pkI32Vg2kDjcxtmYuMtfpApEa/OrQz8o/5+vBXKrTav8WDwtuJD0pvySMM9BYx0axHXe Kiaw== X-Gm-Message-State: ALQs6tCyJSXfFsp3PAkkfwLWiwnRgaWEQMncvplsnsWyPKiijW4uJ2Oy ZYj9FezCNdYlCMukOqzWp0z9wg== X-Google-Smtp-Source: AB8JxZq70JxFWw7Vci+IHvtE/ZGjzoGle/p2Hme2s8qV7/1xiYxB9G+a997kz+XlsfrlcsOGZvfa/g== X-Received: by 2002:ac8:1e86:: with SMTP id c6-v6mr25355421qtm.375.1524529933071; Mon, 23 Apr 2018 17:32:13 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id b125sm11147059qkd.62.2018.04.23.17.32.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 17:32:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: <5990F5D0-B532-482E-BA4F-D20908F6B862@tislabs.com> Date: Mon, 23 Apr 2018 20:32:09 -0400 Cc: Christopher Morrow , sidr chairs , draft-ietf-sidr-rtr-keying@ietf.org, sidr list Content-Transfer-Encoding: quoted-printable Message-Id: <1BA32CF4-F79B-452B-A98F-2C07399EAF44@sn3rd.com> References: <150851896075.15465.7110696373396971840@ietfa.amsl.com> <68DEA77B-EB7C-4345-A60E-A134E5CAC2F7@sn3rd.com> <79137BEA-5FD8-4E08-8C49-215146A352F2@tislabs.com> <48765D76-8B14-492B-B444-9F895A920D89@tislabs.com> <260B2F04-6A90-464C-A6B1-7518AD68F7E6@tislabs.com> <5990F5D0-B532-482E-BA4F-D20908F6B862@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 00:32:28 -0000 Apologies for taking so long to get back to these. I=E2=80=99ve gone = ahead and posted -15; -14 was about to expire. I suspect that there = will be a -16 to address changes that result from resolving #3-5 and #9. spt > On Nov 14, 2017, at 21:07, Sandra Murphy wrote: >=20 > Wellllll. >=20 > The mail archive does not seem to show attachments. For me. I see do = see attachments on other messages. >=20 > It would be nice to know if anyone has seen attachments on my messages = in the last few weeks. >=20 > At any rate, for the mail archive, the comments are copied below the = signature. >=20 > =E2=80=94Sandy >=20 >=20 > Points that might get lost in the long detailed list that follows: >=20 > 1. RFC4271 (and RFC6286) and RFC8209 use the term =E2=80=9CBGP = Identifier=E2=80=9D. The main text says RouterID and the Appendix B = says =E2=80=9Cserial number=E2=80=9D. I believe both are talking about = what RFC8209 calls the =E2=80=9CBGP Identifier=E2=80=9D. Most of the = tech sites say router ID or router-id or routerid or RID or some such. = But I think consistency with the referenced text would be good. #Sean: Changed throughout the draft to BGP Identifier and added a = reference to 4271. > 2. I was initially confused by the text in various places that talks = about the operator adding the AS and RouterID (sic) and sends to the CA. = I thought that meant the operator adds those to the CSR, which would be = hard since the CSR is signed. This occurs a couple of places. I = suggest a sentence early on that says the router certificate includes = the AS and router identifier but the CSR does not include such fields, = so the operator must include the AS and routerID when it sends the CSR = to the CA. #Sean: The setup section explains that the Operator either needs to = configure the AS and to configure/extract the BGP Identifier. These = values are included in the cert req; I guess the way I said they are = added was confusing? I guess in s5.1/s5.2 as opposed to saying the = operator adds it should just say: The PKCS#10 includes the chosen AS number and BGP Identifier that the RPKI CA will certify. > 3. =E2=80=9Ccorresponds=E2=80=9D - there are several places that say = the certificate must be validated to prove that the public key = corresponds with the private key. The main body does not say how that = correspondence is validated. The appendix suggests that the operator = could validate the signature on the CSR with the returned router cert in = order to validate the key. (a) When the operator generated the = public/private key pair, why not just do a comparison to the generated = public key, presuming it was retained? (b) When the operator passed the = CSR generated by the router to the CA, why not validate the public key = before sending it to the CA? The public key in the returned router = certificate could subsequently be validated by a comparison, presuming = the public key was retained. (c) When the router is supposed to = validate the public key of the router cert it receives, and the operator = generated the public/private key pair, it does not have a copy of the = CSR to validate the correspondence. Took me a bit to realize the router = could sign just any old bit of bytes and then validate the signature = with the received router cert. Right? #Keyur: Ack on A and B. Sean and Randy Can u validate if that makes = sense? On C we should call this results in incorrect signing of =E2=80=9Co= ld bit of bytes=E2=80=9D. Assuming there is a key rollover period this = should be okay as old keys could be active?=20 #Randy: yes, if the router has both the private and alleged pubic keys, = it could sign a nonce and then verify it. but if you worry that the = operertor is lying to the router, she would be smart enough to give the = router a public/private pair which matches but is not the same as she = negotited with the CA. the router would have to make some sort of check = with the CA, i.e. the router would need the CA's public key or up-chain. #Sean: So corresponds means that the public key in the certificate and = private key are actually a key pair, i.e., the public key can be used to = validate a signature generated with the private. In this draft we only = do the check on the returned certificate because the CA does the check = on the certificate submitted for certification; that bit is called POP = or proof-of-possession. Now you can do this by verifying any old = signed bag-o-bits or the PKCS#10 and if the RPKI package you used to = generate the key pair supports it special functions that do the = verification. The check in s6 is done when the operator does it to = check that the CA didn=E2=80=99t screw up and send it the wrong cert; = the check in s7 covers both the router and operator generated cases = because in the former the router needs to the check because it made the = request and in the later the operator may have screwed up and sent the = router the wrong cert. The check is repeated in s8 and AppA because = we=E2=80=99ll those sections are variations on a theme. So, I was maybe = a bit lazy with respect to how to ensure the two keys correspond to each = other, but there=E2=80=99s a number of ways to do it and it depends on = what you got installed. I guess I just need to know how much more you = want and where to put it because I=E2=80=99d rather not repeat all of = this four times. > 4. =E2=80=9Ccorresponds=E2=80=9D again - there=E2=80=99s no mention = of a router verifying that the router cert it receives has an AS that is = configured on the router. There are lots of other checks and double = checks - why not this one? And if the router has multiple ASs and = multiple CSRs have been generated (either by the router or by the = operator), then the router uses the received router certificate to = associate the AS with the public/private key pair, so it knows which = private key to use over which session. Right? #Keyur: Yep. #Sean: Sure we can add that check. Can I put all of this in s6 and then = refer the other sections back to this section so it=E2=80=99s not = repeated? > 5. Section 8 on =E2=80=9CAdvanced Deployment Scenarios=E2=80=9D talks = about routers that already have pre-installed keys (with mentions of = types of crypto that are not known to me, and I did not dig up the refs, = so I might be missing something here). The first paragraph talks about = =E2=80=9Cpre-installed key material=E2=80=9D. I could understand why = these pre-installed keys might be useful in authenticating the router = directly to the CA. The =E2=80=9Cburdens=E2=80=9D 1 and 2 also talk = abut =E2=80=9Ckey material=E2=80=9D. It did not look to me like the = =E2=80=9Ckey material=E2=80=9D in 1 and 2 are talking about these = =E2=80=9Cpre-installed=E2=80=9D keys. But I admit to being very = confused by the way the term is used. #Sean: The ADS section was to appease Max; it=E2=80=99s the paragraph = that=E2=80=99s not like the others. His point was that hopefully in the = not to distant future you router will come pre-installed with goodies = from the manufacturer. At the top of that list are keys either = asymmetric (IEEE AR certificates) or symmetric (Pre-Shared Keys); these = keys can be used to authenticate the router to the management station or = the CA. But, you still have to get the keys from the router to the = management station/CA and if this is all going to happen automagically = then you need to make sure the router can talk to the CA; these are = bullets 1 and 2. After that, it=E2=80=99s easy-peasy (or so we hope) = ;). Make more sense? > 6. Section 5.2.1 is titled =E2=80=9DUsing PKCS#8 to Transfer Public = Key=E2=80=9D. The text talks about using PKCS #8 in RFC5958, which = allows for including both the public and private key. But the text of = that section is talking about using PKCS #8 to transmit the private key = to the router. I presume the title should be Using PKCS#8 to Transfer = Private Key #Keyur: Should be fixed. #Sean: p2f (palm-to-face) - fixed > 7. There is an early assumption that all the communication between = the operator and the router is over a protected channel. Section 5.2.1 = suggests using a CMS SignedData to transmit the PKCS#8. RFC5958 = suggests several different =E2=80=9CCMS protecting content types=E2=80=9D = for the PKCS#8 - EncryptedData, EnvelopedData, etc. I presume that the = encrypted versions are not used here because the protected channel = ensures confidentiality. So (a) Appendix A talks about the key strength = to be used for the different crypto algorithms (encryption, key = exchange, =E2=80=A6). That=E2=80=99s a big hint that the channel should = provide the related security protections. I think it would be good to = explicitly state the protections the protected channel must provide: = =E2=80=9CThe protected channel must provide confidentiality, = authentication, integrity and replay protection=E2=80=9D. (b) if the = protected channel provides authentication and integrity, why is the = protection of the CMS SignedData needed? One possible reason follows -> = (c) The AS EE certificate has an AS extension, not an IP extension, I = presume. So the AS EE certificate would be a second way for the router = to associate a private key with an AS and an appropriate BGP session = (see my comment 3c above). But this applies only when the operator = generated the public/private key pair. #Keyur: Agree on incorporating the suggestion #Sean: So no problem adding the requirements on the protected channel. = What might help in the understanding here is that the PKCS#7s that are = returned from the CA are the so called certs-only messages, i.e., = there=E2=80=99s no content so no sig only the cert-bag. The other uses = of CMS SignedData to protect the private key (s5.2.1) is just good = security so that the router will know that the key came from somebody it = trusts, i.e., the operator; also not it=E2=80=99s a =E2=80=9Cshould=E2=80=9D= . > 8. PKCS#7 needs a reference. I looked at RFC2315. RFC2315 defines = several types of content, e.g., signed-data, enveloped-data, = signed-and-enveloped-data, etc. Is there any reason to specify which = type? Is it operator choice? #Keyur: Should be left to an operator. #Sean: The reference is there in s3 for application/pkcs7-mime, but I = can add it next to PKCS#7 as well. As noted in response to q7, the = PKCS#7 is a certs-only message. I=E2=80=99ll point to 5751bis, which is = in IETF LC right now so should be done before this. > 9. The term =E2=80=9Coperator=E2=80=9D is used to talk about = carbon-based units (who are forgetful), ISP organizations (who peer with = other operators), ASs (who have an AS EE certificates) and management = system stations (that receive CSRs from the router). It was a bit = unsettling, but after multiple reads through I=E2=80=99m getting used to = it. I=E2=80=99m not sure I could suggest a term that would fit all = those uses. Perhaps network operators (the ones with DNA) identify = personally with all those uses and think of their person in all cases. = =E2=80=9CI am the AS=E2=80=9D, =E2=80=9CI am the peering entity=E2=80=9D, = =E2=80=9CI am the management of the network=E2=80=9D, etc. #Keyur: Ok by me to replace operator with network operators. #Sean: I just don=E2=80=99t see how adding this qualifier helps; I think = folks pretty quickly ought to be able to catch on that we=E2=80=99re = talking about the folks who press buttons on a computer to make stuff = happen. Are we also renaming the =E2=80=9Coperator-driven=E2=80=9D = model? > 10. I do not understand the last two paragraphs of section 7 at the = bottom of page 6. It sounds to me like they are out of place, like they = belong elsewhere in the text. #Keyur: I would leave them there. #Sean: I=E2=80=99m hoping we can just leave them there too. > 11. There are some occurrences of =E2=80=9Cmust=E2=80=9D and only a = few of =E2=80=9CMUST=E2=80=9D - the draft is standards track, so how = much of the described behaviors are mandatory? #Keyur: Will let Randy Chime in here. #Randy: i do not believe these were accidents. i am really careful with = MUST. examples would be helpful. #Sean: Very little actually. This is a choose your own PKI adventure = kind of draft it=E2=80=99s not a protocol draft. We can=E2=80=99t say = you must do it this way or that way because there=E2=80=99s plenty of = ways to do it and the options available to you are entirely dependent on = what router you=E2=80=99re using. > 12. Some consistency nits - PKCS sometimes followed by a space, = sometimes not. protected channel, secure channel, communications = channel, protected session, SSH session, . . . =20 #Keyur: Lets fix them. #Sean: I will try, but I am sure the RFC editor will do a much better = job than I will in catching all of the inconsistencies. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > OK, so on to the detailed comments, sequentially through the document >=20 > p3, section 1: >=20 > two methods to provision new and existing routers. The methods > described involve the operator configuring the two end points and > acting as the intermediary. >=20 > What are the two endpoints? The router and the management station? = The router and the CA? I can imagine the operator configuring the = management station, but not the CA. I can imagine the operator acting = as the intermediary between the router and the CA, but not between the = router and the management station. #Keyur: I interpret as management station and the router. We should = clarify it Sean. #Sean: Yep management station and router. > p3, section 1: (nit) >=20 > [RFC8208] > specifies the algorithms used to generate the signature. >=20 > If I read correctly, =E2=80=9Cthe=E2=80=9D signature in this text = would be the signature on the PKCS#10. =20 >=20 > suggest: >=20 > [RFC8208] > specifies the algorithms used to generate the PKCS#10 signature. #Keyur: Ack. Text to be incorporated. #Sean: Minor tweak r/PKCS#10/PKCS#10=E2=80=99s > p4, section 2 >=20 > See Appendix A for security considerations > for this channel. >=20 > I think it is important to say what security protection are required = for this protected channel. > Appendix A talks about the strength of the key used in the various = crypto algorithms. I think a > sentence something like the following would be useful here or in = Appendix A. >=20 > =E2=80=9CThe protected channel must provide confidentiality, = authentication, integrity=E2=80=9D and replay protection.=E2=80=9D #Keyur: Ack. Text to be incorporated. #Sean: Incorporated. > p4, section 4 (nit) >=20 > appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router. >=20 > suggest: >=20 > appropriate RPKI Trust Anchor Certificate (TA Cert) in the router. > or > appropriate RPKI Trust Anchor=E2=80=99s Certificate (TA Cert) in the = router. #Keyur: IMHO its later!! #Sean: Incorporated. > p4, section 4 >=20 > The operator also configures the Autonomous System (AS) number to be > used in the generated router certificate. This may be the sole AS > configured on the router, or an operator choice if the router is > configured with multiple ASs. >=20 > There=E2=80=99s a hint here that the operator configures the router to = generate just one router certificate. > RFC8209 allows the router certificate to have one or more ASs, but = recommends that there be multiple router certificates with one AS each. = Does this paragraph intend to limit a router to one router certificate = or just to limit the router to one AS per router certificate? I have = questions later about what happens if the router wants a router = certificate for each of multiple ASs. >=20 > Perhaps =E2=80=9CA router with multiple ASs can be configured with = multiple router certificates=E2=80=9D, maybe also =E2=80=9Cby following = the process of this document for reach desired certificate=E2=80=9D. >=20 > The operator configures or extracts from the router the BGP RouterID #Keyur: Ack. Text to be incorporated. #Sean: Added to the end of the 2nd para. The operator configures or extracts from the router the BGP RouterID = ... > RFC4271 and RFC8209 say =E2=80=9CBGP Identifier=E2=80=9D. OSPF uses = RouterID, and lots of C/J commands use RouterID, or router-id, or router = id, or RID, or . . . But consistency with the referenced specs would a = good thing. #Sean: It=E2=80=99s now BGP Identifier throughout. > p4, section 5 >=20 > I think it would be great to add a sentence here explaining that the = PKCS#10 (CSR) format does not include the AS and RouterID (sic). = Therefore, the operator must transmit the AS and RouterID (sic) as well = when it sends the CSR to the CA. =20 #Keyur: Ack. Text to be incorporated. #Sean: Text added, but I already thought it was in both sections. > That sentence applies to both the router generated keys and the = operator generated keys, so maybe it could go here. >=20 > The PKCS#10 format does not include the AS and RouterID for the router = certificate. Therefore, the operator must include the AS it has chosen = for the router and the RouterID when it sends the CSR to the RPKI CA. >=20 > That should be a MUST, shouldn=E2=80=99t it? #Sean: Okay so it took me forever to figure out that this is text = you=E2=80=99re proposing not something the draft. No I don=E2=80=99t = think it has to be MUST, the operator could send it via carrier pigeon = or in some other email. So how about: The PKCS#10 format does not include the AS and RouterID for the router certificate. Therefore, the operator transmits the AS it has chosen for the router and the RouterID when it sends the CSR to the RPKI CA. > p5, section 5.1 >=20 > The operator adds the chosen AS number and the RouterID to send to > the RPKI CA for the CA to certify. >=20 > My first reading was that the text meant the AS and RouterID were = added to the CSR. First, that=E2=80=99s not possible because of the = signature, unless there=E2=80=99s some key sharing going on. Second, = that=E2=80=99s not possible because the CSR format does not include the = AS and RouterID. Hence my comment above. >=20 > suggest: >=20 > The operator includes the chosen AS number and the RouterID when it = sends the CSR to #Keyur: Ack. Text to be incorporated with RouterID replaced by BGP = Identifier. #Sean: Sure, include is a synonym for add ;) > p4, section 5.1 (nit) >=20 > NOTE: If a router was to communicate directly with a CA to have the >=20 > suggest: >=20 > NOTE: If a router were to communicate directly with a CA to have the >=20 > p5, section 5.2 >=20 > and adds the chosen AS number and RouterID to be sent to the RPKI CA > for the CA to certify. >=20 > suggest: >=20 > and includes the chosen AS number and the RouterID when it sends the = CSR to the RPKI CA > for the CA to certify. #Keyur: Ack. Text to be incorporated with RouterID replaced by BGP = Identifier. #Sean: Sold! > p5, section 5.2.1 >=20 > section title =E2=80=9CUsing PKCS#8 to Transfer Public Key=E2=80=9D >=20 > PKCS#8 in RFC5958 can transfer public keys. But the following text is = talking about transferring the private key to the router. =20 >=20 > I think this title should be =E2=80=9CUsing PKCS#8 to Transfer Private = Key=E2=80=9D >=20 >=20 > A private key encapsulated in a PKCS #8 [RFC5958] should be further > encapsulated in Cryptographic Message Syntax (CMS) SignedData > [RFC5652] and signed with the AS's End Entity (EE) private key. #Keyur: Ack. Text to be incorporated. #Sean: Incorporated. > Would =E2=80=9CA private key encapsulated in a PKCS #8=E2=80=9D be = followed by "OTOH, a private key that is not encapsulated in a = PKCS#8=E2=80=9D? :-) >=20 > Suggest: >=20 > A private key can be encapsulated in a PKCS #8 [RFC5958] and should = be further > (or =E2=80=9Cis=E2=80=9D encapsulated or =E2=80=9Cshould be=E2=80=9D = encapsulated)=20 #Keyur: Ack. Text to be incorporated. #Sean: Incorporated. > Section 3 suggests various ways to =E2=80=9Cexchange PKI-related = information with routers=E2=80=9D. Is this PKCS#8 just one more way, or = is it the recommended way? The intro to section 5 suggests that copy = and paste could also be used, but doesn=E2=80=99t say if that would be = copy and paste of the PKCS#8. If Section 5 is also talking about = straight copy and paste of the hex or the PEM block, then that=E2=80=99s = another alternative. >=20 > RFC5958 discusses several =E2=80=9CCMS protecting content types=E2=80=9D= to protect the AsymmetricKeyPackage. I presume that the = encryption/enveloping content types are not needed because = confidentiality is being provided by the protected channel. But then = why use the CMS SignedData - would not the protected channel provide the = authentication and integrity needed? (But see potential reason below) >=20 >=20 > [RFC5652] and signed with the AS's End Entity (EE) private key. >=20 > Does it matter which AS=E2=80=99s EE cert the operator uses to sign = the PKCS#8? I presume that the AS must match an AS with which the = router is configured. Should the router check that? Does a router that = is configured with multiple ASs use this communication to tie the = private key to the appropriate AS & BGPsec session? =20 >=20 > If the answer is yes to both questions, should those actions be = mentioned here? >=20 > (I admit to being a bit dizzy here, but maybe the mapping of private = key to AS happens in the receipt of the router certificate.) =20 >=20 > include in the SignedData the RPKI CA certificate and relevant AS's > EE certificate(s). =20 >=20 > Maybe this is the reason for using the SignedData - to be able to = include the AS=E2=80=99s EE cert and give the router the means to tie = the private key to the right AS. >=20 > The router SHOULD verify the signature of the encapsulated PKCS#8 to > ensure the returned private key did in fact come from the operator, >=20 > Then shouldn=E2=80=99t it be signed with the operator=E2=80=99s = personal cert? :-) =20 >=20 > include in the SignedData the RPKI CA certificate and relevant AS's > EE certificate(s). >=20 > Elsewhere (sections 6 & 7) it mentions including the entire cert = chain. Should that be mentioned here as well? #Keyur: Think we discussed this point earlier. > p5, section 6 (nit) >=20 > The operator uses RPKI management tools to communicate with the > global RPKI system to have the appropriate CA validate the PKCS#10 > request, sign the key in the PKCS#10 (i.e., certify it) and = generated > PKCS#7 response, as well as publishing the certificate in the Global > RPKI. >=20 > for symmetry, suggest: >=20 > The operator uses RPKI management tools to communicate with the > global RPKI system to have the appropriate CA validate the PKCS#10 > request, sign the key in the PKCS#10 (i.e., certify it) and generate = a > PKCS#7 response, as well as publish the certificate in the Global > RPKI. #Sean: Incorporated. > p5, section 6=20 >=20 > External network connectivity may be needed if the = certificate > is to be published in the Global RPKI. >=20 > The previous sentence and the following paragraph do not hint that = there is any =E2=80=9Cif=E2=80=9D about the publication of the = certificate. Is there a case where the certificate is NOT =E2=80=9Cto = be published in the Global RPKI=E2=80=9D? #Keyur: VPNs? Multiple ASs under same admin domain. Would leave the line = as is. #Sean: It should stay based on RFC6484: Each CA MUST maintain a publicly accessible online repository and publish all RPKI-signed objects (intended for public consumption) via this repository in a manner that conforms with "A Profile for Resource Certificate Repository Structure" [RFC6481]. > p6, section 6 (nit) >=20 > 2. Returns the certificate to the operator's management station, > packaged in a PKCS#7 >=20 > Needs a reference. RFC2315? #Sean: Nope - I-D.lamps-rfc5751-bis, but I think that and adding PKCS#7 = certs-only message ought to clear this up. > In the operator-generated method, the operator SHOULD extract the > certificate from the PKCS#7, and verify that the private key it = holds > corresponds to the returned public key. >=20 > =E2=80=9Cit=E2=80=9D means the operator, right? #Keyur: Yep. > You get to Appendix B before the verification of the correspondence is = explained. I think it should be explained here. >=20 > The Appendix B says the operator should verify the signature on the = PKCS#10 CSR to verify the correspondence. But the operator generated = the key - can=E2=80=99t the correspondence be verified by checking the = certificate=E2=80=99s public key against the operator generated public = key (presuming the key was retained)? That seems too easy - I fear I am = missing some important part here. #Sean: Yes, but there=E2=80=99s more than one way to do that as = discussed earlier. I=E2=80=99m hoping the tweaks to s6 as mentioned = earlier clears this up. > p6, section 7 >=20 > The router SHOULD extract the certificate from the PKCS#7 and verify > that the public key corresponds to the stored private key.=20 >=20 > I think more needs to be said about how the correspondence would be = verified.=20 >=20 > Appendix B says the operator should verify the signature on the = PKCS#10 with the certificate to verify the correspondence to the private = key. That would work for the router as well if the router generated the = PKCS#10, but not if the operator generated the key pair and the PKCS#10. = But the router could sign any random bunch of bits and verify the = signature with the certificate to verify the correspondence. Should = those things be said? >=20 > Also, in the router-driven method, the router can verify the = correspondence simply by matching the certificate=E2=80=99s public key = with one of the router=E2=80=99s stored public keys. (Right? What am I = missing here?) >=20 > Should the router also verify that the AS mentioned in the returned = router certificate is an AS with which it is configured? >=20 > For a router that is configured with multiple ASs, is this where the = router ties the private key to the AS & BGPsec session with which the = private key should be used? #Keyur: In general for multiple AS it should have private key = association with each AS. The keys could overlap or be different? #Sean: I think we got a fix, if we can figure out where to put the text = that says there=E2=80=99s a bunch of ways to do this and just point to = it so that it=E2=80=99s not repeated everywhere. > The last two paragraphs of section 7 confuse me. >=20 > Even if the operator cannot extract the private key from the router, > this signature still provides a linkage between a private key and a > router. That is the operator can verify the proof of possession > (POP), as required by [RFC6484]. >=20 > What is =E2=80=9Cthis signature=E2=80=9D? And there=E2=80=99s been no = mention in this section of extracting the private key from the router. >=20 > This sounds to me like it belongs in section 5.1, maybe after:=20 > =E2=80=9Ct= o sign > the PKCS#10 with the private key. Once generated, the PKCS#10 is > returned to the operator over the protected channel. >=20 > And then: >=20 > NOTE: The signature on the PKCS#8 and Certificate need not be made = by > the same entity. Signing the PKCS#8, permits more advanced > configurations where the entity that generates the keys is not the > direct CA. >=20 > Maybe this belongs in section 5.2.1 where it is talking about the = PKCS#8? >=20 > Even so, I=E2=80=99m not sure what Certificate this text references. = The AS EE cert? >=20 > Both the router-driven method and the operator-driven method are not = the direct CA. Nowhere in this draft does it mention the CA generating = the keys. So the entire draft is one of these =E2=80=9Cadvanced = configurations=E2=80=9D. What am I missing here? >=20 > p7, section 8 (nit) >=20 > Transport" [RFC7030] or the original CMC transport protocol's >=20 > Is the possessive really needed here? I didn=E2=80=99t peruse the = RFC5273 thoroughly, but I can see that it defines a number of transport = methods, so maybe there is a =E2=80=9CCMC transport protocol=E2=80=99s = X=E2=80=9D missing here. #Sean: I leave this to the RFC editor to suggest the right way to do = this. I don=E2=80=99t think it=E2=80=99s confusing or even wrong to do = this. > p7, section 8 >=20 >=20 > This section uses =E2=80=9Ckey material=E2=80=9D several places. But = I=E2=80=99m not certain each use is talking about the same key material. >=20 > When the operator first establishes a secure > communication channel between the management system and the router, > this pre-installed key material is used to authenticate the router. >=20 > So the router gets keys as part of the manufacturing, where the = =E2=80=9Cpre-installed key material=E2=80=9D can be used in = communication with the operator. >=20 > I can see that this might make it easier for the router to communicate = directly with the CA and authenticate itself using these keys. But = section 5.1 notes that the CA has no way to authenticate the router. I = don=E2=80=99t know that the pre-installed key material could provide = that way to authenticate the router, without the participation of the = operator at some point. >=20 > The operator burden shifts here to include: >=20 > I=E2=80=99m not sure how to read this. Maybe =E2=80=9CThe operator = burdens that shift here can/will include=E2=80=9D. >=20 > I=E2=80=99m also not sure if both 1 and 2 are presumed to be = shifted/lifted, or if it is either. >=20 >=20 > 1. Securely communicating the router's authentication material to > the CA prior to operator initiating the router's CSR. CAs use > authentication material to determine whether the router is > eligible to receive a certificate. Authentication material at a > minimum includes the router's AS number and RouterID as well as > the router's key material, but can also include additional > information. Authentication material can be communicated to the > CA (i.e., CSRs signed by this key material are issued > certificates with this AS and RouterID) or to the router (i.e., > the operator uses the vendor-supplied management interface to > include the AS number and routerID in the router-generated CSR). >=20 > Who is doing the communicating in =E2=80=9Csecurely communicating to = the CA=E2=80=9D and =E2=80=9Ccan be communicated to the CA=E2=80=9D? In = the following paragraph, the text says =E2=80=9Cthe router is = communicating directly with the CA=E2=80=9D - is the communication in = this part 1 text going from the router to the CA? >=20 > What is the =E2=80=9Crouter=E2=80=99s key material=E2=80=9D? I could = read it both ways: >=20 > The paragraph above says that the pre-installed key material is used = to authenticate the router, so maybe the =E2=80=9Crouter=E2=80=99s key = material=E2=80=9D is the pre-installed key material. The text says that = the CA =E2=80=9Cuses=E2=80=9D the authentication material, which = includes the router=E2=80=99s key material, to determine whether to = issue the certificate. I don=E2=80=99t know how the pre-installed key = material could assure the CA that the router could be issued a cert, = without some coordination with the operator about that particular key = material. >=20 > Then the text says =E2=80=9CCSRs signed by this key material=E2=80=9D = which implies that the =E2=80=9Crouter=E2=80=99s key material=E2=80=9D = is the public/private key pair. >=20 > So I=E2=80=99m not certain what is going on here, or how the = pre-installed key material is helping. #Sean: See earlier discussion about why this is here. > Once configured, the operator can begin the process of enrolling the > router. =20 >=20 > What does =E2=80=9Conce configured=E2=80=9D mean? configuring the = router-operator protected channel? Doing the communication of = authentication material in 1 and 2 above? Configuring the router with = AS and RouterID? >=20 > Because the router is communicating directly with the CA, > there is no need for the operator to retrieve the PKCS#10 from the > router or return the PKCS#7 to the router as in Section 6. Note = that > the checks performed by the router, >=20 > Section 5 says the router returns the PKCS#10 to the operator. > Section 7 says the operator sends the PKCS#7 to the router and the = router performs checks. >=20 > suggest: >=20 > Because the router is communicating directly with the CA, > there is no need for the operator to retrieve the PKCS#10 from the > router as in Section 5 or return the PKCS#7 to the router as in = Section 7. Note that > the checks performed by the router in Section 7, #Sean: Incorporated > When a router is so configured the communication with the CA SHOULD > be automatically re-established >=20 > what does =E2=80=9Cso configured=E2=80=9D mean here? configured with = pre-installed key material? configured by the operator with AS and = RouterID? #Keyur: I understand it as =E2=80=9Cconfigured with authentication = material described in the section=E2=80=9D. > p8, section 9.1 (nit) >=20 > just for symmetry: >=20 > 4. Use some other kind of automated process to search for and track >=20 > suggest: >=20 > 4. The operator uses some other kind of automated process to search = for and track #Keyur: Ack. We should incorporate the text. #Sean: Sure. > p8, section 9.1 >=20 > Regardless of the technique used to track router certificate expiry > times, it is advisable to notify additional operators in the same > organization >=20 > =E2=80=9Cnotify additional operators=E2=80=9D =E2=80=94 In addition to = what? or after what? >=20 > I think you mean =E2=80=9Cmultiple=E2=80=9D operators, or I = misunderstand. #Sean: This is about ensuring that no single human can be at fault for = forgetting to get a new key. I.e., set up a calendar, tell your buddy, = etc. that this key (and others) expire on day X and we=E2=80=99d better = make sure that there=E2=80=99s a new key in place before then. > p9, section 9.3 (nits) >=20 > certificate to the router), and distributing the status takes time >=20 > Not sure what you mean by =E2=80=9Cstatus=E2=80=9D that needs to be = distributed. Are you talking about distributing the revocation = =E2=80=9Cstatus=E2=80=9D in the CRL? >=20 > Keeping the router operational and BGPsec-speaking is the ideal = goal, > but if operational practices do not allow this then reconfiguring = the > router to disabling BGPsec is likely preferred to bringing the = router > offline. >=20 > suggest: >=20 > router to disable BGPsec is likely preferred to bringing the router #Keyur: Incorporate the suggestion please. #Sean: Incorporated. > p10, section 9.4 >=20 > To allow operators to quickly replace routers without requiring > update and distribution of the corresponding public keys in the = RPKI, > routers SHOULD allow the private BGPsec key to inserted via a > protected session, e.g., SSH, NetConf (see [RFC6470]), SNMP. This > lets the operator escrow the old private key via the mechanism used > for operator-generated keys, see Section 5.2, such that it can be = re- > inserted into a replacement router. >=20 > The topic here is routers that won=E2=80=99t allow off-loading of = their keys. =20 >=20 > =E2=80=9Crouters SHOULD allow the private BGPsec key to inserted=E2=80=9D= >=20 > is the router that is doing the allowing the old, soon to be replaced = routers, or the newly installed routers? >=20 > =E2=80=9Cto inserted=E2=80=9D - where? - in the newly installed = router or in the management station? >=20 > =E2=80=9CThis lets the operator escrow the old private key=E2=80=9D - = sounds like the old router is allowing the private key to be =E2=80=9Cinse= rted in=E2=80=9D (exported to?) the management station. Right? #Keyur: The above text is merely stating that routers SHOULD allow = private BGPsec Key to be inserted via=E2=80=A6.. It is obviously for = routers (old with new image and old replaced by a newer router and NOT = the management station). > Is there a suggestion of how to get the routers to allow export of the = key, which is currently not allowed? #Sean: They either support this or they don=E2=80=99t. > I don=E2=80=99t see that section 5.2 says anything about a mechanism = for escrowing keys. It talks about installing a private key into a = router over the protected channel. If the citation to 5.2 is about the = =E2=80=9Csuch that it can be re-inserted=E2=80=9D part of the sentence, = then I get it. But the citation should move to the end of the = sentence. #Sean: If the operator generated the keys pair then it can send the = private key in the PKCS#8 to anybody it wants. > p10, section 10 (nit) >=20 > After > familiarizing one's self with the capabilities of the router, > operators are encouraged >=20 > suggest: >=20 > After > familiarizing themselves with the capabilities of the router, > operators are encouraged >=20 >=20 > or >=20 > After > familiarizing one's self with the capabilities of the router, > an operator is encouraged #Keyur: Suggest the later line. #Sean: Incorporated. > p11, section 10 (nit) >=20 > employees that no longer need access to > routers SHOULD be removed the router=20 >=20 > suggest >=20 > employees that no longer need access to > a router SHOULD be removed from the router=20 >=20 > or >=20 > employees that no longer need access to > a router SHOULD be removed from the router access [list] #Keyur: Suggest the later line. #Sean: Incorporated. > p11, section 10 (nit) >=20 > The > operator MUST ensure that installed CA certificate is valid. >=20 > suggest: >=20 > The > operator MUST ensure that the installed CA certificate is valid. #Keyur: Incorporate the text please. #Sean: Incorporated. > p14, section Appendix A >=20 > x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for > authentication. >=20 > is that an example, or a recommendation? #Keyur: Suggestion > p15, section Appendix B (nit) >=20 > that will generate the key pair for the algorithms noted in the main > body of this document; >=20 > the algorithms are not noted in the main body, but the end of section = 1 does cite RFC8208. =20 >=20 > the private key just generated to sign the certification request = with > the algorithms specified in the main body of this document; >=20 > the algorithms are not specified in the main body, but the end of = section 1 does cite RFC8208. #Keyur: Ok. Maybe change the text to reflect the end of section 1. #Sean: I mean they are in the main body but it=E2=80=99s by reference so = how about I use =E2=80=9Creferenced=E2=80=9D. Incorporated. > p16, Appendix B >=20 > Uses of =E2=80=9Cserial number=E2=80=9D: >=20 > the subject name and serial number for the router. The CA needs = this > and > CSR you sent; the certificate will include the subject name, serial > number, public key, and other fields > and > Create CSR and sign CSR with private key, and; o Step 3: Send CSR > file with the subject name and serial number to CA. >=20 > The first of these seem to mean the BGP Identifier aka RouterID. As = said before, RFC4271 and RFC8209 use the term BGP Identifier. >=20 > The second and third use of =E2=80=9Cserial number=E2=80=9D probably = also mean BGP Identifier aka RouterID (not the issued cert=E2=80=99s = serial number). #Keyur: Already handled above. > p17, section Appendix B (typo nit) >=20 > way through GPsec-enabling the router. >=20 > suggest: >=20 > way through BGPsec-enabling the router. #Keyur: Ack. Incorporate the text please. #Sean: Incorporated. > p17, section Appendix B >=20 > To avoid having routers with expired certificates > follow the recommendations in the Certification Policy (CP) = [RFC6484] >=20 > you could also mention section 9.1. #Keyur: Ack.=20 #Sean: I could, but where does that end? I could also put references in = each of AppA=E2=80=99s paragraph to front part of the document. I think = that I=E2=80=99m going to rely on readers having read the entire = document. spt From nobody Thu Apr 26 19:39:05 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93139126CD8; Thu, 26 Apr 2018 19:38:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152479673956.6007.12554521761230264666@ietfa.amsl.com> Date: Thu, 26 Apr 2018 19:38:59 -0700 Archived-At: Subject: [sidr] I-D Action: draft-ietf-sidr-slurm-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 02:38:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing WG of the IETF. Title : Simplified Local internet nUmber Resource Management with the RPKI (SLURM) Authors : Di Ma David Mandelberg Tim Bruijnzeels Filename : draft-ietf-sidr-slurm-08.txt Pages : 17 Date : 2018-04-26 Abstract: The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidr-slurm-08 https://datatracker.ietf.org/doc/html/draft-ietf-sidr-slurm-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-slurm-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 26 19:47:30 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B068012D86D for ; Thu, 26 Apr 2018 19:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAzZw0qSyW91 for ; Thu, 26 Apr 2018 19:47:24 -0700 (PDT) Received: from smtpbguseast2.qq.com (smtpbguseast2.qq.com [54.204.34.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0D712D7F9 for ; Thu, 26 Apr 2018 19:47:23 -0700 (PDT) X-QQ-mid: bizesmtp18t1524797237tyfcvn2u Received: from [192.168.218.249] (unknown [202.173.9.210]) by esmtp6.qq.com (ESMTP) with id ; Fri, 27 Apr 2018 10:47:16 +0800 (CST) X-QQ-SSF: 00400000000000F0FH50B00A0000000 X-QQ-FEAT: L3nIu5GLLqKom63ythCRxZuB3EpotqaWLecse3AD6KM9x4gqtO4HwYxxAbHcP 11HlFnhyFQCZsw4PfH39hxbyj4W9nBCH5K8Tw5JT1WxtjdZWssBkNHujBMqeGebNnUUH4Kq 9vq6RuonWGv7NJiXQlgc9gZNleObAeZvxaBxT8EXgr/6SnlSQdlf5lM/Cj9j//JhFlK1ueg yyDOJGh4b0xn6fIQWaBPESnNC5RV3Cx/t36YX6ck58gxeda4o3UNs030E4BRQ/Vd8Oc6Smp OH8/wsbZIHANHTQ9BIA5R3Yt1L3DR/l9WC6P5Cw1b4iMBL X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Di Ma In-Reply-To: Date: Fri, 27 Apr 2018 10:47:15 +0800 Cc: Chris Morrow , sidr-chairs@ietf.org, draft-ietf-sidr-slurm@ietf.org, The IESG , sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <38AC7D1E-1FDC-44BE-A664-6E08E0DD7F49@zdns.cn> References: <152261657190.23824.4759371193986790926.idtracker@ietfa.amsl.com> <9958A258-44B0-4965-B1C9-5E76031198C2@zdns.cn> To: Warren Kumari X-Mailer: Apple Mail (2.3445.6.18) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign4 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] Warren Kumari's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 02:47:29 -0000 Warren, The version -08 of SLURM draft has just been submitted after we authors = exchanged notes on JSON work in this document. Among others, we have dropped slurmTarget. Thanks again for your review and comments. Di > =E5=9C=A8 2018=E5=B9=B44=E6=9C=887=E6=97=A5=EF=BC=8C23:37=EF=BC=8CWarren= Kumari =E5=86=99=E9=81=93=EF=BC=9A >=20 >=20 > On Fri, Apr 6, 2018 at 10:02 AM Di Ma wrote: > Warren, >=20 > Thanks very much for your comments. >=20 > Please see my responses in lines. >=20 > > =E5=9C=A8 2018=E5=B9=B44=E6=9C=882=E6=97=A5=EF=BC=8C05:02=EF=BC=8CWarr= en Kumari =E5=86=99=E9=81=93=EF=BC=9A > > > > Warren Kumari has entered the following ballot position for > > draft-ietf-sidr-slurm-07: Discuss > > > > 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-sidr-slurm/ > > > > > > > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > > > > I don't understand the targeting as it related to domain/host names = (and > > suspect that others will have the same issue). > > > >> =46rom section 3.3: > > " If a "slurmTarget" element is > > present, an RP SHOULD verify that the target is an acceptable = value, > > and reject this SLURM file if the "slurmTarget" element is not > > acceptable.... Accordingly, the SLURM file > > source needs to indicate which RP(s) should make use of the file = by > > adding the domain name(s) of the RP(s) to the SLURM file target... > > Such a target value is a server name expressed in FQDN. > > > > "slurmTarget": [ > > { > > "hostname": "rpki.example.com", > > "comment": "This file is intended for RP server = rpki.example.com" > > } > > ] > > > > So, if I want to target multiple RPs (rpki1.example.com, = rpki2.example.com) can > > I do: > > > > "slurmTarget": [ > > { > > "hostname": "example.com", > > "comment": "This file is intended for RP server = rpki.example.com" > > } > > ] > > > > ? > > The "domain names(s)" versus "hostname" vs "server name expressed in = FQDN" text > > is handwavey. I'm assuming that I'd need to do: > > > > "slurmTarget": [ > > { > > "hostname": "rpki1.example.com", > > "comment": "This file is intended for RP server = rpki1.example.com" > > }, > > { > > "hostname": "rpki2.example.com", > > "comment": "This file is intended for the RP server, = rpki2.example.com" > > }, > > ]" > > Can you please make this clearer, and hopefully add more targets to = the > > examples? This seems like an easy fix / clarification, happy to = clear once it > > is, er, clear. > > > > >=20 > We authors have decided to drop the slurmTarget element completely. >=20 >=20 > That works for me=E2=80=8B.=E2=80=8B >=20 > Please =E2=80=8B(explicitly and loudly!) =E2=80=8Blet me know when the = new version is =E2=80=8Bsubmitted =E2=80=8Band I'll remove my discuss. >=20 >=20 > =E2=80=8BW=E2=80=8B >=20 >=20 > Initially the implementation team was thinking that it would be useful = to have the ability to offer the same set of SLURM files to all RPs = deployed in a network, where local config of the RP would then evaluate = the applicability of each file. However, now that both implementations = (RIPE NCC Validator and RPSTIR) progressed we reconsider and we feel = that it would be better to deal with this on the provisioning side. I.e. = only offer the SLURM file(s) relevant to each RP. >=20 >=20 > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > I have a few questions and editorial comments: > > > > 1: Section Abstract: > > ISPs can also be able to use the RPKI to validate the path of a BGP = route. > > I think you meant =E2=80=9CISPs can also use the RPKI..." >=20 >=20 > ACK. >=20 > > > > 2: Section 1. Introduction > > "However, an "RPKI relying party" (RP) may want to override some of = the > > information expressed via putative Trust Anchor(TA) and the = certificates > > downloaded from the RPKI repository system." I think this should be = either "a > > putative Trust Anchor (TA)" or "putative Trust Anchors (TA)" (single = vs > > plurals). I agree with others that "putative TA" is not a well known = term - > > perhaps you can find a better one? > > >=20 > We will use =E2=80=98configured Trust Anchor(s)=E2=80=99 instead. >=20 >=20 > > Section 3.4.1. Validated ROA Prefix Filters > > In the "prefixFilters examples", I think it would be helpful to = update the > > comments to be more explicit about what is being matched (e.g"All = VRPs covered > > by 198.51.100.0/24 and matching AS 64497") > > > > > ACK. >=20 > And we will update JSON related content in this draft based on = Adam=E2=80=99s suggestions. >=20 > Di >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Apr 26 19:59:29 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62E812D7F9 for ; Thu, 26 Apr 2018 19:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzdbIIQtI4Xa for ; Thu, 26 Apr 2018 19:59:24 -0700 (PDT) Received: from smtpbgau2.qq.com (smtpbgau2.qq.com [54.206.34.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CEED126CD8 for ; Thu, 26 Apr 2018 19:59:22 -0700 (PDT) X-QQ-mid: bizesmtp18t1524797954tffhiq4f Received: from [192.168.218.249] (unknown [202.173.9.210]) by esmtp6.qq.com (ESMTP) with id ; Fri, 27 Apr 2018 10:59:13 +0800 (CST) X-QQ-SSF: 00400000000000F0FH50B00A0000000 X-QQ-FEAT: SMzIe2qKYdN33U6pxXvfTImAiTu4NBPPURAl6NtkK5XXBzTpoLtkhKQBnSxXg sLABaHuFoFEsR/Nb7HIICXy/UdonlNG2PNv2y14LUhxLkv3koxR69s+RGF0E1W0gdVO9xTF MewD9ciSjcgbtfMLWjYR7aOwKy0W8BGPrZV9908s9Heya6ipYvcjKFNzJpI7iOwxs9F2LaV cfMUlpKmxMCwfGCuHd16R0y39x4nWU4QKqxeL9LzcldBHo6kosO9QvFjRz2YdxGdleGPbhl W2esC67G33v4+F74+B6n5UgJd6hnF8cTf9dHli9OWXHIkPSQpNXU6JHlOxx2Ebb2O5LQ== X-QQ-GoodBg: 2 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Di Ma In-Reply-To: <520D0E60-3639-4ED3-B7C4-5FBDC8BCF0CE@nostrum.com> Date: Fri, 27 Apr 2018 10:59:12 +0800 Cc: Tim Bruijnzeels , Chris Morrow , draft-ietf-sidr-slurm@ietf.org, sidr-chairs@ietf.org, The IESG , IETF SIDR Content-Transfer-Encoding: quoted-printable Message-Id: References: <152286976586.23998.1170348122023610014.idtracker@ietfa.amsl.com> <1EFF9988-F988-4A4C-B860-B244C1A59A6E@ripe.net> <520D0E60-3639-4ED3-B7C4-5FBDC8BCF0CE@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.6.18) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign2 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [sidr] Adam Roach's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 02:59:29 -0000 Adam, The version -08 of SLURM draft has just been submitted after we authors = exchanged notes on JSON work in this document. In addition to some editorial changes based on other ADs=A1=AF = suggestion, we authors mainly improved the description of the = specifications of the SLURM file with JSON format. According to your suggestion, we have specified the syntax of SLURM file = and normalized the usage of =A1=AEobject=A1=AF and =A1=AEmember=A1=AF = and so on, not merely relying on the instances we provided in this = document. Thanks to Tim=A1=AFs efforts on JSON work, we believe this version is = much more clear and easier to comprehend. Thanks again to your review and comments. Di > =D4=DA 2018=C4=EA4=D4=C25=C8=D5=A3=AC21:14=A3=ACAdam Roach = =D0=B4=B5=C0=A3=BA >=20 > Thanks for your quick response! Feel free to reach out to me directly = if you find any particular part of the structure challenging to = describe.=20 >=20 > /a >=20 >> On Apr 5, 2018, at 05:38, Tim Bruijnzeels wrote: >>=20 >> Dear Adam, all, >>=20 >> Thank you for this feedback - indeed we struggled a bit with formally = specifying JSON and relied on examples. I believe that with your = suggestions we can improve this. >>=20 >> As for IP address prefix notation - yes.. we should follow your = suggestion and cite RFC 4632 =A1=EC3.1 for prefix-length notation (both = for IPv4 and IPv6), and RFC 5952 for the syntax of IPv6 addresses. I am = so used to doing it this way that it slipped my mind to specify this, = but of course it should be unambiguous. >>=20 >> As I did most of the JSON text I will take it on me to re-work this = text and ask Di to merge it with the changes he is working on. There = should be a -08 version coming soon. >>=20 >> Tim >>=20 >>=20 >>> On 4 Apr 2018, at 21:22, Adam Roach wrote: >>>=20 >>> Adam Roach has entered the following ballot position for >>> draft-ietf-sidr-slurm-07: Discuss >>>=20 >>> 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.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> Thanks to everyone who worked on this document. The mechanism seems = useful. >>>=20 >>> I'm concerned that the document doesn't describe the file format = itself; >>> rather, it relies on examples to provide vital, nonsupplemental = information >>> such as the names of JSON object members, expected encodings (e.g., = strings >>> versus numbers), and distinction between arrays and objects. I'm = making this a >>> DISCUSS because I think the ambiguity here -- and, in particular the = ambiguity >>> about IP address prefix notation -- will lead to non-interoperable >>> implementations. >>>=20 >>> Using section =A1=EC3.2 as an example: >>>=20 >>>> A SLURM file consists of: >>>>=20 >>>> o A SLURM Version indication that MUST be 1 >>>>=20 >>>> o A slurmTarget element (Section 3.3) consisting of: >>>>=20 >>>> * Zero or more target elements. In this version of SLURM, there >>>> are two types of values for the target: ASN or Fully Qualified >>>> Domain Name(FQDN). If more than one target line is present, >>>> all targets MUST be acceptable to the RP. >>>>=20 >>>> o Validation Output Filters (Section 3.4), consisting of: >>>>=20 >>>> * An array of zero or more Prefix Filters, described in >>>> Section 3.4.1 >>>>=20 >>>> * An array of zero or more BGPsec Filters, described in >>>> Section 3.4.2 >>>>=20 >>>> o Locally Added Assertions (Section 3.5), consisting of: >>>>=20 >>>> * An array of zero or more Prefix Assertions, described in >>>> Section 3.5.1 >>>>=20 >>>> * An array of zero or more BGPsec Assertions, described in >>>> Section 3.5.2 >>>>=20 >>>=20 >>> As this is the normative description of the structure, I would have = expected an >>> indication that the file contains a JSON object (rather than, say, a = JSON >>> array), an indication that the version is to be encoded as a number = (rather than >>> a string), and clarification of what value members are expected to = contain. >>>=20 >>> For example, the following JSON object is in compliance with the = preceding >>> normative description (and, as far as I can tell, all other = normative text >>> in the document): >>>=20 >>> ["1", >>> ["65536", "rpki.example.com"], >>> [ >>> ["192.0.2.0/255.255.255.0", "All VRPs encompassed by prefix"], >>> ["64496", "All VPRs maching ASN"], >>> ["198.51.100.0/255.255.255.0", "64497", "All VRPs encompassed by = prefix, >>> matching ASN"] >>> ], >>> [ >>> ["64496", "All keys for ASN"], >>> ["Zm9v", "Key matching Router SKI"], >>> ["64497", "YmFy", "Key for ASN 64497 matching Router SKI"], >>> ], >>> [ >>> ["64496", "198.51.100.0/255.255.255.0", "My other important = route"], >>> ["64496", "2001:DB8::/FFFF:FFFF::", "48", >>> "My other important de-aggregated routes"], >>> ], >>> [ >>> ["64496", "My known key for my important ASN", >>> "", ""] >>> ] >>> ] >>>=20 >>> Fixing this should be pretty easy; the document simply needs text = added that >>> describes the JSON structure explicitly, with clear indications of = how values >>> are to be encoded. For example, the preceding text I quote becomes: >>>=20 >>> A SLURM file consists of a single JSON object containing the = following >>> members: >>>=20 >>> o A "slurmVersion" member that MUST be set to 1, encoded as a = number >>>=20 >>> o A "slurmTarget" member (Section 3.3) If more than one target line = is >>> present, all targets MUST be acceptable to the RP. The = "slurmTarget" >>> member is encoded as an array of zero or more objects. Each = object in the >>> array contains exactly one member. In this version of SLURM, the = member >>> may be named either: >>>=20 >>> * "asn", in which case it contains an ASN, or >>>=20 >>> * "hostname", in which case it contains a Fully Qualified Domain >>> Name (FQDN). >>>=20 >>> o A "validationOutputFilters" member (Section 3.4), whose value is = an >>> object. The object MUST contain exactly two members: >>>=20 >>> * A "prefixFilters" member, whose value is described in >>> Section 3.4.1 >>>=20 >>> * A "bgpsecFilters" member, whose value is described in >>> Section 3.4.2 >>>=20 >>> o A "locallyAddedAssertions" member (Section 3.5), whose value is = an >>> object. The object MUST contain exactly two members: >>>=20 >>> * A "prefixAssertions" member, whose value is described in >>> Section 3.5.1 >>>=20 >>> * A "bgpsecAssertions" member, whose value is described in >>> Section 3.5.2 >>>=20 >>>=20 >>> Gotchas to watch out for include: >>>=20 >>> - If you're using the word "element" to describe something in a JSON = object, >>> you probably need to find a more specific word. This document, for = example, >>> uses "element" instead of "member" in most places. >>>=20 >>> - Everywhere you use the word "structure," replace it with either = "array" or >>> "object," as appropriate. >>>=20 >>> - When values can be encoded as either a number or a string (e.g., = as with >>> "slurmVersion" above, or with AS numbers), indicate which encoding = is >>> expected. >>>=20 >>> - For IP prefixes, be clear about acceptable syntax. For example: is >>> the RFC 950 syntax ("192.0.2.0/255.255.255.0") acceptable? My = suggestion is >>> to cite RFC 4632 =A1=EC3.1 for prefix-length notation (both for IPv4 = and IPv6), >>> and RFC 5952 for the syntax of IPv6 addresses. >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> The remaining comments are in document order. >>>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> Title: >>>=20 >>> It seems odd to use the stylized capitalization (e.g., "nUmber") = without >>> following it by the "SLURM" acronym. Consider adding "(SLURM)" to = the title. >>>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =A1=EC3.1: >>>=20 >>>> This document describes responses in the JSON [RFC8259] format. >>>=20 >>> I don't think this means to say "responses," does it? It appears to = be >>> describing a JSON document rather than a request/response protocol. >>>=20 >>>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =A1=EC3.3: >>>=20 >>>> A SLURM file MUST specify a "slurmTarget" element that identifies = the >>>> environment in which the SLURM file is intended to be used. The >>>> "slurmTarget" element MAY have an empty array as its value, which >>>> means "applies to all". The meaning of the "slurmTarget" element, = if >>>> present, is determined by the user. If a "slurmTarget" element is >>>> present, an RP SHOULD verify that the target is an acceptable = value, >>>> and reject this SLURM file if the "slurmTarget" element is not >>>> acceptable. Each "slurmTarget" element contains merely one "asn" = or >>>> one "hostname". An explanatory "comment" MAY be included in each >>>> "slurmTarget" element so that it can be shown to users of the RP >>>> software. >>>=20 >>> When reworking this paragraph in particular, please be careful to = distinguish >>> between the "slurmTarget" member and the elements in the array that = constitutes >>> its value. The preceding text calls both of these things = '"slurmTarget" >>> element,' which is very confusing. >>>=20 >>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Apr 27 07:23:18 2018 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48C212422F; Fri, 27 Apr 2018 07:23:16 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng2tzeMudSmv; Fri, 27 Apr 2018 07:23:14 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0136.outbound.protection.outlook.com [23.103.201.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99D41201F2; Fri, 27 Apr 2018 07:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XOquVHHbKnDlL27jcSzXbqgfB1RmfrKJDrqXSO3kqZ8=; b=s4Qc0IIhkzDioBiqjQd4OLwsrhg3L9AKmv0WiJAL+naAzkFCExER9J+s/PDxTRP+x3omD+rHzzrY0/eE0rFIWMYLLvQ0gWS1BB81MInX8jgKfr+Lei6qzogx/+z2JAvaOMrVXeSjBLgQmkY7cck8iyLbndpKBiRo8+nD7OQPKDI= Received: from BYAPR09MB2773.namprd09.prod.outlook.com (52.135.224.26) by BYAPR09MB2776.namprd09.prod.outlook.com (52.135.224.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Fri, 27 Apr 2018 14:23:11 +0000 Received: from BYAPR09MB2773.namprd09.prod.outlook.com ([fe80::4cf3:af64:d3c9:6d33]) by BYAPR09MB2773.namprd09.prod.outlook.com ([fe80::4cf3:af64:d3c9:6d33%13]) with mapi id 15.20.0696.019; Fri, 27 Apr 2018 14:23:11 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "sidr wg list (sidr@ietf.org)" , "sidrops@ietf.org" , "idr@ietf.org" CC: "n.brownlee@auckland.ac.nz" , Adrian Farrel , Wes George , "Jeffrey Haas" , Alvaro Retana Thread-Topic: RFC 8374: BGPsec design discussions document published as an Independent Submissions RFC Thread-Index: AdPeL83SZQab8vSyQAmNTppwti1hRg== Date: Fri, 27 Apr 2018 14:23:11 +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: [129.6.140.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR09MB2776; 7:PYpRBDtv3WajU/nd2sav30CzuVqNV9JVZWjmMS+ug7nsylXXb8EZdmBbBjRJhYJEdxOw+MZu+De7X6VlZBqpMGukTX+7mnvA6COZvmfi/kQeIp5u3LxuSUItUU8P+OHBgITrT8f7SZrlnNg4RQq7FnvLUKHARlQUXviRSyZVQClh2dUw7ks+LUMc+IpTtzS12KbzOwSaYVL0kQzI56CilNktKKyiUIfXGVdHit+YtD5oDTh0N6bCKeunY+LwITX1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR09MB2776; x-ms-traffictypediagnostic: BYAPR09MB2776: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231232)(944501410)(52105095)(10201501046)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BYAPR09MB2776; BCL:0; PCL:0; RULEID:; SRVR:BYAPR09MB2776; x-forefront-prvs: 0655F9F006 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39860400002)(396003)(346002)(39380400002)(199004)(189003)(2906002)(2900100001)(3280700002)(2501003)(14454004)(81166006)(5250100002)(74316002)(186003)(4326008)(486006)(25786009)(105586002)(476003)(305945005)(6116002)(33656002)(53936002)(3846002)(97736004)(99286004)(8676002)(68736007)(106356001)(966005)(8936002)(26005)(81156014)(6436002)(478600001)(6506007)(66066001)(316002)(3660700001)(39060400002)(5660300001)(55016002)(54906003)(86362001)(7696005)(102836004)(110136005)(2201001)(9686003)(6306002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR09MB2776; H:BYAPR09MB2773.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: 7kEnZwySSNXx+B0OJs6FCa3WeYO5TJRrgQZKfVw3klOw1r+wFeMEjzvmlMJHBAZgV3cu42490ehJ7C8tyJlQX1M4N3IMjp5ba/EV5qlJI7KGvtOtEpVZfOWvklM58T/hvLbaPkdUXIKUGz4Q7jYOj970T4TX61zn8mXf9WSTsfc9ZOku8AaoP/5mFnEUloQs spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: d07bac4e-cb80-4072-dc0f-08d5ac4a67e3 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: d07bac4e-cb80-4072-dc0f-08d5ac4a67e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2018 14:23:11.2399 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR09MB2776 Archived-At: Subject: [sidr] RFC 8374: BGPsec design discussions document published as an Independent Submissions RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 14:23:17 -0000 In its draft form, the BGPsec design discussions document was=20 found useful and cited many times during sidr/sidrops/idr discussions on BG= Psec.=20 It is now published as an Independent Submissions RFC:=20 https://tools.ietf.org/html/rfc8374=20 The authors/designers/advocates team wishes to thank=20 the ISEs (Nevil Brownlee - previous and Adrian Farrel - current), Alvaro (r= outing AD), the document reviewers Wes George and Jeff Haas, and many other WG members for their support, reviews, and comments over the course of the work/public= ation process. =20 =20 Sriram From nobody Mon Apr 30 10:08:55 2018 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3281201F8; Mon, 30 Apr 2018 10:08:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-sidr-slurm@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152510812670.11743.1039690646995956955.idtracker@ietfa.amsl.com> Date: Mon, 30 Apr 2018 10:08:46 -0700 Archived-At: Subject: [sidr] Warren Kumari's No Objection on draft-ietf-sidr-slurm-08: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 17:08:47 -0000 Warren Kumari has entered the following ballot position for draft-ietf-sidr-slurm-08: 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-sidr-slurm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my concerns / DISCUSS - I'm clearing my position. W ----- I have a few questions and editorial comments: 1: Section Abstract: ISPs can also be able to use the RPKI to validate the path of a BGP route. I think you meant "ISPs can also use the RPKI..." 2: Section 1. Introduction "However, an "RPKI relying party" (RP) may want to override some of the information expressed via putative Trust Anchor(TA) and the certificates downloaded from the RPKI repository system." I think this should be either "a putative Trust Anchor (TA)" or "putative Trust Anchors (TA)" (single vs plurals). I agree with others that "putative TA" is not a well known term - perhaps you can find a better one? Section 3.4.1. Validated ROA Prefix Filters In the "prefixFilters examples", I think it would be helpful to update the comments to be more explicit about what is being matched (e.g"All VRPs covered by 198.51.100.0/24 and matching AS 64497") --- Original DISCUSS for hysterical raisins --- I don't understand the targeting as it related to domain/host names (and suspect that others will have the same issue). >From section 3.3: " If a "slurmTarget" element is present, an RP SHOULD verify that the target is an acceptable value, and reject this SLURM file if the "slurmTarget" element is not acceptable.... Accordingly, the SLURM file source needs to indicate which RP(s) should make use of the file by adding the domain name(s) of the RP(s) to the SLURM file target... Such a target value is a server name expressed in FQDN. "slurmTarget": [ { "hostname": "rpki.example.com", "comment": "This file is intended for RP server rpki.example.com" } ] So, if I want to target multiple RPs (rpki1.example.com, rpki2.example.com) can I do: "slurmTarget": [ { "hostname": "example.com", "comment": "This file is intended for RP server rpki.example.com" } ] ? The "domain names(s)" versus "hostname" vs "server name expressed in FQDN" text is handwavey. I'm assuming that I'd need to do: "slurmTarget": [ { "hostname": "rpki1.example.com", "comment": "This file is intended for RP server rpki1.example.com" }, { "hostname": "rpki2.example.com", "comment": "This file is intended for the RP server, rpki2.example.com" }, ]" Can you please make this clearer, and hopefully add more targets to the examples? This seems like an easy fix / clarification, happy to clear once it is, er, clear.