Jan Parcel wrote:
> The assumption that things are under single administration is a huge problem
> for my customers. The whole point of all this protection and security
> and labeling is the post-9/11 requirements for cooperation BETWEEN
> administrative departments, which means each one wants to gate between
> themselves and others. So General Dynamics wants to be able to
> REQUIRE labels partway through the route, and delete them later.
>
> Implicit labeling needs to be done carefully or be able to be turned off.
>
> Doesn't all this "process must dominate" stuff (I assume you mean
> non-strict domination) tend to promote write-down?
>
>
>
>> ---------------------- Example Model ---------
>> Current semantics for next hop:
>> A gateway is labeled and affect labeling decisions or a gateway is
>> unlabeled and does not affect labeling decisions. A route irregardless
>> of secattrs has the affect of its gateway.
>>
>
> What does that last sentence mean?
>
The affect of route selection is determined by the next hop's tnrhtp
entry not a flag on the secattr.
>
>
>> Current gateway/destination:
>> An unlabeled packet from a CIPSO host is dropped.
>>
>> Theoretical gateway/destination: (CR# 6517744 is open for the unlabeled
>> destination case)
>> An unlabeled packet from a CIPSO host is dropped unless: while assuming
>> a shared TNDB with the source, its intended label can be exactly
>> established and is consistent for the sender (within range or slset.)
>>
>
> How is this decided? I do not believe it is a safe assumption that it
> has a shared TNDB with the source (my customers say this is not
> a safe assumption) so....they want the sysadmin to be able to decide
> whether or not to drop unlabeled packets from CIPSO hosts.
>
> Deciding to derive the label from the label of the destination is
> circular reasoning and precludes using a gateway as a gateway. A
> straight forwarder could just be a Cisco box, if they are using
> Solaris presumably they want more intelligence than dumb forwarding.
>
Not allowing destination based label decision would be a use of the
TSLF_IMPLICIT flag I defined in the example model. I defined an
arbitrary set of rules around it in the example.
Ultimately there is no good solution though, since this is a cake
and eat it too request. "I want to implicitly know how to handle things
without CIPSO or trusted signaling by taking advantage of a shared
database and I don't want to count on the consistency of a shared
database." The ability to differentiate whether we are eating or saving
our cake is one I am happy to punt to interface MAC, which is not the
current topic. At the tnrhdb logic level all that is important is that
we mark it and preserve whatever signaling there is.
>
>> Addition:
>> An unspecified label packet from an MLS host in addition to the current
>> TSLF_UNLABELED flag will be given an TSLF_IMPLICIT flag. Only those
>> with MAC_EXEMPT` able to receive at the deduced label will receive it
>> locally and no labeling will be added in forwarding.
>>
>> Expected Result:
>> The route secattr is a bit more flexible since we can properly tag
>> the routes that unprotected CIPSO should not take.
>> Two CIPSO hosts must have the same max_label for symmetric
>> communication without labels.
>> I think MAC_EXEMPT' could have the same privilege as MAC_EXEMPT
>> since it is no worse then sending to a unlabeled host with a
>> default_label, but it would require a specific differentiator when
>> setting the option for those expecting it to influence only unlabeled
>> host communications.
>> -----------------------------
>> Primary requirements on phase 1 from the example model:
>> Two CIPSO hosts must have the same max_label for communication
>> without labels.
>> TSLF_IMPLICIT is marked on incoming packets in tsol_get_pkt_label
>> and taints them for forwarding and local delivery besides iked with its
>> new privilege protected socket option. (Assuming labeled gateways can
>> be unfriendly to implicit labels in phase 1.)
>>
>
> How can they be unfriendly to implicit labels? Is that a bit?
>
I don't follow, not forwarding them seems unfriendly for a gateway. In
the example of minimal changes for phase 1, with implicit labeling no
gateway could be a labeled one that sees the end systems as CIPSO as it
does not forward packets it has marked TSLF_IMPLICIT.
-Will
