[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec Architecture -- proposed changes
In message <199710071603.JAA20103@trix.cisco.com>, Cheryl Madson writes:
>
> The tunnel should have it's own TTL. This is consistent with how
> other RFCs on tunnelling specify this. Look at RFCs 2003 and 1853
> for examples.
Just to be clear, we're agreeing, right? both RFC 2003 and 1853 say that you
do *not* copy TTLs from inside to outside, but instead decrement the *inner*
TTL when (encapsulating as fowarding) and when (forwarding after
decapsulating), which incidentally produces useful traceroute info :-)
> Sorry. The auth draft *does* specify it: look at the first paragraph
> of section 3:
>
> 3. Keying Material
>
> HMAC-SHA-1-96 is a secret key algorithm. While no fixed key length is
> specified in [RFC-2104], for use with either ESP or AH a fixed key
> length of 160-bits MUST be supported. A key length of 160-bits was
> chosen based on the recommendations in [RFC-2104] (i.e. key lengths
> less than the authenticator length decrease security strength and
> keys longer than the authenticator length do not significantly
> increase security strength).
>
> The same for MD5. These are *not* variable-key-length transforms.
I understand that *now*, but I didn't until this message.
> There is nothing that suggests that other key sizes are even a MAY,
> apart from the reader recalling the history of the older AH drafts. I
> suppose a wordsmith revision could say "this and only this" or
> something which makes the MUST more of a MUST... ;-).
In this case I'd change "160-bits must be supported" to "160-bits must be
used". "Supported" implies that other key lengths are allowed, which is
where I (and others I discussed this with) all went astray.
I know it's a nitpick, but it *did* mislead several of us who are familiar
with both previous documents *and* with the variable-length keys of the hash
algorithms.
--
Harald
Follow-Ups:
References: