Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

joel jaeggli <joelja@bogus.com> Mon, 22 October 2012 18:27 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F1311E80ED for <v6ops@ietfa.amsl.com>; Mon, 22 Oct 2012 11:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.108
X-Spam-Level:
X-Spam-Status: No, score=-102.108 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1uEB1i2OMRH for <v6ops@ietfa.amsl.com>; Mon, 22 Oct 2012 11:27:55 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E8A1F11E80E7 for <v6ops@ietf.org>; Mon, 22 Oct 2012 11:27:54 -0700 (PDT)
Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q9MIRnBw021929 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 22 Oct 2012 18:27:49 GMT (envelope-from joelja@bogus.com)
Message-ID: <50859022.5070709@bogus.com>
Date: Mon, 22 Oct 2012 11:27:46 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0
MIME-Version: 1.0
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3A2@XCH-NW-01V.nw.nos.boeing.com> <507DA6A3.20807@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3C3@XCH-NW-01V.nw.nos.boeing.com> <507DAB13.2010704@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3CE@XCH-NW-01V.nw.nos.boeing.com> <507DDF8A.9010607@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF5AB@XCH-NW-01V.nw.nos.boeing.com> <BB219517-B488-4777-AE9C-35C57BE91263@kumari.net> <Pine.LNX.4.64.1210171337470.7337@shell4.bayarea.net> <AC530E99-4054-4B0A-9B5C-30F9EF4A530C@kumari.net> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5C66F@XCH-NW-01V.nw.nos.boeing.com> <5081A245.9050707@gmail.com> <5085777C.2010404@bogus.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5CAEA@XCH-NW-01V.nw.nos.boeing.com>
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65E0DF5CAEA@XCH-NW-01V.nw.nos.boeing.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 22 Oct 2012 18:27:49 +0000 (UTC)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Oct 2012 18:27:55 -0000

On 10/22/12 10:46 AM, Templin, Fred L wrote:
> Hi Joel,
>
>> -----Original Message-----
>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
>> joel jaeggli
>> Sent: Monday, October 22, 2012 9:43 AM
>> To: Tom Taylor
>> Cc: v6ops@ietf.org
>> Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
>>
>> On 10/19/12 11:56 AM, Tom Taylor wrote:
>>> On 19/10/2012 2:11 PM, Templin, Fred L wrote:
>>>>> other than causing bandwidth / pps DoS attacks, or alternatively
>>>>> tickling
>>>>> obscure ipv6 stack bugs, no.  At least in theory.
>>>> There's no excuse for broken IPv6 stacks that can't handle
>>>> fragmentation and reassembly. About DoS concerns, if the
>>>> network is going to intentionally break frag/reass out of
>>>> concern for edge devices that might not be able to handle
>>>> the load, then that is very bad for applications that cannot
>>>> reduce the size of packets they send down to 1280. Again,
>>>> tunnels fall into that category.
>>>>
>>>> So, if tunnels cannot rely on ICMP PTB and also cannot rely
>>>> on IPv6 frag/reass then there is only one option remaining:
>>>> https://datatracker.ietf.org/doc/draft-templin-intarea-seal/
>> They can implement fragmentation in their upper layer encapsulation
>> rather than using the ip fragmentation header and two or more fragmented
>> ip datagrams in addition to seal, SSL/TLS-vpn's and SSTP have to do the
>> same thing...
> Do you know whether the DoS considerations discussed in this thread
> apply also for SSL/TLS and SSTP when there is fragmentation in the
> upper layers?
Speaking entirely for my own case the reason we actually use the 
stateless l3/l4 hash on our edge in front of a stateful edge that 
therefore has issues with hashed fragements ending up on different load 
balancers is becuase we have to load-balance SSL.
> Thanks - Fred
> fred.l.templin@boeing.com
>
>>> which, as a matter of fact, came up briefly in the Interim Meeting
>>> discussion.
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops