draft-ietf-ospf-ospfv3-auth-04.txt

Vishwas Manral <Vishwas@SINETT.COM> Tue, 29 June 2004 05:41 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 BAA08204 for <ospf-archive@LISTS.IETF.ORG>; Tue, 29 Jun 2004 01:41:44 -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 <3.00DFC9A4@cherry.ease.lsoft.com>; Tue, 29 Jun 2004 1:41:41 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 23597645 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Jun 2004 01:41:39 -0400
Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jun 2004 01:41:39 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45D9C.139D9AD6"
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Thread-Topic: draft-ietf-ospf-ospfv3-auth-04.txt
Thread-Index: AcRdmwZVHkBCqjaeSuGz4FzDGv5/cw==
Message-ID: <BB6D74C75CC76A419B6D6FA7C38317B2249606@sinett-sbs.SiNett.LAN>
Date: Mon, 28 Jun 2004 22:43:59 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vishwas Manral <Vishwas@SINETT.COM>
Subject: draft-ietf-ospf-ospfv3-auth-04.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

Hi,

I just did a quick read of the draft, and had some comments: -

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. "
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.
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".
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)?
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.
6. SA Granularity and Selectors section - I think you are referring to parallel links we may want to state that too.
7. Changing Keys may also be required in case of sequence number rollover.
8. Would we want to refer to the newer drafts for ESP/AH drafts rather then the old RFC's itself?
Thanks,
Vishwas