-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> From: John Shriver [mailto:jas@shiva.com]
>
>[SNIP]
> 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.
>
Hmmm,
Imagine in the near future (even now?) we have terabit networks. That
is 2^40 bits/second. Protecting 2^32KBytes (=2^45 bits) gives me 32
seconds of coverage before a rekey is needed.
In my opinion, 2^32, while more then adequate for today and probably
:-) adequate for time based rekeying, is a bit small for the
foreseeable future with respect to KByte lifetimes.
>
> Also, are there any restrictions on the value of an Attribute
> Length? 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!
>
RFC 2407 section 4.5 (IPsec DOI) and the IKE draft appendix A seems
to imply that any length is valid.
The code I am working on does not parse anything but 2 and 4 byte
values. I feel that this is adequate for the real world right now. I
know it is not fully compliant with the draft IKE document and the
IPsec and ISAKMP RFCs but that doesn't bother me. Other people may
feel different.
- -Michael Heyman
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1b23
iQA/AwUBN6BRW7XbkJfuXzRQEQJEXQCg1wf5nYD4/R0GVM4oQ9i0aiyGQ68AoIrf
l8z3WTfXA5cAwtter7tWpV/I
=MJTl
-----END PGP SIGNATURE-----