Skip to Content.
Sympa Menu

netsec-sig - Re: [Security-WG] [NTAC] Perverse Routing

Subject: Internet2 Network Security SIG

List archive

Re: [Security-WG] [NTAC] Perverse Routing


Chronological Thread 
    < Chronological >      < Thread >
  • From: Bill Owens <>
  • To: David Farmer <>, NTAC <>, "" <>, "" <>
  • Cc: Jeff Harrington <>
  • Subject: Re: [Security-WG] [NTAC] Perverse Routing
  • Date: Sat, 28 Dec 2019 20:12:00 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nysernet.org; dmarc=pass action=none header.from=nysernet.org; dkim=pass header.d=nysernet.org; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6l9CL3jLogJQDpNTy/uzF90C4077aXhmbqMXuDgpLtE=; b=LuwHiLooyWxm3ottyRjbtpElgv/Jy1c3r2UfUfBdTbcu02pOI/p7pgURnRlmnU/eg/1SvaJ+C9FOr8aHjtnlpMvKnjdVfB0dDw8Vv8IrdjQs4y4T3hP/oeWLREL8KLsI5EfnTAdo1+ojjoMz0cIWZP70OeE0MiIPWo433q/7vgtX/JAYucF2Bqzq8LHDtXMGGoQNIN9/4eSpQ2mOa0TDM3HB9ufpr1WIX7DSZ+lavBZHd7fv8rF+9YlUtbM+42XuD6jy34rOaGCd1S+KX5D6pbINbJtbIgiBSOkU3S+viWuHeB3GrgVuiZ0EOpiLzwVubmEDDudGUvKjDeWq8/+X3Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e3MnYkviO0rpGGdIx+fPFppIBS7+Fr15CUVA8vWNuEXCfPU/saCNUsPcxwWnCJb2HShQDzJ94dGWrfoVhKilm2seXUC/IgPVwLPw2AdME2ODTI7V95que9HjUQcNy2C+mvoG39jaZ4+JXmIX/FQwiqE/OGC4w3tMtXQdrEJrLCbWBRQCRrDx01SOhRwRJKTZ4bzLhsjZXiTEAzjotvOCrq/UbtxxJxAQ/MbvoItE91kHM8vVe82s5uoSpkQ0IVT+I8xR1cPvSCWAngJSPjY6BOIxH85P+2aYIVMvZzRs1BUDtPUk4tzOjz9UaIwYzDb49EAjRWGjDht2cKhluDJwng==
*> 170.158.66.0/23 146.57.255.241 1379 202 0 11537 3754 46158 46158 46158 46158 46158 46887 3356 6453 55002 i

This is an interesting test case for our filters, which have obviously failed. The end-user is AS46158 and has, shall we say interesting BGP policies, and is also plagued by almost-continuous DDoS attacks. I think what’s happening here is they’ve heard their own prefix coming from the DDoS scrubber, and arriving back in their table from one of their ISPs. Our filters limit them to their own IP block but otherwise give them a lot of flexibility about how they advertise to us, in part so they can deal with these problems. Obviously we didn’t anticipate them readvertising their own prefix from another origin AS. We’ll have a conversation on Monday and figure out what kind of filter we need to establish to let them continue tweaking their routing as needed but prevent this kind of oops.

Bill.

Archive powered by MHonArc 2.6.19.

Top of Page