Thanks! That sounds good to me! > Am 16.01.2019 um 07:49 schrieb Rabadan, Jorge (Nokia - US/Mountain View) > <[email protected]>: > > Hi Mirja and Luc, > > Mirja, I added this in the security section: > > "...This behavior could be exploited by an attacker that manages to modify > the configuration of one PE in the Ethernet Segment so that the DF Election > Alg and capabilities in all the PEs in the Ethernet Segment fall back to the > Default DF Election. If that is the case, the PEs will be exposed to the > unfair load-balancing, service disruption and black-holing that were > mentioned earlier." > > Other than that I agree with Luc that the injection of a malicious route type > 4 in the network is not specific to this document, so I think we should be ok > since we are also referring to the security considerations in RFC7432. > > Thanks. > Jorge > > > -----Original Message----- > From: "Luc Andre Burdet (lburdet)" <[email protected]> > Date: Tuesday, January 15, 2019 at 5:29 PM > To: "Mirja Kuehlewind (IETF)" <[email protected]>, "Rabadan, Jorge (Nokia - > US/Mountain View)" <[email protected]> > Cc: Stephane Litkowski <[email protected]>, > "[email protected]" <[email protected]>, The IESG <[email protected]>, > "[email protected]" <[email protected]>, > "[email protected]" > <[email protected]> > Subject: Re: [bess] Mirja Kühlewind's No Objection on > draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT) > > That's an interesting point Mirja. > > A rogue PE/agent could foreseeably inject via BGP an ES Route Type 4 with > no DF Alg extended community and "bring down" a peering group to the default > DF election (common denominator). Repetitive inject-delete could cause > considerable churn and disruption as the target peers repetitively accept, > and remove this rogue PE/nexthop from the forwarding determination and > flip-flop DF Alg. > > The only way to prevent this, would be for the "federation of peers" to > (independently) come to a unanimous conclusion to accept, or reject, this new > peer into their peering group (based on.. peer's reputation? Or?) In the end, > however, ...this also applies to 7432 as-is with default algorithm. > The net effect of such an attack would be no different than RFC7432 where > a rogue PE injecting/deleting itself (its nexthop) from the DF election is > causing churn and disruption. > > The other attack vector is not new to this draft, but from 7432. A rogue > PE with knowledge of the {VLAN/VPN, ESI and peers-list} can conceivably > advertise in BGP the correct IP/nexthop value, leveraging the default DF Alg > to steer/attract VPN traffic towards himself. But this is a 7432 attack > vector, not new/introduced by this draft. > > I think if the draft reflects similar to 7432 (peers must be consistently > configured), then parallels to the security aspect of 7432 are sufficient? > > Thanks, > > Luc André Burdet > [email protected] > Tel: +1 613 254 4814 > Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE > Cisco.com <http://www.cisco.com/web/CA/> > > > On 2019-01-15, 10:57, "BESS on behalf of Mirja Kuehlewind (IETF)" > <[email protected] on behalf of [email protected]> wrote: > > Hi Jorge, > > thanks! I guess the security consideration could say even more, e.g. > that this behavior could be exploited by an attack that relies on the default > mechanism. And is there anyway to hinder this attack? That should be > discussed as well. > > Mirja > > > >> Am 15.01.2019 um 16:49 schrieb Rabadan, Jorge (Nokia - US/Mountain View) >> <[email protected]>: >> >> Mirja, >> >> Thank you very much for reviewing. >> Please see in-line with [JORGE]. >> Thx >> Jorge >> >> -----Original Message----- >> From: Mirja Kühlewind <[email protected]> >> Date: Thursday, January 10, 2019 at 12:16 PM >> To: The IESG <[email protected]> >> Cc: "[email protected]" >> <[email protected]>, Stephane Litkowski >> <[email protected]>, "[email protected]" >> <[email protected]>, "[email protected]" >> <[email protected]>, "[email protected]" <[email protected]> >> Subject: Mirja Kühlewind's No Objection on >> draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT) >> Resent-From: <[email protected]> >> Resent-To: <[email protected]>, <[email protected]>, >> <[email protected]>, <[email protected]>, <[email protected]>, >> <[email protected]> >> Resent-Date: Thursday, January 10, 2019 at 12:16 PM >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-bess-evpn-df-election-framework-07: No Objection >> >> 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-bess-evpn-df-election-framework/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> First one minor editorial comment: >> Sec 3.2 "Otherwise if even a single advertisement for the type-4 route is >> not received with the locally configured DF Alg and capability, >> the Default DF Election algorithm (modulus) algorithm MUST be >> used as in [RFC7432]." >> I believe you meant a single advertisement is received without the >> configured >> DF Alg and capability (or a different one I guess), and not that the >> advertisement is not received at all (because that might be hard to check), >> right? Maybe you can rephrase this sentence a bit to make the intention >> more >> clear! >> [JORGE] we changed it to the following: >> " - Otherwise if even a single advertisement for the type-4 route is >> received without the locally configured DF Alg and capability, the Default >> DF Election..." >> >> However, think about this further, I wondering if there is something here >> that >> such be discussed in the security considerations, e.g. how easy would it >> be for >> an attacker to disturb the algo selection and cause a fallback to the >> default >> scheme...? >> [JORGE] yep, good point. We added this in the security section, also based >> on the comments from another reviewer: >> "Note that the network will not benefit of the new procedures if the DF >> Election Alg is not consistently configured on all the PEs in the ES (if >> there is no unanimity among all the PEs, the DF Election Alg falls back to >> the Default [RFC7432] DF Election)." >> >> >> >> >> >> > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
