Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt

Mark Andrews <marka@isc.org> Wed, 26 June 2013 01:38 UTC

Return-Path: <marka@isc.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C536F21E80EC for <ipv6@ietfa.amsl.com>; Tue, 25 Jun 2013 18:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5hbdpTgFLb5 for <ipv6@ietfa.amsl.com>; Tue, 25 Jun 2013 18:38:17 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B402011E8192 for <ipv6@ietf.org>; Tue, 25 Jun 2013 18:38:16 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 97FFCC947E; Wed, 26 Jun 2013 01:38:08 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372210696; bh=jTtmXeWt8pf9wmwBGnLOmNoJOo151GWRMZlf53GMKXg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=JOyAx8vmFGsvXbAMK/118+UnyPpEGxZVU6jnEbY1KwHrUoHZOmh2NRNO5+8Locfoe y5qZw/VbnqIyVn4Vhl/Ap3sTphwwT6bakYafBBSQuWeddleI1FvtCcsQ9PMCjNpLhU h2WFOZghNRfZFZbT3TxoX/1Aa9ovWYT7nbbKeMsI=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 26 Jun 2013 01:38:08 +0000 (UTC) (envelope-from marka@isc.org)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C4CCE16008E; Wed, 26 Jun 2013 01:39:18 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id R5oJ_7iGP5LV; Wed, 26 Jun 2013 01:39:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 36EB016008D; Wed, 26 Jun 2013 01:39:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at zmx1.isc.org
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rseB4CCfFcrS; Wed, 26 Jun 2013 01:39:18 +0000 (UTC)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 96B1016005A; Wed, 26 Jun 2013 01:39:17 +0000 (UTC)
Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 741B23643834; Wed, 26 Jun 2013 11:38:04 +1000 (EST)
To: Tony Hain <alh-ietf@tndh.net>
From: Mark Andrews <marka@isc.org>
References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C56E60.5040009@fud.no> <8C48B86A895913448548E6D15DA7553B9237F3@xmb-rcd-x09.cisco.com> <CAKr6gn17O+B78HJofr-z7Nsgv-y8+w4hgKy+YPicgNS126qwXA@mail.gmail.com> <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.outlook.com> <CAKr6gn2zu2n-pJMirG-seN5WX=Evyquu9EqqLOV-zf-RKQ9eYg@mail.gmail.com> <20130625015317.6B256363BD8F@drugs.dv.isc.org> <2CF4CB03E2AA464BA0982EC92A02CE2509F878B0@BY2PRD0512MB653.namprd05.prod.outlook.com> <20130625040207.1CCA7363C42A@drugs.dv.isc.org> <CAKr6gn1cnGfktfKraQegHNP_kjHyzNKGzw3ZDe1cZ__Czsu_kw@mail.gmail.com> <51C98103.4050008@fud.no> <010f01ce71e3$7f43aea0$7dcb0be0$@tndh.net> <20130625233717.618C53642429@drugs.dv.isc.org> <014201ce7208$1378c5f0$3a6a51d0$@tndh.net>
Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
In-reply-to: Your message of "Tue, 25 Jun 2013 17:57:05 -0700." <014201ce7208$1378c5f0$3a6a51d0$@tndh.net>
Date: Wed, 26 Jun 2013 11:38:04 +1000
Message-Id: <20130626013804.741B23643834@drugs.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Cc: 'Tore Anderson' <tore@fud.no>, ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2013 01:38:21 -0000

In message <014201ce7208$1378c5f0$3a6a51d0$@tndh.net>, "Tony Hain" writes:
> Mark Andrews wrote:
> > One needs to get the L4 information the firewall/loadbalancer uses in
> *each*
> > fragment.
> 
> This is a manufactured requirement to allow devices that can't do a full
> reassembly to operate in under a policy of 'verify the entire packet'.
> Unfortunately, it doesn't even do that since it doesn't actually detect
> overlapping fragments if it is just verifying that the L4 information is the
> same. 

Many firewalls are just trying to ensure packets match the <protocol,
src address, src port, dest address, dest port> tuple.  They are
not trying to protect from overlapping fragements.

That said being able to filter out / forward without reassembly
fragments that you are not interested in also reduces the number
of fragments that need to be processed in the reassembly queues of
the firewall itself when you are doing dpi of some of the packets.

> Load balancers just need to get over it, and use something more/other than
> the L4 in the hash. The FL was intended to provide a consistent value over
> the life of an L4 session, so why not use that instead of developing yet
> another new option? Wait,,, that doesn't exist in IPv4, so it can't be used
> because that would require learning something different...

Flow labels aren't a solution for all problems.  Yes, load balancers should
make use of them.

> > For UDP this is the source and destination ports.  Create a new skipable
> hop-
> > by-hop option that contains a copy of these values and add it along with a
> > fragment header when fragmenting UDP packets.
> 
> I have no problem with that concept, but why when there are other ways of
> accomplishing the task? Simply to mirror IPv4 is not a valid reason...

It isn't just mirror IPv4.
 
> > For TCP ensure that the IP layer informs the TCP layer if it would have to
> > fragment the packet. i.e. don't send fragmented TCP packets.
> 
> So TCP is never allowed to have a long-lived session ...

No.  It's send the equivalent of PTB back to the TCP layer and have
it re-segment rather than fragment a badly sized segment it passed
to the IP layer.  You have a broken stack if you see a TCP fragment.

> Or routes are not
> allowed to flap. Which is it? You either tear down tcp and renegotiate mss
> every time routes flap to a path with a lower mtu, or you send fragments. It
> is easy to say the core is >=1500 now, but what happens with a mix of
> 1500/4k/9k/32k/... over the life of IPv6? Are routes never allowed to flap
> with larger MTUs? Do you require every TCP implementation to do dynamic MSS,
> and try to get that deployed within a decade to two?
> 
> > 
> > For ICMPv6 ???
> > 
> > For IPv4 if DF=0 fragment the Ipv4 packet to fit in inside 1280 IPv6
> packets
> > destination reassembles.
> > For IPv4 if DF=1 return IPv4 PTB
> > 
> > For XXX ????
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org