Re: [saag] IPsec spec problems

["Gray, Eric" <Eric.Gray at marconi.com>]

Sam,

	I am reasonably sure that you didn't mean this the
way it sounds, but I am also sure that we're not really
all that interested in soliciting any particular vendor's
proposed solution to this general problem - especially as
a counter to existing proposals.

	Apparently, we have a proposal from one vendor, but
it seems to be unacceptable because it is not based on 
IPSec.  Now we hear from another vendor that there are a
few reasons why an IPSec-based solution is not going to
work.

	Perhaps it is time to look again at the proposal
already on the table?

--
Eric 

--> -----Original Message-----
--> From: saag-bounces at mit.edu [mailto:saag-bounces at mit.edu] On 
--> Behalf Of Sam Hartman
--> Sent: Tuesday, May 02, 2006 5:08 PM
--> To: Barry Greene (bgreene)
--> Cc: saag at mit.edu
--> Subject: Re: [saag] IPsec spec problems
--> 
--> >>>>> "Barry" == Barry Greene (bgreene) <bgreene at cisco.com> writes:
--> 
-->     Barry> [For some reason my subscription was not allowing my post
-->     Barry> through.  Trying again.]
-->  
-->     >> The situation is not this bad.
--> 
-->     Barry> It is worse. People ask me about doing IPSEC to 
--> protection
-->     Barry> routing protocols all the time. The irony is that you are
-->     Barry> better off NOT doing IPSEC to protect control plane
-->     Barry> protocols. The perceived risk you are protecting against
-->     Barry> (man in the middle snooping) eliminates all point
-->     Barry> protection to the control plane protocol. The multiple
-->     Barry> layers of classification, policing, and physical 
--> queues are
-->     Barry> all bypassed - with the IPSEC packet going all the way to
-->     Barry> the software on the Route Processor to de-encrypt the
-->     Barry> packet.  The result is that the router is MORE vulnerable
-->     Barry> to attack with IPSEC protected control plane than with it
-->     Barry> turned on.
--> 
--> So, would you or someone at Cisco be willing to work on a document
--> giving implementation guidance or perhaps better yet operational
--> requirements for security solutions that protect against 
--> active attack and  that have reasonable DOS properties?
--> 
--> I think if we had a reasonable set of operational requirements we
--> could work on getting customers to demand those requirements in
--> products.
--> 
--> _______________________________________________
--> saag mailing list
--> saag at mit.edu
--> http://mailman.mit.edu/mailman/listinfo/saag
-->