Subject: Re: [OPSAWG] Finding and Using Geofeed Data

From: Randy Bush <[email-masked]>
Date: Fri, 11 Sep 2020 13:48:12 -0700

would appreciate review prior to calling for wg adoption

thanks

randy

A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-02.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:		draft-ymbk-opsawg-finding-geofeeds
Revision:	02
Title:		Finding and Using Geofeed Data
Document date:	2020-09-11
Group:		Individual Submission
Pages:		16
URL:            https://www.ietf.org/id/draft-ymbk-opsawg-finding-geofeeds-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ymbk-opsawg-finding-geofeeds/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds
Htmlized:       https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ymbk-opsawg-finding-geofeeds-02

Abstract:
   This document describes how to find and authenticate geofeed data.

---

From: Erik Kline <[email-masked]>
Date: Fri, 11 Sep 2020 22:26:05 -0700

On Fri, Sep 11, 2020 at 1:48 PM Randy Bush <[email-masked]> wrote:

> URL:
> https://www.ietf.org/id/draft-ymbk-opsawg-finding-geofeeds-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ymbk-opsawg-finding-geofeeds/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds
> Htmlized:
> https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ymbk-opsawg-finding-geofeeds-02
>
> Abstract:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

Probably I should have noticed this before and/or just sent a pull request,
but for the sake of discussion, here are some random thoughts.

[[ questions ]]

[ section 4 ]

* Based on RFC 5485 section 2.2, I assume that any comments in the geofeed
  prior to having the CMS appended are included in the canonicalized text?

      ##
      # Auto-generated by shirebot; do not edit.
      ##
      # This conference is in the Prancing Pony.
      2001:db8:1::/48,Shire,West Farthing,Hobbiton,
      2001:db8:2::/48,Shire,East Farthing,Frogmorton, # NOC is by the
stables

  If the comments change, the signature changes?  That seems fine to me, I
  just wanted to be sure.

[[ comments ]]

[ abstract ]

* "authenticate geofeed data"

  There are two things that need authenticating or verifying when it comes
  to geofeeds:

    [a] the source of the geofeed claims is authoritative to make said
        claims for the contained prefixes, and

    [b] the correctness of the claims themselves (i.e. that the location of
        2001:db8::/32 really is "Shire, Middle Earth").

  This document nicely addresses "a" (whereas "b" is necessarily left as an
  exercise for the consumer).

  The text from section 4 provides a suggestion: perhaps replace
  "authenticate" with "verify the authority of", or some such formulation?

[ section 1 ]

* Probably the intro should hint at the authentication awesomeness contained
  within.  I think, actually, the last paragraph of section 2 can just be
  relocated to the end of this section and it will flow well.

[[ nits ]]

[ section 5 ]

* s/objectss/objects/

[ section 6 ]

* "an sadly"

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 Sep 2020 23:01:57 -0700

thanks for review!  proposed diff attached.

>   If the comments change, the signature changes?

yep.  otherwise vast complexity lurks.  but is there a text change you
want?  i may be naïve expecting that "a digest of the main body of the
file" is sufficient.

>         claims for the contained prefixes, and

iff you trust the rpki crypto chain

>         2001:db8::/32 really is "Shire, Middle Earth").

above my pay grade

do you have suggested text?

>   "authenticate" with "verify the authority of", or some such

hmmmm.  hacked a bit.

>   relocated to the end of this section and it will flow well.

ok

> [[ nits ]]

thanks!

randy

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

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

skipping to change at page 2, line 11 ¶

skipping to change at page 2, line 11 ¶

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

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

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

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

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

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

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

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

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

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

6. Security Considerations . . . . . . . . . . . . . . . . . . . 5

6. Security Considerations . . . . . . . . . . . . . . . . . . . 5

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

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

8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5

8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6

9. Normative References . . . . . . . . . . . . . . . . . . . . 5

