[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [saag] IPsec spec problems



At 9:47 AM -0700 5/1/06, Barry Greene \(bgreene\) wrote:
[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)

presumably the concern is not so much snooping (which suggests passive wiretapping) as packet tampering (active wiretapping).

 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 proper term is decrypt.

 The result is that the router is
MORE vulnerable to attack with IPSEC protected control plane than with
it turned on.

A more accurate characterization of the concern you cite is that an implementation of IPsec in the control/management processor could create a type of DoS vulnerability, one that might be greater than the active wiretap concern alluded to above. But this potential DoS vulnerability is a function of the implementation strategy adopted by a vendor; it is not intrinsic.

For example, if one believes that attackers are not capable of a MITM attack, then one could implement a simple, fast check of the SPI associated with each IPsec (ESP) packet, on a line card. Thus off-path attacks would be rejected efficiently. Alternatively, if future management processors had adequate horsepower to process IPsec traffic at high speeds, e.g., via hardware assist, then the problem would vanish as well.

It is important to discuss the pros and cons of a given approach relative to a well-defined set of assumptions.

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).

Applying checks at multiple layers is certainly a reasonable strategy, especially if DoS is a primary concern. However, one ought not assume that multiple, weak checks are superior to one strong check, all else being equal.

Steve


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.