[rssac-caucus] FOR REVIEW: Elements of Potential Root Operators

Russ Mundy mundy at tislabs.com
Mon Sep 12 04:44:41 UTC 2016


Hi Terry, Duane (& others following this thread)

I’ve followed the discussion about the RIR, RPKI & ROA and find the text that Terry’s comfortable with to be rather confusing since I really don’t have any idea what the phrase “maintain a watching brief on the use of …” is trying to get at?

Terry, it sounds from your earlier posts that you don’t think that use of ROAs & RPKI should be a SHOULD/RECOMMENDED but I don’t think your current suggestion says that.  Would you clarify what you intended with the wording?

As you might imagine, I strongly support having SHOULD/RECOMMENDED wording that says a candidate operator should actually plan on using the technology - the candidate doesn’t think they actually should use the technology, then they can provide their explanation for deciding not follow this paragraph as they would for any SHOULD/RECOMMENDED that they do not want to follow - remembering that the last paragraph in section 1 gives candidate operators the latitude to submit candidate operations that do not comply with the recommendations of this document as long as they can explain their rationale for their approach.

Russ

> On Sep 8, 2016, at 9:09 PM, Terry Manderson <terry at terrym.net> wrote:
> 
> Hi Duane,
> 
> Here is some text I would be comfortable with.
> 
> 'The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries. It is RECOMMENDED that the candidate maintain a watching brief on the use of Route Origin Authorization (ROA) objects in the Resource Public Key Infrastructure (RPKI).'
> 
> Slightly different topic, and I guess I'll be in the rough here - using RFC2119 language seems an easy step for 'us', but is it suitable to communicate the message to non-technical and other folks who simply aren't accustomed to reading RFCs?
> 
> Cheers
> Terry
> 
>> On 9 Sep 2016, at 7:16 AM, Wessels, Duane <dwessels at verisign.com> wrote:
>> 
>> 
>>> On Sep 7, 2016, at 5:26 PM, Terry Manderson <terry at terrym.net> wrote:
>>> 
>>> Caucus,
>>> 
>>> Speaking as just a caucus member,
>>> 
>>> I am very concerned about section 3.3.7
>>> 
>>> =-=-=-=-=-=-=
>>> 3.3.7 Address Registries
>>> 
>>> The candidate operator’s address space SHOULD be registered in one of the Regional Internet Registry (RIR) public databases. The candidate SHOULD have entries in relevant public routing registries, and if possible Route Origin Authorization (ROA) objects in relevant Resource Public Key Infrastructure (RPKI) registries for their IPv4 and IPv6 address space.
>>> =-=-=-=-=-=-=
>>> 
>>> I fully understand what RPKI (and BGPSEC) are meant to do, and I applaud that effort. However in this context My concern comes from two directions:
>>> 
>>> 1) Looking at the diversity principle, any thus by extension, we have currently exactly 5 regional internet registries (and no more on the horizon) for currently 12 operators. So in effect if all operators adopt the SHOULD we are reducing the attack vector diversity for a key component of operating a root server.
>>> 
>>> 2) The RPKI and BGPSEC is fairly well thought out, however I don't believe there is depth of experience there yet. 
>>> 
>>> For both of these reasons, I believe it is premature for RSSAC to make RPKI an element of a potential root operator without a deeper investigation into the benefits and risks (and scenarios of attack) of RPKI in the context of the root server system and the resiliency expected.
>> 
>> Terry,
>> 
>> Would you propose to just strike that second sentence altogether then?
>> 
>> DW
>> 
>> 
>> 
> 
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus




More information about the rssac-caucus mailing list