Re: [Idr] AD Review of draft-ietf-idr-bgp-flowspec-oid-12

[Alvaro Retana <[e-mail]>]

On March 15, 2021 at 8:32:06 PM, Juan Alcaide wrote:


Juan:

> For my dismay, I realized I only had gotten part of your email (till review
> line 118). I think a weird problem with my email server. It was more in-deep
> review that I thought.

Yeah...there seems to be an issue with long messages and Outlook (as
far as I can see): the messages are truncated.  The IETF archive
always gets the whole message.  I have also been including an "[End of
Review]" signal. :-)


> My changes will reflect more or less your suggestions.

Ok -- I'll take a look at the details when you post -13.


> Before, I have some contentious points I’d like to raise:
>
> Any alternative naming to ‘ingress border routers’ ? They are just the
> routers receiving traffic and far away from FS peering

Right -- that is what is confusing: these routers are not at the
border or are ingress routers.

I don't have a better suggestion.  The name is used only 3 times, so
perhaps the simply describe where they are...


> Around line 311...

[It is better if you reply in-line...so we make sure we're both
talking about the same thing. ;-)]

> ...you mention a new security hole because of the new AS_PATH validation rule.
> You are referring to the case of a route-server, right? Let’s say
> AS1—(route-server)—AS2. AS1, instead of AS_PATH = 1, could send us AS_PATH =
> 100 for the -rogue - FS route. The best-match unicast route could be actually
> coming from another route-server client om AS 100 (that is sending -correctly
> -the unicast route with AS_PATH=100)

This is what I wrote:

====
306	      Redefinition of this AS_PATH validation rule for a Flow
307	      Specification does not mean that the original rule in [I-D.ietf-
308	      idr-rfc5575bis] cannot be enforced as well.  Its enforcement
309	      remains optional per [RFC4271] section 6.3.  That is, we can
310	      enforce the first AS in the AS_PATH to be the same as the neighbor
311	      AS for any address-family route (including a Flow Specification).

[major] Both rfc5575 and rfc8955 mentioned that the enforcement is
required "for security reasons".  I'm sure the question will come up
about the potential security holes that are now opened if the
enforcement is not performed.  Please add (preferably in the Security
Considerations section) text including any recommendations on when the
enforcement can/should be performed.

For the general eBGP case, for example, there is the possibility that
the left-most ASN matches for both the FS/unicast routes, but that it
doesn't correspond to the peer AS.  I believe this is a case where an
additional vulnerability is introduced --- but also one that can be
mitigated by recommending/requiring the enforcement in this type of
cases (with appropriate caveats).
====

Yes. The route-server case is a subcase of the "general eBGP case".


> Around line 322, you mention we could use the new AS_PATH check for
> eBGP-confed routes as well. If we did, then we should also extend it for iBGP
> peers. But I don’t see much of a point to it, as long as we do the right
> check of the eBGP received routes any further check is redundant. Same
> concept that checking on AS_PATH loops only for eBGP received routes.

===
318	      Using the new rule to validate a Flow Specification route received
319	      from an External Border Gateway Protocol (eBGP) peer belonging to
320	      the same local domain (in the case that the local AS belongs to a
321	      confederation of ASes) is out of the scope of this document.  Note
322	      that although it's possible, its utility is dubious.

...
[minor] Why can't the same check be applied?  The text above doesn't
talk about segments so it should be able to apply.

[minor] As for the value, you seem to be assuming that just because
the confederation is in the same administrative domain than there
won't be configuration errors or rogue routers.  I believe that is a
dangerous assumption.
===

The "normal" iBGP case is different than the confederation case where
we do find an eBGP relationship.



> Around line 324, you mention we should suppress ‘Other RFC5575bis
> Considerations.’. This section had more points that were trimmed when
> rfc8995 included those points. Only references left are about 2byte AS old
> speakers. Not sure if those references were ever considered for rfc8995. I
> guess the meaning of AS_PATH could be inferred w/o these references. rfc8955
> already seems to infer them (although it is basically a copy of the old
> rfc4271 rule). Is it assumed that the meaning of AS_PATH is also inferred for
> any rfc after rfc6793?

In short, yes.  rfc6793 formally Updated rfc4271, so any
interpretation of the AS_PATH has to consider what rfc6793 says.




> In the security section, you mention ‘ibgp are not trusted’. That’s strictly
> true, but in the sense of rfc8955 it would seem they are (rfc8955 is only
> concerned about trust for eBGP peerings). I can add a note, but is anything
> else is required?

====
412	   BGP updates learned from iBGP peers are trusted so the Traffic Flow
413	   Specifications contained in BGP updates are trusted.  Therefore it is
414	   not required to validate that the originator of an intra-domain
415	   Traffic Flow Specification matches the originator of the best-match
416	   unicast route for the flow destination prefix.  This proposal
417	   continues to enforce the validation Procedure for eBGP learned
418	   Traffic Flow Specifications, as per [I-D.ietf-idr-rfc5575bis] rules.
419	   In this way, the security properties of [I-D.ietf-idr-rfc5575bis] are
420	   maintained such that an EBGP peer cannot cause a denial-of-service
421	   attack by advertising an inter-domain Flow Specification for a
422	   destination prefix that it does not provide reachability information
423	   for.

[major] "iBGP peers are trusted"   This is a flawed assumption because
it doesn't take into account the possibility of a rogue iBGP speaker.
Consider the case where an attacker takes control of a router and
creates (or limits) Flow Specifications -- not checking would open the
network up to any router becoming an attack point.

Yes, I understand that this is not a new vulnerability introduced in
this draft.  However, the type of risk (creating a Flow Specification)
is new to this work and a direct result.

Because the origin check won't happen for iBGP, you should mention the
risk clearly.
====

As you mention, rfc8955 considers eBGP.  The fact that it doesn't say
anything about iBGP shouldn't be interpreted as trusting those peers.
Even if that was the intent in rfc8955, this document deals directly
with iBGP so it makes it the best place to call the risk out.


Thanks!

Alvaro.