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

Re: Decoupling compression and security



On Tue, 26 Nov 1996, Bob Monsour wrote:
(Yes, I'm a little slow to reply)

> At 10:34 AM 11/25/96 +0200, Santeri Paavolainen wrote:
> >Of course, this would mean there is overhead of SPI vs. "bit", but I
> >think the generality is a clear plus. What if you later find out the
> >cryptographic transformation you have embedded the compression layer
> >is not secure? Also, there is no clear way how to interoperate between
> >different transformations which have the same compression engine (you
> >must remember that each transformation should be self-contained from
> >the coding point of view). 
> ...
> 
> This is more than just an issue of the overhead of an SPI vs. a "bit". Let
> me explain by way of example. Let's say that a security association has
> been set up for traffic traveling from a sender to a receiver. Thus the SPI
> for traffic in that direction is  specified. Let's also say that the SPI
> specifies the use of a particular set of compression, encryption and
> authentication algorithms. Then, let's say that the sender wants to send a
> datagram to the receiver. Suppose the data expands. The sender would then
> want to send the original uncompressed form of the data. Under our
> proposal, all the sender would have to do is to change a bit at the start
> of the payload. Under what you propose, the SPI is no longer valid since
> the reciever will erroneously attempt to decompress raw data. Your method
> would thus require that a new SPI be used which would likely require some
> renegotiation between the sender and receiver as to which algorithms and
> modes are to be used for the connection.

Why regenotiation? Why can't they negotiate multiple valid SPI groups
for a single "connection"? Is this a limit of ISAKMP? The way I have
read the drafts I see no implicit reason that a single "connection"
could not have multiple valid SPI groups. In essence, there would be
two valid SPI groups negotiated for the connection
	
	CRYPT,COMPRESS and	(used for compressed and crypted packets)
	CRYPT			(packets which do not benefit from compression)

By the way (a general question) -- how do current implementations
handle the following situations:

- A single "receiving port" (defined such as a TCP port) receiving
  packets with different SPI's or no IPSEC at all, and handling them
  correctly (as with UDP receiver, receiving packets from multiple
  senders, each with their own different security parameters eg. SPIs,
  or having the abovementioned maybe-compressed packet situation)

- Sending packets with different SPIs from same source to same
  destination (several processes with access to the same socket, each
  having set its own security parameters!)

- Handling of deeply-nested packets, eg. ESP(ESP(ESP(ESP(ESP(...))))),
  all with the same or different SPIs (this is a denial of service
  attack) when there is no receiver wanting packets in a such
  configuration

And one more thing that has been in my mind: Instead of defining
separate transport and tunnel modes for all transformations (AH and
ESP alike), why not define just transformations which take no ground
whether they are working on a transformation or tunnel packet? Then
there would be a need for a "tunnel transformation" which would in
essence do IP-in-IP encapsulation, but within IPSEC and SPI framework.

Like that ESP-tunneled packet would look

	ESP(TUNNEL(packet))

Naturally, this incurs the overhead of having to insert Yet Another
SPI to the transported packet. Truly, I do not think that replacing
the current scheme with this would be good.. but there are most likely
some situations where someone wants to TUNNEL a packet without wanting
to use tunneling ESP/AH for it (or any other IPSEC transformation that
would support tunneling)?

--
sjpaavol@cc.Helsinki.FI          I have become death, destroyer of the worlds.