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

Re: Where does security belong?

On Dec 2,  7:59am, Tom Benkart wrote:

} I'd like to second Phil's comments about the "appropriate" place
} for security in the protocol stack.  Restricting information at
} the IP layer to only that which is needed by end AND intermediate
} (router) systems is my strong preference.  

  I don't think there is any single place in the protocol stack that
has an exclusive on security.  My understanding is that the current
work in ipsec is on security for IPv4 (with perhaps an eye towards
SIP/PIP/CLNP/etc).  Working on IP level security need not preclude
subsequent or parallel work at other layers.  There has already been
discussion of handling key management in parallel and possibly doing
it at a different layer in the stack (I *do* hope that work proceeds
in parallel rather than being deferred).

} Not very much security-related information falls into this category.

Not sure what this means.  See below.

} Most of the discussion so far has centered around authentication,
} integrity and confidentiality.  By my criteria from the first
} paragraph, none of these *have* to be handled at the IP level.

  I disagree, by your own criteria, there are many that HAVE to be
handled at the IP level.  For example, without some kind of
authentication in ICMP, there are a very large number of attacks on
both end systems and intermediate systems (Super Source Quench is only
one example).  Policy-based routing (which would be of significant
value to the Navy and probably also most commercial network service
providers) cannot be reliably implemented unless there is some
mechanism which provides assurance that the information used to make
the routing decision is in fact authentic and not forged.
Policy-based routing would probably depend on the source of the
traffic as well as the destination and might also depend on QOS
information.  There are numerous other examples that directly relate.
	 
} Conspicuously absent from the discussion is any mention of access
} control, which would have to be done at the IP level since routers
} might need to restrict routes based on that information.  It is
} also interesting that access control is about the only thing the
} current RIPSO/CIPSO provides.  Is the lack of mention of access
} control because no one really wants/needs it, or because it is
} assumed as a given?

  RIPSO/CIPSO do NOT provide access control.  That is a myth or
perhaps "aggressive marketing" -- depending on one's perspective about
marketing.

  The RIPSO/CIPSO options provide unauthenticated label information on
the sensitivity of the data in the IP datagram.  The CIPSO folks have
strongly resisted efforts to add more descriptive language to their
draft clarifying how to handle packets that are out of range and so
forth -- so the CIPSO draft doesn't even provide any requirements on
access control in the end system, let alone distinguishing the
intermediate router case.  What the receiving host with the arriving
packet is not fully specified -- most trusted systems will map the
received sensitivity label into an internal-to-the-OS sensitivity
label and make MAC decisions based on the OS label.

  Moreover, it is almost trivial to modify the RIPSO/CIPSO label on
the fly (i.e. while the packet is in transit).  Without some
authentication mechanism for the CIPSO/RIPSO information, one can not
make any kind of dependable access control decision based on the
information in that label.

  Optional support for some kind of authentication (whether bundled
with confidentiality or also available separately) is clearly needed.
Integrity and confidentiality properties are also desired by many, at
least optionally (regardless of whether one has an IP option or
optionally encapsulates IP into another security protocol).

Ran
atkinson@itd.nrl.navy.mil




--