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
lbur...@cisco.com
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)" 
<bess-boun...@ietf.org on behalf of i...@kuehlewind.net> 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) 
<jorge.raba...@nokia.com>:
    > 
    > Mirja,
    > 
    > Thank you very much for reviewing.
    > Please see in-line with [JORGE].
    > Thx
    > Jorge
    > 
    > -----Original Message-----
    > From: Mirja Kühlewind <i...@kuehlewind.net>
    > Date: Thursday, January 10, 2019 at 12:16 PM
    > To: The IESG <i...@ietf.org>
    > Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" 
<draft-ietf-bess-evpn-df-election-framew...@ietf.org>, Stephane Litkowski 
<stephane.litkow...@orange.com>, "bess-cha...@ietf.org" <bess-cha...@ietf.org>, 
"stephane.litkow...@orange.com" <stephane.litkow...@orange.com>, 
"bess@ietf.org" <bess@ietf.org>
    > Subject: Mirja Kühlewind's No Objection on 
draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
    > Resent-From: <alias-boun...@ietf.org>
    > Resent-To: <jorge.raba...@nokia.com>, <satya...@cisco.com>, 
<saja...@cisco.com>, <jdr...@juniper.net>, <kiran.naga...@nokia.com>, 
<senthil.sathap...@nokia.com>
    > 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
    BESS@ietf.org
    https://www.ietf.org/mailman/listinfo/bess
    

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to