Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt
"Marek Karasek (mkarasek)" <mkarasek@cisco.com> Tue, 11 June 2013 13:26 UTC
Return-Path: <mkarasek@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631D021F8EBE for <ospf@ietfa.amsl.com>; Tue, 11 Jun 2013 06:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co0-ijnRXNzT for <ospf@ietfa.amsl.com>; Tue, 11 Jun 2013 06:26:14 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 55F8A21F8EEA for <ospf@ietf.org>; Tue, 11 Jun 2013 06:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5658; q=dns/txt; s=iport; t=1370957174; x=1372166774; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3wWkbjOgQt/RW9AvmA5rSi+C9G8L5OnYexI9N5HsUWk=; b=YcgKZ6ikEDja0tXcJIG7OASiZRMKj5MjRssAl2HIcr17dCGi2vLYjyjh DFZGqbnzBJai23oQDSpgrFgR4Nnzpe9cAU145um9txUocUjDCZJ4MR9BJ FJ3UmflOd+kKw2aS2TlqXuB2UWJ6VdycdCXmzPdhQVz6qYoJy7DR2eLoe s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAAolt1GtJXHA/2dsb2JhbABZgwkwQwa+S30WdIIjAQEBBAEBATc0CQ4EAgEIEQQBAQEKCwkJBycLFAkIAgQBEggBC4d5BwW6PI8BOAYEgnVhA5NuhHuQGYMPgic
X-IronPort-AV: E=Sophos;i="4.87,845,1363132800"; d="scan'208";a="221399844"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 11 Jun 2013 13:26:01 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5BDQ1Y4015552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 13:26:01 GMT
Received: from xmb-rcd-x11.cisco.com ([169.254.1.81]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 08:26:01 -0500
From: "Marek Karasek (mkarasek)" <mkarasek@cisco.com>
To: Acee Lindem <acee.lindem@ericsson.com>, "Michael Barnes (mjbarnes)" <mjbarnes@cisco.com>, "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt
Thread-Index: AQHOZpfPs+Y9akuG1Uyjl0ojg1ZQuZkwfPcw
Date: Tue, 11 Jun 2013 13:26:00 +0000
Message-ID: <E7523A682FBA7E498E8FAF27332266AA0F5F11C2@xmb-rcd-x11.cisco.com>
References: <51B0ED10.1090007@cisco.com> <94A203EA12AECE4BA92D42DBFFE0AE4716381E@eusaamb101.ericsson.se>
In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4716381E@eusaamb101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.25.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2013 13:26:19 -0000
Hi Acee, I support bis version as well. I have one more suggestion though for this paragraph: In support of uninterrupted deployment, an OSPFv3 router implementing this specification MAY implement a transition mode where it includes the Authentication Trailer in transmitted packets but does not verify this information in received packets. This is provided as a transition aid for networks in the process of migrating to the authentication mechanism described in this specification. Can it be explicitly added how to work with checksums in the transition (or deployment) mode? I suggest adding: - For OSPFv3 packets to be transmitted in deployment mode, the OSPFv3 header checksum and LLS data block checksum is computed and written in the packets. - For packets received in deployment mode which include an OSPFv3 Authentication Trailer, OSPFv3 header checksum verification MUST be omitted. - For packets received in deployment mode which do not include an OSPFv3 Authentication Trailer, OSPFv3 header checksum and LLS data block checksum are verified. Thanks marek -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Tuesday, June 11, 2013 1:35 PM To: Michael Barnes (mjbarnes); ospf@ietf.org Subject: Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt Thank Michael - Does anyone else support this work? I think it will help ensure compatibility between implementations. I would have expected at least those who submitted the corrected errata to support the draft. Thanks, Acee On 6/6/13 1:12 PM, "Michael Barnes" <mjbarnes@cisco.com> wrote: >I agree these are good changes. Acee, please move forward with this draft. > >Thanks, >Michael > >On 05/09/2013 11:03 AM, Acee Lindem wrote: >> There have been a couple errata filed on RFC 6505 (authors copied). >>As a service to the OSPF community and in an effort to ensure >>interoperable OSPFv3 authentication trailer implementations, I have >>produced a BIS draft. The changes are listed in section 1.2: >> >> 1.2. Summary of Changes from RFC 6506 >> >> This document includes the following changes from RFC 6506 >>[RFC6506]: >> >> 1. Sections 2.2 and 4.2 explicitly state the Link-Local Signalling >> (LLS) block checksum calculation is omitted when an OSPFv3 >> authentication is used. The LLS block is included in the >> authentication digest calculation and computation of a checksum >> is unneccessary. Clarification of this issue was raised in an >> errata. >> >> 2. Section 4.5 includes a correction to the key preparation to use >> the protocol specific key (Ks) rather than the key (K) as the >> initial key (Ko). This problem was also raised in an errata. >> >> 3. Section 4.5 also includes a discussion of the choice of key >> length to be the hash length (L) rather than the block size (B). >> The discussion of this choice was included to clarify an issue >> raised in a rejected errata. >> >> 4. Section 4.1 indicates that sequence number checking is dependent >> on OSPFv3 packet type in order to account for packet >> prioritization as specified in [RFC4222]. This was an omission >> from RFC 6506. >> >> >> I would like to quickly move this to an OSPF WG document and begin >>the review process. I'm now soliciting feedback on OSPF WG adoption. >> >> Thanks, >> Acee >> >> >> On May 9, 2013, at 1:43 PM, <internet-drafts@ietf.org> >> wrote: >> >>> >>> A new version of I-D, draft-acee-ospf-rfc6506bis-01.txt has been >>> successfully submitted by Manav Bhatia and posted to the IETF >>> repository. >>> >>> Filename: draft-acee-ospf-rfc6506bis >>> Revision: 01 >>> Title: Supporting Authentication Trailer for OSPFv3 >>> Creation date: 2013-05-09 >>> Group: Individual Submission >>> Number of pages: 25 >>> URL: >>>http://www.ietf.org/internet-drafts/draft-acee-ospf-rfc6506bis-01.txt >>> Status: >>>http://datatracker.ietf.org/doc/draft-acee-ospf-rfc6506bis >>> Htmlized: >>>http://tools.ietf.org/html/draft-acee-ospf-rfc6506bis-01 >>> Diff: >>>http://www.ietf.org/rfcdiff?url2=draft-acee-ospf-rfc6506bis-01 >>> >>> Abstract: >>> Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism >>> for authenticating protocol packets. This behavior is different >>>from >>> authentication mechanisms present in other routing protocols >>>(OSPFv2, >>> Intermediate System to Intermediate System (IS-IS), RIP, and Routing >>> Information Protocol Next Generation (RIPng)). In some >>>environments, >>> it has been found that IPsec is difficult to configure and maintain >>> and thus cannot be used. This document defines an alternative >>> mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 >>>does >>> not only depend upon IPsec for authentication. This document >>> obsoletes RFC 6506. >>> >>> >>> >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
- Re: [OSPF] New Version Notification for draft-ace… Acee Lindem
- Re: [OSPF] New Version Notification for draft-ace… Michael Barnes
- Re: [OSPF] New Version Notification for draft-ace… Acee Lindem
- Re: [OSPF] New Version Notification for draft-ace… Marek Karasek (mkarasek)
- Re: [OSPF] New Version Notification for draft-ace… Acee Lindem
- Re: [OSPF] New Version Notification for draft-ace… Anton Smirnov
- Re: [OSPF] New Version Notification for draft-ace… Acee Lindem
- Re: [OSPF] New Version Notification for draft-ace… Acee Lindem
- Re: [OSPF] New Version Notification for draft-ace… Marek Karasek (mkarasek)
- Re: [OSPF] New Version Notification for draft-ace… Acee Lindem