This is an attempt to summarize my observations about (mostly-)isolated
networks, and also about some dubious assumptions that I've seen some equipment
developers make about security requirements on such networks.
Most of these observations and assumptions aren't at all specific to email, but
several of them might inform email recommendations.
Sorry for material duplicated from other posts; I thought it useful to try to
collect everything in one place.
1. Scope
I'm only considering IP networks that are disconnected or mostly disconnected,
and devices on such networks which use some IP protocols, including IETF
application layer protocols. While these networks may have no external IP
connectivity at all, they may indirectly interact with hosts on private IP
networks and/or the public Internet, through proxies or application-level
gateways.
What I've seen is mostly (broadly speaking) "industrial" networks, used in
laboratories, manufacturing, energy production, and energy delivery. Some of
these networks are used to monitor and occasionally control production
equipment in factories, some used to monitor and/or control handling of
hazardous materials, some used in critical infrastructure, some where explosive
materials are present with consequent risks to human lives. I've also worked
with production networks In non-industrial settings that have similar
characteristics to networks described here.
Even equipment used only for "monitoring" may still present risks if the
equipment is compromised, if the monitoring is employed in a control feedback
loop, and/or because compromised monitoring equipment can be used to create
diversions from attacks made elsewhere.
What I've seen is a small sample. I can't claim that it's representative, but
I've seen the same patterns in so many different contexts that I suspect
they're very common. And I understand why many of these things are the way
they are. They are generally not easy problems to fix. I expect wide
variation given that every industry has different regulations,
certification requirements, and standard practices including safety practices.
It would be worthwhile to do a comprehensive survey across a variety of
industries.
My biggest concerns for these networks are:
(a) security. I'm not only concerned about the potential for such networks
and devices hosted on such networks to be attacked via external network
connections; I'm also concerned about the potential for such networks and
devices to be attacked locally, e.g. by attacks over WiFi, by unauthorized
devices plugged into local Ethernet, compromise of authorized devices via
physical access, and compromise of authorized devices on the isolated network
by devices that also connect to other networks.
(b) design choices and recommendations in Internet protocol specifications that
don't take into account the particular characteristics of these networks..
2. The Networks
- Common layer 2 media are Ethernet, 802.11, and "EtherNet/IP" (perhaps the
most confusing name for any protocol on Earth). There are a few other
variants of Ethernet media but adapted for industrial use, for instance, using
a different kind of media access control than collision detection. There are
"industrial wireless" networks that mimic Ethernet but over radio. I've seen
some interest in using IP over mesh networks, but haven't personally seen this
deployed.
- Generally they are running IPv4 using RFC1918 address space. I have seen a
tiny amount of interest in IPv6. I suspect most operators of such networks
will prefer IPv4 out of familiarity and because IPv4 addresses are easier to
transcribe. Given that the networks are usually isolated at the IP layer
anyway, use of IPv4 with RFC 1918 addresses doesn't present much of a problem.
- Static IP address assignment is common. DHCP might not be available.
- Often there is no external IP connectivity, though some of the same equipment
used on such isolated networks will also be used on other networks that do have
external IP connectivity. (I mean this in several ways: one is that the same
design and implementation of a device may be expected to function well on both
an isolated network and a more conventional network; another is that the same
device may be connected to conventional and otherwise-isolated networks at the
same time via multiple network interfaces; another is that it's common for
portable devices such as phones and laptops to migrate from one environment to
another and connect to such isolated networks when needed (even if this
violates safety or security regulations). Sometimes there is intermittent IP
connectivity, say, used for firmware update.
- DNS may not be supported or even wanted. I've been told that reliance on
DNS is a risk in a manufacturing environment that provides significant
potential for costly disruption with no benefit. There may be no name lookup
mechanism at all, not even host files. (I don't know how much mDNS is used,
but suspect that the same considerations apply; in my limited experience it
wasn't reliable enough to depend on.) I have seen a few devices that
supported NetBios lookup so that PCs could find them by name.
- There may be some interaction with external networks via proxies or
application-level gateways. (sometimes these are called "firewalls" even if
they never forward IP packets.)
- Zero threat analysis and handwaving security arguments seem to be the norm..
I should not give specific examples.
- Generally, these networks are not managed or operated by networking
professionals. Sometimes there are defensible reasons for that. Sometimes
the network is just a few hosts on WiFi or Ethernet, some of them are in very
remote areas, some are very disruption-sensitive.
3. Devices typically used on such networks
- Most interaction on such networks is between "appliance" devices that
primarily aren't designed to interact with humans. They may have no human
input or output devices at all (e.g. no keyboard, no display) or support only
very limited interactions with humans (a few buttons, a numeric keypad, maybe a
tiny display or touchscreen). That's why they don't need DNS; the devices
generally communicate mostly with other devices that are pre-configured and
there might not even be a way to type letters in. There's some pressure to
keep configuration settings to a bare minimum, not only because of input
difficulties but also because of customer support issues.
- I've seen many such devices with configuration interfaces and status
monitoring based on HTTP, ssh, bare tcp/telnet (sometimes with no
authentication at all), or occasionally rs232.
- I've seen several such devices that were configurable to send email reports
or notices of exceptional conditions.
- It seems to be common to bring a laptop into such an environment as needed to
configure devices, without dedicating a computer for that purpose. Of course
PCs still need firmware updates which are most easily accomplished by
connecting them to the public internet.
- I've seen wide variation in the ways that such devices can have their
firmware updated, if such capability even exists. Sometimes you can insert a
USB stick, sometimes you replace the device's SD card, sometimes you can push a
firmware update to the device from a web browser. Not only can it usually not
be automated, an update can be a cumbersome process and each device is
different.
- It's increasingly common to have such devices be based on Linux or similar
open source platforms (much as we've seen for internet appliances used in other
environments), but without much thought given to physical security, secure
firmware update, supply chain issues, back doors, removable media, JTAG probes,
etc. In my experience it's often trivially easy to alter such a device's
functionality, often with no physical modification needed.
- I've seen far too many devices for which every serial number had the same
root or "back door" password. Even if the device doesn't provide a shell login
from a network interface, there may still be a serial "console" interface..
- The problem of configuring and updating such devices, coupled with the
problem of managing passwords in such an environment (these passwords may
rarely need to be used by humans), is such that devices may be (re)configurable
or updated with no credentials at all - just using the app provided by the
vendor.
4. Implications
These networks remind me of IP networks from the 1980s. For instance,
password sniffing is often trivial because either no encryption is used, or the
encryption is TLS but with self-signed certificates. (There's an increasing
bias against use of self-signed certificates in applications, which makes sense
on the public Internet and most private IP networks. But the same browsers
are used on these isolated networks as are used on the public Internet.)
TLS, as normally used, doesn't work terribly well in such environments because
they don't use host names and there's no good way to rotate keys or update
trusted certificates.
Even HTTP digest authentication doesn't work very well because the protocol
specification doesn't really support all the features needed (how do you logoff
in a way that works for all browsers? how do you timeout a login session?) and
the user interface is so poor.
There's a widespread assumption that connected devices need on-demand firmware
updates in order to minimize the threat from zero-day exploits, but firmware
update is especially difficult in these environments.
Since DNS is not generally available and devices are generally not assigned DNS
names, and it can be difficult even to explicitly configure some of them, it's
not reasonable to expect these devices to use DNS names, say, in email.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp