[Top] [All Lists]

Re: [NAT-T] NON-IKE encapsulation

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [NAT-T] NON-IKE encapsulation
From: Andreas Gruenbacher <agruen@xxxxxxx>
Date: Sat, 26 Jun 2004 01:30:29 +0200
Cc: "David S. Miller" <davem@xxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20040625215747.GA14930@xxxxxxxxxxxxxxxxxxx>
Organization: SUSE Labs
References: <20040624123603.GA1241@xxxxxxxxxxxxxxxxxxx> <20040625101231.6f6b2f12.davem@xxxxxxxxxx> <20040625215747.GA14930@xxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx

On Fri, 2004-06-25 at 23:57, Herbert Xu wrote:
> On Fri, Jun 25, 2004 at 10:12:31AM -0700, David S. Miller wrote:
> > 
> > I now think it's trying to account for the udpdata32[] header area.
> > But that's not 2 bytes, it's (2 * sizeof(u32)) or 8 bytes.
> That's what I thought too, but that is already accounted by
> x->props.header_len in init_state.
> In any case, just increasing alen like that is wrong.  It needs to
> do at least three other things:
> 1. Allocate memory for it in skb_cow_data.
> 2. Fill in those bytes with data so we don't leak information.
> 3. Teach get_max_size about it.
> Andreas, can you please clarify for us as to what those two bytes
> are for?

Your analyses are entirely correct. The two instances of ``alen += 2''
are indeed complete nonsense. The extra 8 bytes required are already
accounted for in header_len; nothing other than the two zero-filled
words is required for this encapsulation mode.

Attached is a new version of the original patch, and a relative diff for
reference. Thanks for reviewing and for reporting. (And sorry for the
confusion; I'm a bit stressed out at the moment.)

Andreas Gruenbacher <agruen@xxxxxxx>

Attachment: ipsec-nat-t-old
Description: Text document

Attachment: delta.diff
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>