9. Normative References . . . . . . . . . . . . . . . . . . . . 6

Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 7

Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 7

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15

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) [RFC2622] inetnum: class [INETNUM] to

Specification Language (RPSL) [RFC2622] inetnum: class [INETNUM] to

refer to geofeed data, and how to prudently use them. In all places

refer to geofeed data, and how to prudently use them. In all places

inetnum: is used, inet6num: should also be assumed [INET6NUM].

inetnum: is used, inet6num: should also be assumed [INET6NUM].

An optional, but utterly awesome, means for authenticating geofeed

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

skipping to change at page 3, line 45 ¶

skipping to change at page 3, line 51 ¶

inetnum: object with a geofeed reference MUST be used.

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.

4. Authenticating Geofeed Data

4. Authenticating Geofeed Data

The question arises on whether a particular geofeed data set is

The question arises on whether a particular geofeed data set is

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

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

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

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

geofeed file provides some authentication. Unfortunately the RPSL in

geofeed file provides some assurance. Unfortunately the RPSL in many

many repositories is weakly authenticated at best.

repositories is weakly authenticated at best.

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

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

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

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

the private key of the relevant RPKI certificate for the covering

the private key of the relevant RPKI certificate for the covering

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

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

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

certificate with the 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)

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

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

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

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

characters.

characters.

skipping to change at page 5, line 13 ¶

skipping to change at page 5, line 23 ¶

# END Signature: 192.0.2.0/24

# END Signature: 192.0.2.0/24

5. Operational Considerations

5. Operational Considerations

Geofeed data SHOULD be fetched using https [RFC2818].

Geofeed data SHOULD be fetched using https [RFC2818].

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 inetnum: object's inetnum: attribute's address range.

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

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

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

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

An entity fetching geofeed data through these mechanisms MUST NOT do

An entity fetching geofeed data through these mechanisms MUST NOT do

frequent real-time look-ups to prevent load on RPSL servers. And do

frequent real-time look-ups to prevent load on RPSL servers. And do

not fetch at midnight, because everyone else may.

not fetch at midnight, because everyone else may.

6. Security Considerations

6. Security Considerations

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

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

use 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 would allow spoofing of inetnum: objects

authentication. This would allow spoofing of inetnum: objects

pointing to malicious geofeed files. Section 4 suggests an sadly

pointing to malicious geofeed files. Section 4 suggests a sadly

complex method for stronger authentication based on the RPKI.

complex method for stronger authentication based on the RPKI.

7. IANA Considerations

7. IANA Considerations

IANA is asked to register object identifiers for one content type in

IANA is asked to register object identifiers for one content type in

the "SMI Security for S/MIME CMS Content Type

the "SMI Security for S/MIME CMS Content Type

(1.2.840.113549.1.9.16.1)" registry as follows:

(1.2.840.113549.1.9.16.1)" registry as follows:

Description OID Specification

Description OID Specification

-----------------------------------------------------------------

-----------------------------------------------------------------

End of changes. 7 change blocks.

12 lines changed or deleted

15 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: Michael Richardson <[email-masked]>
Date: Sat, 12 Sep 2020 19:04:00 -0400

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

This cynical comment jumped out at me.
It seems that you don't have a lot of confidence that the key will be easily used.

