netdev - Using gretap to tunnel layer 2 traffic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 Sep 2011 10:25:04 -0700 (PDT)
From:	John H <uothrawn@...oo.com>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Using gretap to tunnel layer 2 traffic

I am attempting to tunnel Layer 2 traffic through a gretap device, 
while encrypting the GRE tunnel with IPsec. My test environment is as follows:

10.0.1.1                                          10.0.1.2
client_a <--> server_left <==> server_right <---> client_b
                      gretap/IPsec

On the servers, I have two VLANs per server, corresponding to the unencrypted
and encrypted interfaces.  On each server, the unencrypted VLAN is 
bridged with the gretap device.  All VLANs and physical devices have MTUs of 
1500.  The gretap device has a resultant MTU of 1462, thereby causing the 
bridge device to have an MTU of 1462.

Traffic for the most part works as it is expected to behave. However, 
packets are dropped when client_a sends an ICMP packet to client_b which 
has an MTU less than client_a's device MTU but larger than server_left's 
MTU. I suspect other protocols would behave similarly (silently dropping
packets).  I an running "ping -c 1 -s 1450 10.0.1.2" on client_a, this results
in an ICMP packet being sent with an MTU of 1478.

An MTU of 1478 is larger than the bridge device's MTU of 1462, causing the 
packet to be silently discarded per net/bridge/br_forward.c 
in function br_dev_queue_push_xmit:

int br_dev_queue_push_xmit(struct sk_buff *skb)
{
    /* drop mtu oversized packets except gso */
    if (packet_length(skb) > skb->dev->mtu && !skb_is_gso(skb))
        kfree_skb(skb);
    else {
    ....

If the gretap device supported GSO, I suspect that this would not be a
problem. (ethtool -k gretapLeftRight states that GSO/GRO/LRO is not 
supported)

Function br_dev_queue_push_xmit eventually calls ipgre_tunnel_xmit, if the 
packet is not dropped.

I would think that br_dev_queue_push_xmit should call ipgre_tunnel_xmit
regardless of the device MTU and ipgre_tunnel_xmit would handle packet
fragmentation internally, but it never has the chance.

I have tried allowing all packets through br_dev_queue_push_xmit
and explicitly setting the Don't Frament field to 0 in ipgre_tunnel_xmit,
but this didn't solve problem.

Given that this would be tunneling Layer 2 traffic, it wouldn't make sense
to send an ICMP_FRAG_NEEDED response from the bridge.

The real question is, however, why is any client able to send a single ICMP
packet with size 1478 bytes when one of the hops along the way only 
supports 1462 bytes per its MTU? Shouldn't this have been negotiated 
beforehand?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html