Subject: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 20 May 2021 00:48:09 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-finding-geofeeds-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Roman and Russ did the heavy lifting already, but I think I have a bit more
fiddling to do regarding the validation procedures (just getting them
internally consistent, I think)...

(1)
Here:

   As the signer specifies the covered RPKI resources relevant to the
   signature, the RPKI certificate covering the inetnum: object's
   address range is included in the [RFC5652] CMS SignedData
   certificates field.

we say that the signing certificate is included in the SignedData
certificates field.  That makes sense, as SignedData is a SEQUENCE
including "certificates [0] IMPLICIT CertificateSet OPTIONAL", and
CertificateSet, as a SET OF CertificateChoices, allows for the literal
"Certificate" branch of CertificateChoices.

But later on, we say that:

   1.  Obtain the signer's certificate from an RPKI Repository.  The
       certificate SubjectKeyIdentifier extension [RFC5280] MUST match
       the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
       [RFC5286].  If the key identifiers do not match, then validation
       MUST fail.

which entails fetching the certificate from a directory, based on the
SubjectKeyIdentifier.

Why do we need to obtain the certificate twice in two different ways?

(2)
We are careful to note that:

   The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
   present exactly as shown.

How do we construct the bits (CIDR block?) that come after the quoted
strings?  Do they only matter for matching start/end, or are we supposed
to check them in the validation procedure?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Kyle Rose for the secdir review, and all who participated in
the subsequent discussion.

Publishing this document on the stanards-track does make one wonder
whether RFC 8805 should be adopted at least into the IETF stream and
possibly to the standards-track as well...

My colleagues have done a great job commenting on aspects that I also
was unsure about; I will try (and no doubt fail) to deduplicate.

The length of my comments notwithstanding, thank you for putting
together this document: it seems useful without trying to boil any
oceans, and I hope my comments can help improve it.

Section 1

   This document specifies how to augment the Routing Policy
   Specification Language (RPSL) [RFC2622] inetnum: class to refer

Interestingly, I don't see "inetnum" at all in RFC 2622 (but the
treatment in RFC 2725 is helpful to some extent).  Should we be
referencing 2725 (or something else) in addition to 2622?

Section 3

   The URL's use of the web PKI can not provide authentication of IP
   address space ownership.  It is only used to authenticate a pointer
   to the geofeed file, [...]

I'm a little confused by the use of the phrase "authenticate a pointer
to the geofeed file".  My understanding is that the "pointer to the
geofeed file" is the URL itself, i.e., it is a pointer from the RPSL
stanza to the geofeed file, and that dereferencing the URL retrieves the
geofeed file itself (i.e., not a pointer).  In particular, the URL (and
any Web PKI usage therein) does not do anything to authenticate the RPLS
stanza in which the URL appears.  IIUC, it would be okay to just drop
that bit and say "It is only used to authenticate the domain name in the
URL, and provide confidentiality and integrity for the geofeed file in
transit".  Am I missing something?

   If a geofeed CSV file describes multiple disjoint ranges of IP
   address space, there are likely to be geofeed references from
   multiple inetnum: objects.

We might note that such files with geofeed references from multiple
inetnum: objects are not compatible with our signing procedure (right?)
and thus vaguely discouraged.

Section 4

   address range.  One needs a format that bundles the relevant RPKI
   certificate with the signature and the digest of the geofeed text.

If the signature is distributed alongside the file being signed, why is
it necessary to bundle the digest of the file being signed with the
signature?  This just invites security-relevant implementation bugs
where the validator just accepts the precomputed digest and does not
validate that the contents of the geofeed file actually have that
digest.
(There is, however, value in the CMS SignedData including the digest
*algorithms* used in signatures.  I don't know if that was the intent
here.)

   text.  Trailing space characters MUST NOT appear on a line of text.
   That is, the space or tab characters must not be followed by the
   <CRLF> sequence.  [...]

Is the restriction on Unicode characters of category "space separator"
("space characters") or the two listed characters?  (Why just those two,
and not form feed as well?)

   The address range of the signing certificate MUST cover all prefixes
   in the geofeed file it signs; and therefore must be covered by the
   range of the inetnum:.

