On Fri, Sep 11, 2020 at 11:02 PM Randy Bush <ra...@psg.com> 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/> >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
