ICANN ICANN Email List Archives

[ssrt-draft-report]


<<< Chronological Index >>>    <<< Thread Index >>>

comment on the Stakeholder Group on the Security Stability and Resiliency Review Team Draft Report and Recommendations

  • To: ssrt-draft-report@xxxxxxxxx
  • Subject: comment on the Stakeholder Group on the Security Stability and Resiliency Review Team Draft Report and Recommendations
  • From: Rossella Mattioli <rossella.mattioli@xxxxxxxxx>
  • Date: Sun, 15 Apr 2012 17:44:34 -0500

In response of the Stakeholder Group on the Security Stability and Resiliency 
Review Team Draft Report and Recommendations.

I would like to congratulate for this comprehensive report and share with you 
some personal comments on the recommendations proposed in order to enhance the 
debate around this important topic.
I hope to provide some ideas to further develop the goal of the report. 
These comments are on my personal behalf only.

Unique identifiers
I would like to stress the importance of the other unique identifiers such 
Internet protocol ("IP") addresses, autonomous system ("AS") numbers and 
Protocol port and parameter numbers. While these identifiers do not reach the 
same popularity of domain names, they play a key role in the Internet 
Infrastructure. Security threats concerning these identifiers should be 
investigates as well as the domain names and initiative should be acknowledged.

Terminology and definition of the roles
As stated in the recommendation 1, 2, and 5 ICANN due to its position should 
deploy a leading approach and clearly state an unique and exhaustive 
declaration of its duty and roles.This can not only maximize the efforts within 
ICANN but also help the broader community to understand the whole SSR role.

Incident Response and Notification
As reported in the 2012 - 15 Strategic Plan ICANN seeks to improve responses to 
DNS incidents. Along with the clear statements of the SSR duties as in 
recommendation 24 and  28, ICANN should clearly state the constituency of its 
response team (RFC 2350), favor the adoption of incident information sharing 
standards and deploy exercises within the root server community in order to 
establish best practices in response and business continuity procedures and 
coordination.
Another effort in relation to recommendation 15 should comprise the definition 
of a public point of contact for reporting DNS issues using for example 
http://dnscert.org/.  Here,  ICANN should response for those in its consistency 
and forward those not in constituency to the respective response teams.This 
could be an example of its facilitator role in underlying available best 
practices to further leverage the DNS service standards of other fellow 
organizations.

SSR activities in the security debate
ICANN is in a key position at the moment and can play a pivotal role in helping 
developing a comprehensive approach about the security of all Internet unique 
identifiers. Without exceeding its bylaw, it can play a proactive part in the 
current environment. I totally agree with the team recommendation 16. Moreover 
ICANN should also formally engage the security debate not only in IETF working 
groups but all other working groups related to DNS such as for example those 
related to the malware use of domain generation algorithms. As the Conflicker 
experience showed, ICANN can be a fundamental actor in fighting these threats 
that unfortunately will become more and more frequent in the future.

Risk management 
The current Internet security threat scenario has reached a maturity that 
obliges the DNS community to have a comprehensive and clearly defined framework 
as stated in recommendation 25, 26 and 27. The efforts of this report and those 
of the Board DNS Risk Management Working Group and the Joint DNS Security and 
Stability Analysis Working Group are heading in this direction. ICANN should 
enable this in various way: clearly define the perimeter of the SSR, ensure the 
existence and facilitate the interaction of these working groups and pave to 
road to annual revisions and timing response due to constantly changing 
environment of the security threats. 
Particular importance should be focused on the vulnerability research because, 
as has been shown with the Kaminsky bug, there are probably undiscovered 
vulnerabilities in the DNS / DNSSEC and ICANN should make all possible efforts 
to play a proactive role and not a passive one in facing these threats, as 
proposed in recommendation 24 and 25.

Budget
I share Mike O'Connor view and I totally agree with recommendations 20, 21 and 
22, about the allocation of the budget. 
The numbers shown in the figures underline the will of invest in security and 
this could pave the road to numbers of interesting and targeted initiatives as 
aimed in recommendation 7 such as for example:
- fellowships for research on DNS and DNSSEC security
- funds for DSSA and other working groups 
- development of ICANN programs where the ICANN, security, business and 
academia communities working together on the SSR scenarios 
- the establishment of a reward program for reporting vulnerabilities
- the creation of a SSR center of knowledge and education programs for the 
whole community (not only the network operators community but all Internet 
stakeholders)
- SSR continuity exercises with other root servers operators and related 
operators in general.

Thank you so much again for your precious work.

Best regards,
Rossella Mattioli


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy