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

[Stephen Farrell <[e-mail]>]

Hiya,

On 04/01/17 15:44, Randy Bush wrote:
>> - 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.

Grand.

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

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.

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

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.

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