Security Requirements for BGP Path Validation
draft-ietf-sidr-bgpsec-reqs-12

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

[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

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

[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

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

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.

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.

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.