[Ssr2-review] Item 68: L Root Question
Emily Taylor
emily.taylor at oxil.co.uk
Thu Jul 13 16:22:30 UTC 2017
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
<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/2b1daff6/attachment.html>
More information about the Ssr2-review
mailing list