At 10:12 AM -0500 1/18/12, Eric Osterweil wrote:
Hey Sandy,
On Jan 17, 2012, at 8:20 PM, Murphy, Sandra wrote:
About #1:
ROAs are used for origin validation. (*) The bgpsec router needs
only the prefix-AS binding in the ROA, not the crypto part, and
only for the origin validation, not the signature attribute
validation. The rpki-rtr protocol is one way to communicate that
binding.
I think I recall from another recent thread that there was some
contention over whether a router should just take it on faith that
the bindings are legit or if it needs to verify them. Since I don't
recall that thread coming to consensus, rather than recreate that
here, I'm happy to leave this to the other thread if people think
that makes sense.
I don't recall that as a point of contention. The model for use of RTR is that
the set of routers that subscribe to a server in this protocol all trust the
server. If the server is managed by the operator of the AS in which
the routers'operate, this is equivalent to the routers trusting the
network management node for the AS.
> The bgpsec signature attribute validation does need the public
keys that are used to validate the signatures. (And the binding to
an AS - see previous message.) But it is the nature of the public
part of a public/private key pair that security concerns are lower
for communicating that part of the pair and exposure is no concern.
I think we may not be speaking to the same point. If a router gets
a private key installed on it (presumably one that has been vetted
to sign for an AS/prefix binding), then how do we get that key
installed securely? If the router gets born with a key, how does an
AS manage the lifetime of that key? That is, how do you envision it
gets rolled over to a new key, and how does that key get vetted and
installed? Again, I may just be missing the relevant part of some
draft, but I was not able to find this procedure concisely
documented.
PKIX has defined (CMC and CMP) protocols for cert requests that can
be used if the router generates its own key pair. We are in the
process of defining a new one that is simpler that than the two cited
above. So there are multiple options here. If one chooses to generate
a key and insert it into a router, then different protocols would be
employed. (CMC is being enhanced to support this mode of operation,
see draft-ietf-pkix-cmc-serverkeygeneration.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
