[brandz-discuss] Re: [security-discuss] TX as a Brand

[will young]

Erik Nordmark wrote:
> will young wrote:
> 
>>     We would have a few requirements before we can do this.  We would 
>> need to implement the admin zone(the admin_low/admin_high) as a 
>> non-global zone, which would also mean changes to doors.  These admin 
>> zones are what I would like to brand.  Also we would need per-zone 
>> stacks to be implemented as multiple shared stacks with a zone->stack 
>> mapping.
> 
> Will, why do you need this?
> 
> I'd like to instead explore a model where the TX networking support 
> moves from bring all over the TCP/IP code to instead being a "router" 
> function, with the router e.g. running in the global zone and forwarding 
> packets to other zones based on the labels. Thus the communication 
> patterns become analogous to a separate label-aware router and N 
> separate IP hosts.

	The trouble we encounter is that we need service infrastructures to 
operate and perform services for the zones, but function at a different 
label than them.  Currently, this is done by having the global zone at 
the admin_high/admin_low label for our DOI but that does not make sense 
if we have zones that are at a different DOI or are not intended to be 
part of TX at all.
	Really, for each IP instance, there needs to be a zone which manages it 
and this zone should not be in a user accreditation range (it should be 
admin_low/admin_high.)  This would correspond to having an admin zone 
per TX ip instance and keeping our current sparse zones oblivious to 
whether their resources are from the g-z or a different admin zone. 
Since ip instances can't share IP addresses and can presumably determine 
which instance your traffic is in, from a networking perspective we 
should be able to have two zones with identical labels.  This of course 
must be preserved for other places where we could compare local 
credentials with possible zones to deliver to.
	I don't think this is necessarily all that different than what you are 
looking at (assuming a bridge rather than router) except that the N 
separate IP hosts are each either unlabeled zones or a TX administrative 
zone and M distinct label zones.
	If you map N simple IP hosts, you will need to map mac exceptions and 
admin_low traffic in general for each labeled ip address anyway.  If you 
map it all to the global zone it must act as a proxy to configure things 
and really has no business working with multiple DOIs.  If you map them 
to the actual zones, this is really not correct as no user range zone 
should be allowed to manage itself.  This also does not handle the 
situation of two zones with identical label & doi by implicitly 
requiring a separate administrative zone will be available and providing 
services separately for each.  I don't know if our APIs are sufficient 
for unique identification to handle situations where two such zones have 
access to the same global door.  Likewise, if they are in different DOIs 
it is really not correct for them to have access to the same doors etc.
	Another aspect of not having admin zone + sparse zone stack organized 
TX zones is that there is not a clear way to handle multilabel windowing 
as there is nothing to establish which set of zones humans are 
considering a distinct logical machine.
> 
> To do this the label aware router needs to have special support for 
> handling multi-level ports for IP addresses that are shared between 
> zones, i.e. the router needs to look at port numbers in addition to IP 
> addresses and labels.
	We must also allow the registration of mac exceptions even on 
non-shared addresses or we must still pass everything for later MAC 
evaluation.
-Will
> 
>   Erik