Attach 4 Sample SON 2 SecondLife.docx

FA3002-10-R-0045

Attachment 4

AIR EDUCATION & TRAINING COMMAND (AETC)

PERFORMANCE WORK STATEMENT (PWS) ADDENDUM

FOR

SYSTEM ACCREDITATION OF SECOND LIFE VIRTUAL WORLD APPLICATION (Second Life)

31 January 2010

1.0 DESCRIPTION OF TASK ORDER SERVICES:

1.1 HQ Air University Communications, Logistics and Education Directorate requires contractor support to complete the certification and accreditation of the Second Life Virtual World application under the Air Force implementation of DoD Information Assurance Certification and Accreditation Process (DIACAP), to include all requirements pertaining to the Security, Interoperability, Sustainability, Supportability, and Usability (SISSU) process to obtain Approvals to Operate (ATO) and Authorities to Connect (ATC). The contractor will require access to the Enterprise Information Technology Database Repository (EITDR) which requires a minimum of a national agency check (NAC).

2.0 GENERAL DESCRIPTION OF AETC ATOs AND ATCs.

2.1 The Second Life Virtual World (Second Life) application is registered in EITDR as SL. The system is in the Build and Test phase of the IT Lean process. There is current no ATO/ATC for this application. It is a MAC III and has a Public Confidentiality Level. The system resides at the Linden Labs (vendor) location in California and part of an enterprise server configuration consisting of over 22K servers. The Second Life provides a virtual environment in order to facilitate an immersive Virtual Reality (VR) situated community, named the Global Learning Forum (GLF), designed and established to support Air Force prototyping for learning innovations with new media by means of a global outreach to educators spanning government agencies, public, and private universities. A key feature of GLF is dependence on bridging "weak interpersonal tie" social networks for obtaining the maximum channels through which novel ideas and information are gathered from the broadest outreach of social and cultural perspectives. The novel ideas and information are then distilled, using Air Force design studios, to obtain the best innovation prospects for prototyping.

2.2 AETC ATOs and ATCs consist of the following components:

2.2.1 Authority to Operate (ATO) for UNCLASSIFIED SL: Provide accreditation under DIACAP and SISSU sub-processes for the unclassified Second Life system owned by the HQ Air University Communications, Logistics and Education Directorate located at Maxwell Air Force Base. Provide Approval to Operate according to Air Force Policy Directive 33-2, Information Assurance Program. This includes all documentation, coordination, and implementation required to operate on government networks. There are changes/upgrades planned to be submitted during this process. These include a new server, upgrades in software and OS versions. The C&A package will contain current architecture. While these changes are planned, the overall strategy and function of Second Life remains the same. For the purposes of this C&A effort, the Second Life termination point will be the point at which our servers connect to the base network (the literal demarcation point is the back of our servers). All base network settings and equipment connecting Second Life to the NIPRNet are maintained by the 42nd Communications Squadron.

2.2.2 Authority to Connect (ATC) for UNCLASSIFIED SL: Provide accreditation under DIACAP and SISSU sub-processes for unclassified Second Life system owned by HQ Air University Communications, Logistics and Education Directorate located at Maxwell Air Force Base. Provide Authority to Connect according to Air Force Policy Directive 33-2, Information Assurance Program. This includes all documentation, coordination, and implementation required to operate on government networks. The changes planned to be submitted during this process includes the approval of new port openings. The C&A package will contain current architecture and the planned upgrades that will occur in the follow months. For the purposes of this C&A effort, the Second Life termination point will be the point at which our servers connect to the base network (the literal demarcation point is the back of our servers). All base network settings and equipment connecting Second Life to the NIPRNet are maintained by the 42nd Communications Squadron.

3.0 SCOPE/DELIVERABLES:

3.1 Contractor will complete the C&A of the unclassified AETC Second Life site to include all requirements pertaining to the SISSU process to obtain ATOs and ATCs as appropriate.

3.2 The contractor will develop and maintain documentation that meets or exceeds DoD Information Security requirements for system deliverables IAW DoDI 8510.01 DIACAP, AFI 33-202, Network and Computer Security Vol. 1, and Identity Management Vol. 6, and AF IT Lean Guidebook v5.07 (or later) including the first three phases (Define Need, Design, and Build and Test).

