Conference smurf::dec_mls_plus

From:	SMURF::BAT          "Barbara A. Thomson ZKO3-2/X46 1-2955" 12-MAR-1997 16:21:54.50
To:	NM%US2RMC::"sowards@mail.dec.com"
CC:	BAT
Subj:	screend and not forwarding IP header options


	My first cut:

	1) no one has changed screend to do anything differently
	2) I think TSIX protocols put the security info inside
		the IP message, not in the header, so packets
		sent with TSIX protocols would be unaffected.

	3) I think tnet protocols (maxsix, tnet, etc.) put the
		security info into the IP header options field.
		So packets sent with tnet protocols would not
		be forwarded.

	BUT I have to confirm all of the above.

	Regards,
	BAT
    

    We have some conflicting info here, and only testing will out.
    I'll let you know when it gets done.
    
    All the trusted networking protocols use the IP header option field to
    some extent or other. The IPSO (=RIPSO) protocol tries to stuff the
    actual security attributes (that it cares about) in the header; the
    others stuff the security attributes themselves in the body of the IP,
    but use an IP header option field to identify the top-level protocol
    type.
    

    Franklin says he tested it, and it works (but we don't know why :-).

    Just to correct a statement made earlier (.1):
    
    "All the trusted networking protocols use the IP header options field
    to some extent or other"  
    
    is not strictly true.   
    
    You need to use the IP header options (IPSO/RIPSO or CIPSO) labeling
    only if you are talking to some host, e.g., CRAY, that doesn't have
    session labelling or if you want to use a router, e.g., CISCO, that
    routes or screens things for you based on the IP header options.
    
    It is perfectly valid to *not* use the IP header options field, i.e.,
    nlm_type = unlabeled in the TNETRHDB entry.  
    
    The complete set of CMW security attributes (labels, privs, etc.) are 
    handled at the session layer with smm_type = tsix.
    
    
    Now, back to the question of screend -- so even if screend did throw
    away all IP packets with the IP options bit set, you could still have
    screend forward/screen things if you use nlm_type = unlabeled.  But
    screend apparently is not dropping packet with the IP option bit set,
    so don't worry about it :-)

From:	US2RMC::"Sowards@mail.dec.com" "Mark Sowards" 24-MAR-1997 19:03:37.21
To:	"'Barbara A. Thomson ZKO3-2/X46 1-2955  12-Mar-1997 1619'" <smurf::bat>
CC:	
Subj:	RE: screend and not forwarding IP header options


   Barbara,
   I was wondering if you had had a chance to confirm you suspicions
about 'screend'.  It seems that the user is using TSIX, but screend is
not working with multilevel IP traffic.

From:	SMTP%"haskell@kamlia.zk3.dec.com" 25-MAR-1997 13:26:01.60
To:	Sowards@mail.dec.com
CC:	
Subj:	screend

Mark,
It seems that I have become the screend expert around here.  I did some
limited testing of it and it seemed to work as it should.  What sort of
things is screend doing or not doing for you?  
-Franklin

To: Sowards@mail.dec.com
Cc: haskell, bat
Subject: Re: screend 
In-Reply-To: Your message of "Tue, 08 Apr 97 11:10:42 EDT."
Date: Tue, 08 Apr 97 11:27:02 -0400
From: haskell
X-Mts: smtp

Mark,
Yes, I tested it using multi-level traffic.  A few questions for your
customer:

1.  What protocol are they using?  TSIX 1.0, TSIX 1.1, TNET, or what?  

2.  "...seems to ignore the communications."  screend's job is to tell
the kernel not to deliver certain packets.  Is screend not 'screening out'
the packets the customer does not want to go through?  Or is it dropping
everything on the floor.?

3.  What traffic are they trying to 'screen out'?


You need to configure pseudo-device gwscreen into the kernel.  And when
your machine comes up it has to run the screend daemon.  screend reads its
configuration file which tells it what to drop.This info is pretty well
described in the manpages.

Basically, the kernel sends all its incoming packets to screend, who decides
if he likes them or not.  If screend disapproves, the packet does not get
forwarded.  I started digging into the mechanisms used but had to move on
to other things before I acquired a thorough understanding.  I should be 
able to answer most questions, though.
- -Franklin

    

    Just to update this, Franklin has been able to reproduce their problem
    using their set of commands/setup.

    It turns out that the problem I produced was the not the customer's
    problem;  but I did solve it :-)  Which is to say I have not been
    able to reproduce the customer problem.
    
    The problem I did find revealed a capability of the configuration
    file specifications.  Modifiers can be applied to both the source
    and destination host specifiers.  This is necessary to ensure
    communication between components.  E.g. you can screen-out everything
    but telnet traffic to all nodes:
    
    default reject;
    from host any to host any tcp port telnet accept;
    
    but you wont' get any telnet traffic coming back unless you also include:
    
    from host any tcp port telnet to host any accept;
    
    There is good news, however.  The kernel is stripping off the IP 
    security options from the packets and stashing them away elsewhere
    before it ships them up to screend for its scrutiny.  Other options
    do remain attached, however they do NOT cause the packet to be dis-
    carded.  They cause the destination field to be set to the value for
    "broadcast".  This is meant to cause that field to match against
    most anything present in the configuration file presumably causing
    the packet to get 'screened-out'.  We need to update the manpage.