Thanks for your comments, Paul. Responses are inline.
Cheers,
Oliver
On 12/3/25 1:49 AM, Paul Wouters via Datatracker wrote:
Paul Wouters has entered the following ballot position for
draft-ietf-opsawg-prefix-lengths-08: No Objection
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/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I support Deb/Sean's DISCUSS on the ASN.1 module.
The comments below I would have normally filed as a DISCUSS, but I think there
is just no way to address these, and we will just have to wait for evolution in
the RIR space to improve things.
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)
There is no technical limitation to make bulk WHOIS data available via
FTP. In fact, all five RIRs make this data available via HTTPS as well.
We'll add that information to the draft.
[...] 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?
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?
Deferring to @Russ Housley on the security-related comments above.
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
