Open configuration

From eg

An open configuration project seeks to bring the benefits of share alike or licenses to combinations of free software used on Internet hosts and web services. An Internet Service Provider based only on open configuration - that is, using only share alike licensing for all configuration files and procedures - in theory could be merged or disappear entirely with no disruption to any services whatsoever.

A first step would be more limited consortia of ISPs all employing some common consortium best practice including a common open configuration contract guaranteeing all customers the right to transfer among members of the consortium with approriate insurance against losses or claims relevant to service provision.

Contents 1 what's it like? 1.1 XML-based configuration files: OVAL and OASIS 1.2 provisioning, sysoping, failover 1.2.1 fail-only? 1.2.2 friendly zombie 2 open host 3 duties 3.1 trolling 3.2 provisioning 3.3 sysoping 3.4 hacking/penetration 4 rights 4.1 failover 4.2 transfer 4.2.1 email forwarding 4.2.2 web and wiki redirects 4.3 privacy 5 relation to other efforts 5.1 OVAL 5.2 OASIS 5.2.1 in provisioning 5.2.2 in sysoping 5.3 ISO 5.4 share alike 5.4.1 open patent 5.4.2 open content 5.4.3 free software and open source 5.5 trademark

[edit] what's it like?

Such a configuration has attributes of several well known types of system configuration:

• it supports a minimal grid computing situation with at most two or three hosts that take over for each other failover or transfer situations, but usually run alone
• it extends the P2P model to other services than GNUtella or SETIatHome and like those relies on namespace distinctions primarily, and could hide actual IP addresses
  • under IPv6 it would be easier
• it provides basic service guarantees as some field of use specific projects do

[edit] XML-based configuration files: OVAL and OASIS

Existing schemes rely on limiting physical access or supporting only a very limited range of services or per-service guarantees. A more general scheme requires a different approach, so as to rely only on the Public Key Infrastructure and one or more distrust metrics, and well-defined XML-based standards such as:

• OVAL definitions of security vulnerability, compliance and patch*OASIS definitions for user, resource, and service provisioning based on SPML
• Other OASIS definitions for detailed concerns: DCML [1] for data center management, LegalXML [2], UDDI metadata for locating web services [3], and even CGM for diagrams.

[edit] provisioning, sysoping, failover

OS-specific boot image control concerns dominate present provisioning, but ideally are three stages in the lifecycle of any open configuration process:

• open provisioning where bids are taken to meet a given distrust level
• sysopping which relies on the winning bidder for that level or distrust and less, and for services of less sensitivity, literally anyone else whom one might contract
• failover which is the service being taken up by another open host, or none.

[edit] fail-only?

