Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review
Mukesh Gupta <Mukesh.K.Gupta@NOKIA.COM> Mon, 10 January 2005 06:54 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 BAA09185 for <ospf-archive@LISTS.IETF.ORG>; Mon, 10 Jan 2005 01:54:45 -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 <7.00F3ED0A@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 1:54:44 -0500
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52708027 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 01:54:39 -0500
Received: from 131.228.20.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 01:54:38 -0500
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0A6sfs06728 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 10 Jan 2005 08:54:41 +0200 (EET)
X-Scanned: Mon, 10 Jan 2005 09:00:29 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE
Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0A70TwX022128 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 10 Jan 2005 09:00:29 +0200
Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 005741r0; Mon, 10 Jan 2005 09:00:27 EET
Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0A6dRU21652 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 10 Jan 2005 08:39:27 +0200 (EET)
Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jan 2005 00:39:27 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Topic: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review
thread-index: AcT2gXRAoVKYcDZUSEKeUxrHKSX+CQASPhlAAANkP2A=
X-OriginalArrivalTime: 10 Jan 2005 06:39:27.0057 (UTC) FILETIME=[2154EC10:01C4F6DF]
Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79BB2@daebe009.americas.nokia.com>
Date: Mon, 10 Jan 2005 00:39:26 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mukesh Gupta <Mukesh.K.Gupta@NOKIA.COM>
Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable
Acee, Vishwas is right. I don't think we can mandate a specific algorithm in the draft and not have to update it in future. What about we say something like.. ==== This specification does not mandate specific encryption and authentication algorithms because the recommendation for encryption and authentication algorithms changes with time as the algorithms are broken and more secure algorithms are invented. In order to interoperate with each other, the implementations have to have at least one common algorithm that the user can choose to use for OSPFv3 security. The implementation MUST allow the user to choose all the encryption and authentication algorithm that are MUST in IPsec mandatory to implement algorithms. The implementation SHOULD allow the user to choose all the encryption and authentication algorithm that are SHOULD in IPsec mandatory to implement algorithms. ==== Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Vishwas Manral > Sent: Sunday, January 09, 2005 8:17 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review > > > Hi Acee, > > I agree totally with your views. > > However examples where algorithms "support has been changed" are: - > > " > Old Old New > Req. RFC(s) Requirement Algorithm (notes) > --- ------ ----------- --------- > MUST 2406 SHOULD NOT DES-CBC [RFC 2405] (1) > MUST 2402 2406 MAY HMAC-MD5-96 [RFC 2403] > MUST 2402 2406 MUST HMAC-SHA1-96 [RFC 2404] > " > > Thanks, > Vishwas > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > Behalf Of Acee > Lindem > Sent: Monday, January 10, 2005 12:49 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG review > > Mukesh, Vishwas, > > Here is my take. The document should be written in such > a way that it doesn't need to be updated every time the > IPSec algorithm > de jour changes. > > However, I also think the document should specify algorithms with the > caveat that they may be updated. IMHO, once an > authentication/encrpytion > algorithm is deployed, it is unlikely to be withdrawn from support. > Hence, > if someone develops a stronger algorithm with lower computational > requirements > and it becomes the recommended alogorithm, then implementations will > need > to support it in ADDITION to what they are currently supporting. > > Is this possible? Any other opinions? > > Thanks, > Acee > > > Mukesh Gupta wrote: > > >Vishwas, > > > >Comments inline.. > > > > > > > >>VM> I do not think you talk about encryption at all when you > >>talk about > >>AH. If you check the documents I have pointed to carefully, > >>you will see > >>NULL Encryption is a special case of encryption when > encryption is not > >>used. > >> > >> > > > >Would it make more sense if we change the text "NULL encryption" > >to "NULL encryption (for ESP) or no encryption (for AH)" ? > > > > > > > >>Suresh> We are not a fan of DES either for obvious reasons. > But as we > >>wanted to start with the weakest algorithm, we started with DES. We > >>wouldn't have to mention DES at all, had IETF/NIST > >>suggested DES as "MUST NOT". > >>VM> I still don't see a reason why we should talk about DES at all. > >> > >> > > > >I still don't understand why we can't use DES as an example of a weak > >encryption algorithm. > > > >I would like to hear others' opnion about this ? Acee? > > > > > > > >>Suresh> Mukesh and I discussed this again and we agree that > >>referring to > >>the IPsec algorithm draft should be the better way to go. > >>VM> Also not for the authentication you have given the key > length and > >>for Encryption you have not(so there is anyway a case of > >>inconsistency). > >> > >> > > > >Yeah but this will be fixed too if we didn't mention any algorithm > >and just pointed to the madatory to implement algos. Right ? > > > > > > > >>Suresh> What about the following: > >>"Replaying these type of packets can make the router spend some > >>resources. Also when the OSPF adjacency is not FULL, replaying > >>database description packets can cause disruption in forming the > >>adjacency." > >>VM> Its not just forming the adjacency Suresh but the link becoming > >>unusable for transit traffic (DoS). In my view you should > >>just refer to > >>the vulnerabilities draft and probably put a sentence like > the above. > >> > >> > > > >We do refer to the vulnerabilities draft after the brief discussion > >of the replay vulnerabilities.. So are you ok with putting the > >text proposed above and then referring to the vulerabilities draft ? > > > > > > > >>VM> You are right. However I think the aim of the draft is > to specify > >>how we should use IPSec (guidelines) as well as specify the default > >>behavior(Maybe for all optional parameters we should specify this). > >> > >> > > > >You are right. The aim of this draft is to specify how OSPFv3 should > >use IPsec but I still fail to understand why we need to > specify things > >that are not related or exposed to OSPF :( > > > >What exactly do you want to specify about ESN? Do we want to say > >that there is no impact of the usage of ESN by the underlying IPsec > >implementation on OSPFv3 security because sequence numbers > are ignored > >while manual keys are used ? > > > >Regards > >Mukesh > > > > > > >
- draft-ietf-ospf-ospfv3-auth-06.txt Ready for IESG… Mukesh Gupta
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Bill Fenner
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Mukesh Gupta
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Mukesh Gupta
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Acee Lindem
- WG Last Call on draft-ietf-ospf-ospfv3-auth-06.txt Acee Lindem
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Bill Fenner
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Suresh Melam
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Mukesh Gupta
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Acee Lindem
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Mukesh Gupta
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Mukesh Gupta
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Erblichs
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Mukesh Gupta
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Acee Lindem
- Re: draft-ietf-ospf-ospfv3-auth-06.txt Ready for … Mukesh Gupta