Cover Letter Detail
Show a cover letter.
GET /api/covers/851552/?format=api
{ "id": 851552, "url": "http://patchwork.ozlabs.org/api/covers/851552/?format=api", "web_url": "http://patchwork.ozlabs.org/project/netdev/cover/20171220170607.41516-1-lorenzo@google.com/", "project": { "id": 7, "url": "http://patchwork.ozlabs.org/api/projects/7/?format=api", "name": "Linux network development", "link_name": "netdev", "list_id": "netdev.vger.kernel.org", "list_email": "netdev@vger.kernel.org", "web_url": null, "scm_url": null, "webscm_url": null, "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20171220170607.41516-1-lorenzo@google.com>", "list_archive_url": null, "date": "2017-12-20T17:06:00", "name": "[ipsec-next,0/7] : Support multiple VTIs with the same src+dst pair", "submitter": { "id": 3403, "url": "http://patchwork.ozlabs.org/api/people/3403/?format=api", "name": "Lorenzo Colitti", "email": "lorenzo@google.com" }, "mbox": "http://patchwork.ozlabs.org/project/netdev/cover/20171220170607.41516-1-lorenzo@google.com/mbox/", "series": [ { "id": 19695, "url": "http://patchwork.ozlabs.org/api/series/19695/?format=api", "web_url": "http://patchwork.ozlabs.org/project/netdev/list/?series=19695", "date": "2017-12-20T17:06:00", "name": ": Support multiple VTIs with the same src+dst pair", "version": 1, "mbox": "http://patchwork.ozlabs.org/series/19695/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/covers/851552/comments/", "headers": { "Return-Path": "<netdev-owner@vger.kernel.org>", "X-Original-To": "patchwork-incoming@ozlabs.org", "Delivered-To": "patchwork-incoming@ozlabs.org", "Authentication-Results": [ "ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)", "ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=google.com header.i=@google.com\n\theader.b=\"kQjr3ekX\"; dkim-atps=neutral" ], "Received": [ "from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3z21QJ4zXXz9s8J\n\tfor <patchwork-incoming@ozlabs.org>;\n\tThu, 21 Dec 2017 04:06:32 +1100 (AEDT)", "(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755287AbdLTRG2 (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tWed, 20 Dec 2017 12:06:28 -0500", "from mail-pg0-f52.google.com ([74.125.83.52]:43487 \"EHLO\n\tmail-pg0-f52.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751672AbdLTRG0 (ORCPT\n\t<rfc822;netdev@vger.kernel.org>); Wed, 20 Dec 2017 12:06:26 -0500", "by mail-pg0-f52.google.com with SMTP id b18so12141316pgv.10\n\tfor <netdev@vger.kernel.org>; Wed, 20 Dec 2017 09:06:25 -0800 (PST)", "from lorenzo.tok.corp.google.com ([100.103.3.232])\n\tby smtp.gmail.com with ESMTPSA id\n\tt62sm29103067pgt.23.2017.12.20.09.06.22\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);\n\tWed, 20 Dec 2017 09:06:23 -0800 (PST)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=google.com; s=20161025;\n\th=from:to:cc:subject:date:message-id;\n\tbh=pDc0YJx/HLs0f4GIxhFISYGrABQfN/oXSWlPnNfhinE=;\n\tb=kQjr3ekX4HPPkdBZTrK9lrRPoJLAyObnJM4MtAj13icvIsHN9EL15K+2cMLabGBRHb\n\tPquJ5xa2fDoNb69Hf+/2kzLR5hYSNBQf4JMgEnmRrwlNwF/tCQ2jDcU5NODmvhbLFyCQ\n\tQS1BfaY8Tb04FxxP2zq0zRNNNzXOJjTjTwhjpU7pTkOYmM03cP9QQDFxSi4hMR14hW2G\n\tsYtIRErG8aZsG77jAgsbiJNj43fmDlblOcRplEmt9aBPynb1svZOEt2zExIUVPdydyWg\n\tcLxNARgSWHElWuUEiHtS+vyVBV2cAcBUS5qcGCHkWYRUS/Wp0vz4sCv4Rq7y4rTh1g7M\n\tyAbw==", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:from:to:cc:subject:date:message-id;\n\tbh=pDc0YJx/HLs0f4GIxhFISYGrABQfN/oXSWlPnNfhinE=;\n\tb=AbZgIf98dS0iCUseuolj//7gIHkEtSi5Go/03LvCn8VwcvoOcTo5j6TIOz9lv4Sw5y\n\tpBfDYlRFOPNuDk9sUylQrqq/jGmPdbFs7aqI+DTBkWcVCq+nsYFlf5LUtwH7J+Hy/CSQ\n\tcGJzroRN8afXVG8Us+IeiZ/QgtDhHo6Uv/oW8ZeFZLToFWCu0qK8ysv6MXO6tmaCZO4u\n\tHOG7a4eB7KGOao6fk3SzNDXl6bZ4yqAVfF84qaFOWogL354CU4pb1u6tEIcivILozaVJ\n\tt6mf6xjkXO8VazxfulC+ZrkgKT6WV33RHw+a88Q6BVJxf02d6RVzvqv7IAr9eq3mh8lE\n\tw1Pw==", "X-Gm-Message-State": "AKGB3mI8X3e9j180A4cgNFbILSqtp1JvCCwTKpcLVtRySCacmG98ufDB\n\tyAiAslMh3qS4++KGV83EqC0IU5DSci8=", "X-Google-Smtp-Source": "ACJfBou5ND/0aEZEB4l4+I9Vc43ujsta5Xk2A0uyqFTn5YhuicYvd3cn0GiFcZajwTndnuy/vsPaPg==", "X-Received": "by 10.98.61.80 with SMTP id k77mr7534856pfa.226.1513789584633;\n\tWed, 20 Dec 2017 09:06:24 -0800 (PST)", "From": "Lorenzo Colitti <lorenzo@google.com>", "To": "netdev@vger.kernel.org", "Cc": "steffen.klassert@secunet.com, subashab@codeaurora.org,\n\tnharold@google.com, davem@davemloft.net", "Subject": "[PATCH ipsec-next 0/7]: Support multiple VTIs with the same src+dst\n\tpair", "Date": "Thu, 21 Dec 2017 02:06:00 +0900", "Message-Id": "<20171220170607.41516-1-lorenzo@google.com>", "X-Mailer": "git-send-email 2.15.1.620.gb9897f4670-goog", "Sender": "netdev-owner@vger.kernel.org", "Precedence": "bulk", "List-ID": "<netdev.vger.kernel.org>", "X-Mailing-List": "netdev@vger.kernel.org" }, "content": "When using IPsec tunnel mode, VTIs provide many benefits compared\nto direct configuration of xfrm policies / states. However, one\nlimitation is that there can only be one VTI between a given pair\nof IP addresses. This does not allow configuring multiple IPsec\ntunnels to the same security gateway. This is required by some\ndeployments, for example I-WLAN [3GPP TS 24.327].\n\nThis patchset introduces a new VTI_KEYED flag that allows\nconfiguration of multiple VTIs between the same IP address\npairs. The semantics are as follows:\n\n- The output path is the same as current VTI behaviour, where a\n routing lookup selects a VTI interface, and the VTI's okey\n specifies the mark to use in the XFRM lookup.\n- The input and ICMP error paths instead work by first looking up\n an SA with a loose match that ignores the mark. That mark is\n then used to find the tunnel by ikey (for input packets) or\n okey (for ICMP errors).\n\nIn order for ICMP errors to work, flags are added to the common\nIP lookup functions to ignore the tunnel ikey and to look up\ntunnels by okey instead of ikey.\n\nOn the same IP address pair, keyed VTIs can coexist with each\nother (as long as the ikeys are different), but cannot coexist\nwith keyless VTIs. This is because the existing keyless VTI\nbehaviour (which this series does not change) is to always accept\npackets matching an input policy, regardless of whether there is\nany matching XFRM state. Thus, the keyless VTI would accept the\ntraffic for the keyed tunnel and drop it because it would not\nmatch the keyed tunnel's state.\n\nChanges from RFC series:\n- Processing of ICMP errors now works when ikey != okey.\n- Series now contains changes to the common tunnel lookup\n functions to match tunnels by okey and to ignore ikey when\n matching.\n- Fixed missing EXPORT_SYMBOL for xfrm_state_lookup_loose.\n- Made vti6_lookup static as it should have been." }