i had to do some ascii porn for rob to deal with a secdir reviewer for
draft-ietf-sidr-publication. it may help here. i added the routers for
this discussion.
+------+ +------+ +------+
| CA | | CA | | CA |
+------+ +------+ +------+
| | | Publication Protocol
| | | draft-ietf-sidr-publication
+-------+ | +--------+ Business Relationship Set Up by
| | | draft-ietf-sidr-rpki-oob-setup
+----v---v--v-----+
| |
| Publication |
| Repository |
| |
+-----------------+ Distribution Protocols
| draft-ietf-sidr-delta-protocol
+--------------+----------------+ and/or rcynic
| | |
+-------v-----+ +------v------+ +------v------+
| Relying | | Relying | | Relying |
| Party | | Party | | Party |
+-+-----+----++ +---+-----+---+ +-+--------+--+
| | | | | | | |
| | ++ | | +--+ | | RPKI to Router Protocol (RFC
6810)
| | | | | | | |
draft-ietf-sidr-rpki-rtr-rfc6810-bis
v v v v v v v v
/ \ / \ / \ / \ / \ / \ / \ / \
|Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr|
\ / \ / \ / \ / \ / \ / \ / \ /
V V V V V V V V
we're talking about 6810-bis here, the rpki-rtr protocol which carries
the router keys and origin roas for bgpsec and origin validation.
it is a total database push from the RP cache to the router, not a
piecemeal router driven request protocol. so a monkey in the middle
receives no clues as to what the router is using. there is no side
channel leakage that i can see. i would be happy to be educated
otherwise.
as 6810[-bis] has stripped the crypto of the rpki validataion chain to
the root TA, it no longer has object security; red alert. so the two
ops drafts, 7115 for origin validation and draft-ietf-sidr-bgpsec-ops
for bgpsec, try to be very explicit about transport protection for these
data.
draft-ietf-sidr-bgpsec-ops points to rfc 7115 for RP cache advice.
As RPKI-based origin validation relies on the availability of RPKI
data, operators SHOULD locate RPKI caches close to routers that
require these data and services in order to minimize the impact of
likely failures in local routing, intermediate devices, long
circuits, etc. One should also consider trust boundaries, routing
bootstrap reachability, etc.
For example, a router should bootstrap from a cache that is reachable
with minimal reliance on other infrastructure such as DNS or routing
protocols. If a router needs its BGP and/or IGP to converge for the
router to reach a cache, once a cache is reachable, the router will
then have to reevaluate prefixes already learned via BGP. Such
configurations should be avoided if reasonably possible.
If insecure transports are used between an operator's cache and their
router(s), the Transport Security recommendations in [RFC6810] SHOULD
be followed. In particular, operators MUST NOT use insecure
transports between their routers and RPKI caches located in other
Autonomous Systems.
so maybe the bgpsec-protocol document can remove, as opposed to add,
text just this once?
randy
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
