From nobody Wed Aug  6 06:18:29 2014
Return-Path: <rja.lists@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08881B2D2F; Wed,  6 Aug 2014 06:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 tVyejYA7BfAF; Wed,  6 Aug 2014 06:18:20 -0700 (PDT)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BA01B2D2D; Wed,  6 Aug 2014 06:18:20 -0700 (PDT)
Received: by mail-qg0-f50.google.com with SMTP id q108so2584787qgd.23 for <multiple recipients>; Wed, 06 Aug 2014 06:18:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=BwG9skkJXMqHqTnmo6hZUyuPSH3LjVfQB36zKgWGqAU=; b=zkU7nT3AUimNP/YQEIz3rXScYTyUdt+gMG44vRTEkon7Gj57OGa8TsQsvOH0lBQ8HL BLgO5eQS/PN1BhvXycgkN+aMyWJ5X0j7tscJJDi6MjtMMpK596j+trPXrIfCqm9TCCg+ rlY/G+iE3kVg6UeaaCU6Q6Z1+STPVQs7S+fu9ePcV7jtxl/jhQI942RZu8ezqmFg+NYr cd2i3vJgHF6tC1GCBS5kf35ubaxHGP2mddpxqBIgur2E5eElE/qvDkoMlu+KpWvuxsUZ 06L+JzK7vOuS0Igxou7LPiaG5J5f7krdWAHdtiDOsUpYiac9G8g/Z/FPmEbVgvdnh4UG 1OfQ==
X-Received: by 10.224.67.2 with SMTP id p2mr16865407qai.37.1407331099671; Wed, 06 Aug 2014 06:18:19 -0700 (PDT)
Received: from [10.30.20.8] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id m42sm979341qga.21.2014.08.06.06.18.18 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 06:18:19 -0700 (PDT)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 6 Aug 2014 09:18:19 -0400
Message-Id: <2678F1EB-D3D1-4CD8-B243-F500F474E61F@gmail.com>
To: opsec@ietf.org, v6ops@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/pyrgga4W7tkTRcgg6ojsS7mZxUE
Subject: Re: [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 13:18:23 -0000

Earlier, on 18th July 2014, Warren Kumari wrote:
> Related to this is
>=20
> http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02
>  -- Why
> Operators Filter Fragments and What It Implies
>=20
> This expired, but I suspect we may need to revive it...
>=20
> W

(ASIDE:  I've trimmed off the int-area list to reduce list
cross-posting.  My sense is that between v6ops and opsec,=20
the applicable audience will be covered adequately.)


I agree that the above draft ought to be revived.

As a community, it would be very helpful to have an
Informational status RFC describing "Why Operators
Filter Fragments and What it Implies".

=46rom my point of view, this need not be an IETF-track
document.  It would serve the purpose equally well as
an ISE-track document with Informational status. =20

(Just to be clear, I don't object to it being IETF-track,
but the ISE-track has a faster time-to-RFC and generally
is a lower-overhead process.)

Yours,

Ran Atkinson


From nobody Tue Aug 12 02:55:48 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900801A0395; Tue, 12 Aug 2014 02:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level: 
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_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 Sae6n3tOOUA1; Tue, 12 Aug 2014 02:55:38 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBF71A081B; Tue, 12 Aug 2014 02:55:34 -0700 (PDT)
Received: from [2001:5c0:1400:a::63f] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XH8ni-0003bI-6c; Tue, 12 Aug 2014 11:55:32 +0200
Message-ID: <53E9E42F.50102@si6networks.com>
Date: Tue, 12 Aug 2014 05:53:51 -0400
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Mikael Abrahamsson <swmike@swm.pp.se>,  draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org
References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <alpine.DEB.2.02.1407140842170.7929@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1407140842170.7929@uplift.swm.pp.se>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/LVnBsFKNqqt6Nr4zTALwzb4GRrQ
Cc: opsec@ietf.org, IPv6 Operations <v6ops@ietf.org>
Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 09:55:43 -0000

Hi, Mikael,

Thanks so much for your feedback! Comments in-line...

On 07/14/2014 02:55 AM, Mikael Abrahamsson wrote:
> 
> I find this document advocates dropping things way too much.

Actually, of the top of my head, the only EH that we were advocated
dropping (from the standard set) is/was HBH (this is to be changed in
the upcoming rev of the document).


> It uses the
> term "intermediate" devices. I would like this split up into two types
> of devices, a "pure packet forwarding device" (=core router), and a
> "security inspection device" (=device that might have ACLs or being a
> stateful firewall).

Me, I'd probably stick to intermmediate device, or maybe "forwarding
node" or "router". If you bring "firewalls" into the game, reality is
that a firewall will typically be "default deny".



> I believe a core router which just forwards packets, should not drop
> packets because of options it can't handle very well. If it can't handle
> a lot of hop-by-hop header packets, then don't inspect these hop-by-hop
> header packets, just forward the packets without looking at them.

We're trying to provide advice to the same sort of devices that are
dropping packets in draft-gont-v6ops-ipv6-ehs-in-real-world....



> The thought of our core networks limiting what we can and can't do in
> the future with IPv6, makes me a sad panda. I can understand devices
> that enforce some kind of security to drop packets they don't
> understand, but generally recommending blanket dropping of some packets
> in the core because of potential edge problems, that just doesn't make
> sense to me.

That's not what we're doing (modulo HBH, as noted above). Please let us
know if there are specific portions of the document that you're
objecting to or that you'd like to be clarified.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 12 03:32:15 2014
Return-Path: <swmike@swm.pp.se>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDC41A0832; Tue, 12 Aug 2014 03:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.319
X-Spam-Level: 
X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.668, SPF_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 vdeGp8ExASQK; Tue, 12 Aug 2014 03:32:12 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9301A03A5; Tue, 12 Aug 2014 03:32:11 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 372E9A1; Tue, 12 Aug 2014 12:32:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1407839530; bh=iQHWV8O0aXxJwgTZL/5lf7X0PHbFmfinGsy1w5xpaS4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=x8A6Jd8dY6yzUCEMmZ5BJUKCFVQ/2/AN4imVa+n32YmJnaK8OFkIszK8SYUwlQOwb gnvkwsUAKcxG7q0Y9fTQHtTzinYg9tRH569k+Kiu8z4mQa/NWIiwpnAKSWYySH4BCa 2g0qzs6jbCAGuBQoV9JDlPhfHjLmCtSBie331B38=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2C2B79F; Tue, 12 Aug 2014 12:32:10 +0200 (CEST)
Date: Tue, 12 Aug 2014 12:32:10 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Fernando Gont <fgont@si6networks.com>
In-Reply-To: <53E9E42F.50102@si6networks.com>
Message-ID: <alpine.DEB.2.02.1408121230390.7929@uplift.swm.pp.se>
References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <alpine.DEB.2.02.1407140842170.7929@uplift.swm.pp.se> <53E9E42F.50102@si6networks.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/gIXT1muL7vGE-PGWWmLgad36CCM
Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations <v6ops@ietf.org>
Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 10:32:13 -0000

On Tue, 12 Aug 2014, Fernando Gont wrote:

> Hi, Mikael,
>
> Thanks so much for your feedback! Comments in-line...
>
> On 07/14/2014 02:55 AM, Mikael Abrahamsson wrote:
>>
>> I find this document advocates dropping things way too much.
>
> Actually, of the top of my head, the only EH that we were advocated
> dropping (from the standard set) is/was HBH (this is to be changed in
> the upcoming rev of the document).

Ok, good! Another thing I don't know if I mentioned, is that there is a 
mix of different ways of saying the same thing in the advice section, 
sometimes it's "pass", sometimes it's "do not drop". Are you fixing that 
as well?

Anyhow, I'll wait until the next rev and give it a complete read-through.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Tue Aug 12 03:42:39 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DA91A03A5; Tue, 12 Aug 2014 03:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 i5q2W-4mm9Cg; Tue, 12 Aug 2014 03:42:34 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC70F1A03A6; Tue, 12 Aug 2014 03:42:34 -0700 (PDT)
Received: from [2001:5c0:1400:a::63f] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XH9XE-0003iQ-Fl; Tue, 12 Aug 2014 12:42:32 +0200
Message-ID: <53E9EF24.4020100@si6networks.com>
Date: Tue, 12 Aug 2014 06:40:36 -0400
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Mikael Abrahamsson <swmike@swm.pp.se>
References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <alpine.DEB.2.02.1407140842170.7929@uplift.swm.pp.se> <53E9E42F.50102@si6networks.com> <alpine.DEB.2.02.1408121230390.7929@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1408121230390.7929@uplift.swm.pp.se>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/I_kyXfxuhtAfR9-svJ23QmebErI
Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org, IPv6 Operations <v6ops@ietf.org>
Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 10:42:37 -0000

Hi, Mikael,

On 08/12/2014 06:32 AM, Mikael Abrahamsson wrote:
>>> I find this document advocates dropping things way too much.
>>
>> Actually, of the top of my head, the only EH that we were advocated
>> dropping (from the standard set) is/was HBH (this is to be changed in
>> the upcoming rev of the document).
> 
> Ok, good! Another thing I don't know if I mentioned, is that there is a
> mix of different ways of saying the same thing in the advice section,
> sometimes it's "pass", sometimes it's "do not drop". Are you fixing that
> as well?

I wasn't... but now I will.



> Anyhow, I'll wait until the next rev and give it a complete read-through.

Thanks so much!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 12 04:49:20 2014
Return-Path: <fernando@gont.com.ar>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4891A0842 for <opsec@ietfa.amsl.com>; Tue, 12 Aug 2014 04:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 14R97mvijVb8 for <opsec@ietfa.amsl.com>; Tue, 12 Aug 2014 04:49:14 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D13B1A078B for <opsec@ietf.org>; Tue, 12 Aug 2014 04:49:14 -0700 (PDT)
Received: from [2001:5c0:1400:a::575] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fernando@gont.com.ar>) id 1XHAZk-0003qy-20; Tue, 12 Aug 2014 13:49:12 +0200
Message-ID: <53E9FE53.5030907@gont.com.ar>
Date: Tue, 12 Aug 2014 07:45:23 -0400
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com>
In-Reply-To: <53C35CC4.2070304@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/MIZSbvDSfYB8kdtkghb_0k9k21k
Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org
Subject: Re: [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 11:49:17 -0000

Hi, Brian,

On 07/14/2014 12:29 AM, Brian E Carpenter wrote:
>> 2.3.1.5. Advice
>>
>>
>>    Intermediate systems should, by default, drop packets containing a
>>    IPv6 Hop-by-Hop Option Extension Header.
> 
> You can't say that! Firstly, RFC 7045 makes it permissible to
> simply ignore them. That's the simplest DoS defence. Secondly,
> well, dropping them is the wrong default because it breaks stuff.
> You could discuss whether to inspect them for valid contents, and
> you could discuss rate-limiting, which I understand some vendors
> support already.

Does this look reasonable:

---- cut here ----
The recommended configuration for the processing of these packets
depends on the features and capabilities of the underlying platform. On
platforms that allow forwarding of packets with HBH Options on the fast
path, we recommend that packets with HBH be forwarded as normal (for
instance, [RFC7045] allows for implementations to ignore the HBH Options
extension header when forwarding packets). Otherwise, on platforms where
processing of packets with IPv6 HBH Options is carried out in the slow
path, and an option is provided to rate-limit these packets, we
recommend that this option is selected. Finally, when packets with HBH
Options are processed in the slow-path, and the underlying platform does
not have any mitigation options available for attacks based on these
packets, we recommend that such platforms drop packets containing IPv6
HBH Options.

Those intermediate systems processing the contents of this extension
header should drop packets that contain more than one instance of the
Router Alert option (see [RFC2711]).

Finally, we note that, for obvious reasons, RPL routers must not drop
packets based on the presence of an IPv6 Hop-by-Hop Option Extension Header.
---- cut here ----

?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Tue Aug 12 07:44:50 2014
Return-Path: <Donald.Smith@CenturyLink.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DED41A0764; Tue, 12 Aug 2014 07:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TDnf5or7eGHk; Tue, 12 Aug 2014 07:44:38 -0700 (PDT)
Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BC71A08F5; Tue, 12 Aug 2014 07:44:38 -0700 (PDT)
Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s7CEiYIV020114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2014 09:44:34 -0500 (CDT)
Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 3F6FD1E006B; Tue, 12 Aug 2014 08:44:29 -0600 (MDT)
Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 2251A1E0067; Tue, 12 Aug 2014 08:44:29 -0600 (MDT)
Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s7CEiSqs028800; Tue, 12 Aug 2014 08:44:28 -0600 (MDT)
Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.ctl.intranet [151.119.128.29]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s7CEiSFG028787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Aug 2014 08:44:28 -0600 (MDT)
Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.03.0158.001; Tue, 12 Aug 2014 08:44:28 -0600
From: "Smith, Donald" <Donald.Smith@CenturyLink.com>
To: Fernando Gont <fgont@si6networks.com>, Mikael Abrahamsson <swmike@swm.pp.se>
Thread-Topic: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt
Thread-Index: AQHPnxxKV3vKyI8r0kmDCuWMZ5DgUZufh4CAgC3FgICAAAq0AIAAAlwA///dN7c=
Date: Tue, 12 Aug 2014 14:44:27 +0000
Message-ID: <68EFACB32CF4464298EA2779B058889D24BD339A@PDDCWMBXEX503.ctl.intranet>
References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <alpine.DEB.2.02.1407140842170.7929@uplift.swm.pp.se> <53E9E42F.50102@si6networks.com> <alpine.DEB.2.02.1408121230390.7929@uplift.swm.pp.se>, <53E9EF24.4020100@si6networks.com>
In-Reply-To: <53E9EF24.4020100@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [151.117.206.34]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/4TZW7xmXxStnu1PodVJI58bppaU
Cc: "opsec@ietf.org" <opsec@ietf.org>, "draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org" <draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org>, IPv6 Operations <v6ops@ietf.org>
Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 14:44:44 -0000

We have language for that in other rfcs. Drop usually means silent drop.
So is drop a silent drop or a reject?
http://tools.ietf.org/html/rfc3871

"Ability to Specify Filter Actions

   Requirement.

      The device MUST provide a mechanism to allow the specification of
      the action to be taken when a filter rule matches.  Actions MUST
      include "permit" (allow the traffic), "reject" (drop with
      appropriate notification to sender), and "drop" (drop with no
      notification to sender).  Also see Section 2.7.7 and Section 2.9"

Are there cases where reject (with notification) makes more sense then drop=
?
Or where the end user should get to choose one over the other?




(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@centurylink.com



From: OPSEC [opsec-bounces@ietf.org] on behalf of Fernando Gont [fgont@si6n=
etworks.com]
Sent: Tuesday, August 12, 2014 4:40 AM
To: Mikael Abrahamsson
Cc: opsec@ietf.org; draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org; IPv6=
 Operations
Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt


Hi, Mikael,

On 08/12/2014 06:32 AM, Mikael Abrahamsson wrote:
>>> I find this document advocates dropping things way too much.
>>
>> Actually, of the top of my head, the only EH that we were advocated
>> dropping (from the standard set) is/was HBH (this is to be changed in
>> the upcoming rev of the document).
>=20
> Ok, good! Another thing I don't know if I mentioned, is that there is a
> mix of different ways of saying the same thing in the advice section,
> sometimes it's "pass", sometimes it's "do not drop". Are you fixing that
> as well?

I wasn't... but now I will.



> Anyhow, I'll wait until the next rev and give it a complete read-through.

Thanks so much!

Best regards,
--=20
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec=


From nobody Tue Aug 12 16:42:43 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052BB1A6EE6 for <opsec@ietfa.amsl.com>; Tue, 12 Aug 2014 16:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 extTChm8rao4 for <opsec@ietfa.amsl.com>; Tue, 12 Aug 2014 16:42:40 -0700 (PDT)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1131A0ADE for <opsec@ietf.org>; Tue, 12 Aug 2014 16:42:40 -0700 (PDT)
Received: by mail-ob0-f181.google.com with SMTP id va2so7873949obc.12 for <opsec@ietf.org>; Tue, 12 Aug 2014 16:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CBuJLhpO4+4Ph9CZd/tp9ymgkULBhZY7n6oPVqAfMb0=; b=IK4sDYQCgLo7nCSv9RZ9ECWBGYwUNXMrf+uQZ4SWeypjqjoMxTj7DV9eWdInzUcZDg nmfX6vwF19nGpII8HaoVE93tlLjDax0UwwifPyE9/jskxVUDivKQmmDQqQ+nV1SarTJj WMlFht+FIY0OYQwYgN7mdF1y7KFFkDR2Fp1YJVpe0AXOze0wy6qSmB9kEATA/RaByRZf AytDrpHpIWOUxJ+pwuHTh+6jkikWJ3CIezcsc89R3LTt7nv2egt3WOP6uKrG4qZApF2x /oH6PYKbM/BgE/ChFu2TAyQf0GLXEAhK6bpAhSw+DkgSGXDU3KnY9EA0kHXEvVmQnjWc o/vw==
X-Received: by 10.182.33.33 with SMTP id o1mr1160143obi.24.1407886960124; Tue, 12 Aug 2014 16:42:40 -0700 (PDT)
Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id v5sm301145oek.15.2014.08.12.16.42.38 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Aug 2014 16:42:39 -0700 (PDT)
Message-ID: <53EAA672.8000208@gmail.com>
Date: Wed, 13 Aug 2014 11:42:42 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <20140704235122.9794.84948.idtracker@ietfa.amsl.com> <53C35CC4.2070304@gmail.com> <53E9FE53.5030907@gont.com.ar>
In-Reply-To: <53E9FE53.5030907@gont.com.ar>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/PrvJGHmlhUv09cQTv96zpA9Yj-g
Cc: opsec@ietf.org, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org
Subject: Re: [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 23:42:42 -0000

Hi Fernando,

Yes, that works for me. Maybe you need a reference for the
RPL exception.

Thanks
    Brian

On 12/08/2014 23:45, Fernando Gont wrote:
> Hi, Brian,
> 
> On 07/14/2014 12:29 AM, Brian E Carpenter wrote:
>>> 2.3.1.5. Advice
>>>
>>>
>>>    Intermediate systems should, by default, drop packets containing a
>>>    IPv6 Hop-by-Hop Option Extension Header.
>> You can't say that! Firstly, RFC 7045 makes it permissible to
>> simply ignore them. That's the simplest DoS defence. Secondly,
>> well, dropping them is the wrong default because it breaks stuff.
>> You could discuss whether to inspect them for valid contents, and
>> you could discuss rate-limiting, which I understand some vendors
>> support already.
> 
> Does this look reasonable:
> 
> ---- cut here ----
> The recommended configuration for the processing of these packets
> depends on the features and capabilities of the underlying platform. On
> platforms that allow forwarding of packets with HBH Options on the fast
> path, we recommend that packets with HBH be forwarded as normal (for
> instance, [RFC7045] allows for implementations to ignore the HBH Options
> extension header when forwarding packets). Otherwise, on platforms where
> processing of packets with IPv6 HBH Options is carried out in the slow
> path, and an option is provided to rate-limit these packets, we
> recommend that this option is selected. Finally, when packets with HBH
> Options are processed in the slow-path, and the underlying platform does
> not have any mitigation options available for attacks based on these
> packets, we recommend that such platforms drop packets containing IPv6
> HBH Options.
> 
> Those intermediate systems processing the contents of this extension
> header should drop packets that contain more than one instance of the
> Router Alert option (see [RFC2711]).
> 
> Finally, we note that, for obvious reasons, RPL routers must not drop
> packets based on the presence of an IPv6 Hop-by-Hop Option Extension Header.
> ---- cut here ----
> 
> ?
> 
> Thanks!
> 
> Best regards,


From nobody Sat Aug 16 11:49:35 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC251A014E for <opsec@ietfa.amsl.com>; Sat, 16 Aug 2014 11:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 PleVhV7JM4E2 for <opsec@ietfa.amsl.com>; Sat, 16 Aug 2014 11:49:26 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93CA1A0146 for <opsec@ietf.org>; Sat, 16 Aug 2014 11:49:25 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XIj2V-0003z0-1m; Sat, 16 Aug 2014 20:49:19 +0200
Message-ID: <53EF9103.2000900@si6networks.com>
Date: Sat, 16 Aug 2014 14:12:35 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>,  Mikael Abrahamsson <swmike@swm.pp.se>, "Smith, Donald" <Donald.Smith@CenturyLink.com>,  "C. M. Heard" <heard@pobox.com>
References: <20140816170731.13620.5804.idtracker@ietfa.amsl.com>
In-Reply-To: <20140816170731.13620.5804.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140816170731.13620.5804.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/zjlszBw-CgM4UYd7uPExi9Qvvtc
Cc: "'opsec@ietf.org'" <opsec@ietf.org>, draft-gont-opsec-ipv6-eh-filtering@tools.ietf.org
Subject: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-01.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 18:49:33 -0000

Folks,

This revision
(<http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-01.txt>)
of the I-D should address the comments that you have sent so far. Please
do let us know if this is the case.

Thanks!

Best regards,
Fernando (& co-authors)




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-opsec-ipv6-eh-filtering-01.txt
Date: Sat, 16 Aug 2014 10:07:31 -0700
From: internet-drafts@ietf.org
To: Will(Shucheng) Liu <liushucheng@huawei.com>, Shucheng LIU (Will)
<liushucheng@huawei.com>, Fernando Gont <fgont@si6networks.com>, Ron
Bonica <rbonica@juniper.net>, Fernando Gont <fgont@si6networks.com>,
Ronald P. Bonica <rbonica@juniper.net>


A new version of I-D, draft-gont-opsec-ipv6-eh-filtering-01.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-opsec-ipv6-eh-filtering
Revision:	01
Title:		Recommendations on Filtering of IPv6 Packets Containing IPv6
Extension Headers
Document date:	2014-08-16
Group:		Individual Submission
Pages:		28
URL:
http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-01.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-eh-filtering/
Htmlized:
http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-opsec-ipv6-eh-filtering-01

Abstract:
   This document provides advice on the filtering of IPv6 packets based
   on the IPv6 Extension Headers and the IPv6 options they contain.
   Additionally, it discusses the operational and interoperability
   implications of discarding packets based on the IPv6 Extension
   Headers and IPv6 options they contain.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat





From nobody Tue Aug 19 02:44:27 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9021A0394; Tue, 19 Aug 2014 02:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 zkJyq8rm31sd; Tue, 19 Aug 2014 02:44:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C31061A0398; Tue, 19 Aug 2014 02:44:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140819094421.18719.29261.idtracker@ietfa.amsl.com>
Date: Tue, 19 Aug 2014 02:44:21 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/cwS8Bm1UoOKf3KkCzTGwfpccctg
Cc: opsec@ietf.org
Subject: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-05.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 09:44:23 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF.

        Title           : BGP operations and security
        Authors         : Jerome Durand
                          Ivan Pepelnjak
                          Gert Doering
	Filename        : draft-ietf-opsec-bgp-security-05.txt
	Pages           : 29
	Date            : 2014-08-19

Abstract:
   BGP (Border Gateway Protocol) is the protocol almost exclusively used
   in the Internet to exchange routing information between network
   domains.  Due to this central nature, it is important to understand
   the security measures that can and should be deployed to prevent
   accidental or intentional routing disturbances.

   This document describes measures to protect the BGP sessions itself
   (like TTL, TCP-AO, control plane filtering) and to better control the
   flow of routing information, using prefix filtering and
   automatization of prefix filters, max-prefix filtering, AS path
   filtering, route flap dampening and BGP community scrubbing.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-bgp-security-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Aug 19 05:00:36 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71261A03E1; Tue, 19 Aug 2014 05:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 w2-m8TlU2dJO; Tue, 19 Aug 2014 05:00:30 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10EF51A03D7; Tue, 19 Aug 2014 05:00:29 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XJi5T-0003v9-1p; Tue, 19 Aug 2014 14:00:27 +0200
Message-ID: <53F33C4F.2070807@si6networks.com>
Date: Tue, 19 Aug 2014 09:00:15 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: IPv6 Operations <v6ops@ietf.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ynyAKZ8QU-SsNdihI7tTQmxz8Bs
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: [OPSEC] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 12:00:34 -0000

Folks,

Ten days ago or so we published this I-D:
<http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt>

Section 5.2 of the I-D discusses a possible attack vector based on a
combination of "forged" ICMPv6 PTB messages and IPv6 frag drops by
operators, along with proposed countermeasures -- on which we'd like to
hear your comments.

Since Section 5.2 is in the draft, let me offer a more informal and
practical explanation:

1) It is known that filtering of packets containing IPv6 Extension
Headers (including the Fragment Header) is widespread (see our I-D above)

2) Let us assume that Host A is communicating with Server B, and that
some node filters fragments between Host A and Server B.

3) An attacker sends a spoofed ICMPv6 PTB to server B, with a "Next Hop
MTU<1280), in the hopes of eliciting "atomic fragments" (see
<http://tools.ietf.org/rfc/rfc6946.txt>) from now on.

4) Now server B starts sending IPv6 atomic fragments... And since they
include a frag header (and in '2)' above we noted that frags are dropped
on that path), these packets get dropped (i.e., DoS).


