Mature TCP/IP Stack for STM32

Hi

We are working on a TCP/IP Gateway. Ideally we would like to use one of the free TCP/IP stacks that ST has made publicly available, but we are also open to 3rd party stacks

We do however no know the maturity of any of the stacks listed at the ST website:

http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1564/PF221027

(click the "Design Resources" tab)

Or should we be looking elsewhere?

Thanks

Klaus

Hi Klaus,

On 9/13/2013 2:13 AM, Klaus Kragelund wrote:
> We are working on a TCP/IP Gateway.

Is this a "generic" gateway?  Or, intended for use in a specific
sort of application?  What do you expect to encounter on each "side"?
(presumably, you're looking at IPv4; TCP & UDP??)

> Ideally we would like to use one of the free TCP/IP stacks that ST
> has made publicly available, but we are also open to 3rd party stacks
>
> We do however no know the maturity of any of the stacks listed at the
> ST website:
>
> http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1564/PF221027
>
> (click the "Design Resources" tab)
>
> Or should we be looking elsewhere?

I think you first have to look at what you are likely to encounter
for traffic and threats in your environment.

A "mature" stack designed for deployment in a benign environment
will perform like *crap* in a hostile one.  It will typically
"assume" too much that can be easily exploited.

OTOH, a stack designed for a more hostile environment may impose
other usage constraints on your device/system (as it attempts to
close some of the doors that a more naive implementation would
leave open).

You also need to consider the (run time) resources you have available
for this part of your project (presumably, the largest part if your
device *is* a gateway!).  In a resource constrained deployment, a
"mature, though naive" implementation can fail miserably -- potentially
taking down the entire product in the process.

<frown>  Sorry not to be of more help.  But, treating a TCP/IP
stack as a "check off item" is probably not wise in any scenario
other than as a "school project".  :-/

On Fri, 13 Sep 2013 03:21:39 -0700, Don Y <this@isnotme.com> wrote:

>I think you first have to look at what you are likely to encounter
>for traffic and threats in your environment.
>
>A "mature" stack designed for deployment in a benign environment
>will perform like *crap* in a hostile one.  It will typically
>"assume" too much that can be easily exploited.
>
>OTOH, a stack designed for a more hostile environment may impose
>other usage constraints on your device/system (as it attempts to
>close some of the doors that a more naive implementation would
>leave open).

I can confirm that you need to consider this. Our PowerNet
stack (not free, not in C)
  http://www.mpeforth.com/powernet.htm
has been deployed on devices connected directly to internet
feeds. The devices were attacked by port scan attacks within
one minute of first connection.

PowerNet runs comfortably on STM32 devices.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

On Friday, September 13, 2013 12:21:39 PM UTC+2, Don Y wrote:
> Hi Klaus,
> 
> 
> 
> On 9/13/2013 2:13 AM, Klaus Kragelund wrote:
> 
> > We are working on a TCP/IP Gateway.
> 
> 
> 
> Is this a "generic" gateway?  Or, intended for use in a specific
> 
> sort of application?  What do you expect to encounter on each "side"?
> 
> (presumably, you're looking at IPv4; TCP & UDP??)
> 

It is a Modbus TCP/IP to Modbus RTU (RS485) gateway. It is transparent to incoming traffic

> 
> > Ideally we would like to use one of the free TCP/IP stacks that ST
> 
> > has made publicly available, but we are also open to 3rd party stacks
> 
> >
> 
> > We do however no know the maturity of any of the stacks listed at the
> 
> > ST website:
> 
> >
> 
> > http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1564/PF221027
> 
> >
> 
> > (click the "Design Resources" tab)
> 
> >
> 
> > Or should we be looking elsewhere?
> 
> 
> 
> I think you first have to look at what you are likely to encounter
> 
> for traffic and threats in your environment.
> 
> 
> 
> A "mature" stack designed for deployment in a benign environment
> 
> will perform like *crap* in a hostile one.  It will typically
> 
> "assume" too much that can be easily exploited.
> 
> 

I saw a presentation of a guy at the DEFCON conference. He used a tool to scan the net for gateways and he found a lot, even without any password protection


> 
> OTOH, a stack designed for a more hostile environment may impose
> 
> other usage constraints on your device/system (as it attempts to
> 
> close some of the doors that a more naive implementation would
> 
> leave open).
> 

Yes, that is certainly an important issue.

> 
> 
> You also need to consider the (run time) resources you have available
> 
> for this part of your project (presumably, the largest part if your
> 
> device *is* a gateway!).  In a resource constrained deployment, a
> 
> "mature, though naive" implementation can fail miserably -- potentially
> 
> taking down the entire product in the process.
> 
> 

It only needs to support the gateway, so we guestimate that a Cortex M3 would do the trick

Cheers

Klaus

On Friday, September 13, 2013 12:43:25 PM UTC+2, Stephen Pelc wrote:
> On Fri, 13 Sep 2013 03:21:39 -0700, Don Y <this@isnotme.com> wrote:
> 
> 
> 
> >I think you first have to look at what you are likely to encounter
> 
> >for traffic and threats in your environment.
> 
> >
> 
> >A "mature" stack designed for deployment in a benign environment
> 
> >will perform like *crap* in a hostile one.  It will typically
> 
> >"assume" too much that can be easily exploited.
> 
> >
> 
> >OTOH, a stack designed for a more hostile environment may impose
> 
> >other usage constraints on your device/system (as it attempts to
> 
> >close some of the doors that a more naive implementation would
> 
> >leave open).
> 
> 
> 
> I can confirm that you need to consider this. Our PowerNet
> 
> stack (not free, not in C)
> 
>   http://www.mpeforth.com/powernet.htm
> 
> has been deployed on devices connected directly to internet
> 
> feeds. The devices were attacked by port scan attacks within
> 
> one minute of first connection.
> 
> 
> 
> PowerNet runs comfortably on STM32 devices.
> 
> 
Ok, I will add that one to the list.

Regarding the attacks, our IT guy at one point connected a Windows XP machine to the internet, with no firewall just as a test,.... it was infected and inoperable within 48 hours. Scary

Cheers

Klaus

In comp.arch.embedded,
Klaus Kragelund <klauskvik@hotmail.com> wrote:
>
> Regarding the attacks, our IT guy at one point connected a Windows XP machine to the internet, with no firewall just as a test,.... it was infected and inoperable within 48 hours. Scary
>

He was lucky it lasted that long. I think under an hour is not unusual for
such a setup.

Reminds me of the re-install I did on an XP machine not so long ago. Not
wanting to download a virus scanner on another machine and transfer it via
USB stick, I decided to download it directly from the manufacturers'
website.
So I type the URL and another site showed up and the machine started to
behave strangely. I had mistyped the URL and had landed on a purposely
set up infected page. Sigh, reformat and re-install again...
And this time set up security software from USB stick before ethernet is
plugged in.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

"To YOU I'm an atheist; to God, I'm the Loyal Opposition."
-- Woody Allen

Hi Klaus,

On 9/13/2013 6:14 AM, Klaus Kragelund wrote:
> On Friday, September 13, 2013 12:21:39 PM UTC+2, Don Y wrote:

>>> We are working on a TCP/IP Gateway.
>>
>> Is this a "generic" gateway?  Or, intended for use in a specific
>> sort of application?  What do you expect to encounter on each "side"?
>> (presumably, you're looking at IPv4; TCP & UDP??)
>
> It is a Modbus TCP/IP to Modbus RTU (RS485) gateway.

Ah!  Then you probably *really* want to be sure your gateway
can't be "hacked" as there are actuators/mechanisms/sensors
on the EIA485 side that could potentially "break REAL things"!

Have you considered adding firewall capabilities to this box?
BOTH WAYS??

> It is transparent to incoming traffic
>
>>> Ideally we would like to use one of the free TCP/IP stacks that ST
>>> has made publicly available, but we are also open to 3rd party stacks
>>
>>> We do however no know the maturity of any of the stacks listed at the
>>> ST website:
>>> http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1564/PF221027
>>> (click the "Design Resources" tab)
>>
>>> Or should we be looking elsewhere?
>>
>> I think you first have to look at what you are likely to encounter
>> for traffic and threats in your environment.
>>
>> A "mature" stack designed for deployment in a benign environment
>> will perform like *crap* in a hostile one.  It will typically
>> "assume" too much that can be easily exploited.
>
> I saw a presentation of a guy at the DEFCON conference. He used a tool
> to scan the net for gateways and he found a lot, even without any
> password protection

Shodan is your friend (or nemesis!  :> )

<https://en.wikipedia.org/wiki/Shodan_%28website%29>

>> OTOH, a stack designed for a more hostile environment may impose
>> other usage constraints on your device/system (as it attempts to
>> close some of the doors that a more naive implementation would
>> leave open).
>
> Yes, that is certainly an important issue.

Trust me (or not):  you want to sort this out *before* you've deployed
a "solution".  If you later realize you have a problem (too large
of an attack surface), you might find the resources that you have
available in the device are insufficient for a *real* solution!
(i.e., redesign the hardware *and* software instead of just the
software -- see below)

>> You also need to consider the (run time) resources you have available
>> for this part of your project (presumably, the largest part if your
>> device *is* a gateway!).  In a resource constrained deployment, a
>> "mature, though naive" implementation can fail miserably -- potentially
>> taking down the entire product in the process.
>
> It only needs to support the gateway, so we guestimate that a Cortex M3
> would do the trick

In terms of processing power, yes.  My concern is the resources
you make available (memory) and how quickly/effectively they can be
exhausted if attacked.

Ask yourself what the consequences TO YOUR CUSTOMER will likely be
if the gateway "dies" -- if you lose IP connectivity to/from the system
behind the gateway.  Indefinitely.

Good luck!

On Friday, September 13, 2013 5:04:38 PM UTC+2, Don Y wrote:
> Hi Klaus,
> 
> 
> 
> On 9/13/2013 6:14 AM, Klaus Kragelund wrote:
> 
> > On Friday, September 13, 2013 12:21:39 PM UTC+2, Don Y wrote:
> 
> 
> 
> >>> We are working on a TCP/IP Gateway.
> 
> >>
> 
> >> Is this a "generic" gateway?  Or, intended for use in a specific
> 
> >> sort of application?  What do you expect to encounter on each "side"?
> 
> >> (presumably, you're looking at IPv4; TCP & UDP??)
> 
> >
> 
> > It is a Modbus TCP/IP to Modbus RTU (RS485) gateway.
> 
> 
> 
> Ah!  Then you probably *really* want to be sure your gateway
> 
> can't be "hacked" as there are actuators/mechanisms/sensors
> 
> on the EIA485 side that could potentially "break REAL things"!
> 
> 
> 
> Have you considered adding firewall capabilities to this box?
> 
> BOTH WAYS??
> 

Well, kind of. I'm just a HW guy, so I will not be the know it all one, but we will have consultants doing the code, and then I really need to understand what they are up to ;-)

> 
> 
> > It is transparent to incoming traffic
> 
> >
> 
> >>> Ideally we would like to use one of the free TCP/IP stacks that ST
> 
> >>> has made publicly available, but we are also open to 3rd party stacks
> 
> >>
> 
> >>> We do however no know the maturity of any of the stacks listed at the
> 
> >>> ST website:
> 
> >>> http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1564/PF221027
> 
> >>> (click the "Design Resources" tab)
> 
> >>
> 
> >>> Or should we be looking elsewhere?
> 
> >>
> 
> >> I think you first have to look at what you are likely to encounter
> 
> >> for traffic and threats in your environment.
> 
> >>
> 
> >> A "mature" stack designed for deployment in a benign environment
> 
> >> will perform like *crap* in a hostile one.  It will typically
> 
> >> "assume" too much that can be easily exploited.
> 
> >
> 
> > I saw a presentation of a guy at the DEFCON conference. He used a tool
> 
> > to scan the net for gateways and he found a lot, even without any
> 
> > password protection
> 
> 
> 
> Shodan is your friend (or nemesis!  :> )
> 
> 
> 
> <https://en.wikipedia.org/wiki/Shodan_%28website%29>
> 
> 

Exactly, that was the tool :-)

> 
> >> OTOH, a stack designed for a more hostile environment may impose
> 
> >> other usage constraints on your device/system (as it attempts to
> 
> >> close some of the doors that a more naive implementation would
> 
> >> leave open).
> 
> >
> 
> > Yes, that is certainly an important issue.
> 
> 
> 
> Trust me (or not):  you want to sort this out *before* you've deployed
> 
> a "solution".  If you later realize you have a problem (too large
> 
> of an attack surface), you might find the resources that you have
> 
> available in the device are insufficient for a *real* solution!
> 
> (i.e., redesign the hardware *and* software instead of just the
> 
> software -- see below)
> 
> 
> 
Good point

> >> You also need to consider the (run time) resources you have available
> 
> >> for this part of your project (presumably, the largest part if your
> 
> >> device *is* a gateway!).  In a resource constrained deployment, a
> 
> >> "mature, though naive" implementation can fail miserably -- potentially
> 
> >> taking down the entire product in the process.
> 
> >
> 
> > It only needs to support the gateway, so we guestimate that a Cortex M3
> 
> > would do the trick
> 
> 
> 
> In terms of processing power, yes.  My concern is the resources
> 
> you make available (memory) and how quickly/effectively they can be
> 
> exhausted if attacked.
> 
> 
> 
> Ask yourself what the consequences TO YOUR CUSTOMER will likely be
> 
> if the gateway "dies" -- if you lose IP connectivity to/from the system
> 
> behind the gateway.  Indefinitely.
> 

I have noted your valuable comments, thanks :-) 

Regards

Klaus

Hi Klaus,

On 9/16/2013 12:28 PM, Klaus Kragelund wrote:
> On Friday, September 13, 2013 5:04:38 PM UTC+2, Don Y wrote:
>>> It is a Modbus TCP/IP to Modbus RTU (RS485) gateway.
>>
>> Ah!  Then you probably *really* want to be sure your gateway
>> can't be "hacked" as there are actuators/mechanisms/sensors
>> on the EIA485 side that could potentially "break REAL things"!
>>
>> Have you considered adding firewall capabilities to this box?
>> BOTH WAYS??
>
> Well, kind of. I'm just a HW guy, so I will not be the know it all
> one, but we will have consultants doing the code, and then I really
> need to understand what they are up to ;-)

Forget the technical issues, for the moment.  Think of
where your device will be deployed.  The sorts of things on
each *side* of it.  What is the risk you expose yourself
(or your customers) to if some "adversary" can breach
your device and talk directly to the things on the other
side?

E.g., if one side is *an* internet (even if it is not
*THE* Internet) and the other side is an industrial
control system, could someone potentially screw up
the operation of that industrial control system
from "outside" (i.e., some disgruntled employee sitting
in his office cubicle pushing commands THROUGH your
gateway maliciously).

Further, consider if one or more of these "sides" goes
through some *other* gateway to "places beyond" (e.g.,
The Internet).  In effect, potentially exposing your
innermost network to some outside hacker.

(Don't count on your corporate firewall to protect your
internal internet and, thus, your gateway and the industrial
control system beyond.  An adversary can install a device
*inside* your corporate firewall by which he can effectively
*be* inside your firewall -- even though physically located
OUTSIDE it!  I.e., if one of your employees sitting in a
cubicle can hack your system, then someone outside the building
could, also!)

>> Trust me (or not):  you want to sort this out *before* you've deployed
>> a "solution".  If you later realize you have a problem (too large
>> of an attack surface), you might find the resources that you have
>> available in the device are insufficient for a *real* solution!
>> (i.e., redesign the hardware *and* software instead of just the
>> software -- see below)
>
> Good point

If you are the hardware guy, the software guys may have a lot of
leverage by claiming that they're 8 months pregnant and *could*
finish IF the hardware was enhanced.  Suddenly, *you* are the
critical path!  :<

Good luck!
--don