Question about MAC labels and IP fragment handling

[Robert Watson]

When IP fragments are created as a result of exceeding the interface MTU
on transmission, the MAC code arranges for IP fragments to get appropriate
mbuf labels based on the label of the datagram being fragmented.  For all
current MAC policies, this is simply a label copy operation, although
potentially it might be something else.  This seems reasonable, and gets
the expected results on transmission (it's unlikely one fragment will be
rejected from transmission on an interface while others suceed, for
example).

An interesting question is raised when re-assembling fragments, however. 
First, lets consider the basic mbuf labeling case.  Fragments generally
have labels added to them as they come in the interface, or in the case of
loopback, they have the label appropriate for the socket that generated
the original datagram.  Potentially however, there might be fragments
arriving off of different interfaces, and hence having different labels
based on the differing labels of the source interfaces.  This suggests at
least two ways to handle this:

(1) Tweak the matching algorithm that identifies when fragments are from
    the same datagram, and therefore decides they should be reassembled.
    Right now, that matching algorithm is the stock IP algorithm, which
    compares source/destination IPs, IP protocol field, and the IP ID
    field.  For MLS and Biba, generally, equality of label will be the
    criteria for matching.  For TE, you can imagine other behavior, where
    individual interfaces had different labels (if_one_t, if_two_t), but
    it was OK to reassemble fragments that arrived over the interfaces.
    If an attacker on one interface (low integrity) was attempting to
    spoof a packet from another interface, the datagram would be
    reassembled independently of the datagram that was being spoofed.

(2) When a first fragment arrives, create a reassembly queue for it.  When
    additional fragments arrive, drop them if they cann't be assembled
    into the same packet.  This requires a check algorithm, which might be
    the same as listed in (1).  However, potentially an attacker on a low
    integrity interface might interfere with actions on a high integrity
    interface by flooding the fragment queue with potentially viable
    fragments, which would then block legitimate packets that had
    different labels.

Finally, this also raises the question of what the label on the datagram
should be.  For Biba and MLS, I would expect all the labels to be equal
across the fragments, and the datagram label to match that of the
fragments.  For TE, you could imagine wanting more flexible behavior, in
which case we need a policy hook to allow that new composed label to be
determined.  A question here would be what labels that hook might need to
make the decision -- access to all the fragment labels at once?  Access to
all the fragment labels as they come in, plus some storage to hold state?

Then we move onto the more complicated realm where there may be label
sources within the packet.  For example, Ilmar's CIPSO support can bring
labels in IP options.  First question: some IP options are scattered
across all of the fragments as fragmentation occurs (no-ops that maintain
alignment might be, for example, or source routing information).  Others
are maintained only in the first fragment.  Where to IPSO and CIPSO fit
into the picture?  Would composition of those labels be required if
fragments carried their own IPSO/CIPSO labels?  What about the (1) and (2) 
above?

My current temptation is to do the following:

(1) Allow a policy hook to tweak the matching algorithm for fragments, and
    use case (1) above.

(2) Based on the responses to this e-mail, either (a) use the mbuf label
    from the first fragment as the label for the final datagram, or (b)
    store a label in the IP fragment queue and allow the update of that
    label as fragments come in.  This provides access to the labels of all
    the fragments on the way to the final datagram, so the results can be
    composed.

(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). 

Suggestions welcome,

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