On Mon, 04 May 2015, John Heffner wrote: > On Mon, May 4, 2015 at 12:34 AM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > > > > From: Eric Dumazet <edumazet@xxxxxxxxxx> > > > > This patch allows a server application to get the TCP SYN headers for > > its passive connections. This is useful if the server is doing > > fingerprinting of clients based on SYN packet contents. > > > > Two socket options are added: TCP_SAVE_SYN and TCP_SAVED_SYN. > > > > The first is used on a socket to enable saving the SYN headers > > for child connections. This can be set before or after the listen() > > call. > > > > The latter is used to retrieve the SYN headers for passive connections, > > if the parent listener has enabled TCP_SAVE_SYN. > > > > TCP_SAVED_SYN is read once, it frees the saved SYN headers. > > > > The data returned in TCP_SAVED_SYN are network (IPv4/IPv6) and TCP > > headers. > > > > Original patch was written by Tom Herbert, I changed it to not hold > > a full skb (and associated dst and conntracking reference). > > > > We have used such patch for about 3 years at Google. > > > Nice idea, seems handy. But a couple (somewhat related) questions: > > * Other than convenience, are there reasons not use an existing, more > general-purpose and portable mechanism like pcap? (Permissions, I > guess?) Eric Dumazet can speak for their reasons, but we had a difficult time guaranteeing that the data collected by libpcap was avaialble to the accepting thread when accept() returned without making the accepting thread wait on that data. With this implementation, we guarantee that userspace has access to this data when accept() returns. > * Are there conditions where, for security purposes, you don't want an > application to have access to the raw SYNs? In this implementation, userspace does not have access to the raw SYN, rather it can request a copy of the TCP and IP headers. Eric > > Thanks, > -John
Attachment:
signature.asc
Description: Digital signature
