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

[Randy Bush <[e-mail]>]

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

added

    As with most operational practices, this document will likely
    evolve.
    
> - 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."

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.

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

how about

    This has special operational considerations, see Section 6.

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

i can support that :)

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

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

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

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.

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

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