> The question of where the servers would be located, locally or somewhere out on
> the Internet, was raised during the development of this document and the answer
> was, we do not know; so I think that if you only regard it as secure when only
> an internal network is involved, then that needs calling out in the Security
> Considerations.
what the document actually says
Transport Security: The RPKI relies on object, not server or
transport, trust. I.e. the IANA root trust anchor is distributed
to all caches through some out of band means, and can then be used
by each cache to validate certificates and ROAs all the way down
the tree. The inter-cache relationships are based on this object
security model, hence the inter-cache transport can be lightly
protected.
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.
While we can not say the cache must be on the same LAN, if only
due to the issue of an enterprise wanting to off-load the cache
task to their upstream ISP(s), locality, trust, and control are
very critical issues here. The cache(s) really SHOULD be as
close, in the sense of controlled and protected (against DDoS,
MITM) transport, to the router(s) as possible. It also SHOULD be
topologically close so that a minimum of validated routing data
are needed to bootstrap a router's access to a cache.
The identity of the cache server SHOULD be verified and
authenticated by the router client, and vice versa, before any
data are exchanged.
Transports which can not provide the necessary authentication and
integrity (see Section 7) must rely on network design and
operational controls to provide protection against spoofing/
corruption attacks.
send text for what you think should be added.
randy
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf