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

"Acee Lindem (acee)" <acee@cisco.com> Thu, 15 October 2015 09:17 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 162691A8920; Thu, 15 Oct 2015 02:17:25 -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 RLeu3A1Bu9j7; Thu, 15 Oct 2015 02:17:21 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E571A8901; Thu, 15 Oct 2015 02:17:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31402; q=dns/txt; s=iport; t=1444900640; x=1446110240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SPiXpR/D0mMfEdb4iZHwRAxWPvDy7h/cN4uKxZe3zZE=; b=h0uC+5rL42ib2UYFWeJMyz0lfjc5tac1B3Pk/FO+I7zRMm0V82FyuPmb DPCMPKUHk8k6XvqXesACs4jZtuwrmHJIdfDzmCp9YAwj2Y8aWj8hZ4gJ0 2OR784csJfsloqaKrbBHjeDj33DmXK37V9iZNdaV7Jx/nAn6NAwHUBH6C 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D3AQALbh9W/4UNJK1eDoMYgUIGvTIBDYFZhhwCHIEkOBQBAQEBAQEBgQqEJgEBAQQaCQQNOgYFDAQCAQgRBAEBAQICIwMCAgIwFAEICAIEAQ0FiC6vXpMyAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EiilKEWggQGwcCAgKCY4FFAQSHPYpxg20BjRqBWIQ6gySKEYRZg24BHwEBQoIMBQEcgRc+cYRhgQYBAQE
X-IronPort-AV: E=Sophos;i="5.17,684,1437436800"; d="scan'208";a="198181823"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 15 Oct 2015 09:17:19 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t9F9HJZs009233 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2015 09:17:19 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 04:17:04 -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; Thu, 15 Oct 2015 04:17:04 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Shraddha Hegde <shraddha@juniper.net>, Benjamin Kaduk <kaduk@MIT.EDU>
Thread-Topic: secdir review of draft-ietf-ospf-node-admin-tag-05
Thread-Index: AQHRAtRkZED+3D3sTk6f1e8MGzkzuA==
Date: Thu, 15 Oct 2015 09:17:04 +0000
Message-ID: <D244E733.35E2F%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> <BY1PR0501MB138138D3B4DE2513EE209DE8D53F0@BY1PR0501MB1381.namprd05.prod.outlook.com> <D243B972.35177%acee@cisco.com> <BY1PR0501MB138148F6E2EDB2A686439D31D53E0@BY1PR0501MB1381.namprd05.prod.outlook.com>
In-Reply-To: <BY1PR0501MB138148F6E2EDB2A686439D31D53E0@BY1PR0501MB1381.namprd05.prod.outlook.com>
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: <CCFFF5CBF28FCD48A53F4FA3CFAFF945@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/dO0Slq_QTYT78PduBm1NnGvbZpo>
Cc: "draft-ietf-ospf-node-admin-tag.all@ietf.org" <draft-ietf-ospf-node-admin-tag.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@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: Thu, 15 Oct 2015 09:17:25 -0000

Sounds good. 
Thanks, 
Acee 

On 10/15/15, 1:00 AM, "Shraddha Hegde" <shraddha@juniper.net> wrote:

