[nanomsg] Security and the Big Picture
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg <nanomsg@xxxxxxxxxxxxx>
- Date: Wed, 12 Mar 2014 11:17:23 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
There have been a lot of talk about adding security to nanomsg in past
few days.
In this email I am not going to discuss any concrete proposals, rather
it tries where the extension points are what pros/cons they have:
Adding security at network level
- --------------------------------
1. The security is added below the transports, e.g. IPSec, VPN.
2. No need to change nanomsg in any way.
Adding security at transport layer
- ----------------------------------
1. The security is added as a new transport protocol (e.g. "tls://")
2. The mechanism is transport-specific and won't work for other
transport protocols.
3. It works only on hop-by-hop basis.
4. All the necessary params are passed to the transport either via
connection string (e.g. "tcp://192.168.0.111:5555") or transport
specific socket options (e.g. NN_TCP_NODELAY)
5. The transport does its best to keep the communication channels
open, for expample by re-trying to open a channel after a failure.
6. It doesn't report any errors to the user (except via
monitoring/management tools).
7. It doesn't report any specifics about peer identities to the user.
8. The problem is well understood and addressed by existing libraries.
Adding security at scalability layer
- ------------------------------------
1. The security is added to a specific SP protocol (e.g. REQ/REP)
2. It won't work for other SP protocols (e.g. PUB/SUB). In other
words, if Drew is interested of implementing SP-level security for
REQ/REP he can fully ignore PUB/SUB issues.
3. It works on end-to-end basis. The devices are not involved in any way.
4. All the necessary info can be passed via SP-protocol-specific
socket options (e.g. NN_SUB_SUBSCRIBE).
5. It is completely agnostic of the underlying transport, i.e. is
should work as well with TCP as with UDP etc.
5. The problem is not well understood and requires some original research.
- From the implementation point of view, the good news is that in all
cases the security is clearly decoupled from nanomsg core:
1. Security on network level -- nanomsg can be completely agnostic
about it.
2. Security on transport layer -- the functionality is neatly
contained in a transport. Transports have a well-defined interface and
although they are compiled as part of nanomsg at the moment, they can
be moved to separate shared libraries in the future.
3. Security on scalability layer -- in theory this can be built on top
of nanomsg and possibly merged into it later on. Alternatively, it may
turn out that it has to live directly inside existing SP protocols
(rather than atop of them), in which case we have well-defined
interfaces for building new SP protocols and we can even move them
into independent shared libraries in the future.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTIDQzAAoJENTpVjxCNN9Y900H/0vo058CNNoYxgASce2MJVdv
4QsMMId2yCaVZSfP3abyLJva8YL7GsTfTP0W38AI9BQP0VIc4e+v7g2NTBR9i+8f
KfTRQrRWLqfTYNleo7qUMHPHwDfb2zn+X0X8+qIq312S+cqkT6/HXvKVLmpKnGnu
RG2JiiF6GigIgwaC31jrSGiiaLNY/MaslGlNkCIhQlJbG8hqWoECC2vwujtMJUUZ
YSIKzQKpp2jAWc1uE1f47pYMgJBR9Fv4+i5I0c6ZezGksZ+dg2aOPjEFK3DUSZHS
cHI3bF9IrDxhoP/0VDnWy8bEVnjLFqrViN1HspFb0srC8aO9pPnywdGNIfQcnWw=
=3oQT
-----END PGP SIGNATURE-----
Other related posts:
