-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
Here's the summary of the previous IRC meeting. - --- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday 23rd Oct 2014 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2014-10-23> Next meeting has not been scheduled but will be on the same weekday and time. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY cron2, Hes, lev, jamesyonan and mattock participated in this meeting. - -- Discussed the OpenVPN 2.3.5 release. Cron2 will integrate the tap-windows6 fixes a.s.a.p. after which mattock will make the release. - -- Discussed the "session-id implementation" patch: <http://thread.gmane.org/gmane.network.openvpn.devel/8403> Agreed that session-id should be renamed peer-id. The patch got a feature-ACK. Jamesyonan will give the patch a thorough code review (and hopefully code-ACK it). Decided to implement server-side floating in a separate patch if/when it's required to keep things simple. - -- Discussed the upcoming Munich hackthon: <https://community.openvpn.net/openvpn/wiki/MunichHackathon2014> There are several things that should be discussed, such as - - OpenVPN 2.4 - - OpenVPN 3.x + CLA - - Multithreading - - AEAD Full chatlog is attached. - -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRJWlgACgkQwp2X7RmNIqOopACgsr8UPqcfxhgcJimcGz6F4Pcz nxQAoIy2BD45Iw13vr7ESrdhg4Foxv+5 =KKw8 -----END PGP SIGNATURE-----
(21.03.55) mattock: ready? (21.04.02) lev__: yep (21.04.10) mattock: who do we have here today? (21.04.22) mattock: lev, cron2, me... (21.04.32) mattock: syzzer won't be (21.04.41) mattock: james should be here soon (21.05.45) audience_x [~audien...@85-23-34-38.bb.dnainternet.fi] è entrato nella stanza. (21.07.08) Hes: Boing, me. (21.07.23) mattock: I'll remind James (21.09.43) jamesyonan [~jamesy...@c-67-166-32-18.hsd1.co.comcast.net] è entrato nella stanza. (21.09.43) modalità (+o jamesyonan) da ChanServ (21.09.47) cron2: hi james (21.09.56) jamesyonan: hi cron2 (21.10.06) mattock: session ID patch first? (21.10.20) ***cron2 looks for the agenda (21.10.35) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2014-10-23 (21.10.37) cron2: found (21.10.38) vpnHelper: Title: Topics-2014-10-23 – OpenVPN Community (at community.openvpn.net) (21.13.29) cron2: I think we can handle 2.3.5 first, because that's quick and easy :-) - I'll integrate the windows tap fixes ASAP (planned to do yesterday, tax paperwork got in the way), then I'll tag and you release (21.13.59) cron2: the new stuff in there is all minor, but useful, so no major test effort needed - quick smoketest before publishing the windows installers (21.14.06) cron2: (and make sure you have the $PATH fix :) ) (21.14.25) mattock: sounds good (21.14.32) mattock: the path fix is there (21.14.39) mattock: in the fixed mingw packages that is (21.14.41) mattock: sorry, nsis (21.14.55) cron2: great :) (21.15.11) mattock: next topic then :) (21.15.35) cron2: --tls-version-max is out, as syzzer isn't here to argue the point (21.15.52) cron2: leaves session id, I think - is plaisthos around? (21.17.18) mattock: james: have you had a look at the session id patch? (21.17.28) mattock: http://thread.gmane.org/gmane.network.openvpn.devel/8403 (21.17.32) vpnHelper: Title: Gmane Loom (at thread.gmane.org) (21.17.39) cron2: mattock: is 8403 the one from today? (21.17.47) lev__: has anyone tried it (besides me) ? (21.18.01) cron2: lev__: this is why I was asking for plaisthos :) (21.18.20) mattock: cron2: probably not (21.18.44) cron2: lev__: but what we need is buy-in from James :-) - so maybe you could quickly explain what you did (which isn't exactly what we envisioned, but with reason) as James would have to add it to OpenVPN 3 clients for it to make sense (21.19.24) lev__: sure (21.19.47) lev__: so I added P_DATA_V2, with 1 byte opcode and 3 bytes for session_id (21.20.29) lev__: server has int array[MAX_CLIENTS] of sessions (21.21.12) cron2: it should be pointed out that this is "just a numeric ID" and not the TLS ID (21.21.14) lev__: when client connects, server assigns next free session_id (0, 1, 2.. max-clients-1) and sends it with push_reply (21.22.12) jamesyonan: just so I understand this, the net cost of this approach is that we are adding 3 more bytes to every packet? (21.23.04) cron2: my idea was to send the +3byte packet only every now and then, but the initial implementation does it for every packet, yes (21.23.16) cron2: lev__: only for client->server packets, or *every* packet? (21.23.33) jamesyonan: or are we only adding the 3 bytes to P_DATA packets? (21.23.43) cron2: P_DATA -> P_DATA_V2 (21.24.22) jamesyonan: so then P_DATA_V2 packets are the only packets that have the extra 3 bytes? (21.24.43) lev__: then client uses P_DATA_V2 for every data packet. When packet arrives to the server, it gets session by array lookup (instead of hash lookup) and checks if client ip/port changed. If yes, then server verifies hmac and, if success, updates client ip/port in internal structures (21.25.06) lev__: p_data_v2 for client->server only (21.25.27) lev__: I assume that server won't float :-/ (21.25.43) cron2: reasonable assumption :) (21.25.46) jamesyonan: it's not unheard of :) (21.26.18) Hes: Back. Silly LTE. (21.26.22) audience_x ha abbandonato la stanza (quit: Remote host closed the connection). (21.27.14) lev__: I have tested with mobile client and it switches seamlessly between wifi/3g, also UDP NAT timeout is not an issue anymore (21.28.22) lev__: implementation is backward compatible with old (well, existing) clients/servers (21.29.16) jamesyonan: originally I was thinking that it sort of sucks to have to be bloating the protocol with 3 more bytes for every data channel packet, but I do like the way that it solves alignment issue, and I'm also thinking that because of other unrelated changes (such as availability of AEAD ciphers) we might be able to make up the 3 bytes in other ways so we don't have a net increase (21.30.51) Hes: With the mobile clients, and UDP/NAT, floating between networks is pretty common, sending the session ID very often (or always) makes for really smooth sessions. (21.31.45) cron2: remind me again: what is an openvpn "ping" packet? Is that data or control? (21.32.02) cron2: (read: if there is no activity on the client side except --ping, will that work, or not)? (21.32.17) Hes: I've been reviewing the patch, found the bytesex bug which would have broken it when talking between different endianness machines. But that's now fixed. (21.32.49) jamesyonan: I'm actually leaning more towards the approach of, if we include the session ID, of always sending it rather than having the added complexity of an adaptive algorithm that decides whether or not to send it (21.33.10) Hes: The "ping" packet is sent on the same ipaddr:port <> ipaddr:port tuple as data. (21.33.22) cron2: Hes: yes, but is it a control packet or P_DATA? (21.33.33) cron2: (inside OpenVPN) (21.33.36) jamesyonan: ping packet is P_DATA (21.33.55) Hes: In case of a quick NAT timeout, a quick ping timeout seems to help in keeping NAT sessions open. But that consumes battery. (21.33.56) cron2: james: thanks. So that would also nicely work out (21.34.05) jamesyonan: it's a special sequence of magic numbers that can't be confused with an IP or eth packet (21.34.57) Hes: With the session ID, and a "normal mobile device" use case, the ping timer can be increased. It'll still be needed to figure out things like a server restart or other need to switch to another server. (21.34.57) cron2: Hes: understood. Thing is that if the client isn't actually sending anything (so no "P_DATA_V2 with session ID") the pings would still have the desired effect, instead of getting lost due to other packet format -> non-issue (21.35.09) cron2: as far as bytesex goes: this is *not* the right fix in the current patch: (21.35.12) cron2: + sess = htonl(((P_DATA_V2 << P_OPCODE_SHIFT) | ks->key_id) << 24 | (21.35.16) cron2: +(multi->vpn_session_id & 0xFFFFFF)); (21.35.18) cron2: + ASSERT (buf_write_prepend (buf, &sess, 4)); (21.35.47) cron2: or will it? (21.35.54) cron2: rollback, ignore what I said (21.36.34) cron2: it was too complicated for me, but indeed, doing the bit shifting inside and the htonl outside will ensure the opcode will always end on byte[0] (21.36.43) cron2: sorry for the noise (21.36.55) Hes: It is a bit hairy indeed. But it seems like it does the right thing. (21.37.26) jamesyonan: I believe if you do an htonl on the leading 4 bytes of the raw ovpn packet, that the leading op byte will be the high part of the uint32 and the lower 24 bits will be the session id (21.37.43) jamesyonan: so that works out (21.37.44) lev__: jamesyonan: could you clarify "we should send session ID always" (21.38.07) cron2: jamesyonan: ACK, this is what I believe now as well, spoke too fast (21.38.28) jamesyonan: i.e. don't switch between P_DATA_V1 and V2 in the same session (21.39.31) cron2: I was the one who had complicated switch back and forth plans, but the argument "less complexity" is convincing :) (21.39.52) lev__: but this implementation is not supposed to switch (21.40.16) Hes: + "immediate remedy when needed" instead of "try to recover a bit later with a retry" (21.40.16) cron2: lev__: no, this was based on the concept model we discussed before you went coding (21.40.22) lev__: ah ok (21.40.38) mattock: will be away for 10-15 mins... (21.40.50) cron2: your patch definitely looks like "if it switches, it will stay there", trading 3 bytes vs. algorithmic heuristics (21.40.57) lev__: it is always good to start coding before familarizing with concept! (21.41.00) jamesyonan: the problem is if you switch, you then have to deal with the alignment issue more adaptively because you don't know until you've read the packet whether it's V1 or V2 (21.41.04) L'account è stato disconnesso e non si è più in questa conversazione. Sarà possibile ritornare nella conversazione automaticamente quando l'account verrà riconnesso. (21.53.38) L'argomento di #openvpn-devel è: OpenVPN developers channel | For configuration and user support, please go to #openvpn | See !git, !snapshots or !meetings for more info | cron2_> mmmh, this openvpn thingie is actually useful (21.53.38) Argomento per #openvpn-devel impostato da krzee!~k@openvpn/community/support/krzee alle 02.10.21 il 01.10.2014 (21.53.38) ***: Buffer Playback... (21.53.38) jamesyonan: so I would tend to lean against adaptive switching (21.53.38) jamesyonan: so with typical usage of AES CBC mode with HMAC-SHA1 our overhead will be 4 (op + session ID) + 20 (HMAC) + 16 (IV) + 4 (packet ID) = 44 bytes (21.53.38) lev__: small correction - I said that server sends session ID with push_reply. Surely it is peer info. (21.53.38) cron2: no, it's push reply (21.53.38) lev__: hm (21.53.38) cron2: peer info is client->server with "IV_PROTO=2" (21.53.38) lev__: oh right, I was looking on client part (21.53.38) cron2: push.c, send_push_reply :-) "if peer_info contains IV_PROTO and proto >=2" (21.53.38) jamesyonan: also, be careful about session ID and push, because there's already a session ID in OpenVPN that's used for a different purpose (21.53.38) cron2: maybe rename it? "client-id"? (21.53.38) Hes: does it need some terminology / variable name adjustment then (21.53.38) cron2: "instance-id" (21.53.38) jamesyonan: how about peer_id (21.53.38) Hes: +1 for peer_id (21.53.38) jamesyonan: since it's being used in P_DATA_V2 which could conceivably be generated by either client or server (21.53.38) jamesyonan: and there's no existing peer_id symbol in OpenVPN code right now (21.53.38) cron2: we might end up supporting floating servers one day :) (21.53.38) lev__: it is currently generated by server, meaning is position in sessions array (21.53.38) cron2: peer_id is good for me (21.53.38) Hes: Hm, if the server would be improved to float, I suppose an unmodified client might just support that with this code? :) (21.53.38) Hes: right, client does not have the equivalent array (21.53.38) cron2: Hes: no, as the "who does this packet belong to?" logic isn't called in client mode (21.53.38) cron2: some extention might be needed ("P_DATA_V2, not who I expected to talk to? hash ok? update peer!") (21.53.38) Hes: but, in the now-common world of dualhomed IPv4/IPv6 mobile devices, where IPv6 is a globally routable public IP address and IPv4 is NATed, floating between those might actually be cool later (21.53.38) cron2: lev__: understood, thing is, there is TLS session ID, so "session id" will cause confusion eventually. "instance-id" describes the current implementation, but "peer_id" is more neutral regarding "what is in there, what does it reflect"? (21.53.38) Hes: in case one or the other has a hickup, would be nice to be able to switch, like SCTP (21.53.38) cron2: Hes: ack. Eventually :) (21.53.38) Hes: Eventually. (21.53.38) lev__: cron2: right, I should rename those in my wetware (21.53.38) ***: Playback Complete. (21.53.47) Sei ora conosciuto come mattock (21.57.58) mattock: have we reached some sort of conclusion? (21.57.59) mattock: :P (21.58.00) cron2: so, how do we proceed with this patch? I think it warrants a re-spin renaming "session-id" to "peer-id" in push and C structs, and then "someone" needs to review... (21.58.14) cron2: mattock: good timing. Always the impatient one :) (21.58.18) lev__: I can do the first part (21.58.25) mattock: even more impatient than you? (21.58.27) mattock: :) (21.59.37) cron2: Jamesyonan: can you review the hash-relevant code path changes? I'm fine with the push/option/peer_info stuff (skimmed through it, looked good, will do a more thorough review on the next round) but do not feel fully comfortable with the "inside workings" there (21.59.41) Hes: I've reviewed, but it's a rather involved change set, needs a good set of reviews. And maybe some tests in a test suite. (21.59.59) audience_x [~audien...@85-23-34-38.bb.dnainternet.fi] è entrato nella stanza. (22.00.36) lev__: about server floating - should this be implemented to get ACK? or can it be done as a separate patch? (22.00.36) cron2: Hes: the fun of it... "use --bind, change NAT rules while test is running"... t_client.sh is not smart enough yet to do that :) (22.00.57) jamesyonan: cron2: yes, I'm looking at the patch now (22.01.15) jamesyonan: I think server floating should be a separate patch (22.01.17) cron2: lev__: separate, not right now. This one is a big step that solves an immediate need, we can do the next round when the use case exists (22.03.00) audience_x ha abbandonato la stanza (quit: Remote host closed the connection). (22.03.12) Hes: yeah, would be nice to get this forward without making it any bigger than it already is (22.09.39) jamesyonan: I'm going to need more time to review, but I assume we'll be seeing another iteration shortly with the session_id -> peer_id change... (22.11.02) cron2: lev__: you turn :) (22.11.05) cron2: your (22.11.45) lev__: sure, I can do it tomorrow (22.12.02) lev__: (getting too dark today) (22.12.26) mattock: ok (22.12.30) mattock: munich next? (22.12.53) cron2: yeah, this is cool, progress :-) (22.12.56) cron2: Munich next (22.13.05) cron2: http://community.openvpn.net/openvpn/wiki/MunichHackathon2014 (22.13.07) vpnHelper: Title: MunichHackathon2014 – OpenVPN Community (at community.openvpn.net) (22.13.13) mattock: cron2: the stage is yours (22.13.33) cron2: did I put it onto the agenda? (22.13.36) cron2: anyway. (22.13.53) mattock: so basically goals and plans is what I wrote there (22.14.05) mattock: what's the goal besides meeting and having useful discussions? (22.14.09) cron2: munich coming up soon, room is booked, wife knows what is coming up :-) (22.14.35) cron2: I really want to get the windows interactive service done, but d12fk has not formally confirmed that he'll come (22.14.59) cron2: and besides that - meet, have useful discussions, hack on the code, enjoy food & drinks :) (22.15.02) mattock: yep, the interactive service thing is quite a bit overdue (22.15.20) mattock: suppose that d12fk won't be there, and interactive service won't be there (22.15.32) mattock: shall we go and release 2.4 without it? (22.16.05) lev__: any sessi(grrr.. peer) ID related things planned for Munich? It is mentioned on a trac page (22.16.20) cron2: I assume he'll be there or we'll at least get his code (and if I have to haunt him personally, it's just a 3-hour drive) (22.16.36) mattock: stalking is one option, yes (22.16.37) mattock: :P (22.16.49) cron2: lev__: nah, *that* goes in "as soon as reviewed!" now, as we seem to be all in agreement that the approach is fine (22.17.11) cron2: lev__: so I think you have your feature-ACK (after renaming) just need the code-ACK as well :-) (22.17.21) ***lev__ dances (22.17.33) mattock: nice! (22.17.52) cron2: mattock: there will be work to do, things to clarify (like, the CLA), ideas to bounce around (like, multithreading :) or AEAD) (22.18.11) cron2: and if we run out of things to do, I'll just distribute trac tickets (22.18.15) mattock: yeah, world won't be ready by then (22.18.31) mattock: actually trac tickets alone would be enough to keep everyone occupied (22.18.40) mattock: so no worries about having to just eat and drink (22.18.42) mattock: :) (22.18.54) cron2: yeah, but face-to-face time is too valuable to start with trac (22.19.07) mattock: yep, it's a bit boring (22.19.17) mattock: and does not make best use of face-to-face communications (22.20.15) lev__: is that event still limited to "active developers that are also regularily contributing" (22.21.37) cron2: well, it's not a user meeting :-) - this was the intention of the quoted statement (22.22.32) cron2: but "regularily" is a very vague term (*look at d12fk*) :-) - so if you feel like coming, you're welcome (22.22.55) lev__: thanks, let's see if I could make it (22.24.57) cron2: the meeting room can comfortably take about 7-8 people "with gear", but Sat/Sun we have the whole office area for us, so we'd form smaller sub-groups or such to focus (22.28.19) cron2: that's from me for munich - anyone else? (22.29.56) jamesyonan: I think I'll be able to make it (22.30.03) cron2: cool :) (22.31.31) lev__: maybe while people are here, I can ask - what about using inotify to get result of auth-user-pass-verify (and client-connect) instead of checking acf files on incoming request / timeout (22.31.50) mattock: lev: it would great if you could make it! (22.31.55) mattock: the more the merrier (22.33.12) cron2: lev__: spontaneously I'd say "portability" given that not all supported OSes have this and/or it needs extra libraries. But I'm too tired today to really think through it and understand the picture (sorry) (22.33.48) lev__: http://sourceforge.net/p/openvpn/mailman/message/32906587/ (22.33.49) vpnHelper: Title: OpenVPN / Mailing Lists (at sourceforge.net) (22.34.15) mattock: that said, most of the guys are here on a daily basis (22.34.55) mattock: so this is not like the last chance to get an answer :) (22.35.12) cron2: lev__: yeah that thread is still sitting in my mailbox :-) - dazo is the one to think about the async plugin stuff, and I'm the one to worry about portability and adding #ifdefs and the implication of that for testing (22.35.44) lev__: yep I understand. I have sent this patch some time ago, would be nice if someone could take a look (22.36.45) ***cron2 calls it a day and gives up - sorry, it was a really tough day, falling asleep. But this was a good meeting. (22.37.13) mattock: lev: you probably have to push a bit (22.37.38) mattock: when we don't immediately find time to review patches they often are forgotten about by mistake (22.37.49) mattock: so sending a friendly reminder usually helps
openvpn_irc_meeting_chatlog_2014-10-23.txt.sig
Description: PGP signature
