Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT)

[Susan Hares <[e-mail]>]

Ben:

First of all thank you for your detailed review.   

We really appreciate this detailed review during a revision of a deployed
protocol. 
Christoph has added each of your comments to the github repository for this
draft. 


Two clarifying questions that need pulling out besides your DISCUSS. 
(see Robert's comment on the RR implication on the DISCUSS). 
I'm pulling these to the front for ease of responding to the 

Section 12: 
Your comment: 
I'd consider mentioning again that some of the NRLI components won't work
properly on fragmented traffic and that unexpected fragmentation can cause
DoS.  (This is particularly relevant for IPv4, as opposed to IPv6, where
fragmentation can occur anywhere on the path.)
--------
Clarifying questions: 
The RFC5575bis (and RFC5575) is simply providing filters for a firewall
function. 
Is there an RFC that suggestions the appropriate cautions for firewall
filters.? 
If so, could we mention that people implementing RFC5575bis should 
simply be aware of BCPs regarding firewalls regarding DoS? 

Your comment: 
Is it worth saying anything about how the RT-redirect actions can direct
traffic to an entity not expecting it (and, as such, potentially DoS them)?

Clarifying question 
Redirect also occurs with the firewalls?  
RFC5575bis is simply enabling that function with multicast of the 
Filter prefixes.   Is there a BCP regarding firewalls that use redirect?    

I have been trying to monitor the new threats discussion. 

Your comment: 
:It also struck me as noteworthy that we're letting DSCP values creep out of
a single administrative scope -- the filtering of inbound DSCP markings
should probably be consistent with the traffic markings advertised to that
peer." 

The DSCP markings seem to cross boundaries with MPLS. 
If there is a BCP regarding DSCP marking, should we reference this as well? 


Thank you for your careful review. 

Susan Hares 


-----Original Message-----
From: Idr [mailto:[e-mail]] On Behalf Of Benjamin Kaduk via
Datatracker
Sent: Wednesday, April 22, 2020 8:42 PM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22:
(with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-idr-rfc5575bis-22: Discuss

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There might be a minor internal inconsistency to tidy up (or I might be
misunderstanding things).  Section 8 states that:

   Contrary to the behavior specified for the non-VPN NLRI, Flow
   Specifications are accepted by default, when received from remote PE
   routers.

As far as I can tell, this is referring to the text in Section 6 where (for
the non-VPN case) "By default a Flow Specification NLRI MUST be validated
such that it is considered feasible if and only if all of the below is true
[...]".  But immediately following what I quote above is a statement that
"the validation proceure (section 6) [...] [is] the same as for IPv4", which
seems to be in conflict with this statement ("contrary to" vs. "the same
as").


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The Abstract is perhaps pushing the length limits appropriate for an
Abstract (vs. Introduction).

Abstract

   Additionally, it defines two applications of that encoding format:
   one that can be used to automate inter-domain coordination of traffic
   filtering, such as what is required in order to mitigate
   (distributed) denial-of-service attacks, and a second application to

This makes me think of the DOTS WG (but it's far from clear that we should
reference it in this text).

Section 1

   This document obsoletes "Dissemination of Flow Specification Rules"
   [RFC5575], the differences can be found in Appendix B.  This document

nit: comma splice

   A Flow Specification received from an external autonomous system will
   need to be validated against unicast routing before being accepted
   (Section 6).  The Flow Specification received from an internal BGP
   peer within the same autonomous system [RFC4271] is assumed to have
   been validated prior to transmission within the internal BGP (iBGP)
   mesh of an autonomous system.  If the aggregate traffic flow defined

(Just to check, there's no particular harm in also validating iBGP
flowspecs, just the extra computation burden of doing so, right?)

   systems that are able to detect malicious traffic flows.  When
   automated systems are used, care should be taken to ensure their
   correctness as well as the limitations of the systems that receive
   and process the advertised Flow Specifications (see also Section 12).

This seems to discuss making sure that the recipients of automated
information handle it robustly; is it also worth some considerations on
robustness of generating such automated information (something akin to a
circuit breaker that would shut off the source if it started producing
nonsensical output)?
Also, nit: I think I parse this as "care should be taken to ensure [...] the
limitations of the systems that receive and process [flowspecs]", which
doesn't quite seem like what was intended.

Section 4

   The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
   one or more 2-tuples of the form <length, NLRI value>.  It consists
   of a 1- or 2-octet length field followed by a variable-length NLRI
   value.  The length is expressed in octets.

RFC 4760 only shows the one-octet length form; is there a good reference for
the 2-octet length?  (Or is it "new" with 5575?)

Section 4.2

I think we should say something about how multi-byte values are encoded,
especially given that we implicitly allow for different encodings of a given
value (e.g., IP protocol could have padding, and small port numbers don't
need to be encoded in 2 bytes).  Even just making it more explicit that
multiple encodings are allowed (and what the semantics are for any such
"padding") would be worthwhile.  Is there a maximum encoded length for
anything other than the constraints of the 2-bit 'len' field?
Interestingly, for DCSP we are much more strict -- why is the strictness
needed there but not in general?  Is this just to faithfully reproduce RFC
5575, as implied by the discussion in Appendix B?
(I would make this a DISCUSS point if I didn't think that we're acting as if
we're required to preserve the RFC 5575 behavior.)

   A NLRI value not encoded as specified in Section 4.2 is considered

This *is* Section 4.2; perhaps "specified here" or "specified below"?

Section 4.2.1.1, 4.2.1.2

While I don't anticipate needing a future extension to numeric_op, having
the '0' field only be "SHOULD be set to 0" (vs. "MUST") seems to hamper any
future extensibility efforts.
(Similarly for the "Traffic-action" field in Section 7.3, and
"Traffic-marking" from Section 7.5.)

Section 4.2.2.3

   This component uses the Numeric Operator (numeric_op) described in
   Section 4.2.1.1.  Type 3 component values SHOULD be encoded as single
   octet (numeric_op len=00).

Is it well-defined how I would encode the value if I ignored the SHOULD?
I, for one, am not sure what I would do...

Section 4.2.2.4, etc.

(I agree with my esteemed colleagues that hardcoding TCP and UDP as "the
only protocols with ports" is unnecessary.)

   system is unable to locate the transport header.  Different
   implementations may or may not be able to decode the transport header
   in the presence of IP options or Encapsulating Security Payload (ESP)
   NULL [RFC4303] encryption.

If an implementation cannot decode the transport header does it treat all
such packets as matching or not matching?

Section 4.2.2.7

   In case of the presence of the ICMP type (code) component only ICMP
   packets can match the entire Flow Specification.  The ICMP type

I'm not sure why the parenthetical is needed given that there's a separate
NRLI type for "ICMP code".

Section 5.1

   component type.  If the component types are the same, then a type-
   specific comparison is performed (see below) if the types are equal
   the algorithm continues with the next component.

nit: there seems to be some missing punctuation or conjunction here.

   For all other component types, unless otherwise specified, the
   comparison is performed by comparing the component data as a binary
   string using the memcmp() function as defined by [ISO_IEC_9899].  For
   strings with equal lengths the lowest string (memcmp) has higher
   precedence.  For strings of different lengths, the common prefix is
   compared.  If the common prefix is not equal the string with the
   lowest prefix has higher precedence.  If the common prefix is equal,
   the longest string is considered to have higher precedence than the
   shorter one.

It is surprising to me that the comparison operator can return "not-equal"
for different encodings of a quantity that have the same semantic value (viz
my previous note about encoding flexibility).  That said, this procedure is
well-defined and BGP speakers are not going to be re-encoding the NRLI
values as they propagate, so I don't see an interop problem.

Section 6

   By default a Flow Specification NLRI MUST be validated such that it
   is considered feasible if and only if all of the below is true:

Perhaps "in the absence of explicit configuration otherwise," to more
closely parallel the other case?

   BGP implementations MUST also enforce that the AS_PATH attribute of a
   route received via the External Border Gateway Protocol (eBGP)
   contains the neighboring AS in the left-most position of the AS_PATH
   attribute.  While this rule is optional in the BGP specification, it
   becomes necessary to enforce it for security reasons.

nit: missing word (e.g., "necessary to enforce it here" or "necessary to
enforce it in processing flow specifications").

   The best-match unicast route may change over the time independently
   of the Flow Specification NLRI.  Therefore, a revalidation of the
   Flow Specification NLRI MUST be performed whenever unicast routes
   change.  Revalidation is defined as retesting that clause a and
   clause b above are true.

IMPORTANT: Why does clause c not need to be retested?

   The neighboring AS is the immediate destination of the traffic
   described by the Flow Specification.  If it requests these flows to
   be dropped, that request can be honored without concern that it
   represents a denial of service in itself.  Supposedly, the traffic is
   being dropped by the downstream autonomous system, and there is no
   added value in carrying the traffic to it.

(This presumes that there is some integrity protection applied to the
received data, which might be worth making more explicit.) Also, nit: I'd
suggest s/Supposedly,/The reasoning is that this is as if/

Section 7

Please be consistent about "ASN" vs. "AS" in Table 2.

Should the "traffic-action" and "traffic-marking" actions list the encoded
length for the reader's convenience?

Section 7.1

   The remaining 4 octets carry the maximum rate information in IEEE
   floating point [IEEE.754.1985] format, units being bytes per second.

Thank you for being clear about the units!

Section 7.2

Is there anything to say about what time interval a non-integer packet rate
should be evaluated over?

Section 7.3

   o  T: Terminal Action (bit 47): When this bit is set, the traffic
      filtering engine will evaluate any subsequent Flow Specifications
      (as defined by the ordering procedure Section 5.1).  If not set,
      the evaluation of the traffic filters stops when this Flow
      Specification is evaluated.

Just to check I'm reading this right: when the "terminal action" bit is set
to one, it is *not* the terminal action, and the action *is* the terminal
action when the "terminal action" bit is set to zero?  That sounds backwards
to my intuition (and maybe others'?).

Section 7.4

   Interferes with: No other BGP Flow Specification Traffic Filtering
   Action in this document.

Do the different possible 'type's for this 'sub-type' interfere with each
other?

Section 7.6

   Implementations should provide mechanisms that map an arbitrary BGP
   community value (normal or extended) to Traffic Filtering Actions
   that require different mappings in different systems in the network.

nit(?): to my eye this reads better as "on different systems" (vs. "in").

   For instance, providing packets with a worse-than-best-effort, per-
   hop behavior is a functionality that is likely to be implemented

nit: no comma after worst-than-best-effort.

Section 7.7

   other (e.g. there may be more than one conflicting traffic-rate-bytes
   Traffic Filtering Action associated with a single Flow
   Specification).  Traffic Filtering Action interference has no impact

Maybe we should revise the earlier text about "Interferes with: No other
[...]" to be explicit that it *does* self-interfere.

   behaviour (ie. match - replace - delete communities on administrative
   boundaries).  See also Section 12.

nit: could this parenthetical be expanded a little bit more?  I feel like
it's expected to be common knowledge among the main readership and so the
current wording just serves as a trigger for this "well-known" (but not to
me) concept, as opposed to standing on its own.

Section 8

[side note: I'd love for us to eventually stop using "VPN" for things that
don't encrypt the data passing over them.  This doesn't seem like the right
place to start, though.]

Section 9

Should either/both of these mechanisms be on or off by default?

Section 12

I'd consider mentioning again that some of the NRLI components won't work
properly on fragmented traffic and that unexpected fragmentation can cause
DoS.  (This is particularly relevant for IPv4, as opposed to IPv6, where
fragmentation can occur anywhere on the path.)

Is it worth saying anything about how the RT-redirect actions can direct
traffic to an entity not expecting it (and, as such, potentially DoS them)?

It also struck me as noteworthy that we're letting DSCP values creep out of
a single administrative scope -- the filtering of inbound DSCP markings
should probably be consistent with the traffic markings advertised to that
peer.  (There is perhaps also some "information leakage" as to what
semantics are assigned to given DSCP values within the network in question,
but I find it hard to get too worked up about that, especially since the
inter-AS relationship is inherently pretty trusted.)

   As long as Flow Specifications are restricted to match the
   corresponding unicast routing paths for the relevant prefixes
   (Section 6), the security characteristics of this proposal are

[There's an implicit "and both are received over trustworthy channels" in
here.  Perhaps it's okay to remain implicit, given how well-known BGP's
security properties are...]

   Where the above mechanisms are not in place, this could open the door
   to further denial-of-service attacks such as unwanted traffic
   filtering, remarking or redirection.

nit(?): I might just say "In particular, relaxing the validation procedure
could [...]".

   additional filtering.  For example, the use of [RFC6811] to enhance
   filtering within an AS confederation.

nit: incomplete sentence.

   Inter-provider routing is based on a web of trust.  Neighboring
   autonomous systems are trusted to advertise valid reachability
   information.  If this trust model is violated, a neighboring
   autonomous system may cause a denial-of-service attack by advertising
   reachability information for a given prefix for which it does not

I guess it's also a well-known attack that malicious neighbor could also
draw traffic to itself for snooping purposes without actually dropping the
traffic.  But I'm not sure if there are any flowspec-specific considerations
relating to that scenario.

   provide service (unfiltered address space hijack).  Since validation
   of the Flow Specification is tied to the announcement of the best
   unicast route, this may also cause this validation to fail and
   consequently prevent Flow Specifications from being accepted by a
   peer.  Possible mitigations are [RFC6811] and [RFC8205].

nit: there's a lot of pronouns ("this") in here; it might be worth
disambiguating a couple.

   Flow Specification BGP speakers (e.g. automated DDoS controllers) not
   properly programmed, algorithms that are not performing as expected,
   or simply rogue systems may announce unintended Flow Specifications,
   send updates at a high rate or generate a high number of Flow
   Specifications.  This may stress the receiving systems, exceed their
   maximum capacity or may lead to unwanted Traffic Filtering Actions
   being applied to flows.

Is there any relevant guidance to give to receiving systems?

Appendix A

I don't know that just this one function is useful without some description
of what format of input it requires.  For example, if a.components and/or
b.components have elements that evaluate to "false", the first two checks
could return incorrect results (the perhaps-more-obvious case where both
comp_a and comp_b are None cannot happen due to the nature of zip_longest).

Appendix B

      Section 7 defines all Traffic Filtering Action Extended
      communities as transitive extended communities.  [RFC5575] defined
      the traffic-rate action to be non-transitive and did not define
      the transitivity of the other Traffic Filtering Action communities
      at all.

I assume the consequences of changing a community from non-transitive to
transitive are well-known (but not to me) and that any operational
considerations for mixed deployments are already stated somewhere prominent
to someone working with BGP.  (Where is that?)

      Section 7.7 contains general considerations on interfering traffic
      actions.  Section 7.3 also cross-references this section.

nit(?): the last "this section" refers to 7.7, not the location of the text
I'm quoting from (Appendix B).  I misread it the first time.



_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr