Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07

"Black, David" <david.black@emc.com> Sun, 11 October 2015 21:51 UTC

Return-Path: <david.black@emc.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AC61A92F1; Sun, 11 Oct 2015 14:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 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_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 q_nJeKiWQWNy; Sun, 11 Oct 2015 14:51:41 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D828D1A916A; Sun, 11 Oct 2015 14:51:40 -0700 (PDT)
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t9BLpUxZ004462 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 11 Oct 2015 17:51:31 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t9BLpUxZ004462
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1444600291; bh=AG0Kg1jeSQzekrV3j5bzoJyzvOk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=YYJkzmaPSbVh0Ro20QoXQdfVgrJet7TTBKeoRjC+LJNp0UhmGPqtipmV7oDy/D0JH 8PEdQGxS+oGizNvfgM3BUNU1Ru0uIAgCTAufngbxKhQEuw00R7ccmVOePU0arPqTKS okNatSDVlPJv6SSF/jh7vI1Rx8XfMxJpqd34EgvA=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t9BLpUxZ004462
Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd06.lss.emc.com (RSA Interceptor); Sun, 11 Oct 2015 17:50:47 -0400
Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t9BLpCbh004716 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 11 Oct 2015 17:51:13 -0400
Received: from MXHUB207.corp.emc.com (10.253.68.33) by mxhub25.corp.emc.com (10.254.110.181) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sun, 11 Oct 2015 17:51:11 -0400
Received: from MX104CL02.corp.emc.com ([169.254.8.74]) by MXHUB207.corp.emc.com ([10.253.68.33]) with mapi id 14.03.0266.001; Sun, 11 Oct 2015 17:51:11 -0400
From: "Black, David" <david.black@emc.com>
To: Shraddha Hegde <shraddha@juniper.net>, "rjs@rob.sh" <rjs@rob.sh>, "as@cisco.com" <as@cisco.com>, "lizhenbin@huawei.com" <lizhenbin@huawei.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>
Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07
Thread-Index: AdEC0zGWXF/6DiT8S06I9BPuQhJfXABUGhUwABLES3A=
Date: Sun, 11 Oct 2015 21:51:10 +0000
Message-ID: <CE03DB3D7B45C245BCA0D24327794936166B9454@MX104CL02.corp.emc.com>
References: <CE03DB3D7B45C245BCA0D24327794936166B7222@MX104CL02.corp.emc.com> <BY1PR0501MB1381C9C4AE5057EF4C38BAEBD5320@BY1PR0501MB1381.namprd05.prod.outlook.com>
In-Reply-To: <BY1PR0501MB1381C9C4AE5057EF4C38BAEBD5320@BY1PR0501MB1381.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.105.56.35]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com
X-RSA-Classifications: public
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/3ZmYZiNE--mkL-xxIaaxORiBkw4>
Cc: "ospf@ietf.org" <ospf@ietf.org>, "Black, David" <david.black@emc.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 11 Oct 2015 21:51:44 -0000

> I think this description would also cover the issue you have brought up. Let
> me know if you are OK with this.

Yes, I'm OK - that covers the topic.

Thanks, --David

> -----Original Message-----
> From: Shraddha Hegde [mailto:shraddha@juniper.net]
> Sent: Sunday, October 11, 2015 9:08 AM
> To: Black, David; rjs@rob.sh; as@cisco.com; lizhenbin@huawei.com;
> bruno.decraene@orange.com; General Area Review Team (gen-art@ietf.org); ops-
> dir@ietf.org
> Cc: ietf@ietf.org; ospf@ietf.org; acee@cisco.com
> Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07
> 
> David,
> 
> 
> >Injection of tag values from the outside (e.g., forge OSPF traffic that
> appears to be from a node in the domain and carries administrative tag values)
> is >at least a possible denial-of-service attack vector, and could also be
> used for more nefarious purposes (e.g., reroute otherwise unobservable [to the
> >attacker] VPN traffic via a route where the attacker can observe it).
> Measures should be taken to prevent injection of outside OSPF traffic in
> general >to protect not only tags, but all OSPF routing functionality.
> 
> <Shraddha> The -08 version contains reference to RFC 4593 and RFC 6863 which
> discuss in-detail on different security vulnerabilities and OSPF
> authentication mechanisms described in RFC 2328,5340 , 7474 and 7166 are sited
> as solution to the problem.
> I think this description would also cover the issue you have brought up. Let
> me know if you are OK with this.
> 
> Rgds
> Shraddha
> 
> 
> -----Original Message-----
> From: Black, David [mailto:david.black@emc.com]
> Sent: Saturday, October 10, 2015 2:14 AM
> To: Shraddha Hegde <shraddha@juniper.net>et>; rjs@rob.sh; as@cisco.com;
> lizhenbin@huawei.com; bruno.decraene@orange.com; General Area Review Team
> (gen-art@ietf.org) <gen-art@ietf.org>rg>; ops-dir@ietf.org
> Cc: ietf@ietf.org; ospf@ietf.org; acee@cisco.com; Black, David
> <david.black@emc.com>
> Subject: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-07
> 
> The -07 version of this draft addresses all of the issues raised in the Gen-
> ART and OPS-Dir review of the -06 version, with the Operational Considerations
> section being a particularly welcome addition.  Many thanks to the authors for
> the quick turnaround on everything that was done.
> 
> The following is a possible additional security consideration:
> 
> Injection of tag values from the outside (e.g., forge OSPF traffic that
> appears to be from a node in the domain and carries administrative tag values)
> is at least a possible denial-of-service attack vector, and could also be used
> for more nefarious purposes (e.g., reroute otherwise unobservable [to the
> attacker] VPN traffic via a route where the attacker can observe it).
> Measures should be taken to prevent injection of outside OSPF traffic in
> general to protect not only tags, but all OSPF routing functionality.
> 
> Thanks,
> --David
> 
> 
> > -----Original Message-----
> > From: Black, David
> > Sent: Monday, October 05, 2015 7:35 PM
> > To: shraddha@juniper.net; rjs@rob.sh; as@cisco.com;
> > lizhenbin@huawei.com; bruno.decraene@orange.com; General Area Review
> > Team (gen-art@ietf.org); ops- dir@ietf.org
> > Cc: ietf@ietf.org; ospf@ietf.org; Black, David; acee@cisco.com
> > Subject: Gen-ART and OPS-Dir review of
> > draft-ietf-ospf-node-admin-tag-06
> >
> > This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both
> > follows ...
> >
> > I am the assigned Gen-ART reviewer for this draft. For background on
> > Gen-ART, please see the FAQ at:
> >
> > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >
> > Please resolve these comments along with any other Last Call comments
> > you may receive.
> >
> > I have reviewed this document as part of the Operational directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > operational area directors.
> > Document editors and WG chairs should treat these comments just like
> > any other last call comments.
> >
> > Document: draft-ietf-ospf-node-admin-tag-06
> > Reviewer: David Black
> > Review Date: October 5, 2015
> > IETF LC End Date: October 8, 2015
> > IESG Telechat date: October 15, 2015
> >
> > Summary:  This draft is on the right track, but has open issues
> >  		described in the review.
> >
> > This is a generally well-written draft about adding administrative
> > tags for operational use to OSPF.  The draft is clear, and the
> > material on how the tags could be used is helpful, although raises a
> > number of concerns about the consequences of the intended usage of these
> tags.
> >
> > ---- Major issues: ----
> >
> > [1] Operational considerations:  There appears to be more than enough
> > enabled by this draft to wreak serious operational havoc, but the
> > draft seems to sidestep all operational topics, primarily by treating
> > all usage of tags as vendor- or implementation- specific and trusting
> > the vendors and operators not to foul things up.  I'm not sure that's wise.
> >
> > See end of OPS-Dir review below for more on this concern.
> >
> > --- Minor issues: ----
> >
> > -- 3.2 Elements of procedure:
> >
> > [A] I see what look like some underspecified requirements:
> >
> >    Each tag SHOULD be treated as an independent identifier that MAY be
> >    used in policy to perform a policy action.
> >
> >    The administrative tag list within the
> >    TLV SHOULD be considered an unordered list.
> >
> > Why are those two not "MUST" requirements?  What happens if either is
> > not done?
> >
> > [B] Tag set completeness:
> >
> >    Multiple node administrative tag TLVs MAY appear in an RI LSA or
> >    multiple node administrative tag TLVs MAY be contained in different
> >    instances of the RI LSA.  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.
> >
> > This paragraph is about processing at that node.  It's easy to
> > misread, as that implication is buried in the word "originated" in the last
> line.
> > Suggested change:
> >
> > 	"for the purpose of any computation or processing SHOULD" ->
> > 	"for the purpose of any computation or processing performed
> > 		at that node SHOULD"
> >
> > Also, it looks like it's acceptable for other nodes to perform such
> > computation or processing based on a partial tag set for this node
> > (e.g., when some other node has not received all the RI LSAs with all
> > the tags).  That should be stated.
> >
> > [C] Tag change/removal:
> >
> >    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.
> >
> > Inability to interoperably remove a tag value (e.g., distribute the
> > update that tag X no longer applies to node Q) seems like a
> > significant omission, but I'm not a routing expert, so I'll defer to
> > the WG's and ADs' judgment on the importance of this.  At a minimum,
> > the rationale for not specifying an interoperable tag value removal
> > mechanism ought to be added to this document.
> >
> > [D] No management support
> >
> > From OPS-Dir Q&A: At a minimum, reporting of tag values ought to be
> > defined via an OSPF MIB extension or analogous functionality.
> >
> > --- Nits/editorial comments: ----
> >
> > -- 1.  Introduction
> >
> > The Abstract says that the tags are for "route and path selection";
> > the Introduction should also say that.  Suggestion - at the end of
> > this sentence in the first paragraph:
> >
> >    It is useful to assign a per-node administrative tag to a router in
> >    the OSPF domain and use it as an attribute associated with the node.
> >
> > add the text "for route and path selection".  This will help with the
> > second sentence in the second paragraph:
> >
> >    Path selection is a functional set
> >    which applies both to TE and non-TE applications and hence new TLV
> >    for carrying per-node administrative tags is included in Router
> >    Information LSA [RFC4970] .
> >
> > If "path selection" and "functional set" are specific terms with
> > specialized meaning in OSPF context, that sentence is fine as-is,
> > otherwise it would read better if it began with:
> >
> >    Route and path selection functionality applies to both ...
> >
> > -- 3.1.  TLV format
> >
> >    Type : TBA, Suggested value 10
> >
> > Please add an RFC Editor Note asking the RFC Editor to replace this
> > with the actual IANA-assigned value.
> >
> > -- 3.2.  Elements of procedure
> >
> > While it's obvious that tag usage should be confined to the
> > administrative domain that understands the tag, it's worth stating.
> > At the end of this
> > sentence:
> >
> >    Interpretation of tag values is specific to the administrative domain
> >    of a particular network operator.
> >
> > I'd suggest adding:
> >
> >    , and hence tag values SHOULD NOT be propagated outside the
> >    administrative domain to which they apply.
> >
> > -- 4.4.  Mobile back-haul network service deployment
> >
> > Please expand "eNodeB" acronym on first use.
> >
> > -- 4.5.  Explicit routing policy
> >
> > In Figure 3:
> > - The link from the leftmost pair of A nodes to the pair of T nodes
> >    do not have link weights.
> > - The link from the left R node to the left T node does not have a
> >    link weight
> > - The following example of an explicitly routed policy:
> >
> >       - Traffic from A nodes to I nodes must not go through R and T
> >       	nodes
> >
> >     prevents the leftmost pair of A nodes from sending traffic to the
> >     I nodes.  Was this "black hole" intended as part of the example?
> >
> > Also: "explicitly routed policies" -> "explicit routing policies"
> >
> > - 5. Security considerations
> >
> > I'd add discussion that 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.
> >
> > In addition, injection of tag values from the outside (e.g., forge
> > OSPF traffic that appears to be from a node in the domain and carries
> > administrative tag values) is at least a possible denial-of-service
> > attack vector, and could also be used for more nefarious purposes
> > (e.g., reroute otherwise unobservable [to the attacker] VPN traffic
> > via a route where the attacker can observe it).
> >
> > idnits 2.13.02 did not find any nits.
> >
> > ---- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ----
> >
> > A.1.2.  Has installation and initial setup been discussed?
> > A.1.5.  Has the impact on network operation been discussed?
> > A.1.6.  Have suggestions for verifying correct operation been discussed?
> >
> > 	No - given the impact that these tags could have on route and path
> > 		computation, likely implementations will be powerful "guns"
> > 		with which network operators can readily shoot themselves
> > 		in far more than just their "feet."  These
> > 		considerations would have to be documented based on the
> > 		specific uses made of these tags by specific implementations
> > 		and deployments.  All of that appears to be outside the scope
> > 		of this draft.
> >
> > A.1.7.  Has management interoperability been discussed?
> >
> > 	No - at a minimum, reporting of tag values ought to be defined
> > 		via an OSPF MIB extension or analogous functionality.
> > 		This is minor issue [D].
> >
> > A.1.8.  Are there fault or threshold conditions that should be reported?
> >
> > 	Yes, but they're implementation-specific - see response to
> > 		A.1.[2,5,6] above.
> >
> > A.2.  Management Considerations
> >    Do you anticipate any manageability issues with the specification?
> >
> > 	Yes, manageability has been largely ignored.
> >
> > A.3.  Documentation
> >
> >    Is an operational considerations and/or manageability section part of
> >    the document?
> >
> > 	No.
> >
> >    Does the proposed protocol have a significant operational impact on
> >    the Internet?
> >
> > 	Yes, the anticipated uses will.
> >
> >    Is there proof of implementation and/or operational experience?
> >
> > 	Nothing was stated in the draft or shepherd write-up.
> >
> > As an OPS-Dir member, I'm concerned by the above RFC 5706 answers, and
> > in particular treating all operational issues as vendor- and/or
> > operator-specific.  One possible alternative would be to scope the
> > draft down to interoperably specify what's needed for LFA, as
> > indicated by this answer from the Shepherd write-up:
> >
> > (9) How solid is the WG consensus behind this document? Does it
> >     represent the strong concurrence of a few individuals, with others
> >     being silent, or does the WG as a whole understand and agree with it?
> >
> >       There is consensus from the WG and others outside the WG that
> >       this document can progress. It complements work done on LFA
> >       manageability in the RTG Working Group.
> >
> > Another alternative could be Experimental RFC status for the full tag
> > mechanism (e.g., to figure out what it'll be used for in practice, how
> > and why) rather than Proposed Standard.
> >
> > This is major issue [1].
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer EMC Corporation, 176 South St.,
> > Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > david.black@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >