Re: [saag] IPsec spec problems

["Barry Greene \(bgreene\)" <bgreene at cisco.com>]

[For some reason my subscription was not allowing my post through.
Trying again.]
 
> The situation is not this bad.

It is worse. People ask me about doing IPSEC to protection routing
protocols all the time. The irony is that you are better off NOT doing
IPSEC to protect control plane protocols. The perceived risk you are
protecting against (man in the middle snooping) eliminates all point
protection to the control plane protocol. The multiple layers of
classification, policing, and physical queues are all bypassed - with
the IPSEC packet going all the way to the software on the Route
Processor to de-encrypt the packet.  The result is that the router is
MORE vulnerable to attack with IPSEC protected control plane than with
it turned on.

The core principle to remember is that you cannot wait until the packet
arrives to the core processes on the RP of the router before you
classify, queue, and police the packet. In fact, router vendors should
be doing this classify/queue/police multiple times (i.e. layered
security) starting as close to the L2/L3 as possible (i.e. first phases
of the ASIC).




> -----Original Message-----
> From: saag-bounces at mit.edu [mailto:saag-bounces at mit.edu] On 
> Behalf Of Pasi.Eronen at nokia.com
> Sent: Tuesday, April 25, 2006 6:43 AM
> To: saag at mit.edu
> Subject: Re: [saag] IPsec spec problems
> 
> Pekka Savola wrote:
> > 
> > I actually read RFC 4301 for the first time on a plane (for the 
> > record, I had not read any IPsec RFCs previously).  The 
> situation was 
> > much worse than I thought.  One could say that the IPsec 
> spec is not 
> > optimized for control plane protection with all of its crazy talk 
> > about protected/unprotected interfaces, non-native implementations, 
> > etc.
> > 
> > My perception is that IPsec spec tries to address too many problems 
> > (minimal firewall policing through SPDs; control traffic 
> protection; 
> > VPN protection), and the result is too complex that it isn't useful 
> > for anything except VPNs, and even that's pretty complicated due to 
> > all the baggage.
> > 
> > I was also boggled by the notion that an IPsec implementation at a 
> > router would have to inspect ALL packets it forwards 
> (whether IPsec or 
> > not) against SPD.  That means IPsec would need to be implemented on 
> > all the linecards even if all you wanted is to protect the control 
> > plane.
> >
> > Saner alternative: whether to look for SPDs for particular packet 
> > should be keyed off from the routing table entries. That 
> way IPsec is 
> > only consulted when it needs to be consulted.
> 
> The situation is not this bad. Yes, you're required to 
> inspect all packets crossing the IPsec boundary (between 
> unprotected and protected interfaces), but where exactly this 
> boundary is placed can vary.
> 
> In a router that uses IPsec only for its control traffic (and 
> thus is really a host instead of a gateway from IPsec 
> perspective), the protected interface could be the part of 
> the stack delivering packets to/from local control plane 
> daemons. Thus, packets simply being forwarded by line cards 
> would not cross the IPsec boundary at all.
> 
> But yes, things get more complicated if the router also does 
> IPsec for forwarded packets... although you might simplify 
> things if you consider the router to have multiple logically 
> separate IPsec implementations (as suggested in Section 3.3 
> of RFC 4301).
> 
> Best regards,
> Pasi
> 
> _______________________________________________
> saag mailing list
> saag at mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag
>