Subject: [OPSAWG] AD review of draft-ietf-opsawg-finding-geofeeds-04

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 12 Apr 2021 14:16:00 +0000

Hi,

Sorry for the delayed AD review.

Whilst I regard this document is useful, and a good thing (tm), I have a couple of concerns about the exact relationship between this document (std's track) and to RFC 8805, that is informational.

Main comments:

1. Specifically, I think that it would be useful for this document to offer more clarity as to whether the "remarks: Geofeed" tag specifically ties the content of the URL to a document in RFC 8805 format, or whether other formats may be found at that URL in future, noting that RFC 8805 section 7 suggests that a future format may be defined, and end of section 4 of this document also suggests that RFC 8805 may be updated.  If multiple formats, how does the client tell the difference.

2. I wasn't quite sure whether the mechanism for authenticating geofeed data really belonged in this document (e.g., because it applies to all possible forms of geofeed data), or whether it would it is specific to the CSV format described in RFC 8805, and that an update to that document would contain the canonical reference.

3. The definition of canonicalization refers to section 2.2 of RFC 5485 (which talks about ASCII) vs RFC8805 which talks about UTF-8.  Is this disparity an issue?

4. I think that INETNUM should be a normative reference, but I also question whether it is going to be a sufficiently stable reference?  Hence, I was wondering whether it wouldn't be helpful to describe the essence of the INETNUM hierarchy here to avoid a need for a normative reference.

Minor comments:

1. Introduction

   An optional, but utterly awesome, means for authenticating geofeed
   data is also defined.

I'm guessing that this might be Warren's prose, but it perhaps might be worth refining 'utterly awesome' to 'practical'?

2.  Geofeed Files

   The size of a file can be
   even larger if an unsigned geofeed file combines data for many
   prefixes, as may be likely if the location data are maintained by a
   different department than address management, dual IPv4/IPv6 spaces
   are represented, etc.
   
I'm not disputing this, but I wasn't sure why having different departments would increase the side of data.

   This document also suggests optional data for geofeed files to
   provide stronger authenticity to the data.

Would "optional signature data" be clearer than just "optional data"?

3.  inetnum: Class

   Until all producers of inetnum:s, i.e. the RIRs, state that they have
   migrated to supporting a geofeed: attribute, consumers looking at
   inetnum:s to find geofeed URLs MUST be able to consume both the
   remarks: and geofeed: forms.

Is there any possibility that the proper geofeed attribute won't be standardized as "geofeed:"?  I.e., this document refers to this attribute as "geofeed:", but the way that it is written it would end up being very
confusing if the "proper geofeed: attribute" was standardized as "geo-feed:" by referred to as "geofeed:" by this document.

I think that it would aid clarity, at a minimum, if it always at least referred to as the "proper geofeed: attribute", but it may better to just refer to it as the "proper geofeed attribute", i.e., to avoid binding the name used in this document to the proposed long term name?

   Any particular inetnum: object MAY have, at most, one geofeed
   reference, whether a remarks: or a proper geofeed: attribute when one
   is defined.

I think that this MAY should be a MUST, probably with the commas removed.  Otherwise, the constraint can be ignored.  E.g. NEW: 

   Any particular inetnum: object MUST have at most one geofeed
   reference, whether a remarks: or a proper geofeed: attribute when one
   is defined.

Although the draft does not allow a record to contain it, is it worth specifying what a client should do if it receives a record with both "remark: Geofeed" and the proper geofeed attribute?  E.g., should a client choose to use one in preference to the other?

   Currently, the registry data published by ARIN is not the same RPSL
   as the other registries; therefore, when fetching from ARIN via FTP
   [RFC0959], whois [RFC3912], RDAP [RFC7482], or whatever, the
   "NetRange" attribute/key must be treated as "inetnum" and the
   "Comment" attribute must be treated as "remarks".

Is there a reason why these are musts are not MUSTs?  Otherwise, could change from "must be treated" to "is treated" to avoid potential ambiguity.

   inetnum: objects form a hierarchy, see [INETNUM] Section 4.2.4.1,
   Hierarchy of INETNUM Objects.  Geofeed references SHOULD be at the
   lowest applicable inetnum: object.  When fetching, the most specific
   inetnum: object with a geofeed reference MUST be used.
   
As menionted earlier, is "Section 4.2.4.1" going to be a sufficiently stable reference?

   It is significant that geofeed data may have finer granularity than
   the inetnum: which refers to them.
   
This paragraph felt incomplete to me, i.e., I wasn't quite sure what it is trying to convey.

4.  Authenticating Geofeed Data

The text in this section feels a little bit colloquial to me.  As per above, is the intention that this defines the definitive signature encoding that would apply to all Geofeed files (if there is more than one format)?  Or would that we defined in an RFC8805 bis document?

E.g., perhaps change "it would be essentially" to "it is",
      And probably change "would be" to "is" in a few places.

   Both the address ranges of the signing certificate and of the
   inetnum: MUST cover all prefixes in the geofeed file; and the address
   range of the signing certificate must cover that of the inetnum:.

This could perhaps be more simply stated as, NEW:

   The address range of the signing certificate MUST cover that of the
   inetnum: and the address ranges of the inetnum: MUST cover all
   prefixes in the geofeed file.

   An address range A 'covers' address range B if the range of B is
   identical to or a subset of A.  'Address range' is used here because
   inetnum: objects and RPKI certificates need not align on CIDR prefix
   boundaries, while those of geofeed lines must.
   
Unclear what is meant by geofeed lines.  Does this mean entries in the geofeed csv?  Perhaps clarify.  Note, Geofeed lines is used in a couple of places in the document.

   Identifying the private key associated with the certificate, and
   getting the department with the 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.
   
HSM - Hardware Security Module?  If so, please expand on first use.

   Until [RFC8805] is updated to formally define such an appendix, it
   MUST be 'hidden' as a series of "#" comments at the end of the
   geofeed file.  This is a cryptographically incorrect, albeit simple
   example.  A correct and full example is in Appendix A.
   
Presumably the # prefixes of the line MUST be stripped before processing?  Does that need to be stated here?

Nits:

 "Iff the geofeed file" => If, and only if, the geofeed file"?
 "fetching with a tweezers." => "fetching with tweezers" or "fetching with a pair a tweezers".
   
RPKI - Please expand on first use.

Regards,
Rob

---

From: Randy Bush <[email-masked]>
Date: Mon, 12 Apr 2021 14:36:30 -0700

hi rob et alia,

first, thanks a milion for a real review.  really appreciated.

> 1. Specifically, I think that it would be useful for this document to
> offer more clarity as to whether the "remarks: Geofeed" tag
> specifically ties the content of the URL to a document in RFC 8805
> format, or whether other formats may be found at that URL in future,
> noting that RFC 8805 section 7 suggests that a future format may be
> defined, and end of section 4 of this document also suggests that RFC
> 8805 may be updated.  If multiple formats, how does the client tell
> the difference.

see diff.  a lot of 8805 refs sprinkled in before the word 'geofeed
file'

> 2. I wasn't quite sure whether the mechanism for authenticating
> geofeed data really belonged in this document (e.g., because it
> applies to all possible forms of geofeed data), or whether it would it
> is specific to the CSV format described in RFC 8805, and that an
> update to that document would contain the canonical reference.

ibid

> 3. The definition of canonicalization refers to section 2.2 of RFC
> 5485 (which talks about ASCII) vs RFC8805 which talks about UTF-8.  Is
> this disparity an issue?

russ, how do you want to handle?

> 4. I think that INETNUM should be a normative reference, but I also
> question whether it is going to be a sufficiently stable reference?
> Hence, I was wondering whether it wouldn't be helpful to describe the
> essence of the INETNUM hierarchy here to avoid a need for a normative
> reference.

this is why 2275 and 4012 are normative and the refs to ripe docs are
informative.

> I'm guessing that this might be Warren's prose, but it perhaps might
> be worth refining 'utterly awesome' to 'practical'?

my memory could be off, but i think it was i mocking warren.  i can make
the change.  sense of humor declines in the ietf.

> 2.  Geofeed Files
> 
>    The size of a file can be even larger if an unsigned geofeed file
>    combines data for many prefixes, as may be likely if the location
>    data are maintained by a different department than address
>    management, dual IPv4/IPv6 spaces are represented, etc.
>    
> I'm not disputing this, but I wasn't sure why having different
> departments would increase the side of data.

yucchy.  removed.

> Would "optional signature data" be clearer than just "optional data"?

ok.  russ?  maybe 'authenticating'?

> Is there any possibility that the proper geofeed attribute won't be
> standardized as "geofeed:"?  I.e., this document refers to this
> attribute as "geofeed:", but the way that it is written it would end
> up being very confusing if the "proper geofeed: attribute" was
> standardized as "geo-feed:" by referred to as "geofeed:" by this
> document.

i do not think this problem to be likely.  they seem not to be wiggling;
and we are codifying the attribute name in this document.

> I think that it would aid clarity, at a minimum, if it always at least
> referred to as the "proper geofeed: attribute", but it may better to
> just refer to it as the "proper geofeed attribute", i.e., to avoid
> binding the name used in this document to the proposed long term name?

let's see how this goes.  the irr folk working on this do not seem to be
getting creative, at least along this dimension.

> Although the draft does not allow a record to contain it, is it worth
> specifying what a client should do if it receives a record with both
> "remark: Geofeed" and the proper geofeed attribute?  E.g., should a
> client choose to use one in preference to the other?

hacked to say then ignore all

> Is there a reason why these are musts are not MUSTs?

because it is arin.  unpredictable.  but i'll upcase.

> Otherwise, could change from "must be treated" to "is treated" to
> avoid potential ambiguity.

imiho, 2119 adds syntax and accompanying semantics; and should not be
taken to invalidate the american language.

> As menionted earlier, is "Section 4.2.4.1" going to be a sufficiently

unfortunately, RFC2725 is not as thorough on this point as the ripe
document.  i have hacked to ref both.

> This paragraph felt incomplete to me, i.e., I wasn't quite sure what

    I.e. an INETNUM object for a prefix P could refer to a geofeed file
    in which P has been sub-divided into one or more longer prefixes.

> The text in this section feels a little bit colloquial to me.  As per
> above, is the intention that this defines the definitive signature
> encoding that would apply to all Geofeed files (if there is more than
> one format)?  Or would that we defined in an RFC8805 bis document?
> 

sure

i don't think we want to open the 8805 can right now.  the googlers are
having a hard enough time actually using it in operation; see nanog.  so
i doubt they want to spend time on a bis.

>    prefixes in the geofeed file.

nope.  on second thought, the inetnum: might cover more or less than the
rpki cert, just so long as the cert covers the data in the file it is
signing.  i think this catches it

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

> Unclear what is meant by geofeed lines.  Does this mean entries in the
> geofeed csv?  Perhaps clarify.  Note, Geofeed lines is used in a
> couple of places in the document.

	An address range A 'covers' address range B if the range of B is
	identical to or a subset of A.  'Address range' is used here
	because inetnum: objects and RPKI certificates need not align on
	CIDR prefix boundaries, while those of the CSV lines in the
	geofeed file do.

> HSM - Hardware Security Module?  If so, please expand on first use.

ack

> Presumably the # prefixes of the line MUST be stripped before
> processing?  Does that need to be stated here?

	The signature does not cover the signature lines.

>  "Iff the geofeed file" => If, and only if, the geofeed file"?

shall i also s/i.e./id est/ etc?

>  "fetching with a tweezers." => "fetching with tweezers" or "fetching

ok

> RPKI - Please expand on first use.

ok

try this

randy

< draft-ietf-opsawg-finding-geofeeds.txt

draft-ietf-opsawg-finding-geofeeds-04.txt >

Network Working Group R. Bush

Network Working Group R. Bush

Internet-Draft IIJ & Arrcus

Internet-Draft IIJ & Arrcus

Intended status: Standards Track M. Candela

Intended status: Standards Track M. Candela

Expires: October 14, 2021 NTT

Expires: August 23, 2021 NTT

W. Kumari

W. Kumari

Google

Google

R. Housley

R. Housley

Vigil Security

Vigil Security

April 12, 2021

February 19, 2021

Finding and Using Geofeed Data

Finding and Using Geofeed Data

draft-ietf-opsawg-finding-geofeeds-05

draft-ietf-opsawg-finding-geofeeds-04

Abstract

Abstract

This document describes how to find and authenticate geofeed data.

This document describes how to find and authenticate geofeed data.

Status of This Memo

Status of This Memo

This Internet-Draft is submitted in full conformance with the

This Internet-Draft is submitted in full conformance with the

provisions of BCP 78 and BCP 79.

provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering

Internet-Drafts are working documents of the Internet Engineering

Task Force (IETF). Note that other groups may also distribute

Task Force (IETF). Note that other groups may also distribute

working documents as Internet-Drafts. The list of current Internet-

working documents as Internet-Drafts. The list of current Internet-

Drafts is at https://datatracker.ietf.org/drafts/current/.

Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months

Internet-Drafts are draft documents valid for a maximum of six months

and may be updated, replaced, or obsoleted by other documents at any

and may be updated, replaced, or obsoleted by other documents at any

time. It is inappropriate to use Internet-Drafts as reference

time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 14, 2021.

This Internet-Draft will expire on August 23, 2021.

Copyright Notice

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the

Copyright (c) 2021 IETF Trust and the persons identified as the

document authors. All rights reserved.

document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal

This document is subject to BCP 78 and the IETF Trust's Legal

Provisions Relating to IETF Documents

Provisions Relating to IETF Documents

(https://trustee.ietf.org/license-info) in effect on the date of

(https://trustee.ietf.org/license-info) in effect on the date of

publication of this document. Please review these documents

publication of this document. Please review these documents

skipping to change at page 2, line 20 ¶

skipping to change at page 2, line 20 ¶

1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2

1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2

2. Geofeed Files . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Geofeed Files . . . . . . . . . . . . . . . . . . . . . . . . 3

3. inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 3

3. inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 3

4. Authenticating Geofeed Data . . . . . . . . . . . . . . . . . 4

4. Authenticating Geofeed Data . . . . . . . . . . . . . . . . . 4

5. Operational Considerations . . . . . . . . . . . . . . . . . 6

5. Operational Considerations . . . . . . . . . . . . . . . . . 6

6. Security Considerations . . . . . . . . . . . . . . . . . . . 7

6. Security Considerations . . . . . . . . . . . . . . . . . . . 7

7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7

7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7

8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7

8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7

9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8

9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8

9.1. Normative References . . . . . . . . . . . . . . . . . . 8

9.1. Normative References . . . . . . . . . . . . . . . . . . 8

9.2. Informative References . . . . . . . . . . . . . . . . . 9

9.2. Informative References . . . . . . . . . . . . . . . . . 8

Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10

Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18

1. Introduction

1. Introduction

Providers of Internet content and other services may wish to

Providers of Internet content and other services may wish to

customize those services based on the geographic location of the user

customize those services based on the geographic location of the user

of the service. This is often done using the source IP address used

of the service. This is often done using the source IP address used

to contact the service. Also, infrastructure and other services

to contact the service. Also, infrastructure and other services

might wish to publish the locale of their services. [RFC8805]

might wish to publish the locale of their services. [RFC8805]

defines geofeed, a syntax to associate geographic locales with IP

defines geofeed, a syntax to associate geographic locales with IP

addresses. But it does not specify how to find the relevant geofeed

addresses. But it does not specify how to find the relevant geofeed

data given an IP address.

data given an IP address.

This document specifies how to augment the Routing Policy

This document specifies how to augment the Routing Policy

Specification Language (RPSL) [RFC4012] inetnum: class [RFC2725] and

Specification Language (RPSL) [RFC4012] inetnum: class [RFC2725] and

[INETNUM] to refer specifically to geofeed data CSV files, and how to

[INETNUM] to refer to geofeed data, and how to prudently use them.

prudently use them. In all places inetnum: is used, inet6num: should

In all places inetnum: is used, inet6num: should also be assumed

also be assumed [RFC4012] and [INET6NUM].

[RFC4012] and [INET6NUM].

An optional, but practical but slightly complex, means for

authenticating geofeed data is also defined.

data is also defined.

1.1. Requirements Language

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

"OPTIONAL" in this document are to be interpreted as described in BCP

"OPTIONAL" in this document are to be interpreted as described in BCP

14 [RFC2119] [RFC8174] when, and only when, they appear in all

14 [RFC2119] [RFC8174] when, and only when, they appear in all

capitals, as shown here.

capitals, as shown here.

2. Geofeed Files

2. Geofeed Files

Geofeed files are described in [RFC8805]. They provide a facility

Geofeed files are described in [RFC8805]. They provide a facility

for an IP address resource 'owner' to associate those IP addresses to

for an IP address resource 'owner' to associate those IP addresses to

geographic locale(s).

geographic locale(s).

Content providers and other parties who wish to locate an IP address

Content providers and other parties who wish to locate an IP address

to a geographic locale need to find the relevant geofeed data. In

to a geographic locale need to find the relevant geofeed data. In

Section 3 this document specifies how to find the relevant [RFC8805]

Section 3 this document specifies how to find the relevant geofeed

geofeed file given an IP address.

file given an IP address.

Geofeed data for large providers with significant horizontal scale

Geofeed data for large providers with significant horizontal scale

and high granularity can be quite large. The size of a file can be

and high granularity can be quite large. The size of a file can be

prefixes, dual IPv4/IPv6 spaces are represented, etc.

are represented, etc.

[RFC8805] geofeed data may reveal the approximate location of an IP

[RFC8805] geofeed data may reveal the approximate location of an IP

address, which might in turn reveal the approximate location of an

address, which might in turn reveal the approximate location of an

individual user. Unfortunately, [RFC8805] provides no privacy

individual user. Unfortunately, [RFC8805] provides no privacy

guidance on avoiding or ameliorating possible damage due to this

guidance on avoiding or ameliorating possible damage due to this

exposure of the user. In publishing pointers to geofeed files as

exposure of the user. In publishing pointers to geofeed files as

described in this document the operator should be aware of this

described in this document the operator should be aware of this

exposure in geofeed data and be cautious. All the privacy

exposure in geofeed data and be cautious. All the privacy

considerations of [RFC8805] Section 4 apply to this document.

considerations of [RFC8805] Section 4 apply to this document.

This document also suggests optional signature data for geofeed files

to provide stronger authenticity to the data.

3. inetnum: Class

3. inetnum: Class

RPSL, [RFC4012], as used by the Regional Internet Registries (RIRs),

RPSL, [RFC4012], as used by the Regional Internet Registries (RIRs),

has been augmented with the inetnum: [INETNUM] and the inet6num:

has been augmented with the inetnum: [INETNUM] and the inet6num:

[INET6NUM] classes; each of which describes an IP address range and

[INET6NUM] classes; each of which describes an IP address range and

its attributes.

its attributes.

Ideally, RPSL would be augmented to define a new RPSL geofeed:

Ideally, RPSL would be augmented to define a new RPSL geofeed:

attribute in the inetnum: class. Until such time, this document

attribute in the inetnum: class. Until such time, this document

defines the syntax of a Geofeed remarks: attribute which contains an

defines the syntax of a Geofeed remarks: attribute which contains an

HTTPS URL of a geofeed file. The format of the INETNUM attribute

HTTPS URL of a geofeed file. The format MUST be as in this example,

MUST be as in this example, "remarks: Geofeed" followed by a URL

"remarks: Geofeed " followed by a URL which will vary.

which will vary, but MUST refer only to a [RFC8805] geofeed file.

inetnum: 192.0.2.0/24 # example

inetnum: 192.0.2.0/24 # example

remarks: Geofeed https://example.com/geofeed.csv

remarks: Geofeed https://example.com/geofeed.csv

While we leave global agreement of RPSL modification to the relevant

While we leave global agreement of RPSL modification to the relevant

parties, we specify that a proper geofeed: attribute in the inetnum:

parties, we suggest that a proper geofeed: attribute in the inetnum:

class be simply "geofeed: " followed by a URL which will vary.

class be simply "geofeed: " followed by a URL which will vary, but

MUST refer only to a [RFC8805] geofeed file.

inetnum: 192.0.2.0/24 # example

inetnum: 192.0.2.0/24 # example

geofeed: https://example.com/geofeed.csv

geofeed: https://example.com/geofeed.csv

remarks: and geofeed: forms. This not only implies that the RIRs

remarks: and geofeed: forms. This not only implies that the RIRs

support the geofeed: attribute, but that all registrants have

support the geofeed: attribute, but that all registrants have

migrated any inetnum:s from remarks: use to geofeed:s.

migrated any inetnum:s from remarks: use to geofeed:s.

Any particular inetnum: object MUST have at most, one geofeed

reference, whether a remarks: or a proper geofeed: attribute when it

is implemented. If there is more than one, all are ignored.

is defined.

inetnum: objects form a hierarchy, see [RFC2725] Section 9.3 and

[INETNUM] Section 4.2.4.1, Hierarchy of INETNUM Objects. Geofeed

references SHOULD be at the lowest applicable inetnum: object. When

fetching, the most specific inetnum: object with a geofeed reference

MUST be used.

When geofeed references are provided by multiple inetnum: objects

When geofeed references are provided by multiple inetnum: objects

which have identical address ranges, then the geofeed reference on

which have identical address ranges, then the geofeed reference on

the inetnum: with the most recent last-modified: attribute SHOULD be

the inetnum: with the most recent last-modified: attribute SHOULD be

preferred.

preferred.

the inetnum: which refers to them. I.e. an INETNUM object for a

prefix P could refer to a geofeed file in which P has been sub-

divided into one or more longer prefixes.

"NetRange" attribute/key MUST be treated as "inetnum" and the

"Comment" attribute MUST be treated as "remarks".

The question arises of whether a particular [RFC8805] geofeed data

The question arises of whether a particular geofeed data set is

set is valid, i.e. authorized by the 'owner' of the IP address space

valid, i.e. authorized by the 'owner' of the IP address space and is

and is authoritative in some sense. The inetnum: which points to the

authoritative in some sense. The inetnum: which points to the

[RFC8805] geofeed file provides some assurance. Unfortunately the

geofeed file provides some assurance. Unfortunately the RPSL in many

RPSL in many repositories is weakly authenticated at best. An

repositories is weakly authenticated at best. An approach where RPSL

approach where RPSL was signed a la [RFC7909] would be good, except

was signed a la [RFC7909] would be good, except it would have to be

it would have to be deployed by all RPSL registries, and there is a

deployed by all RPSL registries, and there is a fair number of them.

fair number of them.

An optional authenticator MAY be appended to a [RFC8805] geofeed

An optional authenticator MAY be appended to a geofeed file. It

file. It is a digest of the main body of the file signed by the

would be essentially a digest of the main body of the file signed by

private key of the relevant Resource Public Key Infrastructure (RPKI,

the private key of the relevant RPKI certificate for the covering

see [RFC6481]) certificate for the covering address range. One needs

address range. One needs a format that bundles the relevant RPKI

a format that bundles the relevant RPKI certificate with the

certificate with the signature and the digest of the geofeed text.

signature and the digest of the geofeed text.

Borrowing detached signatures from [RFC5485], after text file

Borrowing detached signatures from [RFC5485], after text file

canonicalization (Sec 2.2), the Cryptographic Message Syntax (CMS)

canonicalization (Sec 2.2), the Cryptographic Message Syntax (CMS)

[RFC5652] is used to create a detached DER encoded signature which is

[RFC5652] would be used to create a detached DER encoded signature

then BASE64 encoded and line wrapped to 72 or fewer characters.

which is then BASE64 encoded and line wrapped to 72 or fewer

characters.

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

boundaries, while those of the CSV lines in the geofeed file do.

As the signer specifies the covered RPKI resources relevant to the

As the signer would need to specify the covered RPKI resources

signature, the RPKI certificate covering the inetnum: object's

relevant to the signature, the RPKI certificate covering the inetnum:

address range is included in the [RFC5652] CMS SignedData

object's address range would be included in the [RFC5652] CMS

certificates field.

SignedData certificates field.

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.

geofeed file. The following is a cryptographically incorrect, albeit

simple example. A correct and full example is in Appendix A.

# RPKI Signature: 192.0.2.0/24

# RPKI Signature: 192.0.2.0/24

# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ

# MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ

# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu

# IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu

...

...

# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa

# imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa

# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=

# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=

# End Signature: 192.0.2.0/24

# End Signature: 192.0.2.0/24

The signature does not cover the signature lines.

[I-D.spaghetti-sidrops-rpki-rsc] describes and provides code for a

[I-D.spaghetti-sidrops-rpki-rsc] describes and provides code for a

Cryptographic Message Syntax (CMS) profile for a general purpose

Cryptographic Message Syntax (CMS) profile for a general purpose

listing of checksums (a 'checklist'), for use with the Resource

listing of checksums (a 'checklist'), for use with the Resource

Public Key Infrastructure (RPKI). It provides usable, albeit

Public Key Infrastructure (RPKI). It provides usable, albeit

complex, code to sign geofeed files.

complex, code to sign geofeed files.

[I-D.ietf-sidrops-rpki-rta] describes a Cryptographic Message Syntax

[I-D.ietf-sidrops-rpki-rta] describes a Cryptographic Message Syntax

(CMS) profile for a general purpose Resource Tagged Attestation (RTA)

(CMS) profile for a general purpose Resource Tagged Attestation (RTA)

based on the RPKI. While this is expected to become applicable in

based on the RPKI. While this is expected to become applicable in

the long run, for the purposes of this document, a self-signed root

the long run, for the purposes of this document, a self-signed root

skipping to change at page 6, line 35 ¶

skipping to change at page 6, line 29 ¶

inetnum: objects. They also provide means of [sub-]assigning IP

inetnum: objects. They also provide means of [sub-]assigning IP

address resources and allowing the assignee to create whois data,

address resources and allowing the assignee to create whois data,

including inetnum: objects, and thereby referring to geofeed files.

including inetnum: objects, and thereby referring to geofeed files.

The geofeed files SHOULD be published over and fetched using https

The geofeed files SHOULD be published over and fetched using https

[RFC8446].

[RFC8446].

When using data from a geofeed file, one MUST ignore data outside of

When using data from a geofeed file, one MUST ignore data outside of

the referring inetnum: object's inetnum: attribute address range.

the referring inetnum: object's inetnum: attribute address range.

If and only if the geofeed file is not signed per Section 4, then

Iff the geofeed file is not signed per Section 4, then multiple

multiple inetnum: objects MAY refer to the same geofeed file, and the

inetnum: objects MAY refer to the same geofeed file, and the consumer

consumer MUST use only geofeed lines where the prefix is covered by

MUST use only geofeed lines where the prefix is covered by the

the address range of the inetnum: object they have followed.

address range of the inetnum: object they have followed.

To minimize the load on RIR whois [RFC3912] services, use of the

To minimize the load on RIR whois [RFC3912] services, use of the

RIR's FTP [RFC0959] services SHOULD be the preferred access. This

RIR's FTP [RFC0959] services SHOULD be the preferred access. This

also provides bulk access instead of fetching with tweezers.

also provides bulk access instead of fetching with a tweezers.

Currently, geolocation providers have bulk whois data access at all

Currently, geolocation providers have bulk whois data access at all

the RIRs. An anonymized version of such data is openly available for

the RIRs. An anonymized version of such data is openly available for

all RIRs except ARIN, which requires an authorization. However, for

all RIRs except ARIN, which requires an authorization. However, for

users without such authorization the same result can be achieved with

users without such authorization the same result can be achieved with

extra RDAP effort. There is open source code to pass over such data

extra RDAP effort. There is open source code to pass over such data

across all RIRs, collect all geofeed references, and process them

across all RIRs, collect all geofeed references, and process them

[geofeed-finder].

[geofeed-finder].

An entity fetching geofeed data using these mechanisms MUST NOT do

An entity fetching geofeed data using these mechanisms MUST NOT do

frequent real-time look-ups to prevent load on RPSL and geofeed

frequent real-time look-ups to prevent load on RPSL and geofeed

servers. [RFC8805] Section 3.4 suggests use of the [RFC7234] HTTP

servers. [RFC8805] Section 3.4 suggests use of the [RFC7234] HTTP

Expires Caching Header to signal when geofeed data should be

Expires Caching Header to signal when geofeed data should be

refetched. As the data change very infrequently, in the absence of

refetched. As the data change very infrequently, in the absence of

such an HTTP Header signal, collectors MUST NOT fetch more frequently

such an HTTP Header signal, collectors MUST NOT fetch more frequently

than weekly. It would be polite not to fetch at magic times such as

than weekly. It would be wise not to fetch at magic times such as

midnight UTC, the first of the month, etc., because too many others

midnight UTC, the first of the month, etc., because too many others

are likely to do the same.

are likely to do the same.

6. Security Considerations

6. Security Considerations

It is generally prudent for a consumer of geofeed data to also use

It would be generally prudent for a consumer of geofeed data to also

other sources to cross-validate the data. All of the Security

use other sources to cross-validate the data. All of the Security

Considerations of [RFC8805] apply here as well.

Considerations of [RFC8805] apply here as well.

As mentioned in Section 4, many RPSL repositories have weak if any

As mentioned in Section 4, many RPSL repositories have weak if any

authentication. This allows spoofing of inetnum: objects pointing to

authentication. This would allow spoofing of inetnum: objects

malicious geofeed files. Section 4 suggests an unfortunately complex

pointing to malicious geofeed files. Section 4 suggests an

method for stronger authentication based on the RPKI.

unfortunately complex method for stronger authentication based on the

RPKI.

If an inetnum: for a wide prefix (e.g. a /16) points to an RPKI-

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

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

equal or narrower (e.g. a /24) inetnum: in a whois registry which has

weak authorization.

weak authorization.

The RPSL providers have had to throttle fetching from their servers

The RPSL providers have had to throttle fetching from their servers

due to too-frequent queries. Usually they throttle by the querying

due to too-frequent queries. Usually they throttle by the querying

IP address or block. Similar defenses will likely need to be

IP address or block. Similar defenses will likely need to be

deployed by geofeed file servers.

deployed by geofeed file servers.

skipping to change at page 8, line 37 ¶

skipping to change at page 8, line 32 ¶

<https://www.rfc-editor.org/info/rfc4012>.

<https://www.rfc-editor.org/info/rfc4012>.

[RFC5485] Housley, R., "Digital Signatures on Internet-Draft

[RFC5485] Housley, R., "Digital Signatures on Internet-Draft

Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009,

Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009,

<https://www.rfc-editor.org/info/rfc5485>.

<https://www.rfc-editor.org/info/rfc5485>.

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,

RFC 5652, DOI 10.17487/RFC5652, September 2009,

RFC 5652, DOI 10.17487/RFC5652, September 2009,

<https://www.rfc-editor.org/info/rfc5652>.

<https://www.rfc-editor.org/info/rfc5652>.

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for

Resource Certificate Repository Structure", RFC 6481,

DOI 10.17487/RFC6481, February 2012,

<https://www.rfc-editor.org/info/rfc6481>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC

2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

May 2017, <https://www.rfc-editor.org/info/rfc8174>.

May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol

Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,

Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,

<https://www.rfc-editor.org/info/rfc8446>.

<https://www.rfc-editor.org/info/rfc8446>.

[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.

[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.

Kumari, "A Format for Self-Published IP Geolocation

Kumari, "A Format for Self-Published IP Geolocation

skipping to change at page 9, line 24 ¶

skipping to change at page 9, line 13 ¶

<https://github.com/massimocandela/geofeed-finder>.

<https://github.com/massimocandela/geofeed-finder>.

[I-D.ietf-sidrops-rpki-rta]

[I-D.ietf-sidrops-rpki-rta]

Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T.,

Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T.,

and M. Hoffmann, "A profile for Resource Tagged

and M. Hoffmann, "A profile for Resource Tagged

Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work

Attestations (RTAs)", draft-ietf-sidrops-rpki-rta-00 (work

in progress), January 2021.

in progress), January 2021.

[I-D.spaghetti-sidrops-rpki-rsc]

[I-D.spaghetti-sidrops-rpki-rsc]

Snijders, J., "RPKI Signed Checklists", draft-spaghetti-

Snijders, J., "RPKI Signed Checklists", draft-spaghetti-

sidrops-rpki-rsc-03 (work in progress), February 2021.

sidrops-rpki-rsc-02 (work in progress), February 2021.

[INET6NUM]

[INET6NUM]

RIPE, "Description of the INET6NUM Object",

RIPE, "Description of the INET6NUM Object",

<https://www.ripe.net/manage-ips-and-

<https://www.ripe.net/manage-ips-and-

asns/db/support/documentation/ripe-database-documentation/

asns/db/support/documentation/ripe-database-documentation/

rpsl-object-types/4-2-descriptions-of-primary-

rpsl-object-types/4-2-descriptions-of-primary-

objects/4-2-3-description-of-the-inet6num-object>.

objects/4-2-3-description-of-the-inet6num-object>.

[INETNUM] RIPE, "Description of the INETNUM Object",

[INETNUM] RIPE, "Description of the INETNUM Object",

<https://www.ripe.net/manage-ips-and-

<https://www.ripe.net/manage-ips-and-

End of changes. 32 change blocks.

85 lines changed or deleted

73 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

---

From: Russ Housley <[email-masked]>
Date: Mon, 12 Apr 2021 17:47:07 -0400

Responding to just two places where Randy handed off to me ...

> russ, how do you want to handle?

This is really about line endings, but it would probably be best to assign a content type for UTF8 Test with CRLF.

> ok.  russ?  maybe 'authenticating'?

How about: ... optional signature, which authenticates the data when present.

Russ

---

From: Randy Bush <[email-masked]>
Date: Mon, 12 Apr 2021 16:33:06 -0700

> This is really about line endings, but it would probably be best to
> assign a content type for UTF8 Test with CRLF.

yuchh.  send text, if you would please.

> How about: ... optional signature, which authenticates the data when

        This document also suggests optional signature, which
        authenticates the data when present, for geofeed files to
        provide stronger authenticity to the data.

randy

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 13 Apr 2021 11:11:40 +0000

Hi Randy,

Thanks.  Please see inline ...

> -----Original Message-----
> From: Randy Bush <[email-masked]>
> Sent: 12 April 2021 22:37
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: Ops Area WG <[email-masked]>; draft-ietf-opsawg-finding-
> [email-masked]
> Subject: Re: AD review of draft-ietf-opsawg-finding-geofeeds-04
> 
> hi rob et alia,
> 
[RW] 

No problem.  Sorry, it was delayed.

> see diff.  a lot of 8805 refs sprinkled in before the word 'geofeed
[RW] 

So, solely for my understanding, if 8805 was updated in an incompatible way (e.g., a different format), then a separate "geofeed" attribute  would be used, e.g., "geofeed2:", or the like?

This makes me question whether this comment in section 4 is valid/correct: "Until [RFC8805] is updated to formally define such an appendix".  My understanding is that this couldn't be done without either breaking clients, or requiring new attribute names?

> this is why 2275 and 4012 are normative and the refs to ripe docs are
[RW] 

RFC 2275 doesn't explain the hierarchy of INETNUM entries, and the one reference that does explain it is not a normative reference.  I.e., I think that you need to add a couple of sentences to explain the hierarchy so that you don't need the normative references to RIPE.

> the change.  sense of humor declines in the ietf.
[RW] 

Yes, lack of humour make me sad.

I'm happy for you to try and get "utterly awesome (i.e., practical but slightly complex)" through instead, but if you get push back then you're on your own ;-)

> and we are codifying the attribute name in this document.
[RW] 

Okay.

> getting creative, at least along this dimension.
[RW] 

Are they getting creative along other dimensions?  Who controls this definition,
and are they okay with the IETF constraining the definition this way?  I.e.,
is it possible to get the "irr folk" to agree that they are happy with what
is being proposed here?

> hacked to say then ignore all
[RW] 
Okay.

> taken to invalidate the american language.
[RW] 

I'll pass on the 2119 language debate rathole.

> document.  i have hacked to ref both.
[RW] 

As above, I think that this document needs to be say more about the hierarchy
of inetnums: so that it can avoid needing a normative reference, which seems
wise to avoid.

>     in which P has been sub-divided into one or more longer prefixes.
[RW] 

Thanks.

> i doubt they want to spend time on a bis.
[RW] 

Ack.

> 	covered by the range of the inetnum:.
[RW] 

This looks plausible to me, but don't have the expertise to know.  I assume
that one of the authors will speak up if this is not right.

> 	CIDR prefix boundaries, while those of the CSV lines in the
[RW] 
Okay.

> shall i also s/i.e./id est/ etc?
[RW] 

No need.  I don't think that iff is well known enough, so better to be explicit.

Thanks,
Rob

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Apr 2021 10:11:06 -0400

> On Apr 12, 2021, at 7:33 PM, Randy Bush <[email-masked]> wrote:
> 

Actually, I went back to the I-D, and I withdraw my suggestions.

This I-D already defines a new content type: id-ct-geofeedCSVwithCRLF.

This new content type already handles the situation as I was thinking.  It could be more clear, and I suggest:

OLD:

NEW:

   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.  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.  Thus, a blank line is represented solely by
   the <CRLF> sequence.  Other nonprintable characters, such as
   backspace, are not expected.  For robustness, any nonprintable
   characters MUST NOT be changed by canonicalization.  Trailing
   blank lines MUST NOT appear at the end of the file.  That is, the
   file must not end with multiple consecutive <CRLF> sequences.
   Any end-of-file marker used by an operating system is not considered
   to be part of the file content.  When present, such end-of-file
   markers MUST NOT be processed by the digital signature algorithm.

   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 BASE64 encoded and line wrapped to 72 or fewer
   characters.

END

Russ

---

From: Randy Bush <[email-masked]>
Date: Tue, 13 Apr 2021 09:11:29 -0700

> This I-D already defines a new content type: id-ct-geofeedCSVwithCRLF.

clearly without enough words :)

>    which is then BASE64 encoded and line wrapped to 72 or fewer

done

thanks!

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 13 Apr 2021 10:44:25 -0700

mornin rob,

new diff attached

> So, solely for my understanding, if 8805 was updated in an
> incompatible way

then it would not be 8805.  it would not be a geofeed file.  so the
kiddies then can have fun with a complete do-over and write their own
finding-blarffles draft.

> This makes me question whether this comment in section 4 is
> valid/correct: "Until [RFC8805] is updated to formally define such an
> appendix".  My understanding is that this couldn't be done without
> either breaking clients, or requiring new attribute names?

point, how about

Unless <xref target="RFC8805"/> is modified to formally define

> RFC 2275 doesn't explain the hierarchy of INETNUM entries

yup.  which is why the informative INETNUM refs were left.

> I think that you need to add a couple of sentences to explain the
> hierarchy so that you don't need the normative references to RIPE.

        The Routing Policy Specification Language (RPSL), <xref
        target="RFC4012"/> used by the Regional Internet Registries
        (RIRs) specifies inetnum: database objects.  Each of these
        objects describes an IP address range and its attributes.  The
        inetnum: objects form a hierarchy ordered on the address space.

> I'm happy for you to try and get "utterly awesome (i.e., practical but
> slightly complex)" through instead, but if you get push back then
> you're on your own ;-)

some day i can tell you of jari pushing me to write the AplusP document
and then not backing me when the anti-nat vigilantes attacked.

>> let's see how this goes.  the irr folk working on this do not seem to
>> be getting creative, at least along this dimension.
> 
> Are they getting creative along other dimensions?  Who controls this
> definition, and are they okay with the IETF constraining the
> definition this way?  I.e., is it possible to get the "irr folk" to
> agree that they are happy with what is being proposed here?

they are.  the ripe community is still old school cooperative.  of
course they have to blah blah about it for a few months; but the end
will be what we need.  and then the other rirs, excepting arin of
course, will follow.  warren, massimo, and i are part of the ripe
community.  not to worry.

> This looks plausible to me, but don't have the expertise to know.  I
> assume that one of the authors will speak up if this is not right.

russ has not whacked me.  yet.

> No need.  I don't think that iff is well known enough

i think this says a sad bit about computer science and the ietf

randy

< draft-ietf-opsawg-finding-geofeeds-04.txt

draft-ietf-opsawg-finding-geofeeds.txt >

Expires: October 15, 2021 NTT

W. Kumari

W. Kumari

Google

Google

R. Housley

R. Housley

Vigil Security

Vigil Security

February 19, 2021

April 13, 2021

Abstract

Abstract

Status of This Memo