Maybe I'm just confused about what "covered by he range of the inetnum:"
means, but I only see (at least so far) requirements that the signing
cert cover all addresses in the file, and that we fetch from the
most-specific inetnum: object with a geofeed reference.  Can't I still
sign with a cert that covers a broader range of addresses than the
intenum: object used to fetch?

   Identifying the private key associated with the certificate, and
   getting the department with the Hardware Security Module (HSM) to
   sign the CMS blob is left as an exercise for the implementor.  On the

I thought there was some previous discussion of this but now I can't
find it: I assume that a HSM is not mandatory for holding the RPKI
certificate's private key.  In that case, I'd consider "getting the
department that controls the private key (which might be trapped in a
Hardware Security Module, HSM)".

   1.  Obtain the signer's certificate from an RPKI Repository.  The
       certificate SubjectKeyIdentifier extension [RFC5280] MUST match
       the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
       [RFC5286].  If the key identifiers do not match, then validation
       MUST fail.

We want RFC 5652 again, here (5286 is IP Fast Reroute: Loop-Free
Alternates, which is of no relevance to this document).

   4.  Verify that the IP Address Delegation certificate extension
       [RFC3779] covers the address range of the geofeed file.  If the
       address range is not covered, then validation MUST fail.

"address range of the geofeed file" is probably under-specified, since
the file could in theory include multiple disjoint ranges.  I assume we
want to say something like "covers all the addresses and/or address
ranges in the geofeed file" and make the grammar in the last sentence
match.

   5.  Validation of the signing certificate MUST ensure that it is part
       of the current manifest and that the resources are covered by the
       RPKI certificate.

Is "the signing certificate" different from "the RPKI certificate"?

Also, I suggest clarifying what "the resources" are that are covered.

Also^2, "the current manifest" would be a great place to put in a
reference to the relevant document(s)

Section 5

   If and only if the geofeed file is not signed per Section 4, then
   multiple inetnum: objects MAY refer to the same geofeed file, and the
   consumer MUST use only geofeed lines where the prefix is covered by
   the address range of the inetnum: object they have followed.

Does "geofeed lines" here mean "lines/entries in the geofeed file", as
opposed to "the geofeed: attribute in the intenum: class"?
(Also, didn't we say earlier that geofeed files could have entries that
don't map up to a CIDR block and thus don't have a well-defined prefix?)

   To minimize the load on RIR whois [RFC3912] services, use of the
   RIR's FTP [RFC0959] services SHOULD be the preferred access.  This

Preferred access for which objects/resources?

   If an inetnum: for a wide prefix (e.g. a /16) points to an RPKI-
   signed geofeed file, a customer or attacker could publish an unsigned
   equal or narrower (e.g. a /24) inetnum: in a whois registry which has
   weak authorization.

I might reiterate that the rule for fetching from the most-specific
inetnum: object with a geofeed reference means that the spoofed data
will take effect (for the affected prefix), and possibly also that if
validators could always require signatures, the attack would be stymied
(but of course that is not happening anytime soon).

Appendix A

Those are some interesting Subject CNs in the non-root certs, but I
guess they work...

I only did some cursory spot-checking of the examples, and not a full
work-up.

NITS

Section 1

   of the service.  This is often done using the source IP address used
   to contact the service.  [...]

I'd consider s/using/by using/ or s/using/based on/

Section 2

   Content providers and other parties who wish to locate an IP address
   to a geographic locale need to find the relevant geofeed data.  In

I'd suggest s/to locate/to associate/

   and high granularity can be quite large.  The size of a file can be
   even larger if an unsigned geofeed file combines data for many
   prefixes, dual IPv4/IPv6 spaces are represented, etc.

I'm not sure how the unsigned nature of the geofeed file is relevant for
discussing its large size.

Section 3

   The Routing Policy Specification Language (RPSL), and [RFC2622] and
   [RFC4012] used by the Regional Internet Registries (RIRs) specifies

Is the ", and" needed?

Section 4

   Should the authenticator be syntactically incorrect per the above,
   the authenticator is invalid.

"The above" seems to be mostly discussing the geofeed file being signed,
not the authenticator per se.

   Borrowing detached signatures from [RFC5485], after file
   canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
   would be used to create a detached DER encoded signature which is

