Re: [Idr] Routing directorate QA review of draft-ietf-idr-flowspec-interfaceset

Jeffrey Haas <jhaas@pfrc.org> Tue, 28 February 2017 21:39 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6121A127ABE; Tue, 28 Feb 2017 13:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 grXv8rtSHeyu; Tue, 28 Feb 2017 13:38:58 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B3CD3127071; Tue, 28 Feb 2017 13:38:58 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 439191E32D; Tue, 28 Feb 2017 16:44:46 -0500 (EST)
Date: Tue, 28 Feb 2017 16:44:46 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Geoff Huston <gih@apnic.net>
Message-ID: <20170228214445.GC17448@pfrc.org>
References: <9C5FD3EFA72E1740A3D41BADDE0B461FC61A7A91@szxema506-mbs.china.huawei.com> <D260F07B-21E5-4F78-87D0-E48EEE879AAB@apnic.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D260F07B-21E5-4F78-87D0-E48EEE879AAB@apnic.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nKYesNChifWZmAM5V3-dC6Gwtws>
Cc: draft-ietf-idr-flowspec-interfaceset.all@ietf.org, idr wg <idr@ietf.org>, "Yemin \(Amy\)" <amy.yemin@huawei.com>, rtg-dir@ietf.org
Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-flowspec-interfaceset
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Feb 2017 21:39:00 -0000

Geoff,

Thank you for your comments.

On Mon, Feb 27, 2017 at 02:02:05PM +1100, Geoff Huston wrote:
> Here’s where I have a few issues that I found in reviewing this draft.
> 
> The diagram in figures 1 and 2 appear to overuse the term “PE” - it
> appears that this may or may not be a MPLS PE router, as in the context of
> this draft it appears that they are simply EBGP speakers. It would be
> helpful to clarify this.

While I'm not aware of any specific IETF document clarifying such usage, PE
is often an overloaded term among various Service Providers these days.

While you are correct that PE in most IETF contexts tends to refer to the
router fulfilling a MPLS LxVPN Provider Edge router, it's also become a term
that is used interchangable as the router at the edge of the Service
Provider's domain.  That domain edge might be a MPLS LxVPN PE, or it might be
an ASBR facing an entity that isn't the Service Provider.  However, many
Service Providers build their networks out of multiple-ASes, sometimes
public, sometimes private - and they do so without the benefit of the BGP
Confederations feature.

This greying of the Service Provider administrative boundary is what I
believe is contributing toward your comment.

Given the above, do you have a preferred term you'd care to use?

(As an aside, PE isn't even consistently used across various large
providers.  Figuring out their preferred alphabet soup of acronyms for the
roles of their routers is always an interesting exercise.)

> This brings on a second comment that the document is not overly clear
> about the scope of intended application - the ability to declare filter
> rules per interface appears to assume a detailed level of device
> configuration that would only normally be accessible to a network
> management - so that the intended scope of this form of flowspec
> propagation is iBGP.  But the example in section 2 appears to say
> otherwise - the draft would benefit from some clarity over the intended
> (and safe) scope of propagation of such interface flowspecs.

As you may note above, there is some likelihood of the feature being used
within the scope of multiple ASes under the control of the same Service
Provider.

You might note that an AS# is part of the encoding.  This provides clarity
for the receiving router as to the semantics of the Group Identifier, which
will be defined by that AS's network.  I do note that the draft isn't
sufficiently descriptive about the use of that field.

> The third comment is that the draft is a mix of motivation for the desired
> mechanism, advocating the chosen solution, and the protocol mechanisms
> (extension to BGP extended community set). My own personal taste is to
> split this to a document about the need, and a seperate document about the
> protocol mechanism and the related IANA considerations.

Such motivational documents are not terribly common in IDR and I wouldn't
advocate for one.  But you do make good points later on that the discussion
of the flowspec distributed ACL case that makes use of the proposed
mechanism does muddle things.

> The fourth comment is that the section “Security Considerations” appears
> to also contain some critical design information that is conveniently
> ignored in the rest of the draft. A broader document about the general
> problem space and the strengths and weaknesses of various approaches to
> automated traffic filter management in devices (see previous comment)
> would be a better place to argue the relative merits of various forms of
> network automation vs the use of signalling within BGP. Previous schools
> of through were that flow spec signalling was an ideal approach to remote
> (inter-AS) RBH signalling, while various in-house forms of network
> management would be more approach to operate the local network. 

It is arguable that a better solution to your comment is to simply restrict
the considerations to the impact of this feature upon the existing RFC 5575
feature and its deployment.  The broader context of using BGP flowspec for
domain-wide ACL management, while being one of the use cases of the feature
described in this document, is not the sole motivation.

> This draft
> does not appear to to clearly state exactly what problem it is solving. If
> it is trying to perform remote filter management in Other Peoples Networks
> then there are huge security implications. The draft conveniently waves
> its hands about the group identifier and its intended interpretation. This
> is a large conceptual hole in the draft imho. The second part of this is
> also touched upon in a passing comment in the Security Considerations,
> that these filters are ephemeral in nature, as compared to a more
> ‘conventional’ network management tool that would maintain filters as
> configured elements in the device.

Given the comments above, I think I agree.  Our document should start by
describing the protocol mechanism and the gap that it is filling in the
current flow-spec ecosystem.  That gap being that flow-spec filters apply to
*all* interfaces in *all* directions, which may result in improper
filtering.  (Note that targeted BGP sessions with the routes set with the
NO_ADVERTISE community is one way this is mitigated in some deployments.)

> I think what is missing relates to the observation that sure, you CAN
> stuff this into BGP using extended communities, but SHOULD we do this?
> What are the reasons why this particular approach makes sense over and
> above other existing tools and approaches. If the role of this WG is to
> document everything we COULD do in BGP then the workload may well be
> infinite - if the role is to document what we SHOULD be specifying as a
> BGP-based tool then this would make more sense. As a result, I suspect
> that this draft could benefit from some operational perspectives. Does
> this materially help network operators in attempting to respond to DDOS
> attacks? Or is it just another tool in an environment already replete with
> various tools and technique and as such limited adoption would imply that
> it would be effectively unused by network operators.

The feature is operationally motivated.  In particular, this early review
was motivated by looking for a community assignment so that running code
could start getting deployed without squatting on an arbitrary code point.

And that said, one option open to the authors and implementors is simply
requesting first-come, first-served.  

We do appreciate the thorough review.  

> Obviously I am at this point unconvinced that it “makes sense” in the
> broader sense, and rather than trying to add more words to a single
> document it may be helpful to look at splitting the specification of the
> proposed mechanism and the IANA instructions and the discussion of why
> this particular approach to distributed filter management makes more sense
> than what current operational practices rely on.

We'll take that under consideration for the next revision.

-- Jeff