1.1 What does the name UUDynamics mean?

The "U"s in UUDynamics can be taken to be "Universal" and "Ubiquitous" and refer to the peer-to-peer nature of our products' architecture. "Dynamics" refers to our dramatic departure from traditional static low-level IP based solutions. It is a technological step forward and based on network-independent high-level constructs to meet any extranet's dynamic requirements.

1.2 What does UUDynamics offer?

UUDynamics offers a series of products under a single consistent architecture (iSTAR) for enterprises of all sizes to build their secure connectivity infrastructure. iSTAR also offers a unique opportunity for ISPs to offer value-added services to their customers. For example, managed security services, home-to-office connectivity, Extranet e-business exchanges and so on. They can do this by taking advantage of their existing Internet Data Center and customer base without incurring a large additional capital requirement for equipment purchases.

1.3 What is iSTAR?

iSTAR is the name for the unifying architecture for our products. It stands for instant Secure Tunnel Architecture. The goal of iSTAR is to offer the same ease-of-use characteristics commonly associated with instant messengers but for next-generation secure connectivity needs.

1.4 What are "UUAccounts" and "UUIDs"?

A UUID is the unique identifier for each node in an iSTAR network. Using UUIDs solves problems of addressability when our products are placed into private networks.

A UUAccount is the account each individual user must have in order to connect to an iSTAR network. They are centrally managed at the UUCentral.

2.1 What are all of these different 'nets? Intranet? Extranet? Internet?

"Intranet" refers to the network setup for internal use within an enterprise. It may have multiple branches geographically distributed over a large area. An intranet may need to connect multiple remote networks and provide access for traveling or telecommuting employees to its various branches. An extranet is a network setup for collaborating or cooperating business partners to utilize in order to engage in electronic transactions amongst themselves. Both extranet and intranet refer to private realms accessible by authorized parties only. Both extranets and intranets try to take advantage of the Internet, which is public to everyone and not limited to private engagement.

2.2 What is the biggest challenge for an extranet?

The biggest challenge for an extranet is its connectivity requirement. It requires an addressing plan radically different from both the Internet and Intranet.

Internet connectivity is provided through a standard IP addressing scheme. A station on the Internet has a public IP address, through which all incoming traffic is routed. An Internet site is like a storefront on a street, visible to all other stations connected to the Internet worldwide. On the other hand, the connectivity of an intranet is usually provided through a private IP addressing scheme. A station inside an enterprise needs to reach other stations within the same enterprise, and to connect to the public Internet for accessing public resources. The station usually has an IP address private to the enterprise, and can share the same public IP address with other stations for Internet access. Its private IP address is usually not usable by external stations outside of the enterprise for routing purposes. For an extranet, where two independent private enterprises interact electronically, the enterprises do not share the same private IP addressing plan, which makes connectivity between extranet partners a challenge. For them to connect to each other, there must first exist a consistent addressing scheme.

2.3 Wouldn't IPv6 solve these connectivity issues?

Yes and no. IPv4 won't cut it for Extranet because of the limited supply of IP addresses. IPv6 does solve that problem. However, in addition to the tremendous challenges in IPv6's global deployment and capital requirements, the security concern would severely hamper its applicability. Direct addressing capability to private resources through IPv6 is not considered desirable.

2.4 What are other challenges for extranets?

Security is the primary concern for obvious reasons. You want your partners to come into your private network only for the purposes explicitly allowed. You don't want them to wander around your private space doing things beyond what they're supposed to.

2.5 What security requirements are there specifically for extranets?

One would like to authenticate all visitors to the extranet, permitting only invited guests. Visitor access should be limited to authorized resources only, following authentication. Access should be monitored in order to detect any unauthorized access or intrusion. In the case of intrusion, damage control and prevention measures should also be available.

2.6 What is the preferred "granularity" for extranet interactions?

It is probably not desirable to give your extranet partner(s) a "virtual wire" into your private network. That would be too low-level and therefore difficult to control. (A "virtual wire" is essentially what the IPSec-based extranet solutions provide.) It is necessary to think in terms of applications and resources when dealing with one's partners. More technically, the "object-oriented" approach can be applied. Under that approach, an enterprise's resources are hidden under the extranet setup, allowing only defined and prepackaged interfaces for access to those resources. The approach should be simple, secure, and friendly if designed at the correct level of encapsulation. The protection is delivered through the proper interfaces, not through translation into low-level IP filters.

3.1 What is the application model of iSTAR?

Extranet resources are exported in a Publisher-Subscriber model. Network resources are exported to extranet partners through the process of "publication". Publication is carried out through prepackaged applications, such as Browser/Server, MS Outlook/Exchange, Notes-client/Notes-server, SQL-client/SQL-server, FTP, Telnet, etc.

A remote client then subscribes to published resources. The remote user connects to a Publisher and is provided access through it to the published applications.

3.2 What does a user see?

When a user logs into a publisher, they are presented with a list of allowed applications. This list is in the form of an application menu embedded in a web page. Each application is represented by its own icon, identical to how it would appear normally in the user's local machine.

3.3 What applications can I publish? Do I need to "webify" them?

Almost any client/server application can be published without any "webify"-ing needed. Technically speaking, all Microsoft Winsock-based client/server applications can be published. This includes web servers, IBM's Lotus Notes server, MS Exchange Server, PCAnywhere, FTP, telnet, and the list goes on. We even support Citrix and Microsoft's terminal services. In addition to these supported applications, iSTAR also supports Microsoft file browsing (and others such as NFS). Through this, Microsoft file shares can be published to subscribers and then manipulated by the remote users as if they were locally available.

3.4 Are applications supported transparently? Do I need to mess around with an SDK?

All supported applications are accessed transparently. The look and feel is identical to their local counterpart. The application icons look the same. The user interfaces are identical. The applications are "virtualized", and sent to their intended Publishers securely. The only difference to the user will be launching the application through the secure workspace.

3.5 Are more complicated applications such as NetMeeting supported?

Yes, they are.

3.6 Are UDP applications secured with iSTAR?

Yes. UDP traffic through TCP tunnels is secured under SSL. UDP tunnels are also protected by our proprietary security scheme similar to SSL.

4.1 What do I need in order to use UUDynamics products?

All you need is an Internet connection. UUDynamics' products are independent from the physical connection to the Internet. We work with ADSL, DSL, Cable Modem, dial up, satellites, DDN, etc.

4.2 If we already have an IPSec VPN, will that affect or be affected by iSTAR products?

No, it won't. Our products may be deployed and co-exist with just about any other network/security products out there. There is no incompatibility or even conceptual inconsistency created in working with other VPN products. As a matter of fact, some of our customers introduce us into their companies precisely because of this "network neutrality" when their networks become too complicated to manage. We design our products to meet specific needs. When multiple extranet partners must deal with one another electronically, their networks are incompatible by definition and we need to work through that incompatibility. UUDynamics' products are deployable in any environment as long as the Internet is accessible.

4.3 What do I need to deploy iSTAR?

iSTAR somewhat resembles instant messenging. There is a central server, called UUCentral, which manages all of the interactions between Subscribers and Publishers. For optimal functionality, all users under iSTAR must have access to the UUCentral.

4.4 Do I need to modify or reconfigure my firewall or edge router?

No, you do not. It is truly plug and play. Obviously the iSTAR components need to live under the constraints you placed on your enterprise traffic. The more you allow through your firewalls, the more capabilities iSTAR can offer. For instance, if you allow outgoing UDP initiated from the protected LAN, iSTAR will take advantage of that and run more efficiently.

4.5 Where is the UUCentral placed?

Since many functions are proxied through the UUCentral, it is the only component that requires a static IP address and must be placed in a public place. It may reside in the DMZ of an enterprise, or in an IDC as a hosted service.

4.6 Do I need at least one static IP after all?

Yes. You need at least one static IP for the UUCentral, or, if you choose to forgo the benefits that come with using a UUCentral (improved routing, private access mode, etc.) you will still need a private IP for each individual UUPublisher. However, the IP is not used as part of the routing mechanism as with traditional IP-based routing schemes. All routes between Subscribers and Publishers are managed symmetrically. This single static IP address does not force the routing scheme into a "spoke and wheel" pattern that can creates hot spots, congestion, and other scalability issues.

4.7 Is there a risk with sharing a UUCentral with other enterprises?

A UUCentral mediates the handshakes between Subscribers and Publishers. Since all protection is end-to-end, UUCentral is out of the loop of key exchanges or other security related handshakes, which are conducted confidentially between a Subscriber and the specified Publisher. Subsequently privacy or security is not an issue with a shared UUCentral. iSTAR architecture guarantees end-to-end secure connectivity.

The primary function of the UUCentral is to provide a signaling mechanism so that users under iSTAR can be addressed by their logical names, rather than by their IP addresses. However, since the UUCentral is shared, a Quality of Service issue could exist.

4.8 Does my data go through the UUCentral? Doesn't that add more hops and latency?

Data is routed through the UUCentral however this should not create latency issues if the UUCentral is correctly placed. It makes no difference if you place the UUCentral in your own DMZ. There are also advantages to hosting the UUCentral outside the enterprise with your service provider for reduction of risk and improvement in reliability and performance.

4.9 Is iSTAR for extranet use only?

Technically, Extranet is more challenging than Intranet. iSTAR satisfies your Extranet needs very well. It can be deployed only for your Extranet needs if you are happy with your current Intranet infrastructure. However, some of our customers are pleasantly surprised by our ability to address their other network needs, including the typical Intranet functions of LAN-to-LAN, and site-to-site connectivity. iSTAR not only satisfies those needs, it satisfies them in a secure and easy to use way. We also believe that iSTAR offers these functions on the correct level of granularity.

5.1 Doesn't a traditional IPSec VPN also allow for end-to-end protection?

In theory, yes. Traditional IPSec-based VPN does allow for end-to-end protection via the xx-to-gateway-xx setup. That function is part of the RFC for IPSec. However, in actuality, this setup is rarely deployed due to the extreme complexity involved in administrating the SA (Security Associations) among IPSec clients in accordance with an enterprise's security policies. Since IPSec is based on IP level protection, it is several levels removed from the actual applications. Administering the end-to-end SA typically requires the help of professional services. The user's familiarity is with the applications alone, but IPSec forces them to translate application-level policies into low-level IP rules. This make the entire process more convoluted and user-unfriendly for all involved.

5.2 What is a "DDMZ"?

DDMZ stands for Dynamic De-Militarized Zone. This is in contrast with the traditional DMZ, which is usually placed between the edge router and the internal firewall. The traditional DMZ is a closely guarded zone for protecting resources that are open to the public. Most of the resources in the DMZ have static IP addresses, allowing outside access. The DDMZ is also a highly guarded zone, but one which can be placed anywhere inside the enterprise without the need for static IP addresses. This is unique in that it allow you to place devices in a more logical way within an internal network and remote access will be protected and available regardless. In addition, this architecture enables better damage control if the published resources are somehow compromised.

5.3 What vulnerability is there to a denial-of-service attack with iSTAR?

When employing the traditional "perimeter defense", a network surrounds itself with a wall and opens only a single chokepoint as a security gateway, with all of its defense mechanisms concentrated at that point, it becomes inherently vulnerable to DOS attacks. To combat this, the iSTAR architecture allows the enterprise to utilize the defense assets of its ISP and the Internet Data Center, which provides professional and specialized protection against DOS attacks. It is much more difficult to overwhelm an enterprise by attempting an attack via its ISP/IDC. The iSTAR architecture therefore can provide an additional level of security through its dynamic defense scheme.

5.4 Is it true that using an SSL VPN will make your network visible to external attacks?

Normally, yes. Most SSL VPN solutions rely on an externally accessible public IP. iSTAR however requires you to open nothing to the public internet. As long as appliances within your network can make outgoing connections to the UUCentral, they will work as intended.