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

Re: FW: Request for review of IKEv2/IPsec failover solution draft



Hi,

I've read the draft but as I said to Yaron, yesterday evening, I am
not happy with this proposal.

The main reason is that the management of the keys used to
encrypt/decrypt the tickets (i.e. how the new Security Gateway gets
the keys to decrypt the tickets it receives) is out of scope the
proposal and so, as far as I can understand, the keys management
should still be based on proprietary solutions: that means that the
proposal only works between IKEv2 gateways from a same vendor. The
consequence is that if the failover is DoS based (e.g. fuzzing
attacks), IMHO, the proposal is totally useless.

Best regards.

JMC.

2007/12/4, Narayanan, Vidya <vidyan@xxxxxxxxxxxx>:
>
> Forwarding a review from Charlie.
>
> > -----Original Message-----
> > From: Charlie Kaufman [mailto:charliek@xxxxxxxxxxxxxxxxxxxxxx]
> > Sent: Saturday, December 01, 2007 11:48 PM
> > To: Narayanan, Vidya
> > Subject: RE: Request for review of IKEv2/IPsec failover solution draft
> >
> >
> > I know there has been controversy about the need for this
> > performance enhancement to IKEv2 for the gateway failover
> > scenario. I have no strong feelings one way or the other, but
> > I would tend to take the word of the people who are trying to
> > build boxes who say the restart performance is a problem.
> >
> > The cryptographic structure of this protocol appears correct
> > to me, and the syntax is reasonable. I would have done some
> > of the formats differently, but that's a matter of taste. I
> > found a couple of issues that some might find objectionable
> > and a couple of nits:
> >
> > By going with a minimal 2 message exchange, there are certain
> > security properties lost. In particular, if the server is
> > stateless, the initial message can be replayed and the server
> > will set up a new SA. If the message comes from a forged IP
> > address, this can represent a denial of service attack.
> > Perhaps the server could go through a cookie exchange as in
> > IKE if it suspects it is under attack, but that will only
> > prevent DoS from forged IP addresses. Only when the server
> > gets an ESP or AH message can it confirm that the client is
> > genuine. The impostor cannot replay any ESP or AH messages,
> > so this only represents a subtle DoS attack, but some might
> > object to the inelegance. It could be fixed by making the
> > basic exchange be four messages, but that's not really
> > necessary and the spec claims that minimizing the number of
> > messages is critical.
> >
> > Assuming the same ticket encryption key is used for large
> > numbers of connections (which is the only way the protocol
> > makes sense), there is a loss of PFS from the time a
> > connection that has been reestablished using a ticket is
> > closed and the time the ticket encryption key is forgotten.
> > If ticket encryption keys are recycled frequently,
> > connections still open when the ticket key is rolled over
> > will not be recoverable with a ticket. So there is a
> > trade-off between rolling over the tickets frequently (for
> > PFS) and the performance cost of computing and delivering new
> > tickets to all open connections.
> >
> > Some nits:
> >
> > Under 2. Terminology (Secure Domain). It says all gateways
> > share a security association with each other or through a
> > trusted third party. This is not a security association in
> > the sense commonly used in the IPsec world. They need to
> > share a secret key and they need to trust one another. The
> > mechanism for achieving that is unimportant to this spec.
> >
> > On page 11, there is a notification type
> > N(UPDATE_SA_ADDRESSES) that is not defined as a new nonce
> > type but which also doesn't exist in RFC4306. I believe it
> > has been proposed in some other IKE extension documents. I'm
> > not sure it's appropriate here. I would expect that the
> > addresses for the new SAs would be the ones involved in the
> > new negotiation.
> >
>
>