[tech] UCC Network Access to UWA

[Nick Bannon]

Thanks for getting some text together, James! UCC has been trying to
get a conversation going with UWAIT since at least 2020, but there's
been a few distractions along the way and it seems like we're talking
to new people now.

We don't want to flood them with confusing or conflicting demands and
multiple points of contact, but the work involved in communication and
implementation needs help and persistence. (More so than "design" or
"architecture", that is. We've managed to flood *ourselves* with a few
too many "wouldn't it be nice" thought balloons, with far too large gaps
between experimental implementation attempts)

Nick.

On Mon, Sep 12, 2022 at 09:01:42AM +0800, James Arcus wrote:
[...]
> As discussed last week, I am providing you a high level description of UCC's
> network access requirements, both based on the current architecture as well
> as more generally. I've attached a document with some more detailed
> enumeration of the below requirements and services.
> 
> Our requirements for internal UWA network services are very limited.
> Webserver and mail traffic is relayed through UWA, but almost all of our
> other services are free-standing. Depending on future configuration changes,
> this dependency could be further reduced.
> 
> We have machines across our address range (130.95.13.0/24) that require
> outbound traffic to the internet. However, aside from the aforementioned web
> and mail traffic, our need for outbound traffic to UWA is limited to
> publicly-accessible sites and servers.
> 
> While there are a core set of inbound services that are essential to the
> club's infrastructure, we also self-host a broad range of services across
> many inbound ports (e.g. from Git to IRC to Wireguard). We typically start
> and stop such services and open and close such ports as required. In
> correspondence late last year, we expressed:
> 
> > [We host] a broad range of network services via a subnet for which we have
> > the responsibility of administering. ... While this may not seem
> > important in a
> > corporate-type environment, the club has a long history of experimentation
> > with and development of networking projects (for examples of software that
> > was in-part developed at UCC, see Squid, Dropbear and Avahi) in ways that
> > were made possible by our ability to self-administer our connection.
> 
> We understand the need to balance accessibility against security, however
> wherever possible we would prefer to do so by creating stronger separation
> between UCC and the production UWA network, rather than between the internet
> and UCC. Last year we made some progress advancing possible solutions,
> possibly involving a new IP range that we could provide, before our
> discussion was disrupted by exams and personnel changeovers.
> 
> In more recent discussions, more extensive use of an access VPN has been
> raised as a way to minimise the need for open ports and firewall rule
> changes. While we do have most administrative services (dashboards, admin
> sites, etc.) behind similar controls, we find definite value in the ability
> to "start up and go" with a new service that can then be shared with others
> without setting up VPN clients or other configurations. As such, that would
> be a less preferred solution from our point of view.
> 
> I am happy to be looped in if any further clarification or more information
> is needed.
> 
> Cheers,
> 
> James Arcus

NetRequirements.20220912.txt:
In the below, the "necessary" tag refers to services that are needed
for UCC to function given the current network environment, but could be
rearchitected as part of a revised network environment. The "essential"
tag refers to services that are necessary for the club's services to
function.
Internal UWA network resources
    • [Necessary] F5 web gateways 
    • [Necessary] SMTP to and from mail relays 
Due to the current security architecture, all HTTP(S) traffic in and
SMTP traffic in and out to UCC is filtered by the network and directed
through application-layer gateways that have UWA internal addresses.
    • Internal UWA DNS (possibly unneeded)
UCC currently forwards DNS queries to the internal-facing UWA resolvers.
Historically this was needed for some UWA sites to work correctly,
however may no longer be necessary with the shift towards cloud and
SSO-based applications.
Other UWA-provided services
    • [Essential] Continued access to the "UWA-UCC" Cloudflare container
via designated contact (student/staff) Pheme accounts
This is the mechanism we use to administer our public-facing DNS
(ucc.gu.uwa.edu.au, ucc.guild.uwa.edu.au, and ucc.asn.au). However, this
does not need any specific network-level access to administer.
Inbound connectivity
    • [Necessary] SSH 
SSH is used for a wide range of tasks at UCC including user access,
administration, and automated tasks such as backups and cloud
orchestration. While SSH access is firewalled at our border and further
restricted by per-machine and per-user/per-key policies, these rules are
configured dynamically and are often updated.
    • [Essential] POP3/IMAP/SUBMISSION mail ports
    • [Essential] IRC server ports 
    • [Essential] Ipsec packets; OpenVPN and Wireguard VPN ports
These ports reflect three major services we provide to members, namely
mail, chat and remote-access VPNs.
Outbound connectivity
    • [Essential] Outbound connectivity from UCC subnet to global
internet (except SMTP port 25, as above)
UCC hosts a range of machines, including physical servers, virtual
machines, and desktops/endpoints across our current 130.95.13.0/24
address space. Each machine needs the ability to connect outbound,
primarily for user applications but additionally for system updates,
backups, etc.