Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2017-07-26
16 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-06-14
16 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-06-07
16 (System) RFC Editor state changed to RFC-EDITOR from REF
2017-05-30
16 (System) RFC Editor state changed to REF from EDIT
2017-04-27
16 (System) RFC Editor state changed to EDIT from MISSREF
2017-01-18
16 (System) RFC Editor state changed to MISSREF from EDIT
2017-01-18
16 (System) RFC Editor state changed to EDIT from MISSREF
2017-01-10
16 Jonathan Hardwick Closed request for Last Call review by RTGDIR with state 'No Response'
2017-01-09
16 (System) RFC Editor state changed to MISSREF
2017-01-09
16 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-01-09
16 (System) Announcement was received by RFC Editor
2017-01-09
16 (System) IANA Action state changed to No IC
2017-01-09
16 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-01-09
16 Amy Vezza IESG has approved the document
2017-01-09
16 Amy Vezza Closed "Approve" ballot
2017-01-09
16 Amy Vezza Ballot approval text was generated
2017-01-05
16 Cindy Morgan IESG state changed to Approved-announcement to be sent from IESG Evaluation
2017-01-05
16 Benoît Claise
[Ballot comment]
Happy to see an operational considerations document at the same time at the protocol specifications, even if we know that "It is expected …
[Ballot comment]
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.
2017-01-05
16 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2017-01-05
16 Alvaro Retana Ballot writeup was changed
2017-01-05
16 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-16.txt
2017-01-05
16 (System) New version approved
2017-01-05
16 (System) Request for posting confirmation emailed to previous authors: "Randy Bush"
2017-01-05
16 Randy Bush Uploaded new revision
2017-01-05
15 Alvaro Retana Ballot approval text was generated
2017-01-05
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-01-05
15 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-15.txt
2017-01-05
15 (System) New version approved
2017-01-05
15 (System) Request for posting confirmation emailed to previous authors: "Randy Bush"
2017-01-05
15 Randy Bush Uploaded new revision
2017-01-05
14 Jari Arkko [Ballot comment]
Roni Even's Gen-ART review comments are worth checking -- did not see a response yet.
2017-01-05
14 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2017-01-05
14 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Rich Salz.
2017-01-04
14 Terry Manderson
[Ballot comment]
Thanks for creating a document to begin to pen the upcoming gotchas of BGPsec.

I have a couple small comments.

Section 3. "All …
[Ballot comment]
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.
2017-01-04
14 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2017-01-04
14 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2017-01-04
14 Kathleen Moriarty [Ballot comment]
I support Stephen's comments.
2017-01-04
14 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2017-01-04
14 Spencer Dawkins
[Ballot comment]
Again, thanks for a very readable document.

I did have one question - I saw that you're chatting about the same paragraph with …
[Ballot comment]
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)
2017-01-04
14 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-01-04
14 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-14.txt
2017-01-04
14 (System) New version approved
2017-01-04
14 (System) Request for posting confirmation emailed to previous authors: "Randy Bush"
2017-01-04
14 Randy Bush Uploaded new revision
2017-01-04
13 Alissa Cooper
[Ballot comment]
= Section 5 =

"Route Reflectors MUST have BGPsec
  enabled if and only if there are eBGP speakers in their client cone, …
[Ballot comment]
= 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.
2017-01-04
13 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2017-01-04
13 Stephen Farrell
[Ballot comment]


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

- general: given where we are with deployment I …
[Ballot 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:-)
2017-01-04
13 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2017-01-04
13 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2017-01-03
13 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-01-03
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-01-03
13 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-13.txt
2017-01-03
13 (System) New version approved
2017-01-03
13 (System) Request for posting confirmation emailed to previous authors: "Randy Bush"
2017-01-03
13 Randy Bush Uploaded new revision
2017-01-03
12 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2017-01-03
12 Ben Campbell
[Ballot comment]
Update:  I noted when reviewing other sidr drafts on this telechat agenda that this draft treats 2119 keywords differently than the other drafts. …
[Ballot comment]
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.



-
2017-01-03
12 Ben Campbell Ballot comment text updated for Ben Campbell
2017-01-03
12 Ben Campbell
[Ballot comment]
Just a few minor and editorial comments:

-1, first paragraph: "It is thought...": Can you mention "who" thinks it? Otherwise that reads as …
[Ballot comment]
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.



