On 1/4/20 9:18 PM, John Levine wrote:
In
article<92D1347D-9993-41F8-902B-0C9EDC79AD7D(_at_)network-heretics(_dot_)com>
you write:
-=-=-=-=-=-
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.
Thanks, this is very helpful.
Thanks.
It looks like, insofar as we're thinking about mail, a reasonable
design is to put a reasonably capable submission server on a network
(e.g., Raspberry Pi running linux) and point the IPs of the IoT mail
senders at it. We could give some more thought about what the
submission server could reasonably do to avoid relaying hostile
messages.
At first glance it might seem like good sense to use a Raspberry Pi or
similar devices in some such scenarios. Though it's trickier that it
might seem at first.
Any device that uses an SD card as its primary storage medium is likely
to be flaky. At a minimum, it really needs a good power supply and
ideally a UPS to minimize the risk that the SD card will be trashed. (I
think newer Pis can boot from USB devices, so the SD card might not be
an insurmountable problem.)
In some environments there are other issues associated with such
devices, e.g. environmental (temperature, humidity, etc.). And a Pi is
not approved for use in an environment where explosive gases are
present, etc.
(It's probably possible to build an device which is basically a sealed
IP-rated enclosure containing a Pi with a 24v or lower voltage power
supply, and pay a testing lab to certify that such a device meets
relevant standards. Someone might even have done that already, but
such certification costs many thousands of dollars, so the certified
devices won't be cheap. A wall wart power supply would never be
acceptable.)
And to the person in charge of such a facility, a Raspberry Pi doesn't
look like industrial equipment. It might look more like a security
threat, which it coincidentally is. They're extremely easy to hack via
multiple paths, and it's difficult to protect them from being hacked.
They were, after all, basically designed to be easy to hack, not to
protect their code and data from attack.
-------
Rather than try to define what such a site's hardware configuration
should be, I suspect ietf-smtp would do better to define the behavior of
a submission service that is designed to accept inbound email from
devices in such an environment and forward such email to a "smarthost"
(or whatever you want to call it) that can get it to the appropriate
destinations.
Such a service might be provided by hardware located within that
environment, or external to that environment via a
NAT/proxy/firewall/whatever. Different enterprises will require
different hardware solutions. But the "IIoT submission service" may
still need to be able to operate in the same environment as the devices
it serves, which may still mean no DNS, etc. Or maybe two service
profiles are needed - one for on-site and one for upstream?
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp