Re: [Idr] draft-uttaro-idr-bgp-persistence-00: Security Considerations

Eric,

> If PE1 happens to have noticed that PE2 blinked out, it may be wise for PE1
> to invalidate the routes for which PE2 is the next hop.  If PE1 did not
> notice that PE2 blinked out, it will continue to make use PE2's old VPN-IP
> routes.

So when RR is down PE2's BGP process restarts while IGP not - PE1 has no 
chance to notice any next hop blink - hence till RR comes up and cleans 
up the mess pretty much network is in a bad state.

How long RR will wait after coming up to get his previous IBGP peering 
reestablished before starting the cleanup ?

Thx,
R.

>> If we have a below scenario:
>>
>>            / PE2
>> PE1 -- RR
>>            \ PE3
>
>> When PE2 disappears RR will re-advertise his routes as persistent to PE1
>> with some labels - for simplicity let's assume those are L3VPN labels.
>
> In the case being discussed (I think), the RR is down at the time PE2
> disappears, but PE1 is still using the routes previously distributed to it
> by the RR.
>
>> There are two options ...
>
>> * PE2 went down for good - RR by advertising persistent routes may at
>> most cause to blackhole the traffic - that is why I started by
>> recommending a MUST for next hop reachability
>
>> * PE2 restarted - here I assume RR would withdraw previous STALE routes
>> by both implicit withdraw and explicit withdraw
>
> The RR can't withdraw any routes because it is down.
>
> If PE1 happens to have noticed that PE2 blinked out, it may be wise for PE1
> to invalidate the routes for which PE2 is the next hop.  If PE1 did not
> notice that PE2 blinked out, it will continue to make use PE2's old VPN-IP
> routes.  Unfortunately, all these routes will now have incorrect labels, and
> packets from one VPN may get forwarded by PE2 to another VPN.
>
> As far as I can tell, until the RR comes back up, there is no assurance that
> PE1 will notice PE2's restart, so random cross-connection of VPNs is
> certainly possible.
>
> But it's not obvious that random cross-connections of this sort are any
> worse than a complete loss of service.  While datagrams from one VPN might
> get sprayed into the other, it is hard to see how a TCP connection between
> the two VPNs could be set up or maintained, since there is not going to be a
> working reverse path.
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>