Re: [OPSAWG] Finding and Using Geofeed Data

[Erik Kline <[e-mail]>]

On Fri, Sep 11, 2020 at 11:02 PM Randy Bush <[e-mail]> wrote:

> thanks for review!  proposed diff attached.
>

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

>   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.
>
> >     [a] the source of the geofeed claims is authoritative to make said
> >         claims for the contained prefixes, and
>
> iff you trust the rpki crypto chain
>
> >     [b] the correctness of the claims themselves (i.e. that the location
> of
> >         2001:db8::/32 really is "Shire, Middle Earth").
>
> above my pay grade
>
> 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

>   The text from section 4 provides a suggestion: perhaps replace
> >   "authenticate" with "verify the authority of", or some such
> >   formulation?
>
> hmmmm.  hacked a bit.
>
> > [ 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.
>
> ok
>
> > [[ nits ]]
>
> thanks!
>
> randy
>
>
> < <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].
> 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 ¶* <#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
> 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 ¶* <#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
> -----------------------------------------------------------------
> -----------------------------------------------------------------
>  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/
> <http://www.tools.ietf.org/tools/rfcdiff/>
>