When an open host is removed from the network, another should take over for it automatically, as in utility computing, for at least the basic services guaranteed (allowing bootstrapping of the other services. Deliberately inserting an untrusted host and removing a trusted one, so as to cause the failover to reduce the trust level, is the standard and ordinary and default case. Failover can only be to hosts with a superset of the boot configuration compliance of the old host since zombie PCs could be inserted using a weaker one, and only on accounts or domains where distrust is not exceeded by that of the new host.

Failover must be supported, so it might and perhaps should be the only way a host is deactivated: To prefer open host rely only on failover parallels the ideal of all software being crash-only: since software will crash anyway and must do so very cleanly, effort should focus only on smooth recovery from crashes, and thus no other form of exit should be supported. Likewise, since even dedicated hosts will be penetrated (and shared hosts are penetrated more or less upon provisioning), there is no point trying to define many levels of distrust and set up different styles of provisioning and sysopping for each. There should be only one method and it should assume hosts share vulnerability, seek common compliance and need common patches, enterprises have common boot image control standards, and users share user privacy and other concerns. Such standards as OVAL and SPML accordingly seek to reduce all the parameters to an XML-based framework that can eventually make it just as easy to bootstrap an ISP as to use one.

[edit] friendly zombie

An open host differs from a zombie PC in that it respects distrust metrics. It could thus not be used as a spam relay or in a phishing or denial of service exploit.

[edit] open host

An open host can only failover to another host taking exactly the same position on all sysop issues. Any question about that configuration must be resolved solely with reference to configuration files, which all must be maintained in a well-understood format. See open host for the complete data definition.

At any given time, a single page establishes who defers to whom on final edits to any configuration information. For instance, eg:defer states all these relationships w.r.t. project eg:itself.

The combination of all references to configuration files and all deferences to the sources trusted to provide them, or persons who act as authority on each source, is called an open host configuration. An open host has certain fixed properties that enable it to operate seamlessly as part of an open network, very similar to P2P use of arbitrary machines as hosts.

[edit] duties

Making open configuration work requires that at least some users take on duties:

[edit] trolling

Obviously an open configuration is subject to a large number of requirements pressures, so to identify bona fide requirements bogus or emotional ones must be filtered out immediately.

The recommended approach is to rely only on trolls, preferably anonymous trolls with no body repute whatsoever, so that their contributions will be maximally distrusted. No sysop's desire to control political or personal or obscure professional opinions will go unchallenged, as trolls consider it a duty to point out and ridicule these desires. Only by approximately version 3.1 would trolls sometimes let sysops be.

[edit] provisioning

It isn't very easy to create a complete open host data definition that others can use. Eg:provisioning for instance took some months to evolve, just to get a good list of all sysop issues involved was difficult. This work must continue and will probably not mature for some years. Before 2008 however the OASIS and OVAL work in these areas, and PKI and LegalXML, should be reliable.

[edit] sysoping

Sysoping is work too. An email configuration requires maintenance especially under such pressures as spam, and social engineering can often compromise security even in perfectly run systems. Another difficulty is finding troll-friendly sysops who will accept the somewhat degrading title Lowest Troll.

[edit] hacking/penetration

Hacking is another duty. Penetration tests should be an ordinary and common part of open configuration efforts. SATAN or equivalent should probably be running all the time on all services using spare cycles, and reporting what it finds to responsible parties. Honey traps could be set up for the most common exploits, e.g. attempts to turn a host into a zombie PC, spam relay or phishing front, and the information forwarded directly to open configuration participants who are tracking and reporting such activity. In other words, the penetrating software or operator believes they have succeeded,

[edit] rights

[edit] failover

A key element of open configuration is failover standards that operate on the DNS and SMTP and IP address level, typically with the cooperation of routers (whose configuration is also open ideally). Unless an identical configuration can be copied from the original, or cloned, and instantly replace the original during unscheduled downtime, there is a potential service outage or even a potential exploit created. The Public Key Infrastructure and three party quorum arrangements required to set distrust levels to list failover for any service on any given server, should ultimately be subject to open patent and other arrangements that ensure that such crash-only systems remain free to all to program. Given this requirement, only free software at the OS level should be supported. If proprietary OS want to support these standards, then they must give up all patent rights under share alike arrangements with an open configuration consortium similar to Java. Note that such failovers are already built in to some network OS though they don't allow for arbitrary hardware to be supported. A challenge-response scheme is advised to secure any such failover.

[edit] transfer

A primary benefit of open configuration is that transfer of service provider contracts can be defined as a special case of failover, with new services automatically taking up as old ones lapse, with no potential for exploits or abuse of trust. Those relying on services would be guaranteed adequate notice to line up alternatives rather than seem them simply fail and have to scramble to recover, perhaps without access to configuration files.

For instance:

[edit] email forwarding

Email will be reliably forwarded as part of the duplication of email configuration which includes interim and temporary files created on the old host, which are copied to new hosts. To forward email is a normal part of service shifts. The time horizon after which forwarding expires would be set as part of configuration, and stated clearly in any contract with a service provider meeting open configuration and hosting standards.

[edit] web and wiki redirects

Likewise the use of HTTP redirects and wiki redirects would be guaranteed for a time in a contract, and could not be easily undone and remain within a network of open hosts. In general no contract problem would be worth losing status as an open host.

[edit] privacy

Maintaining user privacy - security of client records in any situation where services move to a different host is difficult but not impossible. It could be done by maintaining them always in a certain encrypted format which is the only one that ever moves between hosts. Again the Public Key Infrastructure would be required to make this operate. Any files stored in the clear would have only ordinary password type protections.

[edit] relation to other efforts

Many other efforts are underway that will constrain and assist open configuration efforts.

[edit] OVAL

The "information security community" has a "baseline standard for how to check for the presence of vulnerabilities and configuration issues on computer systems." It relies on:

• OVAL System Characteristics Schema for collecting configuration data from systems for testing;
• OVAL Definitions to test for the presence of specific vulnerabilities, configuration issues, and/or patches; and
• an OVAL Results Schema for reporting the results from the evaluated systems."

OVAL relies on XML to define a vulnerability, compliance or patch and are "all free to download, use, reference, and implement" in any open configuration effort. These would be referred to in any distrust metric.

[edit] OASIS

[edit] in provisioning

OASIS definitions for user, resource, and service provisioning based on SPML would provide detailed data during provisioning. OASIS sets Public Key Infrastructure standards for this purpose as well, [4] and as of 2006-01 was seeking input from PKI user community to speed adoption of this technology.

[edit] in sysoping

Other OASIS definitions for detailed concerns affect sysoping: DCML [5] for data center management, LegalXML [6], UDDI metadata for locating web services [7], and even CGM for diagrams.

[edit] ISO

The ISO 13335 and ISO 17779:2005 standards apply to privacy.OVAL will have to converge with those standards. ISO TC/211 deals with GIS and any geospatial data (including information about the physical location of hosts or users).

Eventually also an ISO 19011 class audit could apply to the protocols and task descriptions (defined in ISO 9000), and hardware and energy (defined in ISO 14000).

[edit] share alike

Any consortium effort may be relied on as long as its licensing is share alike. It cannot be open source since that definition allows for proprietary extensions that can be patented, and does not allow for restrictions on field of use. By constrast, share alike does support such restrictions, e.g. CC-by-nc-sa, and will soon support more. A CC-by-sa license should be applied for core open host definitions with other licenses applicable per field of use.

[edit] open patent

To prevent patent restrictions on future open hosts, the most basic innovations should be put in an open patent scheme as a blocking patent, relicensed under share alike terms: if a derived work is created, the price for license to the original is full license for all who meet the share alike license terms.

[edit] open content

A narrow open content license like CC-by-nc-sa, or a science or guild license would be ideal for the instructional capital related to this effort.

[edit] free software and open source

To avoid numerous complications in customizing operating systems, any open host should use only free software initially. Eventually open source and proprietary OS can be supported, once all of the implications for what must be supported in the OS itself is clear.

[edit] trademark

Eventually some trademark must be registered to indicate an open host is in use so that those who do not meet the rigorous standards do not claim to be such, and gain from it. This is a consortium best practice.