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

[<[e-mail]>]

Hi John

Thanks for the follow up.
Please see inline [Bruno]

From: John Scudder [mailto:[e-mail]]
Sent: Wednesday, April 18, 2018 8:32 PM
To: DECRAENE Bruno IMT/OLN
Cc: [e-mail]; idr@ietf. org; [e-mail]; [e-mail]
Subject: Re: Rtgdir telechat review of draft-ietf-idr-bgp-gr-notification-15

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.

[Bruno] Thanks (and agreed).

That leaves me with one unresolved comment:

On Apr 17, 2018, at 3:06 PM, John G. Scudder <[e-mail]<mailto:[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?

[Bruno] That's not what I had in mind

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.

[Bruno] Agreed

FWIW I think you are right that a good implementation would age routes on a per route basis. IMHO this is OK.

[Bruno] If it's ok for you, it's also ok for me. I originally felt that that was too much to track using N timers, but now I guess that there are more intelligent ways to track this using a single timer (per session)

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).

[Bruno] That's the one I had in mind.

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".

[Bruno] That's good enough to me.
Nitpicking again, this does set an upper bound for the routes, but as an operator being asked to configure the value, I would have assumed that the configured timer value was exactly this limit and would be surprised to see the route disappear before. (although in a real conditions, I'm not sure the operator would easily track which routes had been re-advertised in a previous restart)
Again, that behavior works for me but if this is the intended behavior, it could be useful to explain it to the network operator, e.g. using your above text.

Possibly the text as written already implies this, although maybe that's asking too much of the reader.

[Bruno] My comment was that the text may be understood both ways (per route, or per session as per your latest alternative). Now does it really matter?? (except for not understanding it as per the first "per session" interpretation). I leave this to you.

In all cases, thanks for the follow up, on this level of nitpicking, at this late stage.
--Bruno

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.