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

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] Benjamin Kaduk's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Benjamin Kaduk]

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

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

[Di Ma]

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