3.3 The contractor shall execute and update a Security Implementation Plan (SIP), conduct validation activities, and compile validation results in EITDR to retrieve a DIACAP scorecard. During the period of performance the contractor shall develop a Plan of Action and Milestones (POA&M) IAW DODI 8500.2.

3.4 The contractor shall provide an Information Support Plan (ISP) and related services. This shall include conducting initial certification tasks, periodic review of security configurations, and reviewing policy and procedure changes. The contractor shall complete the DIACAP Implementation Plan, answer all applicable IA controls, create and/or complete required security artifacts to include but not limited to the architectural framework views and upload into the EITDR system.

3.5 The contractor shall provide support required to achieve Federal Information System Management Act (FISMA) validation. FISMA support will be provided by the contractor to satisfy quarterly and annual reporting guidance requirements in accordance with the Air Force Chief Information Officer (CIO) 7 April 2007 memo and subsequent released guidance. FISMA requirements listed in this memorandum shall meet or exceed minimum standards as required by the program manager/system owner or the Quality Assurance Personnel (QAP). Cooperation between the contractor and the system owner shall ensure the appropriate FISMA questions in EITDR are answered and meet minimum solution requirements listed within the database. FISMA minimum requirements must be met or an appropriate Plan of Action and Milestones (POA&M) schedule shall be produced if it should fail.

3.6 The contractor shall work/coordinate with representatives from AETC and Air Force Network Integration Center (AFNIC) in obtaining information/documentation required for the completion of the C&A documentation required for receiving ATOs and ATCs from AFNIC and Air Force Network Operations (AFNetOPs).

3.7 The contractor shall support the AETC Second Life program manager in responding to any questions, attending meetings, and/or any other activities/tasks facilitating the development of the C&A documentation to include travel for testing and evaluation. Trip reports and/or meeting minutes detailing formal interactions will be required and supplied by the contractor, and included in a Monthly Status Report.

3.8 The contractor shall provide a schedule for completion of all tasks/activities required for receiving the ATO and ATC within five business days of contract. Due to the urgency in getting the DIACAP completed, the contractor is requested to base timelines on minimum time required to complete.

DIAGRAM 1

Second Life Architecture - The Grid Presentation: Second Life’s Architecture (http://www.infoq.com/news/2008/12/Second-Life-Ian-Wilkes) Ian Wilkes, VP of Systems Engineering, describes the architecture used by the popular game named Second Life. Ian presents how the architecture was at its debut and how it evolved over years as users and features have been added.

Second Life is a 3-D virtual world created by its Residents. Virtual Worlds are expected to be more and more popular on the internet so their architecture might be of interest. Especially important is the appearance of open virtual worlds or metaverses. What happens when video games meet Web 2.0? What happens is the metaverse.

Information Sources

· Second Life runs MySQL (http://conferences.oreillynet.com/presentations/mysql06/wilkes_ian.pdf)

· Interview with Ian Wilkes (http://dev.mysql.com/tech-resources/interviews/ian-wilkes-linden-lab.html)

· TechTrends: Inside Linden Lab (http://www.springerlink.com/content/a087424077663u0p/

· Town Hall with Cory Linden (http://blog.secondlife.com/2006/12/20/town-hall-with-cory-introductory-transcript/)

· InformationWeek articles (1, 2) and blog (http://www.informationweek.com/blog/main/archives/2007/05/linden_lab_plan.html%3cbr%20/%3e)

· Second Life Wiki: Server Architecture (http://wiki.secondlife.com/wiki/Server_architecture)

· Wikipedia: Second Life Server (http://en.wikipedia.org/wiki/Second_Life#Server)

· Second Life Blog (http://blog.secondlife.com/2007/08/24/more-open-source-our-web-services-libraries/)

· Second Life: A Guide to Your Virtual World (http://www.amazon.com/gp/product/0321501667?ie=UTF8&tag=innoblog-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0321501667) Platform

· MySQL (http://highscalability.com/tags/mysql)

· Apache (http://highscalability.com/tags/apache)

· Squid (http://highscalability.com/tags/squid)

· Python

· C++

· Mono

· Debian What's Inside?

Client/Viewer

· Open Source client (http://wiki.secondlife.com/wiki/Source_downloads)

· Render the Virtual World

· Handles user interaction

· Handles locations of objects

· Gets velocities and does simple physics to keep track of what is moving where

· No collision detection Simulator (Sim) Each geographic area (256x256 meter region) in Second Life runs on a single instantiation of server software, called a simulator or "sim." And each sim runs on a separate core of a server. The Simulator is the primary SL C++ server process which runs on most servers. As the viewer moves through the world it is handled off from one simulator to another.

· Runs Havok 4 physics engine (http://en.wikipedia.org/wiki/Havok_(software))

· Runs at 45 frames/sec. If it can't keep up, it will attempt time dilation without reducing frame rate.

· Handles storing object state, land parcel state, and terrain height-map state

· Keeps track of where everything is and does collision detection

· Sends locations of stuff to viewer

· Transmits image data in a prioritized queue

· Sends updates to viewers only when needed (only when collision occurs or other changes in direction, velocity etc.)

· Runs Linden Scripting Language (LSL) scripts

· Scripting has been recently upgraded to the much faster Mono scripting engine

· Handles chat and instant messages Asset Server

· One big clustered filesystem ~100TB

· Stores asset data such as textures.

MySQL database Second Life has started with One Database, and has subsequently been forced into clustering. They use a ton of MySQL databases running on Debian machines to handle lots of centralized services. Rather than attempt to build the one, impossibly large database – all hail the Central Database – or one, impossibly large central cluster – all hail the Cluster – Linden Lab instead adopted a divide and conquer strategy based around data partitioning. The good thing is that UUIDs– 128-bit unique identifiers – are associated with most things in Second Life, so partitioning is generally doable.

Backbone Linden Lab has converted much of their backend architecture away from custom C++/messaging into web services. Certain services has been moved off of MySQL – or cached (Squid) between the queries and MySQL. Presence, in particular Agent Presence, i.e. are you online and where are you on the grid, is a particularly tricky kind of query to partition, so there is now a Python service running on the SL grid called Backbone. It proved to be easier to scale, develop and maintain than many of their older technologies, and as a result, it plays an increasingly important role in the Second Life platform as Linden Lab migrates their legacy code to web services. Two main components of the backbone are open source:

· Eventlet is a networking library written in Python. It achieves high scalability by using non-blocking IO while at the same time retaining high programmer usability by using co-routines to make the non-blocking IO operations appear blocking at the source code level.

· Mulib is a REST web service framework built on top of eventlet Source: http://highscalability.com/second-life-architecture-grid Components Login server CGI script running on login.agni.lindenlab.com handles verification of user name and password. Determines the login region based on home vs. last location vs. URL specified location. Finds the simulator process running that region and verifies user is allowed to connect there. Alerts the simulator to expect a connection. Informs the viewer of where to connect.

Userserver Historically, the user server handled login. Now it handles instant message sessions, particularly for groups.

Spaceserver Handles routing of messages based on grid x,y locations. Simulator talks to Space Server to *register* and also find who the neighbors are.

Dataserver Handles connections to the central database, log database, inventory database(s) and search database(s). Performs queries on behalf of the simulator process.

Simulator The primary SL server process: Each simulator process simulates one 256x256 meter region. As the viewer moves through the world it is handled off from one simulator to another. It handles storing object state, land parcel state, and terrain height-map state. It performs visibility calculations on objects and land and transmits the data to the client. It transmits image data in a prioritized queue. Physics simulation is handled with the Havok physics library. Chat and instant messages are processed here.

Running at full tilt, a simulator will run at 45 frames/sec. If it can't keep up, it will attempt time dialation without reducing frame rate.

Simulators communicate with one another using a circuit via UDP. A "circuit" is a UDP network connection. Circuits are maintained between adjacent simulators.

Simulator vs. Viewer It helps to understand the division of labor between the simulator and the viewer, since the split in Second Life is very different than most other virtual environments:

· Simulator's job:

· Runs physics engine

· Collision detection

· keeps track of where everything is

· Sends locations of stuff to viewer

· Sends updates to viewers only when needed (only when collision occurs or other changes in direction, velocity etc.)

· Viewer's job:

· Handle locations of objects

· Gets velocities and other physics information, and does simple physics to keep track of what is moving where

· No collision detection Other servers

· Central Backbone

· Agent Database

· Agent DB keeps track of metadata<->item id (UUID) mapping

· Central DB (CDB)

· a list of who owns what, used for billing, etc

· Find DB (replica of Central DB used for search)

· Map server - renders overall map with OpenGL

· RPC server

· API for developers to manupulate Second Life without using the viewer

· Translates XMLRPC server into in-world requests

· Communicates with space server and CDB Source: http://wiki.secondlife.com/wiki/Server_architecture#Login_server PORTS and PROTOCOLS Introduction This article describes how to configure your firewall to allow use of the Second Life Viewer (client) within your intranet. It is intended for network administrators and others responsible for network security.

Firewalls are a fundamental component of a network security program. Following the "principle of least privilege," firewalls limit traffic between the corporate intranet and the public network to supported network applications. Thus, firewalls are generally configured for common applications such as Domain Name Service (DNS), email, and web browsing. However, Second Life uses a number of non-standard ports that most firewalls block by default.

To enable people to use Second Life from inside the firewall, follow the procedures outlined in this document.

Procedure Although the details depend on your specific firewall, follow this general procedure:

1. Open outbound access for TCP ports. Second Life servers do not establish inbound TCP connections to client systems running the Second Life Viewer software. Instead, they use the "request / response" message pattern.

· Enable outbound TCP access for ports 80, 443, 5060, 5062, 12043 and 21002.

2. Open outbound "session" access for UDP ports. Although UDP is a session-less transport, many firewalls block unsolicited incoming UDP traffic to a particular port unless it has seen recent outgoing UDP traffic from that same port.

· Activate outbound UDP for ports 5060, 5062, and 12000-13050.

3. Monitor. The intricacies of modern firewalls make it difficult for one document to cover every network configuration. Use tools such as ntop and nprobe to monitor network flow between the Second Life Viewer and servers to identify network flows that blocked by the firewall.

Ports In addition to the standard ports for DNS lookup and web access, the Second Life Viewer requires the ports listed in the following table.

Notes:

· RTP: Real-time Transport Protocol

· SIP: Session Initiation Protocol Source: https://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=6044 Protocol Step-by-step Step 1 Viewer( client)--------->User Server

· Secure Message checksum request - Protocol Level Supported? Yes/No.

· Port 12036 Step 2 Viewer -----------> Login Server

· XML-RPC Func call - over HTTPS. to login. (Blocking) [[1][Login Info from libsecondlife]

· Mostly a web server (Apache) that talks to a SQL DB. Gets user info from DB (home. etc.) gets the info about which sim to connect to (IP address etc.) and drops the connection.

· First name, last name, MD5(password), viewer version, requested location Step 3 Login Server ------> Database Checks actual database for authentication credentials Step 4 Login Server------> SIM in the Grid

· Login server decides which SIM to send the viewer to. talks to Grid

· Requests session start Grid (of Simulators):

· inbound UDP port (for comm. with Viewer) 12035, 13000-13050 Step 5 SIM ----> Login server (response)

· Verification that user is allowed on the SIM Step 6 Login server ------> Viewer (response)

· Information returned: agent id, session id, secure session id, sim ip, sim port, global location, some inventory info.

· Most IDs are UUIDs (agent id, session id, and secure session id, for example)

· Agent ID == User ID Unique and Persistent.

Step 7 Viewer -------> Simulator (on Grid) Handshake

· Viewer sends user id and session id Step 8 Viewer -------> User server User server handshake

· Sent for presence information so Group IM works

· Confers group rights to user

· User server verifies the SIM session info via DB Presence-Agent table.(initially committed by the Login Server at the time of Sim-LoginSERVER negotiation) Step p3 Source: http://wiki.secondlife.com/wiki/Authentication_Flow image1.gif