As I understand it, you are not creating the geofeed: attribute, but instead
shoving a URL into a "remark".  (Wasn't JCL afflicted by endless hacks like this?)
(I don't see an IANA Considerations in RFC2622... so many you have to Updates?)

I gather from my quick reading that the geofeed data should be signed by the
same RPKI key, and that such keys are rather high value.
Should they be signing geofeed data?

I understand RFC8805 to be a simple CSV format.
One thought I have is to just stuff that into the "remark" directly.
I think that each inetnum:/inet6num: entry will be unique per prefix.
Maybe the geography is not 1:1, particularly with larger IPv6 allocations.

But, if the HTTP(S) indirection via URL requires a signature from the same
key as the RPSL signature, then why not just put a SHA256 hash into the
remark, eliminating the need to find the private key?
That way, the same person with access signs both?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Erik Kline <[email-masked]>
Date: Sat, 12 Sep 2020 16:44:40 -0700

> thanks for review!  proposed diff attached.

Seems like a fair next step.  =)  I'll see about putting together a PR, too.

> do you have suggested text?

No, I don't and I don't think we need any.  I just wanted to highlight that
there're 2 different things that could be "authenticated" -- where geofeeds
are concerned -- and this draft (rightly) only deals with one of them.
Probably not worth text unless it turns out folks find it confusing.

Thanks

> < <http:///rfcdiff?url2=draft-ymbk-opsawg-finding-geofeeds.txt>
> draft-ymbk-opsawg-finding-geofeeds.txt
> <https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds.txt>
> draft-ymbk-opsawg-finding-geofeeds.txt
> <https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds.txt> >
> <http:///rfcdiff?url1=draft-ymbk-opsawg-finding-geofeeds.txt>
> skipping to change at* page 2, line 11 ¶* <#m_7593764623018977219_part-1> skipping
> to change at* page 2, line 11 ¶* <#m_7593764623018977219_part-1>
> 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 . . . . . . . . . . . . . . . . . . 2 1.1.
> Requirements Language . . . . . . . . . . . . . . . . . . 2
> 2. Geofeed Files . . . . . . . . . . . . . . . . . . . . . . . . 2 2.
> Geofeed Files . . . . . . . . . . . . . . . . . . . . . . . . 3
> 3. inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 3 3.
> inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 3
> 4. Authenticating Geofeed Data . . . . . . . . . . . . . . . . . 3 4.
> Authenticating Geofeed Data . . . . . . . . . . . . . . . . . 3
> 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 5.
> Operational Considerations . . . . . . . . . . . . . . . . . 5
> 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6.
> Security Considerations . . . . . . . . . . . . . . . . . . . 5
> 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7.
> IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
> 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 8.
> Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
> 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 9.
> Normative References . . . . . . . . . . . . . . . . . . . . 6
> Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 7 Appendix
> A. Example . . . . . . . . . . . . . . . . . . . . . . 7
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors'
> Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
> 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) [RFC2622] inetnum: class [INETNUM] to Specification
> Language (RPSL) [RFC2622] inetnum: class [INETNUM] to
> refer to geofeed data, and how to prudently use them. In all places refer
> to geofeed data, and how to prudently use them. In all places
> inetnum: is used, inet6num: should also be assumed [INET6NUM]. inetnum:
> is used, inet6num: should also be assumed [INET6NUM].
> 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
> skipping to change at* page 3, line 45 ¶* <#m_7593764623018977219_part-2> skipping
> to change at* page 3, line 51 ¶* <#m_7593764623018977219_part-2>
> inetnum: object with a geofeed reference MUST be used. 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.
> 4. Authenticating Geofeed Data 4. Authenticating Geofeed Data
> The question arises on whether a particular geofeed data set is The
> question arises on whether a particular geofeed data set is
> is authoritative in some sense. The inetnum: which points to the authoritative
> in some sense. The inetnum: which points to the
> geofeed file provides some authentication. Unfortunately the RPSL in geofeed
> file provides some assurance. Unfortunately the RPSL in many
> many repositories is weakly authenticated at best. repositories is weakly
> authenticated at best.
> An optional authenticator MAY be appended to a geofeed file. It An
> optional authenticator MAY be appended to a geofeed file. It
> would essentially be a digest of the main body of the file signed by would
> be essentially a digest of the main body of the file signed by
> the private key of the relevant RPKI certificate for the covering the
> private key of the relevant RPKI certificate for the covering
> address range. One needs a format that bundles the relevant RPKI address
> range. One needs a format that bundles the relevant RPKI
> certificate with the signature and the digest of the geofeed text. certificate
> with the 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)
> [RFC3852] would be used to create a detached DER encoded signature [RFC3852]
> would be used to create a detached DER encoded signature
> which is then BASE64 encoded and line wrapped to 72 or fewer which is
> then BASE64 encoded and line wrapped to 72 or fewer
> characters. characters.
> skipping to change at* page 5, line 13 ¶* <#m_7593764623018977219_part-3> skipping
> to change at* page 5, line 23 ¶* <#m_7593764623018977219_part-3>
> # END Signature: 192.0.2.0/24 # END Signature: 192.0.2.0/24
> 5. Operational Considerations 5. Operational Considerations
> Geofeed data SHOULD be fetched using https [RFC2818]. Geofeed data SHOULD
> be fetched using https [RFC2818].
> 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 inetnum: object's inetnum: attribute's address range. the inetnum:
> object's inetnum: attribute's address range.
> Iff the geofeed file is not signed per Section 4, then multiple Iff the
> geofeed file is not signed per Section 4, then multiple
> inetnum: objectss 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.
> An entity fetching geofeed data through these mechanisms MUST NOT do An
> entity fetching geofeed data through these mechanisms MUST NOT do
> frequent real-time look-ups to prevent load on RPSL servers. And do frequent
> real-time look-ups to prevent load on RPSL servers. And do
> not fetch at midnight, because everyone else may. not fetch at midnight,
> because everyone else may.
> 6. Security Considerations 6. Security Considerations
> It would be generally prudent for a consumer of geofeed data to also It
> would be generally prudent for a consumer of geofeed data to also
> use 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 would allow spoofing of inetnum: objects authentication.
> This would allow spoofing of inetnum: objects
> pointing to malicious geofeed files. Section 4 suggests an sadly pointing
> to malicious geofeed files. Section 4 suggests a sadly
> complex method for stronger authentication based on the RPKI. complex
> method for stronger authentication based on the RPKI.
> 7. IANA Considerations 7. IANA Considerations
> IANA is asked to register object identifiers for one content type in IANA
> is asked to register object identifiers for one content type in
> the "SMI Security for S/MIME CMS Content Type the "SMI Security for
> S/MIME CMS Content Type
> (1.2.840.113549.1.9.16.1)" registry as follows: (1.2.840.113549.1.9.16.1)"
> registry as follows:
> Description OID Specification Description OID Specification
> *12 lines changed or deleted* *15 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/
> <http://www.tools.ietf.org/tools/rfcdiff/>
>

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Sep 2020 16:53:15 -0700

