lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <200712181114.46957.paul.moore@hp.com> Date: Tue, 18 Dec 2007 11:14:45 -0500 From: Paul Moore <paul.moore@...com> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org, latten@...ibm.com Subject: Re: IPsec replay sequence number overflow behavior? (RFC4303 section 3.3.3) On Sunday 09 December 2007 10:43:56 pm Herbert Xu wrote: > On Mon, Dec 10, 2007 at 04:16:36AM +0100, Patrick McHardy wrote: > > Won't this break with manually installed SAs (without a keying > > daemon)? > > Well what's being suggested here will already break that anyway :) > > Alternatively we can take the interpretation that it's the KM's > responsibility to set the appropriate hard life time if ESNs are > not in use. > > Either way is fine with me. > > Cheers, Sorry for the delay, I got distracted ... Rereading the thread it's unclear to me which solution was deemed "correct". I'm not a big fan of fiddling/forcing SA lifetimes unless we have no other option; if someone is foolish enough to use manual keying with replay protection and no mechanism to catch rollover then they most likely have larger problems. It's the whole "we'll provide you with the gun, but you have to shoot yourself" argument as applied to SA lifetimes. However, you guys have to deal with this code more often than I do so I'll deffer to your better judgment. -- paul moore linux security @ hp -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists