Re: Re: [RPSEC] DDoS of routing ?

John Ioannidis <ji@research.att.com> Fri, 14 March 2003 04:49 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03054 for <rpsec-archive@odin.ietf.org>; Thu, 13 Mar 2003 23:49:34 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E54Lt30878 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 00:04:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E54LO30875 for <rpsec-web-archive@optimus.ietf.org>; Fri, 14 Mar 2003 00:04:21 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03027 for <rpsec-web-archive@ietf.org>; Thu, 13 Mar 2003 23:49:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E53QO30806; Fri, 14 Mar 2003 00:03:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E52wO30747 for <rpsec@optimus.ietf.org>; Fri, 14 Mar 2003 00:02:58 -0500
Received: from mail-red.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02957 for <rpsec@ietf.org>; Thu, 13 Mar 2003 23:47:40 -0500 (EST)
Received: (from postfixfilter@localhost) by mail-red.research.att.com (8.11.6/8.11.6) id h2E4pvE02538; Thu, 13 Mar 2003 23:51:57 -0500
X-Authentication-Warning: mail-red.research.att.com: postfixfilter set sender to ji@research.att.com using -f
Received: from bual.research.att.com (H-135-207-24-19.research.att.com [135.207.24.19]) by mail-red.research.att.com (Postfix) with ESMTP id 15E3F1AB4BD; Thu, 13 Mar 2003 23:51:57 -0500 (EST)
Received: (from ji@localhost) by bual.research.att.com (8.11.6+Sun/8.8.7) id h2E4nkY04344; Thu, 13 Mar 2003 23:49:46 -0500 (EST)
Date: Thu, 13 Mar 2003 23:49:46 -0500
From: John Ioannidis <ji@research.att.com>
To: Alex Zinin <zinin@psg.com>
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, "Ayyasamy, Senthilkumar (UMKC-Student)" <saq66@umkc.edu>, rpsec@ietf.org
Subject: Re: Re: [RPSEC] DDoS of routing ?
Message-ID: <20030314044946.GC4215@bual.research.att.com>
References: <20030313143414.V69506-100000@sequoia.muada.com> <137211665048.20030313185521@psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <137211665048.20030313185521@psg.com>
User-Agent: Mutt/1.4i
X-Spam-Status: No, hits=-138.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT, USER_IN_WHITELIST autolearn=ham version=2.50
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>

DoS attacks on the BGP port are apparently fairly common, at least
according to what I heard at the last NANOG.  The problem is that the
pipe *to* the RP in many current routers is not all that fat, and even
a small flooding attack against port 179 can take out the RP, and
hence the router.

That particular vulnerability is fairly easy to fix; just deny
anything *to* port 179 that's not coming from an adjacent router (that
is, with TTL 255 or 254, depending on exactly what you are running),
and that can stop all simple attacks.  Obviously, this doesn't work
against multihop BGP; there you need crypto that's actually terminated
at the line card (or outside the router); again, you don't want the
cryptographic verification of your packets happening on the RP, for
obvious reasons.

/ji


On Thu, Mar 13, 2003 at 06:55:21PM -0800, Alex Zinin wrote:
> Iljitsch, Senthil-
> 
> <AD hat off wrt this draft>
> 
> Thursday, March 13, 2003, 5:58:00 AM, Iljitsch van Beijnum wrote:
> > On Thu, 13 Mar 2003, Ayyasamy, Senthilkumar  (UMKC-Student) wrote:
> 
> >> while a DoS attack of routing pkts by a peer can lead to RT
> >> exhaustion, is DDoS of routing pkts observed previously?
> 
> > I think attacks on port 179 of routers have been observed in the wild.
> 
> This is what I have heard second hand too.
> 
> Note, btw, that user-level attacks against routers are not limited to
> those using routing protocols or targeted to CPU/queue exhaustion.
> Vulnerabilities related to various forms of buffer overflow, and other
> implementations bugs/suboptimalities have been known for long time.
> Those can be potentially exploited too.
> 
> And the attacks are getting more and more sophisticated, an example
> is the recently announced OSPF exploit where an attacker can make
> a router execute malicious code.
> 
> >> Actually, i had an offline discussion with sandy long back and she
> >> mentioned that it doesn't exist.
> 
> > You're not saying we should wait to fix holes until someone falls in
> > them, are you?
> 
> > At the same time, IGPs are somewhat hard to attack as they use
> > multicasts that routers aren't going to forward.
> 
> This is not entirely true.
> 
> IS-IS is indeed not susceptible to user-level attacks, as, in its
> original form it uses L2 encapsulation for its PDUs, and because those
> are unroutable, a user can't sent an IS-IS packet to a router.
> However, I'm hearing that some vendors have actually implemented
> ISIS-over-IPv4 though it wasn't accepted by the IS-IS WG. This could
> leave a potential backdoor for an attacker if the implementation just
> listens to this IP protocol or has it enabled on a set of interfaces.
> It would be as good/bad as in the OSPF case, no extra.
> 
> OSPF, on the other hand, uses unicast quite extensively. First, on
> broadcast media all neighbor-to-neighbor OSPF packet exchanges from
> ExStart and higher are done in unicast. Plus we have virtual links
> that are exclusively unicast. Besides, the specification suggests to
> treat both unicast and multicast packets equally, which is what many
> implementations do, especially if they allow manually configured
> neighbors. So, it is very possible for an attacker to send a packet to
> a router and it will be allowed to go all the way up to the OSPF
> process (unless MD5 is done on the LC, of course).
> 
> >> context: zinin-rtg-dos-00
> >> I guess, zinin draft talks only about DDoS of data traffic.
> 
> > Doesn't look that way to me.
> 
> Right.
> 
> In fact, it does not talk at all about data traffic DDoS. It is all
> about protecting routers' control plane from user-level attacks.
> 
> Alex
> 
> _______________________________________________
> RPSEC mailing list
> RPSEC@ietf.org
> https://www1.ietf.org/mailman/listinfo/rpsec
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec