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

Re: Tunnel Establishment Protocol II

On May 16,  9:07am, Donald E. Eastlake 3rd (Beast) wrote:

> >I would suggest that this become an RFC for the IPSEC encapsulation, but I
> >want input from the group.
> 
> ?  This doesn't talk at all about IP encapsulation.  It seems to be
> only an incomplete session key negotiation protocol.  Based on my
> experience in dnssec, you can rest assured that pushing to really make
> it a standards track RFC will cause lots of big guns to blast you at
> least for suggesting the use of RSA due to patent issues, failing to
> provide for multiple algorithms, and probably lots of other things.

In talking to the people in charge, they had a suggestion that the work in 
this group could be accomplished with 2 documents. One for the key setup
and one for the tunnel itself. I was going forward on the key setup
half.

Hopefully, someone will come forward for the tunnel part.

> Procedurally, I believe any standards track RFC is *required* to be up
> as an Internet Draft for at least two weeks before the RFC comes out
> and this is a good idea for Informational, Experimental, etc. RFCs
> also.  So you should get the specs and reformat as an Internet Draft.

I wanted to know that this was a valuable effort so as not to be wasting 
our collective time. 

> Also, of course, you need rough consensus to go to Proposed Standard
> (the first standars track rung) and assuming this from the silence
> that has occured so far would be a big mistake.

Agreed.

> Some overall comments: This reads to me like a pretty rough incomplete
> spec that addresses way too narrow a part of the problem.  It seems to
> believe in only a single tunnel between any pair of IP addresses and
> fails to adequately address multicast, multi-homed hosts, tunnels
> between subnets or a host and a subnet as distinguished from between
> two hosts, cases where a host crashes and reboots rapidly (this point
> may be covered by but it's not at all clear (I suggest adding a state
> diagram)), cases where you want multiple tunnels between singly homed
> hosts (yes, I know the arguments that it is logically unnecessary to
> have more than one such tunnel but the fact remains that many people
> consider it a requirement in the muilti-level secure world), etc.,
> etc.,

More then one tunnel is indeed needed.

> >One questions I do have is:
> >
> >Is the "pounding on the tunnel creation task" a real important threat? 
> >Removing this eliminates one RSA decryption as well as eliminating any 
> >data hiding during key negotiation.
> 
> Sure it's a threat.  Everything you can imangine the adversary doing
> is a threat.  I'm not sure just how common a threat it will be
> though..

I will continue to address this threat.

> You are going to have to provide for and document a capability for at
> least adding additional alternative security algorithms later for
> everything.

OK.

> See my remarks above.  You are going to have to allow multiple tunnels
> between a pair of IP addresses.  If someone can sniff the wire and
> fire lots of old packets at you, they can probably deny service by
> just flooding it with crap or cutting the wire.  You should be secure
> against replay, etc., within the security policy you are enforcing,
> but I wouldn't worry that much about this punding threat as such.

OK.

> I assume the point of mentioning this threat is that with randomly
> derived Diffie-Hellman session keys that are destroyed after the
> session, later compromise of either end (or both ends) does not reveal
> a way to decrypt the traffic sent.  Yet you don't say so.

Yes, although I consider that an implementation issue. A not to the wise
would be best.

> >Licenses.
> >
> >The developer is warned that both RSA and Diffie-Hellman licenses may be
> >needed to create a compliant implementation. This document does not imply that
> >these licences or any other licences necessary to implement this have been
> >waved.
> 
> The more you start talking about licensing the more or a morass you
> get into and the more lawyers you need drafting and reviewing your
> paper.  I suggest you say the minimum you feel good with like: "Some
> of the algorithms used in this protocol are coverd by patents in some
> countries." or perhaps saying nothing.  If this becomes an RFC, why
> have it mucked up with patent stuff which will expire in not that many
> years?

Good statement.

> Somewhat the same as licensing.  You have the choice of a weak
> algorithm or one exportable from the US.  Since there are plenty of
> smart people in other countried who can implement crypto, you should
> obviously go with strong algorithms as they are no bar to global
> interoperability.
  
Ditto.

> >The protocol is comprised of two messages.
> 
> Using just two messages is good.

> >Tunnel keep alive messages are sent and acknowledged at a predetermined
> >regular basis. Both sides send the requests and both sides send the Ackd.
> >These messages are passed within the tunnel and are encrypted by that process.
> >The format of the tunnel alive messages are in the tunnel document.
> 
> Traditionally, IETF protocols are timing independent and don't use
> keep alives.  I don't see that they are needed here.  Instead you
> should have a tunnel tear down message.

The problem I am trying to address is the case where there are multiple 
gateways (routers) to the same destination. In this case, if a router
fails, traffic will just cease. Without the keepalives, the tunnel can 
not migrate to another router.

> >"Tunnel Lifetime" is the expected time for the tunnel to live. This value,
> >added to the local time of day creates both the expected time of day to be
> >used in the next request as well as allowing the Responder to calculate the
> >time after which it is to expect that negotiation to occur. Tunnel
> >renegotiation can occur sooner if the tunnel keep alive messages show that the
> >tunnel has collapsed.
> 
> I don't see any point in all this tunnel lifetime stuff.  Just send a
> tear down message when you want the tunnel to go away.

If an attacker wants the tunnel to stay up longer (because he cracked the key) 
he can just toss any tunnel teardown messages. Is this a problem?

> >"Random Padding" is used to pad out the block to the RSA modulus. If both
> >sides are using the same modulus, then the start and end of the packets are
> >both offset by 2 words. If the modulus differ, then the largest one is used to
> >calculate the padding. Both RSAs will be anchored at the *. The calculation
> >with the shorter modulus is allowed to fall short of the +.
> 
> Although it would not make much difference in this case, RSA is more
> secure when padded at the top rather than at the bottom. In fact, you
> probably want to use something very much like PKCS#1 (Public Key
> Cryptographic Standard No. 1).  You can get this by anonymous ftp from
> rsa.com.

OK.

> >The responder can not use the SAID until a packet is received on the new SAID
> >tunnel. This can either be a packet or a Tunnel Alive message.
> 
> The synchronousness of your tunnel re-negotiation seems like a
> problem.  It seems better to set up a new tunnel and then, after a
> reasonable timeout for straggler packers, to close the old one.  Have
> you really considered what happens for all the cases of miss ordered /
> lost / duplicated data and control packets?  What if the data being
> sent through the tunnel is pseudo-real time like voice?

I will add more about keeping a tunnel alive while the next tunnel is being 
negotiated. What you said -is- what I intended.

> Anyway, those are some comments off the top of my head.
> 
> Hope you find them useful.

Yes, I do, and I will continue.

I will also try to put these into a standard IETF form.

> Donald

jim
Follow-Ups: References: