netdev - Re: [PATCH] ip_gre: When TOS is inherited, use configured TOS value for non-IP packets

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-prev] [day] [month] [year] [list]

Message-ID: <5112C9E4.6010708@ll.mit.edu>
Date:	Wed, 6 Feb 2013 16:23:48 -0500
From:	"Ward, David - 0663 - MITLL" <david.ward@...mit.edu>
To:	David Miller <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"timo.teras@....fi" <timo.teras@....fi>
Subject: Re: [PATCH] ip_gre: When TOS is inherited, use configured TOS value
 for non-IP packets

On 01/29/2013 02:06 PM, David Miller wrote:
>
> From: David Ward <david.ward@...mit.edu>
> Date: Sun, 27 Jan 2013 18:04:58 -0500
>
> > A GRE tunnel can be configured so that outgoing tunnel packets inherit
> > the value of the TOS field from the inner IP header. In doing so, when
> > a non-IP packet is transmitted through the tunnel, the TOS field will
> > always be set to 0.
> >
> > Instead, the user should be able to configure a different TOS value as
> > the fallback to use for non-IP packets. This is helpful when the non-IP
> > packets are all control packets and should be handled by routers outside
> > the tunnel as having Internet Control precedence. One example of this is
> > the NHRP packets that control a DMVPN-compatible mGRE tunnel; they are
> > encapsulated directly by GRE and do not contain an inner IP header.
> >
> > Under the existing behavior, the IFLA_GRE_TOS parameter must be set to
> > '1' for the TOS value to be inherited. Now, only the least significant
> > bit of this parameter must be set to '1', and when a non-IP packet is
> > sent through the tunnel, the upper 6 bits of this same parameter will be
> > copied into the TOS field. (The ECN bits get masked off as before.)
> >
> > This behavior is backwards-compatible with existing configurations and
> > iproute2 versions.
> >
> > Signed-off-by: David Ward <david.ward@...mit.edu>
>
> Seems reasonable, applied.  Thanks.
>
> I worry though about the case where tiph comes from skb->data rather
> than the tunnel parameter block, can you describe why this new behavior
> is OK in that situation too.
>

Sorry for the late reply, I have not been well for the past few days.

The case you mentioned will occur when dev->header_ops has been set (to 
ipgre_header_ops).  In that case, ipgre_header() is called before 
ipgre_tunnel_xmit().  It pushes the outer IP header onto the SKB ahead 
of time, copying the contents from the IP header in the tunnel parameter 
block.

So even in this case, the TOS value that we check is taken from the 
tunnel parameter block, not the inner IP header.

David



Download attachment "smime.p7s" of type "application/pkcs7-signature" (4571 bytes)