Security Requirements for BGP Path Validation
draft-ietf-sidr-bgpsec-reqs-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-08-15
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-08-12
|
12 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-07-31
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH48 |
2014-07-30
|
12 | (System) | RFC Editor state changed to AUTH48 from EDIT |
2014-07-16
|
12 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2014-07-15
|
12 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-07-15
|
12 | (System) | RFC Editor state changed to EDIT |
2014-07-15
|
12 | (System) | Announcement was received by RFC Editor |
2014-07-15
|
12 | (System) | IANA Action state changed to No IC from In Progress |
2014-07-15
|
12 | (System) | IANA Action state changed to In Progress |
2014-07-15
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup |
2014-07-15
|
12 | Amy Vezza | IESG has approved the document |
2014-07-15
|
12 | Amy Vezza | Closed "Approve" ballot |
2014-07-15
|
12 | Amy Vezza | Ballot approval text was generated |
2014-07-15
|
12 | Amy Vezza | Ballot writeup was changed |
2014-07-14
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-07-14
|
12 | Cindy Morgan | New revision available |
2014-07-10
|
11 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2014-07-10
|
11 | Stephen Farrell | [Ballot comment] I'm not sure if this would be a good or bad idea but I'll ask anyway since I'm happy to embarrass myself if … [Ballot comment] I'm not sure if this would be a good or bad idea but I'll ask anyway since I'm happy to embarrass myself if it might help:-) Feel free to chat about or entirely ignore this. From time to time I get asked if there's any work to be done with BGP (or interdomain routing) that might help to make pervasive monitoring harder. I always answer "dunno, what do you think?" since I do not know. Would it be worth adding a requirement here that designs should consider whether and if so the extent to which confidentiality being a part of BGPsec might be beneficial? I guess there's no formal need to add this since we do have a BCP on the topic (BCP188) but it might be something that designers would not otherwise consider, so a mention could be useful. |
2014-07-10
|
11 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2014-07-10
|
11 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-07-10
|
11 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-07-09
|
11 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-07-09
|
11 | Kathleen Moriarty | [Ballot comment] There is an interesting discussion going on in reference to Russ' draft on algorithm agility on the SAAG list, where folks are advocating … [Ballot comment] There is an interesting discussion going on in reference to Russ' draft on algorithm agility on the SAAG list, where folks are advocating for the pros and CONS to be included. Would an informational reference be possible in requirement 3.21? I don't know the timeline for this draft: https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/ The SecDir reviewer had a few questions resulting from not being familiar with some of the terms used. I am in an environment where data and control plane discussions come up, so the text is fine for me, but I do see his point and think it would be wrath adding a little more detail to the following sentence in the Security Considerations section. I think you are talking about the path of each. Maybe change from: The data plane might not follow the control plane. To: The data plane might not follow the path of the control plane. SecDir review: http://www.ietf.org/mail-archive/web/secdir/current/msg04876.html |
2014-07-09
|
11 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2014-07-09
|
11 | Francis Dupont | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Francis Dupont. |
2014-07-09
|
11 | Richard Barnes | [Ballot comment] I'm not sure what you mean by saying that origin validation doesn't provide "cryptographic assurance". Do you mean to say something like "authentication … [Ballot comment] I'm not sure what you mean by saying that origin validation doesn't provide "cryptographic assurance". Do you mean to say something like "authentication of the originator of the route"? If I'm understanding correctly, the issue you're trying to point out here is that a ROA lets a prefix holder say "AS $foo may originate prefix $bar", but it doesn't prove that "This announcement for prefix $bar was originated by AS $foo" Nit: "The authors wishe" |
2014-07-09
|
11 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2014-07-08
|
11 | Alissa Cooper | [Ballot comment] Would like to see the 2119 usage sorted out per the others' comments but otherwise looks good to me. |
2014-07-08
|
11 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2014-07-08
|
11 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-07-07
|
11 | Benoît Claise | [Ballot comment] On top of what Adrian wrote, there is always the question of what a SHOULD mean in a requirements document. Here are some … [Ballot comment] On top of what Adrian wrote, there is always the question of what a SHOULD mean in a requirements document. Here are some examples of recent requirements documents. 1. http://www.rfc-editor.org/rfc/rfc7262.txt RFC 2119 keywords, but only MUST. No SHOULD or MAY 2. http://www.rfc-editor.org/rfc/rfc7226.txt RFC 2119 keywords with MUST/SHOULD/MAY With an explanation of the meaning: Any statement that requires the solution to support some new functionality through use of [RFC2119] keywords should be interpreted as follows. The implementation either MUST or SHOULD support the new functionality, depending on the use of either MUST or SHOULD in the requirements statement. The implementation SHOULD, in most or all cases, allow any new functionality to be individually enabled or disabled through configuration. A service provider or other deployment MAY enable or disable any feature in their network, subject to implementation limitations on sets of features that can be disabled. 3. http://tools.ietf.org/html/draft-ietf-cdni-requirements-17 (RFC EDITOR QUEUE) o "High Priority": When a requirement is tagged as "{HIGH}", it is considered by the working group as an essential function for CDNI and necessary to a deployable solution. This requirement has to be met even if it causes a delay in the delivery by the working group of a deployable solution. o "Medium Priority": When a requirement is tagged as "{MED}", it is considered by the working group as an important function for CDNI. This requirement has to be met, unless it is established that attempting to meet this requirement would cause a delay in the delivery by the working group of a deployable solution. o "Low Priority": When a requirement is tagged as "{LOW}", it is considered by the working group as a useful function for CDNI. The working group will attempt to meet this requirement as long as it does not prevent meeting the "High Priority" and "Medium Priority" requirements and does not cause a delay in the delivery by the working group of a deployable solution. 4. https://datatracker.ietf.org/doc/rfc6988/ No RFC 2119 keywords. I'm not religious at all on which way you chose, but 1. be consistent (right now, it's not the case) 2. explain how the protocol spec. authors must interpret SHOULD/MAY/OPTIONAL (or should/may/optional) requirements. From the early discussion between Adrian/Randy, I understand there is a willingness to fix this. Therefore that's a COMMENT (I have nothing against the technical content). If you produce a new version ... == Outdated reference: draft-ietf-sidr-bgpsec-threats has been published as RFC 7132 == Outdated reference: A later version (-03) exists of draft-ga-idr-as-migration-01 == Outdated reference: A later version (-01) exists of draft-ietf-sidr-lta-use-cases-00 |
2014-07-07
|
11 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-07-06
|
11 | Barry Leiba | [Ballot comment] What Adrian said... |
2014-07-06
|
11 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-07-04
|
11 | Adrian Farrel | [Ballot comment] The mixed use of 2119 language could do with being tidied up to remove any implication that there is meaning in the inconsistency. … [Ballot comment] The mixed use of 2119 language could do with being tidied up to remove any implication that there is meaning in the inconsistency. Actually, when I read 3.1-3.3 I was rather pleased at the use of lower case words (as a speaker of English :-) and then got grumpy in 3.4. I won't make a big thing of whether you choose to go upper case or lower case, but your mixed usage is a little bit awkward. Probably, given the wide scale usage in the rest of the document, you probably just want to fix up 3.1-3.3 and quickly check the rest of the document. 3.11 has "it need NOT handle" which needs "not". |
2014-07-04
|
11 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2014-07-03
|
11 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Adam Montville. |
2014-07-03
|
11 | Alia Atlas | IESG state changed to IESG Evaluation from Waiting for Writeup |
2014-07-03
|
11 | Alia Atlas | Ballot has been issued |
2014-07-03
|
11 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2014-07-03
|
11 | Alia Atlas | Created "Approve" ballot |
2014-07-03
|
11 | Alia Atlas | Ballot writeup was changed |
2014-07-03
|
11 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2014-06-26
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Adam Montville |
2014-06-26
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Adam Montville |
2014-06-26
|
11 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2014-06-26
|
11 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-sidr-bgpsec-reqs-11, which is currently in Last Call, and has the following comments: We understand that, upon approval of this … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-sidr-bgpsec-reqs-11, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2014-06-24
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jason Weil |
2014-06-24
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jason Weil |
2014-06-19
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2014-06-19
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2014-06-19
|
11 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-06-19
|
11 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Security Requirements for BGP Path … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Security Requirements for BGP Path Validation) to Informational RFC The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Security Requirements for BGP Path Validation' as Informational RFC 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 2014-07-03. 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 This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-reqs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-reqs/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-06-19
|
11 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-06-19
|
11 | Alia Atlas | Placed on agenda for telechat - 2014-07-10 |
2014-06-19
|
11 | Alia Atlas | Last call was requested |
2014-06-19
|
11 | Alia Atlas | Last call announcement was generated |
2014-06-19
|
11 | Alia Atlas | Ballot approval text was generated |
2014-06-19
|
11 | Alia Atlas | Ballot writeup was generated |
2014-06-19
|
11 | Alia Atlas | IESG state changed to Last Call Requested from Publication Requested |
2014-06-13
|
11 | 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? Informational (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 This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. Working Group Summary The document spent quite some time in WG discussion, one particular sticky point was around the lack of notice that 'route leaks are not fixed by this protocol change'. There is a standing discussion about this in this WG, and the agreed upon process is being followed (get the GROW folk to decide if 'route leaks' are a problem, then get IDR to code some bgp changes that might do the detection/notification/etc, and have SIDR properly secure whatever that result was. Other than that, this was a good effort. Document Quality There are two vendors planning on supporting this protocol once it's finished, both are active in the working group (and have been for a while). Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Chris Morrow (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. The shephard read/commented/reviewed this document through it's lifecycle. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? no concerns at this time. (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. I don't believe the document has expert requirements. (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. none (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. no ipr concerns. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. N/A (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? Fairly solid consensus for this document coming out of WGLC. (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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are 3 warnings, all of which will be addressed before final publication. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? No. (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. No. (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 for this document. (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. No such review was required. |
2014-06-13
|
11 | Chris Morrow | State Change Notice email list changed to sidr-chairs@tools.ietf.org, draft-ietf-sidr-bgpsec-reqs@tools.ietf.org |
2014-06-13
|
11 | Chris Morrow | Responsible AD changed to Alia Atlas |
2014-06-13
|
11 | Chris Morrow | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2014-06-13
|
11 | Chris Morrow | IESG state changed to Publication Requested |
2014-06-13
|
11 | Chris Morrow | IESG process started in state Publication Requested |
2014-05-22
|
11 | Randy Bush | New version available: draft-ietf-sidr-bgpsec-reqs-11.txt |
2014-05-22
|
10 | Chris Morrow | Tag Doc Shepherd Follow-up Underway set. Tag Waiting for Referenced Document cleared. |
2014-05-22
|
10 | Chris Morrow | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2014-05-22
|
10 | Chris Morrow | Document shepherd changed to Chris Morrow |
2014-05-22
|
10 | Chris Morrow | Intended Status changed to Informational from None |
2014-04-15
|
10 | Randy Bush | New version available: draft-ietf-sidr-bgpsec-reqs-10.txt |
2014-01-03
|
09 | Randy Bush | New version available: draft-ietf-sidr-bgpsec-reqs-09.txt |
2013-10-08
|
08 | Randy Bush | New version available: draft-ietf-sidr-bgpsec-reqs-08.txt |
2013-04-12
|
07 | Randy Bush | New version available: draft-ietf-sidr-bgpsec-reqs-07.txt |
2013-02-20
|
06 | Randy Bush | New version available: draft-ietf-sidr-bgpsec-reqs-06.txt |
2012-10-22
|
05 | Randy Bush | New version available: draft-ietf-sidr-bgpsec-reqs-05.txt |
2012-07-30
|
04 | Alexey Melnikov | Annotation tag Waiting for Referenced Document set. Annotation tag Revised I-D Needed - Issue raised by WGLC cleared. |
2012-06-29
|
04 | Alexey Melnikov | Editors requested WGLC. Waiting for draft-ietf-sidr-bgpsec-threats-02.txt to be finished before proceeding with this document. |
2012-06-29
|
04 | Randy Bush | New version available: draft-ietf-sidr-bgpsec-reqs-04.txt |
2012-03-28
|
03 | Chris Morrow | Annotation tag Revised I-D Needed - Issue raised by WGLC set. |
2012-03-10
|
03 | Chris Morrow | Further comments during WGLC still being addressed/discussed. |
2012-03-10
|
03 | Randy Bush | New version available: draft-ietf-sidr-bgpsec-reqs-03.txt |
2012-03-09
|
02 | Randy Bush | New version available: draft-ietf-sidr-bgpsec-reqs-02.txt |
2011-10-19
|
01 | (System) | New version available: draft-ietf-sidr-bgpsec-reqs-01.txt |
2011-06-25
|
00 | (System) | New version available: draft-ietf-sidr-bgpsec-reqs-00.txt |