Question about MAC labels and IP fragment handling

[Robert Watson]

On Tue, 29 Jan 2002, Crist J. Clark wrote:

> On Tue, Jan 29, 2002 at 05:06:01PM -0500, Robert Watson wrote:
> [snip]
> 
> > (3) Assume that IPSO/CIPSO will apply only to the first fragment, and
> >     ignore such labels on later fragments.  (This could be wrong: perhaps
> >     IPSO/CIPSO should be processed before fragment processing, and be used
> >     to update the label on the mbuf subject to policy). 
> 
> Just FYI, RFC 791 specifies that the IP Security Option is copied onto
> all fragments. 

Interesting.  However, given the current implementation order of the
ip_input() routine, this should work OK: ip_dooptions() is processed prior
to reassembly.  Unfortunately, after some of the other "ours" processing,
such as ipfw 'fwd'.  This will result in more consistent behavior, I
think, since the final label on the mbuf will either be from the
interface, or from the ip option (or perhaps eventually from the IPsec
SA) by the time local processing starts, including reassembly.

> If fragments are this much of a PITA, what's going to happen if TCP
> segments from the same TCP connection come in on different interfaces
> (which is much more likely to be seen in the real world than fragments
> on different interfaces)?

This situation actually works out fairly well, because by the time you're
doing TCP session reassembly, you have a reference to the socket it's
being delivered to, and individual checks are performed against the label
of the socket vs. the label of the TCP segment that has arrived:

        so = inp->inp_socket;
#ifdef MAC
        error = mac_socket_can_receive(so, m);
        if (error)
                goto drop;
#endif

The difference from the reassembly situation is that at that point you
know what the delivery target is, and you can simply compare against it. 
With the IP fragments, you have to decide if they're allowed to be
combined, and then if they are, what the label of the datagram should be. 

There are a couple of related tricky points in TCP -- for example,
sometimes, an incoming TCP packet will be responded to without a socket to
extract a label from.  For example, when responding with a RST to a TCP
datagram on a closed port.  Right now, the label of the incoming packet is
used, but you could also imagine selecting a label based on the interface
the response might go out of, or some other policy criteria.

Finally, there's a couple of cases below the network layer that we've run
into, where it's not clear what the right answer is.  Right now, when a
link-layer ARP packet is processed, the response uses a label selected by
the policy for the interface the packet will go out of.  This means that
link layer interaction generally "just works", but probably needs more
analysis.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services




To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message