Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review

[Mukesh Gupta <[e-mail]>]

Vishwas,

Comments inline...

> 1. In "Rekeying Interval" You are giving examples only for 
> ESP, but it is never stated that we are talking only of 
> ESP(and not AH).

We wanted to keep the section general without making it
specific to ESP or AH.  So when we say "Null encryption with
MD5 authentication", it could be used either with ESP or
with AH.  Do we need to add more text to make it clearer?
Do you any have specific changes in mind ?

> 2.  You state 
> " DES Encryption and HMAC-MD5 Authentication will be more secure
>   because of the additional security provided by DES"
> but the draft draft-ietf-ipsec-esp-ah-algorithms-02.txt
> very clearly states that for AH/ESP we should not use DES
> (for well known reasons) "SHOULD NOT DES-CBC [RFC 2405] (3)".
> I am not sure if we want to mention DES at all.

Well, the draft does not recommend using DES either. We just
wanted to compare some non-null encryption schemes with null
encryption schemes and we chose des, 3des and AES.  The draft
mandates the usage of AES so it is inline with the other
IPsec drafts.

> 3. The section 12, is states the mandatory "encryption 
> and authentication algorithms" but does not state the key 
> size to be used for AES-CBC.

All the IPsec implementations that support AES for IPsec
MUST support 128 bit key size (RFC 3602).  So are we not
ok without mentioning the key sizes in this draft and
just referring to 3602?

> 4. On another front instead of having one draft specifying 
> both the support as well as the algorithm's used, would we 
> want a seperate draft for supported algorithms. This allows 
> us to change the supported algorithms even when the base 
> OSPFv3 for IPSec stays the same e.g. when vulnerabilities 
> are found in the algorithm or when key sizes have to be 
> made bigger. This is how it is done in the IPSec working 
> group too(where AH/ESP algorithm's have been seperated 
> from the supported algorithms).

We had taken this approach in previous revs (04, I guess)
but Security ADs (Russ) wanted to have at least one algorithm
required by this draft just to make sure that the 
implementations were interoperable.  We added AES/SHA1
as mandatory as suggested by Russ.

Regards
Mukesh