Status of This Memo

This Internet-Draft will expire on October 15, 2021.

Copyright Notice

Copyright Notice

carefully, as they describe your rights and restrictions with respect

carefully, as they describe your rights and restrictions with respect

to this document. Code Components extracted from this document must

to this document. Code Components extracted from this document must

include Simplified BSD License text as described in Section 4.e of

include Simplified BSD License text as described in Section 4.e of

the Trust Legal Provisions and are provided without warranty as

the Trust Legal Provisions and are provided without warranty as

described in the Simplified BSD License.

described in the Simplified BSD License.

Table of Contents

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3

4. Authenticating Geofeed Data . . . . . . . . . . . . . . . . . 5

7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8

8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19

1. Introduction

1. Introduction

Specification Language (RPSL) [RFC4012] inetnum: class to refer

specifically to geofeed data CSV files, and how to prudently use

them. In all places inetnum: is used, inet6num: should also be

assumed [RFC4012].

The reader may find [INETNUM] and [INET6NUM] informative, and

data is also defined.

certainly more verbose, descriptions of the inetnum: database

classes.

An optional, utterly awesome but slightly complex, means for

capitals, as shown here.

capitals, as shown here.

2. Geofeed Files

2. Geofeed Files

geographic locale(s).

geographic locale(s).

