ok, thanks for the insights Pieter. It is helpful to have some
philosophycal stuff.
Le 04/10/2013 12:21, Pieter Hintjens a écrit :
You are mixing IMO a few different things that should not be mixed.
1. ZAP is not expensive; it's an inproc req/rep once per connection.
2. All mechanisms except default NULL use ZAP at least for IP address
checking. If you make a mechanism that breaks this model, you're
making life harder for everyone. It's already hard enough to
understand the abstractions. If each mechanism goes a different way,
it's painful.
3. Adding IP address checking and blacklisting to libzmq when you can
absolutely use ZAP for would be unfortunate.
4. You can of course authenticate client keys in the parano_server
without using ZAP. That's consistent with how the NULL mechanism
works.
tl;dr please don't make false optimizations that break the model and
create inconsistency that confuses everyone.
Thanks
Pieter
On Fri, Oct 4, 2013 at 11:58 AM, Laurent Alebarde <[email protected]> wrote:
If only ZAP is considered, you are right. But in use cases where the server
knows in advance all its client long term public key, authentication may be
performed without ZAP, in a lightweight mechanism.
In the PARANO mechanism I am designing, the HELLO command use (c->S) instead
of (c'->S), what enables to put C' in the box instead of sending it in plain
text. So here, I can forget the use of ZAP.
Le 04/10/2013 11:48, Pieter Hintjens a écrit :
You don't need to do this in libzmq; it can be completely hidden in
the ZAP handler.
On Fri, Oct 4, 2013 at 10:16 AM, Laurent Alebarde <[email protected]>
wrote:
When ZAP is used, libzmq gain information on possible ennemies. It may be
interesting to manage a EACCESS trigger counter per IP, in order to be able
to feed a fail2ban like list.
Rationals : Efforts are made in the code and has been argumented to delay
the costly operations in the curve protocol, to avoid some types of attacks.
So, it makes sense to delegate to the firewall via fail2ban the rejection of
ennemies.
Use case : For example, if an IP raises 3 EACCESS in less than 2 minutes, it
is banned for one hour directly by the firewall.
This could be implemented via a STL map with the IP has a key, with a value
being a structure containing the counter, the state, a timestamp of the last
trigger, and alongside, a timestamp-ordered STL set of the IP-keys. The
state is true if the counter reaches a parametrisable level (say 3 times).
The number of IP memorized or the duration of the memory SHALL be
parametrisable.
It should be open to enable other conditions than ZAP EACCESS, for future
mechanisms, so, the API SHOULD be something like :
if (errno == EACCESS) record_ennemy();
in say the curve_server.cpp file.
In the background, a text file compatible with fail2ban is maintained.
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
