Hello,
(I'm crossposting this to netdev in the hope to get more answers to my
questions. I hope the patch is not considered too big.)
GRRRR, I should keep up with the list more often, sheesh, this even
came before my 1st announcement. I guess I'm on too many lists.
How is your work going?
I'll comment a bit on how I've tackled the UDP->FSwan issue:
When pluto detects a NATed connection, it will add extra bits (the ports)
to the SADB_ADD message. Upon detecting those bits in the function
ipsec_sa_put():ipsec_sa.c the matching UDP sock is found (this is always a
socket bound to ipsecN_ADDR:500, not *:500) and its data_ready() callback
is changed to point to sock_ipsec_natt_readable():ipsec_rcv.c.
rationale:
* no kernel recompile should be needed
* there should be no overhead for UDP socks not owned by pluto and with
at least a matching UDP encapsulated tunnel
I havent implemented reference counting yet, so once a sock gets changed,
it stays that way.
sock_ipsec_natt_readable() detects if it is a UDP keepalive (drop) or an
UDP-ESP packet (calls ipsec_udp_input). It calls the default
sock->data_ready() callback (sock_def_readable) otherwise.
In ipsec_udp_input I do basically what you describe further down:
* adjust iph->protocol & tot_len
* memmove the data 16 bytes forward (overwriting the udp overhead)
* [n]h.raw += 16
* skb_pull 16
* ipsec_rcv(skb)
I havent implemented error_queue handling yet.
There are a series of issues with this delivery scheme:
* skb->dev gets sets to NULL in the udp delivery path this; really
disturbs ipsec_rcv, so the packets get 'received' on a device stored
on the SA (thx mcr for the idea). This means some stats are lost
(the ones about errors before we can find the SA)
* I'm not sure this is SMP safe. I've tried to hold any lock I could
find in struct sock (at least the ones used in the normal data_ready
cb). I suspect there is a window in which the packet is enqueued on
the sock, the sock is unlocked and we havent yet got the lock on it,
so I suspect another CPU might dequeue it for us (the waitqueue on
the sock hasnt been 'awakened' (that is what sock_def_readable usually
does), but I dont quite expect this to be the only way of initiating
sock dequeueing) and deliver it to pluto.
This window shold be about 10 simple C statements and a function
call. Of course, I cant really pretend to quite understand the code.
The udp-encaps receive device is hardcoded to ipsec4 for now.
On Sat, 15 Dec 2001, K P Muthuvelan wrote:
> This is what I have done in udp_rcv to process UDP encaped IPsec packets
> before passing them to netif_rx(). But, how should I adjust
> sk_buff->data?
>
> udp_rcv()
>
> if the packet is destined for IPsec
> determine protocol = ESP/AH
AH support is being dropped, from what I've seen in the -01 drafts.
> remove UDP header, Non-IKE marker, Non-ESP marker, AH envelop.
> skb_trim(skb)
Is skb_trim needed? Why care (and waste the cycles)? The skb might
expand anyway on decompression? And why should there be space left
on the tail? I think moving the ip header'll be cheaper than moving the
whole udp payload (wag the payload ;-)
> skb->nh.iph->protocol = protocol (ESP/AH)
> calculate skb->nh.iph->tot_len
> calculate skb->nh.iph->check
Is this needed? The csum's been checked already. I cant find a reference
to _csum in ipsec_rcv until the packet's already been mangled.
> adjust skb->h.raw to point to ESP/AH header?
> /* how must I adjust the data pointer? sk_push() */
>
> Thanks
> Divya Mukundan & KPM
>
> KPM,
> Graduate Student,EECS,
> University of Kansas, Lawrence.
Some further comments on my patch: It is a slightly linted and
only tested for compile snapshot of my working tree. I write comments as
I go on, they might or not be actual wrt the code. Specially the comments
about the comments might be out of date. It is against 1.96.
You will need to apply the small patch to the linux tree (I use 2.4.18
uml if that matters).
I've started implementing --ikeport %any to support real
anywhere-NATed-RW, but it is not ready yet (it will hit an assert almost
always).
Support for AH is on the way out.
Transport mode is mostly untested, specially I havent used the NAT
Original Address yet (it isnt correctly sent to the kernel).
Support for the dummy NAT detection is removed.
When sending it just insert a bigger 'ESP' header. I tried to keep the
changes as unintrusive as possible.
Sorry, I've yet to convert all comments to C-Style, // is quicker to
type.
As always I welcome any comments, suggestions or bug reports.
TIA, HAND
yon
diff.natt.2418.apply.gz
Description: Patch against 2.4.18
diff.196.rel.gz
Description: Patch against 1.96
|