are represented, etc.

This document also suggests optional signature, which authenticates

the data when present, for geofeed files to provide stronger

authenticity to the data.

3. inetnum: Class

3. inetnum: Class

The Routing Policy Specification Language (RPSL), [RFC4012] used by

the Regional Internet Registries (RIRs) specifies inetnum: database

classs. Each of these objects describes an IP address range and its

its attributes.

attributes. The inetnum: objects form a hierarchy ordered on the

address space.

HTTPS URL of a geofeed file. The format of the inetnum: geofeed

attribute MUST be as in this example, "remarks: Geofeed" followed by

a URL which will vary, but MUST refer only to a single [RFC8805]

geofeed file.

is defined.

If a geofeed CSV file describes multiple disjoint ranges of IP

address space, there are likely to be geofeed references from

multiple inetnum: objects.

As inetnum: objects form a hierarchy, Geofeed references SHOULD be at

the lowest applicable inetnum: object covering the relevant prefixes

in the referenced geofeed file. When fetching, the most specific

preferred.

preferred.

fair number of them.

and the <CRLF> sequence MUST be used to denote the end of a line of

text. Trailing space characters MUST NOT appear on a line of text.

characters.

That is, the space or tab characters must not be followed by the

<CRLF> sequence. Thus, a blank line is represented solely by the

<CRLF> sequence. Other nonprintable characters, such as backspace,

are not expected. For robustness, any nonprintable characters MUST

NOT be changed by canonicalization. Trailing blank lines MUST NOT

appear at the end of the file. That is, the file must not end with

multiple consecutive <CRLF> sequences. Any end-of-file marker used

by an operating system is not considered to be part of the file

content. When present, such end-of-file markers MUST NOT be

processed by the digital signature algorithm. 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 BASE64 encoded and

line wrapped to 72 or fewer characters.

range of the inetnum:.

certificates field.

needed public key.

Unless [RFC8805] is modified to formally define such an appendix, it

...

...

skipping to change at page 7, line 14 ¶

[RFC8446].

[RFC8446].

[geofeed-finder].

[geofeed-finder].

RPKI.

weak authorization.

weak authorization.

skipping to change at page 7, line 51 ¶

skipping to change at page 8, line 36 ¶

Thanks to Rob Austein for CMS and detached signature clue. George

Thanks to Rob Austein for CMS and detached signature clue. George

Michaelson for the first, and a substantial, external review. Erik

Michaelson for the first, and a substantial, external review. Erik

Kline who was too shy to agree to co-authorship. Additionally, we

Kline who was too shy to agree to co-authorship. Additionally, we

express our gratitude to early implementors, including Menno

