Re: [ietf-smtp] Characteristics of Isolated (or mostly-isolated) industr

On 1/5/20 12:58 AM, Dave Crocker wrote:

> > 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 
> The clients in such an environment appear to simply be MUAs.  The 
> submission server appears simply to be an MSA.
The clients might have MTA-like functions like queuing and retry, but 
aren't likely to bounce mail.   From the outside they look a lot like MUAs.
> I gather what makes them distinctive is methods of identification and 
> authentication -- notably reliance on network address rather than 
> domain names -- rather than anything involving email semantics or 
> basic protocol details (beyond ID & Auth)?
> What else is distinctive?
I should probably preface this by stating my belief that having 
different kinds of Internet for different kinds of devices is overall a 
Bad Idea.   I don't want to see the Internet split up into lots of 
special kinds of networks each with their own protocols.   (I feel the 
same way about homenet, and IoT - as opposed to IIoT - devices.)
IMO, to the extent possible, an IIoT device should be capable of, and 
configurable to, submit mail via an ordinary MSA, authenticating in the 
same way that an MUA would authenticate to an ordinary MSA, etc.   Being 
able to talk to an IIoT MSA should be an extra feature for use by 
devices that operate on more constrained networks - without public IP 
connectivity, without DNS, etc.
But the IIoT MSA might still be operating in an environment without DNS, 
so it can't be expected to do all of the sanity checking and fixup that 
an MSA on the public Internet would do. The IIoT MSA might need to be 
configured to forward to a "real" MSA downstream for such sanity 
checking and fixup.
Something I didn't mention earlier is that such networks may not have a 
reliable source of time, and a lot of these devices' clocks will drift, 
their batteries will fail and not be replaced, and so on.   So an IIoT 
MSA might not be able to put an accurate Date field or accurate 
timestamps in Received fields which is something else that might better 
be done downstream.   (Better to not add a Date header than to add one 
that's not reliable. )
I think an IIoT MSA should support some specific authentication methods 
(most of them probably already existing) other than having to rely on 
source IP address, even if it can still be configured to trust based on 
source IP address alone.
It might need some rate limiting provisions to remedy vulnerabilities 
caused by lack of real authentication.
I'd also like to see if there's a way to use TLS to let the connection 
be secured by a certificate on the client end, using a certificate 
issued by the device manufacturer.   For SMTP, what I have in mind is a 
SLTTRATS SMTP extension that acts like STARTTLS except that the the 
client and server roles on the TLS connection are flipped - the SMTP 
client is the TLS server and vice versa. Then the IIoT devices don't 
need a trusted CA list, the IIoT MSAs that they talk to do - but the 
MSAs are closer to the public network so the update might be easier.   A 
properly designed IIoT device could safeguard its private key from 
exfiltration enough that key rotation might be unnecessary - or maybe 
enough key pairs and certificates could be generated at manufacture to 
last for the lifetime of the device.    This is admittedly more 
ambitious than other ideas, and should probably be investigated separately.
It might be useful to have a standard for mail-generating appliances to 
uniquely identify themselves - maybe a convention for local parts 
containing globally-unique tokens - so they don't need explicit 
per-device configuration in order to have distinct originator addresses.
One service I've found to be useful in such networks is "deliver this 
mail if it can be sent immediately, otherwise don't bother".    This is 
used when implementing alarms/alerts that generate repeated messages 
while an exceptional condition persists.   The first such message might 
have normal delivery semantics, while subsequent messages for the same 
condition (until it's cleared) don't clutter up an outgoing queue, say, 
if there's a network outage.   DELIVERBY seems fairly well suited for 
that, especially when combined with an SMTP client implementation that, 
for messages so marked, simply drops the message (doesn't bother to 
queue it) if it can't be relayed immediately.
> and forward such email to a "smarthost"
>
> What are the differences from a classic originating MTA?
To me most of this stuff seems pretty similar to a typical mid-1980s IP 
lab network, say a local Ethernet with locally-chosen IP addresses, no 
external IP connectivity, no DNS, maybe hosts files, maybe a smarthost 
on the LAN that could forward mail via UUCP.   I don't think any of us 
who were running mail systems back then, would find much of this novel.
But I also think that we're going to see a lot more such systems and 
networks in the 21st century than we ever saw in the 1980s, and the 
scaling issues and security threats will be greater than they were then.
> From your note, the reliance on IP Address and boundary security 
> rather than encryption appear to be the primary points of distinction.
> In any event, I suspect it would be helpful to create an Informational 
> RFC that discusses design, administration and operations issues that 
> are noteworthy in common IoT environments. Sounds like it doesn't need 
> to be lengthy of complicated, but formulating a discrete set of 
> statements and getting community consensus on it could facilitate 
> detailed wg decision-making, here and elsewhere. 
Yeah, I'm thinking along similar lines.  Thanks for the feedback.

Keith


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp