Re: NKE stacking order
Re: NKE stacking order
- Subject: Re: NKE stacking order
- From: Josh Graessley <email@hidden>
- Date: Wed, 30 Nov 2005 11:21:38 -0800
Hi Peter,
The calling of filters in the same order for the inbound and outbound
data paths is a bug and should be addressed. Please file a bug report
through Radar. You may also want to file a bug requesting the ability
to specify where your filter is installed (first or last). The old
KPIs did have a way of specifying where your filter was inserted but
it relied on 32bit identifiers. You could specify that your filter
should load before or after a filter with the identifier that you
specify. There was no coordination in how this 32bit value was
assigned and it wasn't clear how developers would coordinate with
each other on insert order. We wanted to come up with something
simpler when designing the KPIs but ran out of time. We're certainly
open to suggestions.
As of Tiger, the protocol and interface filters are one and the same.
A protocol filter is just an interface filter that specifies which
protocol it is interested in filtering at the interface layer.
On Tiger, SharedIP is implemented as an IP filter. This solves some
problems while creating others.
Apple's built-in internet sharing uses divert sockets. Divert sockets
are part of the ipfw mechanism. ipfw runs as part of ip_input an
ip_output. This happens between the interface/protocol filters and
the ip filters.
-josh
On Nov 30, 2005, at 8:14 AM, Peter Sichel wrote:
I'm trying to help a potential customer use Internet sharing with the
Cisco VPN client which illuminates a gap in the Tiger NKE mechanism.
Specifically, there is no way to examine or specify the required
network
stack order when inserting NKEs.
To use Internet sharing (NAT) with a VPN, the VPN needs to sit
below NAT
in the network stack so the NAT can examine and modify the unencrypted
packets. As I understand it, the Cisco VPN client is implemented
as an
NKE, presumably an Interface Filter as opposed to a Protocol Filter so
it applies to both native and Classic network applications (protocol
filters sit above SharedIP so do not apply to Classic applications).
Apple's built-in Internet Sharing is based on UNIX natd which uses an
ipfw divert socket. As I understand it, divert sockets use a BPF tap
which is applied at the IOKit layer below any interface filter NKEs.
This precludes using an NKE based VPN with UNIX natd.
Another possibility is to use Mac OS X's built-in VPN tools, but
I'm not
sure where these reside in the network stack order. If they use a BPF
tap, I need a way to ensure this tap is below the divert socket
used by
natd. Performance might also be crippled by shuffling packets between
address spaces (kernel, VPN, kernel, natd, kernel).
Finally, I've implemented an NKE based NAT engine in IPNetRouterX
which
could stack above the Cisco VPN client but there's no way to
examine or
specify this explicitly. In my own testing, it appears that interface
filter NKEs are executed in the order they were inserted in both the
inbound and outbound directions, which is not a valid network stack
order. If I insert the VPN first, followed by NAT. I get this:
IP layer of BSD stack
outbound
| ^
V |
VPN NAT
| ^
V |
NAT VPN
| ^
V |
inbound
IOKit layer
If this is indeed the current implementation, how do we get this
fixed?
Notice this problem was solved ages ago in Open Transport (STREAMs)
since you could walk any stream up or down to see the stacking order,
and explicitly request where your own module was to be inserted.
Help me Obi-Wan,
- Peter Sichel
Sustainable Softworks
www.sustworks.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden