[Ssr2-review] [Ext] Item 68: L Root Question

Emily Taylor emily.taylor at oxil.co.uk
Thu Jul 13 20:15:33 UTC 2017


Dear Steve

Thanks for following up.

Kind regards

Emily

On Thu, 13 Jul 2017 at 19:29, Steve Conte <steve.conte at icann.org> wrote:

> Hi Emily,
>
> Since your first email, I’ve been working with some staff whom I feel is
> more appropriate than I to address the question and was hoping to have a
> response for you by now.  I apologize that it hasn’t come yet, but I assure
> you that it’s not a “dropped” issue by any means.
>
> Steve
>
> On Jul 13, 2017, at 9:22 AM, Emily Taylor <emily.taylor at oxil.co.uk> wrote:
>
> Dear Steve
>
> Thanks for this. I will leave it to Geoff - who raised the original query
> - and others in the team to respond on any substantive issues.
>
> I would like to follow up on the rephrasing of the Team's question by
> staff. This was something I suggested somewhat flippantly when it came up
> on a call recently. On reflection, I believe it sets a poor precedent.
>
> I would like to request a full written explanation by staff as to how the
> original question was felt to be objectionable.
>
> Thank you
>
> Emily
>
> On Tue, 11 Jul 2017 at 20:22, Steve Conte <steve.conte at icann.org> wrote:
>
>> Greetings all,
>>
>> In response to the question on open item 68:
>> "What measures are undertaken by ICANN for the anycast deployment for
>> L-Root to ensure physical and network security and stability."
>>
>> Please see the response below:
>>
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>
>> SSR measures undertaken by ICANN for the anycast deployment of the root
>> server operated y ICANN can be considered on two axis, Structured
>> activities, and technical considerations.
>>
>> The ICANN DNS Engineering department undertakes two structured activities
>> directed at operational security matters, they are:
>>
>>         - ICANN DNS Engineering engages in an annual table-top exercise
>> with other root server operators to test its global operational readiness
>> to security or attack events.
>>         - ICANN DNS Engineering have commenced an annual security review
>> where a 3rd party security firm is contracted to perform a range of
>> penetration tests targeting all facets of L-Root operations.
>>
>>
>> Technical considerations cover actions applied to all ICANN root server
>> anycast instances.
>>
>> All L-Root instances have access control lists applied to the interfaces
>> in a stateless mode that:
>>         - only permits access from the greater internet to the public
>> service addresses for the necessary ports on the expected protocols (eg
>> 2001:500:9f::42, port 53, TCP and UDP)
>>         - restrict all traffic to/from the management interfaces to ICANN
>> management networks
>>
>> Additionally, all L-Root instances:
>>         - follow a plan and process to update all hardware before it
>> reaches 5 years of age
>>         - follow a policy that all hardware is under either a 3 year or 5
>> year, next business day, support contract from the hardware vendor (when
>> supported by the vendor in the particular country where the instance is
>> located)
>>         - have internal and external monitoring of the L-Root service AS
>> number
>>         - have internal and external monitoring of the L-Root service on
>> all necessary protocols and service addresses
>>         - are monitored for access activity, network uptime and
>> performance, and system uptime and performance
>>         - implement the appropriate recommendations from BCP38 and
>> RFC7454.
>>
>> Given ICANN anycast deployments come in two forms.
>>        1) Anycast instances operated by ICANN and hosted by contracted
>> parties.
>>        2) Anycast instances operated and hosted by ICANN
>>
>> SSR measures for these two deployment forms differ slightly
>>
>> 1. Anycast instances operated by ICANN and hosted by contracted parties.
>>
>> For all L-Root instances hosted by contracted parties the following
>> conditions are placed on the host, by contract.
>>
>>         - provide connectivity for network traffic for the DNS service
>> interface in such a way to achieve high availability;
>>         - provide connectivity for network traffic for the remote
>> management interface in such a way to achieve high availability;
>>         - provide physical security with no history of breaches within
>> the last 12 months, which may be monitored and adjusted by ICANN from time
>> to time;
>>         - provide suitable power and cooling, which may be monitored and
>> adjusted by ICANN
>>         - ensure access to the Equipment to is restricted to no other
>> individuals than an ICANN representative or an authorised employee of the
>> contracted organisation
>>         - ensure the contracted organisation access the Equipment only as
>> directed by ICANN
>>         - notify ICANN should any security, power or cooling arrangements
>> be changed
>>
>>
>>
>> 2. Anycast instances both operated and hosted by ICANN
>>
>> These anycast instances are maintained in ICANN controlled cages in
>> data-centers that have been inspected by ICANN Staff and meet the following
>> access security and infrastructure requirements:
>>         - require photographic government issued ID for access
>>         - premises are manned by security personnel 24x7
>>         - pre-authorisation is required for access
>>         - key or pin-code access into ICANN caged areas
>>         - 24x7 monitoring and recording of access
>>         - equipment entering or leaving the facility is vetted and
>> checked with ICANN staff
>>         - full UPS power on all circuits
>>         - power supply redundancy including on-site generators.
>>         - robust and redundant heating, ventilation, and air conditioning
>> (HVAC) systems
>>
>> Network connectivity at these anycast locations is via multiple redundant
>> upstream connections and the providers of these services are contracted
>> directly to ICANN, and as such changes can only be implemented by
>> authorised ICANN staff.
>>
>>
>>
>> -----
>> Steve Conte
>> steve.conte at icann.org
>>
>>
>>
>> _______________________________________________
>> Ssr2-review mailing list
>> Ssr2-review at icann.org
>> https://mm.icann.org/mailman/listinfo/ssr2-review
>>
> --
>
> Emily Taylor
>
> CEO, Oxford Information Labs
> *Associate Fellow, Chatham House; Editor, Journal of Cyber Policy*
>
>
> *PLEASE NOTE MY NEW EMAIL ADDRESS AND CONTACTS AS OF 1 JANUARY 2017 *
> Magdalen Centre, Oxford OX4 4GA | T: 01865 582885
> E: emily.taylor at oxil.co.uk | D: 01865 582811 | M: +44 7540 049322
>
>          [explore.tandfonline.com]
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__explore.tandfonline.com_cfp_pgas_rcyb-2Dcfp-2D2017&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=wvHw01dievbmPfc1yw36wc0A8tF__OOVlW7lupAxbVw&m=02BEW3SJBNRL_jMaOFwzyocH1pdoud6_d-TGANj407U&s=CJhtQSFRrLcSHdZrLABG6fSVm53XjFK4RYwho3rGFiw&e=>
>
> Registered office: 37 Market Square, Witney, Oxfordshire OX28 6RE.
> Registered in England and Wales No. 4520925. VAT No. 799526263
>
> .
>
>
> -----
> Steve Conte
> steve.conte at icann.org
>
>
>
> --

Emily Taylor

CEO, Oxford Information Labs
*Associate Fellow, Chatham House; Editor, Journal of Cyber Policy*


*PLEASE NOTE MY NEW EMAIL ADDRESS AND CONTACTS AS OF 1 JANUARY 2017*
Magdalen Centre, Oxford OX4 4GA | T: 01865 582885
E: emily.taylor at oxil.co.uk | D: 01865 582811 | M: +44 7540 049322

          <http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>

Registered office: 37 Market Square, Witney, Oxfordshire OX28 6RE.
Registered in England and Wales No. 4520925. VAT No. 799526263

.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ssr2-review/attachments/20170713/f6701a5e/attachment.html>


More information about the Ssr2-review mailing list