"Demo" with the icmp6 tool
(<http://www.si6networks.com/tools/ipv6toolkit>) -- (some addresses have
been changed (anonimized), but it is trivial to pick a victim server...)

"2001:db8:1:10:0:1991:8:25" is the server, and
"2001:5c0:1000:a::e7d" is my own address):

---- cut here ----
***** First of all, I telnet to port 80 of the server, and
everything works as expected ****

fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80
Trying 2001:db8:1:10:0:1991:8:25...
Connected to 2001:db8:1:10:0:1991:8:25.
Escape character is '^]'.
^CConnection closed by foreign host.

**** Now I send the forget ICMPv6 PTB ****

fgont@satellite:~$ sudo icmp6  --icmp6-packet-too-big -d
2001:db8:1:10:0:1991:8:25 --peer-addr 2001:5c0:1000:a::e7d --mtu 1000 -o
80 -v
icmp6: Security assessment tool for attack vectors based on ICMPv6 error
messages

IPv6 Source Address: 2001:5c0:1000:a::e7d (automatically selected)
IPv6 Destination Address: 2001:db8:1:10:0:1991:8:25
IPv6 Hop Limit: 227 (randomized)
ICMPv6 Packet Too Big (Type 2), Code 0
Next-Hop MTU: 1000
Payload Type: IPv6/TCP (default)
Source Address: 2001:db8:1:10:0:1991:8:25 (automatically-selected)
Destination Address: 2001:5c0:1000:a::e7d
Hop Limit: 237 (randomized)
Source Port: 80	Destination Port: 38189 (randomized)
SEQ Number: 734463213 (randomized)	ACK Number: 866605720 (randomized)
Flags: A (default)	Window: 18944 (randomized)	URG Pointer: 0 (default)
Initial attack packet(s) sent successfully.


***** And now I try the same telnet command as above... but it fails,
because the frags from the server to me are getting dropped somewhere ****

fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80
Trying 2001:db8:1:10:0:1991:8:25...
[timeout]
---- cut here ----


Of course, in this particular case I just "shot myself". But one could
do this to DoS connections between mailservers, etc.

A nice question is: what if e.g....

1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and
react (as expected) by generating atomic fragments, *and*,

2) These same BGP servers deem fragmentation as "harmful", and hence
drop such fragments

you could essentially DoS traffic between them

As noted in the I-D, the mitigations seem to be:

1) Artificially limit your packets to 1280, and drop all incoming ICMPv6
PTB, or,

2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU
smaller than 1280.

Thoughts?
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 19 05:31:55 2014
Return-Path: <jeroen@massar.ch>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65641A040E; Tue, 19 Aug 2014 05:31:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 kK2d7kjB1gkQ; Tue, 19 Aug 2014 05:31:49 -0700 (PDT)
Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00D01A0416; Tue, 19 Aug 2014 05:31:49 -0700 (PDT)
Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id C6A9B10034AC6; Tue, 19 Aug 2014 12:31:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1408451506; bh=/wHsniLtZHm+RYSYa6XIbbJQ50oxkzApF+gYyHsNtAI=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=CTm0FGPulxxUT0eem+H2gqaafb3HR7Bimvj/DvMj9M+A33P1lFxip39x4kmgN8X1v WkQzUiDE0QswbstWA4hWLwiD9USV7eceOkVn5S9CEyRcQBSRQ6tugz72yR6bOF4MoE iXIbV9m8LpOQVZT4iWrBI3mItCMQqKuOIfdx0ij+ccdVpvCLkYxmn2ei9KCJGkEyT0 qry98QHJZRjN4Tr1Noi4NCPk7Zb86AuxyFhuwLhyvmx3BTLwUSM0eREO/TVBYhs7vM Gvvpjc0foJmSlCivqcqqUYnCyexCJbnKFfeGS03rEwXL4me8KA0xdT8K58KEzkDwWh 6yV5Tlf9Uai3g==
Message-ID: <53F343A3.1070505@massar.ch>
Date: Tue, 19 Aug 2014 14:31:31 +0200
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
MIME-Version: 1.0
To: Fernando Gont <fgont@si6networks.com>,  IPv6 Operations <v6ops@ietf.org>
References: <53F33C4F.2070807@si6networks.com>
In-Reply-To: <53F33C4F.2070807@si6networks.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/SxY7et-Y6JCLOgLcD9xW2BCuXW8
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 12:31:51 -0000

On 2014-08-19 14:00, Fernando Gont wrote:
[..]
> 1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and
> react (as expected) by generating atomic fragments, *and*,

Anything accepting an MTU < 1280 does not belong on the Interwebs.

Hence, it would be good that kind of broken code can't send anything.

[..]
> As noted in the I-D, the mitigations seem to be:
> 
> 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6
> PTB, or,
> 
> 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU
> smaller than 1280.

Don't forget:
0) BCP38.

Though, one would have to inspect the ICMPv6 packet too then....

Hmm, maybe time to test that out in sixxsd...

Greets,
 Jeroen


From nobody Tue Aug 19 05:35:34 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01191A0416; Tue, 19 Aug 2014 05:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 WFB4mi00OZ8t; Tue, 19 Aug 2014 05:35:31 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85E31A040A; Tue, 19 Aug 2014 05:35:30 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XJidM-00041q-5J; Tue, 19 Aug 2014 14:35:28 +0200
Message-ID: <53F34486.7010903@si6networks.com>
Date: Tue, 19 Aug 2014 09:35:18 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Jeroen Massar <jeroen@massar.ch>, IPv6 Operations <v6ops@ietf.org>
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch>
In-Reply-To: <53F343A3.1070505@massar.ch>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/QHA13dMwz8POsyKlwiD_z6tVEcg
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 12:35:33 -0000

On 08/19/2014 09:31 AM, Jeroen Massar wrote:
> On 2014-08-19 14:00, Fernando Gont wrote:
> [..]
>> 1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and
>> react (as expected) by generating atomic fragments, *and*,
> 
> Anything accepting an MTU < 1280 does not belong on the Interwebs.
> 
> Hence, it would be good that kind of broken code can't send anything.

Well, RFC2460 requires so....


> [..]
>> As noted in the I-D, the mitigations seem to be:
>>
>> 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6
>> PTB, or,
>>
>> 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU
>> smaller than 1280.
> 
> Don't forget:
> 0) BCP38.
> 
> Though, one would have to inspect the ICMPv6 packet too then....

Agreed. You need to apply ICMPv6 to the embedded payload...



> Hmm, maybe time to test that out in sixxsd...

Just taking my chance to thank you for sixxsd! ;-)

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 19 06:19:20 2014
Return-Path: <jeroen@massar.ch>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C4A1A88E7; Tue, 19 Aug 2014 06:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 1VD6ncwIMCwX; Tue, 19 Aug 2014 06:19:14 -0700 (PDT)
Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C581A88C9; Tue, 19 Aug 2014 06:19:13 -0700 (PDT)
Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 97F3A10034B7C; Tue, 19 Aug 2014 13:19:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1408454350; bh=dgWWg6GkoIrtrhD8/H3YFd6mKsCCWtvTW8nxbYT0DGA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=jzj/m5CoHnmxHbfvQlm8olDmqtrXtbNC+0PLDM5NJRcmluiveLwDY1fPwQtgo2SHA TsZgrofZ4AB116lg0bi2VmAxAgwQg7FQEPCVzcSkcbzlKiKyRS/97r+jjFReg4dNOz Bq/nynGSA2WRbR026wfXmOqzGi4PFZUMs/4mPXCHkzJyywhRyOGteWiM81tq8v3ej9 QfUhb9dk1OHtDAmyE3p7n6gn25qXkVeDMR5rlyj1+YLQlUYt0n8SSle2Vr9S5Ckuhk x3O+QlKmlbEVEAnQjD4iNyTXG2y0Q+8NQ/79ntmeuyVHEevPyqO4e+9ZveXn1jH7sE 5fGwDTfZDStgg==
Message-ID: <53F34EC0.30400@massar.ch>
Date: Tue, 19 Aug 2014 15:18:56 +0200
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
MIME-Version: 1.0
To: Fernando Gont <fgont@si6networks.com>,  IPv6 Operations <v6ops@ietf.org>
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com>
In-Reply-To: <53F34486.7010903@si6networks.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/7nS87igsrlAgWPLn8Xzi4rtKOEY
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 13:19:15 -0000

On 2014-08-19 14:35, Fernando Gont wrote:
[..]
>> Though, one would have to inspect the ICMPv6 packet too then....
> 
> Agreed. You need to apply ICMPv6 to the embedded payload...

But also for ICMPv4, which has similar attacks.

Hence we should formulate text a bit like:

8<------------------------
When forwarding or receiving an ICMP error packet:
 - The IP destination of the packet MUST match the source address
   represented in the ICMP error packet.

 - The ICMP error packet's destination address must qualify uRPF rules
   for the same interface as the source address.[1]

As the verified packets are ICMP errors, when the verification fails the
packet MUST be dropped, logging is recommended.

Due to the checking inside the ICMP portion of a packet:
  Access-routers, firewalls and hosts MUST perform these checks.
  Core-routers SHOULD perform these checks

[1] When ICMP-dst address matches IP-src the check should already have
been performed by the standard uRPF check.
------------------------>8

But then in better wording to avoid dis-ambiguity of which src/dst is
which (the one in IP or ICMP)

>> Hmm, maybe time to test that out in sixxsd...
> 
> Just taking my chance to thank you for sixxsd! ;-)

Unfortunately that is only usable for a very small base of connectivity
and hopefully one day will stop to be needed. The big brands needs to
implement it. And it much more difficult to push out updates to devices
which are not under one's control and where one has a very large
deployed base.

Greets,
 Jeroen


From nobody Tue Aug 19 06:24:48 2014
Return-Path: <rdobbins@arbor.net>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7911A88EB for <opsec@ietfa.amsl.com>; Tue, 19 Aug 2014 06:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
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 T9y7SRE_IE_l for <opsec@ietfa.amsl.com>; Tue, 19 Aug 2014 06:24:33 -0700 (PDT)
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85BB01A03F8 for <opsec@ietf.org>; Tue, 19 Aug 2014 06:24:33 -0700 (PDT)
Received: by mail-ig0-f170.google.com with SMTP id h3so9641574igd.5 for <opsec@ietf.org>; Tue, 19 Aug 2014 06:24:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=BDZrqShWjWHRB5brkxDIHXf6xhS0rY8fWlIzLCWkxts=; b=TenrbSQ6OhqcfwqcEwI4XkXm43l5L6pxhGfE1b0hOWv8PeGUj3fKlyUFoZIgRfk+wa A5QS/Hb4bUEzKoUFiexYgV94HiyilVzTW23mXp3MiPy+NaiAn4IwnSy7o0gyAPoe3kgC 3flQjRmAGOOjVaoc6/n7TDWLfU1HiwXclJMJyBGbnnthVqQMreVn9GMrfzQHPzKL3iN5 V5BKeBpm7alv18KbkP9FOTchtcA1lxs/d8FA85wNGjMn199a84DzeQuCn+uYIaUNKtDk fA/6EpA3RzwuQnHn8SyEypQgolxwdRcrxwz0DZpksQ17FSPWh0ci6R8M1xfn4FnJ6Avk Cahg==
X-Gm-Message-State: ALoCoQly7lHzF9smRoUHKwc9/puPzLYc3EPP2ivQZQnOEkTRLIXJT9fiHaTQ++6V6CU84z8sADob
X-Received: by 10.50.124.102 with SMTP id mh6mr5698625igb.27.1408454672856; Tue, 19 Aug 2014 06:24:32 -0700 (PDT)
Received: from [172.19.254.114] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by mx.google.com with ESMTPSA id l4sm56582049igt.20.2014.08.19.06.24.30 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 06:24:32 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Roland Dobbins <rdobbins@arbor.net>
In-Reply-To: <53F34EC0.30400@massar.ch>
Date: Tue, 19 Aug 2014 20:23:54 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net>
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch>
To: "opsec@ietf.org" <opsec@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/11vvYai0bfTzQjHwbrnutbswbT4
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 13:24:38 -0000

On Aug 19, 2014, at 8:18 PM, Jeroen Massar <jeroen@massar.ch> wrote:

> - The ICMP error packet's destination address must qualify uRPF rules =
for the same interface as the source address.[1]

Should this language be limited to uRPF, or should it include other =
anti-spoofing mechanisms, as well?

----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

                   Equo ne credite, Teucri.

    		   	  -- Laoco=F6n


From nobody Tue Aug 19 06:29:55 2014
Return-Path: <jeroen@massar.ch>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A78C1A041D; Tue, 19 Aug 2014 06:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 Bauy2YLctQz8; Tue, 19 Aug 2014 06:29:52 -0700 (PDT)
Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3471A02C1; Tue, 19 Aug 2014 06:29:52 -0700 (PDT)
Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id B90A310034A9D; Tue, 19 Aug 2014 13:29:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1408454990; bh=Iwji1cC8RoZoIlx+LfwnxAsQ+wQnU5V3V2GV4CbwMPY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=VshfIMmAcsVwVGC6sDM4GtLMdt8iZBmSdrCrz3uoAVmJyUO9YSvtu0yjCnIzvXgPU 5qvgg4Gn0o9IkxbT6NZd3r3E2ECEnNp56vlCGSbx3YmN6TmrbD96V1vrjHon5YY1Im ke8LXNTwj8JUj1Lf4eAfq0QxFqA+PKWPOBDMzWZg3OGeB65C6G2xZ1OzmLiaOTbaYa BfaSPo4oJP8XFXhPGsVocPd+eVkpZE9+Td2hdsSy4KymlFRm0W77NjiJ6z8isO0z/i SksRM5fm2AKA1ruBrH/5UjoWHAklaJuylzMR3SaTYM2FeEKdwquts6A/BHYauIiTx/ 8sai51E1WVB+g==
Message-ID: <53F35140.7040007@massar.ch>
Date: Tue, 19 Aug 2014 15:29:36 +0200
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
MIME-Version: 1.0
To: Roland Dobbins <rdobbins@arbor.net>,  "opsec@ietf.org" <opsec@ietf.org>
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net>
In-Reply-To: <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/x34fHBxV7QOIRtBoBjizCRMYKzY
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 13:29:54 -0000

On 2014-08-19 15:23, Roland Dobbins wrote:
> 
> On Aug 19, 2014, at 8:18 PM, Jeroen Massar <jeroen@massar.ch> wrote:
> 
>> - The ICMP error packet's destination address must qualify uRPF rules for the same interface as the source address.[1]
> 
> Should this language be limited to uRPF, or should it include other anti-spoofing mechanisms, as well?

Any kind of mechanism that can check:
"is this source address supposed to come from that interface"

would qualify IMHO (as long as it does a proper job ;).

Greets,
 Jeroen


From nobody Tue Aug 19 07:59:15 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE421A03DF; Tue, 19 Aug 2014 07:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 8jxV3cYY6Uxw; Tue, 19 Aug 2014 07:59:04 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149391A03C8; Tue, 19 Aug 2014 07:59:04 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XJks8-0004jE-JT; Tue, 19 Aug 2014 16:58:54 +0200
Message-ID: <53F36622.1000503@si6networks.com>
Date: Tue, 19 Aug 2014 11:58:42 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Philip Homburg <pch-v6ops-3@u-1.phicoh.com>,  Roland Dobbins <rdobbins@arbor.net>
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net> <m1XJkXA-0000SGC@stereo.hq.phicoh.net>
In-Reply-To: <m1XJkXA-0000SGC@stereo.hq.phicoh.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/_BfrqWO9F_g5Zj2K00wCj3mWCSM
Cc: "opsec@ietf.org" <opsec@ietf.org>, IPv6 Operations <v6ops@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 14:59:09 -0000

On 08/19/2014 11:37 AM, Philip Homburg wrote:
>>
>>> - The ICMP error packet's destination address must qualify uRPF rules for=
>> the same interface as the source address.[1]
>>
>> Should this language be limited to uRPF, or should it include other anti-spoofing
>> mechanisms, as well?
> 
> At least for TCP it is relatively easy for the host to check whether the sequence
> numbers make sense. If they don't, discard the error ICMP.

mmm.. not really... check this (from
<http://www.ietf.org/id/draft-gont-6man-deprecate-atomfrag-generation-00.txt>):

   o  Many implementations fail to perform validation checks on the
      received ICMPv6 error messages, as recommended in Section 5.2 of
      [RFC4443] and documented in [RFC5927].  It should be noted that in
      some cases, such as when an ICMPv6 error message has (supposedly)
      been elicited by a connection-less transport protocol (or some
      other connection-less protocol being encapsulated in IPv6), it may
      be virtually impossible to perform validation checks on the
      received ICMPv6 error messages.  And, because of IPv6 extension
      headers, the ICMPv6 payload might not even contain any useful
      information on which to perform validation checks.

   o  Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big"
      error messages, the Destination Cache [RFC4861] is usually updated
      to reflect that any subsequent packets to such destination should
      include a Fragment Header.  This means that a single ICMPv6
      "Packet Too Big" error message might affect multiple communication
      instances (e.g., TCP connections) with such destination.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 19 08:01:01 2014
Return-Path: <nick@foobar.org>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7015F1A0376; Tue, 19 Aug 2014 07:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TwMWjYS4QQbX; Tue, 19 Aug 2014 07:11:23 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591AB1A8906; Tue, 19 Aug 2014 07:11:13 -0700 (PDT)
X-Envelope-To: opsec@ietf.org
Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s7JEAeHV012392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2014 15:11:04 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org
Message-ID: <53F35AE0.2040304@foobar.org>
Date: Tue, 19 Aug 2014 15:10:40 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Jeroen Massar <jeroen@massar.ch>, Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch>
In-Reply-To: <53F34EC0.30400@massar.ch>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/nWkaEnDAF8_3Vr7zicTaTCgfJoU
X-Mailman-Approved-At: Tue, 19 Aug 2014 08:00:54 -0700
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 14:11:25 -0000

On 19/08/2014 14:18, Jeroen Massar wrote:
> But also for ICMPv4, which has similar attacks.

no, it doesn't because in general ipv4 fragments are not dropped.  Also,
ipv4 handles this by fragmenting en-route rather than sending PTB packets
to the source.

Nick


From nobody Tue Aug 19 08:01:03 2014
Return-Path: <pch-bBB316E3E@u-1.phicoh.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02A51A890C; Tue, 19 Aug 2014 07:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 iv0d5NRxN_4w; Tue, 19 Aug 2014 07:37:15 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id E3ACE1A0382; Tue, 19 Aug 2014 07:37:14 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XJkXA-0000SGC; Tue, 19 Aug 2014 16:37:12 +0200
Message-Id: <m1XJkXA-0000SGC@stereo.hq.phicoh.net>
To: Roland Dobbins <rdobbins@arbor.net>
From: Philip Homburg <pch-v6ops-3@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net> 
In-reply-to: Your message of "Tue, 19 Aug 2014 20:23:54 +0700 ." <8E7C5F3E-F9E2-468B-AA0E-D6FAE3CA5A6A@arbor.net> 
Date: Tue, 19 Aug 2014 16:37:11 +0200
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/SdqAlNLMba6UcMPtQGcGBd1B1f4
X-Mailman-Approved-At: Tue, 19 Aug 2014 08:00:51 -0700
Cc: "opsec@ietf.org" <opsec@ietf.org>, IPv6 Operations <v6ops@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 14:37:17 -0000

In your letter dated Tue, 19 Aug 2014 20:23:54 +0700 you wrote:
>On Aug 19, 2014, at 8:18 PM, Jeroen Massar <jeroen@massar.ch> wrote:
>
>> - The ICMP error packet's destination address must qualify uRPF rules for=
> the same interface as the source address.[1]
>
>Should this language be limited to uRPF, or should it include other anti-spoofing
>mechanisms, as well?

At least for TCP it is relatively easy for the host to check whether the sequence
numbers make sense. If they don't, discard the error ICMP.



From nobody Tue Aug 19 09:17:32 2014
Return-Path: <jeroen@massar.ch>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E6E1A0645; Tue, 19 Aug 2014 09:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 561sFjRQGxB9; Tue, 19 Aug 2014 09:17:29 -0700 (PDT)
Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F231A063E; Tue, 19 Aug 2014 09:17:28 -0700 (PDT)
Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id D213310038DA0; Tue, 19 Aug 2014 16:17:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1408465046; bh=YpedaDIl0LGDhDO4gIXOej0pxTSbA4PM4WBmMZYj9gI=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=RVcwhEqiM+tDx+oc7tVEIFkxI4SM+CABoKGMRJc0r4W9pUxz21pSuL7UzDf5CuCmw DFd8RlLMi/RVmhD1AlAOmj7FdMmEa6mR+WD5hFLsq84CBwm/aG/G25YgNwyARC0Gzo n/2x78f05hl7QfqBaPlRb+g/ToCABO2vXcGgHrxZNOeA6FwiDZTiavH5OSwjZZ/Zrg QTlHMoz1GwbTogaAe33MXsakAQCg9ZYZQDGDDZtRXyZ848q58Gzp+4fZsj9IEjcHVF jqN1Ft3/SdYk4tdrO9Rc5WBWYz2Zw3abmPbsJmPBMI163Bi8/3YI3zkd7PlyLaGbuj MToTDqB0FXPKA==
Message-ID: <53F37885.9040903@massar.ch>
Date: Tue, 19 Aug 2014 18:17:09 +0200
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
MIME-Version: 1.0
To: Nick Hilliard <nick@foobar.org>, Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <53F35AE0.2040304@foobar.org>
In-Reply-To: <53F35AE0.2040304@foobar.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/HsQG83HZppZeoeNux4zTpoRRkhk
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 16:17:31 -0000

On 2014-08-19 16:10, Nick Hilliard wrote:
> On 19/08/2014 14:18, Jeroen Massar wrote:
>> But also for ICMPv4, which has similar attacks.
> 
> no, it doesn't because in general ipv4 fragments are not dropped.  Also,
> ipv4 handles this by fragmenting en-route rather than sending PTB packets
> to the source.

Note the word 'similar' in that sentence.

While that specific fragmented attack won't work, one can still spoof
return ICMPs and give wrong answers.

Anyone remember Rotorouter[1] ? :)

Hence, why it is a good idea to do the same checks for IPv4 too and why
I avoid mentioning what kind of attack it was solving. It is just good
hygiene to check validity of things.

Greets,
 Jeroen


[1] http://www.shmoo.com/mail/bugtraq/aug98/msg00110.html


From nobody Tue Aug 19 09:30:19 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3321A066A; Tue, 19 Aug 2014 09:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 jx6fIQSTu5WE; Tue, 19 Aug 2014 09:30:12 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9901A0640; Tue, 19 Aug 2014 09:30:12 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XJmIT-00054V-30; Tue, 19 Aug 2014 18:30:09 +0200
Message-ID: <53F37A7F.8020708@si6networks.com>
Date: Tue, 19 Aug 2014 13:25:35 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Jeroen Massar <jeroen@massar.ch>, Nick Hilliard <nick@foobar.org>,  IPv6 Operations <v6ops@ietf.org>
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <53F35AE0.2040304@foobar.org> <53F37885.9040903@massar.ch>
In-Reply-To: <53F37885.9040903@massar.ch>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/hDYgLf48iiSv7ZEtnRYk6Y7eYJg
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 16:30:15 -0000

On 08/19/2014 01:17 PM, Jeroen Massar wrote:
> 
> While that specific fragmented attack won't work, one can still spoof
> return ICMPs and give wrong answers.
> 
> Anyone remember Rotorouter[1] ? :)
> 
> Hence, why it is a good idea to do the same checks for IPv4 too and why
> I avoid mentioning what kind of attack it was solving. It is just good
> hygiene to check validity of things.

FWIW, I had posted this thingy a while ago:
<http://www.gont.com.ar/papers/filtering-of-icmp-error-messages.pdf>  --
essentially BCP38 on the ICMPv4 payload..

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 19 09:34:22 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA111A05F5; Tue, 19 Aug 2014 09:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 JHNF5InF8zhE; Tue, 19 Aug 2014 09:34:20 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37F51A6FCF; Tue, 19 Aug 2014 09:34:20 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XJmMV-00056N-1j; Tue, 19 Aug 2014 18:34:19 +0200
Message-ID: <53F37C72.6040406@si6networks.com>
Date: Tue, 19 Aug 2014 13:33:54 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Jeroen Massar <jeroen@massar.ch>, IPv6 Operations <v6ops@ietf.org>
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch>
In-Reply-To: <53F34EC0.30400@massar.ch>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ZY6i8rz9i9A701I7vAz7SwEDX_w
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 16:34:21 -0000

Hello, Jeroen,

On 08/19/2014 10:18 AM, Jeroen Massar wrote:
> Hence we should formulate text a bit like:
> 
> 8<------------------------
> When forwarding or receiving an ICMP error packet:
>  - The IP destination of the packet MUST match the source address
>    represented in the ICMP error packet.
> 
>  - The ICMP error packet's destination address must qualify uRPF rules
>    for the same interface as the source address.[1]
> 
> As the verified packets are ICMP errors, when the verification fails the
> packet MUST be dropped, logging is recommended.
> 
> Due to the checking inside the ICMP portion of a packet:
>   Access-routers, firewalls and hosts MUST perform these checks.
>   Core-routers SHOULD perform these checks
> 
> [1] When ICMP-dst address matches IP-src the check should already have
> been performed by the standard uRPF check.
> ------------------------>8

Should we include something alng this lines to the countermeasures
listed in draft-gont-v6ops-ipv6-ehs-in-real-world, or were you thinking
about something else?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 19 09:49:03 2014
Return-Path: <jeroen@massar.ch>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC221A04F1; Tue, 19 Aug 2014 09:48:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 XAnihqUR5A0D; Tue, 19 Aug 2014 09:48:57 -0700 (PDT)
Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5C01A0650; Tue, 19 Aug 2014 09:48:56 -0700 (PDT)
Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 09FC810034BE7; Tue, 19 Aug 2014 16:48:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1408466933; bh=2Y7S/GVTibKjrrPfWqWxatouUSki6OGtN8+4knEk414=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=fsZY1T0DG1StynpMHM0iO9Ti/2tcWD1Jl9wabtyX9eoJUKk3duAdqno9iL/CsemOS Z3NLEBvWQumPJKNWEPydTmj4mWMGIWbT4/u1dfIH9cEC5jbj9v16NSNi4H5216QsqZ FCOyEF5ffYV+0pG3eMvyCTAEOv7uD0kcumC6PmtI6ebcR3ctJtQxtkp4/q6GFdhdjS Po7IXzI34GcPnipGWYv/LnQ9opUzz8LtOWHiHc96p3djBhcA96hme6TZLp6qsLdk2u GRdAIgeHsOxgmxurgXXOkNWLhFd3LLQLzCwYWRpMjluGZtB2d83FTCf5PaXydY6fKi 8qvC/uKr5SQGQ==
Message-ID: <53F37FE6.6080306@massar.ch>
Date: Tue, 19 Aug 2014 18:48:38 +0200
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
MIME-Version: 1.0
To: Fernando Gont <fgont@si6networks.com>,  IPv6 Operations <v6ops@ietf.org>
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <53F37C72.6040406@si6networks.com>
In-Reply-To: <53F37C72.6040406@si6networks.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/jUrTK1M6fG2UcTV629SmPaJzjlw
Cc: "'opsec@ietf.org'" <opsec@ietf.org>, Nick Hilliard <nick@foobar.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 16:48:58 -0000

[merging two different replies back into one]

On 2014-08-19 18:33, Fernando Gont wrote:
> Hello, Jeroen,
> 
> On 08/19/2014 10:18 AM, Jeroen Massar wrote:
>> Hence we should formulate text a bit like:
>>
>> 8<------------------------
>> When forwarding or receiving an ICMP error packet:
>>  - The IP destination of the packet MUST match the source address
>>    represented in the ICMP error packet.
>>
>>  - The ICMP error packet's destination address must qualify uRPF rules
>>    for the same interface as the source address.[1]
>>
>> As the verified packets are ICMP errors, when the verification fails the
>> packet MUST be dropped, logging is recommended.
>>
>> Due to the checking inside the ICMP portion of a packet:
>>   Access-routers, firewalls and hosts MUST perform these checks.
>>   Core-routers SHOULD perform these checks
>>
>> [1] When ICMP-dst address matches IP-src the check should already have
>> been performed by the standard uRPF check.
>> ------------------------>8
> 
> Should we include something alng this lines to the countermeasures
> listed in draft-gont-v6ops-ipv6-ehs-in-real-world, or were you thinking
> about something else?

While it kind-of has a place there, (ipv6-ehs-in-real-world) is a
"current state of the Internet" regarding this problem, it thus
introduces the problem.

Hence, a short, separate document which updates ICMPv4 + ICMPv6
referencing that draft would be more appropriate IMHO.

Especially as then it is quicker for implementers to see what they need
to get done to solve the issue. Hence, a short intro with "this is the
problem: ....; for more detail see draft-X + RFC5927" + "do this in your
ICMPv4/v6 stacks" would be a good start.

Then we might be able to get it quickly into at least Linux and BSD
kernels which is what most access-router/firewalls are being built upon.


On 2014-08-19 18:25, Fernando Gont wrote:
> On 08/19/2014 01:17 PM, Jeroen Massar wrote:
>>
>> While that specific fragmented attack won't work, one can still spoof
>> return ICMPs and give wrong answers.
>>
>> Anyone remember Rotorouter[1] ? :)
>>
>> Hence, why it is a good idea to do the same checks for IPv4 too
>> and why I avoid mentioning what kind of attack it was solving.
>> It is just good hygiene to check validity of things.
>
> FWIW, I had posted this thingy a while ago:
> <http://www.gont.com.ar/papers/filtering-of-icmp-error-messages.pdf>
> -- essentially BCP38 on the ICMPv4 payload..

aka RFC 5927, though only informational even though it went through WG
review it seems.

That indeed touches upon the subject quite a bit too, and would be a
good thing to reference from a draft dubbed:
 "ICMPv4 + ICMPv6 Address Verification"

Greets,
 Jeroen


From nobody Tue Aug 19 10:19:49 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49E31A04E9; Tue, 19 Aug 2014 10:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 BJX9yc70ZEZf; Tue, 19 Aug 2014 10:19:43 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C57D1A048D; Tue, 19 Aug 2014 10:19:43 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XJn4N-0005F5-QH; Tue, 19 Aug 2014 19:19:40 +0200
Message-ID: <53F386F2.2060900@si6networks.com>
Date: Tue, 19 Aug 2014 14:18:42 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Jeroen Massar <jeroen@massar.ch>, IPv6 Operations <v6ops@ietf.org>
References: <53F33C4F.2070807@si6networks.com> <53F343A3.1070505@massar.ch> <53F34486.7010903@si6networks.com> <53F34EC0.30400@massar.ch> <53F37C72.6040406@si6networks.com> <53F37FE6.6080306@massar.ch>
In-Reply-To: <53F37FE6.6080306@massar.ch>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/RimQwB_x7N0H8ZJ308aL6T2kl4k
Cc: "'opsec@ietf.org'" <opsec@ietf.org>, Nick Hilliard <nick@foobar.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 17:19:45 -0000

On 08/19/2014 01:48 PM, Jeroen Massar wrote:
>> Should we include something alng this lines to the countermeasures
>> listed in draft-gont-v6ops-ipv6-ehs-in-real-world, or were you thinking
>> about something else?
> 
> While it kind-of has a place there, (ipv6-ehs-in-real-world) is a
> "current state of the Internet" regarding this problem, it thus
> introduces the problem.
> 
> Hence, a short, separate document which updates ICMPv4 + ICMPv6
> referencing that draft would be more appropriate IMHO.

Ok, makes sense.



>>> Hence, why it is a good idea to do the same checks for IPv4 too
>>> and why I avoid mentioning what kind of attack it was solving.
>>> It is just good hygiene to check validity of things.
>>
>> FWIW, I had posted this thingy a while ago:
>> <http://www.gont.com.ar/papers/filtering-of-icmp-error-messages.pdf>
>> -- essentially BCP38 on the ICMPv4 payload..
> 
> aka RFC 5927, though only informational even though it went through WG
> review it seems.

It took 7 years to publish... and not because of slacking. It was
insane. :-)

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 19 11:11:32 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D3F1A0684; Tue, 19 Aug 2014 11:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 9KfcaTPn4Ysh; Tue, 19 Aug 2014 11:11:14 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34AB1A066D; Tue, 19 Aug 2014 11:11:13 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XJnsE-0005PR-EB; Tue, 19 Aug 2014 20:11:10 +0200
Message-ID: <53F3931F.9050601@si6networks.com>
Date: Tue, 19 Aug 2014 15:10:39 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com>
In-Reply-To: <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/MzuRjmwB8uY5jdyI9TlRSSTLVaw
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 18:11:18 -0000

Hi, Jinmei,

On 08/19/2014 02:58 PM, 神明達哉 wrote:
>> As noted in the I-D, the mitigations seem to be:
>>
>> 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6
>> PTB, or,
>>
>> 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU
>> smaller than 1280.
>>
>> Thoughts?
> 
> In my general understanding, ICMPv6 PTB with the MTU < 1280 could be
> only (at least in practice) used for the "stateless" type of IPv4/v6
> translators so that the IPv6-only host can give the translator a hint
> for the 16-bit IPv4 header ID value.  Am I correct?

Yes. (That's the theory, at least. Me, I'd say that the host is really
in no better position than the translator to pick a Frag ID... actually,
it's in a much worse position).


> If so, one possible alternative would be to drop such ICMPv6 PTB
> unless the source IPv6 address is one of those reserved for such use
> (as defined in RFC 6052).

Source of the ICMPv6 message? If so, I'd say that while that's certainly
better than the current situation, unless there's widespread deployment
of BCP38, an attacker could still forge an ICMPv6 with one of such
addresses and still perform the attack..


> Then we can at least reduce the problem to
> source address spoofing.  And, unless/until we heavily rely on such
> types of translators, this may be actually sufficient in practice,
> since in the vast majority of legitimate cases we should use different
> addresses than those special ones.

I must say that I fail to see the need for generating IPv6 atomic
fragments 8packets with a frag header, which are not really fragmented).
See e.g. what we wrote in
<http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00>.

Thoughts?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 19 11:42:17 2014
Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617721A0665; Tue, 19 Aug 2014 10:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 MmarFEBdiCZ3; Tue, 19 Aug 2014 10:58:03 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD99F1A065F; Tue, 19 Aug 2014 10:58:02 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id k48so6819062wev.13 for <multiple recipients>; Tue, 19 Aug 2014 10:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OEJe297rAinQyx6hjtS3gYSrxW5i18ysPS+q8oxDjww=; b=dBTiE8W2XaG0rZV24Akw4F0k+KsUQMydUM25nVd24OzezMcbnzYPCTuFEgq92dG43O PUj89DyBRvUQucDBguW93Z5XHIHcYOUedB/UUmera8bqazjpngwHjLH1xO/yGAiWJEPO GNTOaRjpLMngp1Qaxsm09VTnuvHZSnW8ADKhL7G81QXt5xk3pFoLOslJWFXV3Lsutaoc MhXofD3Neq4HoQ9QOPV5SAA0FPhcTPUnnXZnpNvsRJkoFhlFBaGhiebdoFOP32N4kuzr v+WNt5E9wDMgu1UC+yoE7t0Cv6uDu4C6wLiIKlGs41uehD/U6RhPzyJT/twb4+y+yqb8 9KOw==
MIME-Version: 1.0
X-Received: by 10.180.80.133 with SMTP id r5mr8548105wix.62.1408471081403; Tue, 19 Aug 2014 10:58:01 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.123.164 with HTTP; Tue, 19 Aug 2014 10:58:01 -0700 (PDT)
In-Reply-To: <53F33C4F.2070807@si6networks.com>
References: <53F33C4F.2070807@si6networks.com>
Date: Tue, 19 Aug 2014 10:58:01 -0700
X-Google-Sender-Auth: QFtG_KIiw0MDqLS6Z27ZyGjwiXM
Message-ID: <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/SLCUs536k-orDH7Hc3NvMW0MyNo
X-Mailman-Approved-At: Tue, 19 Aug 2014 11:42:15 -0700
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 17:58:04 -0000

At Tue, 19 Aug 2014 09:00:15 -0300,
Fernando Gont <fgont@si6networks.com> wrote:

> you could essentially DoS traffic between them
>
> As noted in the I-D, the mitigations seem to be:
>
> 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6
> PTB, or,
>
> 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU
> smaller than 1280.
>
> Thoughts?

In my general understanding, ICMPv6 PTB with the MTU < 1280 could be
only (at least in practice) used for the "stateless" type of IPv4/v6
translators so that the IPv6-only host can give the translator a hint
for the 16-bit IPv4 header ID value.  Am I correct?

If so, one possible alternative would be to drop such ICMPv6 PTB
unless the source IPv6 address is one of those reserved for such use
(as defined in RFC 6052).  Then we can at least reduce the problem to
source address spoofing.  And, unless/until we heavily rely on such
types of translators, this may be actually sufficient in practice,
since in the vast majority of legitimate cases we should use different
addresses than those special ones.

--
JINMEI, Tatuya


From nobody Tue Aug 19 15:58:57 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7101A6FA1; Tue, 19 Aug 2014 15:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 NFJk4r2myWSu; Tue, 19 Aug 2014 15:58:50 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814101A6F9B; Tue, 19 Aug 2014 15:58:50 -0700 (PDT)
Received: by mail-oi0-f53.google.com with SMTP id e131so5162342oig.12 for <multiple recipients>; Tue, 19 Aug 2014 15:58:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l9RBnPfkuZBxk7mV4kLWvR1v+NKWxA//psxP1OIJvsY=; b=04bD3LDorcKfkkCk8uICX5Kp/npzlyzMWe4Lrq/nF+KAW9b/KfVjSd7/P34BZOk6B3 y2Fzq3DTh3qqTbcjXOQOtDppx9rvjbLIQDxIFtDYvhSjuCAQLak5VKgSmKUURZtGDb42 TxZ4sCfQSid8nl43biuFHjgM9q1gLSJIzru1ZQ9x800rPyzVU+DjfPabzlGNGzjake05 HXPu2sA5khCdHcfr9EUJz28gYRsJjm6ZWgOydr2KPJ80ciwbES1hI18yRnD4z+CgBEKY BfGe2S3UqDZ+ixi5FS74KxL8TvBCL6PnwLlNymZnBXj3W7WxFi3KeMVutNVB5eRHr1M7 v2FQ==
X-Received: by 10.60.103.195 with SMTP id fy3mr46704274oeb.35.1408489129979; Tue, 19 Aug 2014 15:58:49 -0700 (PDT)
Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id bz3sm30570557oec.10.2014.08.19.15.58.47 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 15:58:49 -0700 (PDT)
Message-ID: <53F3D6AB.4090505@gmail.com>
Date: Wed, 20 Aug 2014 10:58:51 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com>
In-Reply-To: <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Y1o9eZlZ1VK-nL8JFD7aFolSJ9U
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 22:58:52 -0000

On 20/08/2014 10:29, Lorenzo Colitti wrote:
> On Tue, Aug 19, 2014 at 11:10 AM, Fernando Gont <fgont@si6networks.com>
> wrote:
> 
>> I must say that I fail to see the need for generating IPv6 atomic
>> fragments 8packets with a frag header, which are not really fragmented).
>> See e.g. what we wrote in
>> <
>> http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00
>>> .
> 
> It does seem kind of silly that we say "you must support MTU >= 1280 to run
> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't
> simply say that PTB packets < 1280 are invalid?

Because of SIIT, that is equivalent to saying that the minimum IPv4
MTU is now 1260. That might be a discussion worth having, but 576 has
been around for a long time.

   Brian


From nobody Tue Aug 19 16:22:54 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2811A6FA6; Tue, 19 Aug 2014 16:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 2kO7h14FD0Gz; Tue, 19 Aug 2014 16:22:48 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B711A6FC1; Tue, 19 Aug 2014 16:22:47 -0700 (PDT)
Received: from [186.134.69.71] (helo=[192.168.123.127]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XJsjl-0007VS-Sy; Wed, 20 Aug 2014 01:22:46 +0200
Message-ID: <53F3DC3C.5080607@si6networks.com>
Date: Tue, 19 Aug 2014 20:22:36 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Mark Andrews <marka@isc.org>
References: <53F33C4F.2070807@si6networks.com> <20140819224734.28B0B1D0F8C9@rock.dv.isc.org>
In-Reply-To: <20140819224734.28B0B1D0F8C9@rock.dv.isc.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/9HZ6Q9_rTmwBjS7W-KoajRuvRrQ
Cc: IPv6 Operations <v6ops@ietf.org>, "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 23:22:50 -0000

On 08/19/2014 07:47 PM, Mark Andrews wrote:
>> Since Section 5.2 is in the draft, let me offer a more informal and
>> practical explanation:
>>
>> 1) It is known that filtering of packets containing IPv6 Extension
>> Headers (including the Fragment Header) is widespread (see our I-D above)
>>
>> 2) Let us assume that Host A is communicating with Server B, and that
>> some node filters fragments between Host A and Server B.
> 
> Some node is performing a Denial Of Service attack on the communications
> between Host A and Server B.  The logical thing is to remove/reconfigure
> the node performing the denial of service attack.  Note the box
> that is dropping the fragments is almost certainly controlled by
> the owners of A or the owners of B.

Not necessarily. Please see our measurement results in
<http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt>
regarding the percentage of packet drops that happen in a different AS
other than the destination AS.



>> 3) An attacker sends a spoofed ICMPv6 PTB to server B, with a "Next Hop
>> MTU<1280), in the hopes of eliciting "atomic fragments" (see
>> <http://tools.ietf.org/rfc/rfc6946.txt>) from now on.
>>
>> 4) Now server B starts sending IPv6 atomic fragments... And since they
>> include a frag header (and in '2)' above we noted that frags are dropped
>> on that path), these packets get dropped (i.e., DoS).
> 
> The PTB is not the problem.  The Atomic fragments are not the
> problem.  The problem is the node that is filtering the packets.
> Atomic fragements are easily identifiable.  There is zero reason
> to filter them and good reason to let them continue to exist.

There's no problem with *processing* atomic fragments. The question here
is what that of "including an FH in all subsequence packets in response
to an ICMPv6 PTB<1280" buys us. As far as I can see, it only buys trouble.



> Write up a CERT advisary and list all the known firewalls that fail
> to pass atomic fragments.
> 
> Write a RFC "Firewalls That Drop Atomic Fragments Considered Harmful".

FWIW, they are dropping all fragments, not just atomic fragments.

The only issue with atomic fragments is how their generation is
triggered: they are (easily) triggered by a packet type (ICMPv6 PTB)
that does not even require source address spoofing, and that is hard to
validate.

And even if you think you have everything under control in the sense of
"I block all fragments, and artificially limit the MTU to 1280" you may
get bitten. In the same way you will get bitten when a third party is
dropping IPv6 fragments (as our measurements indicate).

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 19 16:25:40 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0723F1A6FA6; Tue, 19 Aug 2014 16:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 gY42JUU9gr7d; Tue, 19 Aug 2014 16:25:34 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE20F1A0023; Tue, 19 Aug 2014 16:25:34 -0700 (PDT)
Received: from [186.134.69.71] (helo=[192.168.123.127]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XJsmR-0007WO-3T; Wed, 20 Aug 2014 01:25:31 +0200
Message-ID: <53F3DCA1.2080207@si6networks.com>
Date: Tue, 19 Aug 2014 20:24:17 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>,  Lorenzo Colitti <lorenzo@google.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com>
In-Reply-To: <53F3D6AB.4090505@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/nlhOi9y3qZN979VUNDHwwTinBVY
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 23:25:36 -0000

Hi, Brian,

On 08/19/2014 07:58 PM, Brian E Carpenter wrote:
>>
>> It does seem kind of silly that we say "you must support MTU >= 1280 to run
>> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't
>> simply say that PTB packets < 1280 are invalid?
> 
> Because of SIIT, that is equivalent to saying that the minimum IPv4
> MTU is now 1260. That might be a discussion worth having, but 576 has
> been around for a long time.

Not sure what you meant about 576... that we can assume that to be a
minmum MTU, or something else?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 19 16:56:14 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E230B1A003A; Tue, 19 Aug 2014 16:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 TdwONpkzvUu6; Tue, 19 Aug 2014 16:56:11 -0700 (PDT)
Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C351A0024; Tue, 19 Aug 2014 16:56:10 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id g18so5887445oah.9 for <multiple recipients>; Tue, 19 Aug 2014 16:56:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HyhaFpk9ScaIGk7Bt0PzJj6b2im7a96QNSyg5OV6fho=; b=J3xU+93nnoxW8wijFSGOGvThACPB/Meha/lYitmfFczxWJFzRsLrH9xTIKIC7rWxyB NawGPnSHXhuHswImwpC9hN67bK3STz1qSxhF/N9HIW2CtsphtpfZXZTfgMc+S6Rz211J kdE+fjc+eD3BRXnSRs04TXFBKlljj5d0WzzdzOLPLFbD8IBy1QGZXVAZ3W2+PWjohKpB cVucd3cFBy+Xg9USHD8t6LI/Z27+jDTE6Rp6eW6q2DGbbbulrVygl+4s10RX1OwpxJ7h T9Iqj6bsgr4h8TeKVZ0uOiLw4x3+QpPXBYxxZgaKHX3GrLA2lRJKIqN2BfmTgkfZQMr1 NPMw==
X-Received: by 10.182.44.135 with SMTP id e7mr46596682obm.18.1408492569731; Tue, 19 Aug 2014 16:56:09 -0700 (PDT)
Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id df10sm30752148oec.1.2014.08.19.16.56.07 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 16:56:09 -0700 (PDT)
Message-ID: <53F3E41C.3060100@gmail.com>
Date: Wed, 20 Aug 2014 11:56:12 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com> <CAKD1Yr12GFse+axuKqousWtYhzhKN98V3928yfSn5YofwAdGDQ@mail.gmail.com>
In-Reply-To: <CAKD1Yr12GFse+axuKqousWtYhzhKN98V3928yfSn5YofwAdGDQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/fVr438kQnoqNJ6KVCpBZo_0e4VU
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 23:56:13 -0000

On 20/08/2014 11:01, Lorenzo Colitti wrote:
> On Tue, Aug 19, 2014 at 3:58 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>>> Any reason we can't simply say that PTB packets < 1280 are invalid?
>> Because of SIIT, that is equivalent to saying that the minimum IPv4
>> MTU is now 1260. That might be a discussion worth having, but 576 has
>> been around for a long time.
>>
> 
> Can we then say that PTB packets < 1280 are invalid and should be ignored
> by hosts? Or should be ignored unless they are running a SIIT translator?

The host doesn't know in general if there is a translator downstream
(except in a DNS64/NAT64 scenario).

   Brian


From nobody Tue Aug 19 17:09:16 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AF91A8971; Tue, 19 Aug 2014 17:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 crA3Qu9pY2Pa; Tue, 19 Aug 2014 17:09:10 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354271A8964; Tue, 19 Aug 2014 17:09:10 -0700 (PDT)
Received: by mail-oi0-f48.google.com with SMTP id h136so5104194oig.7 for <multiple recipients>; Tue, 19 Aug 2014 17:09:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MPl+yRGBdebp2ChjC13UxlENBF6Bv1LYnpKbbv1liYg=; b=HGqBsKFWKZ4mMbp550Ul/qxWTlQ830WcLCGdpRywf5wBblYscFnNnHUdET67RdZC5Y 66Z4S4v5rAdWvJgO5NOFExSKKW6EnjJrreg5AXdv2eZtu+GS+2iiP1nZnIynnI5tv4Mj GKd0gffDzRGPItdVP2FLPzM8aKsulN8IO24UPwgTKvzy2oypRqolbUh37UAkaG+7SRwr lVsmcD6lc5WC6gjunkR1U89BZY95BAZ9DfeMyDez7FQOrzD2At9V83gCjHrXuRBBK3nB O/qUfavLwGCsMSXmK8Yh5u8DCSqTr28P5MOJkm1Svyv21jQSs5gFOjWnj83nNk4zGDXO bjKw==
X-Received: by 10.60.150.211 with SMTP id uk19mr12990627oeb.70.1408493349691;  Tue, 19 Aug 2014 17:09:09 -0700 (PDT)
Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id sx14sm30795044oeb.14.2014.08.19.17.09.07 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 17:09:09 -0700 (PDT)
Message-ID: <53F3E725.6050708@gmail.com>
Date: Wed, 20 Aug 2014 12:09:09 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Fernando Gont <fgont@si6networks.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com>
In-Reply-To: <53F3DCA1.2080207@si6networks.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ATT6HIPq1CnuVDHcR40eVCBPKEU
Cc: IPv6 Operations <v6ops@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>, "opsec@ietf.org" <opsec@ietf.org>, Lorenzo Colitti <lorenzo@google.com>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 00:09:12 -0000

On 20/08/2014 11:24, Fernando Gont wrote:
> Hi, Brian,
> 
> On 08/19/2014 07:58 PM, Brian E Carpenter wrote:
>>> It does seem kind of silly that we say "you must support MTU >= 1280 to run
>>> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't
>>> simply say that PTB packets < 1280 are invalid?
>> Because of SIIT, that is equivalent to saying that the minimum IPv4
>> MTU is now 1260. That might be a discussion worth having, but 576 has
>> been around for a long time.
> 
> Not sure what you meant about 576... that we can assume that to be a
> minmum MTU, 

Yes, that hasn't changed since RFC 791 (although the way fragmentation
is defined for IPv4 is rather different from IPv6, of course).

Maybe we consider it acceptable that SIIT will break on paths that
include a shorter-than-Ethernet link MTU. But we need to make that
statement explicit.

  Brian

or something else?
> 
> Thanks!
> 
> Cheers,


From nobody Tue Aug 19 19:29:54 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C791A8716; Tue, 19 Aug 2014 19:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 W-JUYHSs9RIY; Tue, 19 Aug 2014 19:29:51 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4968D1A8715; Tue, 19 Aug 2014 19:29:51 -0700 (PDT)
Received: by mail-oi0-f43.google.com with SMTP id u20so5250574oif.30 for <multiple recipients>; Tue, 19 Aug 2014 19:29:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zSK19esL+XnjXS/3JEoL0M3pfNydqNct+Cd1V3KOIiY=; b=GNiTjPLyZeSUWmdwJiYeo7afmNfMc4vuWGSV4TxtJ+XFig4IFvT7yGa7V8lsYsZXti SMjlc43ONyptSmdLk1acl13mu0lXZR5lLtbUICi8Og1cMa2AFBqwbbyZaWepsRb4Vnqv KqcMbdPsJy0CaR9CZgzlL4GPz2LaSpL7r4An5K04xpV7iCVWEceXC+bFalVGyDXtD1sS OHWEjWTp3hbG0SW0YiqxRVccwf7wsiZ2H9nOCxk9y86pmFAnEp7rssz/ExxiGXpHrvHK MfyKNzBBUG04NJKqpNVqt1aCsUF99RfmhkL9hTHwNgyX4jToSY2UcNqXshhaGX9kNflz 3V2g==
X-Received: by 10.182.3.100 with SMTP id b4mr96694obb.79.1408501789636; Tue, 19 Aug 2014 19:29:49 -0700 (PDT)
Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id my6sm23408481obb.4.2014.08.19.19.29.47 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 19:29:49 -0700 (PDT)
Message-ID: <53F40820.1060407@gmail.com>
Date: Wed, 20 Aug 2014 14:29:52 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark Andrews <marka@isc.org>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com> <53F3E725.6050708@gmail.com> <20140820015522.6DB261D117FF@rock.dv.isc.org>
In-Reply-To: <20140820015522.6DB261D117FF@rock.dv.isc.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/hJnrpmkz-J_zM63cB066UOoRPuU
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 02:29:52 -0000

On 20/08/2014 13:55, Mark Andrews wrote:
> 	576 is the mimimum reassembly buffer size to be supported
> 	by all IPv4 hosts.  It is *not* the minimum path MTU size.

Indeed. In fact what I was trying to say, badly, is that the
proposed change would de facto create a minimum path MTU of
1260 for IPv4, iff we want SIIT to work in the general case.

Which is a choice we could make, but we'd need to be clear
that we were making it.

   Brian

> 
> 	The miminum link MTU is 68 bytes.  RFC 791.
> 
> 	Mark
> 
> In message <53F3E725.6050708@gmail.com>, Brian E Carpenter writes:
>> On 20/08/2014 11:24, Fernando Gont wrote:
>>> Hi, Brian,
>>>
>>> On 08/19/2014 07:58 PM, Brian E Carpenter wrote:
>>>>> It does seem kind of silly that we say "you must support MTU >= 1280 to r
>> un
>>>>> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't
>>>>> simply say that PTB packets < 1280 are invalid?
>>>> Because of SIIT, that is equivalent to saying that the minimum IPv4
>>>> MTU is now 1260. That might be a discussion worth having, but 576 has
>>>> been around for a long time.
>>> Not sure what you meant about 576... that we can assume that to be a
>>> minmum MTU, 
>> Yes, that hasn't changed since RFC 791 (although the way fragmentation
>> is defined for IPv4 is rather different from IPv6, of course).
>>
>> Maybe we consider it acceptable that SIIT will break on paths that
>> include a shorter-than-Ethernet link MTU. But we need to make that
>> statement explicit.
>>
>>   Brian
>>
>> or something else?
>>> Thanks!
>>>
>>> Cheers,
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Tue Aug 19 21:02:57 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4011A0B82; Tue, 19 Aug 2014 21:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 cgdsAh9trRLL; Tue, 19 Aug 2014 21:02:52 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E251A06D9; Tue, 19 Aug 2014 21:02:51 -0700 (PDT)
Received: by mail-pa0-f54.google.com with SMTP id fa1so11278486pad.41 for <multiple recipients>; Tue, 19 Aug 2014 21:02:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zZdMNEv8deRU9EoL3V9aUV9Lom16VpwS7+CVzZR4VQw=; b=ZihYHBoQdhYZUD3Bf2pudSdykKSAO8vV8dPdchxSE40VtFbXq52R3hdSiKZp3vJrVP FA7n288e7TFL+Ex5ACOaQMUuxndpiBlHWTYxwUYikr+FJFQygPf6gpf2TKY6aXzfLf17 r9x0PsXEJwZCTQG48u5kNPNjhxd6v5KfzL9Bx2O9AYOt2c5i6UIbWYoyQIgQom6cT8AK 9vlrkM1hESVKRMRgJi9RawljSmPwgoQWJp7wVRk0gy7N1Col0b5iFHae7kilzSqfbOKA gvF70HPrnabK/hyqjpHGJSQVMLiktLKfB0lFVSZKtvo+IU0d/WujIW/3LsZGpO8L6hjX J3IA==
X-Received: by 10.68.202.196 with SMTP id kk4mr8601646pbc.37.1408507371588; Tue, 19 Aug 2014 21:02:51 -0700 (PDT)
Received: from [192.168.178.23] (182.199.69.111.dynamic.snap.net.nz. [111.69.199.182]) by mx.google.com with ESMTPSA id mj9sm75695845pab.20.2014.08.19.21.02.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 21:02:51 -0700 (PDT)
Message-ID: <53F41DE2.6020907@gmail.com>
Date: Wed, 20 Aug 2014 16:02:42 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com> <CAKD1Yr12GFse+axuKqousWtYhzhKN98V3928yfSn5YofwAdGDQ@mail.gmail.com> <53F3E41C.3060100@gmail.com> <CAKD1Yr18Lt0=n9jt8dBAOwHe+rqY9MdyU8TQBwYt6Yf6a7o8cA@mail.gmail.com>
In-Reply-To: <CAKD1Yr18Lt0=n9jt8dBAOwHe+rqY9MdyU8TQBwYt6Yf6a7o8cA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/s5Nti5vuv_Qn7S-OQ7YW6KxFA74
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 04:02:54 -0000

On 20/08/2014 14:42, Lorenzo Colitti wrote:
> On Tue, Aug 19, 2014 at 4:56 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>>> Can we then say that PTB packets < 1280 are invalid and should be ignored
>>> by hosts? Or should be ignored unless they are running a SIIT translator?
>> The host doesn't know in general if there is a translator downstream
>> (except in a DNS64/NAT64 scenario).
>>
> 
> What does "downstream" mean? Do you mean "the host does not know if the
> other host it's talking to is behind a SIIT translator"? Or something else?

No, exactly that. SIIT is defined as a stateless translation,
and there's no direct way for a host to know it exists. So if
you get a PTB for <1280, you simply don't know if it's from a
real translator or not in the general case. That's why there's
a DOS risk in the first place.

It would be interesting to know if this matters. It only matters
if there is a significant number of operational paths with the
combination of SIIT and small IPv4 MTUs. I think we need more
data before 6man considers making an incompatible change.

    Brian


From nobody Wed Aug 20 00:40:00 2014
Return-Path: <lorenzo@google.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACF21A6F70 for <opsec@ietfa.amsl.com>; Tue, 19 Aug 2014 15:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable
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 iu0xaGQx5Ny7 for <opsec@ietfa.amsl.com>; Tue, 19 Aug 2014 15:30:01 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962311A6F59 for <opsec@ietf.org>; Tue, 19 Aug 2014 15:30:01 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id tr6so1987810ieb.35 for <opsec@ietf.org>; Tue, 19 Aug 2014 15:30:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=z+p06hkbOpbL8qP3g0YBEKxiGqu8dq3ibLtFfF3EVvM=; b=gYRKZNrINFpwPaK3Oks17p6DUjO4lq201dJx608GrtsaqkffztW8HUxRBpPY8vtRqj FK4DBugMs025Nz/uTGxfCpWJy0GXCTRM4C41tkHV3OCiMLJuxNJtPov5dpIr3ug8alBz Vxsv4vw1Cex8aOhuKk0KlayZL3abQNXcAgjGv/F4LgY0hpSsZC0LCLB9IOe6DWYne0ZG dtpG379XWYEg6FDylOIPL3XveBfY5Izj3A+eGjFwBEwIQAfO+hSE4lf/aTcJE2ptsD9S nVlx9EiSxbGGlgI4rVxLsLSQzslibkcP0mQZUtqGijkSr0RmWSaPTvyhMShP7Gg0ftlS nPsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=z+p06hkbOpbL8qP3g0YBEKxiGqu8dq3ibLtFfF3EVvM=; b=Exbp1QXKURKMDcXAV8NUIjWaxxILZ+YoqrrAnf4smwgb2QN9anTB10B8cW/TY0iiKd P1vBVEHxcGqwkdsVlN38536drDSkbaRO2Wf6nIbEz987JdvveVqhFSQ29gEX7DIhtljd mFKj+9wm0hqman/k4GvCxSyZ8GFof8xc2XjnHmedgdAU3ciy5x/rwzmLrj1sgsk9dUeh XIJLnV7eg7u6ApS4jXQPAQukeI5yI8285Dme//aglhiKN6R9GVaPRbWsr6EDtruXedYc BXclwWRv8J1d+yHGVi1p40sk5B2vwJfYq1b79x1XgfXPVosHf97kM6pRW+sEpb0j1CKe FYnA==
X-Gm-Message-State: ALoCoQkwEcm+dvbx+mLHgmFyGh8D5WS9D6Tg3Eu9ugjAW6U9UaHLHB815v9+KSX0Xehd/dgLtQMX
X-Received: by 10.50.143.101 with SMTP id sd5mr9169419igb.18.1408487400902; Tue, 19 Aug 2014 15:30:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.223.103 with HTTP; Tue, 19 Aug 2014 15:29:40 -0700 (PDT)
In-Reply-To: <53F3931F.9050601@si6networks.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 19 Aug 2014 15:29:40 -0700
Message-ID: <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary=001a1134bad033b15e05010307f1
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/3vPioU0ia1DopQ-Z2VSxz1Iksag
X-Mailman-Approved-At: Wed, 20 Aug 2014 00:39:57 -0700
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 22:30:03 -0000

--001a1134bad033b15e05010307f1
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 19, 2014 at 11:10 AM, Fernando Gont <fgont@si6networks.com>
wrote:

> I must say that I fail to see the need for generating IPv6 atomic
> fragments 8packets with a frag header, which are not really fragmented).
> See e.g. what we wrote in
> <
> http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00
> >.
>

It does seem kind of silly that we say "you must support MTU >= 1280 to run
IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't
simply say that PTB packets < 1280 are invalid?

--001a1134bad033b15e05010307f1
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 19, 2014 at 11:10 AM, Fernando Gont <span dir="ltr">&lt;<a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I must say that I fail to see the need for generating IPv6 atomic<br>
fragments 8packets with a frag header, which are not really fragmented).<br>
See e.g. what we wrote in<br>
&lt;<a href="http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00" target="_blank">http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00</a>&gt;.<br></blockquote><div><br></div>

<div>It does seem kind of silly that we say &quot;you must support MTU &gt;= 1280 to run IPv6&quot; and then allow PTB packets with an MTU &lt; 1280. Any reason we can&#39;t simply say that PTB packets &lt; 1280 are invalid?</div>

</div></div></div>

--001a1134bad033b15e05010307f1--


From nobody Wed Aug 20 00:40:02 2014
Return-Path: <marka@isc.org>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3DB1A6F2A; Tue, 19 Aug 2014 15:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.569
X-Spam-Level: 
X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_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 l6sXHHRjkutD; Tue, 19 Aug 2014 15:47:39 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDC21A6F03; Tue, 19 Aug 2014 15:47:39 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 471063493A5; Tue, 19 Aug 2014 22:47:37 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F09BE160059; Tue, 19 Aug 2014 22:58:50 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 99F89160032; Tue, 19 Aug 2014 22:58:50 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 28B0B1D0F8C9; Wed, 20 Aug 2014 08:47:34 +1000 (EST)
To: Fernando Gont <fgont@si6networks.com>
From: Mark Andrews <marka@isc.org>
References: <53F33C4F.2070807@si6networks.com>
In-reply-to: Your message of "Tue, 19 Aug 2014 09:00:15 -0300." <53F33C4F.2070807@si6networks.com>
Date: Wed, 20 Aug 2014 08:47:34 +1000
Message-Id: <20140819224734.28B0B1D0F8C9@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ZhVW5q7Q6a7frID3BteYjYOsICQ
X-Mailman-Approved-At: Wed, 20 Aug 2014 00:39:57 -0700
Cc: IPv6 Operations <v6ops@ietf.org>, "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 22:47:41 -0000

In message <53F33C4F.2070807@si6networks.com>, Fernando Gont writes:
> Folks,
> 
> Ten days ago or so we published this I-D:
> <http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-
> 00.txt>
> 
> Section 5.2 of the I-D discusses a possible attack vector based on a
> combination of "forged" ICMPv6 PTB messages and IPv6 frag drops by
> operators, along with proposed countermeasures -- on which we'd like to
> hear your comments.
> 
> Since Section 5.2 is in the draft, let me offer a more informal and
> practical explanation:
> 
> 1) It is known that filtering of packets containing IPv6 Extension
> Headers (including the Fragment Header) is widespread (see our I-D above)
> 
> 2) Let us assume that Host A is communicating with Server B, and that
> some node filters fragments between Host A and Server B.

Some node is performing a Denial Of Service attack on the communications
between Host A and Server B.  The logical thing is to remove/reconfigure
the node performing the denial of service attack.  Note the box
that is dropping the fragments is almost certainly controlled by
the owners of A or the owners of B.

> 3) An attacker sends a spoofed ICMPv6 PTB to server B, with a "Next Hop
> MTU<1280), in the hopes of eliciting "atomic fragments" (see
> <http://tools.ietf.org/rfc/rfc6946.txt>) from now on.
> 
> 4) Now server B starts sending IPv6 atomic fragments... And since they
> include a frag header (and in '2)' above we noted that frags are dropped
> on that path), these packets get dropped (i.e., DoS).

The PTB is not the problem.  The Atomic fragments are not the
problem.  The problem is the node that is filtering the packets.
Atomic fragements are easily identifiable.  There is zero reason
to filter them and good reason to let them continue to exist.

Write up a CERT advisary and list all the known firewalls that fail
to pass atomic fragments.

Write a RFC "Firewalls That Drop Atomic Fragments Considered Harmful".

> "Demo" with the icmp6 tool
> (<http://www.si6networks.com/tools/ipv6toolkit>) -- (some addresses have
> been changed (anonimized), but it is trivial to pick a victim server...)
> 
> "2001:db8:1:10:0:1991:8:25" is the server, and
> "2001:5c0:1000:a::e7d" is my own address):
> 
> ---- cut here ----
> ***** First of all, I telnet to port 80 of the server, and
> everything works as expected ****
> 
> fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80
> Trying 2001:db8:1:10:0:1991:8:25...
> Connected to 2001:db8:1:10:0:1991:8:25.
> Escape character is '^]'.
> ^CConnection closed by foreign host.
> 
> **** Now I send the forget ICMPv6 PTB ****
> 
> fgont@satellite:~$ sudo icmp6  --icmp6-packet-too-big -d
> 2001:db8:1:10:0:1991:8:25 --peer-addr 2001:5c0:1000:a::e7d --mtu 1000 -o
> 80 -v
> icmp6: Security assessment tool for attack vectors based on ICMPv6 error
> messages
> 
> IPv6 Source Address: 2001:5c0:1000:a::e7d (automatically selected)
> IPv6 Destination Address: 2001:db8:1:10:0:1991:8:25
> IPv6 Hop Limit: 227 (randomized)
> ICMPv6 Packet Too Big (Type 2), Code 0
> Next-Hop MTU: 1000
> Payload Type: IPv6/TCP (default)
> Source Address: 2001:db8:1:10:0:1991:8:25 (automatically-selected)
> Destination Address: 2001:5c0:1000:a::e7d
> Hop Limit: 237 (randomized)
> Source Port: 80	Destination Port: 38189 (randomized)
> SEQ Number: 734463213 (randomized)	ACK Number: 866605720 (randomized)
> Flags: A (default)	Window: 18944 (randomized)	URG Pointer: 0 (default
> )
> Initial attack packet(s) sent successfully.
> 
> 
> ***** And now I try the same telnet command as above... but it fails,
> because the frags from the server to me are getting dropped somewhere ****
> 
> fgont@satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80
> Trying 2001:db8:1:10:0:1991:8:25...
> [timeout]
> ---- cut here ----
> 
> 
> Of course, in this particular case I just "shot myself". But one could
> do this to DoS connections between mailservers, etc.
> 
> A nice question is: what if e.g....
> 
> 1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and
> react (as expected) by generating atomic fragments, *and*,
> 
> 2) These same BGP servers deem fragmentation as "harmful", and hence
> drop such fragments
> 
> you could essentially DoS traffic between them
> 
> As noted in the I-D, the mitigations seem to be:
> 
> 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6
> PTB, or,
> 
> 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU
> smaller than 1280.
> 
> Thoughts?
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Wed Aug 20 00:40:03 2014
Return-Path: <lorenzo@google.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736831A6FB9 for <opsec@ietfa.amsl.com>; Tue, 19 Aug 2014 16:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_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 9PWnkDTd0F_1 for <opsec@ietfa.amsl.com>; Tue, 19 Aug 2014 16:02:12 -0700 (PDT)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB241A6F9B for <opsec@ietf.org>; Tue, 19 Aug 2014 16:02:11 -0700 (PDT)
Received: by mail-ig0-f179.google.com with SMTP id h18so10412781igc.6 for <opsec@ietf.org>; Tue, 19 Aug 2014 16:02:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dFU++xRywQHGMctoRIY/RoGsaXOcBUCKzHZ63gueQKc=; b=KRhysDzev5xQ/kvvI4fAXXFqhSZVLUfkHYSWlE+GV4cOYhO/7mdTVd+GD8xcAlxJnf bILkwFxLxR8bA1MMl5qSjQzANk7K0NwspV4mlu7p4ctqXhME/xHdVoTe9po08iNku3S0 kFtH/jn/6sgukt/e6RwzKej0ZtHw8n0W+gVBKUbfXDYtVUi1VBxWDoViOTWIB90fT+LY bGy0I76zTn/VTKO37fb8HZswIXr1O7tccPSKQ0T65HxxJHsSIGTC9zO701KKQbmAICr6 kx4AMqQ6dK29vLYOPmhUIaI+QVMX5ytgLAXOZCIjdEZz9Gwb+p94CT93BjRBaRHRmhJy KQdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dFU++xRywQHGMctoRIY/RoGsaXOcBUCKzHZ63gueQKc=; b=Lmn9q0KIDbIhGLD1mQLbTo3alQVb1iT+sh6Xs3tFqy/ou+2aTCbAS/zC/iJKvHBB6A gRIIMt6H5fXtRy/rMpatW9WDHJ4IflJU15LVXxDkvxDTLU0cCqvMTS74nPQsr4v+MZtF 31zzMxeTsOHsHHjIATJQqNlaON42CljNiE7Edr/nLHssBjhGKaSKGmlfLysWIYUS8EDu zNmXKrf0SgJWQOc+8loq6EC4jO6S8vPw1DZBaDwwJLpxzWNuhlNWbQItRbmARItT+2FS 9eO6uh1ZZuw+whWUrEDLNZifBLTqYVxSjCMBl+orfNuAuBYhNwhUhsgaDE1j7JxqE9R9 na7A==
X-Gm-Message-State: ALoCoQmBDxipu3szrbJYA/ILOTWmDW7lJe5HwHHNQYNrDEX+Kw2/qUUDc4yPtyJQhTWT/hFiFEUd
X-Received: by 10.50.33.16 with SMTP id n16mr8924649igi.15.1408489331270; Tue, 19 Aug 2014 16:02:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.223.103 with HTTP; Tue, 19 Aug 2014 16:01:51 -0700 (PDT)
In-Reply-To: <53F3D6AB.4090505@gmail.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 19 Aug 2014 16:01:51 -0700
Message-ID: <CAKD1Yr12GFse+axuKqousWtYhzhKN98V3928yfSn5YofwAdGDQ@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=089e0153840c42c6ca0501037a09
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/RE6pAveDcQP9s15grtt7gfDX5tE
X-Mailman-Approved-At: Wed, 20 Aug 2014 00:39:57 -0700
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 23:02:13 -0000

--089e0153840c42c6ca0501037a09
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 19, 2014 at 3:58 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> > Any reason we can't simply say that PTB packets < 1280 are invalid?
>
> Because of SIIT, that is equivalent to saying that the minimum IPv4
> MTU is now 1260. That might be a discussion worth having, but 576 has
> been around for a long time.
>

Can we then say that PTB packets < 1280 are invalid and should be ignored
by hosts? Or should be ignored unless they are running a SIIT translator?

--089e0153840c42c6ca0501037a09
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Aug 19, 2014 at 3:58 PM, Brian E Carpenter <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:brian.e.carpenter@gmail.com" target=3D"_blank">brian.e.carpente=
r@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">&gt;=
 Any reason we can&#39;t=C2=A0simply say that PTB packets &lt; 1280 are inv=
alid?<br>


<br>
</div></div>Because of SIIT, that is equivalent to saying that the minimum =
IPv4<br>
MTU is now 1260. That might be a discussion worth having, but 576 has<br>
been around for a long time.<br></blockquote><div><br></div><div>Can we the=
n say that PTB packets &lt; 1280 are invalid and should be ignored by hosts=
? Or should be ignored unless they are running a SIIT translator?</div>

</div></div></div>

--089e0153840c42c6ca0501037a09--


From nobody Wed Aug 20 00:40:04 2014
Return-Path: <marka@isc.org>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056D31A6F96; Tue, 19 Aug 2014 18:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.569
X-Spam-Level: 
X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_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 7ZbuaEsRZb2t; Tue, 19 Aug 2014 18:55:30 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5417A1A6FE2; Tue, 19 Aug 2014 18:55:30 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id C9CCC1FCB4D; Wed, 20 Aug 2014 01:55:26 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8118F160059; Wed, 20 Aug 2014 02:06:40 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 518EA160032; Wed, 20 Aug 2014 02:06:40 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 6DB261D117FF; Wed, 20 Aug 2014 11:55:22 +1000 (EST)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com> <53F3E725.6050708@gmail.com>
In-reply-to: Your message of "Wed, 20 Aug 2014 12:09:09 +1200." <53F3E725.6050708@gmail.com>
Date: Wed, 20 Aug 2014 11:55:22 +1000
Message-Id: <20140820015522.6DB261D117FF@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/T4RN_tG07nnBSMmfxfoOCeeepf4
X-Mailman-Approved-At: Wed, 20 Aug 2014 00:39:57 -0700
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 01:55:32 -0000

	576 is the mimimum reassembly buffer size to be supported
	by all IPv4 hosts.  It is *not* the minimum path MTU size.

	The miminum link MTU is 68 bytes.  RFC 791.

	Mark

In message <53F3E725.6050708@gmail.com>, Brian E Carpenter writes:
> On 20/08/2014 11:24, Fernando Gont wrote:
> > Hi, Brian,
> > 
> > On 08/19/2014 07:58 PM, Brian E Carpenter wrote:
> >>> It does seem kind of silly that we say "you must support MTU >= 1280 to r
> un
> >>> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't
> >>> simply say that PTB packets < 1280 are invalid?
> >> Because of SIIT, that is equivalent to saying that the minimum IPv4
> >> MTU is now 1260. That might be a discussion worth having, but 576 has
> >> been around for a long time.
> > 
> > Not sure what you meant about 576... that we can assume that to be a
> > minmum MTU, 
> 
> Yes, that hasn't changed since RFC 791 (although the way fragmentation
> is defined for IPv4 is rather different from IPv6, of course).
> 
> Maybe we consider it acceptable that SIIT will break on paths that
> include a shorter-than-Ethernet link MTU. But we need to make that
> statement explicit.
> 
>   Brian
> 
> or something else?
> > 
> > Thanks!
> > 
> > Cheers,
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Wed Aug 20 00:40:05 2014
Return-Path: <lorenzo@google.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A331A87B1 for <opsec@ietfa.amsl.com>; Tue, 19 Aug 2014 19:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable
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 HGeST8jQkj2Q for <opsec@ietfa.amsl.com>; Tue, 19 Aug 2014 19:42:33 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4BE1A87BF for <opsec@ietf.org>; Tue, 19 Aug 2014 19:42:32 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id x19so2196798ier.34 for <opsec@ietf.org>; Tue, 19 Aug 2014 19:42:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tUI9iMHJ3aHYmlTbJxS4ccUa5T6Y7JHzYo6RWqHCMAc=; b=AESMh+rFBA3IId6RHaLJWLjztMM8kKW+zIpyb6xHsvc3NgFaeopqs5LQlp5vJweWap MHtEat2Wjhq+LAgrTbN5TzcfxmChJN+9/++bQAlh6+sTF3veF7AI/oDMQmfdvZh44TFE MXTzMteZl7b8xhEXBXk9iWaKP4ZbBk2tk+6SuVhBKJzvpYmR3ZvKOTwk5eSknNKwkTTJ Q5ZilWMw+GzQLrUutC1Kacea9PI301KLNI9HvgRBqfIU2vI42ARbfDfi9fqbFNliO559 A+Gj7w+Fw5FlXS+XXDZAfal8HRWTNoOP6V1i43qIbaf81lw/2At675+uZymZ8NXpThWv rN2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tUI9iMHJ3aHYmlTbJxS4ccUa5T6Y7JHzYo6RWqHCMAc=; b=Ra0O8pnhwIGvYAmv+3xYfLXncCcDgCTWgyVjwaWsut6E04mAD8/2Nw6XwYuDG8DIG8 enkJl6OcgxomEqcByteaoOnEQf9urQMxkINv1Ww/zJkzsBJMKQeqxmtWhD1+lvWnG9MM LMNulo05TelrMobnxXVTfndhWyX6nVFB+ff/58097xbtVnrHyUyrTh1t4jRxBb/b4j+/ m/L47CA6q7LZPq5eY9xN1kltFP6W9HnmGWOlzXlgx4o9NcxlRbJdqWN3pw7AkUoZCB8v z/GA8dOF60M/K7lyr1IR9gdkxppm4T1kgRuZ36mdBQGjFcmOXonLv775qh+H/2COCzdm 2AVg==
X-Gm-Message-State: ALoCoQktgCBUY1qIdqEN4vSt88NJi34Gcvyb/lZpscBbGhxcwN1oA6sWFYnMcv/URhKo7/JvfzPa
X-Received: by 10.42.96.132 with SMTP id j4mr44423982icn.16.1408502552239; Tue, 19 Aug 2014 19:42:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.223.103 with HTTP; Tue, 19 Aug 2014 19:42:09 -0700 (PDT)
In-Reply-To: <53F3E41C.3060100@gmail.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com> <CAKD1Yr12GFse+axuKqousWtYhzhKN98V3928yfSn5YofwAdGDQ@mail.gmail.com> <53F3E41C.3060100@gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 19 Aug 2014 19:42:09 -0700
Message-ID: <CAKD1Yr18Lt0=n9jt8dBAOwHe+rqY9MdyU8TQBwYt6Yf6a7o8cA@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=20cf303ea6144ac33b0501068eb0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/RGRwKcGM_VIKREQ4lwmDcGurB3E
X-Mailman-Approved-At: Wed, 20 Aug 2014 00:39:57 -0700
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 02:42:34 -0000

--20cf303ea6144ac33b0501068eb0
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 19, 2014 at 4:56 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> > Can we then say that PTB packets < 1280 are invalid and should be ignored
> > by hosts? Or should be ignored unless they are running a SIIT translator?
>
> The host doesn't know in general if there is a translator downstream
> (except in a DNS64/NAT64 scenario).
>

What does "downstream" mean? Do you mean "the host does not know if the
other host it's talking to is behind a SIIT translator"? Or something else?

--20cf303ea6144ac33b0501068eb0
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 19, 2014 at 4:56 PM, Brian E Carpenter <span dir="ltr">&lt;<a href="mailto:brian.e.carpenter@gmail.com" target="_blank">brian.e.carpenter@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">&gt; Can we then say that PTB packets &lt; 1280 are invalid and should be ignored<br>


&gt; by hosts? Or should be ignored unless they are running a SIIT translator?<br>
<br>
</div></div>The host doesn&#39;t know in general if there is a translator downstream<br>
(except in a DNS64/NAT64 scenario).<br></blockquote><div><br></div><div>What does &quot;downstream&quot; mean? Do you mean &quot;the host does not know if the other host it&#39;s talking to is behind a SIIT translator&quot;? Or something else?</div>

</div></div></div>

--20cf303ea6144ac33b0501068eb0--


From nobody Wed Aug 20 00:52:41 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC501A0056; Wed, 20 Aug 2014 00:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.041
X-Spam-Level: *
X-Spam-Status: No, score=1.041 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DATE_IN_PAST_06_12=1.543, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 JC16zTT1uSJH; Wed, 20 Aug 2014 00:52:34 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743071A0060; Wed, 20 Aug 2014 00:52:30 -0700 (PDT)
Received: from [2001:5c0:1000:a::753] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XK0h0-0001na-0N; Wed, 20 Aug 2014 09:52:26 +0200
Message-ID: <53F3F371.4010402@si6networks.com>
Date: Tue, 19 Aug 2014 22:01:37 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com> <53F3E725.6050708@gmail.com>
In-Reply-To: <53F3E725.6050708@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/g6ByWGuQEBORYVc-poShC1_0lkQ
Cc: IPv6 Operations <v6ops@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>, "opsec@ietf.org" <opsec@ietf.org>, Lorenzo Colitti <lorenzo@google.com>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 07:52:36 -0000

Hi, Brian,

On 08/19/2014 09:09 PM, Brian E Carpenter wrote:
>> On 08/19/2014 07:58 PM, Brian E Carpenter wrote:
>>>> It does seem kind of silly that we say "you must support MTU >= 1280 to run
>>>> IPv6" and then allow PTB packets with an MTU < 1280. Any reason we can't
>>>> simply say that PTB packets < 1280 are invalid?
>>> Because of SIIT, that is equivalent to saying that the minimum IPv4
>>> MTU is now 1260. That might be a discussion worth having, but 576 has
>>> been around for a long time.
>>
>> Not sure what you meant about 576... that we can assume that to be a
>> minmum MTU, 
> 
> Yes, that hasn't changed since RFC 791 

Not really. For v4, 576 is the "minimum reassembly buffer size" (you're
guaranteed to the remote host can reassemble a datagram of that size),
not the minimum MTU.

The IPv4 minimum MTU is actually 68 bytes. While working on RFC5927, I
recall that at least OpenBSD enforced a lower limit as low as (around)
296 bytes, since that accommodated some radio links that were known to
be in use at the time...


> Maybe we consider it acceptable that SIIT will break on paths that
> include a shorter-than-Ethernet link MTU. But we need to make that
> statement explicit.

Or just update SIIT along with deprecating the generation of atomic
fragments. -- At the end of the day, not that long ago there were at
least a handful of implementations that didn't react to ICMPv6 PTB<1280
as required by RFC2460. Some we might already have scenarios in which
the SIIT device expects the host to generate atomic fragments, but it
doesn't.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Aug 20 01:18:43 2014
Return-Path: <tore@fud.no>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197E91A0008; Wed, 20 Aug 2014 01:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.168
X-Spam-Level: 
X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.668] 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 9ldqi11MVQc6; Wed, 20 Aug 2014 01:14:10 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581111A00AB; Wed, 20 Aug 2014 01:14:10 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1000] (port=50726 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <tore@fud.no>) id 1XK11s-0004hw-ID; Wed, 20 Aug 2014 10:14:00 +0200
Message-ID: <53F45871.3040604@fud.no>
Date: Wed, 20 Aug 2014 10:12:33 +0200
From: Tore Anderson <tore@fud.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>,  Fernando Gont <fgont@si6networks.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com> <53F3E725.6050708@gmail.com>
In-Reply-To: <53F3E725.6050708@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/jFUoRe_xXlEppod_bIKdR8uXrmc
X-Mailman-Approved-At: Wed, 20 Aug 2014 01:18:37 -0700
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 08:14:12 -0000

* Brian E Carpenter

> Maybe we consider it acceptable that SIIT will break on paths that
> include a shorter-than-Ethernet link MTU. But we need to make that
> statement explicit.

Making ICMPv6 PTB with MTU < 1280 invalid would only break SIIT for IPv4
paths with an IPv4 MTU, as an ICMPv4 Fragmentation Needed indicating an
MTU value of 1260 would be translated to an ICMPv6 Packet Too Big with
an MTU value of 1280 by the SIIT translator. See RFC 6145 section 4.2.

In other words, "shorter-than-Ethernet link MTU" is fine, IFF the paths
in the IPv4 domain are >=1260 (and obviously >=1280 in the IPv6 domain,
but that is guaranteed irrespective of SIIT).

I discuss this briefly in my SIIT-DC draft here:

http://htmlpreview.github.io/?https://github.com/toreanderson/ietf/blob/master/siit-dc.html#rfc.section.3.8.2

Finally, there is a workaround (described in section 4.5 of my draft).
In a nutshell:

1) Clamp all MTU values in translated ICMPv6 PTBs up to 1280
2) When translating IPv6 packets <=1280 bytes to IPv4, always clear the
DF flag and generate an Identification value.

This will hide the path with the small <1260/1280 IPv4/IPv6 MTU from the
IPv6 node by making the IPv4 network fragment the packets instead.

How common IPv4 paths with an MTU of <1260 are on today's internet, I
don't know. Maybe the RIPE Atlas team could find out for us? It could be
that problem isn't worth losing too much sleep over in the first place.

Tore


From nobody Wed Aug 20 01:28:20 2014
Return-Path: <tore@fud.no>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0791A005D; Wed, 20 Aug 2014 01:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 W8tm4-lnA3u0; Wed, 20 Aug 2014 01:28:17 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3DE1A005C; Wed, 20 Aug 2014 01:28:17 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1000] (port=51076 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <tore@fud.no>) id 1XK1Fc-00051Q-I2; Wed, 20 Aug 2014 10:28:12 +0200
Message-ID: <53F45BC5.2030807@fud.no>
Date: Wed, 20 Aug 2014 10:26:45 +0200
From: Tore Anderson <tore@fud.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>,  Fernando Gont <fgont@si6networks.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com> <53F3DCA1.2080207@si6networks.com> <53F3E725.6050708@gmail.com> <53F45871.3040604@fud.no>
In-Reply-To: <53F45871.3040604@fud.no>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/I78E-Ao6L8FygohIfbOyaj-39no
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 08:28:18 -0000

* Tore Anderson

> Making ICMPv6 PTB with MTU < 1280 invalid would only break SIIT for IPv4
> paths with an IPv4 MTU, [..]

Correction, this should have read «[...] paths with an IPv4 MTU < 1260».

Tore


From nobody Wed Aug 20 01:50:33 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F9B1A0101; Wed, 20 Aug 2014 01:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 fOTwBdLdzH_A; Wed, 20 Aug 2014 01:50:25 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1351A00F9; Wed, 20 Aug 2014 01:50:25 -0700 (PDT)
Received: from [2001:5c0:1000:a::791] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XK1az-0001yI-DA; Wed, 20 Aug 2014 10:50:20 +0200
Message-ID: <53F460D6.4080908@si6networks.com>
Date: Wed, 20 Aug 2014 05:48:22 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>,  Lorenzo Colitti <lorenzo@google.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F3D6AB.4090505@gmail.com> <CAKD1Yr12GFse+axuKqousWtYhzhKN98V3928yfSn5YofwAdGDQ@mail.gmail.com> <53F3E41C.3060100@gmail.com> <CAKD1Yr18Lt0=n9jt8dBAOwHe+rqY9MdyU8TQBwYt6Yf6a7o8cA@mail.gmail.com> <53F41DE2.6020907@gmail.com>
In-Reply-To: <53F41DE2.6020907@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/HGrCaVe5Z5zv6krF_JV_j7htVyQ
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 08:50:28 -0000

Hi, Brian,

On 08/20/2014 01:02 AM, Brian E Carpenter wrote:
>>
>> What does "downstream" mean? Do you mean "the host does not know if the
>> other host it's talking to is behind a SIIT translator"? Or something else?
> 
> No, exactly that. SIIT is defined as a stateless translation,
> and there's no direct way for a host to know it exists. So if
> you get a PTB for <1280, you simply don't know if it's from a
> real translator or not in the general case. That's why there's
> a DOS risk in the first place.
> 
> It would be interesting to know if this matters. It only matters
> if there is a significant number of operational paths with the
> combination of SIIT and small IPv4 MTUs. I think we need more
> data before 6man considers making an incompatible change.

Truth is that, at this point in time, you will not find any significant
number of SIIT deployments for any kind of measurements to be to have
any significance.

It would also depend on the kind of SIIT deployment:

* If the translator is closer to the client, I'd expect that IPv4 path
has at least the 1280 bytes.

* OTOH, if SIIT is being deployed closer to the server (IPv6-only
datacenter sort of thing), then the IPv4 could be... anything (although,
I'd still expect the vast majority to have MTUs of at least 1280 bytes).
But in this case, you really want to avoid IPv6 fragmentation as much as
possible, since sending IPv6 fragments greatly reduces the chances of
your packets from getting there.


In any case, I think that there are some factors to consider here:

* At least some popular OSes were not generating IPv6 atomic fragments
as expected (that includes some rather recent versions of FreeBSD and
Mac OS X). Hence the most robust option is to gracefully handle the case
where the IPv6 node does not generate IPv6 atomic fragments.

* And we're certainly not at a stage in which SIIT deployments are "the
rule". Hence, the earlier this is fixed, the cheaper it gets.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Aug 20 12:20:53 2014
Return-Path: <heard@pobox.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557511A065B for <opsec@ietfa.amsl.com>; Wed, 20 Aug 2014 12:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
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 DZriYedzcHne for <opsec@ietfa.amsl.com>; Wed, 20 Aug 2014 12:20:46 -0700 (PDT)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586C61A06AC for <opsec@ietf.org>; Wed, 20 Aug 2014 12:20:46 -0700 (PDT)
Received: (qmail 7312 invoked from network); 20 Aug 2014 12:20:40 -0700
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Aug 2014 12:20:40 -0700
Date: Wed, 20 Aug 2014 12:20:40 -0700 (PDT)
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: Fernando Gont <fgont@si6networks.com>
In-Reply-To: <53EF9103.2000900@si6networks.com>
Message-ID: <Pine.LNX.4.64.1408200811380.29207@shell4.bayarea.net>
References: <20140816170731.13620.5804.idtracker@ietfa.amsl.com> <53EF9103.2000900@si6networks.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/RYAfkyk6p8bD_3hsCIuip9AKHrk
Cc: OPSEC <opsec@ietf.org>
Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-01.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 19:20:48 -0000

Hello Fernando,

Thanks for addressing my previous comments about destination 
options.  I have a few comments on this new version.


Last paragraph of the introduction:

   Section 3 of this document discusses IPv6 extension headers and IPv6
   options, and provides advice in the area of filtering IPv6 packets
   that contain such IPv6 Extension Headers and/or options.

This needs a small editorial fix since Section 3 discusses extension 
headers and Section 4 discusses specific options.


Section 2.2:

   The advice provided in this document is only meant to guide an
   operator in configuring forwarding devices, and is *not* to be
   interpreted as advice regarding default configuration settings for
   network devices.  That is, this document provides advice with respect
   to operational configurations, but does not change the implementation
   defaults required by [RFC7045].

The second half of the first sentence is not quite tre, since the 
draft does provide advice on default processing of the CALIPSO 
option.  There is no equivalent to RFC 7045 for options, so 
presumably the defaults specified in RFC 2460 for an intermediate 
system would apply.  These are:

- pass by default all options in a Destination Options header

- obey the instructions in the top two bits of the option type for 
  options in a Hop-by-Hop Options header

My inclination is to suggest that Section 2.2 be beefed up to point 
this out, e.g., by saying

   The advice provided in this document is only meant to guide an
   operator in configuring forwarding devices, and is *not* to be
   interpreted as advice regarding default configuration settings for
   network devices.  That is, this document provides advice with respect
   to operational configurations, but does not change the implementation
   defaults required by [RFC7045] and [RFC2460].

and to suggest that all advice for option implementation defaults be 
left out of this document -- at most, it should be pointed out what 
the default configuration default _is_.


Section 3.3.1.1, uses of Hop-by-Hop option header, fails to mention 
the following hop-by-hop options:

   o  Quick-Start     [RFC4782]
   o  CALIPSO         [RFC5570]

I missed this the first time around, sorry about that.  Also, as an 
editorial nit, I would suggest either including the type in this 
list, as was done in Section 3.3.6.2, or leaving it out in both 
places (and while I am at it, I would also suggest listing the 
options in the same subsection in both places, either Uses or 
Specification -- I also missed that in my previous comments).


Section 3.10.5, advice regarding experimental use headers (253/254):

Advice from -00:
   Routers, security gateways, and firewalls SHOULD have configuration
   knobs for IP packets that contain this extension header to select
   between "ignore & forward" and "drop & log".  Otherwise, no
   legitimate experiment using these options will be able to traverse
   any IP router.

   The aforementioned configuration knob SHOULD default to "drop & log".

   Special care needs to be taken in the case of "drop & log".  Devices
   SHOULD count the number of packets dropped, but the logging of drop
   events SHOULD be limited so as to not overburden device resources.

Advice from -01:
   Intermediate systems should discard packets containing these 
   extension headers.

Presumably the reason for this change to avoid giving advice to 
implementors regarding the default configuration and to focus on 
advice to operators on what configuration to set.  If so, maybe 
something along the following lines would have less dissonance with 
the preceding paragraphs (c.f. jumbogram option advice):

Alternative advice:
   Intermediate systems should discard packets containing these 
   extension headers.  This policy could be overridden in specific 
   environments where the experimental headers are used.


General comment on Section 4, advice about options:  should the 
advice be nuanced to distinguish between cases where an option 
appears in a Hop-by-Hop option header vs a Destination Options 
header?  For instance, should the advice be to discard all options 
that are supposed to appear only in a Destination Options header if 
they appear in a Hop-by-Hop options header?  This is done for Tunnel 
Encapsulation Limit but not for other destination options (other 
than Line-Identification, for which the advice is unconditional 
discard).  Also, should it be recommended that implemention allow 
separate polcies for these cases?


Section 4.3.6.5, advice on Router Alert option:

Current text:
   Intermediate systems should discard packets that contain this option.

Recommended text:
   Intermediate systems should discard packets that contain this option.
   This policy could be overridden in specific environments where
   support for RSVP or similar protocols is desired.


Section 4.3.8.5, advice on processing CALIPSO option: eliminate the 
text that provides advice about implentation defaults.


Section 4.3.17.1, Uses if RFC3692-style experimental options: I 
would recommend s/MUST NOT/must not/ since this document does not 
levy that requirement -- RFC 4727 does.


Section 4.3.17.5, advice regarding RFC3692-style experimental options:

Current text:
   Intermediate systems should discard packets that contain these
   options.

Recommended text:
   Intermediate systems should discard packets that contain these
   options.  This policy could be overridden in specific environments 
   where support for one or more of these options is desired.


Unknown options: there is no section covering these.  I am not 
concerned if the RFC 2460 implementation defaults (i.e., obey the 
instructions in the top two bits of the option type) is 
operationally acceptable.


Thanks for considering these comments.

Mike Heard

On Sat, 16 Aug 2014, Fernando Gont wrote:
> Folks,
> 
> This revision
> (<http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-01.txt>)
> of the I-D should address the comments that you have sent so far. Please
> do let us know if this is the case.
> 
> Thanks!
> 
> Best regards,
> Fernando (& co-authors)
> 
> 
> 
> 
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-gont-opsec-ipv6-eh-filtering-01.txt
> Date: Sat, 16 Aug 2014 10:07:31 -0700
> From: internet-drafts@ietf.org
> To: Will(Shucheng) Liu <liushucheng@huawei.com>, Shucheng LIU (Will)
> <liushucheng@huawei.com>, Fernando Gont <fgont@si6networks.com>, Ron
> Bonica <rbonica@juniper.net>, Fernando Gont <fgont@si6networks.com>,
> Ronald P. Bonica <rbonica@juniper.net>
> 
> 
> A new version of I-D, draft-gont-opsec-ipv6-eh-filtering-01.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
> 
> Name:		draft-gont-opsec-ipv6-eh-filtering
> Revision:	01
> Title:		Recommendations on Filtering of IPv6 Packets Containing IPv6
> Extension Headers
> Document date:	2014-08-16
> Group:		Individual Submission
> Pages:		28
> URL:
> http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-eh-filtering/
> Htmlized:
> http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-gont-opsec-ipv6-eh-filtering-01
> 
> Abstract:
>    This document provides advice on the filtering of IPv6 packets based
>    on the IPv6 Extension Headers and the IPv6 options they contain.
>    Additionally, it discusses the operational and interoperability
>    implications of discarding packets based on the IPv6 Extension
>    Headers and IPv6 options they contain.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> 
> 


From nobody Wed Aug 20 13:37:50 2014
Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284951A6ED9; Wed, 20 Aug 2014 13:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 huzH7f0qx6nc; Wed, 20 Aug 2014 13:37:44 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200561A0422; Wed, 20 Aug 2014 13:37:43 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id f8so7515528wiw.6 for <multiple recipients>; Wed, 20 Aug 2014 13:37:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3dFqapswngjp4KCcx+xczTKG9UE3l0TAiGYOVsLRRTw=; b=pFh5ImtlYGsy3FZjIPPOiYaW6HowPTmWsF2YkI8R8clnGVjpWmZ1HnMzfEHVkCUhlL 377TEK5mRfawhpeZi4a+4LzUe23uKZ1j3uDTVj3dYXiEdPLOeUFFbpacbZmjsq60DFAz lD4G+60tChEvDsrG0kkYJhw7L9kCzNlygquioRVjWSr+oxx0UYxeUurabNB34XaJWF7U uoBO9Gn92olV+/pGzmACWSaWs0+xLTv3Z+p2rB+cXAj6o9DDcH0K7/OQZTbBkJHJGUrm QJ8h2N6bEY5w1qM5zgQ/H4DzQk/uA0Bzzg5mFkswn5BzBHEBcw+mXr86uuDYRspUx/qE KJ5g==
MIME-Version: 1.0
X-Received: by 10.194.62.104 with SMTP id x8mr63324509wjr.7.1408567062677; Wed, 20 Aug 2014 13:37:42 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.123.164 with HTTP; Wed, 20 Aug 2014 13:37:42 -0700 (PDT)
In-Reply-To: <53F3931F.9050601@si6networks.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com>
Date: Wed, 20 Aug 2014 13:37:42 -0700
X-Google-Sender-Auth: kd8v3_kOZXB0E9EwGh2nO5a2k_0
Message-ID: <CAJE_bqeJBBghP=qXcYUOqQwTPky0uqoog=ifu0pqGi0zycu8kw@mail.gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/1pqckLVYaqqZQ5B302Y79diOLoc
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 20:37:46 -0000

At Tue, 19 Aug 2014 15:10:39 -0300,
Fernando Gont <fgont@si6networks.com> wrote:

> > If so, one possible alternative would be to drop such ICMPv6 PTB
> > unless the source IPv6 address is one of those reserved for such use
> > (as defined in RFC 6052).
>
> Source of the ICMPv6 message?

I was not really accurate - I should have said the destination address
of the original IPv6 packet that triggered the ICMPv6 PTB.  But in
this specific case, the effect should be the same in practice, since
the source of the ICMPv6 PTB is the translator box, which would use
the destination of the original IPv6 packet as the source of the
ICMPv6.

> If so, I'd say that while that's certainly
> better than the current situation, unless there's widespread deployment
> of BCP38, an attacker could still forge an ICMPv6 with one of such
> addresses and still perform the attack..

In your previous/other messages you emphasized that the attack cannot
be prevented by BCP38, seemingly to back the conclusion that
completely killing PTB<1280 is the best option.  Bringing the point
that BCP38 isn't widely deployed once you saw a scenario where it
could be a measure makes me doubt the credibility of this discussion:
if your goal was to convince people with your preferred solution
(which itself is perfectly fine), I'd rather see the discussion that
way from the beginning, than listing possible options and soliciting
general "thoughts".

But anyway, even the point with the deployability of BCP38 is not that
important in this case.  The key part is here:

>> And, unless/until we heavily rely on such
>> types of translators, this may be actually sufficient in practice,
>> since in the vast majority of legitimate cases we should use different
>> addresses than those special ones.

If SIIT-type of translators aren't really deployed at least yet (which
we all seem to agree on), dropping the offending ICMPv6 PTB except for
these special addresses effectively works as dropping them
unconditionally.  It still works better than dropping all such ICMPv6
PTB for the unlikely case of having serious deployments of SIIT, in
that we don't break existing practices (although they need to decide
whether to keep using it at the cost of seeing the DoS discussed
here).  And, while the SIIT-kind of spec may have to be revised
because of this issue, we can still allow experimental/serious
deployment of it at their own risk.  If and when such revision of the
spec is completed and reasonably deployed, we can then consider
killing ICMPv6 PTB<1280 completely.

> I must say that I fail to see the need for generating IPv6 atomic
> fragments 8packets with a frag header, which are not really fragmented).
> See e.g. what we wrote in
> <http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00>.
>
> Thoughts?

I personally have no problem with deprecating atomic fragments (which
would also deprecate PTB<1280 naturally); I'm not relying on SIIT
myself nor I have any incentive to defend it in general.  So, if
others are also happy with that I'll be too.  But as this thread
actually shows, a proposal of deprecating something can often be
controversial since it can break some existing deployment, and it's
basically impossible to prove there's no such deployment (and the
acceptable deployment level to justify the deprecation is often a
matter of opinion).  Now that I've seen such controversy, I'd
personally prefer more gradual path like the "alternative approach" I
mentioned.

--
JINMEI, Tatuya


From nobody Wed Aug 20 14:26:38 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D881A6EF3; Wed, 20 Aug 2014 14:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 BBoJ1zEVRkA9; Wed, 20 Aug 2014 14:26:32 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229991A2119; Wed, 20 Aug 2014 14:26:31 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XKDOn-0007mz-A8; Wed, 20 Aug 2014 23:26:29 +0200
Message-ID: <53F51269.8070506@si6networks.com>
Date: Wed, 20 Aug 2014 18:26:01 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
References: <53F33C4F.2070807@si6networks.com>	<CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com>	<53F3931F.9050601@si6networks.com> <CAJE_bqeJBBghP=qXcYUOqQwTPky0uqoog=ifu0pqGi0zycu8kw@mail.gmail.com>
In-Reply-To: <CAJE_bqeJBBghP=qXcYUOqQwTPky0uqoog=ifu0pqGi0zycu8kw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/5IpMgiTgFvms1iChB81hDH-Gq4s
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 21:26:34 -0000

Jinmei,

On 08/20/2014 05:37 PM, 神明達哉 wrote:
>> If so, I'd say that while that's certainly
>> better than the current situation, unless there's widespread deployment
>> of BCP38, an attacker could still forge an ICMPv6 with one of such
>> addresses and still perform the attack..
> 
> In your previous/other messages you emphasized that the attack cannot
> be prevented by BCP38, seemingly to back the conclusion that
> completely killing PTB<1280 is the best option.

I never said that. And that certainly wasn't my line of reasoning.

I emphasized that BCP38 doesn't block the attack, because BCP38 does
block many/most of this sort of attack (e.g., attacks against TCP
connections, etc.).

Then,  we came up with one possible way to mitigate this vulnerability
and asked for comments.



> Bringing the point
> that BCP38 isn't widely deployed once you saw a scenario where it
> could be a measure makes me doubt the credibility of this discussion:
> if your goal was to convince people with your preferred solution
> (which itself is perfectly fine), I'd rather see the discussion that
> way from the beginning, than listing possible options and soliciting
> general "thoughts".

I asked for "thoughts" because I might have missed or overlooked
something, or someone might come up with a better idea. Given options so
far, I tried to analyze pros and cons. The one you suggested addresses
only one of the two kinds of translators (if I understood correctly),
and may still leave the door open in some scenarios. That's why I
concluded that the one we originally offered still seemed like the best
way to fix this. (i.e., me thinking out loud rather that anything else)



>>> And, unless/until we heavily rely on such
>>> types of translators, this may be actually sufficient in practice,
>>> since in the vast majority of legitimate cases we should use different
>>> addresses than those special ones.
> 
> If SIIT-type of translators aren't really deployed at least yet (which
> we all seem to agree on), dropping the offending ICMPv6 PTB except for
> these special addresses effectively works as dropping them
> unconditionally.  It still works better than dropping all such ICMPv6
> PTB for the unlikely case of having serious deployments of SIIT, in
> that we don't break existing practices (although they need to decide
> whether to keep using it at the cost of seeing the DoS discussed
> here).

FWIW, the "dropping" is by the end node... and if that really is an
issue, then we're already in "trouble", because it turns out that at
least some boxes (some FreeBSD versions, NetBSD, and some Mac OS
versions, fail to produce atomic fragments in response to ICMPv6 PTB).


> And, while the SIIT-kind of spec may have to be revised
> because of this issue, we can still allow experimental/serious
> deployment of it at their own risk.

It's really "deployment at someone *else's* risk". Because it's the
folks that generate atomic fragments the ones paying the price (and not
the SIIT boxes or deployments).



> I personally have no problem with deprecating atomic fragments (which
> would also deprecate PTB<1280 naturally); I'm not relying on SIIT
> myself nor I have any incentive to defend it in general.  So, if
> others are also happy with that I'll be too.  But as this thread
> actually shows, a proposal of deprecating something can often be
> controversial since it can break some existing deployment, and it's
> basically impossible to prove there's no such deployment (and the
> acceptable deployment level to justify the deprecation is often a
> matter of opinion). 

What breaks what may vary from one case to another. For instance,
relying on atomic fragments implies that you rely on:

1) Both ICMPv4 and ICMPv6 messages not being filtered
2) IPv6 fragments not being filtered
3) Nodes reacting to ICMPv6 PTB<1280

Both 1 through 3 vary from one environment to another... but I'm of the
idea that the lest you rely on them, the better.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Aug 20 14:39:53 2014
Return-Path: <touch@isi.edu>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E46C1A6F0C; Wed, 20 Aug 2014 14:39:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 Ukja48YQ6wkV; Wed, 20 Aug 2014 14:39:49 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7321A8826; Wed, 20 Aug 2014 14:39:43 -0700 (PDT)
Received: from [128.9.184.152] ([128.9.184.152]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s7KLdA4l021830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Aug 2014 14:39:11 -0700 (PDT)
Message-ID: <53F51582.3010003@isi.edu>
Date: Wed, 20 Aug 2014 14:39:14 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>, Fernando Gont <fgont@si6networks.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com>
In-Reply-To: <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/1P0yDZIlAyJJUlP3M6rTlQeB3zU
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 21:39:52 -0000

On 8/19/2014 3:29 PM, Lorenzo Colitti wrote:
> On Tue, Aug 19, 2014 at 11:10 AM, Fernando Gont <fgont@si6networks.com
> <mailto:fgont@si6networks.com>> wrote:
>
>     I must say that I fail to see the need for generating IPv6 atomic
>     fragments 8packets with a frag header, which are not really fragmented).
>     See e.g. what we wrote in
>     <http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00>.
>
>
> It does seem kind of silly that we say "you must support MTU >= 1280 to
> run IPv6" and then allow PTB packets with an MTU < 1280. Any reason we
> can't simply say that PTB packets < 1280 are invalid?

I can't see a good reason that the INT area couldn't do this. I see many 
reasons why V6OPS shouldn't be deciding this.

Joe


From nobody Wed Aug 20 15:20:10 2014
Return-Path: <rdobbins@arbor.net>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0FC1A894F for <opsec@ietfa.amsl.com>; Wed, 20 Aug 2014 15:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
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 Lj4jEmJX3ySO for <opsec@ietfa.amsl.com>; Wed, 20 Aug 2014 15:20:01 -0700 (PDT)
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C7A1A894C for <opsec@ietf.org>; Wed, 20 Aug 2014 15:20:01 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id kx10so12786943pab.34 for <opsec@ietf.org>; Wed, 20 Aug 2014 15:19:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6wcpzfMChGUd8U5tRFTTSvu8hfjqaUQJogGzblmfUV4=; b=WtOUGE5hveT/7UnoKTZusozlrPiaUkBe4uVrzbcow+EcMYz9EaT0smOfJiYxXXrtNU RBgVuBjgxkisYS/FjY5HG+60/YKFJveM65JlbRpZPkEjYzqjuJkBcc3HZFvHtM75nu2b hU2euehT0YDhO/DBUZmt+ev83uKTch9akTmfxEvN1GYUkksD8RG7DaG6tebeKv5Ee14O e1/aMhaQLfs4XZv8zoOoD27qhDPXBPkFNmPhRX/+FCtSLLFpYdP99lHR76qYFCs+ZBUX vVme49gJS3C8yO82HMLJMB2W7MjUBui47ZrKBGTefnCu6OPs0/ATXg7ticCgi4mv9P6a QUZQ==
X-Gm-Message-State: ALoCoQmv153kLmHiSifAPSFRxRTrQggYoKqmjrYr0njw/jKBblTJAMjj9zkQvzW8seNhESqDfE+l
X-Received: by 10.68.68.234 with SMTP id z10mr55763529pbt.59.1408573199450; Wed, 20 Aug 2014 15:19:59 -0700 (PDT)
Received: from [172.19.254.174] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by mx.google.com with ESMTPSA id ou2sm30754709pdb.17.2014.08.20.15.19.56 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 15:19:58 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Roland Dobbins <rdobbins@arbor.net>
In-Reply-To: <53F51582.3010003@isi.edu>
Date: Thu, 21 Aug 2014 05:19:48 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <C12AE5E4-FA90-42B0-A1C2-4974BEA2686D@arbor.net>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAKD1Yr3SrY2Qubj2NRd=PSjtt4Efwdk2xZCs4F7-JEgYuq-x6Q@mail.gmail.com> <53F51582.3010003@isi.edu>
To: "opsec@ietf.org" <opsec@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Y1KE--I2IgJR29sPeH3W9TGGMz0
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 22:20:04 -0000

On Aug 21, 2014, at 4:39 AM, Joe Touch <touch@ISI.EDU> wrote:

> I can't see a good reason that the INT area couldn't do this.

Personally, I don't think it's practical, given the realities of legacy =
deployments, et. al.

> I see many reasons why V6OPS shouldn't be deciding this.

Concur 100%.

----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

                   Equo ne credite, Teucri.

    		   	  -- Laoco=F6n


