Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

[Robert Raszuk <[e-mail]>]

> to the offended ORF(identified by RT).

That is not what the draft says. The draft says that you always filter on
RD and in some cases on RD+RT.

So please do not change the facts as those facts are fundamental to
accepting or rejecting this draft.

Rgs,
R.





On Thu, Feb 24, 2022 at 3:22 AM Aijun Wang <[e-mail]>
wrote:

> Hi, Nick:
> Let's state more clearly the reasonable trigger mechanism for VPN Prefix
> ORF message.
> We should know the initial aim is to position the abnormal behavior of the
> VRF on one PE.
> Then when the VPN routes in one VRF on one PE exceeds the threshold, this
> PE can calculate which VRF(identified by the source RD) on which
> PE(identified by the source PE) contribute or led to the overflow(based on
> each VRF's prefix limit), then send the VPN Prefix ORF message to RR, let
> RR filter the BGP Updates to the offended ORF(identified by RT).
> The information from other PEs, or from other VRFs on the offending PE, or
> to other VRFs on the offended PE will not be influenced.
>
> Does the above explanations work for you(also for other experts that have
> similar concerns)? If so, we can add it into the document.
>
> And, to Gert:
> In order to reduce the meaningless mail exchange, would you like to point
> out exactly what other technical concerns you have still?
> The mechanism may not be easily understood. But if the reader/experts
> follow the discussion closely before they make comments or jump into some
> conclusion directly, we can converge to the key points more quickly.
>
> Then back to Nick's example:
> If the malicious actor send the enough routes on its connected
> PE(offending PE) via one of the VRF(offending ORF) on this PE, and let the
> VRFs(offended VRFs) on other PEs(offended PEs) overflowed.
> Then, we can say the offending VRF is in bad behavior, right?
> Based on the above described behavior on the offended PE, such VRF/Source
> PE can be identified. Then the VPN Prefix ORF message is sent to the RR. RR
> will then filter the BGP updates to the offended VRF on the offended PE.
> So, contrary to your statement, such mechanism filter exactly the source
> that injects the most routes. Right?
>
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
> -----Original Message-----
> From: Nick Hilliard <[e-mail]>
> Sent: Thursday, February 24, 2022 2:45 AM
> To: Aijun Wang <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call
> (2/4/2022 to 2/18/2022)
>
> Aijun Wang wrote on 18/02/2022 23:30:
> > The main advantages of VPN Prefixes ORF mechanism is that it abates
> > the side effect of overwhelming information, and also gives clues to
> > operator to find the root causes of the abnormal results.
>
> Can I make a suggestion for the security section? Consider a malicious
> actor connected to one of the PE devices in the networks in figures 1, 2 or
> 3.  They can monitor how many routes come from each source.  If they have
> knowledge of the VPN infrastructure and know that the number of prefixes is
> close to the limit, they may be able to cause service disruption for other
> parties on the network by injecting enough routes to their PE to bring the
> VPN device which the largest number of prefixes over the limits specified
> in the draft for triggering prefixe removal, while ensuring that they
> aren't the party that injects the most routes.
>
> In other words, there are situations where this proposal can be gamed by
> malicious actors to kick other parties off a VPN.
>
> Nick
>
>