Hi Paul,
I am afraid you are mistaken. Yoav, Yaron, Pratima and I had a discussion about
the draft's IPR back in Dublin in July 2008. We told back then that we would
have rights released. The process takes its own time but as far as Pratima and
I are concerned, we did due diligence.
Will you s
Hi,
version -01 of the draft has been on the IPsecME wiki for the last few
days. It is now posted under
https://datatracker.ietf.org/doc/draft-sheffer-ipsecme-pake-criteria/
(with a new date, but the same content).
Thanks,
Yaron
___
IPsec mai
At 9:51 AM +0100 3/22/10, Frederic Detienne wrote:
>I am afraid you are mistaken. Yoav, Yaron, Pratima and I had a discussion
>about the draft's IPR back in Dublin in July 2008. We told back then that we
>would have rights released. The process takes its own time but as far as
>Pratima and I are
Hi,
we will *not* discuss this document at today's IPsecME session. But we
would appreciate your comments anyway.
Thanks,
Yaron
Original Message
Subject:I-D Action:draft-sheffer-ipsecme-hush-00.txt
Date: Mon, 22 Mar 2010 01:15:02 -0700 (PDT)
From: internet-dr
The following errata report has been submitted for RFC5739,
"IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)".
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5739&eid=2089
-
The following errata report has been submitted for RFC5739,
"IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)".
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5739&eid=2090
-
Hi Paul,
I am still puzzled that you see fit to check in private with Yoav and in public
with us.
For the records, at least one of the co-chairs (Yaron) was advised about the
IPR at the same time as Yoav.
regards,
fred
On 22 Mar 2010, at 15:09, Paul Hoffman wrote:
> At 9:51 AM +0100
Hi Frederic,
this is correct, however we did not share this information because it
was an individual submission at the time, and we expected Cisco to do
the right thing, i.e. to inform the WG in a timely manner (and later, we
simply forgot).
For some reason, Cisco chose to publish the IPR st
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working
Group of the IETF.
Title : Heuristics for Detecting ESP-NULL packets
Author(s) : T. Kivinen, D. McDonald
Hi Yoav,
another requirement for IPsec HA is to coordinate the use of distinct
counters between multiple crypto engines. The problem (and a
convenient solution) is described in http://tools.ietf.org/html/draft-ietf-msec-ipsec-group-counter-modes-05
David
__
This is probably a small thing, but in general the term "cluster"
implies at least some degree of shared state among cluster members.
I understand that there's some suggestion of that in saying that
a cluster protects the same domain but there's really quite a bit
more to it than that - it's going
Summarizing what I said in the meeting:
(1) The performance criteria should include performance with large complex
secrets (e.g., pre-shared keys), not just the smaller passwords that people can
reasonably be expected to remember.
This is because a password-based authentication mechanism may be
Hi,
Another solution is to use a cipher mode (like SIV) that does not lose
all security if a counter is reused. Then you don't have to worry at all
it.
Dan.
On Mon, March 22, 2010 9:29 am, David McGrew wrote:
> Hi Yoav,
>
> another requirement for IPsec HA is to coordinate the use of dist
Hi David,
I think both of these are (correct) requirements, rather than criteria.
None of the algorithms I've seen care whether it's a 6-char ASCII
password, or 512 truly-random bits. None of them say anything about
management (with the possible exception of the "augmented" algorithms
where t
Hi,
First of all, I am not sure if this fit into existing "supported scenarios"
criteria or it is a new one, the failure detection time is cirtical to some
services runs over ipsec tunnel, such services like VoIP can only tolerate
sub-second(or 1~2 seconds max) of transport failure, otherwise th
On Mar 22, 2010, at 11:18 AM, wrote:
> Summarizing what I said in the meeting:
>
> (1) The performance criteria should include performance with large complex
> secrets (e.g., pre-shared keys), not just the smaller passwords that people
> can reasonably be expected to remember.
>
> This is b
That would be good, but we don't want to madate not using certain modes of
operation when you have a cluster. That would be very counter-productive.
OTOH, because of the replay counter, we've already agreed that an outbound
child SA cannot be shared among members of a load-sharing cluster.
As f
Failure detection by either QCD or SIR takes 1-2 roundtrips, whether this is
subsecond or not depends on round-trip time.
In case of a non-synchronized hot-standby gateway, those 2 roundtrips begin the
moment that the standby gateway becomes active, so the call probably doesn't
get dropped.
In
Yoav,
> IKE already has PSK-based authentication. If my "password" is
> 9975612f178b31164bef5bb672cbeb1db6437d6459ff1d8a17f12ec73fcd5c92, then
I don't need any new-fangled
> mode, because the authentication described in section 2.15 of RFC 4306
is good enough.
If that "password" was generated fro
Criteria: the scheme must support arbitrary octets as the input. I
don't want to pick one that doesn't support whatever the current/future
IETF character set encoding is.
spt
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo
20 matches
Mail list logo