> It seems that you don't have a lot of confidence that the key will be

actually, i am hoping that ggm et alia will revive
draft-michaelson-rpki-rta

until then, i am personally not all that concerned about signing.  as
folk start to actually follow this path (and massimo is keeping a list
of those who are), after a while folk may care enough about authenticity
to go through the effort of signing geofeeds.

but we felt it incumbent on us to specify how to do so.

> As I understand it, you are not creating the geofeed: attribute, but
> instead shoving a URL into a "remark".

one thing at a time.  the ietf gave up on specifying rpsl a couple of
decades ago.  a first task i was given as a new ops area director was
to shoot the rps wg.  so we are not attempting to modify rpsl, though
we do suggest how it might be done.

> I don't see an IANA Considerations in RFC2622... so many you have to
> Updates?

let's you and them fight :)

> I gather from my quick reading that the geofeed data should be signed
> by the same RPKI key, and that such keys are rather high value.

got any other congruent authoritative keys?

> One thought I have is to just stuff that into the "remark" directly.

scale issues.  as i just said on nanog

    for some flat fan out last kilometer providers that could be the
    inetnum: object from hell.  there are global providers which segment
    large prefixes over diverse areas.  etc.

    i doubt the rpsl providers would like multi-megabyte inetnum:s.  rpsl
    providers already throttle in defense.

> Maybe the geography is not 1:1, particularly with larger IPv6

it isn't even for ipv4

> But, if the HTTP(S) indirection via URL requires a signature from the
> same key as the RPSL signature

there is no such thing as an rpsl signature.  and i sure as bleep ain't
gonna propose one.

> then why not just put a SHA256 hash into the remark, eliminating the
> need to find the private key?  That way, the same person with access
> signs both?

because, as the draft tries to politely say

    Unfortunately the RPSL in many repositories is weakly authenticated
    at best.

randy

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Sun, 13 Sep 2020 16:19:19 +0000

I just reviewed rev -02.  Other than noticing two ’s’ in “objects” in section 5, I didn’t notice any other issues.

One thing that did stick out to me, though (and I don’t know how to solve it) is when you talk about update frequency in section 5.  Okay, don’t do frequent polls and don’t poll at midnight.  However, in the case of something like the IETF conference network, how would consumers know that this GeoFeed data _is_ likely to change and at a certain periodicity?  The GeoFeed format doesn’t have any parsable way to reflect that.  I don’t know if RPSL does.  Perhaps the remark: could offer some clue as to when one might want to come and retaste?

Joe

> On Sep 11, 2020, at 16:48, Randy Bush <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Sun, 13 Sep 2020 10:22:54 -0700

> I just reviewed rev -02.  Other than noticing two ’s’ in “objects”
> in section 5, I didn’t notice any other issues.

thanks for taking a pass.  objectss corrected, plus a other thinks
erik kline pointed out.  we'll push -03 when there have been changes
of substance.

> One thing that did stick out to me, though (and I don’t know how to
> solve it) is when you talk about update frequency in section 5.  Okay,
> don’t do frequent polls and don’t poll at midnight.  However, in the
> case of something like the IETF conference network, how would
> consumers know that this GeoFeed data _is_ likely to change and at a
> certain periodicity?  The GeoFeed format doesn’t have any parsable way
> to reflect that.  I don’t know if RPSL does.  Perhaps the remark:
> could offer some clue as to when one might want to come and retaste?

i have recently become overly sensitive to this.  i have turned off
rrdp on my rpki CAs because of a DDoS by abusive pollers.  and i may
be driven to just turn off rpki entirely.

i see at least three pieces to the problem

  o what is a reasonable frequency?  imiho, things change very
    infrequently.  the ietf meeting network should be happy with a
    weekly poll.  but, as ggm might say, there is a discussion to be
    had here.

  o could there be a signal on the server side, e.g. an expiry or
    suggested poll frequency in the geofeeds file or in the pointer in
    the rpsl?  for example, massimo is looking at html tags.

  o given the rpki DDoS, will implementors even follow guidelines in
    an RFC?  if we assume not, then we probably should also specify
    a damping mechanism on the service side.  there is a reason rpsl
    servers are strongly damped.  welcome to the tragedy of the
    commons.

folk might have other thoughts.

again, thanks for reading!

randy

---

From: Massimo Candela <[email-masked]>
Date: Sun, 13 Sep 2020 20:09:48 +0200

Hi Joe,

Thanks for your feedback.

>      the rpsl?  for example, massimo is looking at html tags.

What I'm loking at is http cache max-age headers.
Since the geofeed file is served on http(s), that's free to achieve  
(like for any other file).

Ciao,
Massimo

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Sep 2020 14:35:48 -0400

Joe Clarke \(jclarke\) <jclarke=[email-masked]> wrote:
    > case of something like the IETF conference network, how would consumers
    > know that this GeoFeed data _is_ likely to change and at a certain
    > periodicity?  The GeoFeed format doesn’t have any parsable way to
    > reflect that.  I don’t know if RPSL does.  Perhaps the remark: could
    > offer some clue as to when one might want to come and retaste?

Yes, I got the impression that Randy doesn't want to fix the geofeed specification.
If one were to do that, then a TTL on each line, or a notAfter date would work.

The problem with the IETF/etc. conference network isn't that we don't update
things, but that caches don't expire sanely.

---

From: Erik Kline <[email-masked]>
Date: Sun, 13 Sep 2020 22:11:20 -0700

> (like for any other file).

FWIW, we tried to have some HTTP header discussion in 8805:

https://www.rfc-editor.org/rfc/rfc8805.html#name-refreshing-feed-information

The IETF is an example that can be solved with a simple operational
practice that Warren already implements: update the contents of the feed
the day after the conference ends.  This gives everyone ~3 months to learn
the new location from the updated feed.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 14 Sep 2020 12:52:47 +0000

On Sep 14, 2020, at 01:11, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Sep 13, 2020 at 11:10 AM Massimo Candela <[email-masked]<mailto:[email-masked]>> wrote:
Hi Joe,

The IETF is an example that can be solved with a simple operational practice that Warren already implements: update the contents of the feed the day after the conference ends.  This gives everyone ~3 months to learn the new location from the updated feed.

Thanks, Erik.  Yes, that should cover the periodicity.  A reference to that might be a good addition to the ops considerations in your new draft to complement the bit about not polling in real-time.

Joe

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 Sep 2020 10:05:03 -0700

> https://www.rfc-editor.org/rfc/rfc8805.html#name-refreshing-feed-information

        An entity fetching geofeed data using these mechanisms MUST NOT
        do frequent real-time look-ups to prevent load on RPSL and
        geofeed servers.  <xref target="RFC8805"/> Section 3.4 suggests
        use of the <xref target="RFC7234"/> HTTP Expires Cacheing Header
        to signal when geofeed data should be refetched.  As the data
        change very infrequently, in the absense of such an HTTP Header
        signal, collectors MUST NOT fetch more frequently than weekly.
        It would be wise not to fetch at magic times such as midnight
        UCT, the first of the month, etc., because too many others are
        likely to do the same.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 14 Sep 2020 17:08:43 +0000

> On Sep 14, 2020, at 13:05, Randy Bush <[email-masked]> wrote:
> 

This text works for me.  But “UTC” is more canonical than UCT.

Joe

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 Sep 2020 10:09:58 -0700

> But “UTC” is more canonical than UCT.

<blush>

---

From: Owen DeLong <[email-masked]>
Date: Sun, 27 Sep 2020 22:49:44 -0700

I personally think it might be reasonable to add a standard for extended communities in BGP to represent prefix geo-data, but in general, I think it is preferable to discourage the idea that IP and physical addresses have any rational correlation whatsoever, since they really don’t and many of the instances I’ve encountered have wrong assumptions and sloppy thinking applied to create poor user experiences and those are the good ones.

Owen

> On Aug 31, 2020, at 1:45 PM, Massimo Candela <[email-masked]> wrote:
> 
> Hi all,
> 
> IP geolocation is often essential but hard to correct when wrong, mostly
> due to the lack of a unified way to provide geolocation data.
> Internet operators may wish to publish the location of some
> of their IP addresses. RFC 8805 (geofeeds) allows network operators
> to publish "a mapping of IP address prefixes to simplified geolocation".
> Unfortunately it doesn't provide any mechanism to actually *find* the
> geofeed files.
> 
> Section 8  ("Finding Self-Published IP Geolocation Feeds") lists this
> as an open problem, and that:
>   Ad hoc mechanisms, while useful for early experimentation by
>   producers and consumers, are unlikely to be adequate for long-term,
>   widespread use by multiple parties.  Future versions of any such
>   self-published geolocation feed mechanism SHOULD address scalability
>   concerns by defining a means for automated discovery and verification
>   of operational authority of advertised prefixes.
> 
> This document provides a (simple) solution to this issue by describing
> a way to include a URL to a geofeed file in an inetnum object, and
> how to prudently consume such geolocation data.
> 
> Draft: https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds-00
> 
> Please, provide your feedback.
> 
> Have a great day!
> 
> Ciao,
> Massimo
>