Why "would be used" (vs "is used")?

   All of these steps MUST be successful to consider the geofeed file
   signature as valid.

   As the signer specifies the covered RPKI resources relevant to the
   signature, the RPKI certificate covering the inetnum: object's
   address range is included in the [RFC5652] CMS SignedData
   certificates field.

   Identifying the private key associated with the certificate, and
   getting the department with the Hardware Security Module (HSM) to
   sign the CMS blob is left as an exercise for the implementor.  On the
   other hand, verifying the signature requires no complexity; the
   certificate, which can be validated in the public RPKI, has the
   needed public key.

The last two paragraphs here seem to be copy/paste leftovers, as they
(or a edited copy) already appeared prior to the detailed/enumerated
validation procedure.

   [I-D.spaghetti-sidrops-rpki-rsc] describes and provides code for a
   Cryptographic Message Syntax (CMS) profile for a general purpose
   listing of checksums (a 'checklist'), for use with the Resource
   Public Key Infrastructure (RPKI).  It provides usable, albeit
   complex, code to sign geofeed files.

I don't see any code in the draft itself ("provides"), but probably
there is code referenced from it.

Section 5

   their RIR/NIR and/or any provider LIR which has assigned prefixes to

Interestingly, RIR is not listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt (and LIR not
listed at all!).  This is the first time we use LIR, so we should expand
it.

   It is good key hygiene to use a given key for only one purpose.  To
   dedicate a signing private key for signing a geofeed file, an RPKI CA
   may issue a subordinate certificate exclusively for the purpose as
   shown in Appendix A.

"subordinate certificate" seems to be a very uncommon phrase (and mostly
only appears as part of "subordinate certificate authority").  Perhaps
"a dedicated certificate" or "a leaf certificate" would work just as
well?

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 May 2021 11:31:40 -0400

Ben:

Responding to Part 1 of your DISCUSS and a few of your comments.  My co-authors will address the other parts, including the NITS.

Thanks for catching this error that I introduced yesterday.  Here is a correction.

OLD:

NEW:

   1.  Obtain the signer's certificate from the CMS SignedData CertificateSet
        [RFC5652].  The certificate SubjectKeyIdentifier extension [RFC5280]
       MUST match the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
       [RFC5652].  If the key identifiers do not match, then validation
       MUST fail.

[snip]

[snip]

> transit".  Am I missing something?

I think it would be more accurate to say that the WebPKI provides
authentication and integrity of the geofeed file that is fetched.  However,
as I said in response to Roman's ballot comments, the ultimate integrity
check is the signature that is validated with the RPKI certificate.

[snip]

> validate that the contents of the geofeed file actually have that

This comes from the fact that CMS does carry the message digest in a
signed attribute, but this is probably too much detail at this point in the
discussion.

OLD:

   One needs a format that bundles the relevant RPKI
   certificate with the signature and the digest of the geofeed text.

NEW:

   One needs a format that bundles the relevant RPKI
   certificate with the signature of the geofeed text.

> *algorithms* used in signatures.  I don't know if that was the intent

Yes, CMS carries the digest algorithm identifier.  We can be more explicit.

OLD:

   Borrowing detached signatures from [RFC5485], after file
   canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
   would be used to create a detached DER encoded signature which is
   then padded BASE64 encoded (as per [RFC4648]) and line wrapped to 72
   or fewer characters.

NEW:

   Borrowing detached signatures from [RFC5485], after file
   canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
   would be used to create a detached DER encoded signature which is
   then padded BASE64 encoded (as per [RFC4648]) and line wrapped to 72
   or fewer characters.  The same digest algorithm MUST be used for
   calculating the message digest on content being signed, which is the
   geofeed file, and calculating the message digest on the SignerInfo 
   SignedAttributes [RFC8933].  The message digest algorithm identifier
   MUST appear in both the SigenedData DigestAlgorithmIdentifiers and
   the SignerInfo DigestAlgorithmIdentifier [RFC5652].

> and not form feed as well?)

Looking at the ABNF in RFC 8805, It does not look like there should be
any trailing whitespace, this was more for consistency with RFC 5485.

> Alternates, which is of no relevance to this document).

This typo was corrected in the response to your DISCUSS ballot position.

