Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

Fred Baker <fredbaker.ietf@gmail.com> Tue, 29 January 2019 23:37 UTC

Return-Path: <fredbaker.ietf@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B4213103F for <int-area@ietfa.amsl.com>; Tue, 29 Jan 2019 15:37:55 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Ljg46yVoVc47 for <int-area@ietfa.amsl.com>; Tue, 29 Jan 2019 15:37:53 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0561131031 for <int-area@ietf.org>; Tue, 29 Jan 2019 15:37:52 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id b14so17528344edt.6 for <int-area@ietf.org>; Tue, 29 Jan 2019 15:37:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1vLJrbH1vZOMNaQlq/tSmP0HLrnp7F2DmviTwcmNY4Q=; b=BpMXErauL6GBy9qkHsqrd+Da4Dkv5NWsbQrEv8A/T2kkxsfOltFFt85U0kt/8R1B0O YYwR5iR/hBNsVTqm7L/9Ce2PdYgtlRvFrvshIL/3EFfi6JU7XeGkNQsByyCUZlUw70PV XuUgiAGPlMuboBo95pjjikmRRA0ifb1rXp6+oOG3ARrIAinRJ+OktWxFyokpQCRwaxay 2Omr33zQrNAexl6EJLZMrAfjf6LeRAXZcVApRDqn3jPrlhaH1/erznkn++3lzh54P0t/ 3uyEPRnDkStu1JLioh4Vy0zJAf3py8+ZFodPEAxECuW/z3B/YRbOpsaUlKHvCRqPpgMw 0qWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1vLJrbH1vZOMNaQlq/tSmP0HLrnp7F2DmviTwcmNY4Q=; b=LFQUb2V7vqwBFm6aLMlb6prUPsuVgrrzHohIvpKlA80K31gvmFOdqzq2zgzpYe8fyS 9HmOQyf6lWR1P56U9dn3PHAI6HkJAi19fc9+LlBIp345jUg0RCRN5pFRAdxM12JYk5F6 6jWO7xZqNXjBPhoBPsWZSgeAWb1fchEE120NiueeCyBeG/PsYbzPD/QcCZRtVf5D/qtV SmdXd/GX/sesEDrpB1yC6QnnlfOkdfHrN+J9qmArY9OutG0L944T2h60D8mKmLGIvTr1 vsJbjBDjBL4N02CtwVPPJAUDsoTx3zsHBRyZxz5KxPtuqjzeqVAJ1LtkYxvmj4dJ2AQi wIJw==
X-Gm-Message-State: AJcUukdutc+9KsQtsJBpC7rSrfqGVkKwRty/odqohACwkBJwMxG3bdNE 7iUFQHcoLeHO/w3P6xnr8tNJpGtV
X-Google-Smtp-Source: ALg8bN4CnTd3tM/woRZmu1N5ouw9+GoHuwh71PjORbTQ2o5HPShIsA9BaXQKYhVF7s3q9ygZdIsiQQ==
X-Received: by 2002:a17:906:364f:: with SMTP id r15mr9078960ejb.70.1548805071159; Tue, 29 Jan 2019 15:37:51 -0800 (PST)
Received: from ?IPv6:2600:8802:5600:164::14cf? ([2600:8802:5600:164::14cf]) by smtp.gmail.com with ESMTPSA id h9sm57480ede.93.2019.01.29.15.37.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 15:37:50 -0800 (PST)
From: Fred Baker <fredbaker.ietf@gmail.com>
Message-Id: <3B29EAA5-5989-4A8F-857B-3DEF63A7FEA7@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_95833436-77CD-468F-B124-6B1D01EEDE7B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.1\))
Date: Tue, 29 Jan 2019 15:37:46 -0800
In-Reply-To: <CALx6S35kwvHL5iE4Ci10LQbPzun3k1C-T4m5B55yAyL+nP4sdQ@mail.gmail.com>
Cc: int-area <int-area@ietf.org>
To: Tom Herbert <tom@herbertland.com>
References: <CALx6S35kwvHL5iE4Ci10LQbPzun3k1C-T4m5B55yAyL+nP4sdQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/wHW6jvXqy4OpoJge_O07CnZ-YKQ>
Subject: Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jan 2019 23:37:55 -0000


> On Jan 29, 2019, at 11:45 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
> Hello,
> 
> I have suggested text for the draft to address some previous comments
> made on the list.
> 
> Last paragraph in section 4.3:
> 
> "This problem does not occur in stateful firewalls or Network Address
> Translation (NAT) devices. Such devices maintain state so that they
> can afford identical treatment to each fragment that belongs to a
> packet.

Do we have a list of such products? I'm unaware of one. Making a blanket statement such as this troubles me, because it seems to say that this is invariably true, and I don't know that it is or isn't.

> Note, however, that stateful firewalls and NAT devices impose
> the external requirement that all packets of a flow and fragments of a
> packets for a flow must traverse the same stateful device; stateless
> devices do not force this requirement."

Here's an example of why blanket statements need to be qualified. If you take NPTv6 to be a form of NAT, it doesn't force route symmetry.

> Section 4.5:
> "IP fragmentation causes problems for some routers that support Equal
> Cost Multipath (ECMP). Many routers that support ECMP execute the
> algorithm described in Section 4.4 in order to perform flow based
> forwarding;

As far as I know, routers that hash fields in the IP header to select a en ECMP next hop do so because all packets in a flow will hash the same way (modulo the issues with the transport port number), not because they are doing per-flow forwarding. The do so explicitly to avoid having to maintain per-flow state and yet make all fragments of a message follow the same path.

> therefore, the exhibit they same problematic behaviors
> described in Section 4.4. In IPv6, the flow label may alternatively
> used as input to the algorithm as opposed to parsing the transport
> layer of packets to discern port numbers. The flow label should be
> consistently set for a packets of flow including fragments, such that
> a device does not need to parse packets beyond the IP header for the
> purposes of ECMP."
> 
> Add to section 7.3:
> 
> "Routers SHOULD use IPv6 flow label for ECMP routing as described in [RFC6438]."
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu