)]}'
{"id":"openvpn~507","triplet_id":"openvpn~master~I01e258e97351b5aa4b9e561f5b35ddc2318569e2","project":"openvpn","branch":"master","topic":"datav3","attention_set":{},"removed_from_attention_set":{"1000003":{"account":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"last_update":"2024-09-30 12:54:57.000000000","reason":"Change was abandoned"},"1000001":{"account":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"last_update":"2024-09-10 11:47:22.000000000","reason":"removed on reply"},"1000008":{"account":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"last_update":"2024-09-30 12:54:57.000000000","reason":"Change was abandoned"}},"hashtags":[],"change_id":"I01e258e97351b5aa4b9e561f5b35ddc2318569e2","subject":"Implement support for larger packet counter sizes","status":"ABANDONED","created":"2024-01-25 12:38:13.000000000","updated":"2024-09-30 12:54:57.000000000","total_comment_count":68,"unresolved_comment_count":0,"has_review_started":true,"meta_rev_id":"4dc8e82d4994d230f4ccb227084819971d36b05f","_number":507,"virtual_id_number":507,"owner":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"actions":{},"labels":{"Code-Review":{"approved":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"all":[{"value":2,"date":"2024-09-10 11:47:22.000000000","permitted_voting_range":{"min":-2,"max":2},"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"}],"values":{"-2":"This shall not be submitted","-1":"I would prefer this is not submitted as is"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me, approved"},"default_value":0}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"}],"CC":[{"_account_id":1000026,"name":"openvpn-devel","email":"openvpn-devel@lists.sourceforge.net","username":"openvpn-devel"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2024-01-25 12:38:14.000000000","updated_by":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"reviewer":{"_account_id":1000026,"name":"openvpn-devel","email":"openvpn-devel@lists.sourceforge.net","username":"openvpn-devel"},"state":"CC"},{"updated":"2024-01-25 12:38:14.000000000","updated_by":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"reviewer":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"state":"REVIEWER"},{"updated":"2024-07-31 14:12:10.000000000","updated_by":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"reviewer":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"state":"REVIEWER"}],"messages":[{"id":"646d0bac6c3058d2801f2e37ae18a64b9b1854ba","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-01-25 12:38:13.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"58c9ce8d6be735b780ecaced8f0f4bdaba1f2e4e","tag":"autogenerated:gerrit:setTopic","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-01-25 12:39:33.000000000","message":"Topic set to datav3","accounts_in_message":[],"_revision_number":1},{"id":"96f77f91e42116192f3c813e50db5a7d3f5d44b7","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-02-02 12:48:14.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"8cdf8c81e5231b2f99d61634dae9cddcae74e945","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-02-05 11:24:24.000000000","message":"Patch Set 2: Code-Review-1\n\n(11 comments)","accounts_in_message":[],"_revision_number":2},{"id":"9ab88ff8ef05e79a2c33c3c870695e47a4478747","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-02-05 12:24:14.000000000","message":"Patch Set 2:\n\n(8 comments)","accounts_in_message":[],"_revision_number":2},{"id":"036b022b7cbc08713738d920aeda0cd947ee5c39","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-02-09 14:52:54.000000000","message":"Patch Set 2:\n\n(16 comments)","accounts_in_message":[],"_revision_number":2},{"id":"2ef3d3c653e91b2b822b5cf1179aa9be6a491d79","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-02-09 14:59:26.000000000","message":"Uploaded patch set 3.\n\nOutdated Votes:\n* Code-Review-1 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR is:MIN\")\n","accounts_in_message":[],"_revision_number":3},{"id":"2c029016a94bf3343252beb6176492f9476884e2","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-03-18 15:54:38.000000000","message":"Patch Set 3: Code-Review-2\n\n(7 comments)","accounts_in_message":[],"_revision_number":3},{"id":"efe1c3df5d6d565eb8d19c2fab396b9cb9a62578","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-03-27 10:34:05.000000000","message":"Uploaded patch set 4.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n","accounts_in_message":[],"_revision_number":4},{"id":"f427ec580313da27acf6e5ce6710f6beba3c906f","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-03-27 10:40:22.000000000","message":"Patch Set 4:\n\n(5 comments)","accounts_in_message":[],"_revision_number":4},{"id":"777b1cca3866df557e69b1502fd38a953eb3d107","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-03-27 11:33:34.000000000","message":"Patch Set 4: Code-Review+1\n\n(1 comment)","accounts_in_message":[],"_revision_number":4},{"id":"e2daa5ad0a0f69df1cb2f9aa02bc231c52e2f165","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-04-29 15:50:24.000000000","message":"Uploaded patch set 5.\n\nOutdated Votes:\n* Code-Review+1 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR is:MIN\")\n","accounts_in_message":[],"_revision_number":5},{"id":"cf4730cbd4045d3e00ea746459a6d12e7af5da9a","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-04-30 11:34:53.000000000","message":"Patch Set 5: Code-Review-2\n\n(1 comment)","accounts_in_message":[],"_revision_number":5},{"id":"9e5111ed961146922a93ccdf7500cc7adaf0a165","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-04-30 12:13:15.000000000","message":"Uploaded patch set 6.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n","accounts_in_message":[],"_revision_number":6},{"id":"30d68c179f8f5f8e7473ae378698b666f9f9effc","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-07-12 12:15:34.000000000","message":"Patch Set 6: -Code-Review","accounts_in_message":[],"_revision_number":6},{"id":"7fa36718c520745470ce6c1d3f1498653aad19df","author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"date":"2024-07-31 14:12:10.000000000","message":"Patch Set 6: Code-Review+1\n\n(6 comments)","accounts_in_message":[],"_revision_number":6},{"id":"a0a9ebc3640d5fb13af29e85fb645f469a94320e","author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"date":"2024-08-01 11:57:59.000000000","message":"Patch Set 6:\n\n(1 comment)","accounts_in_message":[],"_revision_number":6},{"id":"e61fc92bea2b08e83cc357766cc31a27683e6fc8","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-08-01 12:12:34.000000000","message":"Patch Set 6:\n\n(3 comments)","accounts_in_message":[],"_revision_number":6},{"id":"94499b8414be63ec606baae4f7ee7d19e1f8232e","author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"date":"2024-08-13 10:53:31.000000000","message":"Patch Set 6: Code-Review-2\n\n(1 comment)","accounts_in_message":[],"_revision_number":6},{"id":"47a24fd9ce93c7946ce8b12dcfda7f71c5fafa39","author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"date":"2024-08-13 10:53:54.000000000","message":"Patch Set 6:\n\n(1 comment)","accounts_in_message":[],"_revision_number":6},{"id":"769f44187fe2740222a6fe82897f2bace6bfafd9","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-08-13 11:07:31.000000000","message":"Uploaded patch set 7.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n","accounts_in_message":[],"_revision_number":7},{"id":"9de7f1bef3c4873f2d8b6d99bf96de1f79549636","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-08-13 11:23:03.000000000","message":"Patch Set 7:\n\n(1 comment)","accounts_in_message":[],"_revision_number":7},{"id":"6161dbfd93b975bb9c043048e3ebe58749220542","author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"date":"2024-08-13 11:46:01.000000000","message":"Patch Set 7: Code-Review+1\n\n(1 comment)","accounts_in_message":[],"_revision_number":7},{"id":"7d7bb0f06edc51bda50aa9ac5fcd77611e9ca5ff","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"date":"2024-08-13 12:00:12.000000000","message":"Uploaded patch set 8: Patch Set 7 was rebased.\n\nCopied Votes:\n* Code-Review+1 (copy condition: \"changekind:NO_CHANGE OR **changekind:TRIVIAL_REBASE** OR is:MIN\")\n","accounts_in_message":[],"_revision_number":8},{"id":"d6ac93b6624ccad50b31e3680a3ebf5f38351961","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-08-14 13:16:57.000000000","message":"Patch Set 8: Code-Review+1\n\n(2 comments)","accounts_in_message":[],"_revision_number":8},{"id":"44ad079a2c91637926e2a68c463cda2b1bca14be","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"date":"2024-08-15 12:33:32.000000000","message":"Uploaded patch set 9: New patch set was added with same tree, parent tree, and commit message as Patch Set 8.\n\nCopied Votes:\n* Code-Review+1 (copy condition: \"**changekind:NO_CHANGE** OR **changekind:TRIVIAL_REBASE** OR is:MIN\")\n","accounts_in_message":[],"_revision_number":9},{"id":"17553a2a599ca1de28f7e9dc3e58d36b1d14e5b0","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-09-10 09:24:24.000000000","message":"Uploaded patch set 10.\n\nOutdated Votes:\n* Code-Review+1 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR is:MIN\")\n","accounts_in_message":[],"_revision_number":10},{"id":"315b8f43f024a49698f8cc8543bf918566ee5974","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-09-10 10:05:39.000000000","message":"Patch Set 10:\n\n(3 comments)","accounts_in_message":[],"_revision_number":10},{"id":"6d098f3c1bf1a35723a8543050370d14df217d22","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-09-10 10:37:11.000000000","message":"Patch Set 10: Code-Review+2","accounts_in_message":[],"_revision_number":10},{"id":"ffc85f166157bf1a853b269b3dfcf021b1fa20da","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-09-10 11:16:53.000000000","message":"Uploaded patch set 11.\n\nOutdated Votes:\n* Code-Review+2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR is:MIN\")\n","accounts_in_message":[],"_revision_number":11},{"id":"1b3d63da32761417a2b9b06d592f8e880ffbb501","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-09-10 11:47:22.000000000","message":"Patch Set 11: Code-Review+2","accounts_in_message":[],"_revision_number":11},{"id":"4dc8e82d4994d230f4ccb227084819971d36b05f","tag":"autogenerated:gerrit:abandon","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-09-30 12:54:57.000000000","message":"Abandoned\n\nNew version coming.","accounts_in_message":[],"_revision_number":11}],"current_revision_number":11,"current_revision":"451eec23510e86715dc90e2c34586fcfc92fdaa3","revisions":{"1eb1412505aa7f7a52aa11adc1d2b9378485450d":{"kind":"REWORK","_number":1,"created":"2024-01-25 12:38:13.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/07/507/1","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/07/507/1","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/1 \u0026\u0026 git checkout -b change-507 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/07/507/1","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/1 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"98b5efa86ad1b6d5e08f48262045439467744be3","subject":"Implement support for AEAD tag at the end"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-22 12:28:23.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-25 12:38:00.000000000","tz":60},"subject":"Implement support for larger packet counter sizes","message":"Implement support for larger packet counter sizes\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nThis introduces the 64bit packet counters for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any scenario since the other scenarios\nare all legacy.\n\nWhile we still keep the old --secret logic around we use the same\nweird unix timestamp + packet counter format to avoid refactoring the\ncode now and again when we remove --secret code but DCO\nimplementations are free to use just a single 64 bit counter. One\nother small downside of this approach is that when rollover happens\nand we get reordering all the older packets are thrown away since\nthe distance between the packet before and after the rollover is\nquite large as we probably jump forward more than 1s (or more than\n2^32 packet ids) forward. But this is an obscure edge that we can\n(currently) live with.\n\nChange-Id: I01e258e97351b5aa4b9e561f5b35ddc2318569e2\n"},"branch":"refs/heads/master"},"2ddc0066a66fdd848be5e722afc322f3db2ff896":{"kind":"REWORK","_number":2,"created":"2024-02-02 12:48:14.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/07/507/2","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/07/507/2","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/2 \u0026\u0026 git checkout -b change-507 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/07/507/2","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/2 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"3e6eebb21a2e9cdd3c7ef00a427f17330df707b3","subject":"Implement support for AEAD tag at the end"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-22 12:28:23.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-02-02 12:46:50.000000000","tz":60},"subject":"Implement support for larger packet counter sizes","message":"Implement support for larger packet counter sizes\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nThis introduces the 64bit packet counters for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any scenario since the other scenarios\nare all legacy.\n\nWhile we still keep the old --secret logic around we use the same\nweird unix timestamp + packet counter format to avoid refactoring the\ncode now and again when we remove --secret code but DCO\nimplementations are free to use just a single 64 bit counter. One\nother small downside of this approach is that when rollover happens\nand we get reordering all the older packets are thrown away since\nthe distance between the packet before and after the rollover is\nquite large as we probably jump forward more than 1s (or more than\n2^32 packet ids) forward. But this is an obscure edge that we can\n(currently) live with.\n\nChange-Id: I01e258e97351b5aa4b9e561f5b35ddc2318569e2\n"},"branch":"refs/heads/master"},"4ab329ee98901c6352335913d3b994c95ed0deba":{"kind":"REWORK","_number":3,"created":"2024-02-09 14:59:26.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/07/507/3","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/07/507/3","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/3 \u0026\u0026 git checkout -b change-507 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/07/507/3","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/3 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"fea1412e645410b9435600b17f769d982a2e7ee0","subject":"Implement support for AEAD tag at the end"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-22 12:28:23.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-02-09 14:59:16.000000000","tz":60},"subject":"Implement support for larger packet counter sizes","message":"Implement support for larger packet counter sizes\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nThis introduces the 64bit packet counters for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\n\nWhile we still keep the old --secret logic around we use the same\nweird unix timestamp + packet counter format to avoid refactoring the\ncode now and again when we remove --secret code but DCO\nimplementations are free to use just a single 64 bit counter. One\nother small downside of this approach is that when rollover happens\nand we get reordering all the older packets are thrown away since\nthe distance between the packet before and after the rollover is\nquite large as we probably jump forward more than 1s (or more than\n2^32 packet ids). But this is an obscure edge that we can\n(currently) live with.\n\nChange-Id: I01e258e97351b5aa4b9e561f5b35ddc2318569e2\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"02e1b85d154cfa1df26a90630b6b3c878a5e5813":{"kind":"REWORK","_number":4,"created":"2024-03-27 10:34:05.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/07/507/4","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/07/507/4","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/4 \u0026\u0026 git checkout -b change-507 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/07/507/4","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/4 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"25372beb9f29e62c62925233163f8e149ba1f410","subject":"Implement support for AEAD tag at the end"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-22 12:28:23.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-03-27 10:33:56.000000000","tz":60},"subject":"Implement support for larger packet counter sizes","message":"Implement support for larger packet counter sizes\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nThis introduces the 64bit packet counters for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\n\nWhile we still keep the old --secret logic around we use the same\nweird unix timestamp + packet counter format to avoid refactoring the\ncode now and again when we remove --secret code but DCO\nimplementations are free to use just a single 64 bit counter. One\nother small downside of this approach is that when rollover happens\nand we get reordering all the older packets are thrown away since\nthe distance between the packet before and after the rollover is\nquite large as we probably jump forward more than 1s (or more than\n2^32 packet ids). But this is an obscure edge that we can\n(currently) live with.\n\nChange-Id: I01e258e97351b5aa4b9e561f5b35ddc2318569e2\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"abe84c874af420b99da24f404a13c5d755cae006":{"kind":"REWORK","_number":5,"created":"2024-04-29 15:50:24.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/07/507/5","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/07/507/5","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/5 \u0026\u0026 git checkout -b change-507 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/07/507/5","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/5 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"abbf21bfd2fb55bb2cfcc4899f24cdf6a95ab515","subject":"Implement support for AEAD tag at the end"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-22 12:28:23.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-04-29 15:45:52.000000000","tz":120},"subject":"Implement support for larger packet counter sizes","message":"Implement support for larger packet counter sizes\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nThis introduces the 64bit packet counters for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\n\nWhile we still keep the old --secret logic around we use the same\nweird unix timestamp + packet counter format to avoid refactoring the\ncode now and again when we remove --secret code but DCO\nimplementations are free to use just a single 64 bit counter. One\nother small downside of this approach is that when rollover happens\nand we get reordering all the older packets are thrown away since\nthe distance between the packet before and after the rollover is\nquite large as we probably jump forward more than 1s (or more than\n2^32 packet ids). But this is an obscure edge that we can\n(currently) live with.\n\nWhile this implementation under hood allows one of the two\nto be enabled individually we do not expose this functionality\nbut require the two protocol flags aead-tag-end and pkt-id-64-bit\nto be always come together. This allows other data channel\nimplementations to only support a limited set of data channel\nformats.\n\nChange-Id: I01e258e97351b5aa4b9e561f5b35ddc2318569e2\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"a6d5d57c74652ce4886fc33f7fd97b908d9a78d8":{"kind":"REWORK","_number":6,"created":"2024-04-30 12:13:15.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/07/507/6","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/07/507/6","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/6 \u0026\u0026 git checkout -b change-507 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/07/507/6","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/6 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"e14e38d3e7d9bf8c056dc66a558a7f45db7567f8","subject":"Implement support for AEAD tag at the end"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-22 12:28:23.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-04-30 12:13:05.000000000","tz":120},"subject":"Implement support for larger packet counter sizes","message":"Implement support for larger packet counter sizes\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nThis introduces the 64bit packet counters for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\n\nWhile we still keep the old --secret logic around we use the same\nweird unix timestamp + packet counter format to avoid refactoring the\ncode now and again when we remove --secret code but DCO\nimplementations are free to use just a single 64 bit counter. One\nother small downside of this approach is that when rollover happens\nand we get reordering all the older packets are thrown away since\nthe distance between the packet before and after the rollover is\nquite large as we probably jump forward more than 1s (or more than\n2^32 packet ids). But this is an obscure edge that we can\n(currently) live with.\n\nWhile this implementation under hood allows one of the two\nto be enabled individually we do not expose this functionality\nbut require the two protocol flags aead-tag-end and pkt-id-64-bit\nto be always come together. This allows other data channel\nimplementations to only support a limited set of data channel\nformats.\n\nChange-Id: I01e258e97351b5aa4b9e561f5b35ddc2318569e2\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"32c2ab49129110e379ffc600f3ee77d7f02e2f04":{"kind":"REWORK","_number":7,"created":"2024-08-13 11:07:31.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/07/507/7","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/07/507/7","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/7 \u0026\u0026 git checkout -b change-507 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/07/507/7","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/7 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"958ba0e91bca718e4b8a95e0e4cd10679ecb7084","subject":"Implement support for AEAD tag at the end"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-22 12:28:23.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-08-13 10:58:13.000000000","tz":120},"subject":"Implement support for larger packet counter sizes","message":"Implement support for larger packet counter sizes\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nThis introduces the 64bit packet counters for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\n\nWhile we still keep the old --secret logic around we use the same\nweird unix timestamp + packet counter format to avoid refactoring the\ncode now and again when we remove --secret code but DCO\nimplementations are free to use just a single 64 bit counter. One\nother small downside of this approach is that when rollover happens\nand we get reordering all the older packets are thrown away since\nthe distance between the packet before and after the rollover is\nquite large as we probably jump forward more than 1s (or more than\n2^32 packet ids). But this is an obscure edge that we can\n(currently) live with.\n\nWhile this implementation under hood allows one of the two\nto be enabled individually we do not expose this functionality\nbut require the two protocol flags aead-tag-end and pkt-id-64-bit\nto be always come together. This allows other data channel\nimplementations to only support a limited set of data channel\nformats.\n\nChange-Id: I01e258e97351b5aa4b9e561f5b35ddc2318569e2\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"88328c521930b24c886dfbe60b875676e673d729":{"kind":"TRIVIAL_REBASE","_number":8,"created":"2024-08-13 12:00:12.000000000","uploader":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"ref":"refs/changes/07/507/8","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/07/507/8","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/8 \u0026\u0026 git checkout -b change-507 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/8 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/8 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/8 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/07/507/8","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/8 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"3a6ccbb602ef8fbf353293eb04aab3b1d6575a15","subject":"Implement support for AEAD tag at the end"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-22 12:28:23.000000000","tz":60},"committer":{"name":"Lev Stipakov","email":"lev@openvpn.net","date":"2024-08-13 11:42:29.000000000","tz":180},"subject":"Implement support for larger packet counter sizes","message":"Implement support for larger packet counter sizes\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nThis introduces the 64bit packet counters for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\n\nWhile we still keep the old --secret logic around we use the same\nweird unix timestamp + packet counter format to avoid refactoring the\ncode now and again when we remove --secret code but DCO\nimplementations are free to use just a single 64 bit counter. One\nother small downside of this approach is that when rollover happens\nand we get reordering all the older packets are thrown away since\nthe distance between the packet before and after the rollover is\nquite large as we probably jump forward more than 1s (or more than\n2^32 packet ids). But this is an obscure edge that we can\n(currently) live with.\n\nWhile this implementation under hood allows one of the two\nto be enabled individually we do not expose this functionality\nbut require the two protocol flags aead-tag-end and pkt-id-64-bit\nto be always come together. This allows other data channel\nimplementations to only support a limited set of data channel\nformats.\n\nChange-Id: I01e258e97351b5aa4b9e561f5b35ddc2318569e2\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"3d139a9a5b74c9a4f5d0c9cf8a2eab2efbef6f75":{"kind":"NO_CHANGE","_number":9,"created":"2024-08-15 12:33:32.000000000","uploader":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"ref":"refs/changes/07/507/9","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/07/507/9","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/9 \u0026\u0026 git checkout -b change-507 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/9 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/9 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/9 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/07/507/9","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/9 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"233e10aeec7de02d34fa5c517b44612d38ccc00f","subject":"Implement support for AEAD tag at the end"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-22 12:28:23.000000000","tz":60},"committer":{"name":"Lev Stipakov","email":"lev@openvpn.net","date":"2024-08-15 12:33:12.000000000","tz":180},"subject":"Implement support for larger packet counter sizes","message":"Implement support for larger packet counter sizes\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nThis introduces the 64bit packet counters for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\n\nWhile we still keep the old --secret logic around we use the same\nweird unix timestamp + packet counter format to avoid refactoring the\ncode now and again when we remove --secret code but DCO\nimplementations are free to use just a single 64 bit counter. One\nother small downside of this approach is that when rollover happens\nand we get reordering all the older packets are thrown away since\nthe distance between the packet before and after the rollover is\nquite large as we probably jump forward more than 1s (or more than\n2^32 packet ids). But this is an obscure edge that we can\n(currently) live with.\n\nWhile this implementation under hood allows one of the two\nto be enabled individually we do not expose this functionality\nbut require the two protocol flags aead-tag-end and pkt-id-64-bit\nto be always come together. This allows other data channel\nimplementations to only support a limited set of data channel\nformats.\n\nChange-Id: I01e258e97351b5aa4b9e561f5b35ddc2318569e2\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"6106862f15d1e7dd4935a5c67a347c457b534c5f":{"kind":"REWORK","_number":10,"created":"2024-09-10 09:24:24.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/07/507/10","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/07/507/10","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/10 \u0026\u0026 git checkout -b change-507 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/10 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/10 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/10 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/07/507/10","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/10 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"aa1dd09b5fc196499c84d2ef9b0c254ebb1745d8","subject":"Fix more of uninitialized struct user_pass local vars"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-22 12:28:23.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-10 09:24:09.000000000","tz":120},"subject":"Implement support for larger packet counter sizes","message":"Implement support for larger packet counter sizes\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nThis introduces the 64bit packet counters for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\n\nWhile we still keep the old --secret logic around we use the same\nweird unix timestamp + packet counter format to avoid refactoring the\ncode now and again when we remove --secret code but DCO\nimplementations are free to use just a single 64 bit counter. One\nother small downside of this approach is that when rollover happens\nand we get reordering all the older packets are thrown away since\nthe distance between the packet before and after the rollover is\nquite large as we probably jump forward more than 1s (or more than\n2^32 packet ids). But this is an obscure edge that we can\n(currently) live with.\n\nWhile this implementation under hood allows one of the two\nto be enabled individually we do not expose this functionality\nbut require the two protocol flags aead-tag-end and pkt-id-64-bit\nto be always come together. This allows other data channel\nimplementations to only support a limited set of data channel\nformats.\n\nChange-Id: I01e258e97351b5aa4b9e561f5b35ddc2318569e2\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"451eec23510e86715dc90e2c34586fcfc92fdaa3":{"kind":"REWORK","_number":11,"created":"2024-09-10 11:16:53.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/07/507/11","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/07/507/11","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/11 \u0026\u0026 git checkout -b change-507 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/11 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/11 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/11 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/07/507/11","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/07/507/11 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"aa1dd09b5fc196499c84d2ef9b0c254ebb1745d8","subject":"Fix more of uninitialized struct user_pass local vars"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-01-22 12:28:23.000000000","tz":60},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-10 11:16:47.000000000","tz":120},"subject":"Implement support for larger packet counter sizes","message":"Implement support for larger packet counter sizes\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nThis introduces the 64bit packet counters for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\n\nWhile we still keep the old --secret logic around we use the same\nweird unix timestamp + packet counter format to avoid refactoring the\ncode now and again when we remove --secret code but DCO\nimplementations are free to use just a single 64 bit counter. One\nother small downside of this approach is that when rollover happens\nand we get reordering all the older packets are thrown away since\nthe distance between the packet before and after the rollover is\nquite large as we probably jump forward more than 1s (or more than\n2^32 packet ids). But this is an obscure edge that we can\n(currently) live with.\n\nWhile this implementation under hood allows one of the two\nto be enabled individually we do not expose this functionality\nbut require the two protocol flags aead-tag-end and pkt-id-64-bit\nto be always come together. This allows other data channel\nimplementations to only support a limited set of data channel\nformats.\n\nChange-Id: I01e258e97351b5aa4b9e561f5b35ddc2318569e2\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}