> ranges in the geofeed file" and make the grammar in the last sentence

Yes.  That is better.

OLD:

NEW:

   4.  Verify that the IP Address Delegation certificate extension
       [RFC3779] covers all of the address ranges of the geofeed file.
       If all of the address ranges are not covered, then validation
       MUST fail.

> Is "the signing certificate" different from "the RPKI certificate"?

To be consistent with the other numbered paragraphs, it would be
better to say "signer's certificate".

> Also, I suggest clarifying what "the resources" are that are covered.

As you suggest above, "all of the address ranges of the geofeed file"
is probably a good way to say it.

> reference to the relevant document(s)

Yes, a reference to RFC 6486 would be good here.

[snip]

> I only did some cursory spot-checking of the examples, and not a full

The RPKI purposely does not identify the current address block holder.

RFC 6487 says:

   An issuer name MUST contain one instance of the CommonName attribute
   and MAY contain one instance of the serialNumber attribute.  If both
   attributes are present, it is RECOMMENDED that they appear as a set.
   The CommonName attribute MUST be encoded using the ASN.1 type
   PrintableString [X.680].  Issuer names are not intended to be
   descriptive of the identity of issuer.

There is similar language for the subject name.

Russ

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 May 2021 09:13:52 -0700

> Responding to Part 1 of your DISCUSS and a few of your comments.  My
> co-authors will address the other parts, including the NITS.

turning attention to this now.  i was in the RIPE meetings getting this
through their sausage machine.

>        [RFC5652].  If the key identifiers do not match, then validation

done

> check is the signature that is validated with the RPKI certificate.

the current text is close to this.  please indicate any tweaks that
would improve it

   The URL's use of the web PKI can not provide authentication of IP
   address space ownership.  It is only used to authenticate a pointer
   to the geofeed file, authenticate the domain name in the URL, and
   provide confidentiality and integrity for the geofeed file in
   transit.  In contrast, the Resource Public Key Infrastructure (RPKI,
   see [RFC6481]) can be used to authenticate IP space ownership; see
   optional authentication in Section 4.

>    certificate with the signature of the geofeed text.

easy

>    the SignerInfo DigestAlgorithmIdentifier [RFC5652].

ok

> any trailing whitespace, this was more for consistency with RFC 5485.

perhaps a clearer phrasing would be

    Trailing space characters MUST NOT appear on a line of text.  That
    is, space or tab characters must not immediately preceed a <CRLF>
    sequence.

>        If all of the address ranges are not covered, then validation

ok

> better to say "signer's certificate".

ack

> is probably a good way to say it.

ack

> Yes, a reference to RFC 6486 would be good here.

ack

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 May 2021 15:11:51 -0700

ok, let me try to cover what russ has not.  good reviews are much
appreciated

  [ in the cs academic social circle, there has been comment that,
    though reviews can be a pita, they are substantial revwiews.  one
    gets useful feedback.  in man other fields, one gets one or two
    sentences saying useless and even rude things.  the ietf review
    cycle, once one gets to last call (yes, that is a problem), is even
    more thorough and constructive. ]

> to check them in the validation procedure?

how about

   The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
   present following the model as shown.  The IP address range MUST
   match that of the signer's certificate.

and the cert is already in the validation

> the subsequent discussion.

indeed

> possibly to the standards-track as well...

and it could use a bit of work in the process.  can you say "let's open
a can of worms?"  but yes, geofeed has seriously 8805 deployment, and it
is showing cracks.

> referencing 2725 (or something else) in addition to 2622?

grumph!  i though i had fixed this.  clearly i had not.

> transit".  Am I missing something?

no.  my current edit buffer has

   The URL uses HTTPS, so the WebPKI provides authentication, integrity,
   and confidentiality for the fetched geofeed file.  However, the
   WebPKI can not provide authentication of IP address space assignment.
   In contrast, the Resource Public Key Infrastructure (RPKI, see
   [RFC6481]) can be used to authenticate IP space assignment; see
   optional authentication in Section 4.

> and thus vaguely discouraged.

