Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

I'll try to respond to the thread in reverse order to avoid duplication...

On Thu, May 20, 2021 at 03:11:51PM -0700, Randy Bush wrote:
> 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

That removes the ambiguity I was worried about.  It seems like it should
work.

> > 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.

The analogies to DMARC do kind of write themselves...

> > 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.

Excellent, thanks.

> >    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.

ok.
(We do have plenty of examples of shiny cryptographic schemes that remain
mostly unused, but I will refrain from naming names...)

> > 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

IIUC you'd need to subdivide the inetnums in order for the signatures to
work?

> 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.

I think I just propose to drop the clause "and therefore must be covered by
the range of the inetnum:" since I don't understand what it is trying to
say.

> >    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.

thanks

> > (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.

(We actually said "objects and RPKI certificates need not align on CIDR
prefix boundaries, while those of the CSV lines in the geofeed file do".
My mistake, sorry.)

> >    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.

thanks

> >    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

nit: comma before "abusing" to aid readability.

>    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.

Looks good, thanks.  (I will watch and see if anyone complains about the
last sentence.)

-Ben