[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Routing

	 Why not, if the security association exists between the router
	 and another entity (isn't that the entire reason for
	 encapsulation, to allow intermediate systems to encapsulate
	 datagrams for protected transport across the net?), further
	 postulate a multi-level secure router, attached to multiple
	 red/plaintext side single-level nets. The router therefore
	 needs to distinguish between messages of differing
	 classifications, and as I've seen the SAID described he can
	 encode it that way. (I'll point out that if you do this it is
	 really broken, since the data (not the association) should be
	 labeled.

	 If one looks at classification as simply another QOS
	 identifier, then the SAID can be assigned on the basis of (or
	 included encoding for) a classification.

	 All this being said, I don't see this as a routing problem,
	 but one of security architecture and fuzzy thought.

There are certainly many possible ways to implement a security
architecture.  It may be that the drafts are not clear.  The intent of
the current design is the SAID is strictly an endpoint concept, and is
not known to intermediate hops.  It manifestly is not a security
label.  I personally prefer the term ``key identifier'', from the
SP3/SP4 drafts; it's much less confusing than OSIspeak.

With the exception of the reserved values -- which are a concession to
the need for other possible models of how to do things -- the SAID can
be thought of as strictly a table index.  The table itself supplies the
cryptographic algorithm identifier, the current session key, the
security level, the expiration time, and any host-specific information,
such as userid.

There is a missing architectural piece:  some IPv6 header or hop-by-hop
option to carry a security label.  If ESP is deployed
gateway-to-gateway or gateway-to-host, in a multilevel environment,
there needs to be some way for the host and the encrypting gateway
(which may or may not be a router) to communicate.

The SAID was not intended for this purpose for a number of reasons.
First, of course, it was intended primarily for use in non-MLS
environments.  A related point is that you can only believe encoded
semantics if they arrive from a trustworthy source; most wires on
today's Internet (and for that matter, most hosts) cannot be trusted in
that fashion.  Third, it's not, in my opinion, a good idea to label
sensitive traffic; what better signal to an eavesdropper about what
traffic to collect and try to (crypt)analyze?  It's much better to keep
that hidden inside the key management protocol.  If, by some chance,
you have a cipher system that is suitable for carrying Top Secret
information, but only over Secret-rated lines -- well, as I said, there
is a need for a label attribute somewhere.  I've mentioned this in
the past; I now suggest that someone from the affected communities should
write a draft.


		--Steve Bellovin