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

From: Geoff Huston <[email-masked]>
Date: Mon, 27 Feb 2017 14:02:05 +1100

Hi,

I have been assigned the QA reviewer for this draft. there appears to be no formal template for this review, but the general guidelines at https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa state:

  "When reviewing a draft at WG Adoption, the QA Reviewer should determine whether the draft is readable, understandable, makes sense and is a good start for a WG draft. Any issues the QA Reviewer finds are written down, sent to the mailing list and discussed for future versions"

So here are mo responses to these questions fter reviewing this draft:

** Is the draft readable? 

yes

** Is the draft understandable? 

yes, provided the reader takes to time to familiarise themselves with the BGP flowspec structure and operation in the first place. At least I think it is understandable - if the authors believe that I have misinterpreted the intent of this draft then that may be a very clear signal that it was less understandable than I thought!

** Does it make sense?

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.

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.

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.

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. 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.

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.

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.

regards,

   Geoff

> On 24 Feb 2017, at 3:40 pm, Yemin (Amy) <[email-masked]> wrote:
> 
> Hi Geoff,
>  
> Please would you be the routing directorate QA reviewer for draft-ietf-idr-flowspec-interfaceset
> 
> https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/
> 
> Note that this is a “QA review.” The document does not yet have consensus to be forwarded to the IESG. The goal of this review is to provide a new perspective on the work in progress and to improve its quality. Hence, your comments will be provided primarily for the benefit of the IDR chairs and the document authors.
> Please could you provide your comments by March, 9th, 2017? You should send your comments to the draft authors and WG chairs, and copy the relevant WG mailing list and the rtg-dir list.
> The following web page contains a briefing on the QA process, and guidance for the QA reviewer.
> https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa
> 
> Please let me know if you can do it, or not.
> 
> Many thanks
> Amy
> 
>  
>  
> This e-mail and its attachments contain confidential information from HUAWEI, which 
> is intended only for the person or entity whose address is listed above. Any use of the 
> information contained herein in any way (including, but not limited to, total or partial 
> disclosure, reproduction, or dissemination) by persons other than the intended 
> recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
> phone or email immediately and delete it!

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 28 Feb 2017 16:44:46 -0500

Geoff,

Thank you for your comments.

On Mon, Feb 27, 2017 at 02:02:05PM +1100, Geoff Huston wrote:
> 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