[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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.