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

[Susan Hares <[e-mail]>]

Robert.  

 

Good point on the RRs.   We should leave the text as is.

 

I sent a higher level question to determine what Ben is concerned about. 

 

Sue

 

From: Idr [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Thursday, April 23, 2020 10:53 AM
To: Christoph Loibl
Cc: [e-mail]; [e-mail]; idr@ietf. org; Benjamin Kaduk; The IESG
Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-rfc5575bis-22: (with DISCUSS and COMMENT)

 

 

That suggestion is not right. 

 

They can be received via RRs etc ... 

 

I think the text is fine as is. I think Benjamin perhaps thought that validation happens on ingress to the router. I am not sure if we want to highlight the real meaning - I think it is already described in other sections. 

 

Thx,

R.

 

 

On Thu, Apr 23, 2020 at 10:53 AM Christoph Loibl <[e-mail]> wrote:

Hi Benjamin,

Thanks for your review. I opened cases for all of the issues you raised in the github repo:

        https://github.com/stoffi92/rfc5575bis

The discuss item you raised is this:

        https://github.com/stoffi92/rfc5575bis/issues/184

To resolve this I suggest the following change to the document:

I suggest to change it to the following (I hope that Robert and Sue can also have a look if this is still correct to the desired behaviour):

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

   The validation procedure (Section 6) and Traffic Filtering Actions
   (Section 7) are the same as for IPv4.

NEW:
   Contrary to the behavior specified for the non-VPN NLRI, Flow
   Specifications are accepted by default, when received from remote PE
   routers. The validation procedure (Section 6) when Flow Specifications
   are received from a remote CE are the same as for IPv4. 

   Traffic Filtering Actions (Section 7) are the same as for IPv4..


Cheers Christoph

-- 
Christoph Loibl
[e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at



> On 23.04.2020, at 02:42, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> 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