Skip to main content

Simplified Local Internet Number Resource Management with the RPKI (SLURM)
draft-ietf-sidr-slurm-08

Yes

(Alvaro Retana)

No Objection

(Deborah Brungard)
(Martin Vigoureux)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 06 and is now closed.

Warren Kumari
(was Discuss) No Objection
Comment (2018-04-30) Unknown
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.
Alvaro Retana Former IESG member
Yes
Yes (for -06) Unknown

                            
Adam Roach Former IESG member
(was Discuss) No Objection
No Objection (2018-05-09) Unknown
Thanks for addressing my DISCUSS! The new text looks good.
Alexey Melnikov Former IESG member
No Objection
No Objection (2018-04-02 for -07) Unknown
I agree with Warren's DISCUSS.

I also share Benjamin's sadness about the Security Considerations section.

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.
Alissa Cooper Former IESG member
No Objection
No Objection (2018-04-04 for -07) Unknown
Please cite BCP 14 rather than RFC 2119, assuming you intend for normative keywords to have their normative meaning in uppercase only.
Ben Campbell Former IESG member
No Objection
No Objection (2018-04-03 for -07) Unknown
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 :-) )
Benjamin Kaduk Former IESG member
No Objection
No Objection (2018-03-30 for -07) Unknown
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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Eric Rescorla Former IESG member
No Objection
No Objection (2018-04-02 for -07) Unknown
   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 <prefixAssertions> or
          <prefixFilters> in file Z.

OK, so you are going to error out even if there are assertions which are identical?
Ignas Bagdonas Former IESG member
No Objection
No Objection (2018-03-27 for -07) Unknown
A few comments: 

1. Document uses all capital form of AND for filters containing both prefixes and ASNs, and filters containing ASNs and SKIs. That is not part of RFC2119 language. 

2. s/Route Origination Authorization/Route Origin Authorization

3. If a local assertion is added without a matching filter, does it take priority over existing assertion? 

4. The term 'putative TA' has been flagged a couple of times in various reviews as being not known. It does not appear to be formally defined, RFC7730 seems to be the closest source - while it is not formally defined there either.
Martin Vigoureux Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2018-03-29 for -07) Unknown
The shepherd write-up says "Internet Standard" but I assume "Proposed Standard" as indicated in the datatracker is correct...?
Spencer Dawkins Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -07) Unknown