Re: NKE stacking order
Re: NKE stacking order
- Subject: Re: NKE stacking order
- From: Josh Graessley <email@hidden>
- Date: Thu, 1 Dec 2005 11:14:40 -0800
On Dec 1, 2005, at 7:45 AM, Peter Sichel wrote:
Can you help elaborate on this?
SharedIP was previously an Interface Filter which from your comment on
divert sockets meant the built-in internet sharing and firewall did
not
apply to Classic applications. By changing SharedIP to an IP filter
which sits above ipfw, the built-in firewall can process Classic
network
packets.
Presumably this change might break some existing Classic
configurations.
SharedIP used to manually call the built-in firewall on packets it
intercepted. This prevents Classic from bypassing the firewall.
SharedIP also used to do some packet reassembly to determine whether
a packet should go to Classic or up the standard X stack. This was a
problem because a lot of work has been done on the X stack to make
sure we don't tie up too many resources reassembling packets.
SharedIP didn't have any of that logic. By moving SharedIP further up
the stack we were able to eliminate the need to manually call ipfw
and eliminate the need to reassemble packets. In addition, we no
longer had to deal with ARP packets. In theory, this also means that
all of the IPSec policies and keys will apply to Classic traffic.
This also means that Classic networking could conceivably work with
primary interfaces other than PPP or Ethernet. That still requires
some work from the Classic side to configure things correctly.
The one downside to moving SharedIP to an IP filter is that we don't
have source specific routing. Packets from Classic always come from
the primary interface. The X stacks routes based only on the
destination address. The result is that a packet may be sent over a
secondary interface such as the VPN with a source address of the
primary interface. If a router on the other side is performing
ingress filtering, the packet will be dropped.
In the NKE Programming Guide there's a "Common Caveat" for Interface
Filters which reads:
Your filter's output callback receives the entire packet in the
mbuf chain. To get the protocol layer information, your filter
must know how to parse the link-layer header. For this reason,
if you are writing a filter that needs to work with IP packets,
you should consider writing an IP filter unless it is absolutely
necessary to access link-layer information.
The other issue besides link-layer information is whether you need to
sit below IP forwarding as needed for internet sharing or NAT.
Did I miss anything?
It may not be best to think of ipfw divert sockets only for NAT. Some
third party products use divert sockets to funnel packets to their
application for a variety of reasons. It is much easier than writing
a kernel extension. The problem is that there is no good way to
coordinate the ipfw rules that define which packets get diverted to
where.
-josh
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