express our gratitude to early implementors, including Menno

Schepers, Flavio Luciani, Eric Dugas, Job Snijders who provided

Schepers, Flavio Luciani, Eric Dugas, Job Snijders who provided

running code, and Kevin Pack. Also to geolocation providers that are

running code, and Kevin Pack. Also to geolocation providers that are

consuming geofeeds with this described solution, Jonathan Kosgei

consuming geofeeds with this described solution, Jonathan Kosgei

(ipdata.co), Ben Dowling (ipinfo.io), and Pol Nisenblat

(ipdata.co), Ben Dowling (ipinfo.io), and Pol Nisenblat

(bigdatacloud.com). For reviews, we thank Adrian Farrel, Antonio

(bigdatacloud.com). For reviews, we thank Adrian Farrel, Antonio

Prado, and George Michaelson, the document shepherd.

Prado, Rob Wilton, and George Michaelson, the document shepherd.

9. References

9. References

9.1. Normative References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC 2119,

Requirement Levels", BCP 14, RFC 2119,

DOI 10.17487/RFC2119, March 1997,

DOI 10.17487/RFC2119, March 1997,

<https://www.rfc-editor.org/info/rfc2119>.

<https://www.rfc-editor.org/info/rfc2119>.

[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO

Murphy, "Routing Policy System Security", RFC 2725,

10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November

DOI 10.17487/RFC2725, December 1999,

2003, <https://www.rfc-editor.org/info/rfc3629>.

<https://www.rfc-editor.org/info/rfc2725>.

[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,

[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,

"Routing Policy Specification Language next generation

"Routing Policy Specification Language next generation

(RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005,

(RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005,

skipping to change at page 9, line 50 ¶

[INET6NUM]

[INET6NUM]

End of changes. 41 change blocks.

90 lines changed or deleted

125 lines changed or added

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 19 Apr 2021 13:25:34 +0000

Hi Randy,

Inline ...

> Sent: 13 April 2021 18:44
[RW] 

My comment was less about what gets written in the documents, and more about how this update would actually be done in practice.  E.g., updating 8805 to indicate a new section would presumably break any existing clients expecting to fetch a regular CSV file via the "geofeed: or "remaks: geofeed" attributes?

I.e., it seems that either 8805 would have to be updated in backwards compatible way, and it looks like adding such an appendix wouldn't be backwards compatible (c.f., RFC 8805 section 7), or all clients would have to be updated before the publishing format is changed, or it would need new geofeed attribute names to publish the different versions of the geofeed data at the same time.

How wedded are you to that text?  Perhaps it would be simpler to just delete the "Until [RFC8805] is updated to formally define such an appendix" text and just say that the signature is always predicated by '#' comments?

[RW] 

Ack.

[RW] 

Okay.  Thanks for confirming.

[RW] 

To be fair, after a quick grep of RFCs, it isn't that 'iff' isn't used at all, but it is quite rare:
736 occurrences of "if and only if" vs 12 for "iff".

Hence, I think that using it would be iffy. ;-)

Rob

---

From: Randy Bush <[email-masked]>
Date: Mon, 19 Apr 2021 06:41:21 -0700

> My comment was less about what gets written in the documents, and more
> about how this update would actually be done in practice.  E.g.,
> updating 8805 to indicate a new section would presumably break any
> existing clients expecting to fetch a regular CSV file via the
> "geofeed: or "remaks: geofeed" attributes?
> 
> I.e., it seems that either 8805 would have to be updated in backwards
> compatible way, and it looks like adding such an appendix wouldn't be
> backwards compatible (c.f., RFC 8805 section 7), or all clients would
> have to be updated before the publishing format is changed, or it
> would need new geofeed attribute names to publish the different
> versions of the geofeed data at the same time.
> 
> How wedded are you to that text?  Perhaps it would be simpler to just
> delete the "Until [RFC8805] is updated to formally define such an
> appendix" text and just say that the signature is always predicated by
> '#' comments?

sorry for not understanding your point.  there is no backward compatible
way forward for 8805.  so i have hacked as you suggest

        The appendix MUST be 'hidden' as a series of "#" comments at the
        end of the geofeed file.  The following is a cryptographically
        incorrect, albeit simple example.  A correct and full example is
        in <xref target="example"/>.

randy

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 19 Apr 2021 13:58:57 +0000

Hi Randy,

Thanks for the updates.

Just waiting for confirmation from you/Warren that you are okay with my doc status plan and then I'll send it to IETF LC.

Thanks,
Rob

> Sent: 19 April 2021 14:41

---

From: Russ Housley <[email-masked]>
Date: Mon, 19 Apr 2021 10:40:01 -0400

> How wedded are you to that text?  Perhaps it would be simpler to just delete the "Until [RFC8805] is updated to formally define such an appendix" text and just say that the signature is always pred…

The whole reason that the signature is put in comments is so that they can be ignored by clients that only understand RFC 8805.

> One point of clarification is that 8805 was published as Informational on the RSE, but I'm not sure that really matters.

I think the there just needs to be a downref called out in the IETF Last Call.

Russ

---

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Apr 2021 10:44:13 -0400

On Mon, Apr 19, 2021 at 9:59 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> Hi Randy,
>
> Thanks for the updates.
>
> Just waiting for confirmation from you/Warren that you are okay with my
> doc status plan and then I'll send it to IETF LC.
>

Yup, completely...

(and apologies for the delay, I've been somewhat under the weather for the
past 3 weeks...)
W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 20 Apr 2021 14:59:17 +0000

Warren, George,

Thanks for confirming.

I’ve requested IETF LC on -06.

Randy, authors, thanks for your work on this document, and responding to comments quickly.
George, thank you for your comprehensive doc shepherd review.
WG, thanks for all your reviews and contributions to this document.

Regards,
Rob

From: Warren Kumari <[email-masked]>
Sent: 20 April 2021 15:44
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Randy Bush <[email-masked]>; Ops Area WG <[email-masked]>; [email-masked]
Subject: Re: AD review of draft-ietf-opsawg-finding-geofeeds-04

On Mon, Apr 19, 2021 at 9:59 AM Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Randy,

Thanks for the updates.

Yup, completely...

(and apologies for the delay, I've been somewhat under the weather for the past 3 weeks...)
W

Thanks,
Rob

> From: Randy Bush <[email-masked]<mailto:[email-masked]>>
> To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
> Cc: Ops Area WG <[email-masked]<mailto:[email-masked]>>; draft-ietf-opsawg-finding-
> [email-masked]<mailto:[email-masked]>