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

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



Hi Jean-Michel,

First, we don't have enough community support to work on a
gateway-to-gateway protocol. Unfortunately we could do with more support
even for the base proposal :-)

Second, a key sharing protocol for 2 gateways could be specified very
easily, as a minor tweak to IKE. I think it's much more difficult for 3 or
more gateways. So we are talking of a major security-sensitive protocol. On
the other hand, if we are only looking for simplistic solutions (just use a
shared database for these keys), the draft provides enough hooks to enable
that.

And last, your experience may be different, but I have yet to see an service
provider purchase boxes from two different vendors for *security* reasons. I
think in real-life, the gateways are likely to be all from the same vendor,
and what we need is client-gateway interoperability.

Thanks,
	Yaron

-----Original Message-----
From: owner-ietf-ipsec-failover@xxxxxxxxxxxxx
[mailto:owner-ietf-ipsec-failover@xxxxxxxxxxxxx] On Behalf Of Jean-Michel
Combes
Sent: Wednesday, December 05, 2007 10:18
To: Narayanan, Vidya
Cc: ietf-ipsec-failover@xxxxxxxx; Tim Polk; Charlie Kaufman
Subject: 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.
> >
>
>


Scanned by Check Point Total Security Gateway.