IETF Logo Mail Archive

Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 09 May 2019 23:40 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 70C131200E0 for <ipv6@ietfa.amsl.com>; Thu, 9 May 2019 16:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 bYuh-TbUwX5e for <ipv6@ietfa.amsl.com>; Thu, 9 May 2019 16:40:44 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3721200DF for <ipv6@ietf.org>; Thu, 9 May 2019 16:40:43 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 73AAA3808A; Thu, 9 May 2019 19:40:03 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id B43DFF19; Thu, 9 May 2019 19:40:40 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B1788C11; Thu, 9 May 2019 19:40:40 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: David Farmer <farmer@umn.edu>, IPv6 List <ipv6@ietf.org>
Subject: Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05
In-Reply-To: <CAN-Dau2brdJ98bzFO76j+C=RCZSFpNg-eW0WCz_FYp9C_YSMjQ@mail.gmail.com>
References: <F8BFFCAD-E58E-4736-8A1C-56579B6F6032@employees.org> <a2465e81-a17f-ab48-efda-20fe12a70077@foobar.org> <30239E0C-C444-4A7E-8342-AEE47BF8A2BB@employees.org> <8b9fd743-bfcc-525c-98f6-154f3fa713cc@foobar.org> <CAO42Z2zEWvt9NyemMb8H0AEvPvmNSDGa4wcXiS6n5yRxNFCHQg@mail.gmail.com> <c7e18765-be04-6494-8193-984dbccb520b@foobar.org> <CANMZLAYh+V57yrWOzmUyjSMK0g95u1D5_GZmyZBMOMKAZnrnCg@mail.gmail.com> <3F474511-6FE3-4A0A-9B84-7C37F08FBB5D@steffann.nl> <E352C226-C708-4418-BCDE-10525CAB109A@jisc.ac.uk> <652fb10e-b8ce-0151-a9a0-62d2378caed2@gmail.com> <0079c716-d56c-7199-f493-f5e56e1307ae@foobar.org> <b33de303-eaca-f7f6-804e-2c9343eb92a1@gmail.com> <6C4ABEF1-2565-4BA9-9FC5-5B3C45A719AD@gmail.com> <c2222416-6491-1906-a403-d012777a4b38@gmail.com> <CABNhwV0-SdKZqQa4z9jhpc8h1Eq=8UxRhtvHt1==BYEMTVRjug@mail.gmail.com> <96790121-7D50-4C6F-924F-87065B989E44@gmail.com> <ccab3694-54f2-bdd1-f8ac-cb159dbc0a81@gont.com.ar> <CAN-Dau0_w0n9C6grqi1bXAL-k239K7RMiQyhx5=c-Y_wqrV2OQ@mail.gmail.com> <CAO42Z 2wwftO6wtF7PAJ9CCK2iBvtOj0BQP7O0UREr-pMmPegvQ@mail.gmail.com> <CAN-Dau2brdJ98bzFO76j+C=RCZSFpNg-eW0WCz_FYp9C_YSMjQ@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 09 May 2019 19:40:40 -0400
Message-ID: <20339.1557445240@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/5h00K1Sd9Qmv67v2oxz9msCp6SA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 09 May 2019 23:40:47 -0000

David Farmer <farmer@umn.edu> wrote:
    > Making the lack of DHCPOFFERS the primary signal and this flag a
    > secondary signal mitigates almost all the risks associated with this
    > flag. So, this flag is not saying turn off IPv4, this flag is saying
    > assume that the lack of any DHCPOFFERS is an intentional act and don't
    > auto-configured an IPv4 Link-Local address or perform any IPv4 service
    > discovery with an IPv4 link-local address. Further, if you see only
    > ROUTER ADVERTISEMENTS with this flag set, you can fairly quickly stop
    > sending DHCPDISCOVERS at all, they are not going to get answered.

Thanks for the well written message, the well explained logic and this
modification of primary/secondary notion.

In order for the network and devices to remain safe in the scenario, at least
IPv4 DHCPOFFERS must be filtered out. (Whether by filtering IPv4 broadcasts,
UDP port 67/68 or all IPv4, it doesn't matter)
Otherwise, the rogue DHCPv4 server captures all the IPv4-legacy traffic.
(Such an attacker system could CLAT46 the traffic and NAT64 it out)

The above attack is present with or without the IPv6-only flag.
With the IPv6-only flag, it becomes possible, in a network with IPv4 L2
filters, to detect that perhaps there is something going wrong.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email