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

Benjamin Kaduk <kaduk@MIT.EDU> Tue, 13 October 2015 22:58 UTC

Return-Path: <kaduk@mit.edu>
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 196001A86F7; Tue, 13 Oct 2015 15:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iavw6ceneaM0; Tue, 13 Oct 2015 15:57:59 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30AA1A21C7; Tue, 13 Oct 2015 15:57:57 -0700 (PDT)
X-AuditID: 12074423-f793f6d000007fc1-0c-561d8c73488f
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id BB.7D.32705.37C8D165; Tue, 13 Oct 2015 18:57:55 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t9DMvsYL010487; Tue, 13 Oct 2015 18:57:54 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t9DMvoJM002601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Oct 2015 18:57:53 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t9DMvo4G022669; Tue, 13 Oct 2015 18:57:50 -0400 (EDT)
Date: Tue, 13 Oct 2015 18:57:50 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: "Acee Lindem (acee)" <acee@cisco.com>
In-Reply-To: <D242FF5D.34EA7%acee@cisco.com>
Message-ID: <alpine.GSO.1.10.1510131856050.26829@multics.mit.edu>
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>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-909332701-1444777070=:26829"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixG6nrlvcIxtmMPGogMXkt/OYLX6/2sJu MePPRGaLDwsfsljceLSX2YHVY8rvjaweS5b8ZPK43nSVPYA5issmJTUnsyy1SN8ugSvj5tcH 7AX/BSoOd/5nb2DcydvFyMkhIWAiMe/8fkYIW0ziwr31bF2MXBxCAouZJFb+3MEE4WxklDh/ 9x2Uc4hJYu6vZSwQTgOjxI2Zv5hB+lkEtCWWz7rPBmKzCahIzHyzEcjm4BAR0JTY8h6snlng HqPEvvurWUFqhAXsJY68uMcCYnMK6Ei833uBHcTmFXCU2H1rKzvEgj4miZ/fl4ENFQUqWr1/ CgtEkaDEyZlPwGxmgQCJiTdesk1gFJyFJDULSQrCVpdofHAWytaWuH+zjW0BI8sqRtmU3Crd 3MTMnOLUZN3i5MS8vNQiXTO93MwSvdSU0k2M4DhwUd7B+Oeg0iFGAQ5GJR7eF5EyYUKsiWXF lbmHGCU5mJREeRdXyYYJ8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuE1SgXK8aYkVlalFuXDpKQ5 WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8D7oAmoULEpNT61Iy8wpQUgzcXCCDOcBGu4P UsNbXJCYW5yZDpE/xagoJc57FiQhAJLIKM2D6wWnqd1Mqq8YxYFeEeZ16Qaq4gGmOLjuV0CD mUCuZpcCGVySiJCSamC82X9bvUdg3a8Zd65flbn/6bAvG0/HkyhPdrHTz245NjqXTP77vjJr xe/bYT+OWelbsQu9nKV2OfjfIe8k74IC/yAZJ9aUyIony7YcPzwv+FD/q2/9LM990y7G2anL +OvbMyyrmHe/590syTL5rllNW7ZUTRWReSj35eenuyuq3biVjCIurglWYinOSDTUYi4qTgQA 6x9a1i4DAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/CBE23Dy9VNUMoLgrXU_8aGDC-fU>
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 22:58:01 -0000

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.

-Ben