[IPsec] Issue #177

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

[IPsec] Draft IETF-77 minutes for your comments

Please send me any comments on-list or off-, before we submit the minutes into the proceedings. Thanks, Yaron IPsecME minutes: IETF 77 Monday, March 22, 2010 0900-1130 - Morning Session I Co-chairs: Yaron Sheffer, Paul Hoffman Minute takers: Shawn Emery and Richard Graveman (but all error

Re: [IPsec] Issue #177

Looks good. A few comments down below. Yaron On Tue, 2010-04-13 at 11:49 +0300, Yoav Nir wrote: > 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

Re: [IPsec] Issue #177

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

Re: [IPsec] Issue #177

[snip] > >> "Failover" is the event where a one member takes over some load from > >> some other member. In a hot standby cluster, this hapens when a > >> standby memeber becomes active due to a failure of the former active > >> member, or because of an administrator command. In a load sh

Re: [IPsec] Issue #177

On Apr 13, 2010, at 4:42 PM, Yaron Sheffer wrote: > [snip] "Failover" is the event where a one member takes over some load from some other member. In a hot standby cluster, this hapens when a standby memeber becomes active due to a failure of the former active member, or

[IPsec] IPv6 Address resolution on IPsec node

IPv6 nodes use Neighbor Discovery messages for address resolution as defined in RFC 4861. However on an IPv6 node having IPsec implementation, if there is an SPD entry with a selector that covers all IP traffic, Neighbor Discovery messages could potentially be discarded (especially during system r

[IPsec] IKEv2-bis -09 (review of "diffs")

Here's a quick review of the numerous changes between -08 and -09. Let's get these things resolved and move the doc to the IESG. * I'm a bit uneasy with the use of "Notify error message" instead of the simpler (and admittedly a bit vague) "notification". After all, these ar

Re: [IPsec] IKEv2-bis -09 (review of "diffs")

At 6:36 PM +0300 4/13/10, Yaron Sheffer wrote: >Here's a quick review of the numerous changes between -08 and -09. Let's get >these things resolved and move the doc to the IESG. > >I'm a bit uneasy with the use of "Notify error message" instead of the simpler >(and admittedly a bit vague) "notif

Re: [IPsec] CORRECTION: One last review: draft-ietf-ipsecme-ikev2bis

One nit, I missed earlier: Section 6, there's a reference to [RFC4306] but the reference section uses [IKEv2]. spt Paul Hoffman wrote: I have revised the IKEv2bis draft with the IETF Last Call comments. It is available at . The diff

Re: [IPsec] CORRECTION: One last review: draft-ietf-ipsecme-ikev2bis

At 1:38 PM -0400 4/13/10, Sean Turner wrote: >One nit, I missed earlier: > >Section 6, there's a reference to [RFC4306] but the reference section uses >[IKEv2]. Good catch! Fixed in -10. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list

Re: [IPsec] #188: Explicit list of allowed EAP methods]

> At 6:34 PM +0300 4/12/10, Yaron Sheffer wrote: > >there was some off-line discussion on whether the mutual-EAP auth > draft > >should explicitly list the EAP methods that work, securely, with this > >extension. I now tend to say no, and to remove this list (and IANA > >registry) from the next doc