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

Vishwas Manral <Vishwas@SINETT.COM> Thu, 30 December 2004 05:46 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27819 for <ospf-archive@LISTS.IETF.ORG>; Thu, 30 Dec 2004 00:46:50 -0500 (EST)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F29CDB@cherry.ease.lsoft.com>; Thu, 30 Dec 2004 0:46:48 -0500
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 51222196 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 30 Dec 2004 00:46:46 -0500
Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 30 Dec 2004 00:46:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4EE34.2C9BF086"
Thread-Topic: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review
thread-index: AcTuNCyZyn9vDJkgR2uoT7vU2kWhqw==
Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B207EA8B@sinett-sbs.SiNett.LAN>
Date: Wed, 29 Dec 2004 21:55:32 -0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vishwas Manral <Vishwas@SINETT.COM>
Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi,
 
Some more minor comments: -
 
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).
2.  You state 
" DES Encryption and HMAC-MD5 Authentication will be more secure
   because of the additional security provided by DES"
but the draft http://www.ietf.org/internet-drafts/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.
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.
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).
 
Thanks,
Vishwas
 

--------------------------------------------------------------------------------
From: Mailing List on behalf of Vishwas Manral
Sent: Wed 12/29/2004 9:09 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review

Hi Mukesh and Suresh,
I went through the draft and think it is in pretty good shape now and seems most of my comments are taken care of. However :-
1. In the draft you state that there are know known problems of replaying DB packets. Replaying a DB packet can result in the entrie database being exchanged again which is a CPU heavy process.
2. Similar issues with LS request packets.
3.  Though we have addressed the case of specifying some default/supported values, I think we do not do that for all optional parameters. e.g. ESN etc.
4. We can have multiple SA's between two routers. When DSCP is supported should the same SA be used or should multiple SA's be used?
Thanks,
Vishwas
________________________________
From: Mailing List on behalf of Mukesh Gupta
Sent: Wed 12/29/2004 1:21 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review
 
Alex/Bill,
06 version of the OSPFv3 Security draft addresses the
following comments/issues:
From IESG:
- Discuss about how much protection OSPF has for replay
  attacks without the security enabled
- Add references to 3602 and 2404
- Analyze and recommend values of rekeying interval and KeyRolloverInterval
- Spell out in the security considerations that one router can impersonate another
- Larger routing security not considered here (refer to rpsec)
  i.e., "What's left to worry about after you deploy this?"
- Refer to rpsec drafts
From authors:
- MUST requirement for hex format keys.  This will significantly
  increase the entropy of the keys.
We have addressed all the comments from IESG and we think that
this version is ready to be reviewed by IESG again.
Regards
Mukesh & Suresh