<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: Suggestions for changes/improvements for the CIPE protocol
From: Alan Stern <stern,AT,rowland,DOT,harvard,DOT,edu>
Date: Wed, 30 Oct 2002 18:08:24 +0100
In-reply-to: <E186dZ5-0002y1-00@bigred.inka.de>

On Tue, 29 Oct 2002, Olaf Titz wrote:

> [Static keys, KX procedure]
> > This leaves the problem of handling the situation where an NK_ACK
> > reply is lost.  The receiver is expecting to see the new dynamic key,
> > but the sender doesn't realize that and continues using the old one.
> > To solve this problem, the receiver must store two dynamic keys,
> > both the old one and the new one.  Each incoming packet must be
> > decrypted first with the new key; if the CRC check fails then it must
> > be decrypted using the old key.  Receipt of a packet that uses the new
> > dynamic key is the indication that the old key can be erased.  If the
> I've thought of this in the beginning of the project several years
> ago, and decided that I didn't want to decrypt packets twice mainly
> for efficiency reasons. (386/25 and all that ;-) This reasoning may
> well be bogus today, but I still think it is inelegant.

It is inelegant.  My proposal does have one saving grace: For each key
exchange, only one packet needs to be decrypted twice.  As soon as a
packet is found that fails decryption with the old key but succeeds with
the new key, the old key is abandoned.

This leaves open the possibility that, because of out-of-order delivery,
some packets that were encrypted with the old key may not be recognized
(i.e., if they arrive after a packet that was encrypted with the new key).
This doesn't seem like a big issue, especially since the current protocol
has exactly the same problem.  Packets encrypted with an old key but
received after an NK_IND are decrypted with the new key, which makes them

> In fact when we try two keys, we can as well lose the static-key flag
> in the IV and try three keys. This would remove another little
> ugliness from the crypto POV. Of course that is incompatible (your
> proposal doesn't strictly change the protocol; with mixed protocols it
> leads to massive packet loss after a KX failure but that should be
> able to heal itself eventually. At least I think so).

The difference is that the static key can get used reasonably often during
a CIPE session (for data transfer whenever a key exchange is taking place,
for example), and you don't want the overhead of having to decrypt all
those packets twice.

Another possibility I considered would be to allocate another bit flag in
the IV and use it to indicate whether the old or the new encryption key
was being used.  But this is not really necessary, and it exposes
information that ought to be kept secret.

> I'm not really sure where to go here. When a real protocol overhaul
> (i.e. which would introduce protocol version 5) is necessary some work
> in this area will have to be done, esp. to show that it remains stable
> in all packet loss scenarios.

I'm pretty sure that my proposal would be okay in that regard.  The only
ways I can think of it failing are if sufficiently many packets are lost
over a sufficiently long time that the current key expires, or if a host
is rebooted.  In either case, it would make sense to decide that the link
had gone down and needed to be re-established.

> OTOH I've put more energy in PKCIPE the last time I did major
> development, precisely to do away with the key longevity problem.

Here's another way to look at things.  Don't think of the static key as
something special, to be held in reserve and used whenever the dynamic key
isn't available.  Instead, think of it merely as the initial value of the
dynamic key when a link is started.  With links established using PKCIPE
that is very nearly true, anyway.  With links that don't use PKCIPE, the
key would have to be changed immediately, but afterward all communication
could rely exlusively on dynamic keys.

For all this to make sense, you need to have some notion of the link being
up or down that's a little more explicit than the one used now (which is
just "if enough errors occur, ciped terminates").  And there would have to
be some sort of link establishment as part of the protocol, but it could
be very simple.

> [Replay attacks, timestamps]
> This looks too complicated to me. Better make the window even less
> than 10 seconds and require the peers to be synchronized. I run NTP on
> every box I have, for the time when I used CIPE to connect machines
> across the country, one of which was a cheap router on a nonpermanent
> connection, I even used a homebuilt DCF77 clock on that box. There are
> too many applications already which require synchronized clocks and
> proper synchronization is cheap enough (again, with the current state
> of hw/sw machinery at least) to not allow slack here.

That sounds like a good idea to me.  If nothing else, the two hosts could
run NTP between themselves.

> [Packet stealing by replay]
> This would be a job for STUN instead of creating our own solution
> (which basically does the same thing as STUN) - when/if that becomes
> standard 

STUN is a bit more general purpose.  It tries to determine the properties
of all the NAT servers lying between a client and the Internet.  CIPE
doesn't need to know all that; it just needs to know what IP address and
port to use for one particular connection.  We can get that simply by
having one host tell the other what address was stored in the received
packet.  (This could even be included in the link establishment

Also, STUN requires the use of TSL, which might not be available.

> Another concern why STUN or similar external solutions are desirable
> is that we're currently unable to connect two NATed hosts, even with
> PKCIPE. This requires a mediator, and even though writing one is easy
> (the core STUN protocol is little more than ping, just the
> authentication stuff makes it complex) many users are in a situation
> where they can't deploy arbitrary software on a permanently connected
> host.

As far as I can see, STUN won't do this either.  It's a tough problem in
general.  Some NAT servers don't allow their clients to have listening
sockets accessible to the entire Internet at all.

Alan Stern

<< | Thread Index | >> ]    [ << | Date Index | >> ]