[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
weakness in IKE/DOI specs
John Shriver writes:
> I think it is perfectly appropriate to limit these to 32 bits, with
> the range being 0 to (2^32)-1. I don't think there is any sensible
> justification to allow 64 bit values, that's just too long a
> lifetime.
I think we should allow 64 bit values also. In 30 years (2.8.2029
23:48 GMT) those sending data using 10 gigabit radio link to mars
using ipsec are quite sure to curse us we, because we force them to
wait for 33 minutes every 7 minutes (the distance between earth and
Mars is 1.38 AU).
Of course they will create those SAs beforehand and create 20 of them
at once, but still I think they might want to use bigger lifetimes...
Of course we can define that support for 16 and 32 bit lifetimes is
mandatory, and implemenations may support 64 bit lifetimes for
kilobytes.
> Also, are there any restrictions on the value of an Attribute Length?
Currently no.
> Is 1 a legal? Or must you use the short form when Attribute Length
> would be less than 3? Also, is an attribute length of 3 legal for a
> lifetime? I could want a lifetime of 128 Kbytes, I could choose to
> code that as "00 02 00 03 01 00 00", rather than the far more sensible
> "00 02 00 04 00 01 00 00". Can ANYONE parse that 3 byte lifetime? I
> doubt it! Should we allow it? I don't think so!
We currently parse anything that is shorter than 4 bytes (from 0 bytes
up to 4 bytes).
> This issue partly comes up because we've coded these as Unsigned32 in
> the MIB, but there's nothing in the protocol definitions that assures
> us that Unsigned32 is sufficient.
I think we should not be limited to Unsigned32 there.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
Follow-Ups: