Re: [IPsec] IPsec Digest, Vol 141, Issue 16

> On 14 Jan 2016, at 11:00 PM, ipsec-requ...@ietf.org wrote: > > Send IPsec mailing list submissions to > ipsec@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ipsec > or, via email, send a message with subject or body

Re: [IPsec] WG Interest in TCP Encapsulation

>>> The real question is whether the networks that don't transport ESP or >>> ESPinUDP block those packets on purpose or by accident. I don't think >>> we really have any good numbers on this. >>> If we are doing this as a "workaround" to break through the administrative >>> boundaries, than we

Re: [IPsec] IPsec Digest, Vol 137, Issue 6

> On Sep 16, 2015, at 6:20 AM, ipsec-requ...@ietf.org wrote: > > Message: 4 > Date: Wed, 16 Sep 2015 05:01:14 +0300 > From: Tero Kivinen > > To: Tommy Pauly > > Cc: IPsecME WG

Re: [IPsec] IPsec Digest, Vol 125, Issue 9

imho, this would be useful for bring-up work i.e. for both developers and deployers. However, as folks already pointed out, there are significant security tradeoffs (and mitigations) that SHOULD/MUST to be explicated (i.e.more verbiage). Points to consider: 1) allowing unauthenticated IKE-SAs

Re: [IPsec] IPsec Digest, Vol 125, Issue 9

Hi Valery, On Sep 9, 2014, at 2:08 PM, Valery Smyslov sva...@gmail.com wrote: Hi Les, imho, this would be useful for bring-up work i.e. for both developers and deployers. However, as folks already pointed out, there are significant security tradeoffs (and mitigations) that SHOULD/MUST

Re: [IPsec] IPsec Digest, Vol 125, Issue 9

Hi Paul, On Sep 9, 2014, at 3:40 PM, Paul p...@nohats.ca wrote: On Sep 9, 2014, at 5:40, Les Leposo lep...@gmail.com wrote: imho, this would be useful for bring-up work i.e. for both developers and deployers. However, as folks already pointed out, there are significant security

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

On Aug 18, 2014, at 8:52 PM, Paul Wouters p...@nohats.ca wrote: On Mon, 18 Aug 2014, Les Leposo wrote: If course if the device is not really sleeping, i.e. you just blank the screen, and are still able to receive and send packets, then there is no point of tearing down the IKE SA. could

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

On Aug 19, 2014, at 1:39 PM, Tero Kivinen kivi...@iki.fi wrote: Les Leposo writes: have you overlooked the issue of nat mappings? Nope. ipsec nat keepalives are very useful for keeping nat mappings alive, and in a world full of all sorts of nat devices (some behaving reliably

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

On Aug 19, 2014, at 5:32 PM, Yoav Nir ynir.i...@gmail.com wrote: On Aug 18, 2014, at 8:23 PM, Les Leposo lep...@gmail.com wrote: On Aug 18, 2014, at 5:44 PM, Tero Kivinen kivi...@iki.fi wrote: Les Leposo writes: The iphone (which is only rumored to do IKEv2 with iOS8 likely

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

On Aug 19, 2014, at 5:43 PM, Paul Wouters p...@nohats.ca wrote: On Tue, 19 Aug 2014, Les Leposo wrote: the entire ipsec system is brought down/up, eg racoon is completely killed and restarted all the time. Sounds like a totally reproducible crash/signal. I'm sure if you file a radar

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

On Aug 19, 2014, at 6:11 PM, Yoav Nir ynir.i...@gmail.com wrote: On Aug 19, 2014, at 5:48 PM, Les Leposo lep...@gmail.com wrote: Now, today's client devices need to be energy efficient - so the device sleeps/hibernates to save battery. Sleeping past the nat keepalives is bound

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

On Aug 19, 2014, at 5:43 PM, Paul Wouters p...@nohats.ca wrote: On Tue, 19 Aug 2014, Les Leposo wrote: the entire ipsec system is brought down/up, eg racoon is completely killed and restarted all the time. Sounds like a totally reproducible crash/signal. I'm sure if you file a radar

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

On Aug 18, 2014, at 5:44 PM, Tero Kivinen kivi...@iki.fi wrote: Les Leposo writes: The iphone (which is only rumored to do IKEv2 with iOS8 likely to be released in September this year) currently has a terrible record of continuously re-establishing connections. Like whenever the screen

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

On Aug 18, 2014, at 7:33 PM, Paul Wouters p...@nohats.ca wrote: On Mon, 18 Aug 2014, Tero Kivinen wrote: If dead peer detection is implemented properly, as is described in the rfc5996, the device can safely go to sleep if there is no traffic going between the client and server, and when it

Re: [IPsec] IPsec Digest, Vol 123, Issue 21

Hi some points of discussion below. On Jul 31, 2014, at 7:19 PM, ipsec-requ...@ietf.org wrote: Send IPsec mailing list submissions to ipsec@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ipsec or, via email, send a