Thanks! That sounds good to me!

> Am 16.01.2019 um 07:49 schrieb Rabadan, Jorge (Nokia - US/Mountain View) 
> <jorge.raba...@nokia.com>:
> 
> 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)" <lbur...@cisco.com>
> Date: Tuesday, January 15, 2019 at 5:29 PM
> To: "Mirja Kuehlewind (IETF)" <i...@kuehlewind.net>, "Rabadan, Jorge (Nokia - 
> US/Mountain View)" <jorge.raba...@nokia.com>
> Cc: Stephane Litkowski <stephane.litkow...@orange.com>, 
> "bess-cha...@ietf.org" <bess-cha...@ietf.org>, The IESG <i...@ietf.org>, 
> "bess@ietf.org" <bess@ietf.org>, 
> "draft-ietf-bess-evpn-df-election-framew...@ietf.org" 
> <draft-ietf-bess-evpn-df-election-framew...@ietf.org>
> 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
>    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