Subject: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 04 Jan 2017 05:47:29 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-sidr-bgpsec-ops-13: 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-bgpsec-ops/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I reviewed -12 but I think all these comments are as
(ir)relevant as ever;-)

- general: given where we are with deployment I wonder
would it be a good idea if this document explicitly said
sometthing to the effect that "it's early days, this is
what we think is the BCP but that may change over time, so
while we think doing this is right, be careful to not
paint yourself into a corner when doing this."

- intro: this seems to say: first do rpki and only when
that's finished start on bgpsec - is that really what's
meant? The rest of the document makes me doubt that. I
think what you maybe meant was "Any specific ASN needs to
have setup RPKI for itself before it can speak BGPsec." 

- intro, 3rd para: where are the "special operational
considerations" explained? A reference would be good.  If
there's no good reference, I'm not clear why saying this
is useful. (Actual operators might find this clear of
course, in which case, please ignore me.)

- section 2: this refers to the BGPsec overview which
refers back to this document, but says that this is
informational rather than a BCP. Just noting that in case
there's confusion and that's not just a typo or a case of
the overview not having been updated. I expect the fix is
to change the text in the overview.

- section 5: What does "fully BGPSEC enabled" mean
exactly? That could be referring to signing or to
validation of signatures (with or without hard fails) or
to never emitting unsigned or accepting unsigned
announcements or to some combination of the above.  It
might be better to avoid use of such a term in order to
avoid having to define it for now. (This relates also to
the mail subsequent to Mirja's comments.)

- section 7: MED could do with expansion and a reference.

- section 7: I'm not clear what you mean by "RPKI version
skew." You could explain that or maybe use another basis
to explain why R0 and R1 might disagree, e.g. revocation
status info availability or freshness maybe.

- section 8: "forward signed to R" is a bit opaque (for me
anyway, before I read the protocol draft). Maybe better to
explain this a bit more.

- I-D nits complains about some easily fixable things
(about which I do not care:-)

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Jan 2017 00:44:32 +0900

> paint yourself into a corner when doing this."

added

    As with most operational practices, this document will likely
    evolve.
    
> have setup RPKI for itself before it can speak BGPsec."

we are in a twisty maze of nomenclature.  to be boringly clear (i
suspect you know this stuff, but i believe that you are using the wrong
terms).

    The RPKI is the X.509 based hierarchy [rfc 6481] with is congruent
    with the internet IP address allocation administration, the IANA,
    RIRS, ISPs, ...  It is the substrate on which the next two are
    based.  It is currently deployed in all five administrative regions.

    RPKI-based Origin Validation [rfc 6811] uses some of the RPKI data
    to allow a router to verify that the autonomous system announcing an
    IP address prefix is in fact authorized to do so.  This is not
    crypto checked so can be violated.  But it should prevent the vast
    majority of accidental 'hijackings' on the internet today, e.g. the
    famous Pakistani accidental announcement of YouTube's address space.
    RPKI-based origin validation is in shipping code from Cisco,
    Juniper, AlcLu, and others.

    Path validation, AKA BGPsec, is a the next technology step with only
    proto/test code.  It uses the full crypto information of the RPKI to
    allow a receiver of a BGP announcement to formally cryptographically
    validate that the originating autonomous system was truly authorized
    to announce the IP address prefix, and that the systems through
    which the announcement passed were indeed those which the
    sender/forwarder at each hop intended.

so, i think you are referring to

   As core BGPsec-capable routers may require large memory and/or modern
   CPUs, origin validation based on the Resource Public Key
   Infrastructure (RPKI), [RFC6811], will occur over some years and
   BGPsec will start to deploy after that.

as rpki is deployed to a fair extent, origin validation is baked into
current routers, and bgpsec in the core will require bigger hardware, OV
before BGPsec would seem to be the sequence.

otoh, your last statement is true, an operator will have to set up rpki
data before deploying either origin validation or bgpsec.  rpki is
needed for both.

so i am not sure what you are suggesting i do.

> course, in which case, please ignore me.)

how about

    This has special operational considerations, see Section 6.

> to change the text in the overview.

i can support that :)

> the mail subsequent to Mirja's comments.)

somehow i do not think that adding more words helps, but

   In an AS where edge routers speak BGPsec and therefore inject BGPsec
   paths into the iBGP, Route Reflectors MUST have BGPsec enabled if and
   only if there are eBGP speakers in their client cone, i.e. an RR
   client or the transitive closure of a client's customers' customers'
   customers' etc.

> - section 7: MED could do with expansion and a reference.

how about

    ... value such as local-preference or multi-exit discriminator
    (MED).

> status info availability or freshness maybe.

sigh.  more words.

   As the mildly stochastic timing of RPKI propagation may cause version
   skew across routers, an AS Path which does not validate at router R0
   might validate at R1.

> anyway, before I read the protocol draft). Maybe better to

2.  Suggested Reading

   It is assumed that the reader understands BGP, see [RFC4271], BGPsec,
   [I-D.ietf-sidr-bgpsec-overview], the RPKI, see [RFC6480], the RPKI
   Repository Structure, see [RFC6481], and Route Origin Authorizations
   (ROAs), see [RFC6482].

should i change that from -overview to -protocol?

randy

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Jan 2017 16:09:46 +0000

Hiya,

>     As with most operational practices, this document will likely

Grand.

> so i am not sure what you are suggesting i do.

I was suggesting re-wording so that the text cannot be read so
as to mean "don't bother with BGPsec until the entire world has
finished deploying OV."

Maybe:

   As core BGPsec-capable routers may require large memory and/or modern
   CPUs, origin validation based on the Resource Public Key
   Infrastructure (RPKI), [RFC6811], will occur over some years and,
   once origin validation has been deployed at an AS, then BGPsec
   can start to deploy in that AS.

Though I'm not sure that's precisely right either.

>     This has special operational considerations, see Section 6.

Ack. And the same for all your other suggested changes.

And to be sure to be sure, none of the above should be blocking
and do feel entirely free to not make any of these changes if
you'd rather not.

Thanks,
S.

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Jan 2017 01:48:17 +0900

> Though I'm not sure that's precisely right either.

let me get back to this tomorrow with coffee.

> and do feel entirely free to not make any of these changes if

i made the ones i said i was making, which was most.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Jan 2017 16:24:27 +0900

> Though I'm not sure that's precisely right either.

ok, how about

   Origin Validation based on the Resource Public Key Infrastructure
   (RPKI), [RFC6811], is in its early phases.  As BGPsec,
   [I-D.ietf-sidr-bgpsec-protocol] may require larger memory and/or more
   modern CPUs, it expected to be deployed incrementally over a longer
   time span.  BGPsec is a new protocol with many operational
   considerations which this document attempts to describe.  As with
   most operational practices, this document will likely evolve.

i am still not in love with it.

longitudinal study: how has the distribution of draft word count pre and
post iesg review changed over time?

for research papers, there is considerable pressure to be terse to get
one's content into restricted page limits.

randy