[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


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*

Magdalen Centre, Oxford OX4 4GA | T: 01865 582885
E: emily.taylor at oxil.co.uk | D: 01865 582811 | M: +44 7540 049322


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