i am not sure i would discourage the use, as i suspect the rpki
authentication will mostly remain unused.

   If a geofeed CSV file describes multiple disjoint ranges of IP
   address space, there are likely to be geofeed references from
   multiple inetnum: objects.  Files with geofeed references from
   multiple inetnum: objects are not compatible with the signing
   procedure in Section 4.

> intenum: object used to fetch?

i am trying to think of two examples [ yes, certs and inetnum:s may
express ranges as well as cidr blocks ]

two inetnums:
   1.2.3.0 - 1.2.3.7 
   1.2.3.6 - 1.2.3.13
and a cert for 1.2.3.0 - 1.2.3.13

and conversely

two certs:
   1.2.3.0 - 1.2.3.7 
   1.2.3.6 - 1.2.3.13
and an inetnum: for 1.2.3.0 - 1.2.3.13

and i m starting to think i am rat-holing on complexlow-payoff corner
cases, a disease i rather dislike.

the current state is simple and clear.  are there seriously useful cases
it does not cover?  i will keep thinking.  and listening, of course.

> Hardware Security Module, HSM)".

cool

   If and only if the geofeed file is not signed per Section 4, then
   multiple inetnum: objects MAY refer to the same geofeed file, and the
   consumer MUST use only lines in the geofeed file where the prefix is
   covered by the address range of the inetnum: object they have
   followed.

> (Also, didn't we say earlier that geofeed files could have entries
> that don't map up to a CIDR block and thus don't have a well-defined
> prefix?)

i hope not.  a range such as 1.2.3.4-1.2.3.5 may not be a cidr block
but it is considered a well-defined prefix in rpsl and rpki.

   To minimize the load on RIR whois [RFC3912] services, use of the
   RIR's FTP [RFC0959] services SHOULD be used for large scale access to
   gather geofeed URLs.  This also provides bulk access instead of
   fetching by brute force search through the IP space.

> (but of course that is not happening anytime soon).

   For example, if an inetnum: for a wide prefix (e.g. a /16) points to
   an RPKI-signed geofeed file, a customer or attacker could publish an
   unsigned equal or narrower (e.g. a /24) inetnum: in a whois registry
   which has weak authorization abusing the rule that the most-specific
   inetnum: object with a geofeed reference MUST be used.

   If signatures were mandatory, the above attack would be stymied.  But
   of course that is not happening anytime soon.

randy

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 20 May 2021 16:36:33 -0700

I'll try to respond to the thread in reverse order to avoid duplication...

> and the cert is already in the validation

That removes the ambiguity I was worried about.  It seems like it should
work.

> a can of worms?"  but yes, geofeed has seriously 8805 deployment, and it

The analogies to DMARC do kind of write themselves...

>    optional authentication in Section 4.

Excellent, thanks.

>    multiple inetnum: objects are not compatible with the signing

ok.
(We do have plenty of examples of shiny cryptographic schemes that remain
mostly unused, but I will refrain from naming names...)

> express ranges as well as cidr blocks ]

IIUC you'd need to subdivide the inetnums in order for the signatures to
work?

> it does not cover?  i will keep thinking.  and listening, of course.

I think I just propose to drop the clause "and therefore must be covered by
the range of the inetnum:" since I don't understand what it is trying to
say.

>    covered by the address range of the inetnum: object they have

thanks

> but it is considered a well-defined prefix in rpsl and rpki.

(We actually said "objects and RPKI certificates need not align on CIDR
prefix boundaries, while those of the CSV lines in the geofeed file do".
My mistake, sorry.)

>    fetching by brute force search through the IP space.

thanks

>    which has weak authorization abusing the rule that the most-specific

nit: comma before "abusing" to aid readability.

>    of course that is not happening anytime soon.

Looks good, thanks.  (I will watch and see if anyone complains about the
last sentence.)

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 20 May 2021 16:47:49 -0700

On Thu, May 20, 2021 at 09:13:52AM -0700, Randy Bush wrote:
> Russ wrote:

mmm, sausage, tasty.

> >        [RFC5652].  If the key identifiers do not match, then validation

+1

>    optional authentication in Section 4.
[handled in other thread]
> >    certificate with the signature of the geofeed text.

+1

> >    the SignerInfo DigestAlgorithmIdentifier [RFC5652].

+1
and thanks again to Russ for getting 8933 done

>     is, space or tab characters must not immediately preceed a <CRLF>

Hmm, so I'm supposed to read "space characters" and think "a sequence of
one or more 0x20 bytes"?  I guess I can maybe see that, but do kind of want
an answer on whether we care about other unicode codepoints that are
"whitespace" appearing immediately prior to <CRLF>.  For better or for
worse, things get complicated and messy once we go past 7-bit ASCII.

> >        If all of the address ranges are not covered, then validation

I think "If any ... are not covered" is better.  We need all to be covered,
so if any is not covered then we fail.  (Hi, De Morgan!)

> > Yes, a reference to RFC 6486 would be good here.

+3 for these.

Thanks,

Ben

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 May 2021 12:39:01 -0700

so

   The canonicalization procedure converts the data from its internal
   character representation to the UTF-8 [RFC3629] character encoding,
   and the <CRLF> sequence MUST be used to denote the end of a line of
   text.  A blank line is represented solely by the <CRLF> sequence.
   Other non-printable characters, such as backspace, are not expected.

?

---

From: Russ Housley <[email-masked]>
Date: Fri, 21 May 2021 15:43:04 -0400

I guess the last sentence should go away too.  RFC 8805 does not prohibit them, but I cannot imagine them as helpful.

Russ

> On May 21, 2021, at 3:39 PM, Randy Bush <[email-masked]> wrote:
> 
> so
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 May 2021 12:43:24 -0700

> The analogies to DMARC do kind of write themselves...

i nominate dnssec as the poster child here.  first version was not 
deployable at all.

> mostly unused, but I will refrain from naming names...)

and some that should have been unused

> IIUC you'd need to subdivide the inetnums in order for the signatures to

[ excuse i am running on 36 hours no sleep ]

currently we say

i.e. a cert for 1.2.3.0/24 can not sign either example.  i don't think
that second restrictive clause is a logical conclusion from the first.

i suggest that, for simplicity and a redundancy check, the wrapper MUST
be

    # RPKI Signature: A
    #
    # End Signature: B

where A-B MUST be the range of the inetnum: pointing to the file

and that the signing cert MUST cover A-Z, though could be wider.

i will work the text

ack

randy

---

From: Russ Housley <[email-masked]>
Date: Fri, 21 May 2021 15:35:47 -0400

> worse, things get complicated and messy once we go past 7-bit ASCII.

RFC 8805 says that each feed entry is a text line of the form:

   ip_prefix,alpha2code,region,city,postal_code

The first three fields are ASCII.  The city can be UTF-8, except comma.  The postal_code is optional and deprecated, but it can be can be UTF-9, except comma.

By that description, trailing whitespace is allowed, but not helpful.

I guess we can drop that sentence.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 May 2021 13:50:05 -0700

I don't have particular feelings on the last sentence.  It's true that
those characters don't seem to be prohibited, but it's probably still true
that we don't expect to see them.

Other than that, this looks fine.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 May 2021 14:02:09 -0700

> i nominate dnssec as the poster child here.  first version was not 

I think DNSSEC was always in the IETF stream, though -- DMARC started as
ISE, and we've had an IETF WG open for 6(?) years trying to bring it into
the IETF stream.

> and that the signing cert MUST cover A-Z, though could be wider.

That seems like it should have useful/workable properties.
We're now assigning semantics to the stuff after "RPKI Signature"/"End
Signature", that maybe didn't previously have important semantics.

Rob should probably weigh in on how much review such a change would need.

-Ben

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 May 2021 14:05:55 -0700

> Rob should probably weigh in on how much review such a change would need.

once i have the next rev out, we should look at the diff to -09 or so.
i suspect that giving the wg a week to whine would not be inappropriate.
but such decisions are above my pay grade.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 May 2021 14:17:23 -0700

i have a vague hope -14, just published, addresses all currently
expressed concerns.  but i am under my quota for wrongness for the day.

randy

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 May 2021 14:45:55 -0700

> expressed concerns.  but i am under my quota for wrongness for the day.

If we're going with "[#RPKI Signature] address range MUST match [inetnum:
followed to get here]", then there are probably a couple places that still
talk about "covered by" that should catch up.