-
2017-01-03
12 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2017-01-03
12 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-01-02
12 Mirja Kühlewind
[Ballot comment]
Quick question: I'm by far not an expert here, but I remember that there used to be some concerns that it is practical …
[Ballot comment]
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?
2017-01-02
12 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2016-12-25
12 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-12-24
12 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Sheng Jiang.
2016-12-21
12 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for Writeup
2016-12-21
12 Alvaro Retana Ballot has been issued
2016-12-21
12 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2016-12-21
12 Alvaro Retana Created "Approve" ballot
2016-12-21
12 Alvaro Retana Ballot writeup was changed
2016-12-21
12 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-12-16
12 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2016-12-16
12 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-sidr-bgpsec-ops-12.txt, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-sidr-bgpsec-ops-12.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2016-12-15
12 Roni Even Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Roni Even. Sent review to list.
2016-12-12
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sheng Jiang
2016-12-12
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sheng Jiang
2016-12-09
12 Jonathan Hardwick Request for Last Call review by RTGDIR is assigned to Michael Richardson
2016-12-09
12 Jonathan Hardwick Request for Last Call review by RTGDIR is assigned to Michael Richardson
2016-12-08
12 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2016-12-08
12 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2016-12-08
12 Alvaro Retana Requested Last Call review by RTGDIR
2016-12-08
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rich Salz
2016-12-08
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rich Salz
2016-12-07
12 Amy Vezza IANA Review state changed to IANA - Review Needed
2016-12-07
12 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-sidr-bgpsec-ops@ietf.org, morrowc@ops-netman.net, sidr-chairs@ietf.org, "Chris Morrow" , sidr@ietf.org, …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-sidr-bgpsec-ops@ietf.org, morrowc@ops-netman.net, sidr-chairs@ietf.org, "Chris Morrow" , sidr@ietf.org, aretana@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BGPsec Operational Considerations) to Best Current Practice


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'BGPsec Operational Considerations'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-12-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Deployment of the BGPsec architecture and protocols has many
  operational considerations.  This document attempts to collect and
  present the most critical and universal.  It is expected to evolve as
  BGPsec is formalized and initially deployed.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6811: BGP Prefix Origin Validation (Proposed Standard - IETF stream)
    draft-ietf-sidr-bgpsec-protocol: BGPsec Protocol Specification (None - IETF stream)
    rfc6493: The Resource Public Key Infrastructure (RPKI) Ghostbusters Record (Proposed Standard - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.


2016-12-07
12 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2016-12-07
12 Alvaro Retana Placed on agenda for telechat - 2017-01-05
2016-12-07
12 Alvaro Retana Last call was requested
2016-12-07
12 Alvaro Retana Last call was requested
2016-12-07
12 Alvaro Retana Ballot approval text was generated
2016-12-07
12 Alvaro Retana Ballot writeup was generated
2016-12-07
12 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2016-12-07
12 Alvaro Retana Last call announcement was generated
2016-12-06
12 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-12.txt
2016-12-06
12 (System) New version approved
2016-12-06
12 (System) Request for posting confirmation emailed to previous authors: "Randy Bush"
2016-12-06
12 Randy Bush Uploaded new revision
2016-12-02
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2016-12-02
11 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-11.txt
2016-12-02
11 (System) New version approved
2016-12-02
11 (System) Request for posting confirmation emailed to previous authors: "Randy Bush"
2016-12-02
11 Randy Bush Uploaded new revision
2016-12-02
11 (System) Request for posting confirmation emailed to previous authors: "Randy Bush"
2016-12-02
11 Randy Bush Uploaded new revision
2016-11-13
10 Chris Morrow
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

BCP

Since this document documents the intended actions, systems, etc for deployment
of a bgpsec enabled network, I believe 'BCP' is appropriate as an intended status.
There are no 'BGPSEC Enabled' networks today, but in planning to deploy operations
staff will need plans and maps to use in finding their way through the forest. This
should serve as that map.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
"Deployment of the BGPsec architecture and protocols has many
  operational considerations.  This document attempts to collect and
  present the most critical and universal.  It is expected to evolve as
  BGPsec is formalized and initially deployed."


  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

Working Group Summary

This draft went thorugh several revisions (10), with good discussion from stake-holders in the communit(ies) affected.

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

nothing of note.

Document Quality

The document is in good shape, there are some ID-NITS to deal with prior to final publication, notably:
  2 references to be fixed up (downref 2 normative references, easily adjusted)
  Boilerplate issues (2119 issues), also easily adjusted.

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

This is not a protocol, so no implementations.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: Chris Morrow (morrowc@ops-netman.net)
AD: Alvaro Retana (aretana@cisco.com)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I read the document (a few times over it's lifecycle) and believe it is in good shape for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

no

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

no

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

no concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

no IPR concerns

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Consensus is as solid as ever in SIDR... there was good review over the lifetime of the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

** Downref: Normative reference to an Informational draft:
    draft-ietf-sidr-bgpsec-overview (ref. 'I-D.ietf-sidr-bgpsec-overview')
** Downref: Normative reference to an Informational RFC: RFC 6480

RFC2119 boilerplate issues

and private-ip usage which should be changed to test/documentation networks.

all fixable before final publication, none super relevant to the content.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

no formal review required.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There are references to drafts, yes, which will have to be sorted out before publication is finalized.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

yes, two. which will be fixed.
** Downref: Normative reference to an Informational draft:
    draft-ietf-sidr-bgpsec-overview (ref. 'I-D.ietf-sidr-bgpsec-overview')
  ** Downref: Normative reference to an Informational RFC: RFC 6480

6480 will likely eventually point to the -bis I expect, and the overview will shift ot the final rfc when that is published.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

no


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

NONE

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

id-nits run, no other structured data to review.
2016-11-02
10 Alvaro Retana
== AD Review of draft-ietf-sidr-bgpsec-ops-10 ==

I have two issues I want to highlight upfront, and then some comments (below).  I would like to see …
== AD Review of draft-ietf-sidr-bgpsec-ops-10 ==

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…”
2016-11-02
10 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2016-10-28
10 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2016-06-24
10 Alvaro Retana Notification list changed to "Chris Morrow" <morrowc@ops-netman.net>, aretana@cisco.com from "Chris Morrow" <morrowc@ops-netman.net>
2016-06-24
10 Chris Morrow
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

BCP


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
"Deployment of the BGPsec architecture and protocols has many
  operational considerations.  This document attempts to collect and
  present the most critical and universal.  It is expected to evolve as
  BGPsec is formalized and initially deployed."


  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

Working Group Summary

This draft went thorugh several revisions (10), with good discussion from stake-holders in the communit(ies) affected.

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

nothing of note.

Document Quality

The document is in good shape, there are some ID-NITS to deal with prior to final publication, notably:
  2 references to be fixed up (downref 2 normative references, easily adjusted)
  Boilerplate issues (2119 issues), also easily adjusted.

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

This is not a protocol, so no implementations.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: Chris Morrow (morrowc@ops-netman.net)
AD: Alvaro Retana (aretana@cisco.com)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I read the document (a few times over it's lifecycle) and believe it is in good shape for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

no

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

no

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

no concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

no IPR concerns

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Consensus is as solid as ever in SIDR... there was good review over the lifetime of the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

** Downref: Normative reference to an Informational draft:
    draft-ietf-sidr-bgpsec-overview (ref. 'I-D.ietf-sidr-bgpsec-overview')
** Downref: Normative reference to an Informational RFC: RFC 6480

RFC2119 boilerplate issues

and private-ip usage which should be changed to test/documentation networks.

all fixable before final publication, none super relevant to the content.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

no formal review required.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There are references to drafts, yes, which will have to be sorted out before publication is finalized.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

yes, two. which will be fixed.
** Downref: Normative reference to an Informational draft:
    draft-ietf-sidr-bgpsec-overview (ref. 'I-D.ietf-sidr-bgpsec-overview')
  ** Downref: Normative reference to an Informational RFC: RFC 6480

6480 will likely eventually point to the -bis I expect, and the overview will shift ot the final rfc when that is published.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

no


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

NONE

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

id-nits run, no other structured data to review.
2016-06-24
10 Chris Morrow Responsible AD changed to Alvaro Retana
2016-06-24
10 Chris Morrow IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2016-06-24
10 Chris Morrow IESG state changed to Publication Requested
2016-06-24
10 Chris Morrow IESG process started in state Publication Requested
2016-06-24
10 Chris Morrow Changed consensus to Yes from Unknown
2016-06-24
10 Chris Morrow Intended Status changed to Best Current Practice from None
2016-06-24
10 Chris Morrow Changed document writeup
2016-06-24
10 Chris Morrow Notification list changed to "Chris Morrow" <morrowc@ops-netman.net>
2016-06-24
10 Chris Morrow Document shepherd changed to Chris Morrow
2016-06-24
10 Chris Morrow IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2016-06-23
10 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-10.txt
2016-06-15
09 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-09.txt
2016-06-06
08 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-08.txt
2015-12-15
07 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-07.txt
2015-07-02
06 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-06.txt
2012-05-23
05 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-05.txt
2012-03-12
04 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-04.txt
2012-03-09
03 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-03.txt
2012-03-07
02 Randy Bush New version available: draft-ietf-sidr-bgpsec-ops-02.txt
2011-10-19
01 (System) New version available: draft-ietf-sidr-bgpsec-ops-01.txt
2011-06-28
00 (System) New version available: draft-ietf-sidr-bgpsec-ops-00.txt