On Dec 21, 2011, at 8:01 AM, Russ Housley wrote:
Since all of the objects that are transferred over this protocol are
digitally signed, I do not see a security issue. I think the Security
Considerations section (Section 11) does a good job explaining the situation
They're signed and validated by the router? Where? I don't see that in the
current spec and quite the contrary in the Security Considerations section, as
Stephane pointed out and being the element that triggered my initial concern.
Also, what happened to defense in depth? Even if they were signed (they're
not) then object level integrity doesn't obviate the need for network and
transport layer protections, else off-path attackers could easily trigger
considerable churn with transport connection resets that could manifest
themselves [directly] in the router control plane or impact routability of
prefixes through validation state downgrade attacks, or misbehaving devices at
lower layers could cause application-level object validation failures, how are
these handled?
I see a "turtles all the way down" problem here:
"Integrity protection for payloads is also desirable to protect against
monkey in the middle (MITM) attacks. Unfortunately, there is no
protocol to do so on all currently used platforms. Therefore, as of this
document, there is no mandatory to implement transport which provides
authentication and integrity protection."
I didn't realize support on "all currently used platforms" was a requirement
for a new security capability.
-danny
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf