[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: Request for review of IKEv2/IPsec failover solution draft
2007/12/5, Yaron Sheffer <yaronf@xxxxxxxxxxxxxx>:
> 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 :-)
Yes, but, IHMO, this is a key part that is missing :(
> 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
> 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.
FYI, my company has deployed an UMA based service (i.e. IKEv2 inside)
in many countries in Europe and I can tell you that we are using IKEv2
gateways from different vendors.
> -----Original Message-----
> From: owner-ietf-ipsec-failover@xxxxxxxxxxxxx
> [mailto:owner-ietf-ipsec-failover@xxxxxxxxxxxxx] On Behalf Of Jean-Michel
> 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
> 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.
> 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.