ok, let me try to cover what russ has not. good reviews are much
appreciated
[ in the cs academic social circle, there has been comment that,
though reviews can be a pita, they are substantial revwiews. one
gets useful feedback. in man other fields, one gets one or two
sentences saying useless and even rude things. the ietf review
cycle, once one gets to last call (yes, that is a problem), is even
more thorough and constructive. ]
> We are careful to note that:
>
> The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
> present exactly as shown.
>
> How do we construct the bits (CIDR block?) that come after the quoted
> strings? Do they only matter for matching start/end, or are we supposed
> to check them in the validation procedure?
how about
The bracketing "# RPKI Signature:" and "# End Signature:" MUST be
present following the model as shown. The IP address range MUST
match that of the signer's certificate.
and the cert is already in the validation
> Thanks to Kyle Rose for the secdir review, and all who participated in
> the subsequent discussion.
indeed
> Publishing this document on the stanards-track does make one wonder
> whether RFC 8805 should be adopted at least into the IETF stream and
> possibly to the standards-track as well...
and it could use a bit of work in the process. can you say "let's open
a can of worms?" but yes, geofeed has seriously 8805 deployment, and it
is showing cracks.
> Section 1
>
> This document specifies how to augment the Routing Policy
> Specification Language (RPSL) [RFC2622] inetnum: class to refer
>
> Interestingly, I don't see "inetnum" at all in RFC 2622 (but the
> treatment in RFC 2725 is helpful to some extent). Should we be
> referencing 2725 (or something else) in addition to 2622?
grumph! i though i had fixed this. clearly i had not.
> Section 3
>
> The URL's use of the web PKI can not provide authentication of IP
> address space ownership. It is only used to authenticate a pointer
> to the geofeed file, [...]
>
> I'm a little confused by the use of the phrase "authenticate a pointer
> to the geofeed file". My understanding is that the "pointer to the
> geofeed file" is the URL itself, i.e., it is a pointer from the RPSL
> stanza to the geofeed file, and that dereferencing the URL retrieves the
> geofeed file itself (i.e., not a pointer). In particular, the URL (and
> any Web PKI usage therein) does not do anything to authenticate the RPLS
> stanza in which the URL appears. IIUC, it would be okay to just drop
> that bit and say "It is only used to authenticate the domain name in the
> URL, and provide confidentiality and integrity for the geofeed file in
> transit". Am I missing something?
no. my current edit buffer has
The URL uses HTTPS, so the WebPKI provides authentication, integrity,
and confidentiality for the fetched geofeed file. However, the
WebPKI can not provide authentication of IP address space assignment.
In contrast, the Resource Public Key Infrastructure (RPKI, see
[RFC6481]) can be used to authenticate IP space assignment; see
optional authentication in Section 4.
> If a geofeed CSV file describes multiple disjoint ranges of IP
> address space, there are likely to be geofeed references from
> multiple inetnum: objects.
>
> We might note that such files with geofeed references from multiple
> inetnum: objects are not compatible with our signing procedure (right?)
> and thus vaguely discouraged.
i am not sure i would discourage the use, as i suspect the rpki
authentication will mostly remain unused.
If a geofeed CSV file describes multiple disjoint ranges of IP
address space, there are likely to be geofeed references from
multiple inetnum: objects. Files with geofeed references from
multiple inetnum: objects are not compatible with the signing
procedure in Section 4.
> Maybe I'm just confused about what "covered by he range of the inetnum:"
> means, but I only see (at least so far) requirements that the signing
> cert cover all addresses in the file, and that we fetch from the
> most-specific inetnum: object with a geofeed reference. Can't I still
> sign with a cert that covers a broader range of addresses than the
> intenum: object used to fetch?
i am trying to think of two examples [ yes, certs and inetnum:s may
express ranges as well as cidr blocks ]
two inetnums:
1.2.3.0 - 1.2.3.7
1.2.3.6 - 1.2.3.13
and a cert for 1.2.3.0 - 1.2.3.13
and conversely
two certs:
1.2.3.0 - 1.2.3.7
1.2.3.6 - 1.2.3.13
and an inetnum: for 1.2.3.0 - 1.2.3.13
and i m starting to think i am rat-holing on complexlow-payoff corner
cases, a disease i rather dislike.
the current state is simple and clear. are there seriously useful cases
it does not cover? i will keep thinking. and listening, of course.
> Identifying the private key associated with the certificate, and
> getting the department with the Hardware Security Module (HSM) to
> sign the CMS blob is left as an exercise for the implementor. On the
>
> I thought there was some previous discussion of this but now I can't
> find it: I assume that a HSM is not mandatory for holding the RPKI
> certificate's private key. In that case, I'd consider "getting the
> department that controls the private key (which might be trapped in a
> Hardware Security Module, HSM)".
cool
> Section 5
>
> If and only if the geofeed file is not signed per Section 4, then
> multiple inetnum: objects MAY refer to the same geofeed file, and the
> consumer MUST use only geofeed lines where the prefix is covered by
> the address range of the inetnum: object they have followed.
>
> Does "geofeed lines" here mean "lines/entries in the geofeed file", as
> opposed to "the geofeed: attribute in the intenum: class"?
If and only if the geofeed file is not signed per Section 4, then
multiple inetnum: objects MAY refer to the same geofeed file, and the
consumer MUST use only lines in the geofeed file where the prefix is
covered by the address range of the inetnum: object they have
followed.
> (Also, didn't we say earlier that geofeed files could have entries
> that don't map up to a CIDR block and thus don't have a well-defined
> prefix?)
i hope not. a range such as 1.2.3.4-1.2.3.5 may not be a cidr block
but it is considered a well-defined prefix in rpsl and rpki.
> To minimize the load on RIR whois [RFC3912] services, use of the
> RIR's FTP [RFC0959] services SHOULD be the preferred access. This
>
> Preferred access for which objects/resources?
To minimize the load on RIR whois [RFC3912] services, use of the
RIR's FTP [RFC0959] services SHOULD be used for large scale access to
gather geofeed URLs. This also provides bulk access instead of
fetching by brute force search through the IP space.
> If an inetnum: for a wide prefix (e.g. a /16) points to an RPKI-
> signed geofeed file, a customer or attacker could publish an unsigned
> equal or narrower (e.g. a /24) inetnum: in a whois registry which has
> weak authorization.
>
> I might reiterate that the rule for fetching from the most-specific
> inetnum: object with a geofeed reference means that the spoofed data
> will take effect (for the affected prefix), and possibly also that if
> validators could always require signatures, the attack would be stymied
> (but of course that is not happening anytime soon).
For example, if an inetnum: for a wide prefix (e.g. a /16) points to
an RPKI-signed geofeed file, a customer or attacker could publish an
unsigned equal or narrower (e.g. a /24) inetnum: in a whois registry
which has weak authorization abusing the rule that the most-specific
inetnum: object with a geofeed reference MUST be used.
If signatures were mandatory, the above attack would be stymied. But
of course that is not happening anytime soon.
randy
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
