Zhijun Fu writes:
> James Carlson wrote:
> > 1. I assume that "net_getlifaddr" in the context of a MAC hook
> > actually returns a MAC layer address, and not an IP address as the
> > name "lif" might otherwise suggest. Right?
>
> Yes, that's right. For MAC hook we're kind of reusing the same function
> though there is actually no "lif" at MAC layer. :-) I'd like to hear your
> suggestions on this.
I've no problem with this. I was just verifying that I understood, as
it doesn't seem to be in the materials.
> > 2. You give the new rule processing as:
[...]
> > I don't understand why the ordering of operations isn't just
> > reversed on output. Assuming the input order is correct (and it
> > appears to me to be right), the "L2 firewall" element should be
> > the last operation before "[OUTPUT]."
>
> It could be a useful feature to combine filtering on L2 and L3
> together, or even trigger conditional IP NAT from a L2 filtering rule,
> though they are not supported in the current project scope, down the
> road we may want to add it, and these features require that L2 firewall
> to be processed before those "layer2" IP rules.
>
> Also, since the packet is received at MAC layer, it might be more
> straight forward to do the parsing and matching from the MAC header,
> as we need to parse the MAC header first anyway to locate the IP header
> start. It also allows a simpler implementation in IPFilter but that
> can be considered an implementation issue anyway.
>
> Would the above make sense?
I'm not sure, but I don't think any of it answers the actual question
I had. You currently have this:
[INPUT] -> L2 firewall -> "layer2" IP NAT -> "layer2" IP firewall ->
... -> IP NAT -> IP firewall -> { IP } -> IP firewall -> IP NAT -> ...
-> L2 firewall -> "layer2" IP firewall -> "layer2" IP NAT -> [OUTPUT]
But that's not entirely symmetric, and I don't see why. I would have
expected it to be:
[INPUT] -> L2 firewall -> "layer2" IP NAT -> "layer2" IP firewall ->
... -> IP NAT -> IP firewall -> { IP } -> IP firewall -> IP NAT -> ...
-> "layer2" IP firewall -> "layer2" IP NAT -> L2 firewall -> [OUTPUT]
That would be symmetric processing: we go through steps A through E on
input, and then E' through A' on output. That's easy to understand.
I don't understand doing A-E on input, and then E', D', A', C', B' on
output, which is what you've documented. Is there a reason for this?
(This is my only real sticking point right now.)
> > 3. We're defining these bits of syntax ourselves, and we're expecting
> > that administrators are going to rely on them for the security of
> > their systems. Given that, is "Volatile" the right classification
> > for the new "family ether" and "layer2" configuration keywords?
>
> We'll think more about this.
Please just make it "Committed."
> > 4. Why is hpe_hdrinfo "void *" rather than "hook_pkt_info_t *"?
>
> For MAC layer, it is actually "mac_header_info_t *".
Oh ... ok; the documentation should probably make that clearer.
> > Void
> > pointers are mildly evil, as they prevent the compiler and lint
> > from doing their type-checking jobs. What else would hpe_hdrinfo
> > point to?
>
> The major reason for using "void *" here, is that hook_pkt_event_t
> is a quite general structure that works with all protocols, thus I
> feel it is probably not appropriate to use types that specific to
> one protocol, e.g. mac_header_info_t is specific to MAC. Also it
> could point to other data structure for protocol other than MAC
> layer, though there's not such need right now.
I see. I would have used a discriminated type here to make accidents
less likely (an enum + union, or just overlaid structures as is done
with sockaddr), but I guess this is your call.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
