RE: [ga] Re: Memo to Stuart Lynn

[Roeland Meyer <rmeyer@mhsc.com>]

Thank you for this opportunity Stuart,

My comments are interspersed below and irrelevent text is snipped with the
remainder being formatted for clarity;

|> From: M. Stuart Lynn [mailto:lynn@icann.org]
|> Sent: Tuesday, October 02, 2001 11:28 AM
|> 
|> Comments on a reply to Danny, please.

|> ________________
|> DRAFT

|> As I have pointed out to you earlier, the GA would eb 
|> welcome to meet at the conference hotel on November 12. 
|> There will not be meeting space available on November 13,
|> although of course the GA can meet at some other location.
|> 
|> I know you mean well by your note. However, I think it is based on 
|> some serious misconceptions. The first is that the security meeting 
|> is intended to "hijack" the agenda to the detriment of the At Large 
|> consideration is entirely misplaced. 

Be that as it may, the fact that the relevency of "internet security" wrt
ICANN is tenuous at best (I tend to view things optimistically), leads one
to think of all sorts of neferious reasons why this single issue should push
out other current business. I am not one of those but, IMHO this new
emphasis is misplaced. Is ICANN suddenly going to find a cure for future
Nimda wyrms? Will they put in place systems that will find wyrm authors?
Will they legislate anything to enforce/improve some sort of
security/quality vigilance, in Redmond? I think not.

|> Security of the Internet is a serious matter and must
|> be considered as a matter of urgency and priority, 
|> more than ever. 

Yes, all of us must view security more seriously. A view that I have been
espousing for years. We must also carefully discern the difference between
security and privacy. Having one doesn't mean we have to forego the other.
Recent rhetoric, from Washington DC, indicates that this may become a
serious issue. Newt Gingrich stated, and I agree with him, that the 11Sep01
event was intended to drive us into a police-state mentality. If that
occurs, the terrorists will have won their final objective (after economic
and social disruption comes political disruption).

|> These are times that require thoughtful responses. And
|> there is no question  that every organizational agenda 
|> across most of the world has been seriously affected by the horrible 
|> events of September 11.

Personally, I try to hold to the view that "nothing that can adequately be
explained by stupidity, can be malicious, most of the time". As I said, I'm
an optimist. This new security emphasis  is out of scope for the ICANN. The
clause quoted recently is a part of a catch-all section that broadens ICANN
reach, in untoward events. The practical reality is that ICANN has no
relevance with regard to  security concerns. The bottom-line is that there
is nothing that the ICANN can do, with regards to security, that isn't
already being done, period.

I've stated it earlier this week, but please allow me to reiterate here;

First, with regards to the DNS system;

<quote>
The current system is actually quite good and it's all IP-based, not by
name. If and only if, you build to run a RFC2870 compliant server, which all
zone server operators should at least consider. Your primary zone servers
become non-recursive vaults. You should have at least two and those two
should be the ONLY ones in the name server registration at the InternNIC and
in the root zone file. Your DNS resolvers should be at another IP address
and should be the only ones referenced in your zone files. Updates should
only be allowed from known IP addresses. TCP Wrappers should protect ALL
systems from connecting to strangers, via hosts.allow and BIND access
control lists (ACL). Do not take zone updates except from known systems and
do not allow zone transfers, except to known systems. Allow queries from
anyone. Only use BIND, under *nix, for public facing DNS servers. Even
MS-DNS, as implemented under Win2K Active Directory, allows this level of
control (although I would never use it to implement a zone server). Most
routers are secured similarly.

Now, as to the threat of sniffing, Most modern networks are almost pure
switched, sniffers (including SNORT) don't work very well here or anywhere
else. The perpetrator would have to actually get on the WAN port(s), for a
man-in-the-middle attack. co-opting a insecure host, doesn't buy you much
these days, especially on another switched subnet (you don't even see the
broadcast packets).
</quote>

[I might add that all root zone files, that MHSC publishes, are distributed
using military-grade enciphered tunnels (VPNs), implemented via SSH, rather
than the normal zone transfer mechanism of BIND. IOW, the probability of
interception is quite low.]

and in a later message, with regards to business resumption, I went on to
state;

<quote>
NSI does what every other largish corporation does, they have a disaster
recovery plan, usually called business resumption plan, by most IT managers.
This includes off-site backups. I don't think that this is anywhere near the
issue that many have thought it to be. I would guess that Tucows also has
one. Even lil old' MHSC has one (bunch of 2.2GB magneto-optical disks in a
SF Bay Area Wells Fargo Safety Deposit box, with duplicates in Colorado
Springs). 

A larger issue is the capital loss of the servers themselves. However, I
know of at least 25 other current root zone capable servers that are online
right now, with 100Mbps 100baseT bandwidth, a very large backbone colo
space, that could pick up the slack in less than 30 minutes notice. I have
root access on all of them. All are RFC 2870 compliant and I just finished
upgrading their root zone files. Some of them have been operational for
three years and the ORSC has a bunch more. Operationally, the Internet is
well covered.
</quote>

The point is, in summary, that even without DNSSEC, the DNS system is
reasonably secure and a reasonable business resumption audit of registrars
will cover data robustness and reliability of business continuation. I know
of no corporation, among all my past and current clients, that does not have
an active business resumption plan, at the very least. Most of MHSC clients
require greater than 99.99% uptimes and thus, business continuation is a
priority with them (not simple business resumption, I am using specific
technical terms here).

I might point out that the primary pitch for root-level zone servers, in
MHSC client facilities, is security and business continuation. I wont go
into the technical pitch here, but suffice it to say that a LAN suddenly cut
off from the internet will instantly cease operations if they have to use
external name resolution sources. This is true, even for internal name
resolution. Ergo, business continuation plans must include a currently
functional root level zone server cluster. Extreme cases include COM and NET
as well. Restricting distribution of root-zone file will instantly obsolete
all business continuation plans. In short, it will worsen the security
scenarios, rather than improve them, by a substantial margin. It will also
increase the load on the existing root servers, by an equally substantial
margin.

I might also point out that the cache-poisoning hole, that Kashpureff used,
has been well and truly welded shut, many years ago. There is now no danger
of cache-poisoning if the zone server operator follows RFC2870. All MHSC
zone servers (root and otherwise) and most ORSC root servers are RFC2870
compliant.

The sole remaining issues (those of software and data escrow) are those that
Roberto and others have surfaced and which have already been long answered.
Activating those plans should take no more than 30 minutes of the board's
time. Pull the trigger and be done with it, unless someone wants a
"grandstand" opportunity (stupidity vs. maliciousness).

In conclusion, there are no security issues, that ICANN can approach, that
deserve a majority of time at any ICANN quarterly business meeting.
Refocusing the November meeting on security issues is a mis-placed waste of
ICANN resources. This is regardless of whatever else is being pushed aside
(ALSC or otherwise). If ICANN BoD needs an internet operation primer then
they should do so off-line and in private and not waste everyone else's time
and expense, by being educated in public. MHSC will be glad to provide the
required education, at MHSC standard rates (if anyone from ICANN calls,
please allow a few moments whilst I recover from the shock of receiving such
a call).

|> I hope the foregoing helps you and those to whom you listen in your 
|> deliberations. Although I am sure the Names Council may want 
|> to think about how to allocate the time on November 12, I am sure you 
|> can hold a productive meeting of the GA at that time. You would 
|> also have the opportunity of inviting the ALSC to present its 
|> final conclusions to the GA if you wish.
|> 
|> I am sure the foregoing is of no consequence to those relative few 
|> who choose to see some sort of evil conspiracy in every 
|> ICANN action. 
|> So be it.

--
R O E L A N D  M J  M E Y E R
Managing Director
Morgan Hill Software Company
tel: +1 925 373 3954
cel: +1 925 352 3615
fax: +1 925 373 9781 
http://www.mhsc.com
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html