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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf