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

Re: proposed IPSEC changes/extensions



-----BEGIN PGP SIGNED MESSAGE-----

That was my view, which is why I proposed it as a separate transform.

I believe the different points of view have to do with the use of
history-based or non-history-based compression.

It is my opinion that both schemes have a place.  I sort of see things
evolving from use of a separate transform or protocol, towards some sort
of combined mechanism.  I assume that eventually the transforms actually
used in the real world will be optimized for combined functions such as
the 3des-compression-replay-etc. transform.

>Date: Thu, 31 Oct 1996 09:50:25 -0500
>From: Hilarie Orman <ho@earth.hpc.org>
>To: msabin@netcom.com
>Cc: ipsec@TIS.COM
>Subject: Re: proposed IPSEC changes/extensions
>Sender: ipsec-approval@neptune.hq.tis.com
>
>> 2)  Compression is stateful, which means that the transmitter and
receiver
>> can get out of sync if packets are missed.
>
>Isn't stateful compression is most logically done as a separate
>protocol, performed prior to any IPSEC encryption?

-----BEGIN PGP SIGNATURE-----
Version: 4.0 Business Edition
Comment: PGP by ViaCrypt

iQCVAgUBMnzT2cKmlvJNktGxAQGrZAP8CWC8JqC80/Sire6f9OYiibM2H2JVnFMc
1LvLR/y2RjZyCKIb2ppEVm3QJ9eBXbJjNwwWDReQmton0Ei73IB5ZAPL3sue7An8
WjZWks3k2U1CT2on9Z5WomJJKy4tLvyYgsJUYHGjcn+6fNpXtohgiSEnpIC0NCjt
JE/stO4Nbzg=
=WY44
-----END PGP SIGNATURE-----

               Rodney Thayer <rodney@sabletech.com>       +1 617 332 7292
               Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
               Fax: +1 617 332 7970           http://www.shore.net/~sable
                           Communications Software Development


Date: Fri, 1 Nov 1996 16:02:53 -0500
From: Hilarie Orman <ho@earth.hpc.org>
Message-Id: <199611012102.QAA26649@earth.hpc.org>
To: kent@bbn.com
Cc: ipsec@TIS.COM
In-reply-to: Yourmessage <v02130502ae9ff67db166@[128.89.0.110]>
Subject: Re: proposed IPSEC changes/extensions
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

It's not good to see the design process driven by the perceived difficulty
of modifying an old base and the perceived difficulty of getting through
standards process.

Hilarie



To: Hilarie Orman <ho@earth.hpc.org>
cc: kent@bbn.com, ipsec@TIS.COM
Subject: Re: proposed IPSEC changes/extensions 
Date: Fri, 01 Nov 1996 20:44:58 -0500
From: Steven Bellovin <smb@research.att.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID:  <9611040742.aa27436@neptune.TIS.COM>

	 It's not good to see the design process driven by the
	 perceived difficulty of modifying an old base and the
	 perceived difficulty of getting through standards process.

I'd intended to wait a few days before posting this, but...

The issue isn't one of process.  Rather, it's what we know how to do.
We know (or think we know) how to build ESP and AH.  Many of us have
a few qualms about pieces of the spec, but they're not worth revisiting
anymore -- we have a spec and it works.

I'm much less sanguine that we know how to do compression.  We don't
have a spec (or rather, if we do have one, I couldn't find it; the
best I found was draft-thayer-seccomp-00.txt, and it referenced a
BoF for technical details), and there are some obvious technical
details in implementing compression over a lossy medium such as IP.
Yes, there's a requirement for a resync bit -- but does that imply
a need for compression-level NAK packets, to say that something was
dropped, and that we need to resync?  (Possibly all of these objections
have been dealt with in the technical draft -- I haven't seen it, which
is why I had wanted to wait.)

My estimate is that it will take about a year before we have a clean
spec for compression, independent of the standards process.  I don't
want to wait until then to start deploying IPSEC.  Nor am I convinced
that we know what fields to add now to the ESP header, to leave room
for compression.

The question of one versus two sequence numbers is mostly irrelevant.
Even if we have only one, there's no reason why ESP cannot pass the value
to the decompressor.  That's a matter of interface design -- and if we
so choose, we will impose a new requirement on the interface.

It isn't clear that an additional sequence number would add more probable
plaintext.  If the starting point was random, you'd need a two-packet
attack to start.  And looking at the draft I cited, I'd say that at least
44 bits of the remaining 48 are predictable for a simpler single-packet
attack.  (The sequence number field is 16 bits in that draft.)  I'd also
want to look at what the beginning of the compressed packet looked like.



Date: Sun, 3 Nov 1996 18:18:54 -0800
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199611040218.SAA15844@cornpuffs.cisco.com>
To: sommerfeld@apollo.hp.com
Subject: Re: proposed IPSEC changes/extensions
In-Reply-To: <199611012212.RAA01728@thunk.orchard.medford.ma.us>
References: <9610292001.AA22994@secpwr.watson.ibm.com>
Organization: cisco Systems
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

