<<<
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
>>>
|