Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt

Gyan Mishra <hayabusagsm@gmail.com> Sun, 10 November 2019 16:38 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF591201B7 for <opsec@ietfa.amsl.com>; Sun, 10 Nov 2019 08:38:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CSuWqLHgB6Rj for <opsec@ietfa.amsl.com>; Sun, 10 Nov 2019 08:38:21 -0800 (PST)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 2D702120170 for <opsec@ietf.org>; Sun, 10 Nov 2019 08:38:21 -0800 (PST)
Received: by mail-qt1-x833.google.com with SMTP id y39so13029101qty.0 for <opsec@ietf.org>; Sun, 10 Nov 2019 08:38:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=klzw8g3ITE5R1Z9ikjTCDbndpQkaxdApseO4sBAcLgw=; b=nBNAt0g7EqVJ9+q4GNtMys/pdYMPmkL9YETZG/+VpTTADioCO0VRsWran7Pf93x2DJ 5oVStrZzZ3ELLAEzbnu9ExRGmsK47boAHcfs51Wmjp92HeRgwrToyQxfXEP6iOuSVGIE LrrdtVFYZA19ONFbLHTlswcRrNUZpdtqYizpKRcC7/QsrUgF79x3JGW43TgPN1LLzW+b kmTCpOjFimXDSADXuXapJUQbknoiTC7f1w9q7d8O9xuEsklwWvWPhKYfnlv0wxlzdVyN quv3u3nBL8ukgqGlrMZQLCcVKUdytUFgbUptsc9ejVtZTQfHlSHarwNeBXZenoFiP+lH PsRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=klzw8g3ITE5R1Z9ikjTCDbndpQkaxdApseO4sBAcLgw=; b=hlLPsKj+fbW9qT+MgFrDEjAg2p6aJlUPE8EJjSdbOTWyzO5yvrOKuZuv6iai1BNmgy ZaObjNGzSlDYZ8N7zaz98SjN+GZUYws8NTOZtaTVwwbbkag8+UjMS5n1kdWxMNK+uYur DDmw0xAJJ9M0jujTkmylDqWfztwF8q5dUgsXXdVGfZ1itMOxOpTVmXvoGl0SFV3/kdtc GUhgmNj1+NZQrW4VbE6t7CP/a7EStNSmlqlxjA2UpyQMZS92fVjiEL2LkcuSWF+VYzAz YnlG/TxnS5k/9283PizERfhyDiJ/YU142isai42C62X6waj96FRE3NRcgD3EhErAr2FN 0x6Q==
X-Gm-Message-State: APjAAAXU9QKO2lV+RmmyGedFgk5CUJ/97heqmEb2EAkswFVRQcU8GPVJ MhGXJAHq0g6h9sBnAWi0SBI=
X-Google-Smtp-Source: APXvYqzSuzHmr7ELtbahzH8uAHly7amXTJb9CQgWylCAkiGcEKBbCh8ESplIyOr9FrJyjhUZJ+2kIA==
X-Received: by 2002:ac8:6a13:: with SMTP id t19mr21716183qtr.56.1573403899999; Sun, 10 Nov 2019 08:38:19 -0800 (PST)
Received: from [192.168.1.213] (pool-72-83-194-140.washdc.fios.verizon.net. [72.83.194.140]) by smtp.gmail.com with ESMTPSA id v54sm6679883qtc.77.2019.11.10.08.38.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Nov 2019 08:38:15 -0800 (PST)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Google-Original-From: Gyan Mishra <hayabusaGSM@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-3D73C990-F55B-4475-B90C-AF9C19B56B39
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <D8A603E4-6990-4363-9BFA-6BEF5F333044@gmail.com>
Date: Sun, 10 Nov 2019 11:38:14 -0500
Cc: Ole Troan <otroan@employees.org>, Bob Hinden <bob.hinden@gmail.com>, "opsec@ietf.org" <opsec@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <E27B4ACA-A77F-4723-BDEB-2F03E0580284@gmail.com>
References: <DB5FA864-FE44-4B3E-87A1-DFF72623AC8C@gmail.com> <21EF15E3-51F0-405A-86D1-C68567DBEFFF@employees.org> <D8A603E4-6990-4363-9BFA-6BEF5F333044@gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/vTPyg-bOXI_HquLnH-WTnMtmjNA>
Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 10 Nov 2019 16:38:25 -0000


> On Nov 9, 2019, at 9:15 PM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
> 
> 
> 
> 
> 
>> On Nov 9, 2019, at 4:49 PM, Ole Troan <otroan@employees.org> wrote:
>> 
>> 
>> 
>>> On 9 Nov 2019, at 22:35, Bob Hinden <bob.hinden@gmail.com> wrote:
>>> 
>>>>>>> The hop-by-hop options header, when present in an IPv6 packet, forces
>>>>>>> all nodes in the path to inspect this header in the original IPv6
>>>>>>> specification [RFC2460].  This enables denial of service attacks as
>>>>>>> most, if not all, routers cannot process this kind of packets in
>>>>>>> hardware but have to 'punt' this packet for software processing.
>> 
>> I believe this statement is far out of date. 
>> I would recommend getting recent data on this or delete it. 
>> 
>> Cheers 
>> Ole
> 
> This draft expired late 2016 so only few years old on this subject.
> 
> https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03
> 
> So I think the main issue with hbh is that even on  the latest modern high end routers that process everything in hardware in the forwarding plane that hbh processing had to be sent to the control plane because some hbh options are used in the forwarding plane like jumbo frames, while others are to be consumed by the control plane such as router alert.  Older routers forwarded all hbh from the forwarding plane to the control plane which now newer routers don’t do so but you still have hbh options that have to be consumed by the control plane.
> 
> Excerpt from the draft above.
> 
> Many modern routers maintain a strict separation between forwarding plane hardware and control plane hardware. In these routers, forwarding plane bandwidth is plentiful, while control plane bandwidth is constrained. In order to protect scarce control plane resources, these routers enforce policies the restrict access from    the from the forwarding plane to the control plane. Effective policies address packets containing the HBH Options Extension header, because HBH control options require access from the forwarding plane to the control plane. Many network operators perceive HBH Options to be a breach of the separation between the forwarding and control planes [I-D.ietf-v6ops-ipv6-ehs-in-real-world]. Therefore, some network operators discard all packets containing the HBH Options Extension Header, while others forward the packets but ignore the HBH Options. Still other operators severely rate-limit packets containing the HBH Options Extension Header. In addition, some (notably older) implementations send all packets containing a HBH header to the control plane even if they contain only pad options, resulting in an effect DoS on the router and inconsistent drops among those packets due to rate limiting or other factors. [RFC7045] legitimizes the current state of affairs, severely limiting the utility of HBH options. In the words of RFC 7045: "The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in RFC2460. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. Designers planning to use a Hop-by-Hop option need to be aware of this likely behaviour."
> 
> https://tools.ietf.org/html/rfc7045
> 
> 2.2. Hop-by-Hop Options The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour. As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options header, if present, must be first.
> 
> We should reference these two documents in this draft which I have to check.

Ole

Thanks for the comments.  I think the hbh section is most pertinent to this I-D.  I will work with the authors to update with current data.

Gyan
>