Re: [Idr] Rtgdir telechat review of draft-ietf-idr-bgp-gr-notification-15

[John Scudder <[e-mail]>]

Hi Bruno,

I have a -16 in preparation that takes in the various nits you raised, including removal of the sentence with reference to RFC 4486 (I always like it when I can take something out and make the document better. :-) With respect to the security section I think we came to the conclusion to leave well enough alone. That leaves me with one unresolved comment:

> On Apr 17, 2018, at 3:06 PM, John G. Scudder <[e-mail]> wrote:
> 
>> "If the "N" bit has not been exchanged with the peer, then to
>>       deal with possible consecutive restarts, a route (from the peer)
>>       previously marked as stale MUST be deleted."
>> [...]
>> "To put an upper bound on the amount of time a router retains the
>>       stale routes, an implementation MUST support a (configurable)
>>       timer, called the "stale timer", that imposes this upper bound."
>> 
>> In order to fully respect the semantic, in case of consecutive restarts (with
>> partial route readvertisement), it seems that the stale timer would need to be
>> on a per route basis. I don't think that this is the intention of the authors
>> (nor that this is desirable). Altough this is a local consideration, hence not
>> affecting the peer, the "MUST" make this statement strong. Eventually, a text
>> could be added saying that the timer only needs to be on a per session basis.
>> e.g., :s/this upper bound/this upper bound on a per session basis.
> 
> I'll give this some thought, thanks.

Having done that, I'm not sure the suggested text clarifies things, although I think it was a good point to raise. I'm not sure what it would mean to run the timer on a "per session basis"? Does that mean that I only age stale routes when the session is down, and when the session is re-established the timer gets reset? If so, I think the imagined attack could indeed work -- if my attack lets the session re-establish, but then knocks it over again before it can send EoR, then the timer wouldn't ever fire. 

FWIW I think you are right that a good implementation would age routes on a per route basis. IMHO this is OK. The other alternative I can think of besides that, or the option I argue against above, is to have a per-peer stale timer that once started, is only reset if it expires or if EoR is received for the associated session (but it's not reset by session restarts). When it expires it purges all stale routes ("stale" could be a single bit flag per route, in any case the stale state has to be kept somehow already). This would bound the lifetime of stale routes to no more than the timer duration, which I suppose is the definition of an "upper bound". Possibly the text as written already implies this, although maybe that's asking too much of the reader.

For now I will leave the text as written, pending further discussion. I'll also hold back from publishing -16 pending any more input from the IETF LC or IESG.

Thanks,

--John