Re: draft-ietf-ospf-ospfv3-auth-04.txt
Acee Lindem <acee@REDBACK.COM> Tue, 06 July 2004 14:57 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 KAA21380 for <ospf-archive@LISTS.IETF.ORG>; Tue, 6 Jul 2004 10:57:31 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00E08192@cherry.ease.lsoft.com>; Tue, 6 Jul 2004 10:57:29 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 24717739 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 6 Jul 2004 10:57:28 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 6 Jul 2004 10:57:27 -0400
Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 16B08BF9263 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 6 Jul 2004 07:57:25 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12730-09 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 6 Jul 2004 07:57:24 -0700 (PDT)
Received: from aceeinspiron (unknown [172.31.253.16]) by prattle.redback.com (Postfix) with SMTP id BBB9E3B023D for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 6 Jul 2004 07:49:43 -0700 (PDT)
References: <8D260779A766FB4A9C1739A476F84FA401F79A87@daebe009.americas.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Virus-Scanned: by amavisd-new at redback.com
Message-ID: <014b01c46368$743bc800$0202a8c0@aceeinspiron>
Date: Tue, 06 Jul 2004 10:49:33 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit
Even though this has gone through WG last call it may be a good to schedule some time at the San Deigo IETF to discuss recent issues and how they are addressed in the new draft. Comments? ----- Original Message ----- From: <Mukesh.Gupta@NOKIA.COM> To: <OSPF@PEACH.EASE.LSOFT.COM> Sent: Monday, July 05, 2004 3:19 PM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Hi Vishwas, Thanks for the comments. Please see my comments inline.. > 1. I am not sure we should have a statement which says OSPFv3 > is only for IPv6. > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > the distinction between the packets can be easily made by > IP version. " Do you have a replacement statement that you would prefer ? As the IP protocol type value for OSPF and OSPFv3 is same, we have to depend upon the IP version to separate OSPF and OSPFv3 packets. > 2. I think the value of next header field in the ESP header > to indicate OSPFv3 should be specified, though it may seem > a trivial question. Why do you think it should be specified? Whenever ESP is applied to any IP packet, the IP Protocol Type field value from the IP header is copied to the next header field of ESP/AH. There are no exceptions here. > 3. ESP already states that "integrity-only (MUST be supported)" > do we really need to put down "ESP with NULL encryption MUST be > supported in transport mode". An implementation may support ESP/AH that conform to ESP/AH RFCs, but the idea of putting this in this draft was to ensure that the user is allowed to use the specified combinations for securing the OSPF traffic. So that 2 independent secured OSPF implementations have at least one common combination to configure. Do you see any harm in putting this text in the draft ? > 4. I think we may want to state that Authentication service must > always be supported whenever we do encryption. Our primary aim is > to have data integrity right(anyway encryption only service is a > MAY for ESP)? Doesn't the sentence "Providing confidentiality to OSPFv3 in addition to authentication is optional." imply that ? Or would it better to replace "ESP with non-null encryption in transport mode MUST be used for providing the confidentiality to OSPFv3." with "ESP with non-null encryption and non-null authentication in transport mode MUST be used for providing the confidentiality to OSPFv3." > 5. OSPF packets received in clear text or with incorrect AH > Integrity Check Value (ICV) MUST be dropped when authentication is > enabled. > Do we mean only AH/ICV or do we need ESP ICV too? Besides do we > need to state about combined mode algorithms like AES-CCM where > ICV may not checked even when authentication is done. It should be AH/ESP ICV. I will replace "AH" with "AH/ESP" in the next version. The draft for AES-CCM says "it is inappropriate to use this CCM with statically configured keys". We are using staticaly configured keys here. So should we just NOT use AES-CCM ? > 6. SA Granularity and Selectors section - I think you are referring > to parallel links we may want to state that too. No I am not referring to parallel links (if you mean 2 links connecting the same routers). It should be possible to use the same SA for multiple interfaces belonging to even different areas. > 7. Changing Keys may also be required in case of sequence number rollover. How is the user going to know about the sequence number rollover ? so that he/she can initiate the key change. That brings an interesting question. If the user never changes the keys, what happens when the sequence number rollovers ? > 8. Would we want to refer to the newer drafts for ESP/AH drafts rather > then the old RFC's itself? That's a good idea but the problem is that if we put the new drafts as normative references, this draft will not be published before those drafts. Do we want to block the draft waiting for those drafts ? The draft was reviewed by the IESG on June 26th and the comments can be seen at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9745&rfc_flag=0 We will be working on addressing all the comments now and will publish an updated version of the draft probably after the IETF 60th. regards Mukesh
- draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Mukesh.Gupta
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Abhay Roy
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Acee Lindem
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Erblichs
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Acee Lindem
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Mukesh.Gupta
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Erblichs
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Mukesh.Gupta
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Erblichs
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Suresh Melam
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Suresh Melam
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Mukesh.Gupta
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Erblichs
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Mukesh.Gupta
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Abhay Roy
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Abhay Roy
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Suresh Melam
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Suresh Melam
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Regarding route calculation over Vlink in case of… prasanna s
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral