Re: [v6ops] preventing denial of service in IPv6

"Metzler, Dan J" <dan-metzler@uiowa.edu> Wed, 25 November 2015 15:10 UTC

Return-Path: <dan-metzler@uiowa.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71641B2DEF for <v6ops@ietfa.amsl.com>; Wed, 25 Nov 2015 07:10:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMPuYb35DwD6 for <v6ops@ietfa.amsl.com>; Wed, 25 Nov 2015 07:09:58 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB1E1B2DDD for <v6ops@ietf.org>; Wed, 25 Nov 2015 07:09:57 -0800 (PST)
Received: from CO2PR04MB585.namprd04.prod.outlook.com (10.141.196.139) by CO2PR04MB587.namprd04.prod.outlook.com (10.141.196.150) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 15:09:33 +0000
Received: from CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) by CO2PR04MB585.namprd04.prod.outlook.com ([10.141.196.139]) with mapi id 15.01.0331.019; Wed, 25 Nov 2015 15:09:32 +0000
From: "Metzler, Dan J" <dan-metzler@uiowa.edu>
To: "Ray Hunter (v6ops)" <v6ops@globis.net>, Nikos Mavrogiannopoulos <nmav@gnutls.org>
Thread-Topic: Re: [v6ops] preventing denial of service in IPv6
Thread-Index: AQHRDXllPkT3U56Yb0q2IqTxb+Em45542yXQgABYS4CAM8gjgIAAAt1A
Date: Wed, 25 Nov 2015 15:09:32 +0000
Message-ID: <CO2PR04MB58511D172234305AA2DE9CCFE050@CO2PR04MB585.namprd04.prod.outlook.com>
References: <CAJU7za+ibKJeOLwPnXbZ+zmHo45zWEk9yMOZ_t8biL0zf881+w@mail.gmail.com> <CO2PR04MB5859D5AE68C091C2D9421ACFE260@CO2PR04MB585.namprd04.prod.outlook.com> <CAJU7zaKhqqb-=b=zvnUdLdeFr3es+nUg8eSkSopC94BML+2Tsg@mail.gmail.com> <5655C1B5.8030801@globis.net>
In-Reply-To: <5655C1B5.8030801@globis.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dan-metzler@uiowa.edu;
x-originating-ip: [66.43.218.133]
x-microsoft-exchange-diagnostics: 1; CO2PR04MB587; 5:usMegZinQNU04ca/NaMMCEMlAS4dpRK1+J6zfCafuej2pZB1ijCnhoLNeKy3fhQOrq6P8wm+jQKn/1cdha0XCSkQr6zYhBQsxgtwX7en939+kKhEwOZHON7GZkNlnhVNhzDSnVJxYERoHmxyA/fwEQ==; 24:h8nBOcpl1Odamu/9fPXAFFLhiL0bYIJ3yUev3ehJdkhHmuHmhn2RpzIdDQ689UZjPaR9cyoPK3/qMgusBv0kqLLf7129ydWeZmVCu5sOaI0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB587;
x-microsoft-antispam-prvs: <CO2PR04MB5870B4F782A5DCAC3EBE4C2FE050@CO2PR04MB587.namprd04.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(86304536128247)(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:CO2PR04MB587; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB587;
x-forefront-prvs: 0771670921
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(164054003)(24454002)(106356001)(87936001)(33656002)(2950100001)(19625215002)(86362001)(40100003)(5001960100002)(106116001)(101416001)(81156007)(89122001)(92566002)(1220700001)(10400500002)(99286002)(76576001)(5004730100002)(5008740100001)(2900100001)(105586002)(790700001)(54356999)(5007970100001)(77096005)(15975445007)(16236675004)(75432002)(5002640100001)(97736004)(19300405004)(5001770100001)(66066001)(19580405001)(88552001)(102836003)(3846002)(19580395003)(586003)(189998001)(122556002)(74316001)(6116002)(5003600100002)(90282001)(76176999)(93886004)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB587; H:CO2PR04MB585.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: uiowa.edu does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CO2PR04MB58511D172234305AA2DE9CCFE050CO2PR04MB585namprd_"
MIME-Version: 1.0
X-OriginatorOrg: uiowa.edu
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 15:09:32.6155 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 1bc44595-9aba-4fc3-b8ec-7b94a5586fdc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB587
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/KwUIcr5X3elNG4XsvICT7CcXeyg>
X-Mailman-Approved-At: Wed, 25 Nov 2015 11:25:22 -0800
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] preventing denial of service in IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2015 15:10:07 -0000

With regard to the notion that IPv6's large (source) address space
"...also gives attackers a potential advantage over defenders w.r.t. resource depletion attacks compared to the scarcity of source addresses in IPv4"

I mentioned this before, so don't want to dwell on it too much, but think it is important to understand the problem from a real world perspective.  An address does not deplete resources.  It takes an interface with CPU and memory to do that.

"If an attacker compromises an important server in a corporate network, and the corporation have been sloppy and only applied BCP38 egress filtering at the external boundary at /32 level (rather than individual filters at each /64 per LAN) that could form a very attractive attack platform (2^32/2^64 potential /64 prefixes = equivalent to the entire current Internet address space sourced from a single machine)."

The important point is, with regard to resource depletion, this is a still single machine, and in the context of DOS attack platforms, is usually insignificant without additional systems from which to launch the attack.  Indeed utilizing that many addresses during an attack carries with it some significant overhead that would take away from the effective throughput in this scenario.
The real concern in the stated scenario is the randomly changing source addressing that might evade detection other than the fact that it is all coming from the same subnet.  (That in itself ought to be a useful clue for the corporate network admins of the compromised system, if they are looking to detect the issue.)

When we think about this from a comparison to IPv4, the change is not in the amount of resources that can be dedicated to the attack, but in the potential identities from which they are sourced.

Certainly the massive address space could lead to significant abilities to attack other systems, but it requires more than just address space.  It requires a corresponding investment in network throughput and endpoints that can initiate the attack.
While we think about these issues, I think it is important to not lose sight of that.

Thanks,


-          Dan



From: Ray Hunter (v6ops) [mailto:v6ops@globis.net]
Sent: Wednesday, November 25, 2015 8:12 AM
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Cc: Metzler, Dan J <dan-metzler@uiowa.edu>; v6ops@ietf.org
Subject: Re: Re: [v6ops] preventing denial of service in IPv6



Nikos Mavrogiannopoulos wrote:




Then a single user can exhaust a server's resources by simply

attacking the server with all his available addresses.

FWIW I agree with the original premise that IPv6's large (source) address space is a blessing, but also gives attackers a potential advantage over defenders w.r.t. resource depletion attacks compared to the scarcity of source addresses in IPv4.

I think the problem here is that attackers may also have access to a /32 .. /48 /52 /56 or /60, as well as /64.

If an attacker compromises an important server in a corporate network, and the corporation have been sloppy and only applied BCP38 egress filtering at the external boundary at /32 level (rather than individual filters at each /64 per LAN) that could form a very attractive attack platform (2^32/2^64 potential /64 prefixes = equivalent to the entire current Internet address space sourced from a single machine).





--
regards,
RayH