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

Re: [RPSEC] rate limiting management traffic, redux



At 4:23 PM -0700 4/17/03, Mark Handley wrote:
 >On vrijdag, apr 18, 2003, at 00:13 Europe/Amsterdam, Mark Handley wrote:

 If the management entity is a peer router at the other end of a link,
 one might decide that less stringent resync mechanisms are needed, if
 one does not assume a MITM attack capability.

 I guess I think you need to assume MITM attack capability.  Routers
 are quite often peered across LANs, and I wouldn't want to count on an
 ethernet switch for routing protection.
The question is whether we need to be able to do man in the middle
protection at line rate. If a man in the middle needs a real packet for
every forged packet, it would be ok for the line cards to let these
packets through and let the CPU do the strong crypto to detect this.
That's true. But you've got to be careful in any re-initialization
mechanism to not allow the attacker use a MITM attack to de-sync
genuinely re-initializing peers so they can't communicate further,
while at the same time defending against flooding of the
re-initialization mechanism.

 - Mark
Mark,

Right. My off the cuff protocol should be viewed just as a starting point for discussion, but this is a generally tricky area, because it's hard to defend against attacks that focus on DoS, and initialization is hard, and ...

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec