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

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





> -----Original Message-----
> From: owner-ietf-ipsec-failover@xxxxxxxxxxxxx
[mailto:owner-ietf-ipsec-
> failover@xxxxxxxxxxxxx] On Behalf Of Yaron Sheffer
> Sent: Wednesday, December 05, 2007 12:37 PM
> To: 'Jean-Michel Combes'; 'Narayanan, Vidya'
> Cc: ietf-ipsec-failover@xxxxxxxx; 'Tim Polk'; 'Charlie Kaufman'
> Subject: 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.
> 
[KC>] If you do this tweak, i.e. gateway -to- gateway key sharing
protocol, why can't you share the ticket itself via the same protocol?
Why do you need the client to send the ticket?

> 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.
> 
[KC>] I don't think this is a valid argument to rule out gateway - to -
gateway communication. BTW, operators do buy network gear from multiple
vendors for the same feature/function. At least, that's the desire of
the operator who is speaking up here.

> 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.
> 


"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@xxxxxxxxxxxxxxxxxxx -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."