Tero Kivinen wrote:
Can we live with push-to-talk?
Push-to-talk works well for normal discussion, but it was
impossible to use when giving presentation, which meant that
I myself changed the setting to voice activated microphone
when I started my presentation, and then changed back to
gabriel montenegro wrote:
I'll just comment on one item below:
As the draft says this is mostly meant for stateful devices, and that
has been the main goal for the document. The charter says:
A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion
RFC 4306 specifically requires implementations to support multiple parallel
child SAs.
If you use a different SA for each QoS class, you should not have problems with
the replay window
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Definitely
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott
C Moonen
Sent: Thursday, April 02, 2009 3:48 PM
To: Yaron Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go?
From Appendix C: The
some properties of that as-yet-non-existant IKE SA seems
premature to me. I think it should be in all but the IKE_SA_INIT exchange (and
also not in unprotected informational)
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav
Nir
Sent
Hi Matt
Requests and responses have matching MsgID numbers. The requestor can instantly
identify the response by its matching Msg ID number. INFORMATIONAL exchanges
have message authentication codes applied to messages, so the ID numbers can't
(or shouldn't) get messed up on the responsder.
I prefer the second proposal. I would rather have one (even if longer)
variation of the protocol over two variations (even if one is shorter)
With such a possible attack published, auditors are going to force large
installations to use the safer (and longer) version anyway, as it is up to the
Vijay Devarapalli wrote:
Hello,
Yoav Nir wrote:
I see that in section 6 the following:
In such cases, the gateway should send the REDIRECT notification
payload in the final IKE_AUTH response message that carries the AUTH
payload and the traffic selectors. The gateway MUST
So are we working with the assumption that the gateway (or the AAA server) can
always authenticate any user that connects?
-Original Message-
From: Yaron Sheffer
Sent: Monday, April 20, 2009 10:43 AM
To: Yoav Nir; Vijay Devarapalli
Cc: IPsecme WG
Subject: RE: [IPsec] WG Last Call
I don't think we should really prohibit such extensions and enhancements. It's
just that IKE will fail if you try it with a peer that does not support it.
As far as the end-user is concerned, this is not different from an
UNSUPPORTED_CRITICAL_PAYLOAD in IKE_AUTH. Either way, the tunnel setup
Grewal, Ken wrote:
Issue #90: shorter WESP negotiation
In the current traffic visibility draft, we indicate that WESP can be
negotiated via IKEv2 using a new protocol identifier.
Charlie Kaufman suggested that it may be plausible to use a notification
method along the lines of
Michael Richardson wrote:
Yoav Nir wrote:
Hi Raj
Matt is correct. There is no way in IKEv2 to do a phase1-only
exchange, and then wait for traffic to establish the child SAs.
While we do establish an IKE SA if the piggy-backed child SA failed
for whatever reason (bad selectors
Hi all
I've submitted issue #107 about certificate encoding.
IMO it's not clear how certificate chains are to be encoded in IKEv2.
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107
Yoav
Email secured by Check Point
___
IPsec mailing list
Paul Hoffman wrote:
At 12:53 AM +0300 5/11/09, Yoav Nir wrote:
Paul Hoffman wrote:
At 2:08 PM +0300 5/10/09, Yoav Nir wrote:
Hi all
I've submitted issue #107 about certificate encoding.
IMO it's not clear how certificate chains are to be
encoded in IKEv2.
http
Pasi.Eronen wrote:
Yoav Nir wrote:
You can:
a) start using hash-and-url
b) hope your peer has the sub-CA
c) write an extension to 4306 that allows bundles in CERT
Doing (a) is the most interoperable, but you're probably
save with
(b) in a typical closed network
WARNING: contains banned part
---BeginMessage---
On Tue, 2009-05-12 at 10:05 +, ss murthy nittala wrote:
Hi
Thanks for the clarifications regarding IV usage for AES methods.
RFC 2405 (DES) in its implementation note says
Common practice is to use random data for the first IV and the
Paul Hoffman wrote:
IOW it's up to the initiator whether or not to do PFS, and both
configurations are OK to use the suite name.
That was my intention in RFC 4308; I cannot speak for the
authors of RFC 4869.
You can't speak for them, but Scott has to figure it out.
As for lifetimes,
Hi.
I've read through the draft again, and here are a few comments:
Section 3 has the following line:
If the
IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload,
the responder MUST NOT send the REDIRECT payload to the
be ASCII or UTF-8.
From: Tero Kivinen [kivi...@iki.fi]
Sent: Wednesday, May 27, 2009 13:02
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: [IPsec] Some comments about redirect
Yoav Nir writes:
Section 10 sets up an IANA registry for identity types. Couldn't we
just
in the GUI. In any case, the client is as aware of the names as the
gateways.
From: Vijay Devarapalli [vi...@wichorus.com]
Sent: Thursday, May 28, 2009 01:04
To: Yoav Nir; Tero Kivinen
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Some comments about redirect
Hi Yoav
...@wichorus.com]
Sent: Thursday, May 28, 2009 01:02
To: Yoav Nir; ipsec@ietf.org
Subject: Re: [IPsec] Some comments about redirect
Hello,
On 5/27/09 12:36 AM, Yoav Nir wrote:
Hi.
I've read through the draft again, and here are a few comments:
Section 3 has the following line
-
From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org]
Sent: Sunday, May 31, 2009 6:03 PM
To: Yoav Nir
Subject: New Version Notification for draft-nir-ike-nochild-01
A new version of I-D, draft-nir-ike-nochild-01.txt has been successfuly
submitted by Yoav Nir and posted to the IETF
I'm not so sure about that. The authentication in the IKE_AUTH exchange that
follows the resumption only proves that the (new) responder can decipher the
ticket (or has access to the ticket database).
Presumably a cluster of gateways backing each other up would have the same
IDr, but if
I agree with Yaron that it should be the way it is now described in the draft.
If either side deleted the IKE SA, then it should not come back to life through
session resumption. Specifically, the client should not get reconnected without
authentication. The laptop example is excellent. If I
Hi.
IMO the CFG payloads are the last place where there will ever be a shortage of
IPv4 addresses. The addresses distributed through CFG payloads in IKEv2 or
through extensions to IKEv1 are almost always non-routable addresses, and even
for extremely large organizations, there are plenty of
, 2009 1:43 PM
To: Yoav Nir; Raj Singh
Cc: ipsec@ietf.org
Subject: RE: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
Hi Yoav/Raj,
I think its a good idea for the initiator to announce its capabilities about
supporting just IKE SA without child SA. The responder will then act
I've read it again, and it seems fine. One minor issue, though.
Section 2 describes the WESP header format. It has the following:
HdrLen, 8 bits: Offset to the beginning of the Payload Data in
octets. The receiver MUST ensure that this field matches with
the header offset computed
.
Maybe when we make version 2.1 of IKE, we can add a critical type bit to the
notification payload.
From: Raj Singh [mailto:rsjen...@gmail.com]
Sent: Wednesday, July 08, 2009 7:18 AM
To: Tero Kivinen
Cc: Yaron Sheffer; ipsec@ietf.org; Yoav Nir
Subject: Re: [IPsec] FW
solvable, because the policies actually
conflict.
From: Gaurav Poothia [mailto:gpoot...@microsoft.com]
Sent: Thursday, July 09, 2009 7:57 AM
To: Yoav Nir; 'Raghunandan P (raghup)'; Raj Singh
Cc: ipsec@ietf.org
Subject: RE: [IPsec] FW: I-D Action:draft-nir-ipsecme
to discard #17. If it was still valid for
the initiator to send request #17 again, the responder would have to retain all
the old responses indefinitely.
From: Amjad Inamdar (amjads) [mailto:amj...@cisco.com]
Sent: Wednesday, July 22, 2009 12:23 PM
To: Yoav Nir; Raj
Vijar Devarapalli wrote:
Hi Yoav,
On 7/29/09 9:13 PM, Yoav Nir wrote:
Hi Vijay.
default is usually associated with a particular implementation or
product. I think it would be better to say suggested value rather
than default value.
default value is the right terminology to use here
Any INVALID_IKE_SPI or INVALID_SPI message can trigger DPD (or, as RFC 4306
calls it, liveness check). These messages are very easy to spoof.
But liveness check is just one round trip between the peers and it's supposed
to be rate-limited. I don't think an off-path attacker can cause the
I disagree.
Payloads in a particular CREATE_CHILD_SA exchange should be specifically
related to the SA being created. The IKE_AUTH exchange is different, because
it is used to set up everything we need to get an IPsec SA going.
We do not use the CREATE_CHILD_SA to delete old SAs, to query
Hello all.
Issue #26 was submitted by Tero Kivinen. It concerns section 2.21
(error handling) and states that several things are missing:
- handling of errors before authentication
- listing what error conditions cause the IKE SA to be deleted entirely
- listing how errors are handled in the
On Sep 1, 2009, at 5:07 PM, Tero Kivinen wrote:
Yoav Nir writes:
Following is our suggested new text. Please let us know what you
think. Also, please take a look at the description of
AUTHENTICATION_FAILED in section 3.10.1. response to an IKE_AUTH
message means either an IKE_AUTH response
Hi Kalyani
Of the two, I prefer the 2nd solution, as it is simpler. Reusing message IDs is
not that bad, and you can decrease the change by including (in the
RESET_MESSAGE_ID notification) a random number as the starting message ID.
What I'm not so sure, is that there is a real problem here
Yes, I will soften the language a bit, but I won't mention a DELETE payload. If
some implementations do it. others may come to expect it. We don't want to
encourage that by suggesting that it's a good idea.
On Sep 3, 2009, at 11:52 PM, Keith Welter wrote:
If the error occurs on the
Then I should have explained better.
If an initiator sees an error in the response, the exchange is already over, so
the only way it can notify the responder of the error, is to create a new
INFORMATIONAL exchange with an error notification.
All the text here discusses the one INFORMATIONAL
OK. Let's try this again. Is this acceptable?
2.21. Error Handling
There are many kinds of errors that can occur during IKE processing.
If a request is received that is badly formatted, or unacceptable
for
reasons of policy (e.g., no matching cryptographic algorithms), the
On Sep 7, 2009, at 3:48 PM, Tero Kivinen wrote:
Keith Welter writes:
I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted
either.
I do consider INVALID_SYNTAX fatal error, meaning the IKE SA will be
deleted immediately after sending that response containing
INVALID_SYNTAX
OK. One more try:
2.21. Error Handling
There are many kinds of errors that can occur during IKE processing.
If a request is received that is badly formatted, or unacceptable
for
reasons of policy (e.g., no matching cryptographic algorithms), the
response MUST contain a Notify
On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote:
Section 3.1.5 of RFC 4945 states that when generating an ID type of
ID_DER_ASN1_DN that implementations MUST populate the contents of
ID with the Subject field from the end-entity certificate, and MUST
do so such that a binary
Wierbowski
z/OS Comm Server Developer
Phone:
Tie line: 620-4055
External: 607-429-4055
graycol.gifYoav Nir ---09/17/2009 02:50:34 AM---On Sep 17, 2009, at 5:33 AM,
David Wierbowski wrote: Section 3.1.5 of RFC 4945 states that when ge
ecblank.gif
From: ecblank.gif
Yoav Nir y
Hi all
The draft linked below is a problem statement draft about using
IKEIPsec implementations in high availability and load sharing
configurations.
I will describe this at tomorrows Interim meeting.
Comments are welcome, of course, both on the list and at tomorrow's
session.
Yoav
A
I support advancing this document, and I think the explanations and
pseudo code are good.
I do, however, question the value of it in real life.
Security policies or the deep inspection kind usually are something
like:
- allow HTTP and HTTPS, and verify headers
- allow ICMP and DNS
-
On Sep 24, 2009, at 9:44 PM, Paul Hoffman wrote:
At 12:13 PM -0600 9/24/09, Grewal, Ken wrote:
Proposed change
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Hi Hui
I think there is very little difference between IPv4 and IPv6 as
regards to IPsec. See below
On Oct 11, 2009, at 9:50 AM, Hui Deng wrote:
Dear IPsec forks,
May I get advice about the differnce between them:
1) IPv4 doesn't mandate the support IPsec, IPv6 also doesn't mandate
it
and later in the EAP session.
On Nov 11, 2009, at 4:05 PM, Srinivasu S R S Dhulipala (srinid) wrote:
Hi Yoav,
Thanks for the quick response. Please see inline.
-Original Message-
From: Yoav Nir [mailto:y...@checkpoint.com]
Sent: Wednesday, November 11, 2009 7:23 PM
To: Srinivasu S R S
On Nov 12, 2009, at 5:34 AM, Raj Singh wrote:
The selection of AAA server will be based on IDi then EAP will happen.
The gateway will get EAP authenticated ID from the AAA server.
If EAP identity is different from IDi and no policy is found for EAP identity.
The gateway should initiate
in the
same list as VPN-A and VPN-B.
From: Paul Hoffman [paul.hoff...@vpnc.org]
Sent: Friday, November 13, 2009 02:58
To: Yoav Nir; Law, Laurie; ipsec@ietf.org
Subject: Re: [IPsec] RFC4869 bis submitted
At 10:07 PM +0200 11/11/09, Yoav Nir wrote
What Dan and Gregory said.
But assuming an unloaded gateway, with normal hardware (Any Intel, AMD or
PowerPC processor from the last 10 years or a recent ARM), then even if you use
relatively secure parameters (2048-bit DH group, 2048-bit RSA keys) the round
trip time is going to dominate. The
+1
Even things that seem obvious like https and ftp require a lot of
considerations, like how to verify the certificate in https, or what identity
to present in ftp.
If someone wants to specify additional URL methods, they can specify then in an
I-D.
On Nov 24, 2009, at 8:24 PM, Paul Hoffman
There were several motivations listed for childless IKE SAs.
- remote access, where you create an IKE SA when the user wants to connect,
and only create child SAs in response to traffic
- authentication only over a physically secure network (not necessarily EAP,
but I think this is the use
Hi Alper.
The Do phase 1 first, and phase 2 as traffic demands it motivation is from
the remote access VPN domain (though may be useful for others).
The Do only phase 1, because we don't need encryption and MAC, just peer
authentication motivation is from the 3GPP (though it could be useful
Section 1.4.1 also says:
A node MAY refuse to accept incoming data on half-closed
connections but MUST NOT unilaterally close them and reuse the SPIs.
So if your peer is only responding with empty INFORMATIONAL responses to your
deletes, you're going to accumulate more and more stale inbound
From: ipsec-boun...@ietf.org [ipsec-boun...@ietf.org] On Behalf Of Yoav Nir
[y...@checkpoint.com]
Sent: Wednesday, December 16, 2009 12:01 AM
To: Paul Hoffman; IPsecme WG
Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to
Deletes
On Dec 16, 2009, at 6:36 AM, rahul bharadhwaj wrote:
Hi all
Could anyone let me know which crypt algo des/3des/aes should be used with
aes-xcbc-mac hashing.
As aes-xcbc-mac uses aes for authentication and integrity, is it correct to
apply des for encryption or is there any restriction.
On Jan 5, 2010, at 12:27 AM, Yaron Sheffer wrote:
Hi,
We have had a few discusses during the IESG review of the WESP draft. To
help resolve them, we would like to reopen the following two questions to WG
discussion. Well reasoned answers are certainly appreciated. But plain yes
or no
On Jan 7, 2010, at 9:14 AM, Charlie Kaufman wrote:
Oh sigh!! What is it about IPsec that makes people go down this same path
every time:
snip/
IPsec?
So I guess you haven't been following the TLS mailing list these past couple of
months.
I don't think anyone's described a practical
Hi Scott
When writing remote access VPN clients (running on phones, PCs, tablets,
probably not z/OS) it's usually safe to assume that the peer (a gateway)
supports NAT-T. This is because on the real Internet, a RAS that does not
support NAT-T simply doesn't work. NATs are everywhere.
So it's
+1
Anybody who starts implementing IKEv2 in a few months using the new RFC should
not have to care about the history, and which notify type was added at which
point, except to know that some implementations in the field may not support
these newer notifications.
-Original Message-
We can't really prescribe actions for (presumably older) implementations that
don't support this spec.
Such implementations will do what it says in RFC 4306 and the clarifications
document: TEMPORARY_FAILURE is an error notification, so therefore the exchange
failed. In that case the old SA
Agree. Certainly types 4-6 have to be removed, as they are just methods, and we
RECOMMEND not to use them. I can see some value in mentioning type 1
(Identity), because later in that same section we mention that the responder
should not send such requests. I think we should remove all the rest,
I agree, and I don't think you need brackets:
only the first 64 bits of Ni and the first 64 bits of Nr are used in
calculating SKEYSEED, but all the bits are used for input to the prf+ function.
(although I personally did not find it confusing)
On Jan 19, 2010, at 4:25 AM, Paul Hoffman wrote:
I think extensions such as RoHC that change (or extend) the way keying material
is generated, should and do specify how it is done. Leaving that text there
becomes a recommendation for future draft writers, which I think is
superfluous.
I think we should leave the text as it is.
On Jan 19,
Hi all
We would like to begin closing IKEv2bis issue at a faster rate than we are
opening new ones. Paul has sent the list a several issues. Some we have
discussed, others - not so much. Here's a summary of three issues, which I
think are ready for closure.
Issue #138 - Calculations
On Jan 22, 2010, at 11:57 PM, Yaron Sheffer wrote:
The text in 3.3 requires peace of mind to fully appreciate. A diagram might
be helpful.
Here's a first shot (we'll need to add some descriptive text):
SA Payload
|
On Jan 25, 2010, at 1:44 PM, Tero Kivinen wrote:
Yoav Nir writes:
Issue #141 - Silently deleting the Child SA after a CHILD_SA_NOT_FOUND
==
Section 2.25: A peer that receives a CHILD_SA_NOT_FOUND
notification SHOULD
Hasn't this item just been approved by the IESG? Isn't it done?
snip/
- A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion detection system, to easily and reliably
determine whether an ESP packet is encrypted
Yes, but the heuristics document is not standards-track.
Never mind, I'm not trying to nit-pick our charter proposal.
On Jan 26, 2010, at 11:41 PM, Paul Hoffman wrote:
At 11:27 PM +0200 1/26/10, Yoav Nir wrote:
Hasn't this item just been approved by the IESG? Isn't it done
Hi all.
Combining Pasi's proposed text with Tero's comments I came up with this version.
Is this acceptable to everyone?
Yoav
There are couple of cases when a node receives a packet it cannot
process, but may want to notify the sender about this situation:
o If an ESP or AH packet
Hi all
The offending paragraph is the following;
An initiator can use port 4500, regardless whether or not there is
NAT, even at the beginning of IKE. When either side is using port
4500, sending with UDP encapsulation is not required, but
understanding received packets with UDP
the request. The Response bit is set to 1, and the version
flags are set in the normal fashion.
-Original Message-
From: Tero Kivinen [mailto:kivi...@iki.fi]
Sent: Thursday, January 28, 2010 4:40 PM
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: [IPsec] Closing issue #143 (rewrite of section 1.5
Hi all.
Yet another batch of issues that we wish to close.
Issue #140 - No SPD entry for transport mode
Section 2.23.1: If the responder doesn't find SPD entry for transport mode with
the modified traffic selectors, and does a lookup with the
Me too, but the draft still requires *some* selectors, so the childless draft
is still needed.
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Raj
Singh
Sent: Wednesday, February 03, 2010 5:25 AM
To: Dan McDonald
Cc: IPsecme WG; Paul Hoffman
Hi Raj
I don’t think we can specify MUST requirements for the AAA servers, because
we’re not specifying RADIUS or DIAMETER here.
For example in RADIUS, the VPN gateway sends an Access-Request to the server,
which contains the user-name, presumably the same user-name from the IDi
payload.
If
Hi all.
5 more issues.
Issue #153 - List of EAP methods
3.16: I suggest to remove the table quoted from the EAP RFC. There are dozens
of methods now in the IANA registry, many of which are preferable to the ones
mentioned here.
I agree, especially since we
do need the
user identity.
-Original Message-
From: Alper Yegin [mailto:alper.ye...@yegin.org]
Sent: Thursday, February 04, 2010 3:40 PM
To: Yoav Nir; 'Raj Singh'; Yaron Sheffer
Cc: 'ipsec'
Subject: RE: [IPsec] Fwd: Issue : Regarding EAP identity
Hello,
Why would the IKEv2 responder
Hi. Another week, another 5 issues to discuss.
Issue #159 - Payload processing order within messages
=
(3.1) Clarify that the text:
Payloads are processed in the order in which
they appear in an IKE message by invoking
Hi all.
Again we have some more issues:
Issue #147 - Allowing limited retransmission of one-way IKE messages
Either in 2.1 or in 1.5 we should say something about allowing limited
retransmission of the rare one-way IKE
Hi.
This is an interesting subject, and perhaps could be a good candidate for
discussion at Anaheim. However, from the narrow perspective of a VPN vendor, I
don't think this issue is very complicated:
- In the first IKE_AUTH request the initiator provides *an* identity. This
could be
Hi all.
Wer'e down to single digits with the open issues on IKEv2bis. Here are 5 more.
Issue #168 - Identifier field in the EAP payload
3.16: the text here, ...this field MAY be set to any value implies that the
Identifier field can be constant,
Hi, Syed Ajim.
In future please expand acronyms, because while it's safe to assume that anyone
reading this list knows what an SA is, not all of us are proficient in IPv6
terminology.
Having said that, policies usually have exceptions for protocols, that need to
run in the clear. IKE is an
Hi Rahul.
I don’t have a link, but common sense says that there are four things to
consider when choosing algorithms:
- required strength - for example DES is only 56 bits.
- compliance - certain industries have regulations specifying which algorithms
to use.
- performance - of all the
On Feb 19, 2010, at 6:30 AM, Syed Ajim Hussain wrote:
Hi Yoav Nir All Group Member
Thanks for your quick response. I think, instead of user takes special
care by adding extra Rule to allow un-encrypted ND traffic(unicast) ,
There should be some RFC guidelines, such that IPSEC/IKE
On Feb 22, 2010, at 5:48 PM, Stephen Kent wrote:
At 7:22 PM +0530 2/22/10, Syed Ajim Hussain wrote:
Hi Steve
According to me IPSEC/IKE should have intelligence by by-pass ND Traffic
when SA is not ready state without end-user intervention, and same
should be accepted by other
Hi folks.
5 issues got lost in the system (they were tagged wrong). Hopefully these are
really the last 5.
Issue #132 - Should NO_ADDITIONAL_SAS cover rekeying IKE SAs?
=
In section 1.3 at the end there is text talking about the
Yes, you can sort-of negotiate DH groups, but you don't have the New Group
Mode that we had in section 5.6 or RFC 2409.
So with RFC 4306, you're stuck with only those groups that appear in the IANA
registry, rather than your own pet DH groups.
On Mar 2, 2010, at 10:49 PM, Yaron Sheffer wrote:
Paragraph 5 of section #2:
MUST accept any length that results in proper alignment. It should
be noticed that the ESP [RFC4303] Encrypted Payload requires
Please change noticed to noted.
Other than that, the document looks good enough for implementation.
-Original Message-
From:
Explaining a joke spoils all the fun, but here goes:
It's not like PKI is working out better for user authentication.
And password-in-https-form is also vulnerable to online dictionary attacks.
Now if they were using TLS-EAP
But that, of course, suffers from excessive layering.
To me it’s pretty obviously the former, although the latter is also true.
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Keith
Welter
Sent: Monday, March 08, 2010 6:18 PM
To: ipsec@ietf.org
Subject: [IPsec] IETFLC comments for
On Mar 22, 2010, at 11:18 AM, black_da...@emc.com black_da...@emc.com 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
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
And thank you for taking the time, Rod.
The linktionary has a pretty good definition, though I don't know if it counts
as textbook. Same for Wikipedia
http://www.linktionary.com/f/fault_tolerance.html
http://en.wikipedia.org/wiki/Fault-tolerant_system
Anyway, we need to limit the scope of this
On Mar 23, 2010, at 2:31 PM, Melinda Shore wrote:
On Tue, March 23, 2010 1:20 pm, Yoav Nir wrote:
- For the cluster with just one member doing IKE and IPsec, I propose
hot-standby cluster
- For the cluster with several members doing IKE and IPsec, I propose to
keep load-sharing cluster
I
On Mar 23, 2010, at 6:05 PM, Dan Harkins wrote:
Hi,
hot standby implies a box sitting (hot) twiddling its thumbs doing
little but waiting for another box to fail (standby). It's the VRRP
model.
And that's exactly what I want to describe. Well, not twiddling its thumbs. The
standby is
Hi all
Following Sean's review, Paul has opened 7 issues, which we'd like to close.
I think issues #182, #183, #185 and #186 can be closed immediately.
I think issues #181, #184 and #187 can also be closed, and I have included
below my suggestions. Please take a look and respond if you
Hi all.
As the previous discussion on this topic showed, the WG would like a more
thorough taxonomy in section 2 of the HA/LS draft. Here's what I have come up
with so far. Please send comments to the list.
2. Terminology
Single Gateway is an implementation of IKE and IPsec enforcing a
On Apr 13, 2010, at 1:17 PM, Yaron Sheffer wrote:
Looks good. A few comments down below.
Yaron
On Tue, 2010-04-13 at 11:49 +0300, Yoav Nir wrote:
Fault Tolerance is a condition related to high availability, where
a system maintains service availability, even when a specified
Begin forwarded message:
From: IETF I-D Submission Tool idsubmiss...@ietf.org
Date: April 14, 2010 8:21:14 PM GMT+03:00
To: Yoav Nir y...@checkpoint.com
Subject: New Version Notification for draft-ietf-ipsecme-ipsec-ha-01
A new version of I-D, draft-ietf-ipsecme-ipsec-ha-01.txt has
1 - 100 of 612 matches
Mail list logo
