----- Original Message -----
From: "Randy Bush" <randy(_at_)psg(_dot_)com>
To: "t.petch" <daedulus(_at_)btconnect(_dot_)com>
Cc: "IETF" <ietf(_at_)ietf(_dot_)org>
Sent: Friday, December 23, 2011 12:34 AM
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
The problem is the disconnect (as I see it) between Security Considerations and
Transport. The latter says that unprotected transport over TCP is mandatory,
the former that ".. the last link, from cache to
router, is secured by server authentication and transport level
security."
I am stuck trying to work out how unprotected transport over TCP gives transport
level security.
If it does not, then I would add a sentence to that paragraph in the Security
Considerations along the lines of
"This cannot be achieved with the mandatory-to-implement transport protocol
TCP."
I would also add to Transport
"Unprotected transport over TCP should only be used within an operator's local
network where adequate security can be achieved by other means."
at the end of the paragraph that states that TCP is a MUST.
Tom Petch
randy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf