On Tue, 30 Aug 2022 at 22:31, D. Hugh Redelmeier <h...@mimosa.com> wrote: > > All numbers in conf files are whole numbers (that's all the parser > will accept).
Let's say all byte counts. (I've a long standing wish list item for accepting things like timeout=0.5s which would mean a separate parser) > > How large should we allow them to be? >= 64-bit. Even my ancient 1Gibit hub could overflow a 32-bit byte counter in >under 1 minute.. > Slightly easier question; What are the largest numbers used now? I > cannot answer that because I can't see everyones conf files. > > ===> People: could you tell me the large numbers appearing in your > conf files? It would also be nice to know which parameters are being > set to these large numbers. > > I found all the large decimal numbers in pluto conf files in our test > suite. I defined "large" as five or more digits. > > grep -n '\<[0-9][0-9][0-9][0-9][0-9][0-9]*\>' > > All but one were milliseconds for retransmit-interval, all 10-25 > seconds -- 5 digit numbers. > > The one exception: > pluto/pfkeyv2-replay-window-freebsd/ipsec.conf:37: > replay-window=4294967294 # UINT32_MAX - 1 > This seems pretty arbitrary. > > How large are the numbers you use (or imagine using)? > > Numerical parameters are currently stored as uintmax_t. I've already > posted why this type should not be used. This sample suggests that > 32-bit numbers should be enough. So "unsigned long" should be fine. (C > guarantees the unsigned long is 32 bits or more.) While uintmax_t has limitations (a C committee snafu means it will never be bigger than 64-bit) I think it is fit for purpose: - it's "generic" - it's >= 64-bits for the systems we care about - it's fast on the systems we care about (our bottleneck is crypto which uses bignum) - it's easy to print using 'j' - it's a marker for the poor soul (we'll all be long gone) who gets to deal with 128-bit ints; I suspect it will use bignums I think we're better off limiting uint64_t to code that must use a 64-bit value (for instance, in payloads). > If 32 bits is considered too limiting, 64 should be used. The > portable way of specifying this is uint64_t. > > (I don't really like C unsigned types because overflow is well-defined > to be a surprisinig result. But that's C for you. Using unsigned > puts a burden on the program to detect overflow. There is evidence > that we're not perfect at that.) > > Complete collection: > > pluto/ikev2-x509-26-criticalflag/east.conf:28: retransmit-interval=15000 > pluto/ikev2-x509-26-criticalflag/west.conf:28: retransmit-interval=15000 > pluto/ikev2-labeled-ipsec-06-reauth-ike-acquire/west.conf:15: > retransmit-interval=10000 # 10s > pluto/ikev2-x509-27-criticalflag-clientAuth/east.conf:28: > retransmit-interval=15000 > pluto/ikev2-x509-27-criticalflag-clientAuth/west.conf:28: > retransmit-interval=15000 > pluto/ikev2-labeled-ipsec-06-rekey-ike-acquire/west.conf:15: > retransmit-interval=10000 # 10s > pluto/pfkeyv2-replay-window-freebsd/ipsec.conf:37: > replay-window=4294967294 # UINT32_MAX - 1 > pluto/xauth-pluto-20-pam-timeout/road.conf:17: retransmit-interval=25000 > pluto/ikev2-60-pam/road.conf:14: retransmit-interval=25000 > pluto/ikev2-60-pam/road.conf:18: retransmit-interval=25000 > pluto/ikev2-frag-03-retrans/east.conf:20: retransmit-interval=15000 > pluto/ikev2-frag-03-retrans/west.conf:21: retransmit-interval=15000 > pluto/ikev2-child-rekey-08-deadlock/ipsec.conf:32: > retransmit-interval=14000 > pluto/interop-ikev1-strongswan-x509-aggr-13-san-dn-match-responder/west.conf:28: > retransmit-interval=20000 #strongswan may take time to fetch the crl > pluto/interop-ikev2-strongswan-39-fragmentation-aes-gcm/west.conf:23: > retransmit-interval=15000 > pluto/ikev2-x509-02-eku/east.conf:28: retransmit-interval=15000 > pluto/ikev2-x509-02-eku/west.conf:28: retransmit-interval=15000 > pluto/nss-cert-ocsp-03-bogus-uri-strict-ikev1/east.conf:33: > retransmit-interval=15000 # slow retransmits > pluto/nss-cert-ocsp-03-bogus-uri-strict-ikev1/west.conf:28: > retransmit-interval=15000 # slow retransmits > w > _______________________________________________ > Swan-dev mailing list > Swan-dev@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev