Re: [apps-discuss] APPSDIR review of draft-ietf-sidr-rpki-rtr-25

[Randy Bush <[e-mail]>]

hi lisa,

> I noted that this draft is clear and mature for a v0 protocol.

thanks

> I'm not qualified to judge the tradeoffs between supporting unprotected
> TCP, waiting for TCP-AO, or doing something else, but I did note this had
> been extensively discussed during IETF last call.
> 
> I read this section and then made some inferences:
> 
>  - Only a human administrator can tell if a collection of routers and
> caches using RPKI are "on the same trusted and controlled network"
>  - A human administrator would configure the routers and caches to use TCP,
> based on their trust of the local network.
>  - A router would not attempt to use the RPKI-rtr port with unprotected TCP
> unless it was configured by the human administrator to do so
>  - Thus, there is not a downgrade attack unless a human is involved in the
> decision to downgrade the security configuration

you are basically correct.


> I also infer that while a cache implementation MUST generically implement
> unprotected TCP as a transport, that an instance of a cache may well be
> configured simply not to respond to TCP requests on the RPKI-rtr port.

definitely

> Section 7.2 (TLS transport)
> 
> It's not clear to me why routers would need to provide a client certificate
> to caches, because I had not assumed that the data transported in RPKI-RTR
> was sensitive, only that it needed to be valid and authorized. I'm guessing
> it has something to do with being able to manage load on very central
> caches by dropping requests from unauthorized routers, which would be
> either maliciously or unintentionally configured to use a cache that was
> not set up to handle the load of those unauthorized routers.

exactly.

> If this is a correct guess, I wonder if it would be helpful to be a
> bit more explicit about this possibility?  Will there need to be an
> error code added, to be used when a cache has to reject an
> unauthorized router request?

no error code as no session to transport it.  but explaining why the
defense would be good.  thanks.

but, truth be told, no implementors are playing tls.  given peter's
concerns about tls, we would consider just dropping it if it is not too
much of a change at this late date.

randy