----- Original Message -----
From: "Randy Bush" <randy@xxxxxxx>
To: "t.petch" <daedulus@xxxxxxxxxxxxx>
Cc: "IETF" <ietf@xxxxxxxx>
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf