netdev - Re: IPsec replay sequence number overflow behavior? (RFC4303 section 3.3.3)

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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