BGPsec Operational Considerations
draft-ietf-sidr-bgpsec-ops-16

= Section 5 =

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

"MUST ... if and only if" is a strange construction. I'm assuming what is meant here is that Route Reflectors MUST NOT enable BGPsec unless there are eBGP speakers in their client cone -- that might be a more sensible way to phrase this since clearly enabling BGPsec isn't required for anyone. Also, for a normative requirement I think it would be better to be specific rather than saying "etc." (e.g., "a client's customers or customers thereof" or something like that).

"Additionally, outsourcing verification is not prudent
   security practice."

Isn't that part of the point of draft-ietf-sidr-rpki-rtr-rfc6810-bis though? I know this paragraph is not talking about that but since use of a trusted cache was mentioned in the protocol draft, this struck me as a slight discrepancy.

Update:  I noted when reviewing other sidr drafts on this telechat agenda that this draft treats 2119 keywords differently than the other drafts. That is, this draft explicitly excludes lower case versions of the 2119 keywords, while the other related drafts do not. Assuming that these drafts have the same target audience, I think that will be confusing to readers.

I am okay with either approach; in fact I somewhat prefer excluding lower case versions. But I think consistency among a related group of drafts is more important.

Just a few minor and editorial comments:

-1, first paragraph: "It is thought...": Can you mention "who" thinks it? Otherwise that reads as "weasel words".

-1, third paragraph: Please consider writing out "also known as"

-4, first paragraph: I found "either" followed by "and/or" a bit confusing. I suggest simply dropping the word "either".

-4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended to offer permission, or describe reality? (The latter should not use a 2119 keyword.)

-4, last paragraph: "a prudent operator will..." sounds like it might be worthy of a SHOULD.

-6, first paragraph: "SHOULD/MUST only" constructions tend to be ambiguous. In this case, are we saying SHOULD only originated signed announcements, as opposed to unsigned announcements? Or as opposed to validating received assignments? If the latter, then the "need not validate" seems to weaken the SHOULD.

-6, last paragraph: Can something be cited for the 84% assertion?

-7, paragraph 6: This seems to say that signed paths MUST be signed. Does the "MUST be signed if sent to external BGP speakers" mean that the existing signature must not be stripped (as stated more weakly in the previous sentence), or does it mean the sender must re-sign the path?

-7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid." seems like a statement of fact.

-12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as needed to understand this document. That suggests it should be a normative reference. 



-

Happy to see an operational considerations document at the same time at the protocol specifications, even if we know that "It is expected to evolve as BGPsec is formalized and initially deployed."
Thanks Randy

Proposal: one extra section on migration/deployability
There is text in draft-ietf-sidr-bgpsec-protocol-21

   How will migration from BGP to BGPsec look like?  What are the
   benefits for the first adopters?  Initially small groups of
   contiguous ASes would be doing BGPsec.  There would be possibly one
   or more such groups in different geographic regions of the global
   Internet.  Only the routes originated within each group and
   propagated within its borders would get the benefits of cryptographic
   AS path protection.  As BGPsec adoption grows, each group grows in
   size and eventually they join together to form even larger BGPsec
   capable groups of contiguous ASes.  The benefit for early adopters
   starts with AS path security within the contiguous-AS regions spanned
   by their respective groups.  Over time they would see those
   contiguous-AS regions grow much larger.

Roni Even's Gen-ART review comments are worth checking -- did not see a response yet.

I support Stephen's comments.

Quick question: I'm by far not an expert here, but I remember that there used to be some concerns that it is practical not possible to disable BGPsec once enabled. If that's (still) true, should this be mentioned here?

Again, thanks for a very readable document.

I did have one question - I saw that you're chatting about the same paragraph with Alissa, but I'm wondering if "the transitive closure of a client's customers" has a precise meaning. I know what a customer is, at the hand-waving level, but I'm not sure how I would know whether any particular case fit that description, at the corner-case level. Is "customer" being used a shorthand for another term that isn't depending on an economic transaction?

(If this was "the transitive closure of a client's clients", for instance, I would know what that meant - and I'm not at all suggesting that's correct, only offering it as an example of the kind of thing I'm asking about)

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

Thanks for creating a document to begin to pen the upcoming gotchas of BGPsec.

I have a couple small comments.

Section 3. "All non-ROA considerations in the section on RPKI Distribution and Maintenance of [RFC7115] apply."

Apart from the sentence being stylistically terse (which I don't really care about), If you follow this as a reading list and hit section 3 of RFC7115 it leaves the reader wondering what considerations apply exactly. May I suggest:

" The considerations for RPKI objects (Certificates, Certificate Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]), Trust Anchor Locators (TALs) [RFC6490], cache behaviours of synchronisation and validation from the section on RPKI Distribution and Maintenance of [RFC7115] apply. Specific considerations relating to ROA objects do not apply to this document" 

Forward apologies if that sounds pedantic. 

This is surely early days of BGPsec adoption and use. I have personal opinions about how adoption will go and what will be learnt or discovered along the way. So I do share Stephen's observation about painting one's self into a corner.