Re: [secdir] secdir review of draft-ietf-sidr-delta-protocol-05

[Oleg Muravskiy <[e-mail]>]

Hi everybody,

> On 05 Feb 2017, at 18:23, David Mandelberg <[e-mail]> wrote:
> 
> On 02/05/2017 07:44 AM, Oleg Muravskiy wrote:
>>> On 28 Jan 2017, at 22:29, David Mandelberg <[e-mail]> wrote:
>>> 3.5.1.2: I think the last paragraph might make it harder for the server
>>> to recover from a temporary overload, since it can't tell clients to
>>> wait longer than 1 minute before re-fetching. It seems to me that
>>> letting the clients get a few minutes out of date until the server
>>> operator can provision more capacity is better than accidentally DoSing
>>> the server.
>> 
>> I think what we want to say here is that [for security reasons] RPs should not trust the HTTP caching headers for notification files, if they specify caching for longer than 1 minute, because those headers could be overwritten by the (CDN) distribution servers which might be out of control of the publication server operator.
>> 
>> One minute should be enough for a CDN to overcome DDoS anyway. Additionally, the If-Modified-Since: request header is mandatory, which also lowers the load on the server. And specifying 1 minute cache expiration on notification file does not mean an RP *will* come back for a new file after a minute.
>> 
>> So do you want a longer text in that paragraph?
> 
> No, I think the existing text adequately explains what you're saying. I
> still think it's excessive to poll every 1 minute without honoring
> headers that say to wait longer*. But I don't think it's a security
> issue, and I don't think my opinion on this should delay publication.
> 
> * I was aware of the issue you described where RPs should not trust
> unverified headers, so I'm not advocating for unconditional trust of the
> headers. I just think the RPs should trust the caching headers up to,
> maybe, 1 hour instead of 1 minute. But even 5 minutes would give CDN
> operators a lot more leeway to shed load.

Reading the paragraph in question again:

   Relying Parties SHOULD NOT cache the notification file for longer
   than 1 minute, regardless of the headers set by the repository server
   or CDN.

I think it could be misinterpreted in a way that RP should re-fetch notification file even if being in a middle of a validation run, which is wrong. So I propose a new text:

  In case of a high load on a repository server or its distribution
  network, the Cache-Control HTTP header, or a similar mechanism, MAY
  be used to suggest an optimal (for the repository server) poll
  interval for Relying Parties. However, setting it to an interval
  longer than 1 hour is NOT RECOMMENDED. Relying parties SHOULD align
  the suggested interval with their operational practices and the
  expected update frequency of RPKI repository data, and MAY discard
  suggested value.

What do you think?


Oleg