Thanks for the input, Paul. We've addressed the HTTPS MUST - FTP MUST
NOT issue in revision -11.
Cheers,
Oliver
On 12/4/25 11:34 AM, Paul Wouters via Datatracker wrote:
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]
