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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