Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. thoughts on #3780 (Thomas Markwalder)
2. Fwd: thoughts on #3780 (Thomas Markwalder)
3. Support for SSL on backend database connections (Marvin Frick)
4. Re: Support for SSL on backend database connections
(Francis Dupont)
5. Re: Support for SSL on backend database connections
(Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Oct 2015 11:49:34 -0400
From: Thomas Markwalder <[email protected]>
To: Kea Dev List <[email protected]>
Subject: [kea-dev] thoughts on #3780
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Trac 3969 calls for the servers to exit if they lose connectivity with
MySQL.
I've been looking into this.
First, the MySqlLeaseMgr::checkError() method needs to be modified to
distinguish betweeen a unrecoverable DB error and things like statement
errors. That's pretty straight forward.
But then we have at least the following alternatives:
1. If a fatal error is detected, log it and call exit(-1).
2. Create a new exception, perhaps DbFatalError, and throw it.
One of the issues here is that subsequent MySQL api calls made on a
connection which has been lost can core, so once we detect an issue we
can't use that connection for anything other than looking at error
values. Currently the MySqlLeaseMgr has no real defense against that.
At first blush, the second option seems the proper thing to do.
However, we have done a pretty thorough job of making sure database
related exceptions, and even unexpected std::exceptions within our
libraries, do not bring the server down. This means that propagating
this new exception all the way out to a server's ::run() method, would
require adding catch-rethrows to quite a few try-catch blocks. These
blocks are in lots of places from allocation engine to
TimeMgr::handleReadySocket(). Basically any place that can end up
accessing the database. This seems like a pretty invasive thing to do.
Unless we think there might be other conditions, unrelated to the
database, that we wish to treat as "fatal" in the sense that we want the
server to shut down, but in a more orderly fashion that calling exit().
If that's true, having explicit catches for a generic class of
isc::FatalException might be warranted.
Keep in mind that we have a post 1.0 ticket, under which we should
attempt to reconnect to the database. This has its own challenges but
that's for another day. This might render such as intrusive code as
throw-away.
I am inclined to implement option #1 for 1.0. It might not be pretty
but it is far less invasive than trying to thread the exception all the
way through. In the end, what would we really gain by doing that?
Granted, we would not all of our destructors but is this really a big
issue? We could attempt to register some sort atexit() function but
I'm not sure if it's worth it.
Thoughts?
Thomas
------------------------------
Message: 2
Date: Thu, 22 Oct 2015 11:55:13 -0400
From: Thomas Markwalder <[email protected]>
To: Kea Dev List <[email protected]>
Subject: [kea-dev] Fwd: thoughts on #3780
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Subject is correct text of email states the wrong ticket, The correct
ticket is trac #3780
-------- Forwarded Message --------
Subject: thoughts on #3780
Date: Thu, 22 Oct 2015 11:49:34 -0400
From: Thomas Markwalder <[email protected]>
To: Kea Dev List <[email protected]>
Trac 3969 calls for the servers to exit if they lose connectivity with
MySQL.
I've been looking into this.
First, the MySqlLeaseMgr::checkError() method needs to be modified to
distinguish betweeen a unrecoverable DB error and things like statement
errors. That's pretty straight forward.
But then we have at least the following alternatives:
1. If a fatal error is detected, log it and call exit(-1).
2. Create a new exception, perhaps DbFatalError, and throw it.
One of the issues here is that subsequent MySQL api calls made on a
connection which has been lost can core, so once we detect an issue we
can't use that connection for anything other than looking at error
values. Currently the MySqlLeaseMgr has no real defense against that.
At first blush, the second option seems the proper thing to do.
However, we have done a pretty thorough job of making sure database
related exceptions, and even unexpected std::exceptions within our
libraries, do not bring the server down. This means that propagating
this new exception all the way out to a server's ::run() method, would
require adding catch-rethrows to quite a few try-catch blocks. These
blocks are in lots of places from allocation engine to
TimeMgr::handleReadySocket(). Basically any place that can end up
accessing the database. This seems like a pretty invasive thing to do.
Unless we think there might be other conditions, unrelated to the
database, that we wish to treat as "fatal" in the sense that we want the
server to shut down, but in a more orderly fashion that calling exit().
If that's true, having explicit catches for a generic class of
isc::FatalException might be warranted.
Keep in mind that we have a post 1.0 ticket, under which we should
attempt to reconnect to the database. This has its own challenges but
that's for another day. This might render such as intrusive code as
throw-away.
I am inclined to implement option #1 for 1.0. It might not be pretty
but it is far less invasive than trying to thread the exception all the
way through. In the end, what would we really gain by doing that?
Granted, we would not all of our destructors but is this really a big
issue? We could attempt to register some sort atexit() function but
I'm not sure if it's worth it.
Thoughts?
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20151022/df47b15b/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 22 Oct 2015 20:54:16 +0200
From: Marvin Frick <[email protected]>
To: [email protected]
Subject: [kea-dev] Support for SSL on backend database connections
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hello,
We are currently evaluating kea (+ mysql) and would like the connection to the
backend database to be secured via SSL.
As far as I see in the Code and the roadmap for 1.0/1.1 there is no such
support right now and/or planned. Also, this mailing lists archives do not show
any discussion on this topic either, so I assume its a feature that just hadn?t
come up yet. Is this correct?
Over the last few days I spend some time implementing said feature. The
libmysql allows rather easy integration with safe fallbacks via default values.
Please see my pull request on github:
https://github.com/isc-projects/kea/pull/15
How do you feel about integrating (and possibly enhancing) my code into kea?
BTW please push current master to github when you get the chance. There are
multiple pull request waiting with a lot of upstream commits in them.
Cheers
?
Marvin Frick, Operations
[email protected]
T +49 40 39 88 55-972
SinnerSchrader Deutschland GmbH | SinnerSchrader Group
V?lckersstra?e 38, 22765 Hamburg, Germany
Amtsgericht Hamburg HRB-Nr. 63663
Gesch?ftsf?hrer: Matthias Schrader (Sprecher), J?rgen Alker, Dr. Axel Averdung,
Holger Blank, Thomas Dyckhoff, Dr. Lars Finke, Martin Gassner
B?ros: Hamburg, Frankfurt a. M., M?nchen, Prag
https://www.sinnerschrader.com | NEXT AGENCY
------------------------------
Message: 4
Date: Thu, 22 Oct 2015 20:20:04 +0000
From: Francis Dupont <[email protected]>
To: Marvin Frick <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Support for SSL on backend database connections
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
DHCP itself has no protection at all (secure DHCPv6 provides only
authentication and integrity, no encryption) so there is no plan
to use MySQL over TLS.
Note if you'd like to secure the server infrastructure, IPsec is
the standard solution and is more flexible as it protects all traffic.
BTW it is the way Relay-Server DHCPv6 communication is supposed to
be secured when needed.
At the other hand OpenSSL is already an option for the crypto backend
so MySQL over TLS can be used without adding a new dependency (or
worse a conflicting dependency) so it should be enough to extend
the MySQL connection setup...
Regards
Francis Dupont <[email protected]>
PS: this is my own opinion and I am known to see the world in two
colors (red and black) and to not trust TLS to be correctly used
by common users.
------------------------------
Message: 5
Date: Fri, 23 Oct 2015 08:39:55 +0200
From: Marcin Siodelski <[email protected]>
To: Marvin Frick <[email protected]>,
[email protected]
Subject: Re: [kea-dev] Support for SSL on backend database connections
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Marvin,
Thank you for your email and interest in Kea. I don't recall any
discussions or plans within the team to implement encryption of the
MySQL connection. However, since you're having a use case for it, we
will certainly take it into consideration.
We will evaluate this proposal within the team and should get back to
you some time next week. Having a pull request (actual code written)
definitely increases chances of getting it done sooner. But, you need to
be also aware that we're fully booked for 1.0 release, while review and
integration of the pull request is also a non-zero effort.
Marcin Siodelski
DHCP Software Engineer
ISC
On 22.10.2015 20:54, Marvin Frick wrote:
> Hello,
>
> We are currently evaluating kea (+ mysql) and would like the connection to
> the backend database to be secured via SSL.
>
> As far as I see in the Code and the roadmap for 1.0/1.1 there is no such
> support right now and/or planned. Also, this mailing lists archives do not
> show any discussion on this topic either, so I assume its a feature that just
> hadn?t come up yet. Is this correct?
>
> Over the last few days I spend some time implementing said feature. The
> libmysql allows rather easy integration with safe fallbacks via default
> values. Please see my pull request on github:
> https://github.com/isc-projects/kea/pull/15
>
> How do you feel about integrating (and possibly enhancing) my code into kea?
>
>
> BTW please push current master to github when you get the chance. There are
> multiple pull request waiting with a lot of upstream commits in them.
>
> Cheers
> ?
> Marvin Frick, Operations
>
> [email protected]
> T +49 40 39 88 55-972
>
> SinnerSchrader Deutschland GmbH | SinnerSchrader Group
> V?lckersstra?e 38, 22765 Hamburg, Germany
>
> Amtsgericht Hamburg HRB-Nr. 63663
> Gesch?ftsf?hrer: Matthias Schrader (Sprecher), J?rgen Alker, Dr. Axel
> Averdung, Holger Blank, Thomas Dyckhoff, Dr. Lars Finke, Martin Gassner
> B?ros: Hamburg, Frankfurt a. M., M?nchen, Prag
>
> https://www.sinnerschrader.com | NEXT AGENCY
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 19, Issue 9
**************************************
