netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Ketrenos <jketreno@linux.jf.intel.com>
To: Netdev <netdev@oss.sgi.com>
Subject: Limiting frame re-encryption with TCP retries...
Date: Fri, 09 Jul 2004 16:44:14 -0500	[thread overview]
Message-ID: <40EF11AE.9020008@linux.jf.intel.com> (raw)


The recent 'pskb change in dst-output' thread reminded me that I've been meaning 
to ask about this...

With wireless drivers TCP retransmission occur pretty frequently.  With WEP, 
etc. this means the driver has to re-encrypt the same frame with each retry.

In one of the snapshots for ipw2100 I was encrypting over the SKB provided from 
the kernel via the xmit and putting new data at the head and tail (to hold the 
IV and ICV).  Anyway, that broke all sorts of tools (ip_conntrack, netfilter, etc.)

So now I allocate a new SKB on reception of an SKB from the networking stack and 
encrypt the copy.  The question I have -- is there a way to attach the new SKB 
to the old one such that if the transmit is retried I can check that data and 
don't have to re-encrypt it?

 From the sk_buff.h description of the cb field, I only get to use that data 
while I control the SKB.  Even if this weren't the case it wouldn't quite do 
what I need.  Ideally I want to be able to attach the encrypted SKB to the 
original SKB such that when the network stack gets the ACK it can nuke the 
original SKB and the encrypted one and the driver doesn't have to know.

This gets complicated further when 802.11 level fragmentation is required -- and 
one incoming SKB results in N outbound 802.11 fragments, each encrypted separately.

Any ideas?  I'm not too familiar with the internals of the kernel's network 
stack so if there is something obvious that I should have seen already, please 
point it out to me :)

Thanks,
James

                 reply	other threads:[~2004-07-09 21:44 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40EF11AE.9020008@linux.jf.intel.com \
    --to=jketreno@linux.jf.intel.com \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).