Re: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt

Acee Lindem <acee.lindem@ericsson.com> Tue, 11 June 2013 21:29 UTC

Return-Path: <prvs=687437bc8c=acee.lindem@ericsson.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 8947821F9A17 for <ospf@ietfa.amsl.com>; Tue, 11 Jun 2013 14:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level:
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599]
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 r4D5c2XMe4gH for <ospf@ietfa.amsl.com>; Tue, 11 Jun 2013 14:29:30 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id F114C21F8904 for <ospf@ietf.org>; Tue, 11 Jun 2013 14:29:29 -0700 (PDT)
X-AuditID: c6180641-b7f0e6d0000015f1-1c-51b796b98cde
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 32.23.05617.9B697B15; Tue, 11 Jun 2013 23:29:29 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 17:29:28 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: Anton Smirnov <asmirnov@cisco.com>
Thread-Topic: [OSPF] New Version Notification for draft-acee-ospf-rfc6506bis-01.txt
Thread-Index: AQHOZpfDRu1KsPZQpUSv1C6bqb0hGpkxN/iAgAATZoA=
Date: Tue, 11 Jun 2013 21:29:27 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47164224@eusaamb101.ericsson.se>
References: <94A203EA12AECE4BA92D42DBFFE0AE4716381E@eusaamb101.ericsson.se> <51B78671.6020405@cisco.com>
In-Reply-To: <51B78671.6020405@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6001D101529AB1489C7FF0DC3411D611@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXSPn+7OadsDDd5NULRo2cZq0XLvHrsD k8eU3xtZPZYs+ckUwBTFbZOUWFIWnJmep2+XwJ2x+Pst5oLX2hW9UxezNzC+V+pi5OSQEDCR eP/xKTuELSZx4d56ti5GLg4hgaOMEtc27WKCcJYzSvzbeZ0VpIpNQEfi+aN/zCC2iICaxOa7 n8DizALKEo+7VrOB2MICIRLnWk4ydjFyANWESpzZVAthWkk8/l0DUsEioCqxv6WRCcTmFfCW aLm9CqxTSCBL4syytSwgNqeApsTj3dvBbEag276fWsMEsUlc4taT+UwQNwtILNlznhnCFpV4 +fgfK4StLLHkyX4WiHodiQW7P7FB2NYSh59eY4awtSWWLXzNDHGDoMTJmU9YJjCKz0KyYhaS 9llI2mchaZ+FpH0BI+sqRo7S4tSy3HQjw02MwJg6JsHmuINxwSfLQ4zSHCxK4rw6vIsDhQTS E0tSs1NTC1KL4otKc1KLDzEycXCCCC6pBkZhZ4mn58s/bVXd7MDx4qrfFP4jlpqf91kw8K5h /L+mRbTLyS7hxqHeyHlHXDyy3v2u/F/9jHfhh0uyjR8/lnwuMLlbcLg9vON6XAbr1dtMTjq6 KV/n+XnvFNnzXs/Bo7z0Q/antssSx694RS6RnmE/dS//ufw+r8g6l9xuHd/fgmG3z8xS51Ri Kc5INNRiLipOBABcJY7JfAIAAA==
Cc: "ospf@ietf.org" <ospf@ietf.org>
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 21:29:36 -0000

Hi Anton, 

I am glad you asked. 

On Jun 11, 2013, at 4:20 PM, Anton Smirnov wrote:

>   Hi Acee,
>   I also support bis revision - couple of points not covered in the original document may negatively impact interoperability between different implementations.
> 
>   Regarding sequence numbers - if I understand wording in 'bis' revision correctly, sender is using single incrementing sequence number counter independent of packet type and receiver is using one sequence number per packet type, correct? I am asking because RFC 4222 recommends to sort packets into two classes (i.e. not as many classes as there are packet types), so mentioning it may be somewhat confusing.

Excerpt from section 1.2:

   4.  Section 4.1 and 4.6 indicate 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.

Thanks,
Acee


> 
> Anton
> 
> 
> On 06/11/2013 01:35 PM, Acee Lindem wrote:
>> 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
>>