Trusted Internet Connection

Similar to Departments and Agencies that utilize Networx MTIPS, those using a TIC will already have a contractual relationship in place with their ISP, usually a Networx ISP. Pursuant to that relationship, the ISP, in its ordinary course of business, will use routing tables to ensure that only traffic intended for the Department or Agency’s IP addresses is routed to the Department or Agency’s networks. And the Department or Agency remains responsible for ensuring that only traffic intended for, or originating from, that Department or Agency is routed through the EINSTEIN sensor.

Since EINSTEIN collects network flow information for all traffic traversing a sensor, if, in a rare case the required contractual routing protections fail, in the normal course only network flow information associated with the improperly routed traffic would be collected. This mechanism minimizes the possibility of capturing or releasing Personally Identifiable Information (PII). If improperly routed network traffic matched a pattern of known malicious activity an alert would be triggered. In the event of an alert, and upon further inspection and investigation with the Department or Agency receiving the incorrectly routed traffic, a US-CERT analyst would be able to identify an incorrectly routed traffic error. US-CERT would then work with NCSD’s Network Security Deployment and Federal Network Security branches, the relevant Department or Agency, the ISP and, if necessary, the MTIPS vendor, to remedy the routing problem. In the unlikely event that an ISP’s routing tables mistakenly assign a government IP address to a commercial client, a routing loop would result. The routing loop would cause errors and break the commercial customer’s connection. When the ISP detects the routing loop or the customer reports its broken connections to the ISP, the ISP would correct the error in its ordinary course of business.

How Does a Mobile Community Work ?

It requires three basic functions: collaboration, multiplexing, and indirection.

1) Collaboration Among Mobile Hosts: The mobile community requires users to collaborate
by sharing/pooling their communication channels. However, what are the incentives for
users to collaborate? When only one host or a small set of members want to receive the
contents at others’ expenses, will the other members be willing to contribute their
bandwidths to enable the small set of members to achieve statistical multiplexing gains?

A somewhat related debate is underway with regard to “forwarding incentives” in ad hoc
network routing. In ad hoc networks, the communication between end points outside of the
radio transmission range relies on intermediate nodes on the path to forward packets for
them. Some researchers suggest use of credit-based, or reputation-based, schemes to
stimulate cooperation. Game-theoretic arguments have been used to show that collaboration
on packet forwarding among all participating nodes maximizes network throughput.

Forwarding in ad hoc networks, however, is somewhat different from the collaboration we
consider here. In ad hoc networks, nodes rely on each other to communicate amongst
themselves. In a mobile community, nodes rely on each other, not for basic connectivity
but for performance improvements.A node completely controls access to its shared
communication resources, and revokes access if its communication needs are not met by the
community. Ultimately, it is the ability to opt-in to achieve better performance and the
ability to opt-out when necessary, making link sharing a viable option. Nonetheless,
communities are more likely to be formed within domains where a pre-existing trust
(or cost-sharing) relationship exists. For example, an individual with multiple devices
(e.g., cell phone, PDA, laptop) interconnected with a personal area network can benet
from resource sharing, as in the case of teams of people working together.

2) Multiplexing: Given shared links, how can the mobile community aggregate link bandwidths
for a higher throughput? An inverse-multiplexer is a popular approach that aggregates
individual links to form a virtual high-rate link. For example, an inverse multiplexer
stripes the trafc from a server over multiple wireless links of the community members, each
of which then forwards the trafc to the receiver. Finally, the forwarded packets are merged
and assembled in the receiver at the aggregate rate. An important issue is then where to put
the inverse multiplexer. The inverse multiplexer can be placed at (1) a performance
-enhancing proxy (PEP) by a network access provider, a wireless telecommunication service
provider, or a content distribution network operator for downstream communications,
and (2) one of community members for upstream communications.

Within a proxy or a host, the multiplexer can be placed at the network layer as a routing
component with an efcient trafc ltering function as in the Network Address Translation (NAT)
service. Or, the inverse multiplexer might run as an application like in an overlay network.
However, multiplexing inherently requires responsive network state information, and additional
packet-processing overheads at the application layer limit the performance of the inverse multiplexer.

3) Indirection: Trafc from an inverse multiplexer to community members is tunneled via Generic
Routing Encapsulation (GRE). The inverse multiplexer encapsulates the trafc via GRE and routes
it to the community members’ WWANs. Upon its reception, each member de-capsulates the tunneled
trafc, and forwards it to a destination via WLAN. Since the destination is oblivious to which
member forwarded the data packets, no additional data reassembly functionality is required at
the receiver. Furthermore, because GRE tunneling is supported by most operating systems
(e.g., Linux, FreeBSD, the Windows), no system modication of mobile hosts is required.