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

[Robert Raszuk <[e-mail]>]

Hi Jakob,

Let me try to understand the issue you are describing a bit better.

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.

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 - when new session comes 
up between RR and PE2. RR knows the same rtr_id/peer_ip (session got 
reestablished). I really can not imagine otherwise regardless of 
persistence timer value setting.

Labels are of local significance. They alone mean nothing without the 
next hop. So I fail to see the case you describe or for that matter 
described by security section that even transiently labels advertised 
with BGP NLRIs are going to cause harm or inter-VPN disturbance.

En-light me pls ! I want to see the ghost ;-)

Cheers,
R.


> On Wednesday, October 26, 2011 5:43 PM, Enke Chen<>  wrote:
>
>> Hi, folks:
>>
>> I have a hard time in understanding what new problems (beyond the GR)
>> the draft try to solve :-(
>
> Me too.
>
> The persisting routers will persistently send labeled packets
> into the core. If the intended destination really has disappeared,
> and restarted, what is the chance that such labeled packets
> interfere with other unrelated services, just because of labels
> being reused?
>
> Quote from 3.1 of the draft:
> The persist-timer
>        should be set to a large value on the order of days to infinity.
>
> Customers rely on the separation between VPN's. The "P" means private.
> Anything that threatens that "P" should not be taken lightly.
>
> I'm starting to imagine my video stream intrespersed with dzzt, zzt
> from random packets being injected into it. How real is that?
>