Stephane:
Sorry, I was too terse in my response. Let me try again.
All of the inputs to the server are signed, so there is no concern about theses objects being modified.
Once process by the server, a protocol that provides authentication and integrity protection is used between the server and router. From the Table of Contents, the choices are clear:
7.1. SSH Transport
7.2. TLS Transport
7.3. TCP MD5 Transport
7.4. TCP-AO Transport
I would personally prefer that the TCP MD5 choice not be used, but the model is clear.
This approach lets the server handle that certificate path construction, signature checking, and revocation checking. It seems desirable to offload these potentially expensive operations, while preserving the integrity of the subset of the information actually needed by the router.
Russ
> On Wed, Dec 21, 2011 at 08:01:49AM -0500,
> Russ Housley <housley@xxxxxxxxxxxx> wrote
> a message of 22 lines which said:
>
>> Since all of the objects that are transferred over this protocol are
>> digitally signed,
>
> Over RTR? It is not mentioned in the I-D, quite the contrary.
>
>> I think the Security Considerations section (Section 11) does a good
>> job explaining the situation
>
> Precisely, it explains that the link router<->cache must be secured
> because the data is *not* signed:
>
> But this protocol document assumes that the routers can not do the
> validation cryptography. Hence the last link, from cache to
> router, is secured by server authentication and transport level
> security. This is dangerous, as server authentication and
> transport have very different threat models than object security.
>
> So the strength of the trust relationship and the transport
> between the router(s) and the cache(s) are critical. You're
> betting your routing on this.
>
>
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf