Here's the summary of the IRC meeting.



Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 20th Dec 2017
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:


The next meeting has not been scheduled yet.

Your local meeting time is easy to check from services such as



cron2, dazo, mattock, ordex and syzzer participated in this meeting.


Discussed the suggestion by Internet Bug Bounty to sponsor OpenVPN bug


IBB tries to avoid overlap, in our case with OSTIF.org. Mattock will
contact OSTIF.org (and IBB) to see if we can find a solution that
benefits all parties.


Discussed putting CloudFlare on front of community.openvpn.net and
forums.openvpn.net. It was agreed we should only do it if there benefits
to it. One benefit is that CloudFlare could stop certain types of
attacks before they reach those servers. Performance might improve
somewhat, but people generally haven't had performance issues with
either server. Mattock will make some inquiries to figure out what the
benefits are. We will revisit this topic after that.


Discussed control channel optimization worked on by gertvandijk and
syzzer. The approach they've found has the big downside is that it needs
a wire protocol change, but they have a concept to do that gracefully.
This work is still in pre-PoC phase.


Discussed the FIPS patches. It was agreed that we want them in as
they're very important for some users and they are not too invasive.
Somebody just needs to review the code.


Discussed dazo's new OpenVPN 3-based Linux client. Dazo will release it
later this week. It depends on DBus, which is available for Linux but
also for BSD operating systems. Right now the client is just a backend
service which front-ends (e.g. GUIs) can make use of. The backend
services is a sort of "OpenVPN Interactive Service for *NIX".

The back-end service will not have feature-parity with the OpenVPN 2, as
many things (in particular server-side support) are missing. Dazo will
add a "missing features" list to the Git repository so that people can
look into implementing them in the OpenVPN 3 core library.


Decided to skip the meeting next week (on 27th Dec) because too many
people will be on holiday then. Agreed that the next meeting will be
arranged on 3rd January 2018.


Full chatlog attached.

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock
(12:31:43) mattock: meeting time
(12:31:58) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2017-12-20
(12:32:00) vpnHelper: Title: Topics-2017-12-20 – OpenVPN Community (at 
(12:32:39) mattock: who do we have here today?
(12:33:40) cron2 [gert@openvpn/community/developer/cron2] è entrato nella 
(12:33:45) cron2: good morning
(12:33:46) syzzer: me, and dazo just reported in
(12:34:16) mattock: hi guys!
(12:34:36) mattock: let's start then
(12:34:39) cron2 ha scelto come argomento: Agenda at 
(12:34:50) mattock: #! IBB
(12:34:52) mattock: oops
(12:34:54) mattock: #1 IBB
(12:34:56) syzzer: FYI - I have until 12, because its Christmas lunch today at 
the company, and I'd like to join my colleauges there
(12:35:07) mattock: let's keep this quick
(12:35:17) cron2: syzzer: snowboarding, slacking in asia, christmas lunch... 
you have good life!
(12:35:21) cron2: (but that is good for me)
(12:35:40) mattock: anything to discuss regarding IBB? or should we just wait 
what their board members say about our OSTIF connection?
(12:36:02) mattock: or should we try to coordinate this with OSTIF, so that 
OSTIF would focus on "other things" in OpenVPN rather than bug bounties?
(12:36:10) mattock: then IBB could handle the bug bounty part
(12:36:15) syzzer: I'm all for IBB, even though it probably means more work for 
(12:36:24) mattock: yeah, me too
(12:36:38) cron2: I find this exciting, but have no clue on "how to do IBB vs 
OSTIF" in a way that causes little friction and much benefit
(12:36:39) syzzer: did sounds like we need to formalize our process a bit more 
(12:36:44) cron2: yes
(12:37:26) mattock: I can reach out to Derek at OSTIF to see if we could have 
an arrangement where both IBB and OSTIF would support us but in different ways
(12:38:07) mattock: OSTIF has several non-bug-bounty related goals for OpenVPN 
(12:38:22) dazo: yeah, makes sense.  I have no strong opinions here either way. 
 Whatever encourages people to hack on our code and fix it is appreciated.
(12:38:27) cron2: +1
(12:38:43) mattock: ok, I will do that and we can move on
(12:38:55) mattock: #2: Update on control channel optimization (cron2, syzzer) 
(12:39:13) cron2: that is 3, and the other gert
(12:39:23) syzzer: (I just updated the page)
(12:39:35) mattock: oh
(12:39:54) mattock: so #2: Putting CloudFlare on front of community.openvpn.net 
and forums.openvpn.net? 
(12:40:06) mattock: raidz asked about this - we can do it if we want
(12:40:11) mattock: opinions?
(12:40:33) syzzer: I guess it means SSL termination by cloudflare?
(12:40:37) mattock: yes it does
(12:40:45) mattock: that was one of the original reasons why we didn't do it
(12:41:03) mattock: we also disabled cloudflare on trac because it was forcing 
useless captchas on users
(12:41:04) cron2: so why do we want to do it now?
(12:41:15) mattock: we probably don't, but I promised to ask
(12:41:22) syzzer: not my favourite, but since basically all information is 
public anyway (and I don't reuse passwords ;) ) I don't have any objections
(12:41:33) cron2: (I have no idea about the load situation, costs, etc., so 
totally naive "what is the benefit, what are the costs?")
(12:41:57) mattock: I can ask about the benefits in our case
(12:42:06) mattock: some pages would load faster I guess
(12:42:17) mattock: not sure how cloudlare handles dynamic content like phpbb 
or trac
(12:42:29) cron2: generally speaking unless there is benefit, I'm always 
sceptical about "change for change's sake" :) - but then, I do not use forums, 
and community has always been "fast enough" for me.
(12:42:35) mattock: I'll make some queries and we can come back to this
(12:42:36) mattock: agreed
(12:42:55) mattock: if there is no clear benefit we can continue not having 
(12:43:04) syzzer: mattock: sounds good, I'm fine with whatever your decide 
(12:43:10) mattock: next topic: #3 Update on control channel optimization 
(gertvandijk, syzzer) 
(12:43:21) syzzer: yeah, short status update
(12:43:22) dazo: one benefit is that cloudflare could stop various attacks 
before hitting our servers directly
(12:43:27) cron2: #2 -> ok
(12:43:43) dazo: (but that's the only benefit I see .... moving on now)
(12:44:01) syzzer: as recommended by plaisthos, we (mostly gertvandijk) are 
looking into implementing LEDBAT for the control channel
(12:44:20) cron2: that is one of the TCP congestion avoidance algorithms?
(12:44:29) syzzer: cron2: yes, a simple one
(12:44:36) syzzer: it's used by bittorrent
(12:45:07) syzzer: I think the big downside is that it needs a wire protocol 
change, but we have a concept to do that gracefully
(12:45:12) dazo: and this can happen over the same socket as now?  or do we 
need a separate connection in parallel?
(12:45:46) syzzer: dazo: same socket, but adding microsecond timestamps (32 
bit) to the packet IDs on the control channel
(12:46:07) dazo: okay ... that's reasonable
(12:46:10) cron2: protocol changes!  That will need an RFC update!
(12:46:15) dazo: :)
(12:46:18) cron2: (just making silly noises in the background)
(12:46:29) dazo: LEDBAT in practice :-P
(12:46:29) cron2: syzzer: changing opcodes?
(12:46:35) syzzer: since this is gerts first encounter with the multi, forward 
and all related stuff, it takes a bit of time to get a first prototype
(12:46:42) syzzer: cron2: no, no opcode changes
(12:46:52) syzzer: we're aiming at fully backwards compatible
(12:46:57) cron2: so how's the plan to change the wire format without breaking 
(12:47:25) syzzer: add a 'flags' field after the P_CONTROL_HARD_RESET packet
(12:47:40) syzzer: current implementations ignore any data in those packets
(12:47:52) cron2: sounds good
(12:47:56) dazo: interesting ... that sounds like it could work
(12:48:23) dazo: syzzer: have you mentioned this with James?
(12:48:26) syzzer: looks like it is going to work
(12:48:46) cron2: (of course then we're back to tincantech's favourite "replace 
a 2.5 server with a 2.4 server, and clients won't notice and it will not work")
(12:48:51) syzzer: dazo: no - only at the hackathong, when it was not clear yet 
how we would do this
(12:49:14) dazo: syzzer: okay ... would be good to give him a heads up and 
check if he sees potentials issues here
(12:49:24) syzzer: cron2: yes, that is a scenario we need to think about
(12:49:35) dazo: if anyone can predict how it can explode things, James is my 
best bet :)
(12:49:51) syzzer: dazo: yeah, but I think we should wait a little longer, 
until we have some numbers
(12:50:00) dazo: fair enough
(12:50:40) syzzer: I would still really like it if we can come up with a simple 
algorithm that doesn't need wire proto changes, but that might be not 
(12:50:58) syzzer: just wanted to share where we are right now :)
(12:51:22) dazo: thx! This does indeed sound promising .... while understanding 
that this is pre-PoC phase :)
(12:51:30) syzzer: so unless there are more questions, that's it for this topic 
as far as I'm concerned :)
(12:51:43) mattock: ok
(12:52:01) dazo: Perhaps I could just shoot in a few words on the OpenVPN 3 
Linux client, before patchwork?
(12:52:09) mattock: I suggest we discuss FIPS briefly: the author just wanted 
to verify that we are interested in the FIPS patches
(12:52:16) dazo: sure
(12:53:01) mattock: so are we? :)
(12:53:21) syzzer: yeah, as long as it's not intrusive (looks like it's not) 
I'm fine with patches for openssl-fips-mode support
(12:53:23) mattock: the author obviously did not want to produce more patches 
if FIPS-compliance is not important for us
(12:53:24) dazo: Yes, FIPS is definitely interesting ... even though the 
security parameters in FIPS can be somewhat questionable at times ... it can 
help gov adaptation as FIPS won't be a blocker
(12:53:40) dazo: and in those market segments FIPS compliance is crucial
(12:53:41) mattock: ok, so it's just about "lack of time to review" at this 
(12:53:45) dazo: yes
(12:53:47) mattock: ok, good
(12:54:02) mattock: that's all I need to know - let's do the OpenVPN 3 linux 
client next
(12:54:07) syzzer: mattock: yeah, It's on my radar, but not very high prio
(12:54:17) ordex: argh 
(12:54:25) ***ordex just woke up
(12:54:31) dazo: I'm going to release a brand new OpenVPN 3 Linux client for 
the community tomorrow or Friday
(12:54:32) syzzer: haha
(12:54:34) ordex: mbedTLS sucked all my energy until late night yesterday
(12:54:40) cron2: wrt FIPS - I think that patch is fairly easy, though
(12:54:43) syzzer: dazo: cool!
(12:54:51) cron2: questionable is only the documentation
(12:54:54) dazo: It will be a very different client than openvpn2 ... so you're 
aware of that
(12:55:11) cron2: dazo: which is a good thing :)
(12:55:16) mattock: also note that while it is called "the linux client" it 
should run fine on FreeBSD at least
(12:55:25) mattock: the amount of dependencies is not that large
(12:55:25) ***cron2 has doubts about that
(12:55:39) dazo: Right now I'm finalizing an openvpn2 front-end which tries to 
"look like" our known openvpn 2.x ... but with only support for client options
(12:55:41) mattock: cron2: I have my doubts also for the _initial_ version
(12:55:42) cron2: but you have vagrant boxes to test... (no systemd, no dbus, 
(12:56:10) mattock: cron2: dbus is actually available for freebsd and does not 
pull in gnome or anything huge as dependencies
(12:56:15) mattock: I was surprised about that actually
(12:56:21) dazo: Currently this Linux client only depends on dbus (no systemd 
requirements) ... which is available on most BSDs
(12:56:33) cron2: having a good and fully integrated *Linux* client in 3 sounds 
useful, and all other platforms can do 2.x just fine, I'd say...
(12:56:35) dazo: (but probably not installed, unless you have some more 
advanced desktop environments)
(12:56:36) mattock: yeah let's not bake in hard dependencies to systemd :P
(12:56:56) dazo: I do try to avoid a hard systemd dependency
(12:57:16) cron2: not sure anyone actually does GUI on FreeBSD, and would 
appreciate a nice and shiny new client :) - but I might be wrong
(12:57:35) cron2: I see FreeBSD more on the server side of things
(12:58:03) dazo: The next challenge, which will be resolved next year is DNS 
configuration .... I've barely started looking into various D-Bus services 
already present (NetworkManager, systemd's networkd) ... and will try to find a 
path which is flexible enough to not be hardcoded against a specific network 
config tool
(12:58:49) dazo: cron2: This client does not depend on GUI at all .... GUI is 
something we need to think about in a bit
(12:59:20) dazo: the design details is that there is a backend part (logging, 
configuration and session management as well as the VPN tunnels itself) ... all 
of that is managed over D-Bus
(12:59:45) dazo: and then front-ends, which the users interact with are 
essentially just D-Bus clients ... and can be written in any languages, console 
or GUI or whatever
(13:00:22) dazo: the backends takes care of privilege separation and all that 
... and D-Bus policies dictates whom can do what with the backend services
(13:00:47) syzzer: dazo: sounds like "interactive service for *nix" ?
(13:01:55) dazo: syzzer: yeah, you could say that ... but just using standard 
communication libraries and APIs for client implementations
(13:02:37) dazo: now .... there are some challenges ahead with configurations 
though .... not all openvpn 2.x options are supported
(13:02:41) dazo: no static key tunnels
(13:02:53) dazo: no server support (yet)
(13:03:28) dazo: of over 260 options (approx) in OpenVPN 2 .... only approx 60 
are supported by OpenVPN 3
(13:03:45) dazo: this is not strictly this Linux client implementations fault, 
but more the OpenVPN 3 Core library
(13:04:08) syzzer: that could actually be a feature :p
(13:04:13) dazo: hehehe :-P
(13:04:16) dazo: yeah, true :)
(13:04:20) ordex: yeah :D
(13:04:33) syzzer: 3.x sounds like good milestone to deprecate/drop stuff
(13:04:42) dazo: some options we need to consider .... like --fragment 
(13:05:01) cron2: fragment is important, unfortunately
(13:05:07) dazo: yeah
(13:05:39) dazo: but ... this is a good starting point, I think .... and at 
least a functional client which people can start hacking on
(13:06:58) ordex: dazo: about the missing options: we could also have some kind 
of todo list, so that people know what's missing and may start sending 
contributions to implement those of higher interest for them
(13:06:59) dazo: so, that's all from me now - to avoid taking too much time ... 
unless there are questions :)
(13:07:18) dazo: ordex: good point!  I'll add that to the git repo
(13:07:30) dazo: (or a wiki page)
(13:07:43) ordex: after all we are not "substituting" openvpn2, therefore we 
don't need to reach feature completeness before other people get their hands on
(13:07:45) chipitsine: (or git issue tracker)
(13:07:45) syzzer: dazo: well, maybe maintainers.  will you be maintaining the 
project on gh or so?
(13:08:05) dazo: I'll push this out to GitLab and GitHub
(13:08:17) dazo: and I'll be the main maintainer for now
(13:08:32) syzzer: make sure to add a README that describes how you accept 
(13:08:38) dazo: +1
(13:10:33) syzzer: okay, /me out for lunch then :)
(13:10:39) dazo: enjoy!
(13:10:42) syzzer: thanks
(13:10:49) cron2: enjoy
(13:11:01) mattock: have a good one!
(13:11:14) mattock: any patches in patchwork you want to tackle today?
(13:11:20) ***cron2 <- not
(13:11:55) dazo: I have enough on my plate with the ovpn3 client release for 
this week :)
(13:12:19) ordex: I promised I'd tackle the ipv6 patch + the patchset about 
(13:12:20) ***cron2 has cristmas, end-of-year "we still have budget!!!" 
customers, and family
(13:12:34) mattock: I think VLAN patches will remain on the topic list for a 
while, and there's no need to discuss them right now
(13:12:34) cron2: oh, and tax paperwork (finished today, yay)
(13:12:35) ordex: "throw the budget here!!"
(13:12:41) cron2: +1
(13:12:56) mattock: meeting concluded then
(13:12:58) dazo: agreed, VLAN patches can stay on the list
(13:13:00) dazo: yeah
(13:13:21) mattock: what about next meeting? should we skip it?
(13:13:25) mattock: 27th
(13:13:34) mattock: I have a bunch of stuff on that day
(13:14:03) dazo: I'll be on Christmas holiday officially from Dec 23rd until 
early January 
(13:14:49) dazo: (I might follow up on some things if they look interesting 
enough during those days, but no promises)
(13:14:51) mattock: I have to consider doing something similar, as the HQ also 
has holidays around the same time
(13:15:01) mattock: I  vote "skip next week's meeting"
(13:15:18) ***ordex shuts up because he skipped this one too
(13:15:40) dazo: Let's aim for Jan 3rd or 10th
(13:15:44) mattock: ordex: not entirely
(13:15:47) mattock: 3rd is fine for me
(13:16:20) ordex: I am not personally sure about the 3rd because I might be 
out, but we can aim for that. I'll let you know later
(13:16:30) mattock: ordex: sounds good
(13:16:36) mattock: cron2: opinions about 3rd?
(13:16:43) cron2: phone
(13:16:53) dazo: I might not work that week, but can probably sneak away far an 
hour or so
(13:28:50) mattock: I will postpone sending the summary until cron2 responds -> 
lunch :)
(13:28:54) L'account è disconnesso e non sei più in questa chat. Sarai 
reinserito in questa chat alla riconnessione dell'account.
(14:31:07) L'argomento di #openvpn-meeting è: Agenda at 
(14:31:07) L'argomento per #openvpn-meeting è stato impostato da cron2 a 
12:34:39 su 20/12/2017
(14:31:07) ***: Buffer Playback...
(14:31:07) ordex: [11:31:08] enjoy !
(14:31:07) cron2: [11:32:48] back
(14:31:07) cron2: [11:33:21] mattock: 3rd should work.  I might be boarding :)
(14:31:07) syzzer: [12:21:07] 3rd is good for me :)
(14:31:07) ***: Playback Complete.
(14:31:28) mattock: cron2, syzzer: noted, sending summary
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Openvpn-devel mailing list

Reply via email to