Re: Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/RouterProtocol) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]