IETF Logo Mail Archive

Re: [secdir] secdir review of draft-ietf-ospf-node-admin-tag-05

"Acee Lindem (acee)" <acee@cisco.com> Tue, 13 October 2015 23:02 UTC

Return-Path: <acee@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDB31A87BD; Tue, 13 Oct 2015 16:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx79zS8liYhr; Tue, 13 Oct 2015 16:02:44 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B3C1A87BB; Tue, 13 Oct 2015 16:02:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2896; q=dns/txt; s=iport; t=1444777364; x=1445986964; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mTWDODJICUJykDVxKpiu6knqgUvtTdYSeiIdZ5jq5+M=; b=FApUm+jjofRCFaulC66s85v8NGRuuwNKNhGlEKsvM3Cxmx1Ezvc1aCR5 SdDMmCvLmsItH3xgyraHJwco8tzwqarrQiPM2TxouYo1HGNe44c54Lync KvRgkbmVodyxUr7LMCLjiSV0oe+lmh2RDpt+S7EFwpJGFOSp6mjWT4nZn w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DwAQBLjR1W/4YNJK1eDoMYgUIGvgwBDYFagxODCQIcgSs4FAEBAQEBAQGBCoQnAQEEIxFFEAIBCBgCAiYCAgIwFRACBA4FiC6vIpNVAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EiilGEWjMHgmmBRQWWFgGNGZwHAR8BAUKCER2BFj5xhWuBBgEBAQ
X-IronPort-AV: E=Sophos;i="5.17,680,1437436800"; d="scan'208";a="197553529"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 13 Oct 2015 23:02:30 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9DN2Ua9010771 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Oct 2015 23:02:30 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 13 Oct 2015 18:02:17 -0500
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.000; Tue, 13 Oct 2015 18:02:16 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Thread-Topic: secdir review of draft-ietf-ospf-node-admin-tag-05
Thread-Index: AQHRAtRkZED+3D3sTk6f1e8MGzkzuJ5lMHaAgATWidGAABZXAIAARf4A//++TIA=
Date: Tue, 13 Oct 2015 23:02:16 +0000
Message-ID: <D2430569.34EFD%acee@cisco.com>
References: <alpine.GSO.1.10.1510091159450.26829@multics.mit.edu> <D23ED021.34690%acee@cisco.com> <BY1PR0501MB1381A8D06B804AE4508F371AD5320@BY1PR0501MB1381.namprd05.prod.outlook.com> <alpine.GSO.1.10.1510131547130.26829@multics.mit.edu> <D242FF5D.34EA7%acee@cisco.com> <alpine.GSO.1.10.1510131856050.26829@multics.mit.edu>
In-Reply-To: <alpine.GSO.1.10.1510131856050.26829@multics.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.199]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F09BCB77306C9E46B55DA5F5E5B2A9BE@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/6STwo8kFYO63eXtu2xbfXXsq-Fk>
Cc: "draft-ietf-ospf-node-admin-tag.all@ietf.org" <draft-ietf-ospf-node-admin-tag.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, Shraddha Hegde <shraddha@juniper.net>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-ospf-node-admin-tag-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2015 23:02:45 -0000


On 10/13/15, 6:57 PM, "Benjamin Kaduk" <kaduk@MIT.EDU> wrote:

>On Tue, 13 Oct 2015, Acee Lindem (acee) wrote:
>
>>
>> On 10/13/15, 6:27 PM, "Benjamin Kaduk" <kaduk@MIT.EDU> wrote:
>>
>> >On Sun, 11 Oct 2015, Shraddha Hegde wrote:
>> >
>> >> >(easily) be unset.  Would force-expiring an LSA be enough to reset
>>the
>> >> >tag, or something else?
>> >>
>> >> Yes - this is standard for any OSPF LSA. However, since the OSPF RI
>>LSA
>> >> may include other TLVs or even other tags, a tag could also be
>>withdrawn
>> >> by reoriginating the RI LSA without the TLV or with a TLV that
>>doesn’t
>> >> include the withdrawn tag.
>> >
>> >I may still be confused, but I did not interpret the text in that way.
>> >That is, the text about "all instances of the RI LSA originated by that
>> >node".  (Which I changed to "instances of RI LSAs" in my grammar edits,
>> >possibly incorrectly if I'm still confused.)  I was interpreting the
>>word
>> >"instances" to include historical ones over time, so that even if an RI
>> >LSA carrying a particular admin tag was replaced by a different RI LSA
>> >for the same advertising router, the old one would still be an
>>instance of
>> >that RI LSA.  Going back to RFC 2328, I'm not sure what exactly I had
>>in
>> >mind in terms of ages and scopes and sequence numbers that would cause
>> >this
>> >situation, but I somehow had it in my mind that there could be
>>multiple RI
>> >LSAs active at the same time that apply to a given node, such as if the
>> >admin just added a new RI LSA containing only the admin tag to augment
>>the
>> >existing RI LSAs being sent.  Is that possible?
>>
>> In OSPF, a more-recent version or instance of an LSA will always
>>supersede
>> all previous instances of the same LSA.
>
>Thanks for clarifying.  So, this is a non-issue, and the only question is
>whether the text could/should be changed to improve clarity.

Let me think about this since it is a generic OSPF RI ambiguity and it
will affect multiple documents. In a WebEx right now though…

Thanks,
Acee



>
>-Ben

v2.23.0 | Report a Bug | By Email