Subject: [sidr] Last Call: <draft-ietf-sidr-rpsl-sig-10.txt> (Securing RPSL Objects with RPKI Signatures) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 25 Apr 2016 11:45:08 -0700

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'
  <draft-ietf-sidr-rpsl-sig-10.txt> 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
[email-masked] mailing lists by 2016-05-09. Exceptionally, comments may be
sent to [email-masked] 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.

---

From: Tom Harrison <[email-masked]>
Date: Fri, 29 Apr 2016 08:54:51 +1000

Section 5 requires that an EE certificate be used for the signing of
the RPSL object.  An EE certificate must contain an SIA extension that
points to an RPKI signed object (RFC 6487 [4.8.8.2]).  The draft does
not define a profile for a new type of object, or specify an existing
one that may be used instead.  There are a number of ways to deal with
this: for example, by defining a new profile and changing the
signature URL to suit, or by amending RFC 6487 such that object
pointers in EE certificates are optional.

Section 4 specifies sets of attributes that must be signed.  'org' is
included as one of these attributes for the as-block, inet[6]num, and
route[6] object types.  However, 'org' is not defined in either of the
principal RPSL RFCs (2622 and 4012), and there are current
implementations (e.g. APNIC's) that do not support it.  I think the
references to 'org' should be omitted.

Section 4 specifies 'signature' as an attribute that must be signed.
'signature' can appear multiple times in a single object, where e.g.
two different resource holders sign a route[6] object.  Given that the
text doesn't explicitly state that only the newest 'signature' must be
signed, it would appear to require that any extant 'signature'
attributes be signed as well.  That in turn would prevent previous
signers from re-signing the object independently of the subsequent
signers.  I think the text should be changed so that only the new
signature attribute need be signed.

Section 2.4 requires that "the Internet number resources present in
[RFC3779] extensions of the certificate referred to in the "c" field
of the signature must cover the resources in the primary key of the
object".  This means that it's not possible to sign a route[6] object
for a route where one resource holder has the ASN and another the
prefix.  In revision 8 (and earlier), the possibility of there being
multiple signatures, each with a certificate covering a subset of the
primary key resources, was explicitly permitted.  I think that the
previous text here should be restored.

(The above points were the product of much discussion of this draft
with Tim and Oleg from RIPE, not that I'm speaking for them.  We were
able to write interoperable prototype signer/validator
implementations, so the document is in pretty good shape on the
whole.)

-Tom