summaryrefslogtreecommitdiff
path: root/net/ipv4/af_inet.c
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2018-01-05 11:03:42 -0500
committerDavid S. Miller <davem@davemloft.net>2018-01-05 11:03:42 -0500
commit2e40b823f072e2b57a8d7c43a4bd95988ced5568 (patch)
tree044a578a4e26d713e90fd285b0508ff663e55236 /net/ipv4/af_inet.c
parent74bd5d56bfcb857abb5ae7d9f47933be9d288cbd (diff)
parent4887d8933a8dfdfa6602e0faaa0e31cd343ccefe (diff)
Merge branch 'l2tp-remove-configurable-offset-parameters'
James Chapman says: ==================== l2tp: remove configurable offset parameters This patch series removes all code to support a configurable offset in transmitted l2tp packets. Code to handle this is incomplete and buggy and has been this way for years. If anyone tried to configure an offset, it would be ignored for L2TPv2 tunnels, or for L2TPv3 tunnels, could result in L2TPv3 packets being transmitted which are not compliant with L2TPv3 RFC3931. This patch series removes the support for configurable offsets. No known userspace l2tp daemon configures an offset. However, iproute2's "ip l2tp" command has an offset parameter and if set, the value is passed to the kernel. This is the most likely use case where offsets might be configured, e.g. ip l2tp add tunnel local 1.1.1.1 remote 1.1.1.2 tunnel_id 1 \ peer_tunnel_id 2 encap ip ip l2tp add session name l2tp0 tunnel_id 1 session_id 1 \ peer_session_id 2 offset 8 The above would result in packets being transmitted to 1.1.1.2 with 8 bytes padding between the L2TPv3 header and the payload. The peer would need to be configured with the same offset value. However, the packets are not compliant with the L2TPv3 RFC, hence I think it's unlikely that offset is being used. With this patch series applied, the offset would not be configured. The peer would need to be modified to remove its offset setting too. iproute2 should be modified to remove or ignore the ip l2tp offset parameter. This issue was discovered when reviewing a patch series from lorenzo.bianconi@redhat.com which adds another netlink attribute to configure the expected offset in received L2TPv3 packets. This change is reverted by this series because offsets do not exist in L2TPv3 packets. These commits are: commit f15bc54eeecd ("l2tp: add peer_offset parameter") commit 820da5357572 ("l2tp: fix missing print session offset info") In more detail: The L2TPv2 protocol supports a variable offset from the L2TPv2 header to the payload to give the sender implementation some flexibility for data alignment when adding L2TP headers on to payloads. The offset value is indicated by an optional field in the L2TP header. Our L2TP implementation already detects the presence of the optional offset in received packets and skips those bytes when parsing packets. All transmitted L2TPv2 packets are always transmitted with no offset. L2TPv3 has no optional offset field in the L2TPv3 packet header. Instead, L2TPv3 defines optional fields in a "Layer-2 Specific Sublayer". At the time when the original L2TP code was written, there was talk at IETF of offset being implemented in a new Layer-2 Specific Sublayer. A L2TP_ATTR_OFFSET netlink attribute was added so that this offset could be configured and the intention was to allow it to be also used to set the tx offset for L2TPv2. However, no L2TPv3 offset was ever specified and the L2TP_ATTR_OFFSET parameter was forgotten about. Setting L2TP_ATTR_OFFSET results in L2TPv3 packets being transmitted with the specified number of bytes padding between L2TPv3 header and payload. This is not compliant with L2TPv3 RFC3931. So this change removes the configurable offset altogether while retaining L2TP_ATTR_OFFSET in the API for backwards compatibility. If L2TP_ATTR_OFFSET is given, its value is now silently ignored. ==================== Reviewed-by: Guillaume Nault <g.nault@alphalink.fr> Tested-by: Guillaume Nault <g.nault@alphalink.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/ipv4/af_inet.c')
0 files changed, 0 insertions, 0 deletions