>Acee,
>
>Although RFC 2328/5340 do not explicitly talk about type 11  LSAs, RFC
>5250 
>Restricts type 11 into stub/NSSAs. Adding the blow text to the draft.
>
>"An ABR in a stub or NSSA area MAY originate AS scoped RI LSAs and flood
>them into non-stub/NSSA areas and MAY originate area scoped RI LSAs into
>the stub/NSSA areas as the AS scoped LSAs
>are not flooded into stub/NSSA areas."
>
>Rgds
>Shraddha
>
>-----Original Message-----
>From: Acee Lindem (acee) [mailto:acee@cisco.com]
>Sent: Wednesday, October 14, 2015 5:33 PM
>To: Shraddha Hegde <shraddha@juniper.net>et>; Benjamin Kaduk <kaduk@MIT.EDU>
>Cc: iesg@ietf.org; secdir@ietf.org;
>draft-ietf-ospf-node-admin-tag.all@ietf.org
>Subject: Re: secdir review of draft-ietf-ospf-node-admin-tag-05
>
>Hi Shraddha, 
>
>On 10/14/15, 12:35 AM, "Shraddha Hegde" <shraddha@juniper.net> wrote:
>
>>Acee,
>>
>><---snipped to open points--->
>>
>>
>>-----------------------------------------------------------------------
>>---
>>-----------------------------------------------------------------------
>>-
>>
>>>> <Shraddha> Could you pls elaborate the case. I don't quite
>>>> understand why the ABR in a stub/NSSA area would generate or receive
>>>> RI LSAs with different scopes.I think it's perfectly valid to flood
>>>> the AS scoped RI LSAs into the stub / NSSA area.
>>>
>>>Acee, I think this is a question for you.
>>
>>Yeah - I missed this without E-mail quoting…
>>
>>Shraddha,
>>
>>AS-scoped LSAs are not flooded into stub or NSSA areas. So, if an ABR
>>is going to advertise tags to its attached areas and the rest of the
>>OSPF Routing domain, it will need to originate the LSA at different
>>scopes.
>>
>><Shraddha> Acee,  I think restricting  AS scoped RI LSA into NSSA /stub
>>areas will have many issues.
>>                                      If a non-ABR router from other
>>area originates RI LSA with node tag and the specific application needs
>>the
>>                                      Tag to be available in the entire
>>OPF domain, how will the stub/NSSA area routers receive it?
>>                                      I think this discussion is
>>equally relevant to 4970bis.
>>                                       I don't see a reason why AS
>>scoped RI LSA should be restricted in stub/NSSA.
>>                                        RI LSAs do not contain any
>>route information so it's not going to be huge in number.
>
>By definition, AS-scoped LSAs are NOT flooded into a stub or NSSA area.
>Please read stub and NSSA area references in RFC 2328, RFC 5340, RFC
>5250, and RFC 3101. You’ll note that stub and NSSA area have no
>visibility to topology or Router IDs of OSPF routers in other areas.
>
>Hope this helps,
>Acee 
>
>
>
>
>>                 
>>                 
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: Acee Lindem (acee) [mailto:acee@cisco.com]
>>Sent: Wednesday, October 14, 2015 4:17 AM
>>To: Benjamin Kaduk <kaduk@MIT.EDU>DU>; Shraddha Hegde <shraddha@juniper.net>
>>Cc: iesg@ietf.org; secdir@ietf.org;
>>draft-ietf-ospf-node-admin-tag.all@ietf.org
>>Subject: Re: secdir review of draft-ietf-ospf-node-admin-tag-05
>>
>>See inline. 
>>
>>On 10/13/15, 6:27 PM, "Benjamin Kaduk" <kaduk@MIT.EDU> wrote:
>>
>>>Thanks, Shraddha and Acee, for helping me find some of the context I
>>>was missing.
>>>
>>>On Sun, 11 Oct 2015, Shraddha Hegde wrote:
>>>
>>>>
>>>> Thanks Ben for detailed review comments.Thanks Acee for chiming-in.
>>>> Few more explanations in-line.
>>>>
>>>> -----Original Message-----
>>>> From: Acee Lindem (acee) [mailto:acee@cisco.com]
>>>> Sent: Sunday, October 11, 2015 1:04 AM
>>>> To: Benjamin Kaduk <kaduk@MIT.EDU>DU>; iesg@ietf.org; secdir@ietf.org;
>>>>draft-ietf-ospf-node-admin-tag.all@ietf.org
>>>> Subject: Re: secdir review of draft-ietf-ospf-node-admin-tag-05
>>>>
>>>> Hi Ben,
>>>>
>>>> As the document shepherd and a long-time OSPF contributor, I’m going
>>>> to try and sort out some of your comments. Note that route tagging
>>>> has been in use for decades and this document is merely extending the
>>>> administrative policies advertisement to the node level.
>>>
>>>Good to know; I didn't get to look at many updates past the core OSPFv2
>>>spec.
>>>
>>>> On 10/9/15, 4:52 PM, "Benjamin Kaduk" <kaduk@MIT.EDU> wrote:
>>>>
>>>> >I have reviewed this document as part of the security directorate's
>>>> >ongoing effort to review all IETF documents being processed by the
>>>> >IESG.  These comments were written primarily for the benefit of the
>>>> >security area directors.  Document editors and WG chairs should
>>>> >treat these comments just like any other last call comments.
>>>> >
>>>> >I will preface these comments with a note that my routing background
>>>> >is quite weak, and I needed to read RFC 2328 and RFC 4970 to have
>>>> >enough context to be able to say much useful about what's going on
>>>> >here; I may still be suffering from some misconceptions.
>>>> >
>>>> >On the whole, this document leaves me feeling unsatisfied; it spends
>>>> >maybe three pages talking about the actual new protocol extension
>>>> >and then gives four pages of example usage, all the while claiming
>>>> >that the actual tag values are only meaningful within a single
>>>> >administrative domain/network, are for generic use, and do not
>>>> >require an IANA registry.  That is, it is trying to walk a middle
>>>> >line between "this document allocates a value in the OSPF TLVs
>>>> >registry for site-local use, use it as you will" and "this document
>>>> >specifies a complete protocol extension for tagging OSPF nodes for
>>>> >traffic engineering, LFA, and other purposes".  That is a hard
>>>> >middle line to follow, and I am
>>>>not sure that this document does so successfully.
>>>> >I will not try to reopen the question of whether it would be better
>>>> >to take one of the non-middle paths, and continue on the assumption
>>>> >that this document will take the middle path.  I think there are a
>>>> >few things that are missing before this document should be
>>>> >published, and that it might be worth considering a more drastic
>>>> >restructuring as
>>>>well.
>>>> >
>>>> >It would probably be good to include some text with the reasoning
>>>> >behind the choice of the "middle line" -- the current text
>>>> >attempting to enforce it, "new OSPF extensions MUST NOT require use
>>>> >of per-node administrative tags or define well-known tag values",
>>>> >seems unenforcable, as a future RFC updating this one could just
>>>> >remove that
>>>>restriction.
>>>>
>>>> The intent here is that this TLV is to be solely for locally defined
>>>> policies. If there were to be a TLV for well-known tags and policies,
>>>> this could be accomplished with a separate OSPF RI TLV. I agree that
>>>> the normative text should be softened from “MUST NOT” to “are not
>>>> expected to”.
>>>>
>>>> <Shraddha> There was a long discussion on the mailing list on whether
>>>> we should allow well defined values for the admin tags majority
>>>> consensus was that we should not allow any standard values for node
>>>> admin tags and in future if such a requirement arises it'll go as new
>>>> feature in RI TLV as Acee already mentioned. I am trying to
>>>> understand why the text need to be softened when any future
>>>> standardization would need altogether a new document and will not
>>>>require any changes to this document.
>>>
>>>I suggested that the text be softened because the current statement
>>>does not have any practical effect.  It's trying to place restrictions
>>>on what {the set of future RFCs that update this document} can do, but
>>>any document in that set could remove such a restriction and override
>>>it at the same time.
>>>
>>>I think it would be good to have a note in section 2 to the effect that
>>>"these administrative tags are solely for use within an administrative
>>>domain and are their interpretation is a matter of local policy.  It is
>>>expected that values will not be portable across administrative
>>>domains".
>>>I know that this topic is covered later in the document, but having it
>>>early would help set the stage for the rest of the document.
>>>
>>>> >It looks like there's now an -06, but the changes from the -05 are
>>>> >not significant.  The security considerations in the -05 correctly
>>>> >note what are essentially privacy considerations regarding the
>>>> >contents of the admin tags.  However, it seems like there are also
>>>> >potential security considerations on the actual operation of the
>>>> >network that are not discussed here, nor in RFC 2328 (OSPFv2) or RFC
>>>> >5340 (OSPFv3).  RFC 5340's security considerations explicitly
>>>> >disclaims protections against compromised, malfunctioning, or
>>>> >misconfigured routers, deferring to RFC 4593, "Generic Threats to
>>>> >Routing Protocols".  I believe that the security considerations of
>>>> >this document should address, either directly or indirectly,
>>>> >protections against compromised, malfunctioning, or misconfigured
>>>> >routers, and additionally protection against malicious actors with
>>>> >access to the layer-3 network (and maybe lower layers as well).
>>>> >
>>>> >That probably means mentioning RFC 4593 directly, or maybe just
>>>> >pointing out that RFC 5340 does so.  There are still additional
>>>> >considerations introduced by this document, though; unfortunately,
>>>> >because the bulk of the interpretation of the admin tags is left to
>>>> >the site administrator, it is hard to give a comprehensive security
>>>> >analysis, but the examples and the protocol description itself do
>>>> >give
>>>>some areas for consideration.
>>>>
>>>> The document could reference RFC 4593/RFC 6863 and state that
>>>> authentication as specified in RFC 7474 or RFC 7166 SHOULD be used in
>>>> deployments where attackers have access to the physical networks
>>>> included in the OSPF domain are vulnerable.
>>>> <Shraddha> ok. Updating the Security consideration section
>>>
>>>Thanks.
>>>
>>>>
>>>> >
>>>> >The RI LSAs carrying administrative tags can be at link-, area-, or
>>>> >AS-level scope; an administrator assigning tag values and associated
>>>> >policies should consider what would happen if a given tag was
>>>> >advertised at a different scope than intended.  Compliant
>>>> >implementations MUST NOT generate the same tag at different scopes,
>>>> >but a receiver would need to take some action if it happened,
>>>> >whether due to network glitch or malicious action -- what should they
>>>>do?
>>>>
>>>> I’m not an author, but this is what I’d recommend:
>>>>
>>>>    The conflicting tag SHOULD not be used and this situation SHOULD
>>>> be logged as an error including the tag with conflicting scopes and
>>>> the originator(s).
>>>> <Shraddha> Updated the document with above statement.
>>>>
>>>> There is a case that must be allowed - the same tag could be received
>>>> by an ABR at both the AS scope and the area scope in a stub or NSSA
>>>>area.
>>>> <Shraddha> Could you pls elaborate the case. I don't quite understand
>>>> why the ABR in a stub/NSSA area would generate or receive RI LSAs
>>>> with different scopes.I think it's perfectly valid to flood the AS
>>>> scoped RI LSAs into the stub / NSSA area.
>>>
>>>Acee, I think this is a question for you.
>>
>>Yeah - I missed this without E-mail quoting…
>>
>>Shraddha, 
>>
>>AS-scoped LSAs are not flooded into stub or NSSA areas. So, if an ABR is
>>going to advertise tags to its attached areas and the rest of the OSPF
>>Routing domain, it will need to originate the LSA at different scopes.
>>
>>
>>
>>>
>>>> >Another potential issue lies in the "stickiness" of the admin tags
>>>> >-- the text "the node administrative tags associated with a node for
>>>> >the purpose of any computation or processing SHOULD be a superset of
>>>> >node administrative tags from all the TLVs in all instances of the
>>>> >RI LSA originated by that node" seems to mean that once a tag is
>>>> >set, it cannot
>>>> >(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.
>>
>>>
>>>If there can only be one RI LSA that is "current" for a given node (at
>>>a given scope?), then it seems like it would be useful to change the
>>>text to explicitly say "all current instances" -- that would have
>>>helped me as I read it.
>>
>>I see the confusion is between instances of the same LSA in the general
>>sense and multiple instances of the OSPF RI LSA. Refer to RFC 2328
>>section 13.1.  
>>
>>
>>>
>>>> > How disruptive would that be?  It would be helpful to see some
>>>> >discussion of how a tag would be removed.
>>>>
>>>> I may of worked on OSPF for too long but this should be obvious to
>>>> anyone implementing the draft from the specification.
>>>
>>>If it's simply a matter of re-issuing the RI LSA (I was not sure when I
>>>was writing my review), then I agree it should be obvious.
>>>
>>>> <Shraddha> The below paragraph (from -07 version) is clear on this I
>>>>hope.
>>>>
>>>> "When there is a change or removal of an administrative affiliation
>>>>of a node,
>>>>    the node MUST re-originate the RI LSA with the latest set of node
>>>>administrative tags.
>>>>    On the receiver, When there is a change in the node administrative
>>>>tag TLV or removal/
>>>>    addition of a TLV in any instance of the RI-LSA, implementations
>>>>MUST
>>>>    take appropriate measures to update its state according to the
>>>>    changed set of tags.  Exact actions depend on features working with
>>>>    administrative tags and is outside of scope of this specification."
>>>
>>>This is definitely improved, but it does not do much to address the
>>>issue I had in mind when I was writing my review.  However, it seems
>>>like that issue is not actually an issue, so no further changes to this
>>>text would be needed.
>>>
>>>
>>>> >
>>>> >That is particularly easy for an attacker when the null OSPF
>>>> >authentication mechanism is in use (how common is that?  I saw some
>>>> >websites indicating it was the default behavior, at least sometimes).
>>>> >I do not see a need to turn this document into "security
>>>> >considerations for OSPF authentication", but maybe it is worth
>>>>mentioning some things:
>>>> >the
>>>> >md5 scheme seems pretty week at this point (though probably not
>>>> >trivially broken), the hmac-sha scheme of RFC 5709 is only from
>>>> >2009, and RFC 7474 (only six months old) points out cases where both
>>>> >are susceptible to replay attacks.  Just looking at the security
>>>> >considerations of this document and the core OSPF v2/v3 specs does
>>>> >not convey this to the reader, so I would like to see at least a
>>>> >pointer to such considerations.  (The stance of RFC 2328 that "all
>>>> >OSPF protocol
>>>>exchanges are authenticated"
>>>> >seems particularly disingenous given the presence of the null
>>>> >authentication scheme.)
>>>>
>>>> I think both RFC 7474 and RFC 7176 should be referenced. The OSPF
>>>> vulnerability to replay attacks to OSPFv2/OSPFv3 routers implementing
>>>> these specifications is extremely small and has been reduced as much
>>>> as practical. If you are still concerned, I suggest you discuss with
>>>> Sam Hartman (also once affiliated with MIT).
>>>
>>>I am not especially concerned about this attack, I just noticed that
>>>there was an RFC about it.  Since RFC 7474 was so recent, it made me
>>>wonder how widely deployed the security fixes are today.
>>
>>Correct - it is not widely implemented or deployed.
>>
>>Thanks,
>>Acee
>>
>>>
>>>> <Shraddha> Security consideration section updated with the reference
>>>> to RFC 7474 and 7176.
>>>
>>>Thanks.
>>>
>>>> >
>>>> >There is also the possibility that an attacker could block delivery
>>>> >of an LSA, causing a tag that should be set to not be seen.  This
>>>> >seems unlikely for wired point-to-point links, but is more plausible
>>>> >in other environments, such as radio links.  I think I can imagine
>>>> >scenarios where this would cause drastic damage to the routing
>>>>topology.
>>>>
>>>> The description and mitigation of such a generic threat doesn’t
>>>>belong in a minor (though important) OSPF specification. The effect of
>>>>blocking control traffic is never positive ;^). At least OSPF uses
>>>>reliable flooding so it will be retransmitted.
>>>> <Shraddha> Agree with Acee on this.
>>>
>>>I had forgotten that OSPF flooding was reliable; I agree this does not
>>>need to be explicitly called out in this document, since it's a general
>>>routing concern.
>>>
>>>> >The parenthetical in section 3.2 wherein routers might advertise a
>>>> >per-node aministrative tag "without knowing (or even explicitly
>>>> >supporting) functionality implied by the tag" seems potentially
>>>> >dangerous, since it sounds like the routers in question are lying
>>>> >about their capabilities.  Would the document suffer harm if the
>>>> >parenthetical was removed?
>>>>
>>>> In my opinion, no harm to remove - misconfiguration is almost always
>>>>an issue.
>>>> <Shraddha> It's perfectly valid for a node originate a tag when the
>>>>node  itself does not Process any tags. I think the sentence needs to
>>>>be  rephrased. Changing it as below.
>>>>
>>>> <t>Meaning of the Node administrative tags is generally opaque to
>>>> OSPF. Router advertising the per-node administrative tag (or tags)
>>>> may be configured to do so without knowing (or even without
>>>> supporting processing of) functionality implied by the tag.</t>
>>>
>>>I think there is a question about whether this means that the router
>>>doesn't need to know what feature the tag number means, or whether it
>>>means that the router doesn't need to implement the feature indicated
>>>by that tag value.  I read this text as being in the second case, but I
>>>am interpreting your discussion about this text to mean that you think
>>>it is covering the first case.  (Yes, there can be tag values that just
>>>indicate an administrative grouping and there is no corresponding
>>>functionality needed on the router, but there can also be tag values
>>>that indicate "the router originating this RI LSA supports accepting
>>>targeted LDP sessions"
>>>-- a router will cause breakage if it sends such a tag but does not
>>>actually support accepting targeted LDP sessions.)
>>>
>>>Based on this discussion, I think that what the parenthetical is trying
>>>to say is that "the router originating the tag may not use that tag in
>>>any of its processing decisions" -- is that correct?
>>>
>>>Changing the word "functionality" to "attributes" would cause me to
>>>read the text as being in the first case I described above.
>>>
>>>(By the way, this paragraph had a lot of changes in my patch for
>>>grammar; it might have been easier to apply that patch before making
>>>further edits, to reduce the number of merge conflicts.  The grammar in
>>>the quoted new text has several errors.)
>>>
>>>> >One reason I am unsatisfied by making the interpretation of the tag
>>>> >values specific to an administrative domain is that a misconfigured
>>>> >border router might erroneously use tag values from one domain on
>>>> >the other side of the border.
>>>> > Perhaps the other damage from a router misconfigured in such a
>>>> >fashion would dwarf the additional damage from the misinterpreted
>>>> >tags and so my concern is invalid; I really can't say.
>>>>
>>>> Again, I don’t think misconfiguration needs to be covered - "emptor
>>>>cavete”.
>>>
>>>A misconfigured router is by definition broken.  Such misconfiguration
>>>can happen either by accident due to operator error, or maliciously, if
>>>an attacker has compromised the system.  While it may not be necessary
>>>to say that a broken router will not pass traffic the way it's supposed
>>>to, if a misconfigured router can emit routing protocol messages that
>>>affect the state of the network as a whole, not just its local
>>>surroundings, that seems like an analysis that is appropriate for the
>>>security considerations of a routing protocol document.  Now, I don't
>>>have a good picture of specific examples of network-wide issues due to
>>>the admin tag, but I think there's a large enough probability that it's
>>>possible for such a thing to happen that I wanted to mention it in my
>>>review comments.  Maybe there is not anything worth mentioning about it
>>>in the security considerations section, but I don't think that
>>>"misconfiguration doesn't need to be covered" addresses the concern I
>>>was attempting to raise.
>>>
>>>> <Shraddha> -07 version addresses this issue.
>>>>
>>>> "Advertisement of tag values for one administrative domain into
>>>>another  risks misinterpretation of the tag values (if the two domains
>>>>have assigned  different meanings to the same values), which may have
>>>>undesirable and unanticipated side  effects."
>>>
>>>Thank you, that helps.
>>>
>>>> Thanks for the editorial review as well. Speak as WG chair, I
>>>>appreciate this.
>>>
>>>You're welcome!
>>>
>>>-Ben
>>
>