Paul Wouters has entered the following ballot position for draft-ietf-opsawg-prefix-lengths-10: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-prefix-lengths/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [ Sorry, I updated my COMMENTS to a DISCUSS, see below ] 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. Why can this data not be made available over HTTPS ? (I understand RDAP might address this) Update: I was told that all RIRs now support an HTTPS frontend for their ftp sides, eg: https://ftp.arin.net/ https://ftp.ripe.net/ https://ftp.lacnic.net/ https://ftp.afrinic.net/ https://ftp.apnic.net/ In which case I think the RFC should say that FTP MUST NOT be used, but HTTPS MUST be used. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Deb/Sean's DISCUSS on the ASN.1 module. [...] the authenticator is invalid. What does this mean? Should all the data be thrown away? Should it be processed as unauthenticated? If so, what would that mean in practise ? Similarly for: All of the above steps MUST be successful to consider the prefixlen file signature as valid. What if it is not valid? The prefixlen files MUST be published via and fetched using HTTPS [RFC9110]. 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? Update: I think this should also note to use the HTTPS frontends of the FTP services. So I am not sure I can agree with the following text in the Security Considerations section: As mentioned in Section 6, some RPSL repositories have weak, if any, authentication. This allows spoofing of inetnum: objects pointing to malicious prefixlen files. Section 6 suggests an unfortunately complex method for stronger authentication based on the RPKI. I think Section 6 still has an FTP fetch in its process that can be manipulated to bypass the stronger authentication? Update: this would be resolved if HTTPS is required. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
