hi paul, > To minimize the load on RIRs' WHOIS [RFC3912] services, the > RIR's FTP [RFC0959] services SHOULD be used for large-scale > access to gather > > I can't really ignore the fact that unsigned data is urged to be > transfered in the clear possibly (likely?) without authentication.
yup. but, as was discussed in LC, that is traditionally how the RIRs provided bulk access. as you say, they are heading for rdap, which is over https. > Does this contradict this earlier statement? > > This document provides a guideline for how interested parties > should fetch and read prefixlen files. To minimize the load on > RIRs' WHOIS [RFC3912] services, the RIR's FTP [RFC0959] > services SHOULD be used for large-scale access to gather > inetnum: instances with prefixlen references. > > Either this contradicts, or if the FTP fetch is to fetch data points > that point to where to fetch prefixlen files, then an attacker can > still fetch the prefixlen files over HTTPS, filter the signature(s), > modify what it wants, then serve this over their own HTTPS server by > updating the FTP fetch stream as MITM to point to its own HTTPS > server? yes. but today, FTP is the service which works for all RIRs. until that changes, the consequences of a weak protocol are inevitable. otoh, your attack, though possible, is a bit complex. i have no objection if you think it should be added to sec cons. randy _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
