Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193

2010-10-20 Thread David Wierbowski
RFC and understand the issues. When in doubt they post a question here. Dave Wierbowski From: Yoav Nir To: IPsecme WG Date: 10/20/2010 04:10 AM Subject:Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193 Sent by:ipsec-boun...@ietf.org

Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193

2010-10-20 Thread Yoav Nir
Hi all I have started this thread about this issue a week ago, and so far the only responses we have had are from Yaron and Frederic. I would like to hear some more, because this issue is very central. Here's a summary of my take on this issue. The draft does not mandate any particular method

Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193

2010-10-17 Thread Frederic Detienne
This type of debate happened before and once again, it is critical to design a secure protocol rather than a protocol that can/may be implemented securely. The rejoinder is to - offer recommended cookie computation methods - highlight the risks of each method and the risks of doing something e

Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193

2010-10-17 Thread Yoav Nir
On Oct 17, 2010, at 2:57 PM, Yaron Sheffer wrote: > Hi Frederic, > > I understand the scenario now and I agree that a solution is needed. But > I have two issues, one general and one specific: > > - Even though there are no interoperability implications, I think we > should specify the token

Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193

2010-10-17 Thread Yaron Sheffer
Hi Frederic, I understand the scenario now and I agree that a solution is needed. But I have two issues, one general and one specific: - Even though there are no interoperability implications, I think we should specify the token format. This will prevent people from making some security-crit