Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)

[Randy Bush <[e-mail]>]

thanks for review, paul

> #1 document track
> 
> The document is Standards Track, and so are the docs is
> Obsoletes/Updates ([RFC2725] and [RFC4012]), but the document also
> claims "change control effectively lies in the operator community".
> Normally, that would mean the IETF publishes this as Informational.
> But of course that would raise the issue that an Informational would
> Obsolete a Standards Track document. Some discussion on this would be
> good.

please differentiate between change control of the document, and of
RPSL.  the ietf abandoned RPSL decades ago.

> #2 Transport Security
> 
> There are quite a few sentences scattered through the document about
> transport security that are not aligned, see:
> 
>         The URL uses HTTPS, so the WebPKI provides authentication
> 
> So is HTTPS mandatory? I guess not since (see below) FTP is allowed as
> URL too.

please differentiate between
  - fetching a geofeed file pointed to by an inetnum: https url, and
  - fetching the rirs's published archive of all inetnums: and other
    rpsl objects

>        the RIR's FTP [RFC0959] services SHOULD be used

that is bulk fetching the rpsl, not the geofeed

> More seriously, can we avoid SHOULDing the FTP protocol?
> Are these resources not made available over HTTP?

one at a time with tweezers.  don't do that.

> Note the paragraph above it says: "Historically, [...] often without
> consistent authentication". I wouldn't call that "Historically" if you
> are are promoting FTP and allow "unsigned" files.

again, please differentiate between the bulk fetch of the rpsl via ftp
and the fetch of individual geofeed files via https.

>         The geofeed files MUST be published via and fetched using HTTPS
>         [RFC9110].
> 
> Uhm. So what about FTP now?

again, please differentiate between the bulk fetch of the rpsl via ftp
and the fetch of individual geofeed files via https.

> The Security Considerations could bundle all the talk about HTTPS and
> FTP and put in one clear clause here, mentioning that due to lack of
> universal signing, it is sadly super important to have transport
> security protection (eg HTTPS, not FTP)

again, the differentiateion between the rpsl data and the geofeed files
is critical.

> #3 Signature and white space requirements are a bit troubling
> #4 Misc. Security comments
more on these later, when russ has had a chance to comment

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
>         Since geofeed_1 contains geolocation data about 192.0.2.0/29,
>         it is discarded because 192.0.2.0/24 is within the more specific
>         inetnum: covering the address range and that inetnum: has a
>         geofeed reference.
> 
> This reads a bit odd, a 192.0.2.0/29 comes out of nowhere. I guess you
> meant to say "a client looking for geofeed data for 192.0.2.0/29" ?

how about

         An application looking for geofeed data for 192.0.2.0/29, MUST
         ignore data in geofeed_1 because 192.0.2.0/29 is within the
         more specific 192.0.2.0/24 inetnum: covering that address range
         and that inetnum: does have a geofeed reference.

randy