From nobody Wed Aug 20 18:07:45 2014
Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A4A1A6F97; Wed, 20 Aug 2014 18:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 qbp57lIkyg2C; Wed, 20 Aug 2014 18:07:24 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D0B1A0027; Wed, 20 Aug 2014 18:07:23 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id k14so8657812wgh.32 for <multiple recipients>; Wed, 20 Aug 2014 18:07:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6xJP+fndDEfW3sNzb8gbnwqnWmza4whyJrHhnJ/YeD0=; b=rEZmIps4A/NsowR+rH8SKH8SHYz3DGKyYSM9Q9zyr0kTRzc1xFCF5Vra1Nvh/gHII1 NX6OvGH3dMByejEQ5vVyX5Vv8I6hhtRUjzwfljl2FGZO8yx6cSC86oam8DMzyXHBXY2d dRX2SVQaG3uIAM4aeRVRjh9fUOQnv0Jvijta43lgdxL2FoEgGhz1bN6NinbvmcczCmQj eB0w8FJGCJW2UWn3iUnJORhPCSvTaM96C9xJaKcHjP+sbXFiyVr1I+i7uTdSgG8PcPo1 j6/hRTzGDtH4yREHNNSwLTdSz5D1BztZmIlJ4YtZM2YHi9Jbz7JzH0LaKVj79OmEfz38 fifg==
MIME-Version: 1.0
X-Received: by 10.194.62.104 with SMTP id x8mr64782718wjr.7.1408583241922; Wed, 20 Aug 2014 18:07:21 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.123.164 with HTTP; Wed, 20 Aug 2014 18:07:21 -0700 (PDT)
In-Reply-To: <53F51269.8070506@si6networks.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAJE_bqeJBBghP=qXcYUOqQwTPky0uqoog=ifu0pqGi0zycu8kw@mail.gmail.com> <53F51269.8070506@si6networks.com>
Date: Wed, 20 Aug 2014 18:07:21 -0700
X-Google-Sender-Auth: TcTSDfnqhuDnlX0IT5Y7BVNJn10
Message-ID: <CAJE_bqfgp-dpGnPFGKqYNGQK_TszZ8656AJbnQihenks=t9d1w@mail.gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/hf3mt7BbfVglpoDag1z5RWukSiU
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 01:07:25 -0000

At Wed, 20 Aug 2014 18:26:01 -0300,
Fernando Gont <fgont@si6networks.com> wrote:

> [...] The one you suggested addresses
> only one of the two kinds of translators (if I understood correctly),
> and may still leave the door open in some scenarios.

Specifically?

> > And, while the SIIT-kind of spec may have to be revised
> > because of this issue, we can still allow experimental/serious
> > deployment of it at their own risk.
>
> It's really "deployment at someone *else's* risk". Because it's the
> folks that generate atomic fragments the ones paying the price (and not
> the SIIT boxes or deployments).

If the deployment/experiment of SIIT is real but we still ban
PTB<1280 as a first step of revision, they (= someone *else*) will
need to pay some price anyway: either they can be susceptible to the
DoS in question or they can see some strange failure when IPv4
fragmentation is needed.  Certainly, we should fix SIIT(-kind)
of translators for a longer term.  So it seems to me the question of
which kind of cost we ask "them" for paying until then.

I thought the gradual approach would be less controversial than an
abrupt ban and allow us to use our time more efficiently, so I
mentioned it (I actually didn't intend to "suggest" it, as I
personally don't have a strong stake on it).  I know you have a
different opinion and I respect that.  I just wish it would be
accepted smoothly.

> > I personally have no problem with deprecating atomic fragments (which
> > would also deprecate PTB<1280 naturally); I'm not relying on SIIT
> > myself nor I have any incentive to defend it in general.  So, if
> > others are also happy with that I'll be too.  But as this thread
> > actually shows, a proposal of deprecating something can often be
> > controversial since it can break some existing deployment, and it's
> > basically impossible to prove there's no such deployment (and the
> > acceptable deployment level to justify the deprecation is often a
> > matter of opinion).
>
> What breaks what may vary from one case to another. For instance,
> relying on atomic fragments implies that you rely on:
>
> 1) Both ICMPv4 and ICMPv6 messages not being filtered
> 2) IPv6 fragments not being filtered
> 3) Nodes reacting to ICMPv6 PTB<1280
>
> Both 1 through 3 vary from one environment to another... but I'm of the
> idea that the lest you rely on them, the better.

Same as above.  It just seems to be that we have different
expectations on the feasibility of options from different point of
views.  As you still seem to believe your preferred option is more
feasible in terms of the standardization process, I have nothing more
to say; I have no reason to push the alternative I mentioned, so
please simply ignore it and try to persuade others.

--
JINMEI, Tatuya


From nobody Thu Aug 21 00:18:48 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C8B1A0681; Thu, 21 Aug 2014 00:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 uQXiUyIJh0NR; Thu, 21 Aug 2014 00:18:32 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420111A0652; Thu, 21 Aug 2014 00:18:32 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XKMdf-0004wH-Tm; Thu, 21 Aug 2014 09:18:28 +0200
Message-ID: <53F590A2.2090101@si6networks.com>
Date: Thu, 21 Aug 2014 03:24:34 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
References: <53F33C4F.2070807@si6networks.com>	<CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com>	<53F3931F.9050601@si6networks.com>	<CAJE_bqeJBBghP=qXcYUOqQwTPky0uqoog=ifu0pqGi0zycu8kw@mail.gmail.com>	<53F51269.8070506@si6networks.com> <CAJE_bqfgp-dpGnPFGKqYNGQK_TszZ8656AJbnQihenks=t9d1w@mail.gmail.com>
In-Reply-To: <CAJE_bqfgp-dpGnPFGKqYNGQK_TszZ8656AJbnQihenks=t9d1w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/fIsgHf-_OtLb3VD8FA7x9Ind7gE
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 07:18:35 -0000

On 08/20/2014 10:07 PM, 神明達哉 wrote:
> At Wed, 20 Aug 2014 18:26:01 -0300,
> Fernando Gont <fgont@si6networks.com> wrote:
> 
>> [...] The one you suggested addresses
>> only one of the two kinds of translators (if I understood correctly),
>> and may still leave the door open in some scenarios.
> 
> Specifically?

Well, you can only really apply the suggested check to the stateless
translation scenario. But since a host does not now where it will be
deployed, it cannot (out of the box) require that e.g. ICMPv6 PTB<1280
use any specific part of the address space.

Put another way, the mitigation would not "just work out of the box" for
any of the servers running on the public Internet.

And then, for the scenarios "a" or "c" from Section 2 of RFC6144, you
still need to enforce filtering to prevent attacks within the IPv6 network.




>>> And, while the SIIT-kind of spec may have to be revised
>>> because of this issue, we can still allow experimental/serious
>>> deployment of it at their own risk.
>>
>> It's really "deployment at someone *else's* risk". Because it's the
>> folks that generate atomic fragments the ones paying the price (and not
>> the SIIT boxes or deployments).
> 
> If the deployment/experiment of SIIT is real but we still ban
> PTB<1280 as a first step of revision, they (= someone *else*) will
> need to pay some price anyway: either they can be susceptible to the
> DoS in question or they can see some strange failure when IPv4
> fragmentation is needed.  Certainly, we should fix SIIT(-kind)
> of translators for a longer term.  So it seems to me the question of
> which kind of cost we ask "them" for paying until then.

Reading though RFC6145, I see that in quite a few places the spec
considers "configuration options" and the like t be able to cope with
IPv6 packet drops, and fragmentation -- but for a different than
security (the ones that I've mentioned below).

For instance, Section 6 of RFC6145 says:
   Two recent studies analyzed the behavior of IPv6-capable web servers
   on the Internet and found that approximately 95% responded as
   expected to an IPv6 Packet Too Big that indicated MTU = 1280, but
   only 43% responded as expected to an IPv6 Packet Too Big that
   indicated an MTU < 1280.

Put another way, we are leaving the door open to attack due to something
that is giving us a 60% failure rate already.



> I thought the gradual approach would be less controversial than an
> abrupt ban and allow us to use our time more efficiently, so I
> mentioned it 

Just a request for clarification: The "gradual path" would be to enforce
additional requirements on the ICMPv6 PTB messages?



>> What breaks what may vary from one case to another. For instance,
>> relying on atomic fragments implies that you rely on:
>>
>> 1) Both ICMPv4 and ICMPv6 messages not being filtered
>> 2) IPv6 fragments not being filtered
>> 3) Nodes reacting to ICMPv6 PTB<1280
>>
>> Both 1 through 3 vary from one environment to another... but I'm of the
>> idea that the lest you rely on them, the better.
> 
> Same as above.  It just seems to be that we have different
> expectations on the feasibility of options from different point of
> views.  As you still seem to believe your preferred option is more
> feasible in terms of the standardization process,

I have no idea about which options is "more feasible in terms of
standardization process", to be honest. For the time being, I'm just
rethinking/re-evaluating options, even if just for the technical/mental
exercise of figuring out what would be the best approach. And kind of
hope that if the analysis is correct, that may result in "feasibility in
terms of standardization process".

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Aug 21 06:58:44 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EF91A02ED for <opsec@ietfa.amsl.com>; Thu, 21 Aug 2014 06:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 FUkgOiNUK136 for <opsec@ietfa.amsl.com>; Thu, 21 Aug 2014 06:58:40 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52351A02E4 for <opsec@ietf.org>; Thu, 21 Aug 2014 06:58:39 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XKSst-00066q-NE; Thu, 21 Aug 2014 15:58:36 +0200
Message-ID: <53F5FAF6.1010000@si6networks.com>
Date: Thu, 21 Aug 2014 10:58:14 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "C. M. Heard" <heard@pobox.com>
References: <20140816170731.13620.5804.idtracker@ietfa.amsl.com> <53EF9103.2000900@si6networks.com> <Pine.LNX.4.64.1408200811380.29207@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.64.1408200811380.29207@shell4.bayarea.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/KwrzZzYJPMhdZmfn8ffT0KWUMpY
Cc: OPSEC <opsec@ietf.org>
Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-01.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 13:58:43 -0000

Hi, Mike,

Thanks so much for your feedback! Please find my comments in-line....

On 08/20/2014 04:20 PM, C. M. Heard wrote:
> 
> Last paragraph of the introduction:
> 
>    Section 3 of this document discusses IPv6 extension headers and IPv6
>    options, and provides advice in the area of filtering IPv6 packets
>    that contain such IPv6 Extension Headers and/or options.
> 
> This needs a small editorial fix since Section 3 discusses extension 
> headers and Section 4 discusses specific options.

Yep. Fixed.


> Section 2.2:
> 
>    The advice provided in this document is only meant to guide an
>    operator in configuring forwarding devices, and is *not* to be
>    interpreted as advice regarding default configuration settings for
>    network devices.  That is, this document provides advice with respect
>    to operational configurations, but does not change the implementation
>    defaults required by [RFC7045].
> 
> The second half of the first sentence is not quite tre, since the 
> draft does provide advice on default processing of the CALIPSO 
> option.  

We will remove this "default configuration" thing for this option, such
that there is coherence throughout the document in this respect
(recommending defaults for options but not for EHs would likely lead to
confusion).

Thoughts?


> My inclination is to suggest that Section 2.2 be beefed up to point 
> this out, e.g., by saying
> 
>    The advice provided in this document is only meant to guide an
>    operator in configuring forwarding devices, and is *not* to be
>    interpreted as advice regarding default configuration settings for
>    network devices.  That is, this document provides advice with respect
>    to operational configurations, but does not change the implementation
>    defaults required by [RFC7045] and [RFC2460].
> 
> and to suggest that all advice for option implementation defaults be 
> left out of this document -- at most, it should be pointed out what 
> the default configuration default _is_.

Agreed.



> Section 3.3.1.1, uses of Hop-by-Hop option header, fails to mention 
> the following hop-by-hop options:
> 
>    o  Quick-Start     [RFC4782]
>    o  CALIPSO         [RFC5570]
> 
> I missed this the first time around, sorry about that.  Also, as an 
> editorial nit, I would suggest either including the type in this 
> list, as was done in Section 3.3.6.2, or leaving it out in both 
> places (and while I am at it, I would also suggest listing the 
> options in the same subsection in both places, either Uses or 
> Specification -- I also missed that in my previous comments).

All of these are good points. We will fix all of them in the next
revision. Thanks!



> Section 3.10.5, advice regarding experimental use headers (253/254):
> 
> Advice from -00:
>    Routers, security gateways, and firewalls SHOULD have configuration
>    knobs for IP packets that contain this extension header to select
>    between "ignore & forward" and "drop & log".  Otherwise, no
>    legitimate experiment using these options will be able to traverse
>    any IP router.
> 
>    The aforementioned configuration knob SHOULD default to "drop & log".
> 
>    Special care needs to be taken in the case of "drop & log".  Devices
>    SHOULD count the number of packets dropped, but the logging of drop
>    events SHOULD be limited so as to not overburden device resources.
> 
> Advice from -01:
>    Intermediate systems should discard packets containing these 
>    extension headers.
> 
> Presumably the reason for this change to avoid giving advice to 
> implementors regarding the default configuration and to focus on 
> advice to operators on what configuration to set. 

Exactly. This was the motivation for removing such text.


> If so, maybe 
> something along the following lines would have less dissonance with 
> the preceding paragraphs (c.f. jumbogram option advice):
> 
> Alternative advice:
>    Intermediate systems should discard packets containing these 
>    extension headers.  This policy could be overridden in specific 
>    environments where the experimental headers are used.

The thing is that "this policy could be overriden.." sounds a bit like
defining configuration defaults. mm.. how about:

    Intermediate systems should discard packets containing these
    extension headers.  Only in in specific scenarios in which
    experiments are to be performed, an operator may want to permit
    these extension headers.

?


> General comment on Section 4, advice about options:  should the 
> advice be nuanced to distinguish between cases where an option 
> appears in a Hop-by-Hop option header vs a Destination Options 
> header?

Yes. Even if te advice ends up being the same. I will check if there are
any options (other than the padding ones) that cane be included in
different EH types (of the top of my head, most of the options are meant
for specific EH types).


> For instance, should the advice be to discard all options 
> that are supposed to appear only in a Destination Options header if 
> they appear in a Hop-by-Hop options header?  This is done for Tunnel 
> Encapsulation Limit but not for other destination options (other 
> than Line-Identification, for which the advice is unconditional 
> discard). 

Yes. I will make sure we do this for all options.


> Also, should it be recommended that implemention allow separate polcies for these cases?

I would think so.


> 
> 
> Section 4.3.6.5, advice on Router Alert option:
> 
> Current text:
>    Intermediate systems should discard packets that contain this option.
> 
> Recommended text:
>    Intermediate systems should discard packets that contain this option.
>    This policy could be overridden in specific environments where
>    support for RSVP or similar protocols is desired.

I agree with the recommended text, but as with the experimental options
above, I'd edit it as:

  Intermediate systems should discard packets that contain this option.
  Only in specific environments where support for RSVP or similar
  protocols is desired should this option be permitted.


Thoughts?



> Section 4.3.8.5, advice on processing CALIPSO option: eliminate the 
> text that provides advice about implentation defaults.

Will do.



> Section 4.3.17.1, Uses if RFC3692-style experimental options: I 
> would recommend s/MUST NOT/must not/ since this document does not 
> levy that requirement -- RFC 4727 does.

Correct. Will do.



> Section 4.3.17.5, advice regarding RFC3692-style experimental options:
> 
> Current text:
>    Intermediate systems should discard packets that contain these
>    options.
> 
> Recommended text:
>    Intermediate systems should discard packets that contain these
>    options.  This policy could be overridden in specific environments 
>    where support for one or more of these options is desired.

How about tweaking this text as I did above?


> Unknown options: there is no section covering these.  I am not 
> concerned if the RFC 2460 implementation defaults (i.e., obey the 
> instructions in the top two bits of the option type) is 
> operationally acceptable.

mm.. let me think about this one -- I'll come back to you.

Thanks so much!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Aug 21 07:54:01 2014
Return-Path: <heard@pobox.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF331A6F0B for <opsec@ietfa.amsl.com>; Thu, 21 Aug 2014 07:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
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 EszLvrMiZn0X for <opsec@ietfa.amsl.com>; Thu, 21 Aug 2014 07:53:56 -0700 (PDT)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761181A6EDB for <opsec@ietf.org>; Thu, 21 Aug 2014 07:53:55 -0700 (PDT)
Received: (qmail 13322 invoked from network); 21 Aug 2014 07:53:52 -0700
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Aug 2014 07:53:52 -0700
Date: Thu, 21 Aug 2014 07:53:52 -0700 (PDT)
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: Fernando Gont <fgont@si6networks.com>
In-Reply-To: <53F5FAF6.1010000@si6networks.com>
Message-ID: <Pine.LNX.4.64.1408210742020.27546@shell4.bayarea.net>
References: <20140816170731.13620.5804.idtracker@ietfa.amsl.com> <53EF9103.2000900@si6networks.com> <Pine.LNX.4.64.1408200811380.29207@shell4.bayarea.net> <53F5FAF6.1010000@si6networks.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ftT9mKfGlK0rHxlYq_UP-cA51xE
Cc: OPSEC <opsec@ietf.org>
Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-01.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 14:53:58 -0000

Hello Fernando,

Thanks for the quick reply.  Your responses all work for me.  Just a 
couple of small comments ...

On Thu, 21 Aug 2014, Fernando Gont wrote:
> On 08/20/2014 04:20 PM, C. M. Heard wrote:
> > Alternative advice:
> >    Intermediate systems should discard packets containing these 
> >    extension headers.  This policy could be overridden in specific 
> >    environments where the experimental headers are used.
> 
> The thing is that "this policy could be overriden.." sounds a bit like
> defining configuration defaults. mm.. how about:
> 
>     Intermediate systems should discard packets containing these
>     extension headers.  Only in in specific scenarios in which
>     experiments are to be performed, an operator may want to permit
>     these extension headers.

That works for me (as do the other tweaks of a similar nature that 
you suggested).  I suggested the text "This policy could be 
overridden ..." because it appeared elsewhere in the draft.  If you 
don't like it here, you may want to do a "search and destroy" 
mission to root it out in other places where it appears.

> > General comment on Section 4, advice about options:  should the 
> > advice be nuanced to distinguish between cases where an option 
> > appears in a Hop-by-Hop option header vs a Destination Options 
> > header?
> 
> Yes. Even if te advice ends up being the same. I will check if there are
> any options (other than the padding ones) that cane be included in
> different EH types (of the top of my head, most of the options are meant
> for specific EH types).

As far as I could tell, the padding options are the only ones that 
are allowed to appear in both kinds of option extension headers.

> > Unknown options: there is no section covering these.  I am not 
> > concerned if the RFC 2460 implementation defaults (i.e., obey the 
> > instructions in the top two bits of the option type) is 
> > operationally acceptable.
> 
> mm.. let me think about this one -- I'll come back to you.

Sounds good.  Thanks again for your efforts.

Mike Heard


From nobody Thu Aug 21 08:06:34 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAA11A89B3 for <opsec@ietfa.amsl.com>; Thu, 21 Aug 2014 08:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 oFsxpbXN0skX for <opsec@ietfa.amsl.com>; Thu, 21 Aug 2014 08:06:19 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C951A0721 for <opsec@ietf.org>; Thu, 21 Aug 2014 08:05:56 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XKTvw-0006NT-RV; Thu, 21 Aug 2014 17:05:49 +0200
Message-ID: <53F60AB6.7080909@si6networks.com>
Date: Thu, 21 Aug 2014 12:05:26 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "C. M. Heard" <heard@pobox.com>
References: <20140816170731.13620.5804.idtracker@ietfa.amsl.com> <53EF9103.2000900@si6networks.com> <Pine.LNX.4.64.1408200811380.29207@shell4.bayarea.net> <53F5FAF6.1010000@si6networks.com> <Pine.LNX.4.64.1408210742020.27546@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.64.1408210742020.27546@shell4.bayarea.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/6RcfZKZJgQh42g8mNwACwm1tI40
Cc: OPSEC <opsec@ietf.org>
Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-01.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 15:06:25 -0000

Hi, Mike,

Thanks again for your feedback! Comments in-line....

On 08/21/2014 11:53 AM, C. M. Heard wrote:
> On Thu, 21 Aug 2014, Fernando Gont wrote:
>> On 08/20/2014 04:20 PM, C. M. Heard wrote:
>>> Alternative advice:
>>>    Intermediate systems should discard packets containing these 
>>>    extension headers.  This policy could be overridden in specific 
>>>    environments where the experimental headers are used.
>>
>> The thing is that "this policy could be overriden.." sounds a bit like
>> defining configuration defaults. mm.. how about:
>>
>>     Intermediate systems should discard packets containing these
>>     extension headers.  Only in in specific scenarios in which
>>     experiments are to be performed, an operator may want to permit
>>     these extension headers.
> 
> That works for me (as do the other tweaks of a similar nature that 
> you suggested).  I suggested the text "This policy could be 
> overridden ..." because it appeared elsewhere in the draft.  If you 
> don't like it here, you may want to do a "search and destroy" 
> mission to root it out in other places where it appears.

It would work for *me*. But I guess tweaking the text a bit might avoid
confusion to others.. -- I will proceed with the search & destroy as
indicated. :-)


>>> General comment on Section 4, advice about options:  should the 
>>> advice be nuanced to distinguish between cases where an option 
>>> appears in a Hop-by-Hop option header vs a Destination Options 
>>> header?
>>
>> Yes. Even if te advice ends up being the same. I will check if there are
>> any options (other than the padding ones) that cane be included in
>> different EH types (of the top of my head, most of the options are meant
>> for specific EH types).
> 
> As far as I could tell, the padding options are the only ones that 
> are allowed to appear in both kinds of option extension headers.

So I guess that for the most part, there's no need of a "per-EH-type"
kind of policy for IPv6 options?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Aug 21 08:58:11 2014
Return-Path: <heard@pobox.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B584D1A040D for <opsec@ietfa.amsl.com>; Thu, 21 Aug 2014 08:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
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 AuCGG4szHlR2 for <opsec@ietfa.amsl.com>; Thu, 21 Aug 2014 08:58:07 -0700 (PDT)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1311A03E2 for <opsec@ietf.org>; Thu, 21 Aug 2014 08:57:58 -0700 (PDT)
Received: (qmail 7638 invoked from network); 21 Aug 2014 08:57:54 -0700
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Aug 2014 08:57:54 -0700
Date: Thu, 21 Aug 2014 08:57:54 -0700 (PDT)
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: Fernando Gont <fgont@si6networks.com>
In-Reply-To: <53F60AB6.7080909@si6networks.com>
Message-ID: <Pine.LNX.4.64.1408210810270.27546@shell4.bayarea.net>
References: <20140816170731.13620.5804.idtracker@ietfa.amsl.com> <53EF9103.2000900@si6networks.com> <Pine.LNX.4.64.1408200811380.29207@shell4.bayarea.net> <53F5FAF6.1010000@si6networks.com> <Pine.LNX.4.64.1408210742020.27546@shell4.bayarea.net> <53F60AB6.7080909@si6networks.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/YSfFQbvqo2WgXIZdMPKoBZHrjL4
Cc: OPSEC <opsec@ietf.org>
Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-01.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 15:58:08 -0000

On Thu, 21 Aug 2014, Fernando Gont wrote:
> On 08/21/2014 11:53 AM, C. M. Heard wrote:
> > On Thu, 21 Aug 2014, Fernando Gont wrote:
> >> On 08/20/2014 04:20 PM, C. M. Heard wrote:
> >>> General comment on Section 4, advice about options:  should the 
> >>> advice be nuanced to distinguish between cases where an option 
> >>> appears in a Hop-by-Hop option header vs a Destination Options 
> >>> header?
> >>
> >> Yes. Even if te advice ends up being the same. I will check if there are
> >> any options (other than the padding ones) that cane be included in
> >> different EH types (of the top of my head, most of the options are meant
> >> for specific EH types).
> > 
> > As far as I could tell, the padding options are the only ones that 
> > are allowed to appear in both kinds of option extension headers.
> 
> So I guess that for the most part, there's no need of a "per-EH-type"
> kind of policy for IPv6 options?

I'm not sure I'd quite say that.

For one thing, I think you agreed that the advice should be to 
discard packets with options that appear in the wrong kind of 
options header.  So the recommended policy for a given option would 
depend on the type of option header in which it appears.  But that 
doesn't mean that you need to write a separate section for each 
option type / EH type combination.

Also, in the case of unknown options, or RFC3692-style experimental 
options, if the default action (ignore or discard, depending on the 
upper two bits of the option code) is deemed too permissive, then 
there is clear benefit to allowing a different policy depending on 
the type of option header.

Finally, I could also see a case for an intermediate box to perform 
detailed scrutiny of stuff in a HbH option header but to just pass 
all stuff in a Destination Options header -- not just because of 
greater security issues with HbH but because of implementation 
constraintes (HbH is in a fixed position and can appear only once).  
That would be a global per-EH-type kind of policy.

I'm putting these last two things on the table mainly as food for 
thought.

Thanks

Mike Heard


From nobody Fri Aug 22 02:49:23 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F35C1A01E1 for <opsec@ietfa.amsl.com>; Fri, 22 Aug 2014 02:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 uNMpg6ecA36f for <opsec@ietfa.amsl.com>; Fri, 22 Aug 2014 02:49:20 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352061A00DE for <opsec@ietf.org>; Fri, 22 Aug 2014 02:49:19 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XKlT9-0003X8-K1; Fri, 22 Aug 2014 11:49:15 +0200
Message-ID: <53F70D1C.8080404@si6networks.com>
Date: Fri, 22 Aug 2014 06:27:56 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "C. M. Heard" <heard@pobox.com>
References: <20140816170731.13620.5804.idtracker@ietfa.amsl.com> <53EF9103.2000900@si6networks.com> <Pine.LNX.4.64.1408200811380.29207@shell4.bayarea.net> <53F5FAF6.1010000@si6networks.com> <Pine.LNX.4.64.1408210742020.27546@shell4.bayarea.net> <53F60AB6.7080909@si6networks.com> <Pine.LNX.4.64.1408210810270.27546@shell4.bayarea.net>
In-Reply-To: <Pine.LNX.4.64.1408210810270.27546@shell4.bayarea.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/dJLxSjfVttvtiuVkFtsphP5wQXY
Cc: OPSEC <opsec@ietf.org>
Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-01.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Aug 2014 09:49:22 -0000

On 08/21/2014 12:57 PM, C. M. Heard wrote:
> 
> For one thing, I think you agreed that the advice should be to 
> discard packets with options that appear in the wrong kind of 
> options header. 

After giving this one some thought, I'd say that my take is that the
best option is to produce a 6man document that specifies the default
processing of options, such that we complement RFC7045 (which does that
for IPv6 extension headers). -- this had been suggested by Brian
Carpenter already.

After all, advice of the kind "Drop this packet if it contains two
Router Alert options is really a default setting, rather than something
an operator would configure".

In the worst case scenario (if the 6man document doesn't fly there, we
may incorporate such defaults in this document).

Thoughts?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Fri Aug 22 07:40:05 2014
Return-Path: <heard@pobox.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA151A04D2 for <opsec@ietfa.amsl.com>; Fri, 22 Aug 2014 07:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
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 ZdtkPgjSU7AY for <opsec@ietfa.amsl.com>; Fri, 22 Aug 2014 07:40:02 -0700 (PDT)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F961A04C5 for <opsec@ietf.org>; Fri, 22 Aug 2014 07:40:02 -0700 (PDT)
Received: (qmail 4284 invoked from network); 22 Aug 2014 07:39:59 -0700
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Aug 2014 07:39:59 -0700
Date: Fri, 22 Aug 2014 07:39:59 -0700 (PDT)
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: Fernando Gont <fgont@si6networks.com>
In-Reply-To: <53F70D1C.8080404@si6networks.com>
Message-ID: <Pine.LNX.4.64.1408220656040.20047@shell4.bayarea.net>
References: <20140816170731.13620.5804.idtracker@ietfa.amsl.com> <53EF9103.2000900@si6networks.com> <Pine.LNX.4.64.1408200811380.29207@shell4.bayarea.net> <53F5FAF6.1010000@si6networks.com> <Pine.LNX.4.64.1408210742020.27546@shell4.bayarea.net> <53F60AB6.7080909@si6networks.com> <Pine.LNX.4.64.1408210810270.27546@shell4.bayarea.net> <53F70D1C.8080404@si6networks.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/VTykZf0YPRPwpq86FvbZwrwyYsU
Cc: OPSEC <opsec@ietf.org>, 6MAN <6man@ietf.org>
Subject: [OPSEC] Companion to RFC 7045 for options (was: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-01.txt)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Aug 2014 14:40:03 -0000

[ 6man added to cc: list ]

Fernando, I would have to agree that there is a need for a 
standards-track document doing for options what RFC 7045 did for 
extension headers.  The current rules in RFC 2460 for intermediate 
systems are:

(a) Inspect options in a hop-by-hop options header; process known 
options as specified in the document defining the option, otherwise 
take the action indicated in the upper two bits of the option code.

(b) Pass destination options transparently; do not inspect them or 
filter packets based on them.

There really aren't any provisions for intermediate systems to 
filter IPv6 packets on the basis of the options they contain.  That 
is not consonant with oft-repeated operational requirements.  The 
new document that you propose would need to provide for such 
filtering.  When that is done, the above rules are (IMHO) a 
reasonable starting point for deault behavior, modulo refinements 
such as discarding packets with options that appear in the wrong 
kind of options header.

Mike Heard

On Fri, 22 Aug 2014, Fernando Gont wrote:
> On 08/21/2014 12:57 PM, C. M. Heard wrote:
> > 
> > For one thing, I think you agreed that the advice should be to 
> > discard packets with options that appear in the wrong kind of 
> > options header. 
> 
> After giving this one some thought, I'd say that my take is that the
> best option is to produce a 6man document that specifies the default
> processing of options, such that we complement RFC7045 (which does that
> for IPv6 extension headers). -- this had been suggested by Brian
> Carpenter already.
> 
> After all, advice of the kind "Drop this packet if it contains two
> Router Alert options is really a default setting, rather than something
> an operator would configure".
> 
> In the worst case scenario (if the 6man document doesn't fly there, we
> may incorporate such defaults in this document).
> 
> Thoughts?
> 
> Thanks!
> 
> Best regards,
> 


From nobody Fri Aug 22 09:38:41 2014
Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB0A1A041D; Fri, 22 Aug 2014 09:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 iW2fYM6M3EXO; Fri, 22 Aug 2014 09:38:34 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0202E1A0413; Fri, 22 Aug 2014 09:38:33 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id d1so10438464wiv.7 for <multiple recipients>; Fri, 22 Aug 2014 09:38:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ce+U01500Zz23EY8CbvMR5WVG+MHnbJkYsfvi5PGtzo=; b=G3fEepgXC5xHmXd+QMGfHAUkOT+CrBmhpJ5lTsK5B8LOLM4y4WRvVvpsToLkrtcPV+ f+z5vpp/iTgvBJkGRtYVXCQyHKUqurYAg/XtzCai9nReGm27N0RsD4jQCcaU2CTRZx5q 74cgxlU+VAC9p+QS6MSFAcvYO9Hfvd5L7IVFJkCzQb0t5rvzJ9O3j+GY+P1Kz0TCOWKP rwwPPUKodW6+5uObOI4fh3sIcvKR2yilBh8IkqQP10EcSt5qUSjypUYFfTf4xh7xcRXp 6LHkS1nsIkBsO0rmqgxoVU5fwnX9hhXl3ph714xYlfYil4AgYVT7aqlOlNRCKQavy9zu mUxg==
MIME-Version: 1.0
X-Received: by 10.194.20.230 with SMTP id q6mr6428201wje.43.1408725512679; Fri, 22 Aug 2014 09:38:32 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.123.164 with HTTP; Fri, 22 Aug 2014 09:38:32 -0700 (PDT)
In-Reply-To: <53F590A2.2090101@si6networks.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAJE_bqeJBBghP=qXcYUOqQwTPky0uqoog=ifu0pqGi0zycu8kw@mail.gmail.com> <53F51269.8070506@si6networks.com> <CAJE_bqfgp-dpGnPFGKqYNGQK_TszZ8656AJbnQihenks=t9d1w@mail.gmail.com> <53F590A2.2090101@si6networks.com>
Date: Fri, 22 Aug 2014 09:38:32 -0700
X-Google-Sender-Auth: J7kaeZ6ImAauuyVClgZmEgumTjY
Message-ID: <CAJE_bqdrN6K3z2JzYH2ArHdrTERfSS+UYDH-YO=sPKpp0K-tDA@mail.gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/a6jir3aGki7I6vhgTg07WR7Ib_c
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Aug 2014 16:38:35 -0000

At Thu, 21 Aug 2014 03:24:34 -0300,
Fernando Gont <fgont@si6networks.com> wrote:

> >> [...] The one you suggested addresses
> >> only one of the two kinds of translators (if I understood correctly),
> >> and may still leave the door open in some scenarios.
> >
> > Specifically?
>
> Well, you can only really apply the suggested check to the stateless
> translation scenario.

Yes, and I thought we'd be okay with that, based on the
assumption/understanding that PTB<1280 is only useful for stateless
translation scenarios (and that's why I first asked this in my very
original message of this thread).

> But since a host does not now where it will be
> deployed, it cannot (out of the box) require that e.g. ICMPv6 PTB<1280
> use any specific part of the address space.
>
> Put another way, the mitigation would not "just work out of the box" for
> any of the servers running on the public Internet.
>
> And then, for the scenarios "a" or "c" from Section 2 of RFC6144, you
> still need to enforce filtering to prevent attacks within the IPv6 network.

Do you mean this mitigation isn't effective if the well-known prefix
(64:ff9b::/96) isn't used for the IPv4-Embedded IPv6 Addresses in
the stateless translation scenario?  If so, that's correct, and I have
to confess I don't remember all details and variations of translation
technologies and I assumed that stateless translation always uses the
well-known prefix.  Maybe I was incorrect about that?

--
JINMEI, Tatuya


From nobody Sat Aug 23 00:48:51 2014
Return-Path: <tore@fud.no>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0E01A8719; Sat, 23 Aug 2014 00:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.868
X-Spam-Level: 
X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 pxFci4YwJN0R; Sat, 23 Aug 2014 00:48:49 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EDF1A871A; Sat, 23 Aug 2014 00:48:49 -0700 (PDT)
Received: from [2a02:fe0:c411:a000::2] (port=60332 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <tore@fud.no>) id 1XL643-0002OX-9d; Sat, 23 Aug 2014 09:48:43 +0200
Message-ID: <53F8475A.1090800@fud.no>
Date: Sat, 23 Aug 2014 09:48:42 +0200
From: Tore Anderson <tore@fud.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>,  Fernando Gont <fgont@si6networks.com>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAJE_bqeJBBghP=qXcYUOqQwTPky0uqoog=ifu0pqGi0zycu8kw@mail.gmail.com> <53F51269.8070506@si6networks.com> <CAJE_bqfgp-dpGnPFGKqYNGQK_TszZ8656AJbnQihenks=t9d1w@mail.gmail.com> <53F590A2.2090101@si6networks.com> <CAJE_bqdrN6K3z2JzYH2ArHdrTERfSS+UYDH-YO=sPKpp0K-tDA@mail.gmail.com>
In-Reply-To: <CAJE_bqdrN6K3z2JzYH2ArHdrTERfSS+UYDH-YO=sPKpp0K-tDA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/YpLzkJNezEiJkYqHx3nSjWTHPPI
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Aug 2014 07:48:51 -0000

Hello 神明達哉,

> I assumed that stateless translation always uses the well-known
> prefix.  Maybe I was incorrect about that?

Yes, that is incorrect. Per RFC 6052 the operator can use either the
Well-Known Prefix and a Network-Specific Prefix. There are quite few
reasons why one would choose the latter; for example it allows for the
translating device to be reached across the public internet. Another
reason is that only a single WKP exists, so if the operator wants to
deploy both SIIT and NAT64, and/or multiple instances of either
technology, all of his deployments (except for one), must necessarily
use an NSP.

Tore




From nobody Mon Aug 25 10:58:24 2014
Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B211A00A5; Mon, 25 Aug 2014 10:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.722
X-Spam-Level: *
X-Spam-Status: No, score=1.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 Hk7qsVTCdNcZ; Mon, 25 Aug 2014 10:58:22 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371FC1A0218; Mon, 25 Aug 2014 10:57:09 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id x13so13372318wgg.31 for <multiple recipients>; Mon, 25 Aug 2014 10:57:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8AEwR/qdwLRtrhs0vjkZXkdNI+3PyE6FWEdilm1Q0BQ=; b=Pzm7Dugq7SlIvhrwyj2HMqu7OR86ocvpbftyMOGogYcRpkCwPEIkUmaEokBUOOT9Qw FcIL7e5ZsQF114MijfED+xuvhqY+Pt/BBoiuHrEQdhY9KfykTV7TZuWUZh905Y//0u90 c0Hf5n1r9bGaWPh85cLr6V5KA9TND2HAj3Mibt2745z2e+jVJXCG9rAPCl4oX5HPZlsa MvmR9FMxg+18hT5HU9TC1euY5EV3gSZK4wfI5XLlIXhSB6Ng3LoWyf8GYGPRkbIPOstW rG48aH8K9lwG4JV7a87er6ve7d6YX2/gNm7C6qkwXhIy3Nkmn4cuzLBLLSjP3JkXZaYQ 4yiw==
MIME-Version: 1.0
X-Received: by 10.180.75.49 with SMTP id z17mr16559665wiv.80.1408989427756; Mon, 25 Aug 2014 10:57:07 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.123.164 with HTTP; Mon, 25 Aug 2014 10:57:07 -0700 (PDT)
In-Reply-To: <53F8475A.1090800@fud.no>
References: <53F33C4F.2070807@si6networks.com> <CAJE_bqfb+v9p-PO8-7xzuYx3rs6Lpvob-Zh8ummgUEqsy764Tg@mail.gmail.com> <53F3931F.9050601@si6networks.com> <CAJE_bqeJBBghP=qXcYUOqQwTPky0uqoog=ifu0pqGi0zycu8kw@mail.gmail.com> <53F51269.8070506@si6networks.com> <CAJE_bqfgp-dpGnPFGKqYNGQK_TszZ8656AJbnQihenks=t9d1w@mail.gmail.com> <53F590A2.2090101@si6networks.com> <CAJE_bqdrN6K3z2JzYH2ArHdrTERfSS+UYDH-YO=sPKpp0K-tDA@mail.gmail.com> <53F8475A.1090800@fud.no>
Date: Mon, 25 Aug 2014 10:57:07 -0700
X-Google-Sender-Auth: aiCdpsIpSaaasWSy74Wn2FRjzq8
Message-ID: <CAJE_bqd7kZ0JusgUJsbb9cnaj5WGj7vGpV-f6QxnUH5-VB5Eag@mail.gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
To: Tore Anderson <tore@fud.no>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/7CNix_8cATk8QQ_InmBKynRcjv8
Cc: IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] [v6ops] DoS attacks (ICMPv6-based) resulting from IPv6 EH drops
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Aug 2014 17:58:23 -0000

At Sat, 23 Aug 2014 09:48:42 +0200,
Tore Anderson <tore@fud.no> wrote:

> > I assumed that stateless translation always uses the well-known
> > prefix.  Maybe I was incorrect about that?
>
> Yes, that is incorrect. Per RFC 6052 the operator can use either the
> Well-Known Prefix and a Network-Specific Prefix. There are quite few
> reasons why one would choose the latter; for example it allows for the
> translating device to be reached across the public internet. Another
> reason is that only a single WKP exists, so if the operator wants to
> deploy both SIIT and NAT64, and/or multiple instances of either
> technology, all of his deployments (except for one), must necessarily
> use an NSP.

Okay, thanks for the correction.  In that case this approach cannot be
a complete alternative to dropping PTB<1280 unconditionally without
affecting possible existing/coming deployments.

--
JINMEI, Tatuya


From nobody Tue Aug 26 08:35:28 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDB31A8717 for <opsec@ietfa.amsl.com>; Tue, 26 Aug 2014 08:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 xr8otYBa36EW for <opsec@ietfa.amsl.com>; Tue, 26 Aug 2014 08:35:24 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A121A0233 for <opsec@ietf.org>; Tue, 26 Aug 2014 08:35:24 -0700 (PDT)
Received: from 48-136-17-190.fibertel.com.ar ([190.17.136.48] helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XMImH-0006Aa-50; Tue, 26 Aug 2014 17:35:21 +0200
Message-ID: <53FCA7B1.9000006@si6networks.com>
Date: Tue, 26 Aug 2014 12:28:49 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "'opsec@ietf.org'" <opsec@ietf.org>
References: <20140826152114.26964.93347.idtracker@ietfa.amsl.com>
In-Reply-To: <20140826152114.26964.93347.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140826152114.26964.93347.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/wj4ZWvbIpU_fOo-z_pJrLi8x7mE
Subject: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-02.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 15:35:27 -0000

Folks,

We have posted a revision
(http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-02.txt)
of the aforementioned document, that addresses all the comments we have
received so far.

Any further comments will be highly appreciated.

Thanks!

Best regards,
Fernando (and co-authors)




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-opsec-ipv6-eh-filtering-02.txt
Date: Tue, 26 Aug 2014 08:21:14 -0700
From: internet-drafts@ietf.org
To: Will(Shucheng) Liu <liushucheng@huawei.com>, Shucheng LIU (Will)
<liushucheng@huawei.com>, Fernando Gont <fgont@si6networks.com>, Ron
Bonica <rbonica@juniper.net>, Fernando Gont <fgont@si6networks.com>,
Ronald P. Bonica <rbonica@juniper.net>


A new version of I-D, draft-gont-opsec-ipv6-eh-filtering-02.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-opsec-ipv6-eh-filtering
Revision:	02
Title:		Recommendations on Filtering of IPv6 Packets Containing IPv6
Extension Headers
Document date:	2014-08-26
Group:		Individual Submission
Pages:		30
URL:
http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-02.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-eh-filtering/
Htmlized:
http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-opsec-ipv6-eh-filtering-02

Abstract:
   This document provides advice on the filtering of IPv6 packets based
   on the IPv6 Extension Headers and the IPv6 options they contain.
   Additionally, it discusses the operational and interoperability
   implications of discarding packets based on the IPv6 Extension
   Headers and IPv6 options they contain.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat





From nobody Thu Aug 28 10:44:34 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757ED1A886F; Thu, 28 Aug 2014 10:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_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 HAiQFhJJSwOZ; Thu, 28 Aug 2014 10:44:29 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD42C1A0B82; Thu, 28 Aug 2014 10:44:29 -0700 (PDT)
Received: from [2001:5c0:1000:a::503] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XN3kI-0002gy-MV; Thu, 28 Aug 2014 19:44:27 +0200
Message-ID: <53FF6A6F.5010508@si6networks.com>
Date: Thu, 28 Aug 2014 14:44:15 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "'opsec@ietf.org'" <opsec@ietf.org>, IPv6 Operations <v6ops@ietf.org>
References: <20140828173747.6623.76624.idtracker@ietfa.amsl.com>
In-Reply-To: <20140828173747.6623.76624.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140828173747.6623.76624.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/NUjhJkTSVs7YhqYFu3_mtXHKeuo
Subject: [OPSEC] ICMP/ICMPv6 network ingress filtering (Fwd: New Version Notification for draft-gont-opsec-icmp-ingress-filtering-00.txt)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 17:44:32 -0000

Folks,

Based on the recent discussion we have had about ICMP-based DoS attacks,
we have posted an I-D which describes and suggests that network ingress
filtering be applied on ICMPv4 and ICMPv6 error messages (based on the
addresses of the embedded payload).

The I-D is available at:
<http://www.ietf.org/internet-drafts/draft-gont-opsec-icmp-ingress-filtering-00.txt>

Any feedback will be very appreciated.

Thanks!

Best regards,
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-opsec-icmp-ingress-filtering-00.txt
Date: Thu, 28 Aug 2014 10:37:47 -0700
From: internet-drafts@ietf.org
To: Will(Shucheng) Liu <liushucheng@huawei.com>, Jeroen Massar
<jeroen@massar.ch>, Ray Hunter <v6ops@globis.net>, Fernando Gont
<fgont@si6networks.com>, Ray Hunter <v6ops@globis.net>, Jeroen Massar
<jeroen@massar.ch>, Fernando Gont <fgont@si6networks.com>, Shucheng LIU
(Will) <liushucheng@huawei.com>


A new version of I-D, draft-gont-opsec-icmp-ingress-filtering-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-opsec-icmp-ingress-filtering
Revision:	00
Title:		Network Ingress Filtering: Defeating Attacks which employ Forged
ICMP/ ICMPv6 Error Messages
Document date:	2014-08-28
Group:		Individual Submission
Pages:		9
URL:
http://www.ietf.org/internet-drafts/draft-gont-opsec-icmp-ingress-filtering-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-opsec-icmp-ingress-filtering/
Htmlized:
http://tools.ietf.org/html/draft-gont-opsec-icmp-ingress-filtering-00


Abstract:
   Over the years, a number of attack vectors that employ forged ICMP/
   ICMPv6 error messages have been disclosed and exploited in the wild.
   The aforementioned attack vectors do not require that the source
   address of the packets be forged, but do require that the addresses
   of the IP/IPv6 packet embedded in the ICMP/ICMPv6 payload be forged.
   This document discusses a simple, effective, and straightforward
   method for using ingress traffic filtering to mitigate attacks that
   use forged addresses in the IP/IPv6 packet embedded in an ICMP/ICMPv6
   payload.  This advice is in line with the recommendations in BCP38.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat