Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures
draft-ietf-sidr-rpsl-sig-12

[Ballot comment]

Thanks all for chatting about my discuss, I think the
outcome is good.

--- OLD COMMENTS below, I didn't check 'em, feel
free to chat more or not, as you think best.

- If you keep the potential for http(s) URIs then I think
more text is needed in the security considerations but
it looks like you're taking that out for now so I guess
that's ok.

- 2.1, I don't see why it's useful to allow variation in the
fields of the signature attribute e.g. why "MAY" the version
not be 1st?

- 2.1, "t=" and "x=" any limits on precision here?
(Non-)support for fractional seconds can be a source for
non-interop if not. The "All times MUST be converted to" is
also actually a little ambiguous as you don't say to do that
before signing;-)

- 2.1, "a=" did you want a lowercase "must" there?

- Are steps 2 and 3 in 3.1 order-sensitive? I think you
might sometimes need to do 2 after 3, or re-do 2 maybe or
else leading whitspace could be an issue. Maybe say that
sometimes you need to do step 2 >1 time? 

- 3.1, oops, an ambiguity - in "The following steps MUST be
applied in order..." does "in order" mean "in the order
below" or "so as to"? I assume the latter.

- 3.1: In general I think you'd be better if you pointed at
specific bits of text in all the RFCs mentioned in 3.1 -
it's maybe easy to get wrong otherwise, esp. if we don't yet
have >1 implementation.

- 3.1, step 6: names are all ASCII right? just checking

- 3.2, step 1 - given 3.3 step 2, you're missing a step to
"publish the cert" at the c= location as well.

[Ballot discuss]

I'd like to check one thing - this may be needed for strict
compliance with RPKI thing but it seems kinda weird to also
impose that here, but anyway...

Is 3.2 step 1 needed?  That seems like useless complexity
here.  If it is needed, how does the verifier check that
it's really a single-use? I don't see the point TBH.

[Ballot comment]

- If you keep the potential for http(s) URIs then I think
more text is needed in the security considerations but
it looks like you're taking that out for now so I guess
that's ok.

- 2.1, I don't see why it's useful to allow variation in the
fields of the signature attribute e.g. why "MAY" the version
not be 1st?

- 2.1, "t=" and "x=" any limits on precision here?
(Non-)support for fractional seconds can be a source for
non-interop if not. The "All times MUST be converted to" is
also actually a little ambiguous as you don't say to do that
before signing;-)

- 2.1, "a=" did you want a lowercase "must" there?

- Are steps 2 and 3 in 3.1 order-sensitive? I think you
might sometimes need to do 2 after 3, or re-do 2 maybe or
else leading whitspace could be an issue. Maybe say that
sometimes you need to do step 2 >1 time? 

- 3.1, oops, an ambiguity - in "The following steps MUST be
applied in order..." does "in order" mean "in the order
below" or "so as to"? I assume the latter.

- 3.1: In general I think you'd be better if you pointed at
specific bits of text in all the RFCs mentioned in 3.1 -
it's maybe easy to get wrong otherwise, esp. if we don't yet
have >1 implementation.

- 3.1, step 6: names are all ASCII right? just checking

- 3.2, step 1 - given 3.3 step 2, you're missing a step to
"publish the cert" at the c= location as well.

[Ballot discuss]
Thank you for putting substantial effort into this document.

I have a few discusses. I hope they can be resolved quickly.

In Section 2.1. The reference to the aligned certificate  which has the same private key that signed the RPSL object is mandatory, and defined by a RSYNC URL or a HTTP(S) URL. My question surrounds the "or". The architecture of RPKI (IIRC) is centered around RSYNC, and thus SIA/AIA values MUST have a RSYNC URL, and MAY have other types. By this are you leaving it to the issuing party to control the RPKI Distribution mechanisms of the Replying Party? I am quite comfortable with "or" personally, however this facet of fetching the RPSL Certificate to validate the private key usage is seemingly orthogonal to the RPKI architecture of RSYNC preferred and should be called out if 'or' is the clear intention. Or, has the consensus of the WG moved on from being wedded to RSYNC?

If it is truely "or", my observation is that the use of the RPKI repository is one of  convenience, and that should be called out, in fact it does appear that any valid certificate bearing RFC3779 extensions could be used to validate the digital signature associated with the RPSL object provided the relying party has trust anchor material that leads to the corresponding EE certificate and therefore private key. Is this observation correct?

The Signature expiration time field ("x") currently has no time constraints, and I'm very surprised that it is optional with the text in s2.5, given that the expiration time, by my reading, could not be beyond the 'not after' time of the corresponding certificate. Can you please instruct me as to what the consensus position on this was? A criticism of many IRRs is that data becomes stale. have the signature expiration time field could aide in data freshness models and reduce load on automated import and validation of these RPSL signatures.

And lastly, IRRs tend to run over the (legacy?) whois port 43 that doesn't provide channel layer security. This means that while signature provide a means of detecting modification it may not stop a a MiTM event where the entire object is omitted. Do you agree? if so that might be appropriate for the Security Considerations section.

[Ballot comment]
one nit:

"MUST reject the signature and threat the object as a regular" I think you mean `s/threat/treat`

Misc comments:

* Thank you for the very clear canonicalisation requirements!

* For route6 objects, where two resource holder's signatures considered such that it might address the inability to properly sign the RPSL when one holder possesses the ASN and another possesses the prefix? (just a comment, nothing more)

[Ballot discuss]
This is a generally a well written document and I don't object to its publication. However I have several minor but important points which should be easy to address:

In Section 2.1:

  Reference to the certificate corresponding to the private key used to sign this object (field "c"). The value of this field MUST be a URL of type "rsync" or "http(s)"

You need to have Normative references for the corresponding URI RFCs: RFC 5781 for rsync URIs and RFC 7230 for http/https URIs.

  that points to a specific resource certificate in an RPKI repository [RFC6481]. Any non URL-safe characters (including semicolon ";" and plus "+") must be URL encoded.

This really need a Normative reference to RFC 3986.


  The signature itself (field "b"). This MUST be the last field in the list. The signature is the output of the signature algorithm using the appropriate private key and the calculated hash value of the object as inputs. The value of this field is the digital signature in base64 encoding [RFC4648].

As RFC 4648 specifies 2 base64 alphabets, you need to include section number. I think you meant Section 4 (and not Section 5).

[Ballot comment]
In Section 2.1:

  Time of signing (field "t"). The format of the value of this field MUST be in the Internet Date/Time format [RFC3339]. All times MUST be converted to Universal Coordinated Time (UTC)

To be pedantic, you should clarify that you mean the date-time ABNF production with the timezone always being "Z".

In 3.1, inside numbered list (item 3):

* Converting all line endings to a single blank space.

Please include ASCII code for space, because " " is not very helpful, especially considering that there are other Unicode space characters which are not visually distinguishable. The same issue elsewhere in this section.

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

IANA has reviewed draft-ietf-sidr-rpsl-sig-10.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA 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, IANA does not object.

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

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-sidr-rpsl-sig@ietf.org, sidr@ietf.org, "Sandra L. Murphy" , sidr-chairs@ietf.org, sandy@tislabs.com, aretana@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Securing RPSL Objects with RPKI Signatures) to Proposed Standard


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'Securing RPSL Objects with RPKI Signatures'
  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 2016-05-09. 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 a method to allow parties to electronically
  sign Routing Policy Specification Language objects and validate such
  electronic signatures.  This allows relying parties to detect
  accidental or malicious modifications on such objects.  It also
  allows parties who run Internet Routing Registries or similar
  databases, but do not yet have Routing Policy System Security-based
  authentication of the maintainers of certain objects, to verify that
  the additions or modifications of such database objects are done by
  the legitimate holder(s) of the Internet resources mentioned in those
  objects.  This document updates RFC 2622 and RFC 4012 to add the
  signature attribute to supported RPSL objects.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/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?

  The draft requested status is Standard, as indicated on the title
  page.  This is appropriate as it is defining a security protection
  for database objects that are vital to Internet operations, where the
  protection must be implemented in multiple databases and is used
  by diverse users of the multiple databases.

(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 a method to allow parties to electronically
  sign Routing Policy Specification Language objects and validate such
  electronic signatures.  This allows relying parties to detect
  accidental or malicious modifications on such objects.  It also
  allows parties who run Internet Routing Registries or similar
  databases, but do not yet have Routing Policy System Security-based
  authentication of the maintainers of certain objects, to verify that
  the additions or modifications of such database objects are done by
  the legitimate holder(s) of the Internet resources mentioned in those
  objects.  This document updates RFC 2622 and RFC 4012 to add the
  signature attribute to supported RPSL objects.

Working Group Summary

  This document has been in the working group for a long time, and has
  been presented at IETF75, IETF77, IETF78, and IETF92.  The wg
  has been asked periodically to confirm continued interest, and has
  each time indicated that the work is valuable and should continue.

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?

  The work mentioned here is applicable to routing registries
  that use the Routing Policy Specification Language (RPSL).
  Most, if not all, routing registries use RPSL.  This new
  attribute has been implemented in IRRd, a commonly used
  implementation of RPSL.

  Geoff Huston and Stephen Kent both performed thorough
  reviews, resulting in important changes.

  No expert review was required.

Personnel

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

  Shepherd: Sandra Murphy
  Responsible AD: Alvaro Retana

(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 document shepherd has reviewed the document, identified a few
  ambiguities which have been resolved with the authors.

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

  No.  This document has been reviewed by the wg multiple times.

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

  There is no need for a broader review.

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

  The document shepherd has 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.

  The document authors have all confirmed they know of no needed
  IPR disclosures.

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

  There is no IPR disclosure filed for this document.

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

  The wg has confirmed more than once that they are interested
  in this work and have reviewed it multiple times. 

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

  There has been neither threat of an appeal nor extreme discontent.

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

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

  The document has no content that requires formal review.

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

  Yes, the references are all identified as normative.

(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, all references are published RFCs.

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

  The idnits tool reports no downward normative references.

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

  This document updates RFC2622 and RFC4012 with a new attribute type.
  That is indicated in the abstract and discussed in the introduction.

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

  The IANA considerations section reports no need for IANA actions.
  That is consistent with the body of the 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.

  This document creates no new IANA registries.

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

  There are no sections of the document written in a formal language.

Requests were made for previous commenters to confirm the latest version addresses the comments, but no one replied.  The chairs have reviewed the comments and the latest version and are satisfied that all comments were addressed.  The authors have discussed the future of this draft with the chairs.