In article <199611012212.RAA01728@thunk.orchard.medford.ma.us>, 
	Bill Sommerfeld wrote:

>Definitely.  the current isakmp-05 draft says:
>
>   In particular, key lifetimes and SA lifetimes are purely a local
>   issue, and should not be negotiated.
>
>I think this is *very* wrong.  It means that a receiver can terminate
>an SA while the sender still thinks its valid... this will set off
>false alarms when incoming traffic fails to decrypt/verify, and freeze
>user traffic for several RTT's while the key mgmt protocols try to
>resynchronize.  Very clumsy..

I agree with Bill on this.  The next ISAKMP draft should provide
specific support for negotiating soft and hard SA lifetimes.

>ISAKMP currently handles SA removal with explicit DELETE messages, but
>it would be more efficient, in general, to let idle SA's expire
>without the need to send messages (consider demand-dial links .. you
>probably want the SA to live longer than the demand-dial idle timeout,
>and it would be silly to bring the link up just to send a DELETE
>message..).

Yes, though the DELETE message is useful in other cases (e.g. one side
believes the SA to be compromised and wants to ensure the other side does not
use that SA any longer).

Ran
rja@cisco.com





Date: Mon, 4 Nov 1996 13:18:45 +0200 (EET)
From: Santeri Paavolainen <santtu@mail.cs.hut.fi>
To: ipsec@TIS.COM
Subject: Re: proposed IPSEC changes/extensions 
In-Reply-To: <199611011912.OAA01596@thunk.orchard.medford.ma.us>
Message-ID: <Pine.SUN.3.91.961104122622.11989B-100000@hutcs-2.cs.hut.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

On Fri, 1 Nov 1996, Bill Sommerfeld wrote:

> > Even if compression and replay prevention both require state, their state
> > is separate from each other's state. Compression does not need to know
> > anything about replay prevention's state to work. Why should they be
> > defined in the protocol to be contained both in a single
> > transformation? 
> 
> Both replay prevention and stateful compression require sequence
> numbering of some sort.  Putting two sequence numbers which are
> stepped identically in a packet is wasteful; it also *potentially*
> increases the amount of predictable plaintext in a message (a concern
> which Steve Bellovin has raised on at least one occasion)..

Still I do not count such synergy to be good enough reason to include
both of them in a single transformation. Also all the ciphers must
themselves somehow address known-plaintext attacks, and I would not
combine replay prevention and combination just on the basis of "common
sequence number".

I object to any transformation whose behaviour can be changed on
anything else that counts as a "key". If the compression part of this
mega-transformation is optional it should be defined as a separate
transformation which can be optionally applied or not.

We should not except that the only application of IPSEC is critically
secure data links -- a large portion of traffic containet withing
IPSEC will be non-confidential TCP traffic. TCP is inherently safe
from replay prevention, and no cryptographic security is needed. The
only item of interest is authentication, eg. tamperproof connections. 

These would probably also benefit from compression. We can either
define a single huge transformation with a lot of options:

	CRYPTO-HASH-REPLAYPREVENTION-COMPRESS (crypto, hash,
		replayprevention and compression all optional)

or a lot of smaller transformations

	CRYPTO
	HASH
	REPLAYPREVENTION and
	COMPRESS

and apply them layer by layer in any such combination we deem
necessary. Notice that is the mega-transformation uses any component
which fails, such as MD5 instead of SHA, the whole specification has
to be changed. With multiple component transformations one can tailor
the whole combination to their needs.

That is, for a regular WWW page access the user is mostly interested
that the data that is sent is the same data they receive, thus just
the HASH transformation is necessary (TCP has its own state). Anything
more would be overkill.

Thus to satisfy all the possible needs we would have to specify all
the sub-components of the mega-transformation as a separate pieces
anyway. So do what is the need for such mega-transformation in the
first place if we can have the same effect by combining smaller
transformations? I say there is no need.

The issues about implementation efficiency are just that, an
implementation issue. I am not advocating for us to draft "bad"
specifications that would make efficient implementations impossible,
but I do not either want to be hindered by only considering the
efficiency issues.


There is the problem of known-plaintext in layered transformations. We
should always consider SPI as known plaintext (it could be obtained by
breaking the key management traffic, for example), thus if we do

	AH<-CRYPT<-COMPRESS 

for example we in effect supply at least 8 bytes of known plaintext
for the cryptanalyst for breaking the CRYPT portion of such combined
transformation. On the other hand - none of the cryptographic methods
used should except "good" input, eg. such that is inherently
unguessable. I am saying that any cryptographic transformation falling
on these 8 bytes of known plaintext is unusable in the first
place. 

If we are using IPSEC in a tunnel mode, the IP header itself offers a
much better target than any compression or other transformation header
anyway. If we are so concerned about security, we should not include
the COMPRESS transformation in the first place (with a change of
views: we should, as it increases entropy per byte).  Or apply a
stronger cipher.

What good is of an IV, anyway? :-)

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