BGP Prefix Origin Validation
draft-ietf-sidr-pfx-validate-10

[Ballot comment]
Just echoing Barry's point:
    Just some little non-blocking stuff that needs no response:

  Really a nit: you're taking what we usually call a "man-in-the-middle attack"
  and calling it a "monkey-in-the-middle" attack.  While that might seem cute, I
  find it distracting -- mostly because one wonders whether there's a technical
  reason for choosing an unusual term.

I had to search for the differences between man-in-the-middle and monkey-in-the-middle attacks.
Note that rfc4593 speaks about "man-in-the-middle"

Regards, Benoit.

[Ballot comment]
Just some little non-blocking stuff that needs no response:

Really a nit: you're taking what we usually call a "man-in-the-middle attack" and calling it a "monkey-in-the-middle" attack.  While that might seem cute, I find it distracting -- mostly because one wonders whether there's a technical reason for choosing an unusual term.

---

A few comments on the shepherd writeup -- no action for the authors, and the only action for the shepherd is to please consider this sort of stuff next time; thanks:

1. I agree with Adrian's comments.  Some discussion in the writeup of why the WG decided to put this as Standards Track would have been helpful, and question 1 does ask that (albeit not as clearly as it might).

2. In the Working Group Summary in response to question 2, the writeup says that "there was a fairly lengthy discussion in several in-person meetings as well as on-list," but gives no clue as to what issues the discussion was about.  Again, a few brief words on some key issues would have been helpful, especially for items that were primarily discussed off list.

3. The response to question 8 says, "Yes, there is an IPR disclosure. The WG has seen this and comments were made at an in-person meeting. There wasn't a blocking comment, however."  The question asks to "summarize any WG discussion and conclusion regarding the IPR disclosures," and this isn't a useful summary of the comments.  Such a summary is made more important by the fact that it was in person, and not on the mailing list, so there is no record we can go back to look at.

4. Adrian is NOT a "galactic policeman".  He is an INTERgalactic policeman.  You're selling him short.

[Ballot comment]
I support the publication of this document.

It seemed strange to me that this was positioned on the standards track since it describes an internal implementation issue for individual BGP speakers (akin to other policy-based choices about which routes to select and advertise,or reject). This doesn't affect protocol behavior per se.

I turned to the Shepherd write-up for an explanation of the thought behind this decision, but sadly Question 1 of the write-up hasnot been answered in full, so no hints there.

However, since we hope that this function will become widly available in implementations to factilitate deployment and use of the RPKI system by inter-domain routing, I don't think this is a big issue.

IANA has reviewed draft-ietf-sidr-pfx-validate-09, which is currently
in Last Call, and has the following comments:

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

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (BGP Prefix Origin Validation) to Proposed Standard


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'BGP Prefix Origin Validation'
  as Proposed Standard

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 2012-10-01. 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


  To help reduce well-known threats against BGP including prefix mis-
  announcing and monkey-in-the-middle attacks, one of the security
  requirements is the ability to validate the origination AS of BGP
  routes.  More specifically, one needs to validate that the AS number
  claiming to originate an address prefix (as derived from the AS_PATH
  attribute of the BGP route) is in fact authorized by the prefix
  holder to do so.  This document describes a simple validation
  mechanism to partially satisfy this requirement.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sidr-pfx-validate/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sidr-pfx-validate/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1569/

(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?

Proposed Standard


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

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.

"To help reduce well-known threats against BGP including prefix mis-
announcing and monkey-in-the-middle attacks, one of the security
requirements is the ability to validate the origination AS of BGP
routes. More specifically, one needs to validate that the AS number
claiming to originate an address prefix (as derived from the AS_PATH
attribute of the BGP route) is in fact authorized by the prefix
holder to do so. This document describes a simple validation
mechanism to partially satisfy this requirement."

Working Group Summary:

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?

There were several revisions (8) of this document, there was a fairly
lengthy discussion in several in-person meetings as well as on-list. In
the end, all of the issues seem to have been dealt with.


Document Quality:

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?

To date, there are 2 implementations in vendor code, one of which
brought about the single IPR claim against this document.

Personnel:

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

The document shephard is: Chris Morrow (me)
The responsible AD is: Adrian Farrel (Galactic Policeman this week)

(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 (several revisions), and believe it's in shape for
publication (minus the nits which should be handled in iesg commentary
time).


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

I don't have any issues with the review done.

(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 think there are parts of the document which require
broader-perspective-review, aside from the normal iesg reviews.


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


I don't believe there are any specific 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?


The authors brought forth the current IPR claim, that is the only one known.


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


Yes, there is an IPR disclosure. The WG has seen this and comments were
made at an in-person meeting. There wasn't a blocking comment, however.

(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?

WG consensus seems quite solid.

(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 appeals or issues of grandeur were raised.


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

The document authors are aware of the nits, and will fix them in iesg
review time.

(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).

it seems consistent.

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


n/a

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

n/a