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

Re: Routing

At 7:19 AM 3/17/95, William Allen Simpson wrote:
>> From: throop@dg-rtp.dg.com (Dean D. Throop)
>> We may lose some routing flexability this way.  A router might get a
>> secret message with a SAID that means secret or top secret and not be
>> able to send it on the secret line.
>There seems to be a very serious misconception about a SAID here.  This
>may be because the term SAID is used in other contexts, and we should use
>another term for IPSec (I complained about this long ago).
>SAIDs are relative to the Destination.  No intermediate router knows the
>meaning of the SAID.  No router can use a SAID in its routing decisions.
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

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

>In the event that a Source wishes to specify a particular route for a
>packet to travel, it needs to use a Source Route, or another policy-based
>routing mechanism such as IDPR and Nimrod.  Routing is outside the scope
>of this WG.
No argument.

>> However by abstracting all the MAC
>> info into the SAID, off the shelf routers that know about SAIDs can be
>> used.
>First, this is inapplicable, since routers don't need to know about SAIDs.
>Second, it would help if you used the terminology in the drafts.  MAC is
>not a term used in this context.  SAIDs will not encode Media Access
>Control information.  (Yes, _I_ know you meant "Message Authentication
>Code", but that implies the _result_ of the hash, which is called
>"Authentication Data" in our drafts.  Only the authentication _mechanism_
>is indicated by our SAID.)

I think MAC here means mandatory access control (classification or other
rule-based discriminator). And if he thinks that off the shelf routers
(presumably un-"trusted") will be allowed to provide MAC he needs to think
about it again.

>You have _read_ the drafts, haven't you?

Most of them!