Re: [sidr] Benjamin Kaduk's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Di Ma]

Benjamin,

Thanks very much for your comments.

Please see my responses in lines.


> 在 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.
> 

ACK.

> Section 3.2
> 
> OLD:
>   o  A SLURM Version indication that MUST be 1
> 
> NEW:
>   o  A SLURM Version indication.  This document specifies version 1.
> 

ACK.

> 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?
> 

We authors have decided to drop the slurmTarget element completely. 

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):
> 
> "is locally configured with" does not mention SLURM at all as being
> involved in that configuration; perhaps it should.
> 

We authors are going to make changes as follows: 

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
> 
>   [...] 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?

There is a MAY in the first sentence after all.

We will add in this section that ‘The RP gets multiple SLURM files as a set, 
and the whole set MUST be rejected in case of any overlaps between SLURM files.'

> 
> 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.
> 

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 

Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Spencer Dawkins at IETF]

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
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Di Ma]

Spencer,

Thanks for your explanation. 

Di

> 在 2018年4月6日，23:06，Spencer Dawkins at IETF  写道：
> 
> 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



___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Di Ma]

Alexey,

Thanks very much for your comments.

Please see authors' responses in lines.

> 在 2018年4月2日，18:47，Alexey Melnikov  写道：
> 
> 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.
> 
> 

We authors think this is really a good point.

We will say in next version: 

The Router SKI is the Base64 encoding without trailing ‘=‘ (Section 5 of 
RFC4648 ) of the certificate’s Subject Public Key as described in Section 
4.8.2. of RFC6487. 

Di



___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Eric Rescorla's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Eric Rescorla]

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
>
>
>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Di Ma]

Ben,

Thanks very much for your comments.

Please see authors' responses in lines.

> 在 2018年4月4日，03:43，Ben Campbell  写道：
> 
> 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.

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. 

> 
> Minor Comments:
> 
> §1.1: The document contains at least a few lower case instances of "must".
> Please consider using the boilerplate from RFC 8174.
> 

ACK. 

> §3.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 :-)

> 
> §8.2, " [RFC4648]": The document requires Base64 encoding. Doesn't that make
> this a normative reference?

But it has been listed as 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.

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 ‘local view’ throughout the 
document.

> 
> §1, last paragraph: Please expand or define rpki-rtr on first mention.

ACK. 

> 
> §3.4.1: Please expand SKI on first mention. (You do so in the second mention
> :-) )
> 
> 
ACK. 

Di

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Warren Kumari's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT)

[Di Ma]

Warren,

Thanks very much for your comments.

Please see my responses in lines.

> 在 2018年4月2日，05:02，Warren Kumari  写道：
> 
> 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.
> 
> 

We authors have decided to drop the slurmTarget element completely. 

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:
> --
> 
> 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..."


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 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?
> 

We will use ‘configured Trust Anchor(s)’ 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’s 
suggestions. 

Di

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Eric Rescorla's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Di Ma]

Eric,

Thanks very much for your comments.

Please see authors' responses in lines.

> 在 2018年4月3日，00:56，Eric Rescorla  写道：
> 
> 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"


We authors will go with “configured Trust Anchor(s) (TAs)”

> 
>   operators are hereby called Simplified Local internet nUmber Resource
>   Management with the RPKI (SLURM).
> 
> It would help here to say that this includes filtering.
> 

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
> 
> citation for rpki-rtr plese.

ACK. 

> 
>   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.
> 

ACK. 

>   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.


We authors have decided to drop slurmTarget element.


> 
>   [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?
> 

Good point. 

We will say in next version:

The Router SKI is the Base64 encoding without trailing ‘=‘ (Section 5 of 
RFC4648 ) of the certificate’s Subject Public Key as described in Section 
4.8.2. of RFC6487. 

The Router Public Key is router public key’s 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:
> 
> 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. 

And we will update JSON related content throughout this draft based on your 
suggestion together with Adam’s. 


> 
> 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].


> 
>  contained by any prefix in any  or
>   in file Z.
> 

Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Di Ma]

Alissa,

Thanks very much for your comments.

Is BCP 14 exactly the same document as RFC 2119?

Di

> 在 2018年4月5日，02:00，Alissa Cooper  写道：
> 
> 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.
> 
> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr



___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Benjamin Kaduk's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Benjamin Kaduk]

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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr