Subject: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 2 Nov 2016 15:35:18 +0000

Randy:

Hi!  Thanks for working on this document!

I have two issues I want to highlight upfront, and then some comments (below).  I would like to see these two issues addressed, along with the Major comments below, before moving the document forward.

These two upfront issues are probably more questions for the Chairs/Shepherd.

1. Why is this document a BCP?  A BCP is a document that describes “the community's best current thinking…on what is believed to be the best way to perform some operations” [rfc2026].  This document meets that bar of the description, but there is clearly not a lot of practice behind the considerations – which I think is reflected in the lack of significant comments from the WG.  I would prefer if this document as Informational, pending some actual experience.  But I’ll settle for a good explanation (to be also included in the Shepherd’s write-up) of why BCP.

2. This document, as a companion of draft-ietf-sidr-bgpsec-protocol, is the only place where Operational (or Management) Considerations are discussed.  However, important items recommended in RFC5706 (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions), such as migration or fault management are not covered anywhere.  Given the tone and current content of this document, I don’t think extending it is the way forward -- so, in my review of draft-ietf-sidr-bgpsec-protocol [1], I asked the authors to include an Operations and Management Section there and to consider using this document as the base.  Merging this document into draft-ietf-sidr-bgpsec-protocol is an action that the WG/authors/Chairs/Shepherds should consider.  While that is my preferred solution, I will move forward with publication of this document if that is the consensus.

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/sidr/UOSfI4drrFvnO7271ivU3j9RFm4

Major:
M1. In Section 5, you wrote: “As they are not formally verifiable, an eBGP listener SHOULD NOT strongly trust unsigned security markings such as communities received across a trust boundary.”  After reading this piece of text several times, I think I picked up on the subtle message: don’t trust unsigned *security markings* -- vs what I got from the first n-1 readings: don’t trust communities.  I think that this paragraph would greatly benefit from more details or an example related to security markings.

M2. In Section 7. (Routing Policy): “As BGPsec will be rolled out over…a long time.  Hence a normal operator's policy SHOULD NOT be overly strict, perhaps preferring Valid paths and giving very low preference, but still using, Not Valid paths.”  This recommendation concerns me because “Not Valid” talks directly to the fact that the announcement is, well, not valid – vs just unable to be verified (because there’s no BGPsec_Path  attribute, for example).  The next sentence is a reflection of my concern: “Operators should be aware that accepting Not Valid announcements…will often be the equivalent of treating them as fully Valid.”  I-D.sidr-bgpsec-protocol suggests the same thing (in 5.1, pointing to this document).  I am left with the question: why validate at all if the BCP recommendation is to use all announcements no matter the state?  I obviously realize that it is still early days – maybe it is too early for a BCP document if the “practice” is not there yet…

M3. Also in Section 7: “…signed paths that are Not Valid and yet propagated…SHOULD have their signatures kept intact…”  Section 4.2. (Constructing the BGPsec_Path Attribute) of draft-ietf-sidr-bgpsec-protocol says: “a Signature_Block which is not deemed 'Valid'…such Signature_Blocks MUST NOT be removed.”  The “SHOULD” in this document is at odds with the “MUST NOT” in the BGPSec spec; please s/SHOULD/MUST, or (even better) s/SHOULD/should.

M4. Still in Section 7: “To prevent exposure of the internals of BGP Confederations [RFC5065], a BGPsec speaker which is a Member-AS of a Confederation MUST NOT sign updates sent to another Member-AS of the same Confederation.”  This is another case where the BGPSec spec says something different: Section 4.3. (Processing Instructions for Confederation Members) presents a mandatory mechanism that includes signing, but not necessarily validating.  BTW, if the updates are not signed, then the signed path would be broken, even if all the routers in the path support BGPSec, right?  Is that the recommendation?

M5. In Section 8: “…routers' clocks MUST be correct…”  What does this mean?  Correct with respect to what?  Later (2 paragraphs) you do mention RFC5905, should that be the reference here?  Maybe make the clock topic one paragraph to avoid confusion.

References:
R1. The reference to BGPsec should be draft-ietf-sidr-bgpsec-protocol (and not I-D.ietf-sidr-bgpsec-overview).  I think it is ok to reference I-D.ietf-sidr-bgpsec-overview in the Suggested Reading as an Informative reference.  Similarly, rfc6480, rfc6481 and rfc6482 should be made Informative as well.

R2. Section 7: “This implies that the route server creates signatures per client including its own AS in the BGPsec_Path and the target ASes, see 2.2.2 of [I-D.ietf-idr-ix-bgp-route-server].”  I think this reference is not correct because I-D.ietf-idr-ix-bgp-route-server doesn’t say anything about BGPSec.  That section does say the opposite: “the route server SHOULD NOT prepend its own AS number to the AS_PATH segment nor modify the AS_PATH segment in any other way”.  Maybe point at 4.2 of draft-ietf-sidr-bgpsec-protocol instead.

R3. RFC6811 should be a Normative reference.

Minor:
m1. The IPv4 examples in Section 7 should use addressed from rfc6890.

m2. In Section 7: “Therefore, unless local policy ensures otherwise, a signed path learned via iBGP MAY be Not Valid.”  That “MAY” is not normative in this context, but it is stating a fact: s/MAY/may.

m3. Also in Section 7: “If it is known that a BGPsec neighbor is not a transparent route server, and the router provides a knob to disallow a received pCount (prepend count, zero for transparent route servers) of zero, that knob SHOULD be applied.”  There are other cases when pCount 0 is ok, draft-ietf-sidr-as-migration for example.  I know that “SHOULD” allows other cases, but maybe working in the router server as an example might be an improvement.

m4. Section 9. (Security Considerations): “The major security considerations for the BGPsec protocol are described in [I-D.ietf-sidr-bgpsec-protocol].”  Are there other security considerations not mentioned there?

Nits:
n1. Introduction: “…origin validation…will occur over the next two to three years and that BGPsec will start to deploy well after that.”  Recommendation: avoid specific timeframes, be a little vaguer (short/medium/long term).  I noticed that the first version of draft-ymbk-bgpsec-ops also mentioned “two to five years” (in 2011!).

n2. s/ client cone, i.e. an RR client or the transitive closure of their customers' customers' customers' etc./ client cone, i.e. an RR client or reachable transitively through one of them.

n3. “As the vast majority (84%) of ASs are stubs, and they announce the majority of prefixes…” A reference would be nice.

n4. “Because of possible RPKI version skew…”  I guess you mean lack of sync…

n5. Security Considerations.  Please write something along the lines of: “This document describes operational considerations for the deployment of BGPsec.  The security considerations for BGPsec are…”

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Nov 2016 14:28:42 +0900

alvaro,

thanks for the best review this has had in a while.  i am not ignoring
you; and may even get a version out for next week.  but no promises, as
i suspect you folk will think that having a solid ietf network next week
is more important :)

randy

---

From: Chris Morrow <[email-masked]>
Date: Sun, 13 Nov 2016 21:33:30 -0800

i think the plan is to shift the -ops document (this one) to the
sidrops group...I meant to ask about: "how do we do that?" I'll do
that in person tonight.

At Wed, 2 Nov 2016 15:35:18 +0000,
"Alvaro Retana (aretana)" <[email-masked]> wrote:
> I have two issues I want to highlight upfront, and then some comments
> (below).  I would like to see these two issues addressed, along with
> the Major comments below, before moving the document forward.
> 
> 1. Why is this document a BCP?  A BCP is a document that describes
>    “the community's best current thinking…on what is believed to be
>    the best way to perform some operations” [rfc2026].  This document
>    meets that bar of the description, but there is clearly not a lot
>    of practice behind the considerations – which I think is reflected
>    in the lack of significant comments from the WG.  I would prefer if
>    this document as Informational, pending some actual experience.
>    But I’ll settle for a good explanation (to be also included in the
>    Shepherd’s write-up) of why BCP.

i think the intent of this document is to write down (document) the
inteded 'best practices' for running bgpsec enabled networks.

viewed in that light, there aren't any of these things out there
today, but as a place to start looking and planning for deployment
operations folk (me) want some guidance on what thingsto expect/do/fix
as we roll out.

i think bcp fits for that... much like bcp 17. I have updated the
shepherds doc to reflect the above paragraph's intent/ideas.

> 2. This document, as a companion of draft-ietf-sidr-bgpsec-protocol,
>    is the only place where Operational (or Management) Considerations
>    are discussed.  However, important items recommended in RFC5706
>    (Guidelines for Considering Operations and Management of New
>    Protocols and Protocol Extensions), such as migration or fault
>    management are not covered anywhere.  Given the tone and current

Ideally the migration is covered in the protocol document, I see it
only talk about as migrations (business events), which seems
ok.

Migrations of keys or algorithms are covered in other documents and
mentioned in this document. which migrations are you referring to?

>    content of this document, I don’t think extending it is the way
>    forward -- so, in my review of draft-ietf-sidr-bgpsec-protocol [1],
>    I asked the authors to include an Operations and Management Section
>    there and to consider using this document as the base.  Merging

I'm not sure I'd stick more into the protocol document though,
especially things which don't explicitly describe the protocol
itself. I think keeping the protocol description/design in one
document and the operations of the system in a seperate document isn't
unreasonable.

I expect the set of ops documents to change/evolve over time, I'd hate
to -bis the protocol for operational work later.

>    this document into draft-ietf-sidr-bgpsec-protocol is an action
>    that the WG/authors/Chairs/Shepherds should consider.  While that
>    is my preferred solution, I will move forward with publication of
>    this document if that is the consensus.
> 
> Thanks!
> 
> Alvaro.
> 
> [1]
> https://mailarchive.ietf.org/arch/msg/sidr/UOSfI4drrFvnO7271ivU3j9RFm4
> 
> 
> Major: