Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th)

[Di Ma <[e-mail]>]

Job,

We authors are fine with removing AS0 usecase in RUSH after some discussions.

Di


> 2020年10月28日 14:32，Di Ma <[e-mail]> 写道：
> 
> Job,
> 
> Sorry for my late response.
> 
> 
>> 2020年10月23日 21:44，Job Snijders <[e-mail]> 写道：
>> 
>> Hi Di,
>> 
>> On Fri, Oct 23, 2020 at 09:18:21PM +0800, Di Ma wrote:
>>>> 2020年10月23日 00:17，Job Snijders <[e-mail]> 写道：
>>>> I am hesitant to support adoption as I feel this opens yet another
>>>> not-at-all-validated channel into pandora's box. I don't think this
>>>> draft in its current form is ready for adoption.
>>>> 
>>>> If this work is to proceed, I'd like RUSH to *strictly* limit itself to
>>>> transportation of VRPs within a *single* trust domain. If you are not
>>>> willing to give the operator of the RUSH endpoint absolute unrestricted
>>>> 'enable' access on your BGP routers, they are outside your trust domain
>>>> and one should not talk RUSH with them.
>>> 
>>> You have got the essence of RUSH: TRUST.
>> 
>> RUSH seems the opposite of TRUST. All validation steps from which we can
>> derive a degree of trust have been removed?
> 
> The trust in the RPKI roots in the public key that an RP uses to validate a X.509 certificate or a signed object. 
> 
> The trust in RUSH basically is the key bound to the cache server to do authentication which by the way is out of band of the RPKI.  Or the trust can also be the shared-key pre-configured between cache server and cache client of a RUSH connection in question.
> 
> 
>> 
>>> But, trust is not necessarily limited into the *single* trust domain.
>>> If I am allowed to exaggerate, RUSH even can used between two tier 1
>>> ISPs as long as one trusts the other. 
>> 
>> Interesting point, indeed we could iterate over all permutations of
>> possibilities, but what you mention is simply not how things are done in
>> practise between tier 1s (or other networks). I fail to see how the
>> exaggregation supports the Internet-Draft.
>> 
> 
> An exaggerated example might not implemented in practice but helps make the statement more straightforward.
> 
> 
>>> I think we authors have articulated the essential usecase.
>> 
>> Please see below.
>> 
>>>> The offending paragraph is this one:
>>>> 
>>>>  "o AS0 SLURM File Delivery The Regional Internet Registries (RIRs)
>>>>  need to publish assertions with origin AS0 ([RFC6491]) for all the
>>>>  unallocated and unassigned address space (IPv4 and IPv6) for which
>>>>  it is the current administrator.  RUSH is able to deliver those
>>>>  assertions to RPKI relying parties if so called AS0 SLURM file are
>>>>  generated by the RIR."
>>>> 
>>>> Here is an *explicit* example of the detrimental effects of so-called
>>>> RIR 'AS 0' policies https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html
>>>> Do we really want to create big red buttons that can be pressed to nuke
>>>> *countries* off the global Internet Routing system? Surely that is not
>>>> our intention. I'm a pacifist, I do believe that if we don't develop
>>>> machine guns, machine guns can't be used against other human beings.
>>> 
>>> AS0 is only a potential usecase and it is a policy issue whether the
>>> community decide to use RUSH to implement AS0. 
>>> 
>>> But we just want to offer the tool. 
>> 
>> Yes, you want to offer a tool, but as I mentioned the existence of some
>> tools is not without consequences to the global routing system. When a
>> big red dangerous button is created, at some point someone somewhere
>> will want to push it.
>> 
>> I'll note for full transparency to this group that one of the co-authors
>> of the RUSH Internet-Draft is also the co-author of a "RIR AS0" policy,
>> which was rejected by the RIR community in which it was submitted.
>> 
>> From my perspective the many discussions all over the globe (which so
>> far have taken place in APNIC, AFRINIC, RIPE, and LACNIC), is now just
>> spilling over to SIDROPS. Just like in all those RIR policy forums, it
>> should come as no surprise it will meet some resistance in this forum
>> too. As one of the use cases explicitly references 'AS 0' policies, it
>> no longer can be positioned as a neutral tool but has become part of a
>> wider (contentious) discussion.
> 
> I did note the discussions in RIPE Routing WG where AS0-slurm proposal did not reach consensus.
> 
> But I have not got the similar observation in APNIC, LACNIC, ARIN and AfriNIC community. I would like to hear from them.
> 
> Anyway, AS0-slurm is just one of the usecases.  Should it not be proper to be a RUSH usecase, RUSH should not be denied on the whole.
> 
>> 
>>> As I mentioned,  trust is not necessarily limited into a *single*
>>> trust domain.
>> 
>> Interesting, I am not sure I understand your definition of trust
>> domains. I am not even sure what my definition is, but I will point out
>> that the RIRs generally are *not* considered something to blindly trust.
>> The channel from RIR to Network Operator for RPKI related data is -
>> right now - one that strictly flows through a X.509 verifyable chain,
>> and RUSH is a novel way which sidesteps an existing more secure
>> mechanism. Why water that channel down?
> 
> I think the first two usecases described in the draft are easy to be implemented in a commonsense trust domain.
> 
> 
> o Cache Distribution
>   RUSH can be used to distribute a RPKI validated cache within a single
>   ASN or network, for example a confederation composed of a number of
>   ASes.  A small site or enterprise network MAY also use RUSH by
>   synchronizing with a third-party RPKI cache provider over external
>   networks.
> 
>   o Local Control over Networks
>   Network operators MAY want to inject SLURM Assertions/Filters via an
>   API offered by RPKI validator/cache.  RUSH is therefore able to carry
>   out such local control signals inside an administrative bailiwick in
>   a secure manner.
> 
> 
> Di
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops