PSARC/2008/249 - Packet Interception for the MAC layer

[James Carlson]

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