Re: [OSPF] One more RFC 6506BIS Clarification

Acee Lindem <acee.lindem@ericsson.com> Tue, 08 October 2013 13:00 UTC

Return-Path: <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 5901C11E81B7 for <ospf@ietfa.amsl.com>; Tue, 8 Oct 2013 06:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 T9mGNE3Yu3Wx for <ospf@ietfa.amsl.com>; Tue, 8 Oct 2013 06:00:43 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 91FCB11E81A0 for <ospf@ietf.org>; Tue, 8 Oct 2013 06:00:38 -0700 (PDT)
X-AuditID: c618062d-b7fda8e0000024c6-3f-525401efd55d
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 60.67.09414.FE104525; Tue, 8 Oct 2013 15:00:31 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Tue, 8 Oct 2013 09:00:31 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: Anton Smirnov <asmirnov@cisco.com>
Thread-Topic: [OSPF] One more RFC 6506BIS Clarification
Thread-Index: AQHOxBwI+qIhIuwnX0iuwjrsMgHf1pnrB48A
Date: Tue, 8 Oct 2013 13:00:30 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470307E749@eusaamb101.ericsson.se>
References: <39397A08-58F0-474D-AA3F-17390CB01FEF@lindem.com> <534FD0D7D9E99740A077CE1A38EB79C30328E0A3@xmb-aln-x03.cisco.com> <B090235E-D061-47DA-9BF4-7B76A5853504@lindem.com> <5253F098.6070101@cisco.com>
In-Reply-To: <5253F098.6070101@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: <74CB25CC733C1241A5710BA16049B478@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPoO57xpAggyfbLS2m3ZrOZtGyjdWi 5d49dgdmjym/N7J6LFnyk8njw6ILrAHMUVw2Kak5mWWpRfp2CVwZVzv/sRTMV6343RbewLhd touRk0NCwETiYdN2dghbTOLCvfVsXYxcHEICRxklFv9YxgrhLGOUeP1pLxtIFZuAjsTzR/+Y QWwRATWJzXc/sYLYzAI2EjM/9oHFhQXMJE5/amWDqDGXWLL2MVS9kUTz/V1gNouAisT+K9dZ QGxeAV+Jows+QC27zChxpesSE0iCU0BT4uO0rWALGIHO+35qDRPEMnGJW0/mM0GcLSCxZM95 ZghbVOLl43+sELayxJIn+1kg6nUkFuz+xAZhW0v8m9cEdbS2xLKFr5khjhCUODnzCcsERvFZ SFbMQtI+C0n7LCTts5C0L2BkXcXIUVqcWpabbmSwiREYacck2HR3MO55aXmIUZqDRUmc98tb 5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjKsU7G9tiNe0Ut7JG+r6j/WjrlTNeZnwtRG8 FaqfKhfcuzH1yTyFtoxNWwSCHlxmbP7fGxytb8V53Fak3EMr6lKw+3b+wu0mPuXPs2dHzjDN +Fr+6blT6vOiMEamH43m3EUSfQYt68pmLSgMKtaeEb77fQK7nof0O835087Hf84P9p7NLvBC iaU4I9FQi7moOBEAMdOJYoICAAA=
Cc: OSPF List <ospf@ietf.org>
Subject: Re: [OSPF] One more RFC 6506BIS Clarification
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, 08 Oct 2013 13:00:51 -0000

Hi Anton,

We are updating the security in OSPFv2 as well with draft-ietf-ospf-security-extension-manual-keying-05.txt. This a different mechanism but it is where we ultimately want to get. 

Thanks,
Acee 
On Oct 8, 2013, at 7:46 AM, Anton Smirnov wrote:

>   Hi Acee,
>   RFC 6506 inherited this property from RFC 5709 which has this text word for word:
> 
>>                        In the event that the last key associated
>>    with an interface expires, it is unacceptable to revert to an
>>    unauthenticated condition, and not advisable to disrupt routing.
>>    Therefore, the router should send a "last Authentication Key
>>    expiration" notification to the network manager and treat the key as
>>    having an infinite lifetime until the lifetime is extended, the key
>>    is deleted by network management, or a new key is configured.
> 
> To me this property looks wrong from security point of view and in general I would agree to have it removed. OTOH difference between v2 and v3 specs is highly undesirable, so if RFC 6506 is changed so that this property is dropped (or made optional) then at the same time we should evaluate how the same change can be pushed into RFC 5709.
> 
> Anton
> 
> 
> 
> 
> 
> 
> On 10/08/2013 12:35 AM, Acee Lindem wrote:
>> Hi Mike,
>> I agree and don't see why this one configuration error should be handled explicitly when there are many other possible errors. Actually, I'd looked at this text before and meant to address it since I'd never implement this. I'll discuss with the other authors.
>> Thanks,
>> Acee
>> 
>> On Oct 7, 2013, at 6:19 PM, Mike Dubrovskiy (mdubrovs) wrote:
>> 
>>> Hi Acee,
>>> 
>>> I like the change but we currently have the following text in rfc6506
>>> 
>>>   "In the event that the last key associated
>>>   with an interface expires, it is unacceptable to revert to an
>>>   unauthenticated condition and not advisable to disrupt routing.
>>>   Therefore, the router SHOULD send a "last Authentication Key
>>>   expiration" notification to the network operator and treat the key as
>>>   having an infinite lifetime until the lifetime is extended, the key
>>>   is deleted by the network operator, or a new key is configured."
>>> 
>>> The above text is difficult to apply to Accept keys. It should be either deleted
>>> or modified.
>>> 
>>> Thank you,
>>> Mike
>>> 
>>>> -----Original Message-----
>>>> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of
>>>> Acee Lindem
>>>> Sent: Monday, October 07, 2013 1:25 PM
>>>> To: OSPF List
>>>> Subject: [OSPF] One more RFC 6506BIS Clarification
>>>> 
>>>> One more thing I intend to add is explicit specification that the OSPFv3 packet
>>>> should be dropped if the Security Association isn't found or has expired. The
>>>> text is analogous to the original RFC 2328 Appendix D text. This will be added
>>>> to section 4.6.
>>>> 
>>>> ***************
>>>> *** 976,981 ****
>>>> --- 976,986 ----
>>>>     and the IPv6 header length is less than the amount necessary to
>>>>     include an Authentication Trailer.
>>>> 
>>>> +    Locate the receiving interface's OSPFv3 SA using the SA ID in the
>>>> +    received AT.  If the SA is not found, or if the SA is not valid for
>>>> +    reception (i.e., current time < KeyStartAccept or current time >=
>>>> +    KeyStopAccept), the OSPFv3 packet is dropped.
>>>> +
>>>>     If the cryptographic sequence number in the AT is less than or equal
>>>>     to the last sequence number in the last OSPFv3 packet of the same
>>>>     OSPFv3 type successfully received from the neighbor, the OSPFv3
>>>> 
>>>> Although I would hope no one would complain about this since it was always
>>>> implied in section 3 (see excerpt below), please speak now if you have any
>>>> concerns.
>>>> 
>>>>   o  Security Association Identifier (SA ID)
>>>> 
>>>>      This is a 16-bit unsigned integer used to uniquely identify an
>>>>      OSPFv3 SA, as manually configured by the network operator.
>>>> 
>>>>      The receiver determines the active SA by looking at the SA ID
>>>>      field in the incoming protocol packet.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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