We may also need to look more closely at the bits after "# RPKI Signature".
The example uses a CIDR range, but IIRC inetnum: ranges are not limited to
CIDR blocks, which would mean we need a story for how to handle non-CIDR
blocks.

-Ben

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 May 2021 15:12:21 -0700

> talk about "covered by" that should catch up.

don't find any

what i did find is that i forgot to remove

         The address range of the signing certificate MUST cover all
-        prefixes in the geofeed file it signs; and therefore must be
-        covered by the range of the inetnum:.
+        prefixes in the geofeed file it signs.

> We may also need to look more closely at the bits after "# RPKI
> Signature".  The example uses a CIDR range, but IIRC inetnum: ranges
> are not limited to CIDR blocks, which would mean we need a story for
> how to handle non-CIDR blocks.

ranges are well-defined in rpki, inetnum:, etc.  8805 entries must be
cidr.

that an inetnum: or rpki cert range must cover geofeed file prefixes
seems pretty clear.  but i have tweaked wording a bit.  i can push my
emacs buffer to id repo, but will wait a bit for other comments.

randy

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 25 May 2021 11:53:29 +0000

Hi Ben,

When you get a chance, please can you check whether -15 is sufficient to clear your discuss.  I think that is the last step to progressing this doc.

Regards,
Rob

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Randy Bush
> Sent: 21 May 2021 23:12
> To: Benjamin Kaduk <[email-masked]>
> Cc: Benjamin Kaduk via Datatracker <[email-masked]>; draft-ietf-opsawg-
> [email-masked]; [email-masked]; The IESG
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-
> geofeeds-12: (with DISCUSS and COMMENT)
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 May 2021 06:18:41 -0700

mornin' folk,

thanks, rob.  to be honest, i did not track process.

> When you get a chance, please can you check whether -15 is sufficient
> to clear your discuss.  I think that is the last step to progressing
> this doc.

shout if you need anything from my side.

randy

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 25 May 2021 19:55:41 -0700

ok.

It looks like the thing in the diff that stuck out at me is actually for
the unsigned case, and "covered by" is (AFAICT) the right semantics for
that situation.
 
> emacs buffer to id repo, but will wait a bit for other comments.

I guess I dallied too long and this became the -15.

Having slept it over, I think the "IP address range [of "# RPKI
Signature:"/"# End Signature"] must match the inetnum: URL followed to get
to the file" is a good choice and helps identify the intended semantics
(though, of course, is not itself covered by the signature).

I think we still need to update the example to show how to represent a
non-CIDR range, though.  (I think, from the previous discussion, we wanted
the "RPKI Signature" line to have a starting address and the "End
Signature" line to have an ending address, but could be misremembering.)

Otherwise, looking at the diff from -12 to -15
(https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-finding-geofeeds-15&url1=draft-ietf-opsawg-finding-geofeeds-12),
I see that we now say "The IETF standardized RPSL in [RFC2725] and
[RFC4012]", but 2622 might actually be the right reference there, even if
we do need 2725 later for "inetnum:" itself.

The other changes look good.

Thanks,

Ben

P.S. I am impressed by the (apparent) automation to re-generate the
certificate (and example) at the time of building the document!

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 May 2021 20:18:06 -0700

> the unsigned case, and "covered by" is (AFAICT) the right semantics for

if it still itches, could i get a direct pointer?

> (though, of course, is not itself covered by the signature).

consider yourself lucky to have missed the dozen messages where we went
down this rathole.

> non-CIDR range, though.  (I think, from the previous discussion, we
> wanted the "RPKI Signature" line to have a starting address and the
> "End Signature" line to have an ending address, but could be
> misremembering.)

uh, i think it would be

    # RPKI Signature: 192.0.2.0 - 192.0.2.255
    # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
    # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
    ...
    # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
    # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
    # End Signature: 192.0.2.0 - 192.0.2.255

change made in my emacs buffer

> certificate (and example) at the time of building the document!

no comment

randy

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 25 May 2021 20:42:45 -0700

> if it still itches, could i get a direct pointer?

Sorry, I wasn't clear -- it *doesn't* itch anymore, now that I actually read it.
There's nothing to change.

> change made in my emacs buffer

Okay, I think that works fine.

-Ben

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 May 2021 20:43:31 -0700

will push 16

randy