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

Gyan Mishra <hayabusagsm@gmail.com> Sun, 10 November 2019 02:16 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 56E9F1200EF for <opsec@ietfa.amsl.com>; Sat, 9 Nov 2019 18:16:08 -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 fYtzrwTRbA7S for <opsec@ietfa.amsl.com>; Sat, 9 Nov 2019 18:16:04 -0800 (PST)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 3862D12001E for <opsec@ietf.org>; Sat, 9 Nov 2019 18:16:04 -0800 (PST)
Received: by mail-qk1-x735.google.com with SMTP id 205so8462781qkk.1 for <opsec@ietf.org>; Sat, 09 Nov 2019 18:16:04 -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=WP2M1SxPB6172GJN2ORlP2OjttxnldN94RMNmlXGuwg=; b=cTqmSzm8unCUIurWNW+IqlTysEVXspov//3w+O1k91UtJGxCWXHQJSVot6RdfUxAwD RiNCDdsnqMaolPGVIrkbCcKce+ZCjYRBgUexCrp68K/35l8fQR0f3LoH3IoRVSIWQVw7 UDm5JKDACMfkALwZwv03HWgGYhFe3m/6hYrQFnw2404/LDibYTg6p9QRQT2Zwi9U7OjD enbBo0NtwJ3Ty1fm8U+MKFJKIETAtVIeep5SYvos0toWH7F9Ewb5lF6OqLn+te6j+8s2 nDlCmP+S3W6OARuodvoV24ZqhnHnjZ2BX9o8SAOaoB6oGl3ZYfPnmAI0gMeIVZT80/fO e52Q==
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=WP2M1SxPB6172GJN2ORlP2OjttxnldN94RMNmlXGuwg=; b=k3gsKxuxdv2ZaVc7lFjXYR3hhVDxHREuTHma6mr1AbNtdSXfcn7eyD251EE96THk1x nbe51KPAThv32Dc3lgQNmIldGTQHJZmw9+ZTm0SK39MMfDidVSxgqRmgPj0V+M5pBlz5 FfBr7ifR+JxdbVKq8M1zPjKo0BCNVa+FXs0GtzrqT1nwjuHYTZ+zxEzJ9llgQZSwIoNe cFO4ncNXBuIRLhwMW8funiIc5c/youFZVmSqPPnz8vTsifZKxx18q/pmdFDZbclpqgLg NY9qfrJwITdCUl4/3NoiewPYIWJZXGjree7pyL5CHJjDIs/4IyU5MMr3rkFOUnbMz5G0 FmuA==
X-Gm-Message-State: APjAAAWo0UhZIl7jPiWUB8QNWHX3oGVzp/k0TiKqummFbV/IXRo8iSJV du5g09Avco4KRwHxj5Bf4w0aJhnW
X-Google-Smtp-Source: APXvYqwqKodM4MMf6kwMWAiDGsK83mYcZJzcUPMkoL7/Zu/3GRIxZDFDUjQpBKAHNdEjYcz2xLEPbg==
X-Received: by 2002:ae9:e114:: with SMTP id g20mr4033745qkm.13.1573352161812; Sat, 09 Nov 2019 18:16:01 -0800 (PST)
Received: from ?IPv6:2600:1003:b02c:8e21:bd93:abc:b878:80c4? ([2600:1003:b02c:8e21:bd93:abc:b878:80c4]) by smtp.gmail.com with ESMTPSA id h37sm5532974qth.78.2019.11.09.18.15.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 18:16:00 -0800 (PST)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Google-Original-From: Gyan Mishra <hayabusaGSM@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-BB8D9D87-B363-4513-A6A9-898E9790DD2E
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <21EF15E3-51F0-405A-86D1-C68567DBEFFF@employees.org>
Date: Sat, 9 Nov 2019 21:15:59 -0500
Cc: Bob Hinden <bob.hinden@gmail.com>, "opsec@ietf.org" <opsec@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <D8A603E4-6990-4363-9BFA-6BEF5F333044@gmail.com>
References: <DB5FA864-FE44-4B3E-87A1-DFF72623AC8C@gmail.com> <21EF15E3-51F0-405A-86D1-C68567DBEFFF@employees.org>
To: Ole Troan <otroan@employees.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/W5mb4LogI4zGN3d8W7AFha0QrwU>
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 02:16:08 -0000




> 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.