Hi,
There is parallel, partly orthogonal, work in sidr-ops (no wg adoption yet):
https://tools.ietf.org/html/draft-azimov-sidrops-aspa-profile-00
https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-00
This is essentially opt-in forward signing by a AS-‘x’ allowing to make an
explicit list of upstream ASNs. If AS-X did not make a list, then any upstream
is ‘unknown’. If they made a list and an upstream is not in it, then *that*
upstream is ‘invalid’. Advice then is to drop invalids, but accept unknown and
valid. This has similar semantics to ROA origin validation in that it allows
outsourcing all the hard crypto work to validation software, and it allows for
incremental deployment. It is not full path security like BGP Sec but it makes
a path plausible, and in particular it makes it harder to do origin ASN
spoofing — one would have to create longer and longer paths && more specifics
would be rejected because of the ROA.
As far as I can tell the AS-cones is orthogonal to this in its simple form. It
allows specifying the policy of which downstream ASNs (x,y,..) could be seen
for a specific upstream ASN (z), relative to the ASN (a) in between. However,
the ability to cite downstream ‘sets’ signed by others makes it very hard to
reason about who signs what.
I think it could work if the two approaches were merged, and no downstream set
inclusion is possible. e.g.. have an object where AS-X signs:
Upstreams AS-1 from AS-X:
With downstreams forwarded to AS-1: ANY (null) -OR- None (empty list)
- OR- AS 5, 6, 7 (specific list)
Upstream AS-2 from AS-X, etc..
Signed AS-X
This would allow for the forward signing just like described in the ASPA
verification document. To me this seems the most valuable, but it would also
add a policy layer where certain downstreams may or may not be seen by an
upstream. The downstream verification would then have the following states:
ANY: all downstreams ‘valid' for this upstream
LIST: cited downstreams ‘valid’, uncited downstreams ‘invalid’
NONE: all downstreams ‘invalid’ for this upstream (empty list: they are all
uncited)
It implies that this is always specified if the above object is made. However,
if ASN-X did not create any object then both its upstreams, and downstreams,
would be ‘unknown’.
The cryptographic validation can be done by validation software, and a router
can get a simple list of tuples. The rpki-rtr protocol could be extended
(something that should be done for aspa by itself anyway).
Going further, I know that part of the motivation of the AS-cones work is to
provide feature parity with the IRR, and the above is only a subset. That said
I think this would still allow for the creation of manual filter list of people
are so inclined. As the upstream AS I can find all documented policies facing
myself, and the ASNs that would be forwarded to me. Recursively I can find the
policies facing those ASNs and the ANSs facing them. So I can still compile a
list of all possible ASNs behind an ‘incoming’ ASN and using ROUTE objects
and/or ROAs compile a list of allowed prefixes.
Kind regards,
Tim
> On 8 Sep 2018, at 01:22, George Michaelson <[email protected]> wrote:
>
> You have to state quite clearly WHO IS SIGNING. Whern you define a
> signed object into RPKI, the critical question is the PKI validation
> question: what meaning is applied to the RPKI resources associated
> with the signature which validates the object.
>
> You haven't stated anywhere what is in the signing EE certificate, or
> whose certificate it is.
>
> Clearly, in context, its the ASN which "owns" the cone. so the EE
> certificate has to consist of the RFC3779 list of ASN which say "I am
> the owner"
>
> As I said at a microphone at least once, Semantically, I think you
> have a problem because I believe the customer ASN are the ones who
> give authority to you to be placed into a cone, but we disagree there.
>
> Syntactically, I think you really need specific language to state the
> signer is the ASN constructing the cone, not the ASN inside the cone
> object.
>
> -George
> On Fri, Sep 7, 2018 at 9:48 PM <[email protected]
> <mailto:[email protected]>> wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Global Routing Operations WG of the IETF.
>>
>> Title : RPKI Autonomous Systems Cones: A Profile To Define
>> Sets of Autonomous Systems Numbers To Facilitate BGP Filtering
>> Authors : Job Snijders
>> Massimiliano Stucchi
>> Filename : draft-ietf-grow-rpki-as-cones-00.txt
>> Pages : 8
>> Date : 2018-09-07
>>
>> Abstract:
>> This document describes a way to define groups of Autonomous System
>> numbers in RPKI [RFC6480]. We call them AS-Cones. AS-Cones provide
>> a mechanism to be used by operators for filtering BGP-4 [RFC4271]
>> announcements.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-grow-rpki-as-cones/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-grow-rpki-as-cones-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-grow-rpki-as-cones-00
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> <https://www.ietf.org/mailman/listinfo/i-d-announce>
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> <http://www.ietf.org/shadow.html>
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>
> _______________________________________________
> GROW mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/grow
> <https://www.ietf.org/mailman/listinfo/grow>
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
