|
Tammy, here is a first pass at some answers for JR. I still need
to do some research on CISCO routers and I cannot do that now, but
working on responses to some of my questions below in the meantime
might be helpful?
P.S. Did you ever send the "tnet_presentations.tar.Z" file
to JR (See note 395)? I think it has an explanation of
nlm and smm and where they fit in the network layer protocols
but I could be wrong.
P.P.S. I still haven't packaged up the "callback" error
fixes -- I seem to keep getting interruptions :-)
.......................................................................
> we cannot get the new CISCO 2505 router to
> talk to our machines at anything but tsix(cipso).
Do you have the CISCO 2505 manual? I can try and find one
here, but what I would be looking for is to find if it can
pass, or can be configured to pass, extended IP header options.
I am not familiar with the different models, but have been told
that some routers strip IP header options. It's my understanding
(and I'll check this) that the ripso nlm_type protocol puts SLs
(or rather 'mapped' SLs) in the options field of the IP header,
rather than in the body of the IP message.
Also, you can verify this for yourself if you have a network
sniffer that parses the IP stack, or if you have another
MLS+ box that you can put on the wire on the other side
from the transmitter (same side a receiving system), on
which you can run tcpdump. If you do not know how to run
tcpdump, we'll send a crib sheet. (If you have a box that
can run MLS+ V4.0, you do not need a second MLS+ box to
monitor -- in V4.0 tcpdump can be used to monitor the
system on which it is running; in V3, it can only monitor
traffic between or among the other systems on the LAN to
which it is attached.)
> We would greatly appreciate a 60 second analysis of it and answers to our
> questions.
60 seconds won't buy you much -- it takes me longer than
that to find the people who really know the answers :-)
> 1. Can you give us a better definition of "unlabeled". We have our
> OSF boxes will only talk to the routes when configured as
> tsix(unlabeled).
"The OSF boxes [I presume you mean MLS+ V3.1A boxes] will
only talk through the routers? to the routers? when
the routers are configured in the MLS+ V3.1A boxes as
tsix with nlm_type=unlabeled."
Is that what you meant to say? I'll have to get more
information on that...
I thought nlm_type=unlabelled means that the packets
go out without any tags/labels on them. This mode is
supposed to be used only during the initial stages of
RIS installs or BOOTP requests, i.e., when the target host
in the data base is known to be a normally a host that
"does labels" but is at the moment in the state when it
does not have the trusted network daemon(s) running
(the system would dynamically temporarily configure a
host entry this way, but it would put it back to the
value for nlm_type in the TNETRHDB once the trusted
daemon from the target host starts sending labelled
packets).
So the fact that you are not using labels means something
else is wrong. It might be helpful if we knew exactly
what "fails" -- do you have command output, responses,
excerpts from log files -- something to go on? Given the
routes, and TNETRHDB files from the systems involved...
> It's obviously sending some labeling because it
> retains the security level when telneting to another machine at
> different levels.
But that's just a question of what the routers pass through?
I thought the labels that go on the packet are what the
target expects, not what the next hop expects? Only in tnet
does the system put the label on the packet that is what the
next hop expects, instead of what the target expects.
Or is this what you were asking?
> 2. Our understanding is that tnet and tsix are two separate
> protocols. Why does our tsix not talk to our tnet configured
> machines?
I am confused here. tnet and tsix are two separate protocols.
A given MLS+ box does not "have" a given protocol: the protocol
it uses to talk to another machine depends on what it and
the other machine agreed to use to talk to each other.
I may be misunderstanding your question, and if I am, correct
me -- and ignore the following. [ I am lifting an explanation
from note 399.11, slightly updated ]
===========================================================================
The remote host entry in a given host's TNETRHDB file does not
really represent what the remote host *is*, it identifies what
protocol that host and another host _agree_to_use_ to talk with
each other.
Given three MLS+ hosts, you could do the following:
System A's TNETRHDB file System B's TNETRHDB File
entry for localhost: "tnet" entry for localhost: "tnet"
entry for System A: "tnet" entry for System B: "tsix_1_0"
entry for System B: "tsix_1_1" <=> entry for System A: "tsix_1_1"
entry for System C: "tnet" entry for System C: "tsix_1_0"
System C's TNETRHDB File
entry for localhost: "tsix_1_1"
entry for System C: "tnet"
entry for System A: "tnet"
entry for System B: "tsix_1_0"
So what "kind" of host is System C?(1)
Each of the above entries "match". A's entry for B matches
B's entry for A; A's entry for C matches C's entry for A;
B's entry for C matches C's entry for B... so if you ask,
"what is System C?" -- you'd have to say, well, A thinks C is
tnet and B thinks it is tsix... and if it talks to itself,
it thinks it is tnet, no, it thinks it is tsix... uh...
Note: localhost can be anything you want it to be (it used
to have to be "tnet" so you could run lockd and statd, but I
believe that is no longer a requirement). The above is just to
illustrate that "localhost" and the local host's name entry
(/etc/hosts) do not have to be the same. It just determines
the protocol used when you specify "localhost" -- for example,
in System C's case, suppose you are logged in on System C
and you type the rlogin command as follows:
# rlogin localhost ==> you'll use tsix_1_1 protocol
# rlogin SystemC ==> you'll use tnet protocol
(1)Answer: It is an MLS+ host :-)
==========================================================================
> The only way we found them to talk is both running
> tsix/unlabeled.
This doesn't make sense. We have mixed protocols in use
on our network here.
If the systems are failing to talk using labels, there must
be some evidence of that. What is failing? What command?
What is the response?
If you set up
> We have a large WAN and would like to gradually move
> the machines to tsix without cutting off legacy machines running tnet.
You should be able to run tnet between some machines and
tsix between others.
I have forgotten why you had to have some machines running
tnet. Could you refresh my memory?
> 3. Why does tsix not talk to our single-level printers? Our printers
> are on the network and were previously configured as single-level.
>
Because printers don't know tsix protocol. Why would you
expect printers to talk tsix? Why do you need printers to
talk tsix? The can only talk IP (assuming you are talking
about network printers). If someone is expecting you to
talk tsix with a printer -- or with any device that does
not know from trusted protocols, let me know.
"Hosts" or "devices" that do not know how to label packets
are "unlabelled" hosts. Printers are an example of unlabelled
"host" (at least I don't know of any printer manufacturer that
has modified their firmware to be able to use a trusted networking
protocol).
Printers are a special case of an unlabelled "host". When you
look at a TNETRHDB host entry, you see three fields:
def_sl
min_sl
max_sl
Those fields mean: If it is an unlabelled host, the min and
max SL field determine the valid range that data going out
to the "host" can have. The def_sl field is the label that
is to be put ON the data when it comes in from the host.
So, for example, in the case of printers, the data that comes
in is going to be control info, and it should be labelled at syslo.
The data that goes out could be a file that contains syslo
data, so the min_sl is syslo, and it could be a file that
contains syshi data, or the max_sl would be syshi.
> 4. In the diagram below: Why can we ping the machines local router
> but not the distant router (from each machine? (E=ethernet side of
> router S=serial side of router)
I don't know. I'll have to talk to some people who know
the CISCO routers. What are the entries in the TNETRHDB
file for those addresses? What does netstat -r say about
those addresses? Do you have route entries for those
addresses set up?
FTServer v3.1a -> CISCO 2505 -> CISCO 4000 -> SYSB v3.1a
xxx.xxx.130.1 Exxx.xxx.130.254 Sxxx.xxx.131.1 xxx.xxx.138.131
Sxxx.xxx.131.253 Exxx.xxx.138.254
5. How can (or can we?) configure our network to run both tnet,
dxsix, and tsix simultaneously?
We do it all the time here, i.e., use tnet between some hosts,
tsix between others. So I'm not sure how to answer that question.
Question on your TNETRHDB -- does each of the two systems
have the same TNETRHDB?
|
| Tammy, here is some additional data.
(I got a network guru here to help me with the following. This guy is
an independent consultant, and he has a clearance and used to work in
the security group. JR may want to consider hiring him to get this
"dnsix" setup done and over with.)
There is a web page, www.cisco.com, on which there is much
documentation. It is not actually important which model number of
router they are using, it is more important to know which version of
the software they are running, e.g., "Version 11" something.
The documentation says that you have to configure in the recognition of
the RIPSO (IPSO) bit in the IP options. Then there various other
parameters to configure (it gives a setup for multilevel traffic).
There was also a guess as to what their requirement to "use DNSIX"
might mean. In the case of MLS+, it probably at a minimum means
configuring the information that gets stuffed in the IP header for
IPSO/RIPSO nlm_type protocol. This can be done in addition to what
takes place at the higher levels (session layer, e.g., TSIX SAMP).
You can configure the "RFC1108" security attributes that the MLS+ box
will put in the IP header, and which will be recognized by the CISCO
router for "security" routing, to be compatible with the full-blown set
of CMW (MLS+ attributes) -- but they are really configured
independently from the labels used further up the protocol stack (e.g.,
TSIX SAMP etc.)
The customer requirement to use "dnsix" may just be a requirement to
use CISCO routers to take advantage of the logging features using the
IP security option.
To satisfy the CISCO router (once it is configured for recognizing and
passing the IP security option), and to satisfy the customer
requirement to be "dnsix", I should think you could start by using the
default_tsix_1_0 host template in TNETRHDB. It has nlm_type=ipso
defined.
However, the doi in the default template is ripso_eso. The domain of
interprestation, doi=dnsix, is defined in the TNETDOMAINDB, and you
probably want to create a template using that doi. But that depends on
what the customer means by "must use DNSIX".
In MLS+ V3.1A, you configure the mappings to classifications in the
/tcb/files/ripso.conf file. In MLS+ V4, the configuration files have
changed. They are located in /var/adm/tnet. The default TNETDOMAINDB
is more or less the same (new comments) but the RIPSO classifications
mappings appear in the /var/adm/tnet/mappings.d/ripso_class file.
These values are the values that will be pumped into the IP header as
part of the security IP header option.
|