Inter-Realm Infrastructure for Security (IRIS)

Inter-Realm Infrastructure for Security (IRIS)

IRIS started as a result of trying to integrate Grid middleware protocols with firewalls. It became quickly apparent that endpoints need to be able to discover middleboxes, negotiate any required authentication and authorizations, request services (such as RSIP IP address and port), and pass traffic to other endpoints. Middleboxes include diverse gateways such as firewalls, NAT boxes, performance enhancing proxies, or any other box that inserts itself above the IP layer in the communications between two IP end-points.

As part of IRIS work at LANL, Jalal Al-Muhtadi developed a Java/JINI implementation of a client that downloads authentication and encryption libraries from a server. See our LACSI 2001 paper, An Inter-Realm, Cyber-Security Infrastructure for Virtual Supercomputing.

SOCKS (see below) is perhaps the best starting point for authenticating connections and traversing middleboxes. However, it is stateful and therefore does not tolerate middlebox resets and failures. IPsec is more agile in this regard. Nonetheless existing SOCKS infrastructure provides a useful testbed. We have adopted the transocks codebase as a mechanism for routing traffic through SOCKS servers.

Related Work

SOCKS
The IETF Authenticated Firewall Traversal Working Group developed RFC 1928, the SOCKS v5 Protocol. A 1997 draft described extensions for specifying multiple SOCKS hops and negotiating authentication separately for each hop.

With SOCKS 4a and SOCKS 5, the client may send DNS names to the SOCKS server instead of already-resolved IP addresses. This is preferable in anonymized overlay networks such as Onion routing. This approach also provides the SOCKS server with more information with which to make policy decisions.

The following tools are useful for transparently socksifying binary applications. This is done by redefining the libc networking calls. However, this technique leaves hostname resolution as a separate, UDP network connection that is not relayed via SOCKS:

One could kludge support for remote DNS resolution by overloading the resolver library calls to store names and return fake IP addresses. When a network connection is attempted to one of those fake IP addresses, the SOCKS client library can substitute the fake IP for the real DNS name.

Onion Routing
The EFF-funded TOR project operates a functional overlay network for onion routing. TOR uses its own cell format for relaying data in encrypted form, but entry to the overlay network usually occurs via the SOCKS 4A protocol.

Topology-Insensitive Service Traversal (TIST)
TIST is a pre-working group protocol draft and a BOF at IETF 54 in July 2002. TIST uses RSVP as a middlebox discovery and communications protocol.

BEEP Tunnel Profile
The IETF Intrusion Detection Working Group developed TUNNEL, a BEEP profile that alows a BEEP peer to serve as an application-layer proxy.

Protocol for carrying Authentication for Network Access (PANA)
The IETF PANA Working Group is developing an IP protocol for performing EAP-like authentication to network access devices.

Realm-Specific IP
RFC 3103 defines Realm Specific IP, a TCP (or UDP) protocol for leasing address/port space from a gateway. RSIP is designed to be an alternative to NAT when multiple machines have to share addresses. The gateway will commit to routing traffic to the leased address/ports to the client. The client can generate end-to-end traffic using that address/port. Unlike NAT, this traffic is passed unmodified by the gateway. This means that the gateway doesn't have to know anything about the protocol that the client is using, and the traffic can be encrypted end-to-end. A nice Linux implementation exists.

Middlebox Communications (Midcom)
The IETF Middlebox Communication Working Group has developed requirements documents for a middlebox communications protocol, potentially based on some existing protocol. Midcom doesn't necessarily handle middlebox discovery, but does provide a protocol by which you can ask your firewall to poke a hole.

Supporting Protocols

Extensible Authentication Protocol (EAP)
EAP was originally specified as a generic mechanism for authenticating in PPP. Since then it has been adopted by 802.1X Ethernet authentication, and will likely show up in SOCKS. It has been proposed that RADIUS handle opaque EAP requests without the RADIUS client (a network service) having to understand EAP. This provides advantages over GSSAPI since the service need not understand or participate directly in the authentication.