Private Address Routing

UW Information Technology offers Private Address Routing to the UW campus (also known as Project 172, or simply as p172) as part of its Wired Network Services.

Objectives

This service provides additional options for improving the security of end-systems that cannot be made network-safe, and which do not need full, unmediated Internet connectivity — while not undermining the quality or supportability of the campus network.

The service includes four elements:

  1. Provide campus-wide routing of (172.x) private address space.
  2. Provide 172.x DHCP service (rather than global address DHCP service) on a per-subnet basis; subnets are either/or, and require coordination with Customer Care to convert to private address DHCP.
  3. Provide a Public and a Private view of the DNS zones.
  4. Provide Network Address Translation (NAT) from 172.x addresses to (a relatively small number) of UW public addresses.

The aggregate effect is to allow a subnet to (optionally) be configured such that attached computers, by default, are not accessible from outside UW, but can initiate outbound connections. This type of service is comparable to that provided by residential gateways for home networks in their default configuration.

Hosts configured with standard public/global addresses (e.g. most servers), would not derive any security benefit from this feature. Furthermore, this service offers no protection from attacks exploiting hosts within the UW network. The protection perimeter afforded by campus-wide “private addressing” is, by definition, enterprise wide; consequently the vulnerability zone within the perimeter is also large. Hence, use of campus-wide private addresses is intended to supplement but definitely not replace edge and host-based security measures.

Background

Hosts that do not require connectivity off their own subnet have always been able to use private addresses, but many systems require cross-subnet connectivity within the UW network, even if they do not need (any or full) connectivity to the entire Internet. (Private addresses are not usually routed between subnets, much less to the Internet.)

The premise of Project 172 is that it is useful to add a new class of campus-wide network service that is analogous to what a typical home LAN user experiences when behind a residential gateway–one that provides an additional measure of protection against “outside” attacks against certain networked systems. The hope is that this is an additional “tool in the security toolkit” that would complement other “edge-oriented” security approaches. Existing policies and mechanisms for assigning static global addresses to servers still apply to subnets configured to use the service.

As globally-routable IPv4 space has become more scarce, UW-IT has begun routing additional blocks of RFC1918 IPv4 space on the campus network without public equivalents. Campus users interested in setting up private, unrouted networks using RFC1918 space should consult this policy (Campus RFC1918 Space Usage Policy).

Overview

The campus-wide private network service element uses the 172.x private address space as defined by RFC1918. The 172.x private address space will be routed to/from campus global address space.

Mapping of the public subnets to the private RFC1918 address space follows the following scheme:

  • 128.95.x -> 172.25.x
  • 128.208.y -> 172.28.y
  • 140.142.z -> 172.22.z

We maintain a one-to-one subnet mapping between the public and private subnets. For example, the 128.95.1/24 public subnet maps to a 24 private subnet; in this case, 172.25.1/24 using the scheme above. We do not require a one-to-one IP mapping within the subnets.

The 172 private address routing is a ‘branded’ service in the sense that UW Information Technology provides the routing infrastructure to route between the private address space and the public space, and it is managed and monitored by our Network Operations Center (NOC).

The NAT function is performed at the UW Border Routers (UWBR). Each NAT device configured for redundancy in the event of a failure of either the NAT module or the UWBR that is connected to it.

A trace-back function to map the public NAT address to the originating UW subnet exists, enabling UW Information Technology to identify the source of errant traffic.

For p172 address assignments, DHCP configuration for your subnet, DNS registration of your systems, or general questions about the service, please contact Customer Services at help@uw.edu.

 

Last modified: September 19, 2013