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>; 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>; 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>; 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 >> >
- [secdir] secdir review of draft-ietf-ospf-node-ad… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Acee Lindem (acee)
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… bruno.decraene
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… bruno.decraene
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde
- Re: [secdir] secdir review of draft-ietf-ospf-nod… Shraddha Hegde