From nobody Tue Dec 4 12:18:00 2018 Return-Path: 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 2443E130E3C; Tue, 4 Dec 2018 12:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 AxLsJzrANMNX; Tue, 4 Dec 2018 12:17:45 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 6C8E612F1AB; Tue, 4 Dec 2018 12:17:45 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id b5so16540164iti.2; Tue, 04 Dec 2018 12:17:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NMHFzN1cvcghWgJb3Z8DYwame2bS0CwI9GV1983uQU0=; b=HUeToHhgXdMK7wX34lD7p5oVm5FMh0+CigZDEWa9l1k5PdeB8w/pnPPJ2UJ4i2bkmo QIGZb7ksjYotGKJvKFe34Lz3v5cpklWDBqgQ6IxY2+VM3C1jBHZp9yQDcRDwD4NlvRSs 7hOMNnfsusE1Hm68WDAOPfrpphiwaIRtCBuLuY+6xnS5q2tX2nbvNPI/KV3adRWZakVK j+V8d8aRc4TF5Yhj5h+3F2lYhbBqwN9raawJs28Ubo2yKYZQapV1amnBYPYrG7KYZKwt Bd9ZLtaIyzR1nCcSHusP//wd8EpgLRAtL95DUwgPwshFvtqbHi3CAvYy5mEch21OxkoO qO0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NMHFzN1cvcghWgJb3Z8DYwame2bS0CwI9GV1983uQU0=; b=DooENNJiVmd5JKDJoPKA2gp6X1cY5dtMqsfhOWEq5A3Lu1mHmSeYSG+eagZ+k9FFF8 lbesD2J7VNHRptbIVW6Uw6zx+Hsw6xDzJIPVd82c+rjAxVEs1unedZVyzpsnXT67g40m UEIGi8xTWqaSyn+iTfF1VmreuCzVwsseM1gpe0pU5U31A9eQ2WnA0pH7KR2h+M6POzp4 LJgU3AvAFLnplJ7GzBNE8cacLOPDXzUsxqn+TrJG8ruXSPrmU0Nqko5HmqIu3SRCycZE 1stqs/Ua4z3J2u/+UdJVxe2M0zNkbTVZH6Wwa/tIGIsjUa9Dxq4hdFk4K9mJ3FW0RRDk vJQQ== X-Gm-Message-State: AA+aEWaZSlo61N8I9g5z+yG+obsHddolAnMxPriY8HM4szzkdOXINpOA 1Vdtwc7k8TcdXRjqH0g8JhygMs1sfgrsH04hbIM= X-Google-Smtp-Source: AFSGD/XRjxhWRsH4bS4BA7nunoEwV6dNVcF76yYGsRm/9/V5YRahYn7t8HQKQ1LxC4gyYjkgwQYcDk2X2gt7l6o3HQM= X-Received: by 2002:a24:d08d:: with SMTP id m135mr12628991itg.89.1543954664491; Tue, 04 Dec 2018 12:17:44 -0800 (PST) MIME-Version: 1.0 References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> In-Reply-To: From: Christopher Morrow Date: Tue, 4 Dec 2018 15:17:33 -0500 Message-ID: To: Joe Touch Cc: Stewart Bryant , tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard Content-Type: multipart/alternative; boundary="00000000000053907b057c37f51e" Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 20:17:48 -0000 --00000000000053907b057c37f51e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2018 at 5:40 AM Joe Touch wrote: > Take that to the standards wg. Don=E2=80=99t stick your head in the sand = and try > to do an end run in ops. And don=E2=80=99t call any of this a security is= sue that > it isn=E2=80=99t. > > > Joe, I think one of the 3 pillars of security is: "Availability" (the other two are 'Confidentiality' and 'Integrity') I think the point that Nick and Gert are outlining is that if the case is that the hardware available will have no fast-path processing for packets with obtuse patterns or sets of extension headers those packets will get sent to the control-plane (slow-path). That slow-path being congested will cause availability problems. Actually, whether or not the control-plane fails under such load may not even matter, if the rate-limiting of the packets here is such that (as gert said) all but a trickle of the interesting packets are forwarded. A solution might be to have a mode where a router may just ignore all headers except the src/dst-ip and simply forward all packets, trusting that the conversing adults will sort out problems with unknown/new/experimental headers or with a tortured ordering of headers (for instance). This will also cause some operational headaches: "Please drop all traffic toward ipX with protoY and dst-port Z" but perhaps it's still acceptable to some folk to operate like this? --00000000000053907b057c37f51e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable




On Tue, Nov 27, 2018 at 5:40 AM Joe Touch <touch@strayalpha.com> wrote:
<= /div>
Take that to the standards wg. Don=E2= =80=99t stick your head in the sand and try to do an end run in ops. And do= n=E2=80=99t call any of this a security issue that it isn=E2=80=99t.



Joe, I think one of the 3 pillars = of security is: "Availability" (the other two are 'Confidenti= ality' and 'Integrity')
=C2=A0
I think the = point that Nick and Gert are outlining is that if the case is that the hard= ware available will have no fast-path processing for packets with obtuse pa= tterns or sets of extension headers those packets will get sent to the cont= rol-plane (slow-path). That slow-path being congested will cause availabili= ty problems.

Actually, whether or not the control-= plane fails under such load may not even matter, if the rate-limiting of th= e packets here is such that (as gert said) all but a trickle of the interes= ting packets are forwarded.

A solution might be to= have a mode where=C2=A0 a router may just ignore all headers except the sr= c/dst-ip and simply forward all packets, trusting that the conversing adult= s will sort out problems with unknown/new/experimental headers or with a to= rtured ordering of headers (for instance). This will also cause some operat= ional headaches: "Please drop all traffic toward ipX with protoY and d= st-port Z" but perhaps it's still acceptable to some folk to opera= te like this?

--00000000000053907b057c37f51e-- From nobody Tue Dec 4 14:57:00 2018 Return-Path: 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 70237128D0C; Tue, 4 Dec 2018 14:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 NgSA_XzELUpC; Tue, 4 Dec 2018 14:56:50 -0800 (PST) Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8C9123FFD; Tue, 4 Dec 2018 14:56:50 -0800 (PST) Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 5547822221; Tue, 4 Dec 2018 17:56:49 -0500 (EST) (envelope-from heard@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=z/3 fm2lfa445V3sR6GciBX8UGls=; b=vL+yl2Ph7HyDhVKRoYvgXW1F8eJpbWjtPDV UuX6wO/fcYYDiA6Sor02qQoPu0zZTgaYjkP+oH1c+M+3+wvfKP5RpUaJHV/w2gPS yJ2+4ck6uHsj5VW/srz63jWH5CO0las7RvcFJxAkpSSI2PfPraKthsgiAjRw32iu HdRCnIOo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= hAuBf3xP7T5BanvDOZXaNgDwUODcv7gMQeBhatr6kmDnsFFPGcO7VwH+jtKlWSq/ aExnlkLMSd5r2SW3tWIYdN+FQfK+5IKXW6GaytPk8Gnjd9dFiuagbXmCCNsKspm5 l8BKA8Ts8ZllkogiKIhLu+7KkClYLbxCSWXcxgX+iXY= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 4E0FD2221F; Tue, 4 Dec 2018 17:56:49 -0500 (EST) (envelope-from heard@pobox.com) Received: from mail-it1-f174.google.com (unknown [209.85.166.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id BC64122219; Tue, 4 Dec 2018 17:56:45 -0500 (EST) (envelope-from heard@pobox.com) Received: by mail-it1-f174.google.com with SMTP id x19so18318741itl.1; Tue, 04 Dec 2018 14:56:45 -0800 (PST) X-Gm-Message-State: AA+aEWYxytsbsM+uaQilUY6nLHlFuoex3UJL6w6Yy+0vd6/Hbh18BGQJ Vo40MYxyIyijEgp/eR302rR6l937BRbCbjSx96o= X-Google-Smtp-Source: AFSGD/W2bgjtG2WPTqYoBYYnGwbap2VsUwQX284gbs2b/tHkE2EbYfH+5jUzWNvkxdojpKqnUWSxYE4X5zGhH5vBEnU= X-Received: by 2002:a02:b529:: with SMTP id l38mr18924506jaj.25.1543964204581; Tue, 04 Dec 2018 14:56:44 -0800 (PST) MIME-Version: 1.0 From: "C. M. Heard" Date: Tue, 4 Dec 2018 14:56:32 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Christopher Morrow Cc: Joe Touch , Stewart Bryant , TSV-ART , OPSEC , IETF , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: DFD2AF30-F817-11E8-9417-F5C31241B9FE-06080547!pb-smtp20.pobox.com Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 22:56:53 -0000 On Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote: > A solution might be to have a mode where a router may just ignore all > headers except the src/dst-ip and simply forward all packets, trusting > that the conversing adults will sort out problems with unknown/new/ > experimental headers or with a tortured ordering of headers (for > instance). Glad to hear you say that, because that's exactly what RFC 7045 envisions as the default forwarding behavior: Any forwarding node along an IPv6 packet's path, which forwards the packet for any reason, SHOULD do so regardless of any extension headers that are present [...] Recognizing that processing of Hop-by-Hop Options in the fast path is costly, RFC 8200 formally dropped the requirement for every router to process them by default: NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so. What some of us would like to see is a statement in the draft that it's just fine to operate this way (Christian Huitema made that suggestion earlier in this thread, and so did I in my detailed last-call comments). Mike Heard From nobody Tue Dec 4 15:24:20 2018 Return-Path: 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 25D6A127332; Tue, 4 Dec 2018 15:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 c6vWXb4PldL7; Tue, 4 Dec 2018 15:24:09 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 CD0E912E7C1; Tue, 4 Dec 2018 15:24:08 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id x6so15103343ioa.9; Tue, 04 Dec 2018 15:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XQS6VgfoBf7NphuBezLckvOm1t4Fhl061u2zgrFg4o4=; b=ogiyE0yjsVatLRvld/PWYjZulSV5KCoJo4IQT760e9Y2B7txlslx9ufkpGmV3I91bb 7ACnnI3JSvOg5CnxcC9sra+Ak/vAlYEUFYDVNLH5z6+rWWus1qfYTgRGE8e12HxQZ3RR zmVO9lxLGU8lbVGBt4Ggt4MmlP4O85lTFMI1wUteYES95eJNYr+IelkihKpbWpqZ8Fl5 IRR5Gdkiv/v9CzQTFavipZ97thbejjd0O0YSrGHT9ebaGyf8yQ1F834bjkYFs6Z9WGRw M582Y85rUGm1BgQK8QE3u+gCHcyGoDghtUqGY0ITBWOBSbNfjAdKo+8zKEehUdtukQpK pNQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XQS6VgfoBf7NphuBezLckvOm1t4Fhl061u2zgrFg4o4=; b=SigVFbc3iuW9j7BELndHHvZPYfAhmHba6zSKPbg+dICzolkCE4IDv3HBXsYcAKrQMj u6PTFrhG0+89CqkDrba67iA1UksXEfJT4UOs6Lm/bb2tGsacfIP0bgsKY4wrGCSAaEGL 4q0n1+ze2NQxlggYF3EXBtXx4Y59HbwtHLvGeU/5uaDURrSR591L0GEjEei3/dq9l2X/ RYrnEH5j9dUGCxVDc84dXh4cBsOVNAbAGBRLhyXxI1tZY4tvW6g6KAHE+juHZu55AWK7 b9fq9xTOo+4afrPUh26gxeRyJfJgXXnhtOk/4Guqfeiy5MpZ0QBpvBLaVfxNF4RxZHt1 7sfg== X-Gm-Message-State: AA+aEWacpvnpUQNrdcSl433R4YtIJ5ZGHXKSM8uzJh1Kxvrfp8UpvMoU QN5YNSfY6Lw3F/dDxQYlfeUfJaw0QDQ6kQ1vAqk= X-Google-Smtp-Source: AFSGD/Uq4QXhbs8Lshcs5MtJD7ccpJs7wWvCFNLEyyYtqhUb/+TfiErfQBuFzPtNgmB8761T5IXo1wwJ+xiKTRAptR8= X-Received: by 2002:a5d:8ac6:: with SMTP id e6mr10978718iot.235.1543965847885; Tue, 04 Dec 2018 15:24:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Tue, 4 Dec 2018 18:23:55 -0500 Message-ID: To: heard@pobox.com Cc: Joe Touch , Stewart Bryant , tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard Content-Type: multipart/alternative; boundary="000000000000e89e15057c3a8fd5" Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 23:24:11 -0000 --000000000000e89e15057c3a8fd5 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 4, 2018 at 5:56 PM C. M. Heard wrote: > On Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote: > > A solution might be to have a mode where a router may just ignore all > > headers except the src/dst-ip and simply forward all packets, trusting > > that the conversing adults will sort out problems with unknown/new/ > > experimental headers or with a tortured ordering of headers (for > > instance). > > Glad to hear you say that, because that's exactly what RFC 7045 > envisions as the default forwarding behavior: > > I'm glad I'm not too nuts :) > Any forwarding node along an IPv6 packet's path, which forwards the > packet for any reason, SHOULD do so regardless of any extension > headers that are present [...] > > this does mean that: "please filter the flarbly protocol traffic, eh-1234" is going to be very hard to do in the network. > Recognizing that processing of Hop-by-Hop Options in the fast path is > costly, RFC 8200 formally dropped the requirement for every router to > process them by default: > > NOTE: While [RFC2460] required that all nodes must examine and > process the Hop-by-Hop Options header, it is now expected that nodes > along a packet's delivery path only examine and process the > Hop-by-Hop Options header if explicitly configured to do so. > > it's important to note that some platforms can't look beyond a certain number of headers, and that ordering of the headers us up to the src, which when they are being mean is ... bad :( Even platforms that can look more than a few headers deep pay for that with clock cycles, so 100g -> 400g -> 1tbps interfaces are less and less likely to see further into the packet(s). > What some of us would like to see is a statement in the draft that it's > just fine to operate this way (Christian Huitema made that suggestion > earlier in this thread, and so did I in my detailed last-call comments). > > oh, good. I like that idea... noting that: "makes filtering bad traffic pretty impossible" though. > Mike Heard > --000000000000e89e15057c3a8fd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Dec 4, 2018 at 5:56 PM C. M. Heard <heard@pobox.com> wrote:
On = Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote:
> A solution might be to have a mode where=C2=A0 a router may just ignor= e all
> headers except the src/dst-ip and simply forward all packets, trusting=
> that the conversing adults will sort out problems with unknown/new/ > experimental headers or with a tortured ordering of headers (for
> instance).

Glad to hear you say that, because that's exactly what RFC 7045
envisions as the default forwarding behavior:


I'm glad I'm not too nuts :)
=C2=A0
=C2=A0 =C2=A0Any forwarding node along an IPv6 packet's path, which for= wards the
=C2=A0 =C2=A0packet for any reason, SHOULD do so regardless of any extensio= n
=C2=A0 =C2=A0headers that are present [...]


this does mean that: "please filt= er the flarbly protocol traffic, eh-1234" is going to be very hard to = do in the network.
=C2=A0
Recognizing that processing of Hop-by-Hop Options in the fast path is
costly, RFC 8200 formally dropped the requirement for every router to
process them by default:

=C2=A0 =C2=A0NOTE: While [RFC2460] required that all nodes must examine and=
=C2=A0 =C2=A0process the Hop-by-Hop Options header, it is now expected that= nodes
=C2=A0 =C2=A0along a packet's delivery path only examine and process th= e
=C2=A0 =C2=A0Hop-by-Hop Options header if explicitly configured to do so.

it's important to note that some p= latforms can't look beyond a certain number of headers, and that orderi= ng of the headers us up to the src, which when they are being mean is ... b= ad :( Even platforms that can look more than a few headers deep pay for tha= t with clock cycles, so 100g -> 400g -> 1tbps interfaces are less and= less likely to see further into the packet(s).
=C2=A0
What some of us would like to see is a statement in the draft that it's=
just fine to operate this way (Christian Huitema made that suggestion
earlier in this thread, and so did I in my detailed last-call comments).

oh, good. I like that idea... noting t= hat: "makes filtering bad traffic pretty impossible" though.
=C2=A0
Mike Heard
--000000000000e89e15057c3a8fd5-- From nobody Tue Dec 4 16:56:39 2018 Return-Path: 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 965BF1200B3; Tue, 4 Dec 2018 16:56:29 -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 OTwrDmMgEXMo; Tue, 4 Dec 2018 16:56:26 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 77E9F130DC2; Tue, 4 Dec 2018 16:56:26 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id k8so9151643pls.11; Tue, 04 Dec 2018 16:56:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lBpXsBRX6nEHVMWdlLh+dY34d61Q/C0CDY7qNBcXS4E=; b=T2X+GSqIHRt9zkUF0856z23zBUL76w/dLe51hqASdQndLGK6wDwg5ZXObaVn9EAnur atO2Dl6rqE+AKTWv4fHNqe5IbetISC2hMWKdjI8Y30oy2FY6p5sGov6PrDJ02tCIKgrB RMFh51dQ0oHAwA2YVFm/xdyewuAduFewgGQ0PEQq7ZSAsJOUPKT1zMgPoRGIwcxqKo8I AbQlo2YDx0LyNKvdFB9uCmSlSu2/ckluFOHkCU/8hVJu2gU8NoOkNlKTr+Nl4zXJhZbE RG1AjVIe8ip90DH3pJN9wiqLUcojC+DFE/x0/AEG/N35e5s2EFtcVvEQD94KWc/eD6PF GQIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lBpXsBRX6nEHVMWdlLh+dY34d61Q/C0CDY7qNBcXS4E=; b=X8BwaSRcIS328lsICD1rpCFTUDwOBQhiaVn7bvLi6oykzG9JGNfMBPk7d2Au9SUYmL y9RLPxil74vQJozvV83KIzH7FyKNyDwqdcuvtb/EMteDjMTDCDf+yMImY5lIERUWEDuu H7z1f4JZ7fry832noA5LFr06ddHxo5tm1DZjRIkGkx+VofR5R4Um9tLm1jLGHvxTUX8t mzRAQ6jmXidBxJQanKlPyLNnRS+pcVV1Xeo+kwoiPYRIQFeaigeUgvhtpZ+Yx//GkUYY srl1fVh28YiNVmCu8jIhwYEMNatpdS3tNw7Cw9llULqAmWHoNA+9VQ987SBRJsC+qY+l Th5g== X-Gm-Message-State: AA+aEWYBgnqSYm1B8Ek06K6OILP+MYYS2QNpeb2Nb007nk30NJOXECWf egZXSPmcAs6CdjLGpQlqPxCbQfjB X-Google-Smtp-Source: AFSGD/WQ/H/d+eBAAHFAnwpzsuIBkLSczx8n59PmkQgzTUgrmH+BDRHLS1SPv7bz0XfFfPe01VbuhA== X-Received: by 2002:a17:902:2aaa:: with SMTP id j39mr22743381plb.335.1543971385702; Tue, 04 Dec 2018 16:56:25 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id n70sm25742545pfi.185.2018.12.04.16.56.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 16:56:24 -0800 (PST) To: Christopher Morrow , heard@pobox.com Cc: ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org References: From: Brian E Carpenter Message-ID: Date: Wed, 5 Dec 2018 13:56:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 00:56:30 -0000 On 2018-12-05 12:23, Christopher Morrow wrote: > On Tue, Dec 4, 2018 at 5:56 PM C. M. Heard wrote: > >> On Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote: >>> A solution might be to have a mode where a router may just ignore all >>> headers except the src/dst-ip and simply forward all packets, trusting >>> that the conversing adults will sort out problems with unknown/new/ >>> experimental headers or with a tortured ordering of headers (for >>> instance). >> >> Glad to hear you say that, because that's exactly what RFC 7045 >> envisions as the default forwarding behavior: >> >> > I'm glad I'm not too nuts :) > > >> Any forwarding node along an IPv6 packet's path, which forwards the >> packet for any reason, SHOULD do so regardless of any extension >> headers that are present [...] >> >> > this does mean that: "please filter the flarbly protocol traffic, eh-1234" > is going to be very hard to do in the network. Yes. But extension headers were explicitly defined to be from end system to end system, not for middleboxes. So that difficulty was designed in. >> Recognizing that processing of Hop-by-Hop Options in the fast path is >> costly, RFC 8200 formally dropped the requirement for every router to >> process them by default: >> >> NOTE: While [RFC2460] required that all nodes must examine and >> process the Hop-by-Hop Options header, it is now expected that nodes >> along a packet's delivery path only examine and process the >> Hop-by-Hop Options header if explicitly configured to do so. >> >> > it's important to note that some platforms can't look beyond a certain > number of headers, and that ordering of the headers us up to the src, which > when they are being mean is ... bad :( Even platforms that can look more > than a few headers deep pay for that with clock cycles, so 100g -> 400g -> > 1tbps interfaces are less and less likely to see further into the packet(s). Yes. The IPv6 header was designed so that all the information needed for *forwarding* was at the front. The extension headers were designed on the assumption that they would be analysed by a CPU, not by an ASIC or FPGA, so that the linked-list model seemed fine. I think people believed that endpoints would take over DPI filtering: https://www.cs.columbia.edu/~smb/papers/distfw.pdf Brian >> What some of us would like to see is a statement in the draft that it's >> just fine to operate this way (Christian Huitema made that suggestion >> earlier in this thread, and so did I in my detailed last-call comments). >> >> > oh, good. I like that idea... noting that: "makes filtering bad traffic > pretty impossible" though. > > >> Mike Heard >> > From nobody Tue Dec 4 17:10:16 2018 Return-Path: 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 91EB4130E0E; Tue, 4 Dec 2018 17:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 XStPtXsgUD0S; Tue, 4 Dec 2018 17:10:06 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EAC1200B3; Tue, 4 Dec 2018 17:10:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IPCTIxFW0ybx9TU3J0sp3YAZpaO+xknJN4/YKKEmFEI=; b=prlnIb2PXUgbtd9b4i5d+Iwqc fV9sT8sspLcuQ1fFfZ6lxDxZiORcV5vjvAA3EAf9V1qO6dOSmyXzsxhcUZcd9ArycaSZw+kDhRDjH mGd5LYJ+Sn2K9m/hk8aPMRIYtuGfg2wfeBpyZ/mF+bWIMpdN4TJAPiPjrlj+/3gYz61uGjueqOWtX OV0ICopQV3WIUFdaXHHz//X3o0NEpD1drkAUthJnAGaSG2ndCMp16FAUl3eKy6K6g/DJ1CpBBwVZz lKbqxGA5+lggEN6PT935ufUGX8b/Qv7NyZyJnX/lca9BOvyrIXqKZb7wmndBYbg9ttDZmQ/UmIKF7 eIaIiq2qA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57792 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gULhU-001NNk-QK; Tue, 04 Dec 2018 20:10:05 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_01DEA340-BB25-4BB9-BEE7-0F7357884FCF" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Tue, 4 Dec 2018 17:10:03 -0800 Cc: Stewart Bryant , tsv-art , opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard Message-Id: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> To: Christopher Morrow X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 01:10:09 -0000 --Apple-Mail=_01DEA340-BB25-4BB9-BEE7-0F7357884FCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 4, 2018, at 12:17 PM, Christopher Morrow = wrote: >=20 >=20 >=20 >=20 >=20 > On Tue, Nov 27, 2018 at 5:40 AM Joe Touch > wrote: > Take that to the standards wg. Don=E2=80=99t stick your head in the = sand and try to do an end run in ops. And don=E2=80=99t call any of this = a security issue that it isn=E2=80=99t.=20 >=20 >=20 >=20 > Joe, I think one of the 3 pillars of security is: "Availability" (the = other two are 'Confidentiality' and 'Integrity=E2=80=99) It is... > =20 > I think the point that Nick and Gert are outlining is that if the case = is that the hardware available will have no fast-path processing for = packets with obtuse patterns or sets of extension headers those packets = will get sent to the control-plane (slow-path). That slow-path being = congested will cause availability problems. If that happens, the packets with these headers can easily be throttled = - thus avoiding a security issue. However, what you=E2=80=99re basically saying is that =E2=80=9Cit is a = security risk to send packets to a router because it might have to do = work=E2=80=9D. Yeah, big surprise. Either do the work or limit the = impact. But that=E2=80=99s not the kind of security risk we associate = with availability - a good example of which would be that sending a = single packet would cause the work of 1000. But none of that is happening here. >=20 > Actually, whether or not the control-plane fails under such load may = not even matter, if the rate-limiting of the packets here is such that = (as gert said) all but a trickle of the interesting packets are = forwarded. But then that=E2=80=99s not a security problem. >=20 > A solution might be to have a mode where a router may just ignore all = headers except the src/dst-ip and simply forward all packets, trusting = that the conversing adults will sort out problems with = unknown/new/experimental headers or with a tortured ordering of headers = (for instance). This will also cause some operational headaches: "Please = drop all traffic toward ipX with protoY and dst-port Z" but perhaps it's = still acceptable to some folk to operate like this? That works only for HBH options of type 00. Others require particular = actions when not supported. Joe= --Apple-Mail=_01DEA340-BB25-4BB9-BEE7-0F7357884FCF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 4, 2018, at 12:17 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:





On Tue, Nov 27, 2018 = at 5:40 AM Joe Touch <touch@strayalpha.com> wrote:
Take that to the = standards wg. Don=E2=80=99t stick your head in the sand and try to do an = end run in ops. And don=E2=80=99t call any of this a security issue that = it isn=E2=80=99t.



Joe, I think one of the 3 pillars of = security is: "Availability" (the other two are 'Confidentiality' and = 'Integrity=E2=80=99)

It is...

 
I = think the point that Nick and Gert are outlining is that if the case is = that the hardware available will have no fast-path processing for = packets with obtuse patterns or sets of extension headers those packets = will get sent to the control-plane (slow-path). That slow-path being = congested will cause availability = problems.

If that = happens, the packets with these headers can easily be throttled - thus = avoiding a security issue.

However, what you=E2=80=99= re basically saying is that =E2=80=9Cit is a security risk to send = packets to a router because it might have to do work=E2=80=9D. Yeah, big = surprise. Either do the work or limit the impact. But that=E2=80=99s not = the kind of security risk we associate with availability - a good = example of which would be that sending a single packet would cause the = work of 1000.

But none of that is = happening here.


Actually, whether or not the control-plane fails under such = load may not even matter, if the rate-limiting of the packets here is = such that (as gert said) all but a trickle of the interesting packets = are forwarded.

But then that=E2=80=99s not a security problem.


A solution might be to have a mode = where  a router may just ignore all headers except the src/dst-ip = and simply forward all packets, trusting that the conversing adults will = sort out problems with unknown/new/experimental headers or with a = tortured ordering of headers (for instance). This will also cause some = operational headaches: "Please drop all traffic toward ipX with protoY = and dst-port Z" but perhaps it's still acceptable to some folk to = operate like this?

That works only for HBH = options of type 00. Others require particular actions when not = supported.

Joe
= --Apple-Mail=_01DEA340-BB25-4BB9-BEE7-0F7357884FCF-- From nobody Tue Dec 4 17:17:26 2018 Return-Path: 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 04B31130DD0; Tue, 4 Dec 2018 17:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 c7NbOXmRxiS8; Tue, 4 Dec 2018 17:17:23 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B929B130DC2; Tue, 4 Dec 2018 17:17:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cO2f3WuaG3vj/jEXiZyEpdH3NgJoZjQ7ZnspymDeHk4=; b=w5ajJ8DhsqkCDTDy6cU70Apk5 UNs9TMtgeY+o4U/9nnLpqoCVTQnBaNe28ZAo2p/dT49DYKKftOg8UvTDNL2M53qe9tv2vXzVrzaLq FAwKH0epWhA0HoTtKW6J3vFhjTZV5Hc4Z+snBZjZTBbdCHYEKtnZ18TUPd8bW47T3XM1OsHzrJcuj x3baZhg54phd9mLLeTYAM8UY6hZcNeM193YlhWq2bIYLigHz8NDtGPNtevUxe17Q+uZ5vIuAzkVm5 CoUvHsg2C2hrQeieoIbbN3YTbPYNhkmo2gL5L4L+Jx+D3ZD7Qmuixwuo0NHWdXTRroOcJWShXcV4t hdLrwGIpg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57836 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gULoY-001SkA-C8; Tue, 04 Dec 2018 20:17:23 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Tue, 4 Dec 2018 17:17:21 -0800 Cc: Christopher Morrow , IETF , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard , OPSEC , TSV-ART , Stewart Bryant Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "C. M. Heard" X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 01:17:25 -0000 It=E2=80=99s difficult to reconcile the text from other RFCs below with = the fact that 8200 kept the 01, 10, and 11 option types. Joe > On Dec 4, 2018, at 2:56 PM, C. M. Heard wrote: >=20 > On Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote: >> A solution might be to have a mode where a router may just ignore = all >> headers except the src/dst-ip and simply forward all packets, = trusting >> that the conversing adults will sort out problems with unknown/new/ >> experimental headers or with a tortured ordering of headers (for >> instance). >=20 > Glad to hear you say that, because that's exactly what RFC 7045 > envisions as the default forwarding behavior: >=20 > Any forwarding node along an IPv6 packet's path, which forwards the > packet for any reason, SHOULD do so regardless of any extension > headers that are present [=E2=80=A6]r This text is in direct contradiction to RFC2460 as per above.=20 >=20 > Recognizing that processing of Hop-by-Hop Options in the fast path is > costly, RFC 8200 formally dropped the requirement for every router to > process them by default: >=20 > NOTE: While [RFC2460] required that all nodes must examine and > process the Hop-by-Hop Options header, it is now expected that nodes > along a packet's delivery path only examine and process the > Hop-by-Hop Options header if explicitly configured to do so. That is an expectation of the inadequacy of others. It does not clearly = drop the requirement. >=20 > What some of us would like to see is a statement in the draft that = it's > just fine to operate this way (Christian Huitema made that suggestion > earlier in this thread, and so did I in my detailed last-call = comments). >=20 > Mike Heard >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Tue Dec 4 17:18:34 2018 Return-Path: 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 85AA3131027; Tue, 4 Dec 2018 17:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 B1IDSeqL-9fV; Tue, 4 Dec 2018 17:18:27 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605D8130FD1; Tue, 4 Dec 2018 17:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=x0fkTxFgXDFpoaMzbI+HjCix1LEhjbgEHRymhna8RhA=; b=F92oEDrPLuoQpEY5DYLVRS5X9 HOtewdyv0uyOqpwETNNsPTFonzLp1v2I6SBxhs/oc95AUw3cAdQgnKfw16B/LxqLqRXDCAfdnxSGS da8qzjf11nX9GJDpp5PWdgbl0AFmgZmNSWnyPF1XJNqaZt/3A/ERSFljgf5YytbY6IMTxSzNU5RN9 X0NiYIfIs8ZFbOA2QQumMt3GRA9YTa8r0Ppbz1VOk3s1/UaJUPg4P3UDv7hlEjbuLg4B0/tMxG/0p e/jhgbxbYOFIE2O6fBQjS3vTZwNz++r+WB69rHYJHO3CyeuQukicyENusKIimk78KrOPVeZNwMqO9 VpU9Frelw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57840 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gULpa-001TV1-Bn; Tue, 04 Dec 2018 20:18:26 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_7BC74984-129F-4A25-A0D2-2EC78724BC78" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Tue, 4 Dec 2018 17:18:25 -0800 Cc: Christopher Morrow , heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-Id: <6738EDA7-FDE9-4683-8C0C-FB8C33F7B185@strayalpha.com> References: To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 01:18:31 -0000 --Apple-Mail=_7BC74984-129F-4A25-A0D2-2EC78724BC78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 4, 2018, at 4:56 PM, Brian E Carpenter = wrote: >=20 > Yes. But extension headers were explicitly defined to be from end = system > to end system, not for middleboxes. So that difficulty was designed = in. Not HBH ones...= --Apple-Mail=_7BC74984-129F-4A25-A0D2-2EC78724BC78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Dec 4, 2018, at 4:56 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Yes. But extension headers were = explicitly defined to be from end system
to end system, not for middleboxes. So that difficulty was = designed in.

Not HBH ones...
= --Apple-Mail=_7BC74984-129F-4A25-A0D2-2EC78724BC78-- From nobody Tue Dec 4 18:29:52 2018 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 479DE130E0A; Tue, 4 Dec 2018 18:29:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget To: Cc: opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154397698424.4865.5720014731238210447@ietfa.amsl.com> Date: Tue, 04 Dec 2018 18:29:44 -0800 Archived-At: Subject: [OPSEC] Secdir last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 02:29:44 -0000 Reviewer: Nancy Cam-Winget Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Significant nits: This document provides recommendations that do include security considerations; but it is missing privacy considerations. While there may be no (or little impact), there should at least be some mention of privacy considerations in Section 6 (or create a new section). The document also references two drafts that are expired. General: it would be useful to reference the “EH Types” (RFC7045?) so that it is clearly distinct from the general “Option types” defined in RFC8200 (and also include the RFC8200 as reference on the first occurrence of “option types”) Section 2.1: the Terminology needs to be updated to comply with the latest BCP14 and RFC8174 Section 2.3: given the expressed terminology, I believe the “is *not*” is better stated as “SHOULD NOT” to be consistent with IETF guidelines in RFC8174. Section 2.3: this section not about “Conventions” but is really more about “Assumptions” with some recommendations already sprinkled, so the section should fall more in the “General Discussion” section Section 3.1: Not sure this is correct: “[RFC7045] identifies which of the currently assigned Internet Protocol numbers identify IPv6 EHs vs. upper-layer protocols. ” Reading RFC7045: it seems to be focused on how to process the extensions appropriately not sure it really does the identification of protocol layering or distinction? Simple Editorial nits: Section 2.3: redundant reference. Suggest to update from: “in [RFC7045]. Namely (from [RFC7045]),” to: “namely from [RFC7045]:” Section 3.1: the following sentence or perhaps the last clause (“they contain”) is not needed: “ This document discusses the filtering of packets based on the IPv6 EHs (as specified by [RFC7045]) they contain.” From nobody Tue Dec 4 18:59:27 2018 Return-Path: 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 DF2A5130DDE; Tue, 4 Dec 2018 18:59:19 -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 2KGjAnkVbz58; Tue, 4 Dec 2018 18:59:17 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 16FA2130DD2; Tue, 4 Dec 2018 18:59:17 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id u6so9298240plm.8; Tue, 04 Dec 2018 18:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FNNimi6fpEODc+K+M0NEHfqvixy6li7gOO8qTv5Rxjw=; b=hSITjHIQJYRttZTTkLsPg7UcU5frSZ/AWcr2IQ8Qln6BJ5zk1o+ApN11GdmuCsP/HM 52GFwilN5bKIcz96khEmjKNKxHo7w5VbJw1RUFOyN2V+hLrxqStUZ9kL3dn8KHFh9jpl 7qK+uaKCr/J9UKjg73EiZYV6vvhIsrU3puMLhWXiFVl9uQ3mM/3AILqtumFRRR/in8Ur tSshWj2KRpvkIdBTsB1md1GKj5uLsqhSjNZTC5EsTsLE2EOK8K16leTMnu0R7lyWqsKz 8zICouMxNERyxycED2OgpRiHCZpreNrpoli/JJwaFP6TDfy3NQI/dhM1u+mXTfmbl3SE rAGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FNNimi6fpEODc+K+M0NEHfqvixy6li7gOO8qTv5Rxjw=; b=LoCy/rMPPNy48o9nPX/9UjSv3NLPD+x48xFcFb2pGCkXpR838nf9Zj1cg9BUH2AFDw gvCA7HTsCWryadABZQpHaY4pmGPV9NfpJ0wTHuLXh6rBmRckHC0CMVbCQHlZgiV20Mir hgbD/Hk1ZDaBIhovsNfwUB5kcbbtW0FyMyumvJ6IpTRLo2rf702fZB+771VDc3vCNbYV 5VYKSeM9Eikdc48RzoCXfh7bj3XnArBDEnx9nl08s9gs3SxI0/bcKJt0ye2z6mHQ+Jnh 42k67wJxmIWKReeobgzHTw2Yu5kq4FtsPg+9nHg5wgyxLbnBGbgqHwcmWskLH3CWMIsT mykA== X-Gm-Message-State: AA+aEWbQu0wypRLqjsqmOmV8Dy84lijC4xj22F/AZFCEzxLp81AvfTIn wNxHuiggAmdSjHcyF/ctnmUgxg3GaIs= X-Google-Smtp-Source: AFSGD/VQeaTX0oJwED4VzZq0eZJa09r5PJlZFWFcmG016L/uXKn2bbG214uKt+rbMrdoBcCs8fhTlQ== X-Received: by 2002:a17:902:d83:: with SMTP id 3mr1112993plv.43.1543978756310; Tue, 04 Dec 2018 18:59:16 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id i4sm35259979pfj.82.2018.12.04.18.59.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 18:59:15 -0800 (PST) To: Joe Touch , "C. M. Heard" Cc: IETF , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , TSV-ART References: From: Brian E Carpenter Message-ID: <42f482b8-ef85-909b-861f-c95a6a9efde1@gmail.com> Date: Wed, 5 Dec 2018 15:59:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 02:59:20 -0000 On 2018-12-05 14:17, Joe Touch wrote: > It=E2=80=99s difficult to reconcile the text from other RFCs below with= the fact that 8200 kept the 01, 10, and 11 option types. >=20 > Joe >=20 >> On Dec 4, 2018, at 2:56 PM, C. M. Heard wrote: >> >> On Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote: >>> A solution might be to have a mode where a router may just ignore al= l >>> headers except the src/dst-ip and simply forward all packets, trustin= g >>> that the conversing adults will sort out problems with unknown/new/ >>> experimental headers or with a tortured ordering of headers (for >>> instance). >> >> Glad to hear you say that, because that's exactly what RFC 7045 >> envisions as the default forwarding behavior: >> >> Any forwarding node along an IPv6 packet's path, which forwards the >> packet for any reason, SHOULD do so regardless of any extension >> headers that are present [=E2=80=A6]r >=20 > This text is in direct contradiction to RFC2460 as per above. Of course. RFC 7045 updated RFC2460. >=20 >> >> Recognizing that processing of Hop-by-Hop Options in the fast path is >> costly, RFC 8200 formally dropped the requirement for every router to >> process them by default: >> >> NOTE: While [RFC2460] required that all nodes must examine and >> process the Hop-by-Hop Options header, it is now expected that nodes= >> along a packet's delivery path only examine and process the >> Hop-by-Hop Options header if explicitly configured to do so. >=20 > That is an expectation of the inadequacy of others. It does not clearly= drop the requirement. If so, that was a drafting error. RFC 7045 already formally changed it to a SHOULD. And IMHO it's entirely correct. For example, making the open Internet com= pletely transparent to HbH means that a HbH-using application has a chanc= e of crossing the open Internet successfully. By contrast, expecting line= -speed routers on multi-Gbit intercontinental links to process HbH condemns such an application to fai= lure. This was all thrashed out when we drafted RFC 7045 and again when we drafted RFC 8200. What's new here is that OPSEC wants to legitimise filtering for reasons other than performance, and that's contentious. Brian >=20 >> >> What some of us would like to see is a statement in the draft that it'= s >> just fine to operate this way (Christian Huitema made that suggestion >> earlier in this thread, and so did I in my detailed last-call comments= ). >> >> Mike Heard >> >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art >=20 >=20 From nobody Tue Dec 4 19:00:33 2018 Return-Path: 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 85A2F131002; Tue, 4 Dec 2018 19:00:12 -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 uEd9N_IgTdWA; Tue, 4 Dec 2018 19:00:10 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 C0C9713102C; Tue, 4 Dec 2018 19:00:09 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id q1so9244557pfi.5; Tue, 04 Dec 2018 19:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=i5q5LE1g0V8VUUy/VWiYXqeizMJVwlzmYmq805s6LTU=; b=RrynwIVzx6mV8gUqTvhtmL3lqJpgOUVAUcTjA9Hwbcj0kQjV9yAkQWrz0m82lBv8aC YxUpbN3SUxiUNyVlHukYUQVSCQ96SgKhhWKgwY8B/gKiyDVHuHEueqBK93W5vEpUpesa BwuP7OKr940ki7LAlcqxNy5t3fUn9VP3Adospx/W+eZZtLVLT9sAa6PY+3ohQhPN0OOf fnR1DT1mtV/ItpkRamhDRtRXK0xJr7eZoM6zjXRnndgNiIExsRCtvl0kobs0dB2MiCuU 9nZmb6muaSddc/3cqvdm/Po/SZWUD4Siy2UC6FuJqjYBvY6pJPNF9B23J29F1QvwWA5w jgiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=i5q5LE1g0V8VUUy/VWiYXqeizMJVwlzmYmq805s6LTU=; b=W5U57psH7sAqGgO/nra0gCIrZI9EU/mlMOuOpmCj8V/m4a1u30hSCIN3KV0hG4Uldg 5Hnv/DCF+3iLAZR1EOQSMg4fmQBAmOJ90yV+0jw71/3OSuO32jraUH92XymRYMnPCbHF xb3rYx8b6CDujz3LxWDmY1GhCLrpJT+7NdDsndxligM2Ks5yYJYKSsm97LKjKc6Sv+6F Hcg5cqAq2YWTckhSAoWNqSNgY+x0AZ6dDjdgtNDva2j8m/AYsM6S79sJav3TirlSdsAm BgLNsJadlXawSF5kzTBCdRO0p3CqKmPnl6eOwLseW9PtLSmBeHYd2x3GnlgJ0YJEevab yqhg== X-Gm-Message-State: AA+aEWa1OFXtD+QPU7hYHmkGM3Bqa4XLGwRJvHjdTc5pW7fI/2sWrHid hyAYTFsJ790X/tRovaq9oAfuRNP2UpQ= X-Google-Smtp-Source: AFSGD/XlfJvp29w3HLofmz+dF6ozU2I0AKF6KDqgOLV6NzZK+Zxte7Yr++mKh3hJR+AWfXSfJCITNA== X-Received: by 2002:a63:2d82:: with SMTP id t124mr18827983pgt.260.1543978808942; Tue, 04 Dec 2018 19:00:08 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id n186sm31940521pfn.137.2018.12.04.19.00.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 19:00:08 -0800 (PST) To: Joe Touch Cc: Christopher Morrow , heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <6738EDA7-FDE9-4683-8C0C-FB8C33F7B185@strayalpha.com> From: Brian E Carpenter Message-ID: <0406e896-44eb-7dc9-def5-26b9ecbf444f@gmail.com> Date: Wed, 5 Dec 2018 16:00:03 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <6738EDA7-FDE9-4683-8C0C-FB8C33F7B185@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 03:00:21 -0000 On 2018-12-05 14:18, Joe Touch wrote: > > >> On Dec 4, 2018, at 4:56 PM, Brian E Carpenter wrote: >> >> Yes. But extension headers were explicitly defined to be from end system >> to end system, not for middleboxes. So that difficulty was designed in. > > Not HBH ones... Indeed, which is why RFC 7045 changed the requirement. Brian From nobody Tue Dec 4 19:07:24 2018 Return-Path: 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 78E7A130DD2; Tue, 4 Dec 2018 19:07:21 -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 X1MmEO2UDElv; Tue, 4 Dec 2018 19:07:19 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 950E6130DBE; Tue, 4 Dec 2018 19:07:19 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id y126so9261929pfb.4; Tue, 04 Dec 2018 19:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Y3gX3y7Wq8EtbhyOB3aGadOQMTO4pa9wEPmW9zpKEBA=; b=c4Wszhjo5vzoJzj2AId9Pq/w14pmYp4hJDCVToYB1DoG4HVXnK0SGDKwjPWQl/FbT1 vZaXacaTmyTx/KdBv+X0wAKGgpGzX/W3WerYMsMoOfWspZgoOnTz0MA33XEnnc4LCVqX Wcbfb4l72eBsTv8XvzdTzq/Yl5g2bT9zFTXtkPDH7NJQInm/Oke4AtNicxIZuRxecKRD nKrwWqe6sKiMXDB87kNTP/4cJeDrMKPPinCnJm5rktYjfN+/q4WAUb3STHQ/gSH1Gk7q IdSu4d+DlcmBq0PEqnG4MEWoBQl8hVImMesZ7+lVuhQO3k5y69k5OC/YkYZewHbeZLO1 0A1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y3gX3y7Wq8EtbhyOB3aGadOQMTO4pa9wEPmW9zpKEBA=; b=bHAjXHluZmqgtxvQ71nkyufGeDB87NwuELFvemISAf+ZaJ/ot1Ms1ZMbsT1wSyZ1Vu rIPpPqCFbzRMIbtsKfu+NwOtOuNIkAp1M5uDpDawP2TSTtLzoj0dDT4/oc5i0QhB/QPe mgC4etAqD7FfUUBkVEfhSSAJ0eir6vLSsG/9t/UttK4zF+GPqYJtBik98AnrlUthXHnU jCtFvPAvTdAes0myZBiO+jlwmkLAluwDXAYHb/QZ28gYrfREFvSCbws8Hd/X7yx8OVDw 5NixweFDxhsSJgN75ulit8WR++YkdL8uU8mLYImhAQGnrzozd+BhgKn/YLDjKC5Ei7kX QSiw== X-Gm-Message-State: AA+aEWbpAstXtgwUM8jOlRBTRiijjvtXgz2M/orjg9RxANamdGHwhLw/ xEa2sC2R1hVIMCHGB2POa0+lm8n5w9E= X-Google-Smtp-Source: AFSGD/Vo884qQfUmBy8Bm/chzpn+SBwAUC6gtz/wKombkFk8J9qh2ZTQOk7KRN6XcC8a7J7xEFfTsQ== X-Received: by 2002:a63:6782:: with SMTP id b124mr19251209pgc.151.1543979238803; Tue, 04 Dec 2018 19:07:18 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id l22sm17627996pfj.179.2018.12.04.19.07.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 19:07:17 -0800 (PST) To: Nancy Cam-Winget , secdir@ietf.org Cc: opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <154397698424.4865.5720014731238210447@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <80d710f4-8c77-66f4-6837-e93cbb57a008@gmail.com> Date: Wed, 5 Dec 2018 16:07:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <154397698424.4865.5720014731238210447@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSEC] Secdir last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 03:07:21 -0000 On 2018-12-05 15:29, Nancy Cam-Winget wrote: > Section 3.1: Not sure this is correct: =E2=80=9C[RFC7045] identifies > which of the currently assigned Internet Protocol numbers identify > IPv6 EHs vs. upper-layer protocols. =E2=80=9D > Reading RFC7045: it seems to be focused on how to process the extension= s > appropriately not sure it really does the identification of protocol la= yering > or distinction? It set up the IANA registry that makes the distinction: https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ex= tension-header There is no way except looking in that registry to distinguish an EH numb= er from a protocol number. Brian From nobody Tue Dec 4 19:43:52 2018 Return-Path: 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 B617C130E93; Tue, 4 Dec 2018 19:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 2118H0setDXT; Tue, 4 Dec 2018 19:43:46 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D6A130DE3; Tue, 4 Dec 2018 19:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JV2xnSsNabkEBKz2ZhCTrv4HEuyR7ow0tbDod0PMbcQ=; b=ijCzkrkHQc6OzstJK1Pq7ghnS UC4fvy9Za8FRlho++qwNifYZ3YdTlxdFyXwV+TNTW94rfZZvfO2Xf3zBsREeFg2KHeYtQcX/gnk7/ MGkJbQbOG4FevCQYSnBqf309bdMNXj/0JhiDKh83fSXmEY73dcimO+ZT0ILzQBzZ7iOYg786C8ybi 1cJqOoG/QSHtHQu1ZEsIpdOaBOytOtcTl6NkQfT+7M+tQIEqe7KckZD/fFA4tZ/t0OZ4sIBnkdEF+ EAx/huag4e71mC8CVA5xCGZ1JVine4SQ6va/+qEvpGlTxAsdo14Gwp/iTY/ZtjkKUGARSbywcpWsF fAz3Kp82A==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53411 helo=[192.168.1.179]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUO6C-003cyy-DK; Tue, 04 Dec 2018 22:43:44 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: <0406e896-44eb-7dc9-def5-26b9ecbf444f@gmail.com> Date: Tue, 4 Dec 2018 19:43:43 -0800 Cc: Christopher Morrow , heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9EBAEED9-44DF-44E9-BD7B-8202B8AC8F39@strayalpha.com> References: <6738EDA7-FDE9-4683-8C0C-FB8C33F7B185@strayalpha.com> <0406e896-44eb-7dc9-def5-26b9ecbf444f@gmail.com> To: Brian E Carpenter X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 03:43:48 -0000 > On Dec 4, 2018, at 7:00 PM, Brian E Carpenter wrote: >=20 >> On 2018-12-05 14:18, Joe Touch wrote: >>=20 >>=20 >>> On Dec 4, 2018, at 4:56 PM, Brian E Carpenter wrote: >>>=20 >>> Yes. But extension headers were explicitly defined to be from end system= >>> to end system, not for middleboxes. So that difficulty was designed in. >>=20 >> Not HBH ones... >=20 > Indeed, which is why RFC 7045 changed the requirement. >=20 > Brian Except it didn=E2=80=99t. The bits are still there in 8200 and 7045 never de= precated their meaning. =20 Joe= From nobody Tue Dec 4 19:48:21 2018 Return-Path: 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 82767130DE3; Tue, 4 Dec 2018 19:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 52mx6lsmL3rP; Tue, 4 Dec 2018 19:48:11 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424C3130DD2; Tue, 4 Dec 2018 19:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eaoODdJ61o8UUMu8uDNC+DY9asoUoyn8myvtQiDzj64=; b=5xaNMj+5VdfXretO5QCzzlr+4 cnAb8+6+5mz1JLkq2JwDyee7gS5YPDcsr/GYtdfvXZAF9R6RdrDzsA2puHzEwENbgJvwIv0sNgv6l IhH8msUMj32rfPeBLEZ52HWfTNaKi83uMT5sxI8fPdzJcT3ZfOuAPmRFpLQOUnvwhRamOMFu2KikQ 3eEbitK5ALO6swV+OyS1Jqx8hvta1vieq9WNPcrb7demYlIo8oM39YAI+9qvRWGFZW8MOSTbmBspB x3bVsQ2vM9OFH/l3hjwDGjRY2j6Y8HEfIM/7ICAtNB4qnISvus2Vc/PFi3IY6Li76GdCTEsAgZO7q KeJ4PhPjw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53416 helo=[192.168.1.179]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUOAU-003gIg-7E; Tue, 04 Dec 2018 22:48:10 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: <42f482b8-ef85-909b-861f-c95a6a9efde1@gmail.com> Date: Tue, 4 Dec 2018 19:48:09 -0800 Cc: "C. M. Heard" , IETF , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , TSV-ART Content-Transfer-Encoding: quoted-printable Message-Id: <6D2BADF7-E3FB-4A71-A06C-7A0FB23D1515@strayalpha.com> References: <42f482b8-ef85-909b-861f-c95a6a9efde1@gmail.com> To: Brian E Carpenter X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 03:48:13 -0000 On Dec 4, 2018, at 6:59 PM, Brian E Carpenter w= rote: >>> NOTE: While [RFC2460] required that all nodes must examine and >>> process the Hop-by-Hop Options header, it is now expected that nodes >>> along a packet's delivery path only examine and process the >>> Hop-by-Hop Options header if explicitly configured to do so. >>=20 >> That is an expectation of the inadequacy of others. It does not clearly d= rop the requirement. >=20 > If so, that was a drafting error. RFC 7045 already formally changed > it to a SHOULD. >=20 > And IMHO it's entirely correct. It makes the notion of option flag bits irrelevant but never removed them.=20= The trouble is that the flags were there to prevent silently ignoring explic= it direction to each router. If that isn=E2=80=99t what HBH options are, the= n what are they? If they were disabled as you say, they should have been completely removed f= rom 8200. But they were - and are - not.=20 Joe= From nobody Tue Dec 4 19:58:06 2018 Return-Path: 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 22B8C130DD2; Tue, 4 Dec 2018 19:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 9OT900Z8wTNl; Tue, 4 Dec 2018 19:57:56 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 770C5130DCC; Tue, 4 Dec 2018 19:57:56 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id c9so18165829itj.1; Tue, 04 Dec 2018 19:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ReYToVRUQtEbbHOEub9Tv7rGregMvQA635yuC+iiV2g=; b=qnJGdLEMNBeghQpDS6cbwpEIk1kJQXeKHPlpO9c8347B9Mn8+dogazbWHXrJEYSZ1K HCjzTIWrgAu82Wee5JJtr3MS+8OGB1rAdGmvVb9BDoKj9Hwy4cLI8o5sGcYWTscDd0/V 9oXcpAr+ttWbhvyfPN5i73brh8P18z0ZUwZ+wXpo17ZxH+ZCILVWOHd5uQEpLGFdZECH JOGgknx5RQyY2JHp+qraWHCm8lnzJ7tHKRqlMtG3GBie91Qn9K52WyKWV4cVwO8vCZzG YdCrV0FjxIYNEEiNHasa/+cpDMfl2K4VNUJ472mpJyV9g/d3h+SCVtd5Qw50f54jFHoT J7tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ReYToVRUQtEbbHOEub9Tv7rGregMvQA635yuC+iiV2g=; b=kBmrV2sm4itycvC8Ta3mlFyw30UueCdHnxl4Qn/G+D2ygO8yRIBAuONSpoxkhU3HlY 0g58R9FQdE+lnM9mNG5FRn56bdS+wos1dO1UiMHQO9knxyTzHM/WyW6P1WdR20iwmc0q r0OWxsaDExbNYmfw2bCD+kNMSYnvQGmKEsaYsNj65zw0AxvMJ1Fc57ij1TtWoOrjJRUk Fd2rPKmnrPTfXychBp8ZQ/RV7U5iTaN9W+e8cnUgkTOsQ4GxZgvzQkOAsklkYD5JJA38 bzNzKrjOVmTaIrjrxTLsBFjJSPZRoH2Fj97XyxA6iMblGnKPFseQ1tQQsxx7EhVeBpYk Sc8A== X-Gm-Message-State: AA+aEWZ3O4UpDWcWB3RxNRr+X/ewmDJ4Th7VmGRUGAuUlq0BPvJlqACl vVx1fQw/ywLLUj7e3zDzxcPXdTyJ5DGHcTST7H8= X-Google-Smtp-Source: AFSGD/U42R0SpZSixetMGJd4o5zym0L4vUW7i3KWlSF2ZRjrZ12HpnkQ6pH9uuRljHuHVXsRB76+uHLV226bOyMQCPU= X-Received: by 2002:a24:32c5:: with SMTP id j188mr13695385ita.139.1543982275487; Tue, 04 Dec 2018 19:57:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Tue, 4 Dec 2018 22:57:43 -0500 Message-ID: To: Brian E Carpenter Cc: heard@pobox.com, ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org Content-Type: multipart/alternative; boundary="00000000000011f1ad057c3e635c" Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 03:57:59 -0000 --00000000000011f1ad057c3e635c Content-Type: text/plain; charset="UTF-8" On Tue, Dec 4, 2018 at 7:56 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 2018-12-05 12:23, Christopher Morrow wrote: > > On Tue, Dec 4, 2018 at 5:56 PM C. M. Heard wrote: > > > >> On Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote: > >>> A solution might be to have a mode where a router may just ignore all > >>> headers except the src/dst-ip and simply forward all packets, trusting > >>> that the conversing adults will sort out problems with unknown/new/ > >>> experimental headers or with a tortured ordering of headers (for > >>> instance). > >> > >> Glad to hear you say that, because that's exactly what RFC 7045 > >> envisions as the default forwarding behavior: > >> > >> > > I'm glad I'm not too nuts :) > > > > > >> Any forwarding node along an IPv6 packet's path, which forwards the > >> packet for any reason, SHOULD do so regardless of any extension > >> headers that are present [...] > >> > >> > > this does mean that: "please filter the flarbly protocol traffic, > eh-1234" > > is going to be very hard to do in the network. > > Yes. But extension headers were explicitly defined to be from end system > to end system, not for middleboxes. So that difficulty was designed in. > > sure, that's all well an good, but when 1mpps of eh-1234 show up on your door... uhm, you're going to want "relief" :) speaking from experience ... you really will want your ISP/carier/transit/peer to help you NOT get lit on fire. Them saying: "Well I COULD do that... but ... no, sorry I'm just the bit carrier, have fun!" is going to go 'not well' (again, having had this conversation, though not about ipv6 extension headers). > >> Recognizing that processing of Hop-by-Hop Options in the fast path is > >> costly, RFC 8200 formally dropped the requirement for every router to > >> process them by default: > >> > >> NOTE: While [RFC2460] required that all nodes must examine and > >> process the Hop-by-Hop Options header, it is now expected that nodes > >> along a packet's delivery path only examine and process the > >> Hop-by-Hop Options header if explicitly configured to do so. > >> > >> > > it's important to note that some platforms can't look beyond a certain > > number of headers, and that ordering of the headers us up to the src, > which > > when they are being mean is ... bad :( Even platforms that can look more > > than a few headers deep pay for that with clock cycles, so 100g -> 400g > -> > > 1tbps interfaces are less and less likely to see further into the > packet(s). > > Yes. The IPv6 header was designed so that all the information needed for > *forwarding* was at the front. The extension headers were designed on > the assumption that they would be analysed by a CPU, not by an ASIC > or FPGA, so that the linked-list model seemed fine. > > I think people believed that endpoints would take over DPI > filtering: https://www.cs.columbia.edu/~smb/papers/distfw.pdf > > HA! ok. As gert/nick noted ... we have Nx100G links today (at the edge) and coming nx400G ... there's just not a reasonable story for "dpi" there. (I suppose: "yet" and "without paying the approximate value Coca-Cola Companies yearly advertising budget") -chris > Brian > > >> What some of us would like to see is a statement in the draft that it's > >> just fine to operate this way (Christian Huitema made that suggestion > >> earlier in this thread, and so did I in my detailed last-call comments). > >> > >> > > oh, good. I like that idea... noting that: "makes filtering bad traffic > > pretty impossible" though. > > > > > >> Mike Heard > >> > > > --00000000000011f1ad057c3e635c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Dec 4, 2018 at 7:56 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 2018-12-05 12:23, Christopher Morrow wrote: > On Tue, Dec 4, 2018 at 5:56 PM C. M. Heard <heard@pobox.com> wrote:
>
>> On Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote:
>>> A solution might be to have a mode where=C2=A0 a router may ju= st ignore all
>>> headers except the src/dst-ip and simply forward all packets, = trusting
>>> that the conversing adults will sort out problems with unknown= /new/
>>> experimental headers or with a tortured ordering of headers (f= or
>>> instance).
>>
>> Glad to hear you say that, because that's exactly what RFC 704= 5
>> envisions as the default forwarding behavior:
>>
>>
> I'm glad I'm not too nuts :)
>
>
>>=C2=A0 =C2=A0 Any forwarding node along an IPv6 packet's path, = which forwards the
>>=C2=A0 =C2=A0 packet for any reason, SHOULD do so regardless of any= extension
>>=C2=A0 =C2=A0 headers that are present [...]
>>
>>
> this does mean that: "please filter the flarbly protocol traffic,= eh-1234"
> is going to be very hard to do in the network.

Yes. But extension headers were explicitly defined to be from end system to end system, not for middleboxes. So that difficulty was designed in.


sure, that's all well an good, but= when 1mpps of eh-1234 show up on your door... uhm, you're going to wan= t "relief" :)
speaking from experience ... you really w= ill want your ISP/carier/transit/peer to help you NOT get lit on fire.
Them saying: "Well I COULD do that... but ... no, sorry I'm = just the bit carrier, have fun!"
is going to go 'not wel= l' (again, having had this conversation, though not about ipv6 extensio= n headers).
=C2=A0
>> Recognizing that processing of Hop-by-Hop Options in the fast path= is
>> costly, RFC 8200 formally dropped the requirement for every router= to
>> process them by default:
>>
>>=C2=A0 =C2=A0 NOTE: While [RFC2460] required that all nodes must ex= amine and
>>=C2=A0 =C2=A0 process the Hop-by-Hop Options header, it is now expe= cted that nodes
>>=C2=A0 =C2=A0 along a packet's delivery path only examine and p= rocess the
>>=C2=A0 =C2=A0 Hop-by-Hop Options header if explicitly configured to= do so.
>>
>>
> it's important to note that some platforms can't look beyond a= certain
> number of headers, and that ordering of the headers us up to the src, = which
> when they are being mean is ... bad :( Even platforms that can look mo= re
> than a few headers deep pay for that with clock cycles, so 100g -> = 400g ->
> 1tbps interfaces are less and less likely to see further into the pack= et(s).

Yes. The IPv6 header was designed so that all the information needed for *forwarding* was at the front. The extension headers were designed on
the assumption that they would be analysed by a CPU, not by an ASIC
or FPGA, so that the linked-list model seemed fine.

I think people believed that endpoints would take over DPI
filtering: https://www.cs.columbia.edu/~smb/papers= /distfw.pdf


HA! ok. As gert/nick noted ... we have= Nx100G links today (at the edge) and coming nx400G ... there's just no= t a reasonable story for "dpi" there. (I suppose: "yet"= and "without paying the approximate value Coca-Cola Companies yearly = advertising budget")

-chris
=C2=A0<= /div>
=C2=A0 =C2=A0 Brian

>> What some of us would like to see is a statement in the draft that= it's
>> just fine to operate this way (Christian Huitema made that suggest= ion
>> earlier in this thread, and so did I in my detailed last-call comm= ents).
>>
>>
> oh, good. I like that idea... noting that: "makes filtering bad t= raffic
> pretty impossible" though.
>
>
>> Mike Heard
>>
>
--00000000000011f1ad057c3e635c-- From nobody Tue Dec 4 20:12:19 2018 Return-Path: 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 EBBD6130DCC; Tue, 4 Dec 2018 20:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 OLPySL3IBrX1; Tue, 4 Dec 2018 20:12:07 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 E67F9130DDF; Tue, 4 Dec 2018 20:12:06 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id x19so19234519itl.1; Tue, 04 Dec 2018 20:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qaNs/5aEsKulmQ0YYv9B7lu00O4Ym5uR4LOlquJb81A=; b=kKkUpQKZQxlRAdzd5seP0KEtHvYXY0hvSamAnUQ/vOtbksXy1Vy5mARbvnwWWFGJAk pHuTJl/fF0d90F3ap2apqtEi/cFShYp/YORT4nLWi/7T+iZy58UJLrfo1DUVWwTDBjFN fVUaEgcla/9kZ5z0MxYpgKtvCxViFoqdmmfU/8OlaSoKoururZYNgHc7FiY2jDIdFNlk vkiD5WTugpsOJy8H41FIjujMFOakuD0NOjtkmIAfW/Q4aSlgf47BhOc+TCjaB6k0VmWM m3IVT++LpzaJ6bydfQVZrH8C4nns5ecNz/exlYuBZyX4N2g6RxXyK0A4YUV2NPeeHNFF ESAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qaNs/5aEsKulmQ0YYv9B7lu00O4Ym5uR4LOlquJb81A=; b=LVMWn9Gd3dGw675FXRHMMreJrH75hWFFQcDwUNL8UuFAroRBNtnx+u5Vab2yBssTlA mZm0SMbNcqtlsPP505bIR8I6USAtbrFRwrRn0ycJ/P8k8+KxMYsKzXUitigESGaxvdtv Jw03FsERVEMsfxetu63o05mdWpsRpOyRfIXgvr57hQ1sa45EyuoLD6iEtUNLC3YM6LCi cMPin4D3AQNsORcJSJsE6vFI5KYXP+q8qBrpZJ2W4IpfoxdD/SQ5Xf4Ij7FIRXJoKvHC tbmIgLtYqW48JRTjnR4a+ukwELUwVYREQnhjiBPzxZmvsnDXvkZpTZkxWhxZBFlSkIUB yW6A== X-Gm-Message-State: AA+aEWY4TF71/rE8wFbbqDOAzrCFuYEh65P/m9NAp75gcVcZQ41IHr8T 8r54nccSaMo8K47OIthUsuEXKPNcs1T35YSISHg= X-Google-Smtp-Source: AFSGD/XTkWt0m+zcdVvoK3QWPnT/jkg/O8XeGYRddia/A3d0ivwbxl0+XCoOyCb+kUEoxYXKCrhJxdudiDGk5OW+I7I= X-Received: by 2002:a24:32c5:: with SMTP id j188mr13719479ita.139.1543983125987; Tue, 04 Dec 2018 20:12:05 -0800 (PST) MIME-Version: 1.0 References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> In-Reply-To: From: Christopher Morrow Date: Tue, 4 Dec 2018 23:11:54 -0500 Message-ID: To: Joe Touch Cc: Stewart Bryant , tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard Content-Type: multipart/alternative; boundary="000000000000c38669057c3e95d5" Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 04:12:11 -0000 --000000000000c38669057c3e95d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 4, 2018 at 8:10 PM Joe Touch wrote: > > > On Dec 4, 2018, at 12:17 PM, Christopher Morrow > wrote: > > > > > > On Tue, Nov 27, 2018 at 5:40 AM Joe Touch wrote: > >> Take that to the standards wg. Don=E2=80=99t stick your head in the sand= and try >> to do an end run in ops. And don=E2=80=99t call any of this a security i= ssue that >> it isn=E2=80=99t. >> >> >> > Joe, I think one of the 3 pillars of security is: "Availability" (the > other two are 'Confidentiality' and 'Integrity=E2=80=99) > > > It is... > > > I think the point that Nick and Gert are outlining is that if the case is > that the hardware available will have no fast-path processing for packets > with obtuse patterns or sets of extension headers those packets will get > sent to the control-plane (slow-path). That slow-path being congested wil= l > cause availability problems. > > > If that happens, the packets with these headers can easily be throttled - > thus avoiding a security issue. > > So, perhaps I'm not expressing my point properly... I'll try again in a different way. I don't think that they can be meaningfully throttled, no. I think that they will 'always' be throttled if they can not go on the fast-path, because the difference between 'fast-path' and 'not fast-path' is ~9 orders of magnitude. There's not a sane "welp, 50% of bandwidth" or anything like that possible in this scenario. Except: "meh, just pass along all packets unchecked, no HBH checking/evaluation nothing". > However, what you=E2=80=99re basically saying is that =E2=80=9Cit is a se= curity risk to > send packets to a router because it might have to do work=E2=80=9D. > I don't think that's what I said, what i said is that loss of control-plane functionality is a security risk, because you lose availability. Yes, that's not a 'big surprise', it's just a fact of life on the public network, to operate a network connected to the public you don't let things poke at your control-plane. > Yeah, big surprise. Either do the work or limit the impact. But that=E2= =80=99s not > the kind of security risk we associate with availability - a good example > of which would be that sending a single packet would cause the work of 10= 00. > > 'you' (the royal, not you in particular) may not consider loss of availability to be a security concern, but I expect all network operations folk to consider it such. I expect that, by and large, folk who operate networks aren't trying to make 'your' (royal again) life hard here, 'we' (royal) are just saying: "there's a tradeoff, let's be sure we agree what the costs are going to be" But none of that is happening here. > > > Actually, whether or not the control-plane fails under such load may not > even matter, if the rate-limiting of the packets here is such that (as ge= rt > said) all but a trickle of the interesting packets are forwarded. > > > But then that=E2=80=99s not a security problem. > > it's a loss of availability for the users of the expected packets. It's not really "my" concern, unless I'm trying to do some new protocol thingy. > > A solution might be to have a mode where a router may just ignore all > headers except the src/dst-ip and simply forward all packets, trusting th= at > the conversing adults will sort out problems with unknown/new/experimenta= l > headers or with a tortured ordering of headers (for instance). This will > also cause some operational headaches: "Please drop all traffic toward ip= X > with protoY and dst-port Z" but perhaps it's still acceptable to some fol= k > to operate like this? > > > That works only for HBH options of type 00. Others require particular > actions when not supported. > > can you expand on this some? > Joe > --000000000000c38669057c3e95d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Dec 4, 2018 at 8:10 PM Joe Touch <touch@strayalpha.com> wrote:


On Dec 4, 2018, at 12:17 PM, Christopher Morrow <morrowc.lists@gmail.c= om> wrote:





On Tue, Nov 27, 2018 at 5:40 AM Joe = Touch <touch@s= trayalpha.com> wrote:
Take t= hat to the standards wg. Don=E2=80=99t stick your head in the sand and try = to do an end run in ops. And don=E2=80=99t call any of this a security issu= e that it isn=E2=80=99t.



Joe, I think one of the 3 pillars = of security is: "Availability" (the other two are 'Confidenti= ality' and 'Integrity=E2=80=99)

It i= s...

=C2=A0
I think the point that Nick and Gert ar= e outlining is that if the case is that the hardware available will have no= fast-path processing for packets with obtuse patterns or sets of extension= headers those packets will get sent to the control-plane (slow-path). That= slow-path being congested will cause availability problems.

If that happens, the packets with these headers can easily= be throttled - thus avoiding a security issue.


So, perhaps = I'm not expressing my point properly... I'll try again in a differe= nt way.
I don't think that they can be meaningfully throttled= , no. I think that they will 'always' be throttled if they can not = go on the fast-path, because the difference between 'fast-path' and= 'not fast-path' is ~9 orders of magnitude. There's not a sane = "welp, 50% of bandwidth" or anything like that possible in this s= cenario. Except: "meh, just pass along all packets unchecked, no HBH c= hecking/evaluation nothing".
=C2=A0
However, what you=E2=80=99re basically saying is t= hat =E2=80=9Cit is a security risk to send packets to a router because it m= ight have to do work=E2=80=9D.

I don't think that's what I said, what i said is that loss o= f control-plane functionality is a security risk, because you lose availabi= lity.
Yes, that's not a 'big surprise', it's just= a fact of life on the public network, to operate a network connected to th= e public you don't let things poke at your control-plane.
=C2= =A0
Yeah, big surprise. Either do the work or limit the impact. = But that=E2=80=99s not the kind of security risk we associate with availabi= lity - a good example of which would be that sending a single packet would = cause the work of 1000.

=

'you' (the royal, not you in= particular) may not consider loss of availability to be a security concern= , but I expect all network operations folk to consider it such.
I= expect that, by and large, folk who operate networks aren't trying to = make 'your' (royal again) life hard here, 'we' (royal) are = just saying: "there's a tradeoff, let's be sure we agree what = the costs are going to be"


But none of that is happening here.
=

Actually, whether or not the control-plane fails un= der such load may not even matter, if the rate-limiting of the packets here= is such that (as gert said) all but a trickle of the interesting packets a= re forwarded.

But then that=E2=80=99s not a = security problem.


it&= #39;s a loss of availability for the users of the expected packets. It'= s not really "my" concern, unless I'm trying to do some new p= rotocol thingy.
=C2=A0

A solution might be to have a mode where= =C2=A0 a router may just ignore all headers except the src/dst-ip and simpl= y forward all packets, trusting that the conversing adults will sort out pr= oblems with unknown/new/experimental headers or with a tortured ordering of= headers (for instance). This will also cause some operational headaches: &= quot;Please drop all traffic toward ipX with protoY and dst-port Z" bu= t perhaps it's still acceptable to some folk to operate like this?

Tha= t works only for HBH options of type 00. Others require particular actions = when not supported.


can you expand on this some?
=C2=A0<= /div>
Joe
--000000000000c38669057c3e95d5-- From nobody Tue Dec 4 20:32:24 2018 Return-Path: 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 51377130DE4; Tue, 4 Dec 2018 20:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=strayalpha.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 dhQX126B9llS; Tue, 4 Dec 2018 20:32:13 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D05A130DDF; Tue, 4 Dec 2018 20:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0L1PKXg4dC1F3SLvo7prNY7y7DPpZx/0q0e2KXh1Bvo=; b=I/vv917iPPrVqvuPAHaA8SRfJ 8BYFqHD7fnX5VEcciLjft/NveIQPe7IRtS10ApUT7moH4UDG6MUiGuYlxUGzV5RYKGF5M3Fen5EvB jRXiV/lqBhTnv4FYLYS2qY2xmF/T0vmSSlVTBbCUJ9hAxh737HQX/uzzN2vX2savDSf+JXkXkwfSb Nhxh/7dscnt8DOAaJW8e8bg9tbyOkvgvR+DI/OfU3S4fyNnNXnZ2cYZWu0Tr5dGICnb1LRNd7MGSw IcgbBpFs+qpcX7mvPUMM9IN3j+MVoeYAML5DpGyuHOlssURNj5oy1syy0FP2G0eKuPCr+ZN1HPA84 upXhWnSWQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53450 helo=[192.168.1.179]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUOr5-004KMA-VX; Tue, 04 Dec 2018 23:32:12 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-A59A3538-E846-4F77-8E15-E0EA5487DE02 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Tue, 4 Dec 2018 20:32:11 -0800 Cc: ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard , opsec wg mailing list , tsv-art@ietf.org, Stewart Bryant Content-Transfer-Encoding: 7bit Message-Id: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> To: Christopher Morrow X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 04:32:15 -0000 --Apple-Mail-A59A3538-E846-4F77-8E15-E0EA5487DE02 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Dec 4, 2018, at 8:11 PM, Christopher Morrow wro= te: >> That works only for HBH options of type 00. Others require particular act= ions when not supported. >>=20 >=20 > can you expand on this some? Nobody deprecated the flags that require HBH options to be processed or drop= ped if not supported.=20 And if there is a security risk to the control plane, it is using that place= for slow path processing without properly limiting its use of shared resour= ces.=20 This idea that packets processed as intended are a security risk is like say= ing big packets are a security risk to small packets. It may be a bad design= but it doesn=E2=80=99t mean such packets are inherently a security risk.=20= Joe= --Apple-Mail-A59A3538-E846-4F77-8E15-E0EA5487DE02 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Dec 4, 2018, at 8:11 PM, Christopher Morrow &= lt;morrowc.lists@gmail.com>= ; wrote:

That works only for HBH options of typ= e 00. Others require particular actions when not supported.


can you ex= pand on this some?

Nobody deprecated the fl= ags that require HBH options to be processed or dropped if not supported.&nb= sp;

And if there is a security risk to the control p= lane, it is using that place for slow path processing without properly limit= ing its use of shared resources. 

This idea th= at packets processed as intended are a security risk is like saying big pack= ets are a security risk to small packets. It may be a bad design but it does= n=E2=80=99t mean such packets are inherently a security risk. 

Joe
= --Apple-Mail-A59A3538-E846-4F77-8E15-E0EA5487DE02-- From nobody Tue Dec 4 20:46:24 2018 Return-Path: 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 255DE130DC9; Tue, 4 Dec 2018 20:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 hkbtqecqCErD; Tue, 4 Dec 2018 20:46:21 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 19762126F72; Tue, 4 Dec 2018 20:46:20 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id p8so9449503plo.2; Tue, 04 Dec 2018 20:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kxRx9+sUKk7A/HVVrCF4oQvD6HfHQdZK1zsWXdIlZ7w=; b=TVQ5KHjG91MZuR5h+qSEGZmxMSGDubm+IaUtHptr7uOqB+J/IXgZNVbEErcvA2Kuxk G1lAgs3OIiFp5fHa+dCjnELKZoQ70xMBYeo+h85spHnMFD2umXEXGXABMa5wIW4aZiGk e+n1Xag91ttmCdWf4NtXNgpxeXnkYYpU8uLVqI7jcA08tYcONn5Ab/Vy5xafnlrXEFu1 Hh+JbLp7N/mO+GQrdcNCMT1/CyXAHeU3KtsL85KZ6fsOTr+wBBxXuc65r5ZpcMeaM89+ bvXuZ9RNbAo1ztMgL5HscAnjfj6OK7Kzufg0tWb4OOB2SW+OHIlyJXxxSH4NSEI2RVyZ gc7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kxRx9+sUKk7A/HVVrCF4oQvD6HfHQdZK1zsWXdIlZ7w=; b=PJf0omEcg8Buoqiw1wGQrlMwEo5DYFIZWCHkgbwPjKA1z0ndw2eDJe55GXeJssr1ls qL4JKf6dZthxGy6XLRFuthcDgvt3BnkkJijMHtpjb9jQdVy+pinWMX2ByTbk+dircL5N 0RcrlozWAwKvBeA2ukD4spZ3H7wB0ajcON6nRrwl9Cnjnbo/UHrsihL4Pv6UsmoDOnrm QiTuf3gOKaYD3PGnnQm/LPa8uRPQkgaMiLZlNM40FKLnmK+R2e+lnhGQE2KPI4y8d0ES A+3cAr3aEnL08krnJ0VW4dPEX/xOCjXfQmELgx3+lO+fGXI/neZ0rA0MZ7ZNHv0NNa78 9XJg== X-Gm-Message-State: AA+aEWbpJ4SrE5M8WLp6B2bGHc8WvvDgbAyyjPl0Xu1FcNdCK3Wuo+42 1LzLRFhnvNNeV0CzPAIGF9MMFCAgm4A= X-Google-Smtp-Source: AFSGD/XEh3+iueutiz2q5lh8US0BXJ2u2FHT9cPXMKM6En9rLIi/C9QBDa/wkyVpS0ILLFOSoMu2SA== X-Received: by 2002:a17:902:9a9:: with SMTP id 38mr22387570pln.204.1543985180320; Tue, 04 Dec 2018 20:46:20 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id f20sm11098820pfn.177.2018.12.04.20.46.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 20:46:19 -0800 (PST) To: Joe Touch , Christopher Morrow Cc: ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> From: Brian E Carpenter Message-ID: <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> Date: Wed, 5 Dec 2018 17:46:14 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 04:46:22 -0000 On 2018-12-05 17:32, Joe Touch wrote: >=20 >=20 > On Dec 4, 2018, at 8:11 PM, Christopher Morrow > wrote: >=20 >> That works only for HBH options of type 00. Others require particu= lar actions when not supported. >> >> >> can you expand on this some? >=20 > Nobody deprecated the flags that require HBH options to be processed or= dropped if not supported.=20 Intentionally. If a forwarding node is transparent to HbH options, it is not looking at those flags. If it is looking at HbH options, it will obey those flags. Why is that a problem? Brian >=20 > And if there is a security risk to the control plane, it is using that = place for slow path processing without properly limiting its use of share= d resources.=C2=A0 >=20 > This idea that packets processed as intended are a security risk is lik= e saying big packets are a security risk to small packets. It may be a ba= d design but it doesn=E2=80=99t mean such packets are inherently a securi= ty risk.=C2=A0 >=20 > Joe From nobody Tue Dec 4 21:37:51 2018 Return-Path: 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 1C604128CFD; Tue, 4 Dec 2018 21:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 hpkegXVoYI9p; Tue, 4 Dec 2018 21:37:40 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 23E2712D4E9; Tue, 4 Dec 2018 21:37:40 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id f10so9882198iop.10; Tue, 04 Dec 2018 21:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sf3lJ62CgSlnmj1arx3aSb5oxC0OeSc2hvZmErwsaJk=; b=NcNnEpjXGxYGGHLu4ufNfTV/iZkPW1gOfI1wOLYT+slY+wbYChuc6/+a1LYN0KdGXV 0+0MAJIqW6+JKsoeUG48IStc1NBl2O66XwnCUmLCzdfeC4UyOqTdVTzmsdWSTGaSGPKb 4ldD60cBJy8e0HS/aGMEQTK9cToT1cvj74BXz+wgISo3DbnlkFInMCxIEuokMZGyO6/T k0OK78Rdld7C74BlcVmHfJbXIyeQFY5hSmaQkdqZDTJnj8/9PTs7CVpfoL/7LGuwdsQE J4BV2fgwk2mJIdg9ecaNbBeSbSDemnUogNcNFqagy+JY5yy3yXNOp8ymNQGOHn5eAu0C 2xKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sf3lJ62CgSlnmj1arx3aSb5oxC0OeSc2hvZmErwsaJk=; b=jrSjAnjfYH2BHsHBYR8APcj+OaXTj9+hzufzOd8atvGibGlphuzQu3jvQ9tJhapxwz kD28+ni4Me8bpS3DkmRIew+JAGPPie090vMbqXFOlgDauiJqLcvJ4snoj3rypj880zr/ i+vFyPgTqw/BXRVBCWxi6CacPzYH5H4UkKIZeQBdralPm1e7nEc9jf0TKwjxJDNW4N9h OoAwmzzdFGt6oDzlMv2npRhEyztSZ78RdRhP9LvNyoOLGrxlJRE7rEzckqBN3yGk+svs h6YKVAfc7MBvkDOpYodEJy9W0by7xnT4JzdTfEu0kEN7OAh5ZtH/qwVZlgXjWqytHuoS SjoQ== X-Gm-Message-State: AA+aEWZddpupavrkccNnFDaExfTbv6Gxdpp63QgKpuKGYcGRNACbAOxy SaZ494Fw2PiadJ5qfW2AWCEdz68cXTQTsAFmsls= X-Google-Smtp-Source: AFSGD/X8+Whpag6Soo0fKTG6rBHq/5FYPdnuCaq2EZCrx4UKwRYed26hrODhOPH3S+WhfB+yfsbl9tYzjR10STZ3p7k= X-Received: by 2002:a5d:844d:: with SMTP id w13mr11300319ior.17.1543988259144; Tue, 04 Dec 2018 21:37:39 -0800 (PST) MIME-Version: 1.0 References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> In-Reply-To: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> From: Christopher Morrow Date: Wed, 5 Dec 2018 00:37:25 -0500 Message-ID: To: Joe Touch Cc: ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard , opsec wg mailing list , tsv-art@ietf.org, Stewart Bryant Content-Type: multipart/alternative; boundary="000000000000b94bd7057c3fc794" Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 05:37:42 -0000 --000000000000b94bd7057c3fc794 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 4, 2018 at 11:32 PM Joe Touch wrote: > > > On Dec 4, 2018, at 8:11 PM, Christopher Morrow > wrote: > > That works only for HBH options of type 00. Others require particular >> actions when not supported. >> >> > can you expand on this some? > > > Nobody deprecated the flags that require HBH options to be processed or > dropped if not supported. > > Oh, you are highlighting the difference between the 'theory' and 'practice'. ok. > And if there is a security risk to the control plane, it is using that > place for slow path processing without properly limiting its use of share= d > resources. > > sure, that's a fine point. Doesn't actually change the state of the world where: "If your control-plane collapses, you have an unavailability event" which is a security problem. It's also an operational problem and likely a cost problem :( but... maintaining availability is part of what a good isp security group will do for the isp. > This idea that packets processed as intended are a security risk is like > saying big packets are a security risk to small packets. It may be a bad > design but it doesn=E2=80=99t mean such packets are inherently a security= risk. > > it seems weird that in this case 'this is not a security problem', but sending a packet that breaks some assumptions in the applications at the end points and causes unexpected problems with the end point(s) (say sql injection in a web server or breaking some ssh server through some vulnerability) is a security problem? Instead of rat-holing on this point though, don't you actually care that the end points can do their work regardless of the network devices? (smart edges, dumb core ... that sort of thing) -chris --000000000000b94bd7057c3fc794 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Dec 4, 2018 at 11:32 PM Joe Touch <touch@strayalpha.com> wrote:

<= div dir=3D"ltr">
On Dec 4, 2018, at 8:11 PM, Christopher Morrow <morrowc.lists@gmai= l.com> wrote:

That works only for HB= H options of type 00. Others require particular actions when not supported.=


<= /div>
can you expand on this some?

Nob= ody deprecated the flags that require HBH options to be processed or droppe= d if not supported.=C2=A0


<= /div>
Oh, you are highlighting the difference between the 'theory&#= 39; and 'practice'. ok.
=C2=A0
And if there is a security = risk to the control plane, it is using that place for slow path processing = without properly limiting its use of shared resources.=C2=A0

=

sure, that's a fine point.= Doesn't actually change the state of the world where: "If your co= ntrol-plane collapses, you have an unavailability event" which is a se= curity problem. It's also an operational problem and likely a cost prob= lem :( but... maintaining availability is part of what a good isp security = group will do for the isp.
=C2=A0
This idea that packets processed as = intended are a security risk is like saying big packets are a security risk= to small packets. It may be a bad design but it doesn=E2=80=99t mean such = packets are inherently a security risk.=C2=A0


it seems weird that in this case 'this is= not a security problem', but sending a packet that breaks some assumpt= ions in the applications at the end points and causes unexpected problems w= ith the end point(s) (say sql injection in a web server or breaking some ss= h server through some vulnerability) is a security problem?

<= /div>
Instead of rat-holing on this point though, don't you actuall= y care that the end points can do their work regardless of the network devi= ces? (smart edges, dumb core ... that sort of thing)

-chris
--000000000000b94bd7057c3fc794-- From nobody Tue Dec 4 22:15:00 2018 Return-Path: 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 765CF128CB7; Tue, 4 Dec 2018 22:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 wJvBXiHmBSRC; Tue, 4 Dec 2018 22:14:49 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82440127333; Tue, 4 Dec 2018 22:14:49 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 4A88B3AB067; Wed, 5 Dec 2018 06:14:47 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 28C9B160046; Wed, 5 Dec 2018 06:14:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F386416007B; Wed, 5 Dec 2018 06:14:16 +0000 (UTC) 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 Emo_ZDZhJX09; Wed, 5 Dec 2018 06:14:16 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 8BFFA160046; Wed, 5 Dec 2018 06:14:15 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: Date: Wed, 5 Dec 2018 17:14:11 +1100 Cc: Joe Touch , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> To: Christopher Morrow X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 06:14:51 -0000 > On 5 Dec 2018, at 4:37 pm, Christopher Morrow = wrote: >=20 >=20 >=20 > On Tue, Dec 4, 2018 at 11:32 PM Joe Touch = wrote: >=20 >=20 > On Dec 4, 2018, at 8:11 PM, Christopher Morrow = wrote: >=20 >> That works only for HBH options of type 00. Others require particular = actions when not supported. >>=20 >>=20 >> can you expand on this some? >=20 > Nobody deprecated the flags that require HBH options to be processed = or dropped if not supported.=20 >=20 >=20 > Oh, you are highlighting the difference between the 'theory' and = 'practice'. ok. > =20 > And if there is a security risk to the control plane, it is using that = place for slow path processing without properly limiting its use of = shared resources.=20 >=20 >=20 > sure, that's a fine point. Doesn't actually change the state of the = world where: "If your control-plane collapses, you have an = unavailability event" which is a security problem. It's also an = operational problem and likely a cost problem :( but... maintaining = availability is part of what a good isp security group will do for the = isp. And the correct thing to do is to FIX THE BROKEN PRODUCT. =20 If a ssh implementation is broken we don=E2=80=99t drop SSH packets. We = fix the broken implementation of ssh. If there is a SQL injection problem we fix that problem rather than = dropping HTTP and HTTPS packets. If a router can=E2=80=99t handle all legal packets at line rate the = router needs to fixed. Punting stuff to be processed by the same CPU that process the routing = table worked for a while. There is no rule that says routers can=E2=80=99t have = multiple CPUs some of which are dedicated to handling the control plane and other that deal = with everything else that has been punted. Design the router so that the control plane = doesn=E2=80=99t get overloaded and the exceptional packet get handled. Generating PTB=E2=80=99s shouldn=E2=80=99t be seen as exceptional. = Fragmented packets shouldn=E2=80=99t be seen as exceptional.=20 > This idea that packets processed as intended are a security risk is = like saying big packets are a security risk to small packets. It may be = a bad design but it doesn=E2=80=99t mean such packets are inherently a = security risk.=20 >=20 >=20 > it seems weird that in this case 'this is not a security problem', but = sending a packet that breaks some assumptions in the applications at the = end points and causes unexpected problems with the end point(s) (say sql = injection in a web server or breaking some ssh server through some = vulnerability) is a security problem? > Instead of rat-holing on this point though, don't you actually care = that the end points can do their work regardless of the network devices? = (smart edges, dumb core ... that sort of thing) >=20 > -chris --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Dec 4 23:02:43 2018 Return-Path: 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 1E26512D4E9 for ; Tue, 4 Dec 2018 23:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 H83R_SN7DS9b for ; Tue, 4 Dec 2018 23:00:50 -0800 (PST) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E4E129533 for ; Tue, 4 Dec 2018 23:00:49 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 56603645 for ; Wed, 5 Dec 2018 07:00:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a0u0rz-WGNv for ; Wed, 5 Dec 2018 01:00:49 -0600 (CST) Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 0AF5C6CB for ; Wed, 5 Dec 2018 01:00:48 -0600 (CST) Received: by mail-ua1-f70.google.com with SMTP id j14so2079191uap.18 for ; Tue, 04 Dec 2018 23:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t80ePzyj96stD7HAWRlB5NtEYPDu+NICqNhJiTIHmOA=; b=mOXp4NO8I42hKLDxMZI2vondlGyK6JBYGT3VG9hypuvicCAazyBdYP75DfV9/OexkG LwUG8X8g1wgCPN833SQe/RJj9uWvxZep+5eV2rAR8Kdxqd+BnvMGl0U7ueFB1NEvPvDI qxv8DBKPZOdzrfOBDGMWeOSTlVpCzC4d8nFAf+rQkk7+C8k//MsGDVTqMc+STyxVnliC kjlFhOGk4AJwZZEEAUBviA1IMISeY1OqItdqcnkNhfnQXcZBeKXnBcv3aQPWAZM1qz/K OlBzt2nQ+V3mzasz3udkwmbKVMp0gnY5hVa4cqQ0nWTn7NPywZXQbTOmZ5FvVtJID169 fLTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t80ePzyj96stD7HAWRlB5NtEYPDu+NICqNhJiTIHmOA=; b=jpx5Gwp0Pw7qpjhB0abIR+sVby9N6+TlWeRojyshxrzJ1DUlCgza55yKK8l5A0s2VT vm0WTjI9LEuzKhT936EYJEjBhchVg0C0vd63OBuxgwN7htdltGnQKFvruK0rKfg1mROM uvQj2s0NQawbBeGOm3HYZZsUcDK/7QnWGxWat77gU3UFmXrujCdMiluJhY1xAakn4Qh4 BY7yICyy4QJ5AjThkJuvgbDEM1FRA6JPl8yAzckiVyP+wl4bcPU6MuOpkJzz7aMF6NZg FJ6AF0ChECnNpn78Pp3BJ5vzUMEKGrXhvvyizS2YF6lbvdEaCAIanhOL5zKYkWoVD6OI 9Tsg== X-Gm-Message-State: AA+aEWa61sMaiANtqPdC6gr5BPad+SnQdLKFu4F6nuuf1R4T5shrQmhW 2X/d0EeCbWDVCqWJwftlHqnYwM++L5NGeeNWZrPopizVBFT/5NRh+vrgSdpXaxWf/8ll2w4fQft rPYvztoH4ntT3Ps+gec/O8HYv0w== X-Received: by 2002:a67:c86:: with SMTP id 128mr10323669vsm.221.1543993247335; Tue, 04 Dec 2018 23:00:47 -0800 (PST) X-Google-Smtp-Source: AFSGD/VvKtMH84gSbbS7QSBeZN69qHR88/ykxjTMgfmOTew7pF01esP0vFc+FHa0SVuuBaXQd2wFZ2lKjKU+bVf8BRs= X-Received: by 2002:a67:c86:: with SMTP id 128mr10323659vsm.221.1543993246962; Tue, 04 Dec 2018 23:00:46 -0800 (PST) MIME-Version: 1.0 References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> In-Reply-To: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> From: David Farmer Date: Wed, 5 Dec 2018 01:00:30 -0600 Message-ID: To: Mark Andrews Cc: morrowc.lists@gmail.com, tsv-art@ietf.org, opsec@ietf.org, IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000000570c4057c40f105" Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 07:00:52 -0000 --0000000000000570c4057c40f105 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 5, 2018 at 12:15 AM Mark Andrews wrote: > > And the correct thing to do is to FIX THE BROKEN PRODUCT. > > If a ssh implementation is broken we don=E2=80=99t drop SSH packets. We = fix the > broken implementation of ssh. > > If there is a SQL injection problem we fix that problem rather than > dropping HTTP > and HTTPS packets. > > If a router can=E2=80=99t handle all legal packets at line rate the route= r needs > to fixed. > > Punting stuff to be processed by the same CPU that process the routing > table worked > for a while. There is no rule that says routers can=E2=80=99t have multi= ple CPUs > some of > which are dedicated to handling the control plane and other that deal wit= h > everything > else that has been punted. Design the router so that the control plane > doesn=E2=80=99t get > overloaded and the exceptional packet get handled. > > Generating PTB=E2=80=99s shouldn=E2=80=99t be seen as exceptional. Fragm= ented packets > shouldn=E2=80=99t be > seen as exceptional. > Even if agree that is the way routers SHOULD be designed today. I'm not aware of any that are designed that way. Further, even if all new router shipped from today on were designed that way, which they are not. It would easily take a decade or more for all the old legacy routers to fade away on the Internet. Those are facts we have to work with. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --0000000000000570c4057c40f105 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Dec 5, 2018 at 12:15 AM Mark Andrews <marka@isc.org> wrote:

And the correct thing to do is to FIX THE BROKEN PRODUCT.=C2=A0

If a ssh implementation is broken we don=E2=80=99t drop SSH packets.=C2=A0 = We fix the broken implementation of ssh.

If there is a SQL injection problem we fix that problem rather than droppin= g HTTP
and HTTPS packets.

If a router can=E2=80=99t handle all legal packets at line rate the router = needs to fixed.

Punting stuff to be processed by the same CPU that process the routing tabl= e worked
for a while.=C2=A0 There is no rule that says routers can=E2=80=99t have mu= ltiple CPUs some of
which are dedicated to handling the control plane and other that deal with = everything
else that has been punted.=C2=A0 Design the router so that the control plan= e doesn=E2=80=99t get
overloaded and the exceptional packet get handled.

Generating PTB=E2=80=99s shouldn=E2=80=99t be seen as exceptional.=C2=A0 Fr= agmented packets shouldn=E2=80=99t be
seen as exceptional.

Even if agre= e that is the way routers SHOULD be designed today. I'm not aware of an= y that are designed that way.=C2=A0

Further, even = if all new router shipped from today on were designed that way, which they = are not. It would easily take a decade or more for all the old legacy route= rs to fade away on the Internet. Those are facts we have to work with.=C2= =A0=C2=A0

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Da= vid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu<= br>Networking & Telecommunication Services
Office of Information Tec= hnology
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-30= 29=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--0000000000000570c4057c40f105-- From nobody Wed Dec 5 00:52:51 2018 Return-Path: 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 D727F130DE5 for ; Wed, 5 Dec 2018 00:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 XctkGD0_5hUm for ; Wed, 5 Dec 2018 00:52:31 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF9D130DFB for ; Wed, 5 Dec 2018 00:52:30 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5431C43813 for ; Wed, 5 Dec 2018 09:52:27 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 434FC41C0F; Wed, 5 Dec 2018 09:52:27 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 342C5A1FD; Wed, 5 Dec 2018 09:52:27 +0100 (CET) Date: Wed, 5 Dec 2018 09:52:27 +0100 From: Gert Doering To: Christopher Morrow Cc: Brian E Carpenter , heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-ID: <20181205085227.GG1543@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 08:52:43 -0000 Hi, On Tue, Dec 04, 2018 at 10:57:43PM -0500, Christopher Morrow wrote: > HA! ok. As gert/nick noted ... we have Nx100G links today (at the edge) and > coming nx400G ... there's just not a reasonable story for "dpi" there. (I > suppose: "yet" and "without paying the approximate value Coca-Cola > Companies yearly advertising budget") Indeed. Unfortunately, there *is* a story for being able to rate-limit incoming crap by protocol type - "give me no more than 200 Mbit/s of UDP packets coming from source port 53". Which implies that as soon as the evil guys out there find a way to generate DDoS streams carrying EHs that our border routers will (have to) apply very strict rate limiting to everything they do not understand. - pass TCP - rate-limit UDP on well-known reflective attacks port - pass rest of UDP - rate-limit ICMP - rate-limit fragments - rate-limit all the rest to something which can never exceed a customer's access-link game over, EH (We're not doing this today, because as of today, "volume DDoS" comes in without EHs [except fragment] - but this is just a matter of time) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Dec 5 04:14:00 2018 Return-Path: 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 5FB86130DF4; Wed, 5 Dec 2018 04:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=strayalpha.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 SxtWW76-ryrG; Wed, 5 Dec 2018 04:13:50 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6706C130DEB; Wed, 5 Dec 2018 04:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9rH7ybk3gKm+3xUHKoQPv0WssDjS8v64XI55kyO+ggE=; b=sBVL77LLgNnQw69+vetysiSab num6b3HiRRW5gVK7bj6glgOgMN8APD79QbFOFHQvsJj96YQ2UzQJHC9oHOJFJiCrb0pz/AXhQIkav oiUikNlZNwZ1N0eqhGrESS6VgSn/FZ0evm8Xz7GpK2zitPggFl10SsS+Mu0B5ENUCwR595DQRt4vq 4eAVXh2TtzNJfMK9dJz0O291EhOuwUJdvVFkRRDyUNDHGbQN0Pp3oji3PwnatSWYVc+TOFfpMsiVd h7lTndDahQcddgPOLKPFXb7xY9puckJQaFVpOXvnESfhMfA0G/UG1FbrrKya6/mUoxA4mtVVNGAMs CWCIgXOHg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57083 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUW3o-002cht-39; Wed, 05 Dec 2018 07:13:48 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-76F8A01F-7B43-4471-9E05-D1A245A08470 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: Date: Wed, 5 Dec 2018 04:13:47 -0800 Cc: Mark Andrews , tsv-art@ietf.org, opsec@ietf.org, morrowc.lists@gmail.com, IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> To: David Farmer X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 12:13:52 -0000 --Apple-Mail-76F8A01F-7B43-4471-9E05-D1A245A08470 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Dec 4, 2018, at 11:00 PM, David Farmer wrote: >> Punting stuff to be processed by the same CPU that process the routing ta= ble worked >> for a while. There is no rule that says routers can=E2=80=99t have multi= ple CPUs some of >> which are dedicated to handling the control plane and other that deal wit= h everything >> else that has been punted. Design the router so that the control plane d= oesn=E2=80=99t get >> overloaded and the exceptional packet get handled. >>=20 >> Generating PTB=E2=80=99s shouldn=E2=80=99t be seen as exceptional. Fragm= ented packets shouldn=E2=80=99t be >> seen as exceptional.=20 >=20 > Even if agree that is the way routers SHOULD be designed today. I'm not aw= are of any that are designed that way.=20 >=20 > Further, even if all new router shipped from today on were designed that w= ay, which they are not. It would easily take a decade or more for all the ol= d legacy routers to fade away on the Internet. Those are facts we have to wo= rk with. =20 Then THAT is the security issue. Not the packets that cause a broken implem= entation to have problems. Joe= --Apple-Mail-76F8A01F-7B43-4471-9E05-D1A245A08470 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Dec 4, 2018, at 11:00 PM, David Farmer <farmer@umn.edu> wrote:

<= blockquote type=3D"cite">
Punti= ng stuff to be processed by the same CPU that process the routing table work= ed
for a while.  There is no rule that says routers can=E2=80=99t have mul= tiple CPUs some of
which are dedicated to handling the control plane and other that deal with e= verything
else that has been punted.  Design the router so that the control plane= doesn=E2=80=99t get
overloaded and the exceptional packet get handled.

Generating PTB=E2=80=99s shouldn=E2=80=99t be seen as exceptional.  Fra= gmented packets shouldn=E2=80=99t be
seen as exceptional.

Even if agree= that is the way routers SHOULD be designed today. I'm not aware of any that= are designed that way. 

Further, even if all n= ew router shipped from today on were designed that way, which they are not. I= t would easily take a decade or more for all the old legacy routers to fade a= way on the Internet. Those are facts we have to work with.  
=

Then THAT is the security issue= .  Not the packets that cause a broken implementation to have problems.=

Joe
= --Apple-Mail-76F8A01F-7B43-4471-9E05-D1A245A08470-- From nobody Wed Dec 5 04:16:33 2018 Return-Path: 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 C4C85130DDA; Wed, 5 Dec 2018 04:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=strayalpha.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 WJ2fsnM1V5w5; Wed, 5 Dec 2018 04:16:20 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002B91200D7; Wed, 5 Dec 2018 04:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fWILj72iXp7WTuh6RB4AZJ3YTgaM+K4nYNedtVlkHfg=; b=OWm1FiOQY4GfMdujkWixFtoZh aID8EfLfYtDFoY/mEazRGX7Z/a0AqVGpPBiVQPryLvIInniz/a88QFsqGmEYjyQGUGUc63Yi2OftD RKdytOKdmdaynRQjhWUQXXNhR5QWBC1Y5l53XDwRm81rajSEX0vpppSgpERmLlqX8hn87llJaEvKp wafW36absQLcwGCH/C7IG0OFrMVs2PtBSCduvNE9ZR4WOfM6quYQ0zjJ00iXAZZHSwEiyUJ69NIk+ IFwVawQ+fk+EfpkGOYlN6mW29Xp9wCxUwkED5qM2g+PT6FQkk70VICP8FPcgQzPSHsMlqTtp4mvRd B9BpIWIZA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57092 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUW6E-002f5Q-NB; Wed, 05 Dec 2018 07:16:19 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> Date: Wed, 5 Dec 2018 04:16:18 -0800 Cc: Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.co m> To: Brian E Carpenter X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 12:16:23 -0000 On Dec 4, 2018, at 8:46 PM, Brian E Carpenter w= rote: >> Nobody deprecated the flags that require HBH options to be processed or d= ropped if not supported.=20 >=20 > Intentionally. If a forwarding node is transparent to HbH options, > it is not looking at those flags. If it is looking at HbH options, > it will obey those flags. Why is that a problem? What exactly does =E2=80=98transparent to HbH options mean=E2=80=99 if not =E2= =80=98not supported=E2=80=99? In that case, the flags have exactly no meaning anywhere. But they=E2=80=99r= e not deprecated. That makes no sense at all. Joe= From nobody Wed Dec 5 04:21:54 2018 Return-Path: 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 07619130DF4 for ; Wed, 5 Dec 2018 04:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 f4Ksq8GPuu1p for ; Wed, 5 Dec 2018 04:21:46 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71850130DF7 for ; Wed, 5 Dec 2018 04:21:44 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A64BC421A6 for ; Wed, 5 Dec 2018 13:21:42 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 94DEC41C36; Wed, 5 Dec 2018 13:21:42 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 86346AD63; Wed, 5 Dec 2018 13:21:42 +0100 (CET) Date: Wed, 5 Dec 2018 13:21:42 +0100 From: Gert Doering To: Joe Touch Cc: David Farmer , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , opsec@ietf.org, tsv-art@ietf.org Message-ID: <20181205122142.GJ1543@Space.Net> References: <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 12:21:49 -0000 Hi, On Wed, Dec 05, 2018 at 04:13:47AM -0800, Joe Touch wrote: > Then THAT is the security issue. Not the packets that cause a broken implementation to have problems. Can we declare folks at IETF that have no idea about operational realities to be a security issue? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Dec 5 04:31:42 2018 Return-Path: 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 8AD3F130DF4; Wed, 5 Dec 2018 04:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 wDg_RZog1XsO; Wed, 5 Dec 2018 04:31:19 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60CB128BCC; Wed, 5 Dec 2018 04:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6ZSvvSfPnOhWrsFl8flMyNtMlH7XUPUNKdP1ne5Ts9g=; b=Kpdme9GKRANcrCvBmyf72tN0m PYVTKcezFaovBWCwfUvm8sdL33yADWCzPjztGrUcJj8WJX84dhDLkN6GyRgVzoMbifDXr6rrH2ie2 9c9XKGSbGWiADaOO1lcgZ8yS+GOT0S6GcJ/vHmmGNpwWRe2zIf9b8F03/A9ycGRl7cCB2Dc+9+ehb LmBrzhiyBakiBUQ3IGzy0DcQUSWv+4F3Ni1sUdejryfUyit8Wtc+EfwXeQtCE0GT0lGaGsCOHpo8+ VhRQyS+x8KdZ4yYJTOEJK1OthUTptKO7A7VZZb1g480IbNMAqnsw9ASbLBMzXkL15R2KofGg7YSHf bDUZOttgQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57125 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUWKk-002yGV-9L; Wed, 05 Dec 2018 07:31:19 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <20181205122142.GJ1543@Space.Net> Date: Wed, 5 Dec 2018 04:31:17 -0800 Cc: David Farmer , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , opsec@ietf.org, tsv-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> To: Gert Doering X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 12:31:21 -0000 > On Dec 5, 2018, at 4:21 AM, Gert Doering wrote: >=20 > Hi, >=20 >> On Wed, Dec 05, 2018 at 04:13:47AM -0800, Joe Touch wrote: >> Then THAT is the security issue. Not the packets that cause a broken imp= lementation to have problems. >=20 > Can we declare folks at IETF that have no idea about operational realities= > to be a security issue? As long as we can do the same for operators that blame protocols for vendor i= ssues. Joe From nobody Wed Dec 5 04:48:37 2018 Return-Path: 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 416D6124BF6; Wed, 5 Dec 2018 04:48:35 -0800 (PST) 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 CBsOdHhJeW68; Wed, 5 Dec 2018 04:48:33 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB160124D68; Wed, 5 Dec 2018 04:48:32 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wB5CmTo3046426 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2018 12:48:30 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Joe Touch Cc: David Farmer , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec@ietf.org, tsv-art@ietf.org References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> From: Nick Hilliard Message-ID: <9a613af3-c71e-1c30-d10a-f8a57aee3250@foobar.org> Date: Wed, 5 Dec 2018 12:48:28 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.6 MIME-Version: 1.0 In-Reply-To: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 12:48:35 -0000 Joe Touch wrote on 05/12/2018 12:13: > Then THAT is the security issue..  Not the packets that cause a broken > implementation to have problems. In this specific case: 1. the protocol definition states that HBH packets should be processed per intermediate node. 2. even small routers can now handle terabits of data plane throughput. What do we do? 1. declare that these routers should be able to process terabits of HBH packets (or experimental EHs because we don't know whether experimental EHs are required to be processed HBH or by end points only). 2. formally drop the requirement for intermediate routers to process HBH headers 3. build routers which will take some HBH headers at low packet rates and drop the rest (+ update rfcs to make this formally compliant). 4. something else. Nick From nobody Wed Dec 5 05:02:56 2018 Return-Path: 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 854BF12872C; Wed, 5 Dec 2018 05:02:42 -0800 (PST) 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=unavailable 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 PcjKva734s7R; Wed, 5 Dec 2018 05:02:41 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350D71277C8; Wed, 5 Dec 2018 05:02:41 -0800 (PST) X-Envelope-To: tsv-art@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wB5D2aG1048112 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2018 13:02:36 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Christopher Morrow Cc: Joe Touch , Stewart Bryant , tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> From: Nick Hilliard Message-ID: <59c6c31e-05ea-65b2-4ffe-ca05a449c8cd@foobar.org> Date: Wed, 5 Dec 2018 13:02:34 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.6 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 13:02:43 -0000 Christopher Morrow wrote on 04/12/2018 20:17: > I think the point that Nick and Gert are outlining is that if the case > is that the hardware available will have no fast-path processing for > packets with obtuse patterns or sets of extension headers those packets > will get sent to the control-plane (slow-path). in this case, yes, but there is a more general issue, namely that protocols are often written without the benefit of hindsight or experience. Implementation of specifications will usually throw up problems and it almost never happens that a protocol specification is defined so jesuitically that ambiguity doesn't happen. Looking at this from another angle, engineering is about optimisation of conflicting input parameters. The IETF needs to understand how and why this happens, because it can provide useful feedback on the rfcs that are churned out, ranging from ambiguity to gap analysis to impracticality. Nick From nobody Wed Dec 5 05:12:54 2018 Return-Path: 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 3EFD3124D68; Wed, 5 Dec 2018 05:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=strayalpha.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 eYiTjZFB2-20; Wed, 5 Dec 2018 05:12:51 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100F8124BF6; Wed, 5 Dec 2018 05:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gqaZu64wbfpfCg93df5wfO+o8mGw6lVBPmOS59YX728=; b=sWNGX4jjDGdCNig/DeBLjfgPL a1OfqeMSEnhZpDi6tP1Ps7OXuEFVFNzWcwEoIW7/8TqtpW9kO18dSJkPG2UxUHCxvxz1r7L6QfqZe 3c+LLFcz+G8WTqr0VKBLbMARGOnwYVtYbVTFOzYQQdC3xrY4O7IRN3T1tUZxmgcx/qSFLH7/UuYfr kwodfDrq7SkBqdv4MqyUfUUWSQmT3U2twPyL7ZNFLk04NsfJ5dYfH0n9IOG74nYFgNeOxIw3+YbTq PAibeL8bT+6ZwEU9TRSy1BoFx/4y8ml4UbetA1R32Y9wEsRumtEyQvjRB5e3JukMlYAT/UeE6v3NT gIPsSk2NA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57172 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUWyv-003b94-7u; Wed, 05 Dec 2018 08:12:50 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <9a613af3-c71e-1c30-d10a-f8a57aee3250@foobar.org> Date: Wed, 5 Dec 2018 05:12:48 -0800 Cc: David Farmer , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec@ietf.org, tsv-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8FE8712B-4CFC-450F-AEB8-A7CCD7D2F121@strayalpha.com> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <9a613af3-c 71e-1c30-d10a-f8a57aee3250@foobar.org> To: Nick Hilliard X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 13:12:52 -0000 The choices below don=E2=80=99t include declaring this a security risk and t= urning it off. If you want to change the standard, do so. But this isn=E2=80=99t a step isn= =E2=80=99t that direction. And the previous attempts only show why IPv6 has a= doption problems. The standard can still be changed, but regardless, this simply is not a secu= rity issue and shouldn=E2=80=99t be sold as one. Joe > On Dec 5, 2018, at 4:48 AM, Nick Hilliard wrote: >=20 > Joe Touch wrote on 05/12/2018 12:13: >> Then THAT is the security issue.. Not the packets that cause a broken im= plementation to have problems. >=20 > In this specific case: >=20 > 1. the protocol definition states that HBH packets should be processed per= intermediate node. >=20 > 2. even small routers can now handle terabits of data plane throughput. >=20 > What do we do? >=20 > 1. declare that these routers should be able to process terabits of HBH pa= ckets (or experimental EHs because we don't know whether experimental EHs ar= e required to be processed HBH or by end points only). >=20 > 2. formally drop the requirement for intermediate routers to process HBH h= eaders >=20 > 3. build routers which will take some HBH headers at low packet rates and d= rop the rest (+ update rfcs to make this formally compliant). >=20 > 4. something else. >=20 > Nick From nobody Wed Dec 5 05:38:27 2018 Return-Path: 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 7EB4C12D4E6 for ; Wed, 5 Dec 2018 05:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 JcnRFJfi25yK for ; Wed, 5 Dec 2018 05:38:24 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91771292F1 for ; Wed, 5 Dec 2018 05:38:23 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3CD9441C21 for ; Wed, 5 Dec 2018 14:38:21 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 2959C41B3A; Wed, 5 Dec 2018 14:38:21 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 24DC7B320; Wed, 5 Dec 2018 14:38:21 +0100 (CET) Date: Wed, 5 Dec 2018 14:38:21 +0100 From: Gert Doering To: Joe Touch Cc: Gert Doering , David Farmer , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , opsec@ietf.org, tsv-art@ietf.org Message-ID: <20181205133821.GL1543@Space.Net> References: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PAKmkkBo0+rTwAqJ" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 13:38:27 -0000 --PAKmkkBo0+rTwAqJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Dec 05, 2018 at 04:31:17AM -0800, Joe Touch wrote: > > On Dec 5, 2018, at 4:21 AM, Gert Doering wrote: > >=20 > >> On Wed, Dec 05, 2018 at 04:13:47AM -0800, Joe Touch wrote: > >> Then THAT is the security issue. Not the packets that cause a broken = implementation to have problems. > >=20 > > Can we declare folks at IETF that have no idea about operational realit= ies > > to be a security issue? >=20 > As long as we can do the same for operators that blame protocols for vend= or issues. If a protocol cannot be implemented in a way that can be paid by real world= =20 participants, it's not a vendor issue. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --PAKmkkBo0+rTwAqJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwH1MoACgkQ31bAZeTO f8WfUA/+JFRHOyZUg43wGy6Jns0DwSYzMjkyfg4eO0fvkd1y9JxBEYYc5Q4MarNH TTeGONtB0/WDb4LrjangEIZ0Rm4rXZ5cXP0t/Xkec+Yu3Vg21/CEqLFJ8lwAXSPG hgVxLLTZg4Yax9Wl/012ZH4zpWJ44O+gk78zqEv65QVOKLuA3LrrtcZF9+Cs3hM8 m7KadKlopVRZH3WLnm+A+FGG4cNueY39pLsa3lSwgRsPzk+k046xY6z4aq4qxo9H 56suRJUCBgB8+buzezEDb4LzOBX0r8i0FxOhHxJCZJIF5NabpzfuSqpmlxn57fGj n8986KAdXCAyg88cUYzDFNRqRUMQYPpFn3u3IHa6U12Z6D+0sxOvCT1agMAebqTf obkrPvB8I147iKwbfUxjlYS0VPgAjObaglHH3ajTUYM8mq7l+o4K+LnQ3NClQ5OF fS7I8cYx8pqnqu6wsUSviogUbQ0FV1OMJegg06nr9GHGAg0f7PvgKwGSWLFqPIJk dkv747n7OXFWTDXdN61XB3OmifATsn7hT86dDyMcPh2G55HF3WDzmVbbDczAfdJ1 37mSyfBwMVUieMT7KGqLtphPmABwJ93Bo6/XqRuDG3fOG8Cv7vX0AugSI1gIi4dA wTgo8Iq3cZ6xBAr1fkFs5Bnm23i86QdqnOj5gqDBkpIqEEhgRcM= =H9x8 -----END PGP SIGNATURE----- --PAKmkkBo0+rTwAqJ-- From nobody Wed Dec 5 05:45:34 2018 Return-Path: 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 BEE2E1288EB; Wed, 5 Dec 2018 05:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 J75WX9GvFt34; Wed, 5 Dec 2018 05:45:06 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A798E1277BB; Wed, 5 Dec 2018 05:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q1apF+rsm7a/ZxUP2221yGdF1cEH32Dsfez7ocS87fM=; b=bNGfxU8mgmFXFMAERNoaZi7rH MPTaYebmVwLpbgQb1eP/JaUsYt77OFojn280w8NcPF4HGbOUpNoBNj9kOu15oFeQP1Gz7ck483n7r u/dE/lPE+VFBxyIrOWbunkmFE9kkFz9RI+KSqUll7Ghg7k/ixJWtSHASrxz8CwvhOdksdJvqD10xS rPNvhxCOpbo6FR80rhStAnbqV/HIm3ltZhIrirgQDkyNG6x88jvldgN/WH+dV1SYkmSdzhnpSsDub yoRHm9mbbQPK0I/vQrNMMkRZ5TaAv5V3qjMxDcCeXzSY3iOdqIbtdsWd2ooR9OtHHK0fj7IoPrCPH D1JEhzz9A==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57196 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUXU7-004Afo-EN; Wed, 05 Dec 2018 08:45:04 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <20181205133821.GL1543@Space.Net> Date: Wed, 5 Dec 2018 05:45:02 -0800 Cc: draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , David Farmer , opsec@ietf.org, tsv-art@ietf.org, IETF-Discussion Discussion Content-Transfer-Encoding: quoted-printable Message-Id: References: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> To: Gert Doering X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 13:45:13 -0000 Vendors are not required to lie when claiming IPv6 support. > On Dec 5, 2018, at 5:38 AM, Gert Doering wrote: >=20 > Hi, >=20 > On Wed, Dec 05, 2018 at 04:31:17AM -0800, Joe Touch wrote: >>> On Dec 5, 2018, at 4:21 AM, Gert Doering wrote: >>>=20 >>>> On Wed, Dec 05, 2018 at 04:13:47AM -0800, Joe Touch wrote: >>>> Then THAT is the security issue. Not the packets that cause a broken i= mplementation to have problems. >>>=20 >>> Can we declare folks at IETF that have no idea about operational realiti= es >>> to be a security issue? >>=20 >> As long as we can do the same for operators that blame protocols for vend= or issues. >=20 > If a protocol cannot be implemented in a way that can be paid by real worl= d=20 > participants, it's not a vendor issue. >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael E= mmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Wed Dec 5 05:49:04 2018 Return-Path: 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 8B9621277BB; Wed, 5 Dec 2018 05:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 g1_-MFFQ0OSM; Wed, 5 Dec 2018 05:48:49 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A825124D68; Wed, 5 Dec 2018 05:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=756mMnyKnbGMrJmvzfncy4Cx/mWGoG7kVf+K6FgmjD4=; b=yo0tgJ0y0W7oY5NZTeK8gEPBE 8lkyVCCJVWJBK+Cd8jfwm9xcmn7MVVKKsYLI6ez/oIm3FBcE52XlcJUmeDsWtJG2k6Q/uRaOnh+Kx nDzHOxH6sKqZuIovwDvpU9SbcLEjQ1AEL4TYlObhxv2EuhOacMeKWTTYTYb/UpvVJn1n/ywTfg5A0 hmHp8q9ci8CBAYZhVWWdv/4mpwj/zRwk/37Dgk5la+STU3RmAXPZfQMSPJ8CB928/jYwjmgqrXePo BnciEI2KlYjSKu6GC9fx16cvwgVIAiJFfWBKJ9Ny8SflghVDAeUO5KOH90ccom87I+5lbDyN6Hrk9 dHEMT6mWg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57198 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUXXj-004Die-Vm; Wed, 05 Dec 2018 08:48:48 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <59c6c31e-05ea-65b2-4ffe-ca05a449c8cd@foobar.org> Date: Wed, 5 Dec 2018 05:48:43 -0800 Cc: Christopher Morrow , Stewart Bryant , tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <59c6c31e-05ea-65b2-4ffe-ca05a449c8cd@foobar.org> To: Nick Hilliard X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 13:48:51 -0000 > On Dec 5, 2018, at 5:02 AM, Nick Hilliard wrote: >=20 > there is a more general issue, namely that protocols are often written wit= hout the benefit of hindsight or experience Yet we had that experience by 8200 and did not remove HBH options or their f= lags. I agree there is a problem her, but it is not a security problem. We cannot= continue to claim that the options exist if they can be silently ignored at= will while being marked Sa =E2=80=98drop if not supported=E2=80=99.=20 Fix the problem. But let=E2=80=99s not perpetuate the lies. Joe= From nobody Wed Dec 5 05:54:35 2018 Return-Path: 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 E2AA01277BB; Wed, 5 Dec 2018 05:54:33 -0800 (PST) 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 IanY2h_tsr6e; Wed, 5 Dec 2018 05:54:30 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEFD1277C8; Wed, 5 Dec 2018 05:54:30 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wB5DsRLE054391 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2018 13:54:27 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Joe Touch Cc: David Farmer , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec@ietf.org, tsv-art@ietf.org References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <9a613af3-c71e-1c30-d10a-f8a57aee3250@foobar.org> <8FE8712B-4CFC-450F-AEB8-A7CCD7D2F121@strayalpha.com> From: Nick Hilliard Message-ID: Date: Wed, 5 Dec 2018 13:54:26 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.6 MIME-Version: 1.0 In-Reply-To: <8FE8712B-4CFC-450F-AEB8-A7CCD7D2F121@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 13:54:34 -0000 Joe Touch wrote on 05/12/2018 13:12: > The choices below don’t include declaring this a security risk and > turning it off. > > If you want to change the standard, do so. But this isn’t a step > isn’t that direction. And the previous attempts only show why IPv6 > has adoption problems. > > The standard can still be changed, but regardless, this simply is not > a security issue and shouldn’t be sold as one. If J Random Hacker in his mom's basement can launch an attack which takes down your network core because your management planes can't handle 1Tbit, or more realistically 10gbit, of HBH packets, then that is categorically a network security issue, even if it is a secondary effect. Nick From nobody Wed Dec 5 05:57:33 2018 Return-Path: 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 310341277BB for ; Wed, 5 Dec 2018 05:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 E_2InKfcDVgp for ; Wed, 5 Dec 2018 05:57:24 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88238124D68 for ; Wed, 5 Dec 2018 05:57:24 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3B01A41C21 for ; Wed, 5 Dec 2018 14:57:23 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 2BC8641C0F; Wed, 5 Dec 2018 14:57:23 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 1CFF2B431; Wed, 5 Dec 2018 14:57:23 +0100 (CET) Date: Wed, 5 Dec 2018 14:57:23 +0100 From: Gert Doering To: Joe Touch Cc: Gert Doering , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , David Farmer , opsec@ietf.org, tsv-art@ietf.org, IETF-Discussion Discussion Message-ID: <20181205135723.GN1543@Space.Net> References: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fblc08uBQ7kpPybH" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 13:57:26 -0000 --fblc08uBQ7kpPybH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Dec 05, 2018 at 05:45:02AM -0800, Joe Touch wrote: > Vendors are not required to lie when claiming IPv6 support. So you prefer that vendors just do not deliver IPv6 at all? Let me repeat that: what you want will not be paid by the marketplace. Chained EHs are a relict from a time when everybody was nice and=20 cooperative, bandwith was sparse, routers used CPUs to forward packets, and money came from governments to research networks in huge amounts. This is not today's Internet anymore. You can accept that or not, but nothing you can say will magically make=20 the necessary amount of money and development resources (let alone=20 "interest") appear to build and deploy routers that can do what you want=20 all across the Internet. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --fblc08uBQ7kpPybH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwH2UIACgkQ31bAZeTO f8W9Iw//VGxvr41wpQCGF4cI5kEVko2BRkFd4YdQ86VaBrTw23XBKMnAskMGW+Ss MCagWrXsexvleq21h7I4hFFp1CsCDt+tQsQ/0riMDEU+P2oRqqKyONlzFJwH76+Z KaocZv1BM5Bug2hdQODeU5WC2ETOPOl3GQAGfOGJYGeAKV84LahirqcxdAQ3g5zZ HDRDXgOJqrKgbfvgYg68Rk5Hq46TMF22uQXXzjmokPFLA579JxI494YUmKfGidEs AwGSAOWEoB+JLuEie+clBiw8JO1RI4cqoPx7bVkFPEnYBKGhGBctOcptFJEl6YlK 38sqhKjmRulr915iBlVjLWGJGMJDI27RBnQ1muTvvm1GGqvAekfF35o+8YC5avVQ Ob3n5Hj1ONr5UJDCAD34g8dc21ohikOLL53fy/AFDcCeBNjL5sfDUJholfV8V2yt 5+0Q9AAQFo5eFidgTEBjeNPO5Mf5aB1nrPZuL7giZqImf/7D1hhKSTkiesiDqBUI HuHh9qVM6B0ULkWBEiKItjscSH+u7jyWu2ru1eTRP5xyKg9/LWf80lGS104hU3o2 xEghZTDgC5QKRKwIaY4y3m20nO/KVj2E4b3V9YmR//Cyc2UQ5i06GDDMqNnSBl+y HcUWCZfVYU82FpZdBtAIgkCxx8Ytx/abyft61CUNTQwgYeIhQ38= =yLnd -----END PGP SIGNATURE----- --fblc08uBQ7kpPybH-- From nobody Wed Dec 5 06:31:10 2018 Return-Path: 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 354BB130E0C; Wed, 5 Dec 2018 06:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 LnMSPqSObmZC; Wed, 5 Dec 2018 06:31:05 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD874130E54; Wed, 5 Dec 2018 06:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wlnm/4w9iSDtG9UBpB6P5vmcGxkLVOnN2AoqN06lXww=; b=1n6KbLsx+4vwTmlkpw98fg3+I mUihhudeKt4Np381Sw6KrBAJB2FPQTA5uIXSWfzdCp+Jh2hQh0FzvZRwp1bkcYzyj07J8y0mZj40l zn9w5laiHhUwxQnYZnja/uQRDkVG8ELTVgI1pJE6rzVNH+QgkACc63UiCBqR7FW/W9lwVCRKZupHH BRs8Dv6VR37lXRaBmfKwUe5d+FsFj4fsYsmflUa6U9F8o3kpyfTcPs7Ud8l/wB6uGBhuYYLcdZ5fm NZF1RYVvA6TytXgqbU0QpfX8NkXlA/DZLNC1CVXrO5jXGYmUCGuL6VAH8z8iRx+GpffCHBwUfcx5w 7ppuJTpKQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57250 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUYCQ-000YSE-IP; Wed, 05 Dec 2018 09:30:51 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: Date: Wed, 5 Dec 2018 06:30:49 -0800 Cc: David Farmer , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec@ietf.org, tsv-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <9a613af3-c71e-1c30-d10a-f8a57aee3250@foobar.org> <8FE8712B-4CFC-450F-AEB8-A7CCD7D2F121@strayalpha.com> To: Nick Hilliard X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 14:31:08 -0000 > On Dec 5, 2018, at 5:54 AM, Nick Hilliard wrote: >=20 > Joe Touch wrote on 05/12/2018 13:12: >> The choices below don=E2=80=99t include declaring this a security risk an= d >> turning it off. >> If you want to change the standard, do so. But this isn=E2=80=99t a step >> isn=E2=80=99t that direction. And the previous attempts only show why IPv= 6 >> has adoption problems. >> The standard can still be changed, but regardless, this simply is not >> a security issue and shouldn=E2=80=99t be sold as one. > If J Random Hacker in his mom's basement can launch an attack which takes d= own your network core because your management planes can't handle 1Tbit, or m= ore realistically 10gbit, of HBH packets, then that is categorically a netwo= rk security issue, even if it is a secondary effect. So every SNMP packet is an attack as well? As is every routing packet? A security issue is created when a packet can cause *disproportionate* load.= Otherwise it=E2=80=99s just called load. The security issue is the implementation not throttling such packets to avoi= d having 10G of them shutting down the control plane. Yes, that=E2=80=99s a s= ecurity issue, but it=E2=80=99s not the fault of the HBH packets. Joe= From nobody Wed Dec 5 06:31:56 2018 Return-Path: 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 84659130E01; Wed, 5 Dec 2018 06:31:48 -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 JTK8P6pbkVTt; Wed, 5 Dec 2018 06:31:46 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 1C0CB130E1E; Wed, 5 Dec 2018 06:31:46 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id z5so19911377wrt.11; Wed, 05 Dec 2018 06:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=I9CqO5Ei5qRe3HpyWoY5INCwrrh2hJM61gjUcfL7PLw=; b=ePx0d71rF1kbo1ksarl0MQRlBo+aha2kcj8IBe5TeQyr+NkMyEXmLW/AMv6CQOxjeG ltzawNfclVDLKWPke17Rftvp4UajEuZiQbjShSJll6P+W3W1N6IX91LaPecoALJJ2YzB eGD3+mZsoLrTiwCU6FlDApcxm7oaZxhVhlRU4yRH42WefUjKwJO9nQKOzymdujquu4mY 5Torv2FP8v5h6ofKHcEpod8uKCHnKjzWQeWYresGr+ZmQuvS4Gdj3LJcu9HX798/3TJ7 2SHr16Ji4bl8POFz/KCbpnExv21/l0hcrKFvctyKI6eEtBGYTqMmGbA8B2wzxCZeT2JB scQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=I9CqO5Ei5qRe3HpyWoY5INCwrrh2hJM61gjUcfL7PLw=; b=uS6bDEcFNvJNrH/Y2x4lknt1tzGwGQUabfKedWZ0j3/PGYDIB19y7EqnKLow4GKfm2 4Bs+TYItMJijfcdEuWtNJZ3RnXQX0SBOHn7N0ebo7iczIJoEVgD0L53uO6hGpI1SyB2Q QiB07ArEsGZy71OKwAwY/UUiq4/r8RG3/fbrG9vJIuzlo39/VzI8NzbsmUHwiFXh+aa1 n4Th+ujpNgpNDd6cBBanIaJDklMsYDWFUTTGbqbj4FsZMm1WOO/Jr4Q4glR4IDkcSus6 VXRbFbxmNQIHEEtG+ScMaRdzMRY49SmbRDejYHjJ10pwS3rYsKyAUOUt0O0aMegiNBKC JPQw== X-Gm-Message-State: AA+aEWaah/OBVvsDX+VgEAEm25qSANGKQFc+HHLCwr/oRlyw/yaIkn3P jzuZUAIEW67dYLuEQ2FlXMtnZHwh X-Google-Smtp-Source: AFSGD/UW/CpJ+2VeSYo8QWRBNV8PTHj9PZuTzGiRx+GVTOkMFJ4CyCGqm6ma6IH//E00VAQgCNIEUw== X-Received: by 2002:adf:9168:: with SMTP id j95mr21639379wrj.217.1544020304121; Wed, 05 Dec 2018 06:31:44 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id x12sm12479381wmc.37.2018.12.05.06.31.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 06:31:43 -0800 (PST) To: Joe Touch , Gert Doering Cc: IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec@ietf.org, tsv-art@ietf.org References: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> From: Stewart Bryant Message-ID: <49ce09a7-8974-fc74-f2ed-c5ef734095a7@gmail.com> Date: Wed, 5 Dec 2018 14:31:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 14:31:55 -0000 As far as I see, this thread illustrates that there is a significant gap between the protocol designers, the protocol implementers and the protocol users. This is something that needs to be addressed if the IETF is not to loose its reason to exist. Best regards Stewart On 05/12/2018 13:45, Joe Touch wrote: > Vendors are not required to lie when claiming IPv6 support. > >> On Dec 5, 2018, at 5:38 AM, Gert Doering wrote: >> >> Hi, >> >> On Wed, Dec 05, 2018 at 04:31:17AM -0800, Joe Touch wrote: >>>> On Dec 5, 2018, at 4:21 AM, Gert Doering wrote: >>>> >>>>> On Wed, Dec 05, 2018 at 04:13:47AM -0800, Joe Touch wrote: >>>>> Then THAT is the security issue. Not the packets that cause a broken implementation to have problems. >>>> Can we declare folks at IETF that have no idea about operational realities >>>> to be a security issue? >>> As long as we can do the same for operators that blame protocols for vendor issues. >> If a protocol cannot be implemented in a way that can be paid by real world >> participants, it's not a vendor issue. >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art From nobody Wed Dec 5 06:32:59 2018 Return-Path: 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 92542130E3A; Wed, 5 Dec 2018 06:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 ZkGWOXmwN54q; Wed, 5 Dec 2018 06:32:35 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801B512DDA3; Wed, 5 Dec 2018 06:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uorv0o7RBfIwe5C+sTRv67HDl0fpwQP43SwhojVLYAI=; b=L+zpnmfFA4hD59egwJYQTiLZU 8C/r9xUwRjHIhGRJSMRHyRqaNrPVFuV58sBHQzW8tAwE4aonyA6DYUVgS1MPqHqCz9sMkim3aiIPe K7BUQK3R5ugds/JcLMRqAWhYQV7qEbTtvN4PIi3w1+Kv3oSPIMxbi+HOLtK13xWRuYq1Z3KxKeo33 mqry+Bj30AWsyMhjzkdtwSLXY0SXXDdlneolLrRtMCUzc0TbfKOGkp+2L9HZ34DlTqVZ7Mi1+Dx17 u2E/IkJYE0tImHsmmSbI4Q1T8JZJuEoJeczMGUnooKnBAzzYAJ4XJKnp0osgWcnEm5fENftf0JfEE rTyoG3TBA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57256 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUYE6-000aSN-2l; Wed, 05 Dec 2018 09:32:34 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <20181205135723.GN1543@Space.Net> Date: Wed, 5 Dec 2018 06:32:33 -0800 Cc: draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , David Farmer , opsec@ietf.org, tsv-art@ietf.org, IETF-Discussion Discussion Content-Transfer-Encoding: quoted-printable Message-Id: References: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> To: Gert Doering X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 14:32:51 -0000 > On Dec 5, 2018, at 5:57 AM, Gert Doering wrote: >=20 > Hi, >=20 >> On Wed, Dec 05, 2018 at 05:45:02AM -0800, Joe Touch wrote: >> Vendors are not required to lie when claiming IPv6 support. >=20 > So you prefer that vendors just do not deliver IPv6 at all? I=E2=80=99m only saying: - implement what IP requires or don=E2=80=99t call it IP - if we can=E2=80=99t implement what IP requires, then change the STANDARD But this isn=E2=80=99t an operational issue and it isn=E2=80=99t a security i= ssue. > have you enabled IPv6 on something today...? No, but you haven=E2=80=99t either. Joe= From nobody Wed Dec 5 06:35:51 2018 Return-Path: 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 3C191126C01; Wed, 5 Dec 2018 06:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Qp6WCd_mUeq8; Wed, 5 Dec 2018 06:35:48 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53DD12785F; Wed, 5 Dec 2018 06:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4D8+sekdvngH+2i5IFAcj5I/0X/OHRwGurKIJp0V3a8=; b=m/aQhl1Ey8+Zyxo3F2XF1QcEk 7h86arpKAE/9Xqe9+uzmIU+urN1r5nhtV+dDdunqugKN1RxMkBYlCp1FP/2vAYKPG7mnv+d1ai0FY 906kOTIE9oGeNElU/Wk1+6av48W7UVK8uIFsbiFHW1LEOTnmpteUVj4xXF4q2pDWXolXyRfhP19H3 NyCmoJxx5MRYrkuzUmdreh3m/LM7NGMak2zN7IJG5gExweASEA7+7q98OpnVssSNVRDstzJST3FOC JmImzpMZ6TM5dIFNVtcFqxTkKPFW46VQuNcTjOK8osI2xafAR7AZCdAP4q84EMRaenb4bB3htVV0h 5XZl9zhVA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57261 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUYHC-000e5M-Oy; Wed, 05 Dec 2018 09:35:47 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <49ce09a7-8974-fc74-f2ed-c5ef734095a7@gmail.com> Date: Wed, 5 Dec 2018 06:35:46 -0800 Cc: Gert Doering , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec@ietf.org, tsv-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2FF6B298-B948-44C0-9345-FD72FE4901B5@strayalpha.com> References: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <49ce09a7-8974-fc74-f2ed-c5ef734095a7@gmail.com> To: Stewart Bryant X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 14:35:49 -0000 There are gaps here, but there in other places: - the gap between what a protocol needs and what is in the spec if HBH isn=E2=80=99t needed and can=E2=80=99t be implemented, remov= e them if HBH is needed, then we need to find a way to have the requiremen= t mean something A similar problem exists with fragmentation. NIMBYisnm won=E2=80=99t fix it,= nor will operator declarations, nor false security declarations. I don=E2=80=99t have a problem with fixing the STANDARD. I have a problem wi= th an end-run in ops. Joe > On Dec 5, 2018, at 6:31 AM, Stewart Bryant wrot= e: >=20 >=20 > As far as I see, this thread illustrates that there is a significant gap b= etween the protocol designers, the protocol implementers and the protocol us= ers. This is something that needs to be addressed if the IETF is not to loos= e its reason to exist. >=20 > Best regards >=20 > Stewart >=20 >=20 >> On 05/12/2018 13:45, Joe Touch wrote: >> Vendors are not required to lie when claiming IPv6 support. >>=20 >>> On Dec 5, 2018, at 5:38 AM, Gert Doering wrote: >>>=20 >>> Hi, >>>=20 >>> On Wed, Dec 05, 2018 at 04:31:17AM -0800, Joe Touch wrote: >>>>> On Dec 5, 2018, at 4:21 AM, Gert Doering wrote: >>>>>=20 >>>>>> On Wed, Dec 05, 2018 at 04:13:47AM -0800, Joe Touch wrote: >>>>>> Then THAT is the security issue. Not the packets that cause a broken= implementation to have problems. >>>>> Can we declare folks at IETF that have no idea about operational reali= ties >>>>> to be a security issue? >>>> As long as we can do the same for operators that blame protocols for ve= ndor issues. >>> If a protocol cannot be implemented in a way that can be paid by real wo= rld >>> participants, it's not a vendor issue. >>>=20 >>> Gert Doering >>> -- NetMaster >>> --=20 >>> have you enabled IPv6 on something today...? >>>=20 >>> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael= Emmer >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culeman= n >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >>> _______________________________________________ >>> Tsv-art mailing list >>> Tsv-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/tsv-art >=20 From nobody Wed Dec 5 06:53:52 2018 Return-Path: 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 5ACBE126C01; Wed, 5 Dec 2018 06:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ez2oQgNknLXA; Wed, 5 Dec 2018 06:53:39 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27CD1271FF; Wed, 5 Dec 2018 06:53:39 -0800 (PST) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id AA55FFECC0A9; Wed, 5 Dec 2018 14:53:38 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id CC9CEAA92D6; Wed, 5 Dec 2018 15:53:35 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Ole Troan In-Reply-To: <20181205135723.GN1543@Space.Net> Date: Wed, 5 Dec 2018 15:53:35 +0100 Cc: Joe Touch , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , David Farmer , OPSEC , tsv-art , IETF-Discussion Discussion Content-Transfer-Encoding: quoted-printable Message-Id: <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> References: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 14:53:45 -0000 Gert, >> Vendors are not required to lie when claiming IPv6 support. >=20 > So you prefer that vendors just do not deliver IPv6 at all? >=20 > Let me repeat that: what you want will not be paid by the marketplace. >=20 > Chained EHs are a relict from a time when everybody was nice and=20 > cooperative, bandwith was sparse, routers used CPUs to forward = packets, > and money came from governments to research networks in huge amounts. >=20 > This is not today's Internet anymore. >=20 > You can accept that or not, but nothing you can say will magically = make=20 > the necessary amount of money and development resources (let alone=20 > "interest") appear to build and deploy routers that can do what you = want=20 > all across the Internet. This is the exact reason we have layering in the Internet protocols. IPv6 routers are not meant to parse further into packets then the IPv6 = header (with one exception (1)). That network devices find it hard to parse deep into user=E2=80=99s = traffic is a feature. I find the argument that we should then change upper layer protocols to = accommodate that, hard to digest. I agree with Joe, this isn=E2=80=99t a security issue. Ole (1) The exception is the HBH header which is intended as a hook for = forwarding devices to do further processing of the packet. To Joe=E2=80=99s point, RFC8200 specifies that the header is to be = ignored unless the device is specifically configured to handle the = header. There is obviously no security risk for the router itself in ignoring = the NH=3D0 and forwarding the packet. There might be a risk if and when an actual HBH option is specified. But = that specification should have security considerations. From nobody Wed Dec 5 07:17:38 2018 Return-Path: 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 25F2712F1A2; Wed, 5 Dec 2018 07:17:27 -0800 (PST) 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 kHb_--H45iCB; Wed, 5 Dec 2018 07:17:24 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5B9130DEE; Wed, 5 Dec 2018 07:17:22 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wB5FHKlw064773 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2018 15:17:20 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Joe Touch Cc: David Farmer , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec@ietf.org, tsv-art@ietf.org References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <9a613af3-c71e-1c30-d10a-f8a57aee3250@foobar.org> <8FE8712B-4CFC-450F-AEB8-A7CCD7D2F121@strayalpha.com> From: Nick Hilliard Message-ID: <070ed0d8-f7cc-9634-7367-69c09d9eeaf3@foobar.org> Date: Wed, 5 Dec 2018 15:17:19 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.6 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 15:17:36 -0000 Joe Touch wrote on 05/12/2018 14:30: > So every SNMP packet is an attack as well? As is every routing > packet? snmp packets are either directed at a router or else directed through a router. If they are directed at a router, then they will be filtered / rate-limited on the data plane before they ever hit the management plane because no-one with half a brain cell is going to let their dfz core router open to snmp abuse. If they're pure data plane packets, then the management plane will never hear about them in the first place. Routing protocol packets are considered to be a potential attack vector, but again are subject to the limitation that if they are generated by third parties (i.e. unrelated parties, as compared to directly connected second parties who might have a legitimate reason for sending specific types of routing protocol packets - and not others), then they are routinely filtered out and/or rate limited before being forwarded to any router management plane. In any event, they are also subject to policers / shapers before hitting the management planes, regardless of source. Packets with HBH EHs are fundamentally different in this regard because they are data plane packets which are mandated by protocol to be processed on the management plane on every forwarding plane that they hit, even if this isn't their destination point. This is what's different and what is so dangerous about HBH packets, and why they need the sort of specific consideration that doesn't apply to most other types of packets. Thankfully rfc8200 recategorised them so that intermediate nodes are no longer required to process them. > A security issue is created when a packet can cause*disproportionate* > load. Otherwise it’s just called load. This is exactly what we are talking about: terabits of data-plane traffic hitting a management plane because the protocol says that that's what needs to happen. Terabits of data-plane traffic hitting a management plane which can only handle kilobits or megabits of data is disproportionate. You can trivially assess the level of disproportionality by noting the orders of magnitude in the numbers. Is 6 orders of magnitude disproportionate enough? One order of magnitude is enough for me. Trashed control planes are trashed, regardless of the scale of the trashing. > The security issue is the implementation not throttling such packets > to avoid having 10G of them shutting down the control plane. Yes, > that’s a security issue, but it’s not the fault of the HBH packets. It's a direct consequence of what the defining protocol used to say, except that vendors had more sense than to take protocols literally, and operations people have more sense than to leave their networks open to catastrophic abuse vectors just because it was written in a formal specification. Common sense is, thankfully, one of the optimisation considerations applied when dealing with the conflicting standpoints presented by protocols and reality. Nick From nobody Wed Dec 5 07:28:08 2018 Return-Path: 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 3A8C3130DDA; Wed, 5 Dec 2018 07:28:06 -0800 (PST) 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 N8hYJ1406qsn; Wed, 5 Dec 2018 07:28:04 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521CB128C65; Wed, 5 Dec 2018 07:28:04 -0800 (PST) X-Envelope-To: tsv-art@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wB5FS1mH066012 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2018 15:28:01 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Stewart Bryant Cc: tsv-art@ietf.org, opsec@ietf.org, IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <49ce09a7-8974-fc74-f2ed-c5ef734095a7@gmail.com> From: Nick Hilliard Message-ID: Date: Wed, 5 Dec 2018 15:28:00 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.6 MIME-Version: 1.0 In-Reply-To: <49ce09a7-8974-fc74-f2ed-c5ef734095a7@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 15:28:06 -0000 Stewart Bryant wrote on 05/12/2018 14:31: > As far as I see, this thread illustrates that there is a significant gap > between the protocol designers, the protocol implementers and the > protocol users. This is something that needs to be addressed if the IETF > is not to loose its reason to exist. yes, completely. There has always been a tension in this area. The tension isn't necessarily a bad thing, btw. It reminds us that this is important. Nick From nobody Wed Dec 5 07:55:35 2018 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2136130E3B; Wed, 5 Dec 2018 07:55:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Stewart Bryant To: Cc: opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154402532675.31849.8881420176249331430@ietfa.amsl.com> Date: Wed, 05 Dec 2018 07:55:26 -0800 Archived-At: Subject: [OPSEC] Rtgdir last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 15:55:27 -0000 Reviewer: Stewart Bryant Review result: Has Issues I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsec-ipv6-eh-filtering-06 Reviewer: Stewart Bryant Review Date: 5 December 2018 Intended Status: Informational Summary: This is a comprehensive and well written document. However the IESG needs to think carefully about whether this document end-runs the protocol development process. Comments: It is clear from the discussion on the list about this text that there is a disconnect between protocol theory, protocol implementation and protocol deployment with regard to IPv6 that needs to be resolved in the IETF, and which may be of broader scope than this text. Reading the text and the associated references I share those concerns. Major Issues: I am worried about the fragmented filter that this document attempts to mandate. It is easy to see why a router on the edge of its performance envelope would take the view : "if not UDP | TCP: slow path" if small queue to slow path full: drop Whilst this document performs a solid analysis of what actions should be taken on an option, it ought to make it clearer to the reader that how a router handles options needs to be a pragmatic engineering and business decision taken by the vendor and network operator. 3.4.2.5. Advice Intermediate systems should discard packets containing a RHT0 or RHT1. Other routing header types should be permitted, as required by [RFC7045]. SB> There also need to be advice to the protocol designers to SB> avoid the problems that got RHT0 deprecated in the first place. SB> Also, given the emergency deprecation of RHT0 there ought to SB> be a requirement on the fast path that it can block any RH type SB> at any time in the future. Minor Issues: The document includes the RFC 2119 template and makes very occasional use of RFC 2119 language, but as I read through the text I found instances where it looked as if such language could be usefully used but was not used. It is possible that the authors took the view that RFC 2119 language would only be used in quoted text, in which case a clarifying note to this effect might be useful. ============== o Ignore this IPv6 EH or option type (as if it was not present) and forward the packet. We note that if a packet carries forwarding information (e.g., in an IPv6 Routing Header) this might be an inappropriate or undesirable action. SB> If the node in question needed to see the routing information isn't SB> that a misconfiguration that should never happen? ============= Finally, we note that when discarding packets, it is generally desirable that the sender be signaled of the packet drop, since this is of use for trouble-shooting purposes. SB> Without further qualification of the action, isn't that also an attack vector SB> for a target "sender"? ============= 4.3.7.5. Advice Intermediate systems should discard packets that contain this option. SB> I think you mean should by default discard packets containing this option. SB> Otherwise this sentence technically conflicts with the next. Only in specific environments where support for RSVP, multicast routing, or similar protocols is desired, should this option be permitted. ============= 4.3.8.5. Advice Intermediate systems should not discard IPv6 packets based on the presence of this option. SB> Shouldn't this advice be more qualified given the advise in 4.3.8.4 ============= 4.3.10.5. Advice Intermediate system should discard packets that contain this option. SB> Shouldn't that be intermediate systems not in a MANET should...? ============= Nits: Blocking packets containing a RHT0 or RTH1 has no operational SB> That should be RHT1 in your notation) ============= Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4304' is defined on line 1412, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-hbh-header-handling' is defined on line 1554, but no explicit reference was found in the text From nobody Wed Dec 5 08:44:59 2018 Return-Path: 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 E381E130E83 for ; Wed, 5 Dec 2018 08:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 9AMSfulyPeEE for ; Wed, 5 Dec 2018 08:44:32 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A81130E92 for ; Wed, 5 Dec 2018 08:44:29 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 598DD41B3A for ; Wed, 5 Dec 2018 17:44:27 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 4B00141135; Wed, 5 Dec 2018 17:44:27 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 3C317BCB9; Wed, 5 Dec 2018 17:44:27 +0100 (CET) Date: Wed, 5 Dec 2018 17:44:27 +0100 From: Gert Doering To: Joe Touch Cc: Gert Doering , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , David Farmer , opsec@ietf.org, tsv-art@ietf.org, IETF-Discussion Discussion Message-ID: <20181205164427.GP1543@Space.Net> References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vK3aNhhOnFYnG5nq" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 16:44:46 -0000 --vK3aNhhOnFYnG5nq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Dec 05, 2018 at 06:32:33AM -0800, Joe Touch wrote: > > have you enabled IPv6 on something today...? > No, but you haven???t either. How would you know? I turn on IPv6 on things all day. I'm an operator, after all :-) (That my routers - thankfully - do not agree to certain parts of the IPv6 specification doesn't mean my endpoints are not proper IPv6 endpoints) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --vK3aNhhOnFYnG5nq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwIAGgACgkQ31bAZeTO f8WO3RAAklQ3GtTZw3EfeKKF8ThjDBwlBctOF1tlIAMx7YjBuPk+jvLmuNtIiEE1 1sldVgrCE5OUCEd7KAz8MaOLx0WQjZrRPb9px6C88niwvdwqBmT1dYoDQsyc3lGu vq6zcoNyrnkWPglz3+scLW8opAtTO/PY+RtEEwaJBFxDtmAYFadfgSMVxtVbs4q0 v+Ts6+vWqGuaEvZfov5Gtexh7mTnp8doFDcnN6XDoRDKArCvmO3jJXvUSwNim1Eh L+Sb7J7pqmeY3a+zPuu/mr/s6nLKrND9vAMLS3Kq4vIryG5ak/qis+okOJwu4iDe WHcTR/BEZIix3ksnYLuRAcYB6yf7VhbeIzVYAaiqM61uODwXhVClLdSIMKplvbcK Hx1EkteauAVlCuzr9/CbPT1C/KgmaWD5oRcmw3k6ewXOMzSRC7NUTPMXnG9yGwix MW3lR9oifBvZcVfCbmM/S7LFhjPKLgIAzCGRE1Arxp+0Mn3hVIrjq0ycfk5m+l53 UHrvKqzu1sn9F0ei5F/0CQHBttJ+A9mWLvQMgtO7izL+1Bs4z5pX4zwfmh6qtHZk f/IS9oGmHxKt4L7Z1kauAh971oMiHKdmDD/unL7hdnx+8FBtWKRDo1EFdfQ0sczM DrFFfuyOhwzUTED2+HRF/fUA9oCucruGLmxiGS+RDweus7noY7I= =LvKE -----END PGP SIGNATURE----- --vK3aNhhOnFYnG5nq-- From nobody Wed Dec 5 08:46:12 2018 Return-Path: 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 7DBCD130DEC for ; Wed, 5 Dec 2018 08:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ykT5GU-wI4ve for ; Wed, 5 Dec 2018 08:46:01 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990AF130E8C for ; Wed, 5 Dec 2018 08:46:00 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2F49A41C38 for ; Wed, 5 Dec 2018 17:45:59 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1950E41135; Wed, 5 Dec 2018 17:45:59 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 14E34BCD2; Wed, 5 Dec 2018 17:45:59 +0100 (CET) Date: Wed, 5 Dec 2018 17:45:59 +0100 From: Gert Doering To: Ole Troan Cc: Gert Doering , Joe Touch , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , David Farmer , OPSEC , tsv-art , IETF-Discussion Discussion Message-ID: <20181205164558.GQ1543@Space.Net> References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="r4jNezHNW2wfBox+" Content-Disposition: inline In-Reply-To: <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 16:46:11 -0000 --r4jNezHNW2wfBox+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable HI, On Wed, Dec 05, 2018 at 03:53:35PM +0100, Ole Troan wrote: > > Chained EHs are a relict from a time when everybody was nice and=20 > > cooperative, bandwith was sparse, routers used CPUs to forward packets, > > and money came from governments to research networks in huge amounts. [..] > This is the exact reason we have layering in the Internet protocols. > IPv6 routers are not meant to parse further into packets then the IPv6 he= ader (with one exception (1)). >=20 > That network devices find it hard to parse deep into user???s traffic is = a feature. > I find the argument that we should then change upper layer protocols to a= ccommodate that, hard to digest. Ole, you've worked for a vendor long enough, and understand terms like "rate limiting" and "hardware". Please. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --r4jNezHNW2wfBox+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwIAMYACgkQ31bAZeTO f8V9Dw/+L3vqQOIhczEVhu43IuNvY5xehlT8yw/feVsrpjCv5zPmsud8heR2aDvl dDEBhsbV/yNL6XJfvts5I5zEjvhCnaRUooDZgOi1xN1k/nXu8udtu5DNMwPqHsTG P/WxnR8tHTwN+xVO/7qW6TD5b74byXHmWk1zE7EEf0TUPCsP/dHd70ljMwZB+WF3 UasX3mapIO38Ks+nj9FFy/3+CdFWZoSW7RJvKsVt64+LgutdijlrORqXOIvV02YB 7G+oBFl/OFZi0oVjqGyJ4Y+j0DJOZMo/UYI9XeWQe0gbYfPJ1UprDZulrwya5Ylb hLDt18LtU+qmCeCP1nP3+A2SvsZOgRvl04RqsoGc2jUHDAQDxl4G2Ayb4aw4tbWy iP7Ynl7BtdPjASW9JtS82VKOyQ2K9lRWfzk8VtWz1X/BfJCSxdK2uKV2TH7ELPad Dbjnh49nlfBzOY5iEESTAplvbcmmC0WfP6VOUdeKFPZuI5PiZw1taclL3vpVDJjX nUD4goO050GKV7k3Zr5vpPZ/ojXDRU4AfesPV3T8O/xroQJt/KNStg+Ruo99oXNa MUQaQLdpFTqCbnJZ8izx8HDi9MuG62W0socVyeam5MlXV01KefmUmM2tvvzgf+5X huNyj1Q5cIxA40DKMRnyeQ+ipvDbmvKnKdxa5cg3+K0k3qaItuY= =hiG1 -----END PGP SIGNATURE----- --r4jNezHNW2wfBox+-- From nobody Wed Dec 5 09:10:36 2018 Return-Path: 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 C83C5130E29; Wed, 5 Dec 2018 09:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 5Tzs0S8aTLbi; Wed, 5 Dec 2018 09:10:25 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7B212DF72; Wed, 5 Dec 2018 09:10:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gUagp-00011D-8b; Wed, 05 Dec 2018 17:10:23 +0000 Date: Wed, 05 Dec 2018 09:10:22 -0800 Message-ID: From: Randy Bush To: Nick Hilliard Cc: opsec@ietf.org, IETF Rinse Repeat , tsv-art@ietf.org In-Reply-To: <9a613af3-c71e-1c30-d10a-f8a57aee3250@foobar.org> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 17:10:27 -0000 > If J Random Hacker in his mom's basement can launch an attack which > takes down your network core because your management planes can't > handle 1Tbit, or more realistically 10gbit, of HBH packets, then that > is categorically a network security issue, even if it is a secondary > effect. security failure is almost always a secondary effect. we usually do not intentionally design in specific security vulnerabilities. well, RH0 i guess; every rule has exceptions. but we don't have to knowingly add an other. perhaps there is a signal here where folk who operate the network worry about the operational consequences of ipv6 protocol purism. perhaps we have seen this before. i suspect we will see it again. > What do we do? > > 1. declare that these routers should be able to process terabits of > HBH packets (or experimental EHs because we don't know whether > experimental EHs are required to be processed HBH or by end points > only). and i presume i can print this rfc on paper and put it in the floppy drive slot of my routers and they will suddenly be able to process terabits of hbh on the slow path. cool! > 2. formally drop the requirement for intermediate routers to process > HBH headers we do not really have an actually deployable choice other than this. > 3. build routers which will take some HBH headers at low packet rates > and drop the rest (+ update rfcs to make this formally compliant). and put this into my routers' floopy slot too? we're talking EXISTING ROUTERS that are just not going to be able to make this happen. if this was an ideal world, i would focus on war, hunger, the resurgence of fascism, etc. an undeployable protocol requirement is pretty far down my priority list. randy From nobody Wed Dec 5 09:57:49 2018 Return-Path: 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 55DF8130E96; Wed, 5 Dec 2018 09:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xTJsHk6cHryL; Wed, 5 Dec 2018 09:57:32 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF4F128766; Wed, 5 Dec 2018 09:57:31 -0800 (PST) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 2CD7BFECC0AA; Wed, 5 Dec 2018 17:57:31 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 17F8DAACD84; Wed, 5 Dec 2018 18:57:29 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Ole Troan In-Reply-To: <20181205164558.GQ1543@Space.Net> Date: Wed, 5 Dec 2018 18:57:28 +0100 Cc: Joe Touch , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , David Farmer , OPSEC , tsv-art , IETF-Discussion Discussion Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 17:57:35 -0000 >>> Chained EHs are a relict from a time when everybody was nice and=20 >>> cooperative, bandwith was sparse, routers used CPUs to forward = packets, >>> and money came from governments to research networks in huge = amounts. > [..] >> This is the exact reason we have layering in the Internet protocols. >> IPv6 routers are not meant to parse further into packets then the = IPv6 header (with one exception (1)). >>=20 >> That network devices find it hard to parse deep into user???s traffic = is a feature. >> I find the argument that we should then change upper layer protocols = to accommodate that, hard to digest. >=20 > Ole, you've worked for a vendor long enough, and understand terms like > "rate limiting" and "hardware=E2=80=9D. You are creating the =E2=80=9Cperceived=E2=80=9D security problem = yourself, by requiring processing deeper into the packet than is = required. Just comply with RFC8200. As long as a router is not configured to = process any HBH options, it can ignore the header. You seem to think HBH still means =E2=80=9Cpunt to software=E2=80=9D. If = it ever meant that. There=E2=80=99s no need for rate-limiting for not processing HBH = obviously. Cheers, Ole= From nobody Wed Dec 5 10:08:33 2018 Return-Path: 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 04D35130E96; Wed, 5 Dec 2018 10:08:16 -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 CU1Oq95eX_yP; Wed, 5 Dec 2018 10:08:14 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 7D5E5128766; Wed, 5 Dec 2018 10:08:12 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id j10so20656703wru.4; Wed, 05 Dec 2018 10:08:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=S8BXuuDoXeEuholN91ngej8bnWvedut/WWaMyfqYaZc=; b=JB5pbi7VBM1P+HwoMVu+W6m+WmTxYaeDeGG+aCzd8iq4pSHXydVRAkihIk/42trJnc nP0XPsOLLAB7YaclBAjXspamFQm36Ivv/IOyOGC4nkSSg0SB4188dEbz4dwHD/yY3JPb LcpobBQrun+EgYYJmcW6fcBKW1ScYC/TS1sSGUHvH6W4QPCadgZouistf1QHHV66xMw6 1mmXx+wIo1jQeywvf1gu+UGNv8c7IdrKVdCqelYncL0FmnAU/OIbXYJ3qOHWCmfhztES 2WCgUr6zNo2QsLajs+TrSrTVNx+9eOb3eKr4eQDFPESFOlq1zanGeGyP0vbGPJS3QTHC Ev1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=S8BXuuDoXeEuholN91ngej8bnWvedut/WWaMyfqYaZc=; b=pofyq0jAgGY0zzQns1HUHYTug560Qc3CZnFeLi/tjio/tnWkOG7uYrhOi0AJJRMaVC EQdj9NXqT48AioyoxwbysT3L6LN4FQph1xNmqDYOjNOO2kcbAAuOodAg1WfbUKdxDs9P QEwNtuj9KUKHfEn3ATrOrYqUaTR8bi0d+IodbymlnIh9vC9xH/L/x5Ewa+m6NbWExdJq Qy6MOz5GnR8Z72n91itn1JHHTr0oqO/rX0ddVBkGTbWrKlKmr8ihk8t0/GaeEyueLrFW xKttn2AngG9/T9ci9arwYKnyUYjPNSwhVYWhx9gg+yecj8fsdB8YgfjVGbXV2VhqOCfA wHsg== X-Gm-Message-State: AA+aEWbQC3/beG91GJvqwyMBLzvjir08fMnO/uJ8nirIR8mDhlIIe1At pLLWPrZMRhsEV2JV4nI6glvlNyik X-Google-Smtp-Source: AFSGD/W+gVt/RBreKzZYIXXpyCR23GBQEdEZWnwU5Yhan94mvi7z6QuHOEEauYKJPtvZYWygGrachQ== X-Received: by 2002:adf:b201:: with SMTP id u1mr22782785wra.165.1544033290498; Wed, 05 Dec 2018 10:08:10 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id y9sm19776352wrq.55.2018.12.05.10.08.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 10:08:09 -0800 (PST) To: Ole Troan , Gert Doering Cc: draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , tsv-art , IETF-Discussion Discussion References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> From: Stewart Bryant Message-ID: Date: Wed, 5 Dec 2018 18:08:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 18:08:16 -0000 On 05/12/2018 17:57, Ole Troan wrote: >>>> Chained EHs are a relict from a time when everybody was nice and >>>> cooperative, bandwith was sparse, routers used CPUs to forward packets, >>>> and money came from governments to research networks in huge amounts. >> [..] >>> This is the exact reason we have layering in the Internet protocols. >>> IPv6 routers are not meant to parse further into packets then the IPv6 header (with one exception (1)). >>> >>> That network devices find it hard to parse deep into user???s traffic is a feature. >>> I find the argument that we should then change upper layer protocols to accommodate that, hard to digest. >> Ole, you've worked for a vendor long enough, and understand terms like >> "rate limiting" and "hardware”. > You are creating the “perceived” security problem yourself, by requiring processing deeper into the packet than is required. > Just comply with RFC8200. As long as a router is not configured to process any HBH options, it can ignore the header. > You seem to think HBH still means “punt to software”. If it ever meant that. > > There’s no need for rate-limiting for not processing HBH obviously. Of course it still needs to step through them all to do ECMP even if they are all disabled. Of course here it is only looking for two values (TCP or UDP). If it has to look at any it has a much more complex set of tests, or a large vector table  given the way the EH space is fragmented. Stewart > > Cheers, > Ole From nobody Wed Dec 5 10:09:08 2018 Return-Path: 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 EA9C5130F03 for ; Wed, 5 Dec 2018 10:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 CgF1d6gzzK3y for ; Wed, 5 Dec 2018 10:08:57 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8E2130F2F for ; Wed, 5 Dec 2018 10:08:57 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4CC2A41B3A for ; Wed, 5 Dec 2018 19:08:55 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 3CFA341135; Wed, 5 Dec 2018 19:08:55 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 2DACAC1A2; Wed, 5 Dec 2018 19:08:55 +0100 (CET) Date: Wed, 5 Dec 2018 19:08:55 +0100 From: Gert Doering To: Ole Troan Cc: Gert Doering , Joe Touch , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , David Farmer , OPSEC , tsv-art , IETF-Discussion Discussion Message-ID: <20181205180855.GR1543@Space.Net> References: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yxUjl2uTvAeSG6i1" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 18:09:06 -0000 --yxUjl2uTvAeSG6i1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Dec 05, 2018 at 06:57:28PM +0100, Ole Troan wrote: > You are creating the ???perceived??? security problem yourself, by requir= ing processing deeper into the packet than is required. > Just comply with RFC8200. As long as a router is not configured to proces= s any HBH options, it can ignore the header. > You seem to think HBH still means ???punt to software???. If it ever mean= t that. >=20 > There???s no need for rate-limiting for not processing HBH obviously. I *must* be able to look at the protocol field of packets coming in on our borders (see detailed description on our rate-limiting rules in=20 another mail of today). If there are EHs in the way so our routers'=20 hardware cannot decide if this is a TCP or UDP packet, these packets=20 go down the drain. And I'm fairly sure you understand that operational reality, so I'm not sure what point you are making. (It's not just HBH. EHs are fundamentally incompatible with today's reality) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --yxUjl2uTvAeSG6i1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwIFDQACgkQ31bAZeTO f8VMTRAAjkTPT9LpLWjjrwbvOOI9edJ4eEpU68zDmmEcLMbt+MVbi0zX29GtwBi/ CbsO2QIzRmgQ6aKs0quAmFVSwGg7ee7EgijkmM8Z3VwH6g3u4uVEfYAfYYxSvB+s O7JPkDb+9kcT08IszdBBkvUjmWa3PGUEwcXp8cmJs8j8jnnsys/p1qdfqZPVY19q 8fP8cesoKwn1+H79NGhG7i5h3Kz3hnBZPhtp3MPy/SyhPzDthPKWDqC8o950iknp 9iGq8uGPVtAdid6R4xsktRPHY56TTuCcn+azUQ3lvQPkFK2Clkfovd0yz22QIx9j xpQl9H8ocJCrdZHPax7OD+TC8t2dbsbG6WvgrAqW+q4qtqq6+Bobl8oMIQq/2dVH 6pkLXFRdWGYRU+Cx0KludnuybzZXvo2i8B/fHVoSD7d+zq8KElghMOWLuAUKmnuS ZYCPsQmCkOJLWzFwZHF+mcQ6pyqoNcI6+cdnpYvkS3SrNlcQJceKcLLn+0LI9DsO RSJjpPNnhJ+SVamQTs/CT2nwcnAdeN2PO6pu3GQ71nGmDwTRNJu3p9+R79UrU+kz awZROGgVLz0mH53jCkWbDSF5Q17R5kWd4Q8ls4fvb9H20VKxDz2XZaaYFiqkrz9g ibP/X2whxI6pWZMom5L3BPRS6sPAvT1arsmHiSh4J/gjD7Zt3YI= =lyZ8 -----END PGP SIGNATURE----- --yxUjl2uTvAeSG6i1-- From nobody Wed Dec 5 10:58:16 2018 Return-Path: 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 723FE130E7B; Wed, 5 Dec 2018 10:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qh2Osdlk1a2K; Wed, 5 Dec 2018 10:58:13 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0262F130E95; Wed, 5 Dec 2018 10:58:12 -0800 (PST) Received: from [192.168.10.187] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 14598FECC068; Wed, 5 Dec 2018 18:58:12 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (16B92) In-Reply-To: <20181205180855.GR1543@Space.Net> Date: Wed, 5 Dec 2018 19:58:09 +0100 Cc: Joe Touch , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , David Farmer , OPSEC , tsv-art , IETF-Discussion Discussion Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> To: Gert Doering Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 18:58:15 -0000 > On 5 Dec 2018, at 19:08, Gert Doering wrote: >=20 > Hi, >=20 >> On Wed, Dec 05, 2018 at 06:57:28PM +0100, Ole Troan wrote: >> You are creating the ???perceived??? security problem yourself, by requir= ing processing deeper into the packet than is required. >> Just comply with RFC8200. As long as a router is not configured to proces= s any HBH options, it can ignore the header. >> You seem to think HBH still means ???punt to software???. If it ever mean= t that. >>=20 >> There???s no need for rate-limiting for not processing HBH obviously. >=20 > I *must* be able to look at the protocol field of packets coming in on > our borders (see detailed description on our rate-limiting rules in=20 > another mail of today). If there are EHs in the way so our routers'=20 > hardware cannot decide if this is a TCP or UDP packet, these packets=20 > go down the drain. >=20 > And I'm fairly sure you understand that operational reality, so I'm not > sure what point you are making. >=20 > (It's not just HBH. EHs are fundamentally incompatible with today's > reality) My point is that if you are worried about the processing cost for routers of= EHs and HBH specifically, then this =E2=80=9Csecurity=E2=80=9D draft makes t= hat much worse than what=E2=80=99s specified in rfc8200.=20 Cheers=20 Ole >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael E= mmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Dec 5 11:12:29 2018 Return-Path: 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 9AA67130F59 for ; Wed, 5 Dec 2018 11:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 ttAAK2bVMcsj for ; Wed, 5 Dec 2018 11:12:11 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B026A130F1D for ; Wed, 5 Dec 2018 11:12:08 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7377B41C20 for ; Wed, 5 Dec 2018 20:12:06 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 61405418E5; Wed, 5 Dec 2018 20:12:06 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 52658C47A; Wed, 5 Dec 2018 20:12:06 +0100 (CET) Date: Wed, 5 Dec 2018 20:12:06 +0100 From: Gert Doering To: Ole Troan Cc: Gert Doering , Joe Touch , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews , David Farmer , OPSEC , tsv-art , IETF-Discussion Discussion Message-ID: <20181205191206.GT1543@Space.Net> References: <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qZVVwWJgpX9Jzs7f" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 19:12:18 -0000 --qZVVwWJgpX9Jzs7f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Dec 05, 2018 at 07:58:09PM +0100, Ole Troan wrote: > My point is that if you are worried about the processing cost for routers= of EHs and HBH specifically, then this ???security??? draft makes that muc= h worse than what???s specified in rfc8200.=20 I see. I do not particularily care about this draft, tbh, I just tried to bring insight into operational realities into the discussion. Other people are much better versed at writing nice documents that vendors can then ignore. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --qZVVwWJgpX9Jzs7f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwIIwMACgkQ31bAZeTO f8VxtA/8Dv3Sh4JRTuf5A8HfPmgNLJRPx7d/iEgygGYxirM4w9zSUZ9seORrq9LJ mRSXsU21GyXPvutp8pnjrREPjrjO5/OAducgqZOyIvapmTJe1Wwjja5GL9ATAfYs gXy0/MGbBgCX0jRGBvtux3ElexTR8He77O1H5ySSSBx6c3WZJDEAVzpoN4KSqUDk 3+E7mc1M+uzY9oKbhxD4g2eVxCLgx0QF11LAj7RHhf3cQFXpDtZzwGthWHW2+CxC KvXqp03AMUtzgU+TfMnICSxRw2NRpf0nvq6utkIyTo2kWniQa+nAWSgrB26pcQE1 l20zhwNw07ON/2LCIAg8cvMxbkUr94NUOGdY42tD0Bl9zUlyg9MdhlR/nVQe81qr 9efXuIaskJ3zcy1mdZaCf91rJQuvraFEY0I0zjWIL/pJKFgJubVKv/Y7aoGo6Wjq IJnJcZSp4q1Fai+le1PBwp8aKKKfdAM4EpknVqTfVdFZucmNYbp2zBiT6Gv4dBDM 9c1SbA4jeaibPyQqF28YRAOiTOTvSP6nk7yIXtOQoGs8wlxiolKOFPPL4hs5UOcr X2yu3/vOoLCOynsnxEI/DQCaco+6qTdVxMnT7xCztKaeT0gG7GyxKTxtjt3FaaTV i/0dLisMBqA8wLCqu1zXwWUN22uHqDYXHGN+L87mdJNOOOo8mWI= =15ql -----END PGP SIGNATURE----- --qZVVwWJgpX9Jzs7f-- From nobody Wed Dec 5 11:33:47 2018 Return-Path: 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 41164130E4C for ; Wed, 5 Dec 2018 11:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 8YbA48QOAee7 for ; Wed, 5 Dec 2018 11:33:43 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACA5128A6E for ; Wed, 5 Dec 2018 11:33:43 -0800 (PST) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx128.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gUcvT-000DM1-B4 for opsec@ietf.org; Wed, 05 Dec 2018 20:33:40 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gUcvR-0005yb-1Z for opsec@ietf.org; Wed, 05 Dec 2018 14:33:38 -0500 Received: (qmail 24070 invoked from network); 5 Dec 2018 19:26:54 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Dec 2018 19:26:53 -0000 To: Gert Doering , Ole Troan Cc: draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , tsv-art , IETF-Discussion Discussion References: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> Date: Wed, 5 Dec 2018 11:26:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <20181205180855.GR1543@Space.Net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gHoeACLL9w1v9MMHpTxXrq8TZzggQeBjd" X-Originating-IP: 168.144.250.231 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5gG8NOIzAwepgXjUM+K3YbF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO8xElEi180GZlZa73Jjp9N9Vjyn5UrUp4n4yKOOaq9Axcfz9CR/iyf94BIBhTZ9DxVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5dwmMW2Igo3slaTKxvBsN66Xe0Of4jddu9xC8 8+iQ5nb7LoaTAX7mj3bIh4FDz/DsTWjvPyjQw0UjfF+Jrlh6iu5FWD3Fo0oXNNKNfWMJhMmBaQIi fdaGzMoXcgXnOXfsRAwX31WVY5lWjWxuGSRuxURW8UvT0kUDO7BO02wlaiMJNrZqjoiSWdcjcZLv /Am2ptBB9icD2fnZzw/HNF6wGm/P3Q658NtotfOVlwP9Y9difvX7GxYM34o1TppnqMQviUSfAdJk YJaAlfzQz6q7eKBmNlijRSWQzbBZx5Si4hrQHolQlVdf0A32Xtl5FAWD8PcNYjhf2jycpxDLnRQv ahqZR3KVQgqF/fPYYAfEfsiW9oFktVPzI6hjS2b07n6nuIz4K0fzmn9MOHbNlsnl2TiMsZ03cH7d ZVPzwedpKJfFVfV8YwbQTud2ndj194c9/49qryIYbFFBOkVCXXzvNuW3bv1nPfn3AWXq7M22DtZ0 Dg9K+vwGh2YhLXUzLTJYs7W549ydvqZDiFMXDyPJeJLaHCnfs3i0UtPne0vcKpXozswVgmo2tH4W 8yU3FuMqHhq36cwsF+W74NbeI3QLqh+ZmTOlmFFbdWY+JOCoHek8CVsONrMJuGzuoGnKTKcyyDl+ Iey4xwZiQVVdRpyDl/r0x/hxBKQivuGmC/m7GOCf3MLbn7l3g+Lh7r9C5nLMhK7unSGReaJhoESb MmiSIky2ZS50wJ+lQ+LaxBNJUp6t2ykfuEOAy+YBuZa3mFPXkVWClPVvbW5lVyQanRxw5p2JYH/6 BohvTRmOq56pXi2xVeaE7wHMAOKzNxZH1vP9C0T1BLTNamueI0y1oJZKcQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 19:33:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gHoeACLL9w1v9MMHpTxXrq8TZzggQeBjd Content-Type: multipart/mixed; boundary="TWy2vJaCraJpWtQvgupWiooHNgRkQYqpU"; protected-headers="v1" From: Christian Huitema To: Gert Doering , Ole Troan Cc: draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , tsv-art , IETF-Discussion Discussion Message-ID: <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 References: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> In-Reply-To: <20181205180855.GR1543@Space.Net> --TWy2vJaCraJpWtQvgupWiooHNgRkQYqpU Content-Type: multipart/alternative; boundary="------------E146C6319ACF3944B8BFA5F3" Content-Language: en-US This is a multi-part message in MIME format. --------------E146C6319ACF3944B8BFA5F3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/5/2018 10:08 AM, Gert Doering wrote: > On Wed, Dec 05, 2018 at 06:57:28PM +0100, Ole Troan wrote: >> You are creating the ???perceived??? security problem yourself, by req= uiring processing deeper into the packet than is required. >> Just comply with RFC8200. As long as a router is not configured to pro= cess any HBH options, it can ignore the header. >> You seem to think HBH still means ???punt to software???. If it ever m= eant that. >> >> There???s no need for rate-limiting for not processing HBH obviously. > I *must* be able to look at the protocol field of packets coming in on > our borders (see detailed description on our rate-limiting rules in=20 > another mail of today). If there are EHs in the way so our routers'=20 > hardware cannot decide if this is a TCP or UDP packet, these packets=20 > go down the drain. Gert, I think that you are actually pointing at a significant issue with the draft. The draft goes into an evaluation of "security issues", without actually explaining some basic assumptions. For example, it is hard to believe that a router forwarding too many packets of any kind will cause an issue for the security *of that router*. But on the other hand there is a widely distributed practice of network equipment attempting to provide differential treatment of packets based on protocol types and port numbers. That practice is not acknowledged in the RFC that specify IPv6. In fact, the IPv6 design assumes that routers only look at the address and flow-id fields. This design is actually a departure from IPv4, whose header format makes it easy to skip over the option field and assess the "five tuple". The draft *implicitly* assumes that routers will try to find the protocol and port numbers "because of security reasons", but never actually delineates these reasons. I think the discussion would be much more productive if the draft started by explaining why network managers believe that access to the "five tuple" is essential for a variety of reasons, many of which are only tangentially related to "security". At that point we can have a discussion between protocol designers assuming that the network routers shall only look at IPv6 addresses and that everything else is end-to-end on one side, and on the other side network managers explaining why they need access to the payload type and port numbers. My personal preferences on the subject are not very relevant, and I could actually line up arguments for both sides of that debate. But I believe that getting to a resolution there would be much better than arguing piecemeal over this or that end-to-end option. -- Christian Huitema --------------E146C6319ACF3944B8BFA5F3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On 12/5/2018 10:08 AM, Gert Doering wrote:
On Wed, Dec 05, 2018 at 06:5=
7:28PM +0100, Ole Troan wrote:

You are creating the ???pe=
rceived??? security problem yourself, by requiring processing deeper into=
 the packet than is required.
Just comply with RFC8200. As long as a router is not configured to proces=
s any HBH options, it can ignore the header.
You seem to think HBH still means ???punt to software???. If it ever mean=
t that.

There???s no need for rate-limiting for not processing HBH obviously.

I =
*must* be able to look at the protocol field of packets coming in on
our borders (see detailed description on our rate-limiting rules in=20
another mail of today).  If there are EHs in the way so our routers'=20
hardware cannot decide if this is a TCP or UDP packet, these packets=20
go down the drain.

Gert, I think that you are actually pointing at a significant issue with the draft.

The draft goes into an evaluation of "security issues", without actually explaining some basic assumptions. For example, it is hard to believe that a router forwarding too many packets of any kind will cause an issue for the security *of that router*. But on the other hand there is a widely distributed practice of network equipment attempting to provide differential treatment of packets based on protocol types and port numbers. That practice is not acknowledged in the RFC that specify IPv6. In fact, the IPv6 design assumes that routers only look at the address and flow-id fields. This design is actually a departure from IPv4, whose header format makes it easy to skip over the option field and assess the "five tuple".

The draft *implicitly* assumes that routers will try to find the protocol and port numbers "because of security reasons", but never actually delineates these reasons. I think the discussion would be much more productive if the draft started by explaining why network managers believe that access to the "five tuple" is essential for a variety of reasons, many of which are only tangentially related to "security". At that point we can have a discussion between protocol designers assuming that the network routers shall only look at IPv6 addresses and that everything else is end-to-end on one side, and on the other side network managers explaining why they need access to the payload type and port numbers.

My personal preferences on the subject are not very relevant, and I could actually line up arguments for both sides of that debate. But I believe that getting to a resolution there would be much better than arguing piecemeal over this or that end-to-end option.<= /p>

-- Christian Huitema


--------------E146C6319ACF3944B8BFA5F3-- --TWy2vJaCraJpWtQvgupWiooHNgRkQYqpU-- --gHoeACLL9w1v9MMHpTxXrq8TZzggQeBjd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJcCCZ6AAoJELba05IUOHVQPbwH+QFfSvkaKW7pIfgE0k+0Awk9 Legg78YLn5kXY98AcU7DfMpP+APVKbPkhQXnSUAR8ww9PwmuQ/HvjLCeG7INpyKd DHFZPmx7/rzETEfN7eOfX+xcV33MeQOAQ3Q8EHcpP8R+3TqnKhyEp3gSh88TgrQ0 vZu4nQjl4ykQ+QnON5YX/hCY4q3Heg7tjKAnJiEtEnWEK4079/HRuZZtSCE67Wi9 Mhc+c/fJShWWFEoUHNWPAQIUz8xw6/WyW0oRfT5+rbshJoXUEcxyt2DZix4sNYat HGzNL1+0MPnAlWIImL1zbW4MZiPab9ICayVZ55ip0LQDQ+CMOeaaITSYcBLNsOc= =0HAm -----END PGP SIGNATURE----- --gHoeACLL9w1v9MMHpTxXrq8TZzggQeBjd-- From nobody Wed Dec 5 12:05:07 2018 Return-Path: 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 5518B130ED7; Wed, 5 Dec 2018 12:04:57 -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 5mq11NGaMm6Z; Wed, 5 Dec 2018 12:04:54 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 9E1BF130DF1; Wed, 5 Dec 2018 12:04:54 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id u6so10562926plm.8; Wed, 05 Dec 2018 12:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fgODihu3c8W5sSIORnhLirCOqbSuUM5I5/SIXNaZ1ZA=; b=tlBy6YdRkOS4dVn7H0dcxtz5zd9tPnHSp/f5P9r/nS/HwiRyXI/EnfBIhwTAjZCLen 49rlxgQ5bS9S79FpjE24AcZ7E/s/tcFH6uVbXm5GxHZymGTJWUzk+ukzxGg1DN7LfjIu JFmI81xEELwwLe9aPngLWwzDel7hJoPHhcoC9CM2Uu/tjxcgtUcMMmLpQQYJe70UluNf Wof+OKxMvef8+RFaq39KDJTiWw0pztvCkRAmeGUhz88WjGs09WEZlJepkp9p10HDHkA1 zM5lde9GK5g+yEXOloFL7rwuQjLuD8TOzu9oJfsUb95sxQ3gF2d7nJ9HPjIdPg/+rCpn 1pbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fgODihu3c8W5sSIORnhLirCOqbSuUM5I5/SIXNaZ1ZA=; b=fa2Xowwy0SsBJ5Ev442nbMfNLfwmTdjDKjxhtFLQqbf/FGxrQTSBa6J8dUG0RWKs59 LKnlTzrTUjy7O+2gLl34TGgfR/zUOMUAuufJsT/3lCgJknqwZziBiKMIs7YzbuTBFg/U 7wOV4SfatqD5WpirNvPD3Gnm9EgVz35BUcReSYd4xI0JHZRPSrtQo2ajymZbkEbGvx4L 8PNbLFfeeS9UvNI+wNjalNBo23Njmbbi3IRJD/H1QrF7o4lhv4qFhIIvU1Np+dKyVmNt fPDOBcDUkEF91DAUFrct9dY0Z0xXypL6c4jyebUd5G/BEhNKDQeVJsrsMqRm0Fq3GPJc FTJg== X-Gm-Message-State: AA+aEWZBqxbdA0ZozrKTTyE9xm+iAnyt5rzCVpIlx5n6OJRIzkcm3KIU nwEaaWl9trzhATkpOq0wJc/nBtI+3b8= X-Google-Smtp-Source: AFSGD/V5B5hnnv7C5DUdJYFFTcfFNq0qCYVUC3EmzMZpas6hNCvdk9D+azVWUbwRPvTMipFC7b7Kwg== X-Received: by 2002:a17:902:6185:: with SMTP id u5mr25360244plj.194.1544040293827; Wed, 05 Dec 2018 12:04:53 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id p6sm27411558pfn.53.2018.12.05.12.04.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 12:04:53 -0800 (PST) To: Joe Touch Cc: Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> From: Brian E Carpenter Message-ID: Date: Thu, 6 Dec 2018 09:04:48 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 20:04:58 -0000 On 2018-12-06 01:16, Joe Touch wrote: >=20 >=20 > On Dec 4, 2018, at 8:46 PM, Brian E Carpenter wrote: >=20 >>> Nobody deprecated the flags that require HBH options to be processed = or dropped if not supported.=20 >> >> Intentionally. If a forwarding node is transparent to HbH options, >> it is not looking at those flags. If it is looking at HbH options, >> it will obey those flags. Why is that a problem? >=20 > What exactly does =E2=80=98transparent to HbH options mean=E2=80=99 if = not =E2=80=98not supported=E2=80=99? It means a forwarding node that uses the exception added by RFC7045 and s= imply doesn't even look for an HbH header. The flag bits are invisible and irre= levant to such a node. The flag bits apply as defined for a forwarding node that= *does* process HbH options, so they certainly should not be deprecated. Brian >=20 > In that case, the flags have exactly no meaning anywhere. But they=E2=80= =99re not deprecated. >=20 > That makes no sense at all. >=20 > Joe > . >=20 From nobody Wed Dec 5 14:51:04 2018 Return-Path: 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 D3243130E14; Wed, 5 Dec 2018 14:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=strayalpha.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 AjUNEFjfiCLn; Wed, 5 Dec 2018 14:51:00 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77409130E03; Wed, 5 Dec 2018 14:51:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=A0qFJ4XdGu/BpRoEp1IOsSmTDc9kgzby6gSjWD1sm8E=; b=xwVcdI1/jB2EGXR9aTejEcdH9 rMTRbb2KC5Dac32KGvjfUmCqe+IjRQ/1GaQtuWVdkQ/s+k4IbA8oQOWCG/w3tCjh9Jjz7Tn++sH4T iOtYAzEztBw/65Crco63Vaz0PnxM/J9ZhSB9vrZVoy7nEbA1RX8/5iqRFcHPaynTypW+Ir1rAScxn qB7E/WcyvHiN0JKnaNDsw8LHj+9X6pwxF0+Rh+0p/B9nWdY//WAaVQ1b1KXzJncSWyvsxLtHg68g3 zvlH6GSF/rMAdP1gQ3g5ufaHaWjUIAaFIxxstk7zy9LHf5JTn8A4p7/Quby1iV/HcLcDG8tli/L+D QZW8zkqdw==; Received: from [172.58.21.134] (port=60197 helo=[IPv6:2607:fb90:5ab9:34a3:a5d1:5453:14c2:db03]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUg0R-00443K-9p; Wed, 05 Dec 2018 17:50:59 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Wed, 5 Dec 2018 14:50:58 -0800 Cc: Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> To: Brian E Carpenter X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 22:51:02 -0000 > On Dec 5, 2018, at 12:04 PM, Brian E Carpenter wrote: >=20 >> On 2018-12-06 01:16, Joe Touch wrote: >>=20 >>=20 >> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter wrote: >>=20 >>>> Nobody deprecated the flags that require HBH options to be processed or= dropped if not supported.=20 >>>=20 >>> Intentionally. If a forwarding node is transparent to HbH options, >>> it is not looking at those flags. If it is looking at HbH options, >>> it will obey those flags. Why is that a problem? >>=20 >> What exactly does =E2=80=98transparent to HbH options mean=E2=80=99 if no= t =E2=80=98not supported=E2=80=99? >=20 > It means a forwarding node that uses the exception added by RFC7045 and si= mply > doesn't even look for an HbH header. The flag bits are invisible and irrel= evant > to such a node. The flag bits apply as defined for a forwarding node that *= does* > process HbH options, so they certainly should not be deprecated Do why bother with =E2=80=9Cdrop if not supported=E2=80=9D if not supported c= an mean silently skipped over? Or the other variants? They=E2=80=99re now meaningless but required to support. You don=E2=80=99t s= ee the contradiction? >=20 > Brian >=20 >>=20 >> In that case, the flags have exactly no meaning anywhere. But they=E2=80=99= re not deprecated. >>=20 >> That makes no sense at all. >>=20 >> Joe >> . >>=20 >=20 From nobody Wed Dec 5 14:53:59 2018 Return-Path: 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 A9D6E12E043; Wed, 5 Dec 2018 14:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Z_z38roF3_RW; Wed, 5 Dec 2018 14:53:56 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F0B126CC7; Wed, 5 Dec 2018 14:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WseRQi3ZrUYqdhH2IQ+PugMGS+r/UVBNt4Ppt9TQyks=; b=sGQy2cjyBVgnYdNw8nqiFIZ3t 5QF28l9vF5S2mdEgNtvNw9/LJEImXxWASDptN5Ps5fAQMhBvb36dTQDccDP30SlpLgoonH7OzFmeX JEbG+F3Li/e4OqKkOYIRps2VyfVk18wBVxlvCQJ6j/6cl7FvA0Pv9O3l1LP5gEfdbmosSiwq/Tng9 YoYSgjKCLy9xi8DCJZ5v9NvLy114rTj+hbH1DGdc4WoIE4eNV93fEZt1rdUho26wZ4xOTxS12ZYSg kSVAqS0W+yQ8hy3ixz526LGtxOEjeJAvS2gk0q1EUcile9X6qrzbQIGiTf1qpsHngFJYisWI4mCrO L9jX+R0VQ==; Received: from [172.58.21.134] (port=51373 helo=[IPv6:2607:fb90:5ab9:34a3:a5d1:5453:14c2:db03]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUg3F-00469p-Nt; Wed, 05 Dec 2018 17:53:54 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-2AAC2CF4-9C55-4B04-8064-E774515AE534 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> Date: Wed, 5 Dec 2018 14:53:52 -0800 Cc: Gert Doering , Ole Troan , tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <38262252-AECF-427E-9216-3732C9973BFB@strayalpha.com> References: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> To: Christian Huitema X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 22:53:58 -0000 --Apple-Mail-2AAC2CF4-9C55-4B04-8064-E774515AE534 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 > On Dec 5, 2018, at 11:26 AM, Christian Huitema wrote= : >=20 >=20 >> On 12/5/2018 10:08 AM, Gert Doering wrote: >>> On Wed, Dec 05, 2018 at 06:57:28PM +0100, Ole Troan wrote: >>> You are creating the ???perceived??? security problem yourself, by requi= ring processing deeper into the packet than is required. >>> Just comply with RFC8200. As long as a router is not configured to proce= ss any HBH options, it can ignore the header. >>> You seem to think HBH still means ???punt to software???. If it ever mea= nt that. >>>=20 >>> There???s no need for rate-limiting for not processing HBH obviously. >> I *must* be able to look at the protocol field of packets coming in on >> our borders (see detailed description on our rate-limiting rules in=20 >> another mail of today). If there are EHs in the way so our routers'=20 >> hardware cannot decide if this is a TCP or UDP packet, these packets=20 >> go down the drain. > Gert, I think that you are actually pointing at a significant issue with t= he draft.=20 >=20 > The draft goes into an evaluation of "security issues", without actually e= xplaining some basic assumptions. For example, it is hard to believe that a r= outer forwarding too many packets of any kind will cause an issue for the se= curity *of that router*. But on the other hand there is a widely distributed= practice of network equipment attempting to provide differential treatment o= f packets based on protocol types and port numbers. That practice is not ack= nowledged in the RFC that specify IPv6. In fact, the IPv6 design assumes tha= t routers only look at the address and flow-id fields. This design is actual= ly a departure from IPv4, whose header format makes it easy to skip ov= er the option field and assess the "five tuple". >=20 > The draft *implicitly* assumes that routers will try to find the protocol a= nd port numbers "because of security reasons", but never actually delineates= these reasons. I think the discussion would be much more productive if the d= raft started by explaining why network managers believe that access to the "= five tuple" is essential for a variety of reasons, many of which are only ta= ngentially related to "security". At that point we can have a discussion bet= ween protocol designers assuming that the network routers shall only look at= IPv6 addresses and that everything else is end-to-end on one side, and on t= he other side network managers explaining why they need access to the payloa= d type and port numbers. >=20 > My personal preferences on the subject are not very relevant, and I could a= ctually line up arguments for both sides of that debate. But I believe that g= etting to a resolution there would be much better than arguing piecemeal ove= r this or that end-to-end option. >=20 > -- Christian Huitema >=20 >=20 >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art --Apple-Mail-2AAC2CF4-9C55-4B04-8064-E774515AE534 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
+1

On Dec 5, 2018, at 11:26 AM, Christian Huitema <huitema@huitema.net> wrote:


On 12/5/2018 10:08 AM, Gert Doering wrote:
On Wed, Dec 05, 2018 at 06:57:28PM +0100, Ole Troan wrote:

You are creating the ???perceived??? security problem yourself, by requiring processing deeper into the packet than is required.
Just comply with RFC8200. As long as a router is not configured to process any HBH options, it can ignore the header.
You seem to think HBH still means ???punt to software???. If it ever meant that.

There???s no need for rate-limiting for not processing HBH obviously.

I *must* be able to look at the protocol field of packets coming in on
our borders (see detailed description on our rate-limiting rules in 
another mail of today).  If there are EHs in the way so our routers' 
hardware cannot decide if this is a TCP or UDP packet, these packets 
go down the drain.

Gert, I think that you are actually pointing at a significant issue with the draft.

The draft goes into an evaluation of "security issues", without actually explaining some basic assumptions. For example, it is hard to believe that a router forwarding too many packets of any kind will cause an issue for the security *of that router*. But on the other hand there is a widely distributed practice of network equipment attempting to provide differential treatment of packets based on protocol types and port numbers. That practice is not acknowledged in the RFC that specify IPv6. In fact, the IPv6 design assumes that routers only look at the address and flow-id fields. This design is actually a departure from IPv4, whose header format makes it easy to skip over the option field and assess the "five tuple".

The draft *implicitly* assumes that routers will try to find the protocol and port numbers "because of security reasons", but never actually delineates these reasons. I think the discussion would be much more productive if the draft started by explaining why network managers believe that access to the "five tuple" is essential for a variety of reasons, many of which are only tangentially related to "security". At that point we can have a discussion between protocol designers assuming that the network routers shall only look at IPv6 addresses and that everything else is end-to-end on one side, and on the other side network managers explaining why they need access to the payload type and port numbers.

My personal preferences on the subject are not very relevant, and I could actually line up arguments for both sides of that debate. But I believe that getting to a resolution there would be much better than arguing piecemeal over this or that end-to-end option.

-- Christian Huitema


_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art
--Apple-Mail-2AAC2CF4-9C55-4B04-8064-E774515AE534-- From nobody Wed Dec 5 16:05:45 2018 Return-Path: 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 5DC77130E73; Wed, 5 Dec 2018 16:05:30 -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 lmlmKbxmmIeH; Wed, 5 Dec 2018 16:05:27 -0800 (PST) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 75F13130E51; Wed, 5 Dec 2018 16:05:27 -0800 (PST) Received: by mail-pg1-x543.google.com with SMTP id s198so9783460pgs.2; Wed, 05 Dec 2018 16:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mzW91bh7J8Yg9VKRfUgXWwe8dWciIeDLbBJarYaDyw4=; b=vgWxlCkJ2WyONLxszIUG52KFFuTFFbrmi8xPwJ1HP25iJQA/cR4khXj6wLvfqIt0hS 0pLYpO2ZOg8n35zDqr1r8+Okghd6tNwdowrJJGk/+mDaG3uT7cbMGJS7KbdV1ZXp4Z/w RzjW+rBPF3OV84qCzXnhz5nTWYkoqldZk9rmPcvbYDgVU0lZBnVGNc4FxaxuKS3peX0I kLcmZeGxVF95h8/weGWD0EI8JiFwjXoqqU4608m5qCC+Z0AzUeRjI3bL+Xzxe5Bxl3KS NJ+oOqhSTwVAD0C40sJBi7eH/HxFeUTMKqZf3pMs2fTJWUvhIcqgFgyGoMHN0TMhe17U kkGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mzW91bh7J8Yg9VKRfUgXWwe8dWciIeDLbBJarYaDyw4=; b=gzcYFruj216tMDkV5MPluemX/YQr9NuNoi1upDOaFVLaOQAqpWYwSDjykIM0oS+1Km fF8hfROr7S8is+nG21kpwOzeeKIjZmV5z+9G8oAwn7IYIWd6ZsVkxuTPw5cxHFIsk54J PYX2Pf1JBnVEabfXOI19SHLIlwlNrfZRdCmY9mPQA7Cqr4BW2Z/jH1wr3Qh0aWHAYW66 JDRH5seDHUhlbmOOTvlrh6fenlKPnXl8EbrZEkyLKEgw+KIMFBeCRnPf/799yKoYbEof 46vJDAh5NCnUs1+z2TYbKYsg0QGR3wCCIzulXr21UU/w6jQIsq5yA2sCQkx4gctEsYHR k3sQ== X-Gm-Message-State: AA+aEWYY/MOFoB75bzKKrFEfUQp9pP6HNQx2H634VnUb414KOVCMfxdP hITYbA7paGTbZGieZejiW+2SWRgXbvA= X-Google-Smtp-Source: AFSGD/Ur50KHsEY9jPj48J+CCKGEdherJU7r3jOh2a6CeEIcjB1IR3ZqSrKpM2O9/2SEgQxqIOowmw== X-Received: by 2002:a63:4745:: with SMTP id w5mr22783380pgk.377.1544054726695; Wed, 05 Dec 2018 16:05:26 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id o8sm52262561pfa.42.2018.12.05.16.05.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 16:05:25 -0800 (PST) To: Joe Touch Cc: Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> From: Brian E Carpenter Message-ID: <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> Date: Thu, 6 Dec 2018 13:05:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 00:05:31 -0000 On 2018-12-06 11:50, Joe Touch wrote: >=20 >=20 >> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter wrote: >> >>> On 2018-12-06 01:16, Joe Touch wrote: >>> >>> >>> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter wrote: >>> >>>>> Nobody deprecated the flags that require HBH options to be processe= d or dropped if not supported.=20 >>>> >>>> Intentionally. If a forwarding node is transparent to HbH options, >>>> it is not looking at those flags. If it is looking at HbH options, >>>> it will obey those flags. Why is that a problem? >>> >>> What exactly does =E2=80=98transparent to HbH options mean=E2=80=99 i= f not =E2=80=98not supported=E2=80=99? >> >> It means a forwarding node that uses the exception added by RFC7045 an= d simply >> doesn't even look for an HbH header. The flag bits are invisible and i= rrelevant >> to such a node. The flag bits apply as defined for a forwarding node t= hat *does* >> process HbH options, so they certainly should not be deprecated >=20 > Do why bother with =E2=80=9Cdrop if not supported=E2=80=9D if not suppo= rted can mean silently skipped over? Ah. I assume that you are not referring to RFC7045 + RFC8200 (the standar= ds) but to https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#= section-3.4.1.5 , which is quite nuanced. All I can say is that *if* we a= re going to issue guidance for security-based filtering of HbH headers, t= hat advice seems realistic. It does include this: ... Finally, when packets containing a HBH Options EH are processed in the slow-path, and the underlying platform does not have any mitigation options available for attacks based on these packets, we recommend that such platforms discard packets containing IPv6 HBH Options EHs. Frankly I don't think you'd find any operational security practitioner wh= o disagrees with this. Whether we *should* issue guidance for security-based filtering of HbH he= aders is a broader question. All I would say is that if we don't, then ei= ther somebody else will, or default-deny will remain as the most common p= ractice. Brian =20 > Or the other variants? >=20 > They=E2=80=99re now meaningless but required to support. You don=E2=80=99= t see the contradiction? >=20 >=20 >> >> Brian >> >>> >>> In that case, the flags have exactly no meaning anywhere. But they=E2= =80=99re not deprecated. >>> >>> That makes no sense at all. >>> >>> Joe >>> . >>> >> >=20 >=20 From nobody Wed Dec 5 16:15:11 2018 Return-Path: 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 F17B5130E14; Wed, 5 Dec 2018 16:15:04 -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 h7DtwsjdovIm; Wed, 5 Dec 2018 16:15:03 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 301BD12426E; Wed, 5 Dec 2018 16:15:01 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id b5so10866292plr.4; Wed, 05 Dec 2018 16:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uYLF2pBR0RcCmyy7MTS7QoOlRRFmBdxEJtBkHjBTIdw=; b=K2gPgXeXSgm7o/YTHyiZ65Y5V2vyRK9v5ni2+Kxzpms0Xfzee3LzEaY23Sgf18XDTs 1TwsZ78P8QfWZBnWY0sCE8+em8YEIuKb4DzhK7/rQnP5rba3f0Usrf1VrGaisWZiA4xB 1zdfRb75/Q5NBEwdpOEvSSW0mtnHCCyzK9JHC7K283KuvG3iKPVQgV1+k3W3Re4MnK5c X9wvmiyPeRc4N2NmrG73evsbJs63x314+cJ/5Br25Dcx+SrrcJ8O9aw9XOubfRdOSfop 6xD4Su0SxKtihiWlfrIoKIW/x5TT3GGI0eZlkX8VVdEkbUhD/DrKhrmQ4N1bfqvsdmyE xNnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uYLF2pBR0RcCmyy7MTS7QoOlRRFmBdxEJtBkHjBTIdw=; b=c3yqtnE82WjPUBCDGoHj11MP3VLsy47iTh6/qBPGkKf1w2H4px7veSZ71O5q+zUloT hC96M7MXvF5WgtAtkeWXiVsuQEU599cv30fgYoTchgxdkVattKyrMiwLEMi+1kP9sEpx qnoQxdM0be2FSlRcMLJVGOi3lfa+kFzU8ixv9w4O3HyeGxXCJ4gU35aCAjgAFd+XFd9y YvYKsx8+hoUkwLJsj1D0FV0cpGbIoEiswcL5KNhpVY8Tznp5cam/uwU5KYr/F3nGZ1b1 8phpKktS4XGBj7Y3dNfALE7HXYDDIw0QwDRlPsBvBr0EG+APa7+txo539M2sA22Jns+G Mn1g== X-Gm-Message-State: AA+aEWYUCNZUAHEruExdAmAB5JA/ObqpqBUg4Js7LbAWZyRkfqlfw1Ia nuzv/e8D84yKLCHWbZBZ3qKFogCygo0= X-Google-Smtp-Source: AFSGD/XXQY97BOxLNVSsHZ4ZSFCkRmf2hyjZVh077SumqsSJgDqeXK6/fGOr8BdHQoeN1QRs80jW4Q== X-Received: by 2002:a17:902:9a02:: with SMTP id v2mr26802366plp.180.1544055300561; Wed, 05 Dec 2018 16:15:00 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id i73sm39027676pfi.66.2018.12.05.16.14.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 16:14:59 -0800 (PST) To: Gert Doering , Christopher Morrow Cc: heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <20181205085227.GG1543@Space.Net> From: Brian E Carpenter Message-ID: <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> Date: Thu, 6 Dec 2018 13:14:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <20181205085227.GG1543@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 00:15:05 -0000 On 2018-12-05 21:52, Gert Doering wrote: > Hi, > > On Tue, Dec 04, 2018 at 10:57:43PM -0500, Christopher Morrow wrote: >> HA! ok. As gert/nick noted ... we have Nx100G links today (at the edge) and >> coming nx400G ... there's just not a reasonable story for "dpi" there. (I >> suppose: "yet" and "without paying the approximate value Coca-Cola >> Companies yearly advertising budget") > > Indeed. > > Unfortunately, there *is* a story for being able to rate-limit incoming > crap by protocol type - "give me no more than 200 Mbit/s of UDP packets > coming from source port 53". > > Which implies that as soon as the evil guys out there find a way to > generate DDoS streams carrying EHs that our border routers will (have to) > apply very strict rate limiting to everything they do not understand. > > - pass TCP > - rate-limit UDP on well-known reflective attacks port > - pass rest of UDP > - rate-limit ICMP > - rate-limit fragments > - rate-limit all the rest to something which can never exceed a customer's > access-link > > game over, EH Just to point out that this is equivalent to saying "game over, any new layer 4 protocol" too. For example, you just killed SCTP. And the same goes for new protocols over IPv4. Brian > (We're not doing this today, because as of today, "volume DDoS" comes in > without EHs [except fragment] - but this is just a matter of time) > > Gert Doering > -- NetMaster > From nobody Wed Dec 5 16:17:42 2018 Return-Path: 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 99ECE12426E; Wed, 5 Dec 2018 16:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=strayalpha.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 3eUJrwzUSHNN; Wed, 5 Dec 2018 16:17:36 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F10124BE5; Wed, 5 Dec 2018 16:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=S9m5IfeheqMr2hi5OXDB5wMuHUaZBq9N+NrWwGqTjSE=; b=mjWZ1MP5WpOm98hR3JCN0SIHR be+oSgiCcINi1OrIXboHnrf3VlM1L1XGhBSlXP92xBGkspcHVtnl7Xt5nxZBt4ELE2u8RMtGjpTBn 4BGneXRBcqxP1RmTDFtnCrmAmPPqwyA4Tb/DSk+bAyAALTL8W2pwQJe5rNbAjD5dSkspLJvixdGXA DPFEQoTv/ie30laVB7Was5mCbKPqY0bdeuveh5+ptB9Y4OiShBlREctLzJN+jO5iCsEsd6VcFQjJU wpBycHiv3VB7kWbdKGjd3S8cDDshDGa64eXIyd0esUZSH3GWZmMqTnKlGa8WKd5V+5bkRCcH3KHM3 F9s2eeYQQ==; Received: from [172.58.21.134] (port=28513 helo=[IPv6:2607:fb90:5ab9:34a3:a5d1:5453:14c2:db03]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUhMD-000v1p-HZ; Wed, 05 Dec 2018 19:17:36 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> Date: Wed, 5 Dec 2018 16:17:32 -0800 Cc: Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail. com> To: Brian E Carpenter X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 00:17:40 -0000 I am referring to the standards. They=E2=80=99re in direct conflict.=20 > On Dec 5, 2018, at 4:05 PM, Brian E Carpenter wrote: >=20 >> On 2018-12-06 11:50, Joe Touch wrote: >>=20 >>=20 >>>> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter wrote: >>>>=20 >>>> On 2018-12-06 01:16, Joe Touch wrote: >>>>=20 >>>>=20 >>>> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter wrote: >>>>=20 >>>>>> Nobody deprecated the flags that require HBH options to be processed o= r dropped if not supported.=20 >>>>>=20 >>>>> Intentionally. If a forwarding node is transparent to HbH options, >>>>> it is not looking at those flags. If it is looking at HbH options, >>>>> it will obey those flags. Why is that a problem? >>>>=20 >>>> What exactly does =E2=80=98transparent to HbH options mean=E2=80=99 if n= ot =E2=80=98not supported=E2=80=99? >>>=20 >>> It means a forwarding node that uses the exception added by RFC7045 and s= imply >>> doesn't even look for an HbH header. The flag bits are invisible and irr= elevant >>> to such a node. The flag bits apply as defined for a forwarding node tha= t *does* >>> process HbH options, so they certainly should not be deprecated >>=20 >> Do why bother with =E2=80=9Cdrop if not supported=E2=80=9D if not support= ed can mean silently skipped over? >=20 > Ah. I assume that you are not referring to RFC7045 + RFC8200 (the standard= s) > but to https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#s= ection-3.4.1.5 , which is quite nuanced. All I can say is that *if* we are g= oing to issue guidance for security-based filtering of HbH headers, that adv= ice seems realistic. It does include this: > ... Finally, when > packets containing a HBH Options EH are processed in the slow-path, > and the underlying platform does not have any mitigation options > available for attacks based on these packets, we recommend that such > platforms discard packets containing IPv6 HBH Options EHs. > Frankly I don't think you'd find any operational security practitioner who= disagrees with this. >=20 > Whether we *should* issue guidance for security-based filtering of HbH hea= ders is a broader question. All I would say is that if we don't, then either= somebody else will, or default-deny will remain as the most common practice= . >=20 > Brian >=20 >> Or the other variants? >>=20 >> They=E2=80=99re now meaningless but required to support. You don=E2=80=99= t see the contradiction? >>=20 >>=20 >>>=20 >>> Brian >>>=20 >>>>=20 >>>> In that case, the flags have exactly no meaning anywhere. But they=E2=80= =99re not deprecated. >>>>=20 >>>> That makes no sense at all. >>>>=20 >>>> Joe >>>> . >>>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Wed Dec 5 16:34:46 2018 Return-Path: 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 A5999130DC8; Wed, 5 Dec 2018 16:34:44 -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 zT0Ks8f_3jX9; Wed, 5 Dec 2018 16:34:42 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 C4B1E127332; Wed, 5 Dec 2018 16:34:41 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id k8so10871901pls.11; Wed, 05 Dec 2018 16:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=x7y/LO2ZdOIF7LTihtC5RpjTLAmIQRdYHHgHdcRD0zU=; b=ptfeqzb+YmcvsWBadKflHKOStOJbnAY48fjpNbwY6nu/qiL44EH+ZoP2kGmVgdU8JZ LxMh4pHhjqJrjF0fWZcrwSeaxTDOyUdVajkaYs/YaaA9DHGcKmkZfCtNtNjnS6wxtTCH u4XTp7yLCaTDr6CIkUtQk32Rus38nYf2uYZEEVdfykSbm1K1dx4XDm7dJLvbyPkRCL6h Oy88+AICa+iZNZVTy8etNva2syNUzReTF1R5kVlQdB+Bs3+JdtkHqZilQn7rxwlssxV1 AQqH1RclUEzimUICHNpRoaErnm2vzehqBbJ1ZYQnhVB39Ip2hQ2cjXGWjV5d0U+Gv5cH AunQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=x7y/LO2ZdOIF7LTihtC5RpjTLAmIQRdYHHgHdcRD0zU=; b=YrXGLmQAAtDuvixvGYCXsh26kR/4ZgeWh0AN15NTrinfTbKZU2mGSJyevv8EJ3aLIt 9Cn1uiONtvmDcHj43QSvT7vNjSUX7XQzgw0/6hXBXcafVfat3oBPOrPLcKu4/Uz+YTQl ZUnEupvnVrjwv0oPnww/ozAj6i5Nbj9Mr0rvJKOtI4nAOZWtMkfvWAPdiClvaDl5ec5z qUDNjRTExNKxrs4Pi6b8wRX20Z8oWBg+1Ln3GbmNKlvlzmzlRaDpCarXWcNWOl+hVrw9 40w1EQePW3aCVgpxrX5YUOjaahmtFMWSrrdq8qbp3Cg6x9xVMdvR52yVtEIO/eU4fXsB 76cg== X-Gm-Message-State: AA+aEWYtmR9y4lQGFjxOJ1wi2zsi7v2/1UHh0BZ89VNihY3XQN5xTIbr /9PNH4l2LwO74Egutc8rI0FLt/uNsWY= X-Google-Smtp-Source: AFSGD/XkACAiWWnU1f4f6+M23kaZI/Cg2XmvnncCz7SfImylaUGARBXt+lgT8K9HPSRYVZYgxSXkDg== X-Received: by 2002:a17:902:5a0b:: with SMTP id q11mr26535707pli.186.1544056480986; Wed, 05 Dec 2018 16:34:40 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id r12sm21297432pgv.83.2018.12.05.16.34.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 16:34:40 -0800 (PST) To: Stewart Bryant , Ole Troan , Gert Doering Cc: tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> From: Brian E Carpenter Message-ID: Date: Thu, 6 Dec 2018 13:34:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 00:34:45 -0000 On 2018-12-06 07:08, Stewart Bryant wrote: >=20 >=20 > On 05/12/2018 17:57, Ole Troan wrote: >>>>> Chained EHs are a relict from a time when everybody was nice and >>>>> cooperative, bandwith was sparse, routers used CPUs to forward pack= ets, >>>>> and money came from governments to research networks in huge amount= s. >>> [..] >>>> This is the exact reason we have layering in the Internet protocols.= >>>> IPv6 routers are not meant to parse further into packets then the IP= v6 header (with one exception (1)). >>>> >>>> That network devices find it hard to parse deep into user???s traffi= c is a feature. >>>> I find the argument that we should then change upper layer protocols= to accommodate that, hard to digest. >>> Ole, you've worked for a vendor long enough, and understand terms lik= e >>> "rate limiting" and "hardware=E2=80=9D. >> You are creating the =E2=80=9Cperceived=E2=80=9D security problem your= self, by requiring processing deeper into the packet than is required. >> Just comply with RFC8200. As long as a router is not configured to pro= cess any HBH options, it can ignore the header. >> You seem to think HBH still means =E2=80=9Cpunt to software=E2=80=9D. = If it ever meant that. >> >> There=E2=80=99s no need for rate-limiting for not processing HBH obvio= usly. > Of course it still needs to step through them all to do ECMP even if=20 > they are all disabled.=20 No it doesn't. That's what the flow label, in a fixed position early in t= he IPv6 header, is for. A line speed IPv6 router has no need to look at t= he layer 4 header, even if it's doing both diffserv and ECMP. Looking at = transport headers is an IPv4 concept. The topic here is not really IPv6 routers. It's devices whose job in life= includes filtering. They might also be routers. > Of course here it is only looking for two values=20 > (TCP or UDP). You too just killed SCTP ;-) > If it has to look at any it has a much more complex set of tests, or a = > large vector table=C2=A0 given the way the EH space is fragmented. Frankly doing it without a network processor seems wrong. You can't expec= t an ASIC or FPGA based device to handle the EH structures. Brian From nobody Wed Dec 5 16:38:47 2018 Return-Path: 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 8BBE412D4E8; Wed, 5 Dec 2018 16:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 yYb8C41wdfEl; Wed, 5 Dec 2018 16:38:31 -0800 (PST) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (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 5F462127332; Wed, 5 Dec 2018 16:38:31 -0800 (PST) Received: by mail-pl1-x644.google.com with SMTP id 101so10886976pld.6; Wed, 05 Dec 2018 16:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=y1OowR8S3FpesTwEfhb2l3zWISBFv/VIWBT4OohucqI=; b=puzaDBtP/E596g6QWHQdYOKAKDKEm9RX6ye9ldHdCb/YGIT4TawQR69w5v92MmXh4o xOF3TD6bzPBQ/1A9sM5KLbqQkjSwe/lLUKrVPyj7hQ2kVJkquyefoT5VOCIMEeDxgPVL oq+9Ip/bUEPWICyrFCMTKGZo9+Fzjh5WgoZhXw9I76ZhavTOKHRRG48R7bThldo8eRow aW6F67QD1CuQJRkbb2xixFW+Inx0k6LR8lQ5ZdffQIKDHCoqLkGuTRj577P9m48OwLCN ZBPCULTv9XP9LLsTNcGnHrT1uQmQDK1s6MtcPqs+u2Ajw+2fLSI7KJsyRcJBfbuEPq0j m2QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=y1OowR8S3FpesTwEfhb2l3zWISBFv/VIWBT4OohucqI=; b=qTZ0zETYRe+NADd2PjPVJ8kLRpB4/yw8sQ3pUyX42YgQ42DS9gzGW2vQ3IyVx9dfgM iMy+zGhOTRNjjejwfnxdrROTgmLSzNpzKoFNky4Ign2uG01dbakYmjKV8ackVv+BU8Uv I5oP6qED+Sfa4ikgL1FXKs5y3O2n4LJNSnMXyQ6kl4apUyJaZCmi89JOf7CBq3LR3ZxI FgcqkliO0fGp+CODfCyngz3xLgdAIFw7zwOXvpsixeCf73haQEFjC5Uk22DRZtxceaVi E05gWlfSBFW/PigfLThV8nbYWIfE0/bDoYKkm52dFhCfesjuPDntpxfzmhfbHiT2dSAO t6zg== X-Gm-Message-State: AA+aEWYLl7cio1+NSaWwIy5hSfC5yAGegrWoX+jf6nlzzyaDfGFbYsm/ 5IT/RGvYzTvDlliR8FfX13oTUyS3uXM= X-Google-Smtp-Source: AFSGD/XrYCxepKkoAvmRYe6MAhaICS6eCVLqfs9If/h8+sJbgGC0nA6D3xAtxghTneP145Prr7t3hA== X-Received: by 2002:a17:902:5ac2:: with SMTP id g2mr26283502plm.313.1544056710670; Wed, 05 Dec 2018 16:38:30 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id q75sm41836892pfa.38.2018.12.05.16.38.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 16:38:30 -0800 (PST) To: Joe Touch Cc: Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> From: Brian E Carpenter Message-ID: <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> Date: Thu, 6 Dec 2018 13:38:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 00:38:37 -0000 On 2018-12-06 13:17, Joe Touch wrote: > I am referring to the standards. They=E2=80=99re in direct conflict.=20 I see no conflict between RFC8200 and RFC7045. RFC2460 is obsolete, so it= doesn't matter. Brian >=20 >> On Dec 5, 2018, at 4:05 PM, Brian E Carpenter wrote: >> >>> On 2018-12-06 11:50, Joe Touch wrote: >>> >>> >>>>> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter wrote: >>>>> >>>>> On 2018-12-06 01:16, Joe Touch wrote: >>>>> >>>>> >>>>> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter wrote: >>>>> >>>>>>> Nobody deprecated the flags that require HBH options to be proces= sed or dropped if not supported.=20 >>>>>> >>>>>> Intentionally. If a forwarding node is transparent to HbH options,= >>>>>> it is not looking at those flags. If it is looking at HbH options,= >>>>>> it will obey those flags. Why is that a problem? >>>>> >>>>> What exactly does =E2=80=98transparent to HbH options mean=E2=80=99= if not =E2=80=98not supported=E2=80=99? >>>> >>>> It means a forwarding node that uses the exception added by RFC7045 = and simply >>>> doesn't even look for an HbH header. The flag bits are invisible and= irrelevant >>>> to such a node. The flag bits apply as defined for a forwarding node= that *does* >>>> process HbH options, so they certainly should not be deprecated >>> >>> Do why bother with =E2=80=9Cdrop if not supported=E2=80=9D if not sup= ported can mean silently skipped over? >> >> Ah. I assume that you are not referring to RFC7045 + RFC8200 (the stan= dards) >> but to https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-= 06#section-3.4.1.5 , which is quite nuanced. All I can say is that *if* w= e are going to issue guidance for security-based filtering of HbH headers= , that advice seems realistic. It does include this: >> ... Finally, when >> packets containing a HBH Options EH are processed in the slow-path, >> and the underlying platform does not have any mitigation options >> available for attacks based on these packets, we recommend that such= >> platforms discard packets containing IPv6 HBH Options EHs. >> Frankly I don't think you'd find any operational security practitioner= who disagrees with this. >> >> Whether we *should* issue guidance for security-based filtering of HbH= headers is a broader question. All I would say is that if we don't, then= either somebody else will, or default-deny will remain as the most commo= n practice. >> >> Brian >> >>> Or the other variants? >>> >>> They=E2=80=99re now meaningless but required to support. You don=E2=80= =99t see the contradiction? >>> >>> >>>> >>>> Brian >>>> >>>>> >>>>> In that case, the flags have exactly no meaning anywhere. But they=E2= =80=99re not deprecated. >>>>> >>>>> That makes no sense at all. >>>>> >>>>> Joe >>>>> . >>>>> >>>> >>> >>> >> >=20 >=20 From nobody Wed Dec 5 16:39:01 2018 Return-Path: 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 9B466130F0F; Wed, 5 Dec 2018 16:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 17ArjKiHl_ET; Wed, 5 Dec 2018 16:38:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EB56130F33; Wed, 5 Dec 2018 16:38:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 20F9BBE2C; Thu, 6 Dec 2018 00:38:41 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf9vToAOJXrj; Thu, 6 Dec 2018 00:38:35 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D6D21BDCF; Thu, 6 Dec 2018 00:38:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1544056715; bh=QLoYoZorjxKSI5jAB6D8/SjYCmBSbUo4gkT3gXLk5jU=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=KdRHnHN0H194AeCwbD51ESN8BTn2uo28gNG8Pn5xKIqy7nP1DrQ2oiwxYGqdXx9Jf Wr6q2Vs6Q3b1q84BjWTzwX0yj6MTz1t4OQ0gvpvLfvxivE7vzpONPCGa84BgrQlLYQ 9Za78GMbsdj8Y/jlOChDK94Dywqv7UedCDHjSOYk= To: Brian E Carpenter , Gert Doering , Christopher Morrow Cc: heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <3b26c94a-b3cc-94c7-a891-b0ab6a81237d@cs.tcd.ie> Date: Thu, 6 Dec 2018 00:38:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fP0ukr3xtLquaz3yWVgbsB3EJWFhof8HK" Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 00:38:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fP0ukr3xtLquaz3yWVgbsB3EJWFhof8HK Content-Type: multipart/mixed; boundary="LKJv5KeySYFrbVgBFJ5hozdWhjylkXpOh"; protected-headers="v1" From: Stephen Farrell To: Brian E Carpenter , Gert Doering , Christopher Morrow Cc: heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-ID: <3b26c94a-b3cc-94c7-a891-b0ab6a81237d@cs.tcd.ie> Subject: Re: game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> In-Reply-To: <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> --LKJv5KeySYFrbVgBFJ5hozdWhjylkXpOh Content-Type: multipart/mixed; boundary="------------748A84F5421963901497F814" Content-Language: en-GB This is a multi-part message in MIME format. --------------748A84F5421963901497F814 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 06/12/2018 00:14, Brian E Carpenter wrote: > Just to point out that this is equivalent to saying "game over, any > new layer 4 protocol" too. For example, you just killed SCTP. And the > same goes for new protocols over IPv4. Well, there is port 443 and quic etc. While I don't have a position in the discussion so far, it does seem to validate the proposition that encrypting as a counter to ossification is a valid (but not the only valid) argument. Interestingly, this discussion could be read to imply that encrypting transports like quic may better support higher throughput networks with fast-path routers (where anything other than fast-path is basically /dev/null) by taking some models of DPI off the table. That somewhat sharply contrasts with arguments against such encrypting transports that I've seen offered by operators. I'm not claiming this is a winning argument, nor anything like one, but perhaps noteworthy. Cheers, S. --------------748A84F5421963901497F814 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------748A84F5421963901497F814-- --LKJv5KeySYFrbVgBFJ5hozdWhjylkXpOh-- --fP0ukr3xtLquaz3yWVgbsB3EJWFhof8HK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlwIb4kACgkQWrL68XsX K+o7chAAtL/qUU+D/EX6ZMxOKYKiMS/Gdzilbawdb69MwYTBP21oiz+h+BhaeNnS /v9RYO+V0csnmWAGM5VKETpYWuz+HihDRl3SnC7IDS14gYv+tG69WwV4yPfPtD6N Ii1mdi8LFOeXhE9LfLaN8Dq5uuE89qo3+kyAZ3n6KCxwPl6ijGq4fL0CR3P2D1wn WZjteY8CwxU2tV9M8iOszjUvbEo7NgRsCd0auuWtnPCFAvsaj6qvrulyNoM+U1lK cyk/UTAT1kURprnS2CpoeICkDqS3y223Vl4MqFoZ4GaEF+D+MJAq0lOiT81c+hp2 O7RcVFbfdenQ4KhHJXx0lwV6rMraydFZsiAsVNZfND8sT0Z4sJRMjpTaC59NDHvf rXyL7NSmpZY1XdbXgfI7gD59qg5FSVT8HlVRIJLS/d/94lSqo0eORQL0VzxvmUVk ibEGqVMUD+Fe/UlrJSj52/U5Xcutl9BQdfUe4czvGgtgeGc+bXMoGDMnD+IypPTa qCuUQ9XFXf2f8k+g76tKdDkIaW9l2nH96NmmymoJfAzPDdIEyOdk658K4QZuirt3 9pxzEhTNzVDISVbYMR6GkryXRPX3cJDUxWpqodfR1WbFcsan0DY2OiAUZZwJHL2l f3zM8wGnj4GYQ9JFhAAncYp9S8wK66PktV6CYgQnUUw2ncgXFBQ= =djZ7 -----END PGP SIGNATURE----- --fP0ukr3xtLquaz3yWVgbsB3EJWFhof8HK-- From nobody Wed Dec 5 16:48:41 2018 Return-Path: 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 F108612F295; Wed, 5 Dec 2018 16:48:38 -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 LV21XiNytfCD; Wed, 5 Dec 2018 16:48:36 -0800 (PST) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 996EB12D4E8; Wed, 5 Dec 2018 16:48:36 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id 64so10852989pfr.9; Wed, 05 Dec 2018 16:48:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pvl2Q1/9QABDtgXH1xAO1emPsdMw5eekMd2/mtZPTCE=; b=C8ijBUL0/5xtus42ldGvGsXd0iD8ffGxiccCsYQQaqMQ4ZWasJfuuBbC1HEYoK7fPS GJuPubZmIPa5EvfNSGizkERhBfOzG9V/cCIw8bVKYbaFiNeXabzFuCyVJgzjOZNXArAa PAkREHVZui/6TXkHm3fk++bgJgMj3iG39qOG3B842243H06Imdd2QdG92r9N+7VMsZmc IvpgvqMMT81Ub7orsXw7VZKVXPWCRQDgiYlw3qxfmdRRpjFPy06aTK57D8ZANvw4F2Ip lMmUZONP2FjWwvcawY1BBsTgc37XHjrbnbWQ6E/8eO1Yne03+vWCIWL2rpFP5xli7DBK OT/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pvl2Q1/9QABDtgXH1xAO1emPsdMw5eekMd2/mtZPTCE=; b=VcVTkJNdUONooXCPEybcoQ+2V2Y2cutmpAqM/Ll0fd2CxUvWiroWjxzYGQmqSRJpOr P0He5LPr9AWYwDWK5PxpaXrEdPom8LVstza61zTgqdRmSgCOban3EAE5jSxv3QT4V44s Kr+TVpGnhtR1x/FlqlFD6rZYT7t3fORJ8F4jcpPXBMy40TYefUbeY3WT1Fo9vdfT+jty nwPQAVw6CHG2d+4jSnQ+rzFIAEcql3wYMjajHxMxHlwDp0zWio1cvgLBtnW5WIuRS/RX G2B38VlqSW/C7EsGrjwD7QzASiZAi7OQi7He+W2EJbfm9VDDcXr4b+Xx/426X+/Ub5if w6+g== X-Gm-Message-State: AA+aEWZIOm2fo9EdUTtCUoLIoHpoDAEWtLMXrpq93o/8vQbxDHjPYyqB 7PgttYMGeLg0/uFcgE4lGsOu2MxJmQU= X-Google-Smtp-Source: AFSGD/Uz+5Fu6hgkoTkPk9x/Hl6EyoG5NdqfHsgd7urwbgfBS96sMaV2K2gfGk+o81+DrakPK40amQ== X-Received: by 2002:a65:6094:: with SMTP id t20mr22061068pgu.285.1544057315774; Wed, 05 Dec 2018 16:48:35 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id p2sm27022755pfb.28.2018.12.05.16.48.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 16:48:34 -0800 (PST) To: Christian Huitema , Gert Doering , Ole Troan Cc: tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> From: Brian E Carpenter Message-ID: Date: Thu, 6 Dec 2018 13:48:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 00:48:39 -0000 On 2018-12-06 08:26, Christian Huitema wrote: > > On 12/5/2018 10:08 AM, Gert Doering wrote: >> On Wed, Dec 05, 2018 at 06:57:28PM +0100, Ole Troan wrote: >>> You are creating the ???perceived??? security problem yourself, by requiring processing deeper into the packet than is required. >>> Just comply with RFC8200. As long as a router is not configured to process any HBH options, it can ignore the header. >>> You seem to think HBH still means ???punt to software???. If it ever meant that. >>> >>> There???s no need for rate-limiting for not processing HBH obviously. >> I *must* be able to look at the protocol field of packets coming in on >> our borders (see detailed description on our rate-limiting rules in >> another mail of today). If there are EHs in the way so our routers' >> hardware cannot decide if this is a TCP or UDP packet, these packets >> go down the drain. > > Gert, I think that you are actually pointing at a significant issue with > the draft. > > The draft goes into an evaluation of "security issues", without actually > explaining some basic assumptions. For example, it is hard to believe > that a router forwarding too many packets of any kind will cause an > issue for the security *of that router*. But on the other hand there is > a widely distributed practice of network equipment attempting to provide > differential treatment of packets based on protocol types and port > numbers. That practice is not acknowledged in the RFC that specify IPv6. > In fact, the IPv6 design assumes that routers only look at the address > and flow-id fields. This design is actually a departure from IPv4, whose > header format makes it easy to skip over the option field and assess the > "five tuple". And I don't think that is an oversight. The *definition* of "router" for IPv6 is "a node that forwards IPv6 packets not explicitly addressed to itself." No mention of filtering, classification, admission control,... > The draft *implicitly* assumes that routers will try to find the > protocol and port numbers "because of security reasons", but never > actually delineates these reasons. I think the discussion would be much > more productive if the draft started by explaining why network managers > believe that access to the "five tuple" is essential for a variety of > reasons, many of which are only tangentially related to "security". At > that point we can have a discussion between protocol designers assuming > that the network routers shall only look at IPv6 addresses and that > everything else is end-to-end on one side, and on the other side network > managers explaining why they need access to the payload type and port > numbers. That seems to define a class of "routers" that have supplementary functions that are not part of routing. And, surprise, these functions cannot be satisfied by only inspecting the first 40 bytes of the packet. I agree that this could usefully be made very clear in the draft. > My personal preferences on the subject are not very relevant, and I > could actually line up arguments for both sides of that debate. But I > believe that getting to a resolution there would be much better than > arguing piecemeal over this or that end-to-end option. I doubt that we can ever resolve this, but we can document it. Brian From nobody Wed Dec 5 18:45:52 2018 Return-Path: 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 983C8130F79; Wed, 5 Dec 2018 18:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 7f0M3wQx2mdj; Wed, 5 Dec 2018 18:45:38 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABAF130F82; Wed, 5 Dec 2018 18:45:38 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4] (unknown [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 610E28268A; Thu, 6 Dec 2018 03:45:31 +0100 (CET) To: Mark Andrews , Christopher Morrow Cc: Joe Touch , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <4661966d-c260-4552-0512-20e41ab6c64f@si6networks.com> Date: Wed, 5 Dec 2018 23:06:29 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 02:45:44 -0000 On 5/12/18 03:14, Mark Andrews wrote: >> sure, that's a fine point. Doesn't actually change the state of the world where: "If your control-plane collapses, you have an unavailability event" which is a security problem. It's also an operational problem and likely a cost problem :( but... maintaining availability is part of what a good isp security group will do for the isp. > > And the correct thing to do is to FIX THE BROKEN PRODUCT. > > If a ssh implementation is broken we don’t drop SSH packets. We fix the broken implementation of ssh. > > If there is a SQL injection problem we fix that problem rather than dropping HTTP > and HTTPS packets. Bad analogy there. If you are vulnerable to SQL injection problems, you just stop trasting whatever crap is being sent to your app, and enforce checks on the input, usually based on what you'd expect or what one might consider "sane". -- some extremists might call some of that a deviation from "be liberal in what you accept". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Dec 5 18:46:14 2018 Return-Path: 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 89C74130FC2; Wed, 5 Dec 2018 18:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 Vf5d-a_uXfQE; Wed, 5 Dec 2018 18:45:44 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A58130F82; Wed, 5 Dec 2018 18:45:43 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4] (unknown [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7A42280EF4; Thu, 6 Dec 2018 03:45:39 +0100 (CET) To: Brian E Carpenter , Gert Doering , Christopher Morrow Cc: heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Wed, 5 Dec 2018 23:37:56 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 02:45:57 -0000 On 5/12/18 21:14, Brian E Carpenter wrote: > On 2018-12-05 21:52, Gert Doering wrote: >> Hi, >> >> On Tue, Dec 04, 2018 at 10:57:43PM -0500, Christopher Morrow wrote: >>> HA! ok. As gert/nick noted ... we have Nx100G links today (at the edge) and >>> coming nx400G ... there's just not a reasonable story for "dpi" there. (I >>> suppose: "yet" and "without paying the approximate value Coca-Cola >>> Companies yearly advertising budget") >> >> Indeed. >> >> Unfortunately, there *is* a story for being able to rate-limit incoming >> crap by protocol type - "give me no more than 200 Mbit/s of UDP packets >> coming from source port 53". >> >> Which implies that as soon as the evil guys out there find a way to >> generate DDoS streams carrying EHs that our border routers will (have to) >> apply very strict rate limiting to everything they do not understand. >> >> - pass TCP >> - rate-limit UDP on well-known reflective attacks port >> - pass rest of UDP >> - rate-limit ICMP >> - rate-limit fragments >> - rate-limit all the rest to something which can never exceed a customer's >> access-link >> >> game over, EH > > Just to point out that this is equivalent to saying "game over, any new layer 4 protocol" too. For example, you just killed SCTP. And the same goes for new protocols over IPv4. Not exactly the same. If you are using a new transport protocols (*) without any EHs, you have already found the upper-layer protocol. May allow or drop, but that's it. With EHs, if you need to do packet filtering or ECMP, you need to follow the EH chain.The later (particularly if the EH) is normally going to cause issues, where the former would not. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Dec 5 19:52:48 2018 Return-Path: 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 75DD1130DE0; Wed, 5 Dec 2018 19:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tIg_-L_T9LDF; Wed, 5 Dec 2018 19:52:28 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DFE130DF5; Wed, 5 Dec 2018 19:52:27 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4] (unknown [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E45748254C; Thu, 6 Dec 2018 04:52:22 +0100 (CET) To: Christian Huitema , Gert Doering , Ole Troan Cc: draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , tsv-art , IETF-Discussion Discussion References: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Thu, 6 Dec 2018 00:33:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 03:52:34 -0000 On 5/12/18 16:26, Christian Huitema wrote: > > On 12/5/2018 10:08 AM, Gert Doering wrote: >> On Wed, Dec 05, 2018 at 06:57:28PM +0100, Ole Troan wrote: >>> You are creating the ???perceived??? security problem yourself, by requiring processing deeper into the packet than is required. >>> Just comply with RFC8200. As long as a router is not configured to process any HBH options, it can ignore the header. >>> You seem to think HBH still means ???punt to software???. If it ever meant that. >>> >>> There???s no need for rate-limiting for not processing HBH obviously. >> I *must* be able to look at the protocol field of packets coming in on >> our borders (see detailed description on our rate-limiting rules in >> another mail of today). If there are EHs in the way so our routers' >> hardware cannot decide if this is a TCP or UDP packet, these packets >> go down the drain. > > Gert, I think that you are actually pointing at a significant issue with > the draft. > > The draft goes into an evaluation of "security issues", without actually > explaining some basic assumptions. For example, it is hard to believe > that a router forwarding too many packets of any kind will cause an > issue for the security *of that router*. But on the other hand there is > a widely distributed practice of network equipment attempting to provide > differential treatment of packets based on protocol types and port > numbers. That practice is not acknowledged in the RFC that specify IPv6. > In fact, the IPv6 design assumes that routers only look at the address > and flow-id fields. This design is actually a departure from IPv4, whose > header format makes it easy to skip over the option field and assess the > "five tuple". > > The draft *implicitly* assumes that routers will try to find the > protocol and port numbers "because of security reasons", but never > actually delineates these reasons. I think the discussion would be much > more productive if the draft started by explaining why network managers > believe that access to the "five tuple" is essential for a variety of > reasons, many of which are only tangentially related to "security". At > that point we can have a discussion between protocol designers assuming > that the network routers shall only look at IPv6 addresses and that > everything else is end-to-end on one side, and on the other side network > managers explaining why they need access to the payload type and port > numbers. We did that in gont-v6ops-ipv6-ehs-packet-drops, but I agree that that is not explicitly mentioned in the document. I wouldn't rehash the I-D here, but simply note something along the lines of: ---- cut here ---- While not strictly part of the functionality in of a router, it is a common practice for network equipment attempting to provide differential treatment of packets based on protocol types and port, for reasons such as: o ECMP and Hash-based Load-Sharing o Enforcing infrastructure ACLs o DDoS Management and Customer Requests for Filtering While the IPv6 standard assumes that routers only look at the address flow-id fields, the aforementioned operational requirements results in the aforementioned devices having to parse the IPv6 extension header chain. In such scenarios, extension headers poses a challenge to these devices, which have implementation limits in the lengths of the extension chains they are able to process, or the performance with which they can process the EH chains. In that sense, the IPv6 design is actually a departure from IPv4, whose header format makes it easy to skip over the option field and assess the "five tuple". [gont-v6ops-ipv6-ehs-packet-drops] contains further discussion of these issues. ---- cut here ---- Thoughts? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Dec 5 20:11:53 2018 Return-Path: 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 8A94D130DF5; Wed, 5 Dec 2018 20:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 acXcLr25x8Mi; Wed, 5 Dec 2018 20:11:46 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DC5130DBE; Wed, 5 Dec 2018 20:11:46 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4] (unknown [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3FC7F8268A; Thu, 6 Dec 2018 05:11:41 +0100 (CET) From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== To: "'ietf@ietf.org'" Cc: "'opsec@ietf.org'" , opsec chairs Message-ID: <5be1f097-68f0-f41a-3c42-e92c437551ff@si6networks.com> Date: Thu, 6 Dec 2018 01:08:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSEC] FYI: DDoS defences in the terabit era: Pre-deployed filters, future initiatives (draft-ietf-opsec-ipv6-eh-filtering= X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 04:11:51 -0000 Folks, This was posted today: https://blog.apnic.net/2018/12/06/ddos-defences-in-the-terabit-era-pre-deployed-filters-future-initiatives/ Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Dec 5 20:57:51 2018 Return-Path: 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 0E81D131023; Wed, 5 Dec 2018 20:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=strayalpha.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 Ox-UXzYNbjSS; Wed, 5 Dec 2018 20:57:38 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB528131021; Wed, 5 Dec 2018 20:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ihUvZ5RkfxzFdWjwy1dsNojF8JsCyahjDcQ09WWRwjY=; b=zAq1ohHsfVqoECaolPWMt8deX Hb80HSBHk3SUE0J5PRFQX/XI8qsR/LWzObCqOHQX5DexfAEYVxlYZ9bxOI8CztFZMZfVPYY6Ia7SR jVR9j5pDZv497n20raHxXEdz5fR4xyzxQ8d828fRw35BkU9JCcmLhkJTf7hMnAqBQZvEAhWfkX74j N4GDAa9Zc4qKU+QnVco2ksq1D1sV5te0RqigASxweHA3v9FVvNOsyLG22ZTryQEfe6mbmKxzLV63y 3jQp1moq8KhScZph7kMqk1YdF1UwYYjRsbon0JRLmxxBOvnKEV+0TGmXClc4ZVMVyKR2mDaPRqRQ2 SDa6sIgyQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53867 helo=[192.168.1.179]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUljD-000buZ-Mz; Wed, 05 Dec 2018 23:57:38 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> Date: Wed, 5 Dec 2018 20:57:22 -0800 Cc: Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a 43bfdcb@gmail.com> To: Brian E Carpenter X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 04:57:43 -0000 Then explain what it means to mark an EH as =E2=80=98drop if not supported=E2= =80=99 if it isn=E2=80=99t dropped where - well - NOT SUPPORTED. Or ICMP where not supported.=20 Or any of those values.=20 I=E2=80=99m talking about a conflict in the text of 8200 - which has those f= ields as required to support - and 7045, which says they can be silently ign= ored.=20 > On Dec 5, 2018, at 4:38 PM, Brian E Carpenter wrote: >=20 >> On 2018-12-06 13:17, Joe Touch wrote: >> I am referring to the standards. They=E2=80=99re in direct conflict.=20 >=20 > I see no conflict between RFC8200 and RFC7045. RFC2460 is obsolete, so it d= oesn't matter. >=20 > Brian >=20 >>=20 >>>> On Dec 5, 2018, at 4:05 PM, Brian E Carpenter wrote: >>>>=20 >>>> On 2018-12-06 11:50, Joe Touch wrote: >>>>=20 >>>>=20 >>>>>> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter wrote: >>>>>>=20 >>>>>> On 2018-12-06 01:16, Joe Touch wrote: >>>>>>=20 >>>>>>=20 >>>>>> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter wrote: >>>>>>=20 >>>>>>>> Nobody deprecated the flags that require HBH options to be processe= d or dropped if not supported.=20 >>>>>>>=20 >>>>>>> Intentionally. If a forwarding node is transparent to HbH options, >>>>>>> it is not looking at those flags. If it is looking at HbH options, >>>>>>> it will obey those flags. Why is that a problem? >>>>>>=20 >>>>>> What exactly does =E2=80=98transparent to HbH options mean=E2=80=99 i= f not =E2=80=98not supported=E2=80=99? >>>>>=20 >>>>> It means a forwarding node that uses the exception added by RFC7045 an= d simply >>>>> doesn't even look for an HbH header. The flag bits are invisible and i= rrelevant >>>>> to such a node. The flag bits apply as defined for a forwarding node t= hat *does* >>>>> process HbH options, so they certainly should not be deprecated >>>>=20 >>>> Do why bother with =E2=80=9Cdrop if not supported=E2=80=9D if not suppo= rted can mean silently skipped over? >>>=20 >>> Ah. I assume that you are not referring to RFC7045 + RFC8200 (the standa= rds) >>> but to https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06= #section-3.4.1.5 , which is quite nuanced. All I can say is that *if* we are= going to issue guidance for security-based filtering of HbH headers, that a= dvice seems realistic. It does include this: >>> ... Finally, when >>> packets containing a HBH Options EH are processed in the slow-path, >>> and the underlying platform does not have any mitigation options >>> available for attacks based on these packets, we recommend that such >>> platforms discard packets containing IPv6 HBH Options EHs. >>> Frankly I don't think you'd find any operational security practitioner w= ho disagrees with this. >>>=20 >>> Whether we *should* issue guidance for security-based filtering of HbH h= eaders is a broader question. All I would say is that if we don't, then eith= er somebody else will, or default-deny will remain as the most common practi= ce. >>>=20 >>> Brian >>>=20 >>>> Or the other variants? >>>>=20 >>>> They=E2=80=99re now meaningless but required to support. You don=E2=80=99= t see the contradiction? >>>>=20 >>>>=20 >>>>>=20 >>>>> Brian >>>>>=20 >>>>>>=20 >>>>>> In that case, the flags have exactly no meaning anywhere. But they=E2= =80=99re not deprecated. >>>>>>=20 >>>>>> That makes no sense at all. >>>>>>=20 >>>>>> Joe >>>>>> . >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Wed Dec 5 21:02:27 2018 Return-Path: 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 B247E131027; Wed, 5 Dec 2018 21:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 tW0MbceWKkGX; Wed, 5 Dec 2018 21:02:07 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 E1CA9131021; Wed, 5 Dec 2018 21:02:06 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id c9so23980107itj.1; Wed, 05 Dec 2018 21:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iP53YQxm40zioBz/TBywQnpLfZqcTKwbzlKLkAUOGws=; b=ZBpP/t37XS+sXO+DftJ2f4UtOWC/0zvNb2tDd14GsN0QfZ3D/nlDwvmNWzwe4sfaNp W6KXjC4OnsmOSa83OFDj5x4OgNi9nc3CqTlnaUmvsf9Lbjhxg5J47PUg6wR2dp67BeqB zb82eh2Ee7VPal4XifdR50O6jqwCFc7FhjisUgNbjp15rBbog9sy6VditBzf2GM8Wpga YVAA6M0+ILIxmb7dw+bB5sTF3PNyniEcIY9ML1GoDlcTz6ekJe9kbqamtIcO3OFt4t97 GSOop+D3A70820ijWm+utyVuU4DO+4F5ylqoqsLnETRzmP/eA3AURuMXnFPzjcFBbDtu X0HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iP53YQxm40zioBz/TBywQnpLfZqcTKwbzlKLkAUOGws=; b=WSZ2FQX+dyIdo5hO8tgYXiYYuEPgl+NiAKwAsXapUmSN5lwXeLDX9eGu/zXDmTL6TM XEu6UfCI8ogSiemXeQUi7cgCr+tCuMeAKEvW5ClCPN6QLzzwqh3GGqwEkQF2RpBzWmTq Pbz2XfsoQj5IjJXUX8n5uyrADGv6LEFNVzgCvR4234Iy6XTAhRyPlXyn9ElAhtUYAUFE X/KqCyZfg792AoD2X94dnUy5wRnkqDrBe6OfusKTcrGVlyjLi+9S5tURuCjQK0f6C6sh A1lP5VoXddSclArF4jcGlYHZbgoy2L38iH1/rJwt7/5jY+E0du8KYHHqJabADKoo3nhR 02bA== X-Gm-Message-State: AA+aEWYxtU6eDRu8774A6Zcb8BcI/DS+DIz7IHyps4/yixkk2svGvMPG ZaRRSNM8JDeZbf28T7QR5UR/jEXsHvqmcF6J4d0= X-Google-Smtp-Source: AFSGD/V/8PBj3nBWwCzmnZXOx5RNWavXRZJu1QnT/eS7meFicncMl/cbWxFcmVUDXV9368O5+p6igax0kQUMC+eVpuk= X-Received: by 2002:a24:32c5:: with SMTP id j188mr17468825ita.139.1544072526078; Wed, 05 Dec 2018 21:02:06 -0800 (PST) MIME-Version: 1.0 References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> In-Reply-To: <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> From: Christopher Morrow Date: Thu, 6 Dec 2018 00:01:55 -0500 Message-ID: To: Joe Touch Cc: Brian E Carpenter , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org Content-Type: multipart/alternative; boundary="0000000000006ca947057c536622" Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 05:02:13 -0000 --0000000000006ca947057c536622 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 5, 2018 at 11:57 PM Joe Touch wrote: > Then explain what it means to mark an EH as =E2=80=98drop if not supporte= d=E2=80=99 if it > isn=E2=80=99t dropped where - well - NOT SUPPORTED. > > Or ICMP where not supported. > > Or any of those values. > > I=E2=80=99m talking about a conflict in the text of 8200 - which has thos= e fields > as required to support - and 7045, which says they can be silently ignore= d. > > How is it, for example, different to put ipv6 packets into an MPLS path doing nothing along 'many' hops (except forwarding the packets along), and then once you pop out of the tunnel start processing the packet as you (joe) would want. Versus just ignoring the offensive EHs along the same path outside of MPLS and then dealing with them after you pop out the last router in the chain? In my mind this is what Brian (and me and apparently 8200) are proposing: "edge site sends packet with offensive header(s) to ISP, ISP ignores EHs and forwards across (potentially many) routers/as-hops and far end edge site gets the packet and parses EHs to it's hearts content." > > On Dec 5, 2018, at 4:38 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > >> On 2018-12-06 13:17, Joe Touch wrote: > >> I am referring to the standards. They=E2=80=99re in direct conflict. > > > > I see no conflict between RFC8200 and RFC7045. RFC2460 is obsolete, so > it doesn't matter. > > > > Brian > > > >> > >>>> On Dec 5, 2018, at 4:05 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>>> > >>>> On 2018-12-06 11:50, Joe Touch wrote: > >>>> > >>>> > >>>>>> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>>>>> > >>>>>> On 2018-12-06 01:16, Joe Touch wrote: > >>>>>> > >>>>>> > >>>>>> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>>>>> > >>>>>>>> Nobody deprecated the flags that require HBH options to be > processed or dropped if not supported. > >>>>>>> > >>>>>>> Intentionally. If a forwarding node is transparent to HbH options= , > >>>>>>> it is not looking at those flags. If it is looking at HbH options= , > >>>>>>> it will obey those flags. Why is that a problem? > >>>>>> > >>>>>> What exactly does =E2=80=98transparent to HbH options mean=E2=80= =99 if not =E2=80=98not > supported=E2=80=99? > >>>>> > >>>>> It means a forwarding node that uses the exception added by RFC7045 > and simply > >>>>> doesn't even look for an HbH header. The flag bits are invisible an= d > irrelevant > >>>>> to such a node. The flag bits apply as defined for a forwarding nod= e > that *does* > >>>>> process HbH options, so they certainly should not be deprecated > >>>> > >>>> Do why bother with =E2=80=9Cdrop if not supported=E2=80=9D if not su= pported can mean > silently skipped over? > >>> > >>> Ah. I assume that you are not referring to RFC7045 + RFC8200 (the > standards) > >>> but to > https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section= -3.4.1.5 > , which is quite nuanced. All I can say is that *if* we are going to issu= e > guidance for security-based filtering of HbH headers, that advice seems > realistic. It does include this: > >>> ... Finally, when > >>> packets containing a HBH Options EH are processed in the slow-path, > >>> and the underlying platform does not have any mitigation options > >>> available for attacks based on these packets, we recommend that such > >>> platforms discard packets containing IPv6 HBH Options EHs. > >>> Frankly I don't think you'd find any operational security practitione= r > who disagrees with this. > >>> > >>> Whether we *should* issue guidance for security-based filtering of Hb= H > headers is a broader question. All I would say is that if we don't, then > either somebody else will, or default-deny will remain as the most common > practice. > >>> > >>> Brian > >>> > >>>> Or the other variants? > >>>> > >>>> They=E2=80=99re now meaningless but required to support. You don=E2= =80=99t see the > contradiction? > >>>> > >>>> > >>>>> > >>>>> Brian > >>>>> > >>>>>> > >>>>>> In that case, the flags have exactly no meaning anywhere. But > they=E2=80=99re not deprecated. > >>>>>> > >>>>>> That makes no sense at all. > >>>>>> > >>>>>> Joe > >>>>>> . > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >> > > > > --0000000000006ca947057c536622 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Dec 5, 2018 at 11:57 PM Joe Touch <touch@strayalpha.com> wrote:
Then explain what it means to mark an EH as =E2=80=98drop if not supp= orted=E2=80=99 if it isn=E2=80=99t dropped where - well - NOT SUPPORTED.
Or ICMP where not supported.

Or any of those values.

I=E2=80=99m talking about a conflict in the text of 8200 - which has those = fields as required to support - and 7045, which says they can be silently i= gnored.


How is it, for example, different to p= ut ipv6 packets into an MPLS path doing nothing along 'many' hops (= except forwarding the packets along), and then once you pop out of the tunn= el start processing the packet as you (joe) would want.

Versus just ignoring the offensive EHs along the same path outside of= MPLS and then dealing with them after you pop out the last router in the c= hain?

In my mind this is what Brian (and me and ap= parently 8200) are proposing: "edge site sends packet with offensive h= eader(s) to ISP, ISP ignores EHs and forwards across (potentially many) rou= ters/as-hops and far end edge site gets the packet and parses EHs to it'= ;s hearts content."
=C2=A0
> On Dec 5, 2018, at 4:38 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
>> On 2018-12-06 13:17, Joe Touch wrote:
>> I am referring to the standards. They=E2=80=99re in direct conflic= t.
>
> I see no conflict between RFC8200 and RFC7045. RFC2460 is obsolete, so= it doesn't matter.
>
>=C2=A0 =C2=A0 Brian
>
>>
>>>> On Dec 5, 2018, at 4:05 PM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
>>>>
>>>> On 2018-12-06 11:50, Joe Touch wrote:
>>>>
>>>>
>>>>>> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter <= ;brian.e.c= arpenter@gmail.com> wrote:
>>>>>>
>>>>>> On 2018-12-06 01:16, Joe Touch wrote:
>>>>>>
>>>>>>
>>>>>> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter <= brian.e.ca= rpenter@gmail.com> wrote:
>>>>>>
>>>>>>>> Nobody deprecated the flags that require H= BH options to be processed or dropped if not supported.
>>>>>>>
>>>>>>> Intentionally. If a forwarding node is transpa= rent to HbH options,
>>>>>>> it is not looking at those flags. If it is loo= king at HbH options,
>>>>>>> it will obey those flags. Why is that a proble= m?
>>>>>>
>>>>>> What exactly does =E2=80=98transparent to HbH opti= ons mean=E2=80=99 if not =E2=80=98not supported=E2=80=99?
>>>>>
>>>>> It means a forwarding node that uses the exception add= ed by RFC7045 and simply
>>>>> doesn't even look for an HbH header. The flag bits= are invisible and irrelevant
>>>>> to such a node. The flag bits apply as defined for a f= orwarding node that *does*
>>>>> process HbH options, so they certainly should not be d= eprecated
>>>>
>>>> Do why bother with =E2=80=9Cdrop if not supported=E2=80=9D= if not supported can mean silently skipped over?
>>>
>>> Ah. I assume that you are not referring to RFC7045 + RFC8200 (= the standards)
>>> but to https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-= 3.4.1.5 , which is quite nuanced. All I can say is that *if* we are goi= ng to issue guidance for security-based filtering of HbH headers, that advi= ce seems realistic. It does include this:
>>>=C2=A0 ...=C2=A0 Finally, when
>>>=C2=A0 packets containing a HBH Options EH are processed in the= slow-path,
>>>=C2=A0 and the underlying platform does not have any mitigation= options
>>>=C2=A0 available for attacks based on these packets, we recomme= nd that such
>>>=C2=A0 platforms discard packets containing IPv6 HBH Options EH= s.
>>> Frankly I don't think you'd find any operational secur= ity practitioner who disagrees with this.
>>>
>>> Whether we *should* issue guidance for security-based filterin= g of HbH headers is a broader question. All I would say is that if we don&#= 39;t, then either somebody else will, or default-deny will remain as the mo= st common practice.
>>>
>>> Brian
>>>
>>>> Or the other variants?
>>>>
>>>> They=E2=80=99re now meaningless but required to support. Y= ou don=E2=80=99t see the contradiction?
>>>>
>>>>
>>>>>
>>>>> Brian
>>>>>
>>>>>>
>>>>>> In that case, the flags have exactly no meaning an= ywhere. But they=E2=80=99re not deprecated.
>>>>>>
>>>>>> That makes no sense at all.
>>>>>>
>>>>>> Joe
>>>>>> .
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

--0000000000006ca947057c536622-- From nobody Wed Dec 5 21:22:27 2018 Return-Path: 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 E471C131027; Wed, 5 Dec 2018 21:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=strayalpha.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 LRPzPIbcFI6B; Wed, 5 Dec 2018 21:22:19 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B1C131024; Wed, 5 Dec 2018 21:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=C1Si3ZNWnCEbnt59FYXt7ztnG/vned3blaU4INKRldk=; b=m9PgVhgjVwL2uyQ5WgnLjWhnH Ww5c/m8dZaefYPHH2GFrFtKaznqXkRlm7XY6EsoeC1Qz5XqUpCFPX/RuY2kbCuXG6LL+eQD+qVtTA jHiVf7FUu2Ps3RR8QLFg94GRnX5EYfLXuhrIoew9ZpLq2LR22fPE/pzSfH3NclNX1te2+Dfzi5LSt iOuzZtwf5oyw1MunBxFvk9XA84eCe8zHqrFsOQOFAM5jXbGmhhaAN8e0GVe7uY2sKPkQKwDDMPgDj 07Ksj+XyoiKuxgJ3QxXp6H0XGIsPQWjhr01kaLouOtM6LI5uWKE9lsaMGD9a5R2uQNPlpBLshKsdx uSDN2iJ5w==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53891 helo=[192.168.1.179]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUm76-000zRN-UM; Thu, 06 Dec 2018 00:22:17 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Wed, 5 Dec 2018 21:22:15 -0800 Cc: Brian E Carpenter , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.co m> To: Christopher Morrow X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 05:22:20 -0000 > On Dec 5, 2018, at 9:01 PM, Christopher Morrow w= rote: >=20 > How is it, for example, different to put ipv6 packets into an MPLS path do= ing nothing along 'many' hops (except forwarding the packets along), and the= n once you pop out of the tunnel start processing the packet as you (joe) wo= uld want. The hopcount doesn=E2=80=99t get decremented by L2.=20 Joe= From nobody Wed Dec 5 21:31:59 2018 Return-Path: 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 B9B8A131062; Wed, 5 Dec 2018 21:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 XI8MABlJhZqy; Wed, 5 Dec 2018 21:31:38 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DC0131069; Wed, 5 Dec 2018 21:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kbgJgS8u3ubQ8LWtNLHb4xa7HzfsnntW5eQkYBg3YaU=; b=Tsqz3JIxTG1/HXIaiazV7Aaw8 yRlraUdUZbB/ko9yaYJcSkAB3CaSuUUGDc2yzT7t1XcGj+F1jsUvbHCukgtmzQSW33Q/oO63/yQfP K4QlID+UugnSiGPFLNRH3fEblKtUc+V3I30KcGGJTKqPMmaujzeK3oUpHUJi7B6wULO2arf/vn/oT CVR9eRf92Y7zHeG08QL79J+z0m8VCptBuxBrTx9qdIMotr6X2wPtCvH/B9kdl6xr3nU5mNHHpdNgd LWDdu+j8mxxh69QlVmiRqTfjXEUb4ZeUKgNLntYorPT3iKFgvbS7FTYvQKq396ApQt+gnU6+5Jisk B/qnAJK/g==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53903 helo=[192.168.1.179]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUmG5-0018Lx-22; Thu, 06 Dec 2018 00:31:34 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> Date: Wed, 5 Dec 2018 21:31:32 -0800 Cc: tsv-art@ietf.org, opsec wg mailing list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ietf Content-Transfer-Encoding: quoted-printable Message-Id: <811D965A-149E-4E33-A526-2CFCB7A1882B@strayalpha.com> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.co m> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> To: Christopher Morrow X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 05:31:50 -0000 Additionally, packets don=E2=80=99t emerge from different mole endpoints or a= re IP processed in any way. The mold acts like a wire, which is fine. That c= an be done by IP tunnels too. But not routers that converge and diverge pack= ets.=20 Again, if HBH headers are meaningless and not needed, then go through the pr= oper process and remove them from IPv6. If not, stop trying to hobble this p= rotocol to the point where we all realize why nobody wants to use it.=20 > On Dec 5, 2018, at 9:22 PM, Joe Touch wrote: >=20 >=20 >=20 >> On Dec 5, 2018, at 9:01 PM, Christopher Morrow w= rote: >>=20 >> How is it, for example, different to put ipv6 packets into an MPLS path d= oing nothing along 'many' hops (except forwarding the packets along), and th= en once you pop out of the tunnel start processing the packet as you (joe) w= ould want. >=20 > The hopcount doesn=E2=80=99t get decremented by L2.=20 >=20 > Joe From nobody Wed Dec 5 22:24:44 2018 Return-Path: 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 5460B131071; Wed, 5 Dec 2018 22:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 tj32Kd_uWFvw; Wed, 5 Dec 2018 22:24:30 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 7E586127133; Wed, 5 Dec 2018 22:24:30 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id f10so12977299iop.10; Wed, 05 Dec 2018 22:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MA/K1T0MwObFQ/bkTCShNHp0Bb+w6VwzI4WnnrTWYQM=; b=f9qDf2E87uyUVgki6e0kMFV2OUtfTc1UoG23C5LffMdjMNVmpSi146NrCqQ/7ONrWm PJn5K4DaiT8Nz0SLdatzqsbI0GQsMj4F0h3b2IwpSr3QomoUbHdNUq4YoIrgbpYa/wn7 B18Fm+qu5avb1cS36uC7Q7f4zuJMHv4ZFQKOnyTnc2yG2QDsBQCI/PT49EE6FYeUfn1P esychhc1g045LHw4HBL4j27vzA60Ax5zjC4+HibSlB/s43xmEeVP8n45JKs9L0FirFov zw8WpDgrC2AASA5bDIyiLxhvkqyOGgKgE7CD7a6PqTnMEp1tYppN2QNTwDTq4YFIKyeD FObw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MA/K1T0MwObFQ/bkTCShNHp0Bb+w6VwzI4WnnrTWYQM=; b=uWRafjk8AMgjhDQs8PCxJ7g8fds38GisktoHYOrojPNMzpFtUwVk1AQwCE2dG6fb7Z uHa6ySDUBK9PJoHLRP3Crcz9ddCLJTQOlvA5HJkn/czdQ2e3gTtKpOtyqEwDOv6h69OX iXVWoE1SIaX/fz7sFDjc/LhHHiZBC+nFQ4We53a1fbKbCFTOKb+03UCChOGJranU929d ydAHnzbvRmh+x8+r3/lPaWjDd63IezcHecX/ngKUWOZZDihXpfSiHerCEm3Ar1Nw6d0E +tiV1LZbKJT1W6XIlueyWdgw9TekRaetwhu6ecG4zmgxdY6XA2xiQ28W3Nq+gEuEM94j h7iw== X-Gm-Message-State: AA+aEWbxF0HUcWkcxDSrT370PQeAYTfOHxsGbct0JgUMLYJ6HTUB4RSQ DhzIPwjMF56nzf/6TrOq5BC4ZIaUO1GFRFbnAv8= X-Google-Smtp-Source: AFSGD/UcHl/w0ltYhNZ8KwwBM5JeCbPEmZ+PBdXvf19Y8wMcMK1LjCqd5YbMw3qmBKeHxBvVvGe/orhJPidKtvSkGKU= X-Received: by 2002:a6b:c9ce:: with SMTP id z197mr23046091iof.287.1544077469550; Wed, 05 Dec 2018 22:24:29 -0800 (PST) MIME-Version: 1.0 References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> In-Reply-To: <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> From: Christopher Morrow Date: Thu, 6 Dec 2018 01:24:17 -0500 Message-ID: To: Joe Touch Cc: Brian E Carpenter , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list , tsv-art@ietf.org Content-Type: multipart/alternative; boundary="000000000000140d27057c548ddd" Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 06:24:35 -0000 --000000000000140d27057c548ddd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 6, 2018 at 12:22 AM Joe Touch wrote: > > > > On Dec 5, 2018, at 9:01 PM, Christopher Morrow > wrote: > > > > How is it, for example, different to put ipv6 packets into an MPLS path > doing nothing along 'many' hops (except forwarding the packets along), an= d > then once you pop out of the tunnel start processing the packet as you > (joe) would want. > > The hopcount doesn=E2=80=99t get decremented by L2. > > you are assuming that the mpls path has 'no_decrement_ttl' set though? --000000000000140d27057c548ddd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Dec 6, 2018 at 12:22 AM Joe Touch <touch@strayalpha.com> wrote:


> On Dec 5, 2018, at 9:01 PM, Christopher Morrow <morrowc.lists@gmail.com> w= rote:
>
> How is it, for example, different to put ipv6 packets into an MPLS pat= h doing nothing along 'many' hops (except forwarding the packets al= ong), and then once you pop out of the tunnel start processing the packet a= s you (joe) would want.

The hopcount doesn=E2=80=99t get decremented by L2.


you are assuming that the mpls path ha= s 'no_decrement_ttl' set though?=C2=A0
--000000000000140d27057c548ddd-- From nobody Wed Dec 5 22:28:36 2018 Return-Path: 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 1B0DE13106E; Wed, 5 Dec 2018 22:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 8FtwxtVuG85s; Wed, 5 Dec 2018 22:28:14 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 39FF3128CB7; Wed, 5 Dec 2018 22:28:14 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id h65so24182851ith.3; Wed, 05 Dec 2018 22:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lueKbVAiXI8cy+2EmOaMGPxxgdKJHlxlMUE5O5sgU/g=; b=WbRYoJxnQEri0rLTQhr8g7yWDI+yPR/qbC7qHbMyNVqr50bJSC307Qd8+ZEedvoQJ2 LPghpEU206HVLJnqLYfUulQGDatsZqYHYoUoQj7ibQH4KDqBzD5nT6qsjhro3qH9FkOk U2dPEE1HKGWqDv3H+Y7ojeou03hlPREwqGbq1V1Eiy9663zlAGJOhaUz5gipsXlzfETi iRPwYs4nvDOF817mr/SDQXzg+/HoR3bk2n/uJuWj1KvrQ87RV3TGbi3gdC7fJ79657uO rhcK6+1z+JWE3TxixGrFUP2CDOUGYAybbKWgQHlNTwFDvnHe3r6PfyQrrDUYt944GZIx Zd9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lueKbVAiXI8cy+2EmOaMGPxxgdKJHlxlMUE5O5sgU/g=; b=cgjFuwO9PV3N+73yLJGUYTf4FAWNIUFNtJOuhzdUJgweMcdxKe3UsKYxX1JXyMj+wY lTArJPHIwcz9GjInfyWMymnSJDsxmC63AX3i4TMXcOMQnt/6x7qS/9BQkxl/LdW76fbg VKgtXBepveHS9lB4pfZBbMovrmMbHaG2/h7rsDFP8DP0/HYbVZmphY6HSFFM01tVFWHb 4dPQTp73JJBTpEthtT1xc8X64uhppa+5xcOGGYZfwAWP/Qmv4eOMHRAemltOBoEjcYb8 ysGl25ysQuxf1T1Q87CLR68tPzN4JSJq7Xg3Vvq1lfB30josrMMgoV+WbYnwyIeZeHz8 sNjA== X-Gm-Message-State: AA+aEWajNWi1/YqF+GvC85fa4qkNTnGYRY5e/eYdC0fkOC8asJBY1TO3 zK07RUbccLWPDfaTmVeqePnY3+tTVWdDnpdLzY/YJw== X-Google-Smtp-Source: AFSGD/XWWrRa2oKifuuNToszFCv/sY91VvtkuuP+2fX0v4WMragaCv04LcY3itXtAqECLgyjOlc2q0q6YpllJIERUnk= X-Received: by 2002:a24:9d1:: with SMTP id 200mr19322600itm.53.1544077693383; Wed, 05 Dec 2018 22:28:13 -0800 (PST) MIME-Version: 1.0 References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> <811D965A-149E-4E33-A526-2CFCB7A1882B@strayalpha.com> In-Reply-To: <811D965A-149E-4E33-A526-2CFCB7A1882B@strayalpha.com> From: Christopher Morrow Date: Thu, 6 Dec 2018 01:28:02 -0500 Message-ID: To: Joe Touch Cc: tsv-art@ietf.org, opsec wg mailing list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ietf Content-Type: multipart/alternative; boundary="0000000000006b79dd057c549a8a" Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 06:28:19 -0000 --0000000000006b79dd057c549a8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 6, 2018 at 12:31 AM Joe Touch wrote: > Additionally, packets don=E2=80=99t emerge from different mole endpoints = or are > IP processed in any way. The mold acts like a wire, which is fine. That > can be done by IP tunnels too. But not routers that converge and diverge > packets. > > this is patently incorrect. but also not particularly important I suppose. > Again, if HBH headers are meaningless and not needed, then go through the > proper process and remove them from IPv6. If not, stop trying to hobble > this protocol to the point where we all realize why nobody wants to use i= t. > > I think everyone here is actually happy to see v6 progress. I think the option to ignore if you are an adult is a fine option, and actually helps deploy v6 further/faster/more. I do agree that IF the end systems expect their core networking (across the wider internet, not in their campus deployment) to 'do something' to the packets aside from 'forward' ... they are going to be sad. I don't know how much processing (aside from 'forward') matters though on the wider internet. What L3 does with my packet EXCEPT deliver it .. is unimportant to me, please just deliver my packet(s). note I'm not trying to be intentionally combative, just attempting to say: "the best answer for the user here is PROBABLY to just have the core ignore all the EH business entirely" --0000000000006b79dd057c549a8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Dec 6, 2018 at 12:31 AM Joe Touch <touch@strayalpha.com> wrote:
Additionally, packets don=E2=80=99t emerge from different mole endpoi= nts or are IP=C2=A0 processed in any way. The mold acts like a wire, which = is fine. That can be done by IP tunnels too. But not routers that converge = and diverge packets.


this is patently incorrect. but also n= ot particularly important I suppose.
=C2=A0
Again, if HBH headers are meaningless and not needed, then go through the p= roper process and remove them from IPv6. If not, stop trying to hobble this= protocol to the point where we all realize why nobody wants to use it.

I think everyone here is actually hap= py to see v6 progress.
I think the option to ignore if you are an= adult is a fine option, and actually helps deploy v6 further/faster/more.<= /div>

I do agree that IF the end systems expect their co= re networking (across the wider internet, not in their campus deployment) t= o 'do something' to the packets aside from 'forward' ... th= ey are going to be sad. I don't know how much processing (aside from &#= 39;forward') matters though on the wider internet. What L3 does with my= packet EXCEPT deliver it .. is unimportant to me, please just deliver my p= acket(s).

note I'm not trying to be intentiona= lly combative, just attempting to say: "the best answer for the user h= ere is PROBABLY to just have the core ignore all the EH business entirely&q= uot;=C2=A0
--0000000000006b79dd057c549a8a-- From nobody Thu Dec 6 01:00:58 2018 Return-Path: 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 E926513110B for ; Thu, 6 Dec 2018 01:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 rVqvr1v3DYCI for ; Thu, 6 Dec 2018 01:00:50 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C407913111F for ; Thu, 6 Dec 2018 01:00:47 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 680AC41B3A for ; Thu, 6 Dec 2018 10:00:45 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 5615540B9E; Thu, 6 Dec 2018 10:00:45 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 51823F010; Thu, 6 Dec 2018 10:00:45 +0100 (CET) Date: Thu, 6 Dec 2018 10:00:45 +0100 From: Gert Doering To: Christian Huitema Cc: Gert Doering , Ole Troan , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , tsv-art , IETF-Discussion Discussion Message-ID: <20181206090045.GB1543@Space.Net> References: <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Bf1m62tZozKFsi1s" Content-Disposition: inline In-Reply-To: <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 09:00:51 -0000 --Bf1m62tZozKFsi1s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Dec 05, 2018 at 11:26:38AM -0800, Christian Huitema wrote: > Gert, I think that you are actually pointing at a significant issue with > the draft. [..] > The draft *implicitly* assumes that routers will try to find the > protocol and port numbers "because of security reasons", but never > actually delineates these reasons. I think the discussion would be much > more productive if the draft started by explaining why network managers > believe that access to the "five tuple" is essential for a variety of > reasons, many of which are only tangentially related to "security". [..] Thanks for spotting this and spelling it out. gert --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Bf1m62tZozKFsi1s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwI5ToACgkQ31bAZeTO f8XNaRAAoJPxpaIosO/zN1jmfiG/yO17yQoQgO4SF9Fyvma+fEUmFqqDRfjVyl7p GyVuUIVyX05oagEvj/9yONfrj+thkmkUk0Z7qLjNVwUJk/YXajiv+FLW27f6XfYD ge6z66jaHsVZjXMxmGg89CRkLnpZWh58oGQfhSjF8fT65ttvjlA4xrqKqmItanP+ eV8afETLJjCzYaGQZ/w+Z9Vfa7p0EnH5/1ObnNBPqp3nPzACF12MiLoCwKVW5xc5 pfAilbCff2xaOJDxB259nwrD2RPjIrE2aXbm4is9pmKvZbsd6vGb6Rb1vYq18JeU N2tM7f2AxhTmbFVjmIFPjizWWbQ6dlS6OjNS0CU6M4eBF+NzbfF8QZDGzAWJZTlE 7Juvp2zazACIif9+NhVoqyOnKhyaPa0HXrzXI4c/g3uNvGDu3jnKqqRnWc+QOVAc mliTzf6m1iod4xc9yWe5h/0JTa4nCQr5QdjHEeuCVIZzJVEPWei4Xoj8D/0gWQnS DghrwaAg0jrJIVf9MtRJ8/rOo+tsAVFG+1NHjLpLe/e5o5jwT7PDvL91uiUxGqYu cxasbrtgVFj4kmu1wBCbblBXNnIjtrdk/9HisBjC/Ur7D3b1/aImiBNQ50xB2s1J YmBpQg0p3Z1t0dNd8MtEjqxrXXwwTSQPxrLrWCnJsLlW0Ivupvw= =Piu4 -----END PGP SIGNATURE----- --Bf1m62tZozKFsi1s-- From nobody Thu Dec 6 01:13:32 2018 Return-Path: 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 726E1127B4C for ; Thu, 6 Dec 2018 01:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 27gs1AhX9cLd for ; Thu, 6 Dec 2018 01:13:18 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3FF5130DC9 for ; Thu, 6 Dec 2018 01:13:16 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 238D241C10 for ; Thu, 6 Dec 2018 10:13:15 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1085740B9E; Thu, 6 Dec 2018 10:13:15 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 01111F0DF; Thu, 6 Dec 2018 10:13:15 +0100 (CET) Date: Thu, 6 Dec 2018 10:13:14 +0100 From: Gert Doering To: Brian E Carpenter Cc: Christian Huitema , Gert Doering , Ole Troan , tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-ID: <20181206091314.GC1543@Space.Net> References: <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MOLI6A2k/lnHENyK" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 09:13:20 -0000 --MOLI6A2k/lnHENyK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Dec 06, 2018 at 01:48:29PM +1300, Brian E Carpenter wrote: > And I don't think that is an oversight. The *definition* of "router" > for IPv6 is "a node that forwards IPv6 packets not explicitly addressed > to itself." No mention of filtering, classification, admission control,... This definition of a router is nice, but such a device will not be=20 useful in today's Internet. What do you want this draft to be? Theoretically beautiful, or useful for people operating outside a closed and well-controlled network? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --MOLI6A2k/lnHENyK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwI6CcACgkQ31bAZeTO f8XS9xAArIJJEfnLGtcRv6w8jQErWDpo77WM9DFbkir6XaaP7WREK06hvcdtRLE3 BGLcHDvJ2iqVaz/NmddBqiWk09oHtRrlW01uwVX18SbtE5Nvgpb9uriWJ9D0aKqe xkHyc8H+k9t3E9sE4qKbCZw3C1+2ODHk2rEwoBVfvLsk3Z4CN8cEER/pLzOiklDe 2AnXA+/i5XrCO3YB6YL1P9FdhfFXEn3TwlF0BdUQ9ZBTO8XLmM2WyHznQlSyBzNb 0BoyXeDZx9fZqAz5yxEPUZ+SYHGIzXFeOjtYmyngpHijSIc8XGkMGeucM4DkQ7Sc g9nEyYTc1Kjme+qGq3UiFsUITUQ3YIW/Z1XTphDg8Iveg8LZjzxXm7YQQXDkT4Ja CQXENfqMs9OrMd4l7/qtl+Mhjih3Z+lduulR6gB/wW4Oudy/srfuCxfNclwClG1H aZ4xrWx4+st4nhDpMmWrRd81bZhr83Gy9BahPcKrQ0fWKlWJxHD955e8UvbRovh/ 49eqHIXn0GIyoZzmlBReRk7lZOpvppsbon8shbnYlEFtmnMMuAKakK9evMros4n3 F/uM8i5NUXjjAMZtLqNFyw1Disugyfr0Byx1Ojyu4khXpEpfh5JsfGCcERVT3Jy8 tZcrE5uINyD7mBt5k2o9GDo+ABjSQhhgfF1nWwP3xuA259uIqDM= =i/Fd -----END PGP SIGNATURE----- --MOLI6A2k/lnHENyK-- From nobody Thu Dec 6 01:22:32 2018 Return-Path: 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 DA5AF131139 for ; Thu, 6 Dec 2018 01:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 LKx6ht0Sw6rn for ; Thu, 6 Dec 2018 01:22:23 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C4E131134 for ; Thu, 6 Dec 2018 01:22:23 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id BA15140D75 for ; Thu, 6 Dec 2018 10:22:21 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id A20D140B9E; Thu, 6 Dec 2018 10:22:21 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 9369FF177; Thu, 6 Dec 2018 10:22:21 +0100 (CET) Date: Thu, 6 Dec 2018 10:22:21 +0100 From: Gert Doering To: Joe Touch Cc: Christopher Morrow , tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-ID: <20181206092221.GD1543@Space.Net> References: <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> <811D965A-149E-4E33-A526-2CFCB7A1882B@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <811D965A-149E-4E33-A526-2CFCB7A1882B@strayalpha.com> X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 09:22:31 -0000 Hi, On Wed, Dec 05, 2018 at 09:31:32PM -0800, Joe Touch wrote: > Again, if HBH headers are meaningless and not needed, then go through the proper process and remove them from IPv6. If not, stop trying to hobble this protocol to the point where we all realize why nobody wants to use it. I don't think "lack of extensibility" is the major showstopper in IPv6 deployment. "Endless quarrelling and unimplementable complexity, while lacking sorely needed aspects that are considered too-hard or out-of-scope" might come closer. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Dec 6 01:32:06 2018 Return-Path: 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 A6A6F124408 for ; Thu, 6 Dec 2018 01:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 36dIP6ezHzuO for ; Thu, 6 Dec 2018 01:32:02 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E47D13111D for ; Thu, 6 Dec 2018 01:31:56 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1F80B41135 for ; Thu, 6 Dec 2018 10:31:55 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 0ED5F40B9E; Thu, 6 Dec 2018 10:31:55 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 0A8AAF20C; Thu, 6 Dec 2018 10:31:55 +0100 (CET) Date: Thu, 6 Dec 2018 10:31:54 +0100 From: Gert Doering To: Brian E Carpenter Cc: Gert Doering , Christopher Morrow , heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-ID: <20181206093154.GF1543@Space.Net> References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bpNGSkw8ExqLHKDe" Content-Disposition: inline In-Reply-To: <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 09:32:05 -0000 --bpNGSkw8ExqLHKDe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Dec 06, 2018 at 01:14:54PM +1300, Brian E Carpenter wrote: > > Which implies that as soon as the evil guys out there find a way to > > generate DDoS streams carrying EHs that our border routers will (have t= o) > > apply very strict rate limiting to everything they do not understand. > >=20 > > - pass TCP > > - rate-limit UDP on well-known reflective attacks port > > - pass rest of UDP > > - rate-limit ICMP > > - rate-limit fragments > > - rate-limit all the rest to something which can never exceed a custom= er's > > access-link > >=20 > > game over, EH >=20 > Just to point out that this is equivalent to saying "game over, > any new layer 4 protocol" too. For example, you just killed SCTP. > And the same goes for new protocols over IPv4. Well. Since nobody is using SCTP, it can nicely live in the=20 "rate-limit all the rest to something ..." bucket... But yes, "any new layer 4 protocol" is likely to not work in an Internet that is basically full of hostile packets *in high volumes*. Trying to run large volume traffic over UDP/443 is going to be the next excercise in "operators told you that is isn't going to work"... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --bpNGSkw8ExqLHKDe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwI7IoACgkQ31bAZeTO f8Vnag/+JgB66nWgMcgzsFCm442GvZfE7gtfYHTy5I6pQ6I1m7FVskkcsLWyJlRD rN89BEunzVs+o2gOxUab+W8G2RgQdw8XiTkzuG5rWPZjeQDnrKuvlfTlr/HlEJnE LhlAxux6Wy/gG5b9Rak1lnivfkE+xdSnJRKUbSATEpYe0o//TdFC9Wa8iO8352nE ujsRuasQw0bwkRDORB+hS5kzJDQ+SfMeLfuEiwHKg9t0WSTwe9OXDZTQen1zp1t0 +NyFESZZJBzwucNB1ByGahvCA0q6qraY6FfIRWjq40rCsd/bC034MyfXP8jbVTXK ZjjH+LBgFDAqUF3Wg8hdhe9zWoJ3vUk/fWxF2T2Kfzhx13rW4dZfrpblL6voIYd9 M5+m5g3kMFNjs11AKY+BuKpYTPgHTOT5kuiTddcyqag7fP2uuke03wbTDZKJ70NC D3HvpOdAxb7mzJRloCuSLUk398bJN7IG3n93a38BYTcjOKR5+3S3jstS1C8qymMu /zJ70epODcFrLf+skm9fSkB3miDfMQWxZ3xBigkqMC1NoyWvq2XG9+7gI5yJDXUj jTcCOBItPkUQoR6wLwcHpauE0tuIEC8wja003GM7Z7o/XhYVYyJ33p/pQRgdRjyo Z0y+RZyH2Yjf29KN3ZbJXwSJckF9mIVKTSNtMkpAqhhSzBfPdW0= =FiOs -----END PGP SIGNATURE----- --bpNGSkw8ExqLHKDe-- From nobody Thu Dec 6 02:15:24 2018 Return-Path: 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 5C3CB130DCE; Thu, 6 Dec 2018 02:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 I8C1lUZXHjOi; Thu, 6 Dec 2018 02:15:15 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4353129BBF; Thu, 6 Dec 2018 02:15:14 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 145B73410ED; Thu, 6 Dec 2018 11:15:12 +0100 (CET) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/3959.24150); Thu, 6 Dec 2018 11:15:11 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 6 Dec 2018 11:15:11 +0100 (CET) Received: from [195.176.113.156] (account ietf@trammell.ch HELO staff-net-etx-0133.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.2.9) with ESMTPSA id 76244073; Thu, 06 Dec 2018 11:15:11 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Brian Trammell (IETF)" In-Reply-To: <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> Date: Thu, 6 Dec 2018 11:15:11 +0100 Cc: Gert Doering , Christopher Morrow , heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E79A9B9-13A0-45DC-8D7F-25554137C414@trammell.ch> References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 10:15:17 -0000 hi Brian, all, > On 6 Dec 2018, at 01:14, Brian E Carpenter = wrote: >=20 > On 2018-12-05 21:52, Gert Doering wrote: >> Hi, >>=20 >> On Tue, Dec 04, 2018 at 10:57:43PM -0500, Christopher Morrow wrote: >>> HA! ok. As gert/nick noted ... we have Nx100G links today (at the = edge) and >>> coming nx400G ... there's just not a reasonable story for "dpi" = there. (I >>> suppose: "yet" and "without paying the approximate value Coca-Cola >>> Companies yearly advertising budget") >>=20 >> Indeed. >>=20 >> Unfortunately, there *is* a story for being able to rate-limit = incoming >> crap by protocol type - "give me no more than 200 Mbit/s of UDP = packets >> coming from source port 53". >>=20 >> Which implies that as soon as the evil guys out there find a way to >> generate DDoS streams carrying EHs that our border routers will (have = to) >> apply very strict rate limiting to everything they do not understand. >>=20 >> - pass TCP >> - rate-limit UDP on well-known reflective attacks port >> - pass rest of UDP >> - rate-limit ICMP >> - rate-limit fragments >> - rate-limit all the rest to something which can never exceed a = customer's >> access-link >>=20 >> game over, EH >=20 > Just to point out that this is equivalent to saying "game over, any = new layer 4 protocol" too. For example, you just killed SCTP. And the = same goes for new protocols over IPv4. Indeed, it is, and I think it's a nice honest assessment of the current = state of the Internet. We lost the ability to deploy new layer 4 protocols (in terms of the = value of the protocol or next header fields in the network layer) = universally within the Internet at least a decade ago. The argument here = seems to be whether we, as the IETF, want to acknowledge this fact, or = not -- and all of the evidence I've seen would seem to confirm the = situation is the same for HbH (and to a lesser extent, DO) EH for v6 -- = and whether there are degrees of freedom to be won from said = acknowledgment. I note that current work in TSV on transport evolution pretty much seems = to acknowledge this, if tacitly, for layer 4, and to actively design for = this situation: - the original concept behind TAPS, runtime transport stack agility, was = designed to make "new" protocols deployable (whether over v4 or over v6) = when not impaired by the network, and to fall back to less impaired = protocol stacks when they are the only ones available. - QUIC explicitly uses UDP in part because only protocols 6, 17, and to = a lesser extent 1 are assumed to be widely passed in the network (and = numbers from Google and RIPE Atlas, presented in MAPRG, show that even = here there's about a one-in-thirty chance that a given path won't = support QUIC over UDP, necessitating TCP fallback), and the primary = utility of encryption of the QUIC protocol header is avoiding the = deployment of in-network functions using any part of the QUIC header not = explicitly designed for on-path use, thereby (we hope) keeping this = decay from impairing our ability to change QUIC as it has our ability to = change L4 otherwise. Cheers, Brian From nobody Thu Dec 6 02:29:01 2018 Return-Path: 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 60A8C130DE8; Thu, 6 Dec 2018 02:28:59 -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 AmLGNgmFVyaP; Thu, 6 Dec 2018 02:28:57 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 38CFB130DCE; Thu, 6 Dec 2018 02:28:57 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id b14so9101388wru.12; Thu, 06 Dec 2018 02:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=8/Bg1tnpWGkoQ1A1hOlCERrkoorcb5TSRchrMu/RGCo=; b=Kp2zs9p8k/MtX0KZdaYigaB+hVqkMtFROXMF+EJ0WmyFKlvPespt8C3TVHrWqlUT3F agyMw4UXedj0PctMFua3I1EeBY2Ze/T0/xDxuuDPwz5d82rA94wbM3wAPbkIwD4sbTiA 9bgc6wBViJW8DWcpt5tatRq0sxd3Iwrv40DypgB5JU9Jt3TZvhNjH4kHt4V7PAKdN3/r IDiCXwv7Ay4Ms5eMbnrIxYNZAevsDsgd/qHfK1f+MZwfJIpAcK6k8ZDRBGarHhetyqiJ UXSabJ+Wo/vg/u1B2tIWR2bONbtReeFXU5IKcZQLQDyMxhIlSQNUS8UUIkFPd8nCtXHt PjyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8/Bg1tnpWGkoQ1A1hOlCERrkoorcb5TSRchrMu/RGCo=; b=YWkDKQv9t53W8vPnyDuIZiFxUZ8L4Y1GKa11PqmG9TWMiRz16uUGq0w/o75o0uOasm f2tAclEWVgLKMBJ/ByRIM0acsjk4gi8MmLo2O5qvq/4EiogigKZwp3VJJJF/KggaFBff 4ziCw1I3KYRx9nsyo/jvBEBtQjBJtSkczXeyxNox6p2MJmgPFgwiYxShv7GkM05+f+ib aviJC0GmLICNVf/ts68Sl9IbYi0/9theO6ZMlBIaP749zw0sF4NDLgr6cN4FgWUq/yae LBLmeGudeQ13ZBXGO043aWlNRIpR7HJ6CMFAJhbzbDow3ENhRsy2OIu+h4u2kVyckV+F JIFQ== X-Gm-Message-State: AA+aEWa3nuChL1G8//mzCPOoeIFk2sVkyhsolC/nXg5OuelpwFZWWrjF zgTHudbYdG70UircJrgA3R9o5szU X-Google-Smtp-Source: AFSGD/V/P3FbOYrL81/SamuNsfHUmEYlHbzmkqEK/DMN6fjsI1JmOarfeYkHgm+EOaY/Lmi8Gyisjg== X-Received: by 2002:a5d:56d2:: with SMTP id m18mr26498987wrw.113.1544092135281; Thu, 06 Dec 2018 02:28:55 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id b131sm548630wma.21.2018.12.06.02.28.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 02:28:54 -0800 (PST) To: Brian E Carpenter , Gert Doering , Christopher Morrow Cc: heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> From: Stewart Bryant Message-ID: <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> Date: Thu, 6 Dec 2018 10:28:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 10:28:59 -0000 On 06/12/2018 00:14, Brian E Carpenter wrote: > On 2018-12-05 21:52, Gert Doering wrote: >> Hi, >> >> On Tue, Dec 04, 2018 at 10:57:43PM -0500, Christopher Morrow wrote: >>> HA! ok. As gert/nick noted ... we have Nx100G links today (at the edge) and >>> coming nx400G ... there's just not a reasonable story for "dpi" there. (I >>> suppose: "yet" and "without paying the approximate value Coca-Cola >>> Companies yearly advertising budget") >> Indeed. >> >> Unfortunately, there *is* a story for being able to rate-limit incoming >> crap by protocol type - "give me no more than 200 Mbit/s of UDP packets >> coming from source port 53". >> >> Which implies that as soon as the evil guys out there find a way to >> generate DDoS streams carrying EHs that our border routers will (have to) >> apply very strict rate limiting to everything they do not understand. >> >> - pass TCP >> - rate-limit UDP on well-known reflective attacks port >> - pass rest of UDP >> - rate-limit ICMP >> - rate-limit fragments >> - rate-limit all the rest to something which can never exceed a customer's >> access-link >> >> game over, EH > Just to point out that this is equivalent to saying "game over, any new layer 4 protocol" too. For example, you just killed SCTP. And the same goes for new protocols over IPv4. > > Brian > .. a consequence of the original design decision to make options and next protocols indistinguishable other than by knowing the full set of next protocol types. However, aren't we moving to a world where new protocols get carried over UDP anyway?  This is needed so that those protocols can pass through NATS and firewalls, and be subjected to ECMP to spread them across the available paths. - Stewart >> (We're not doing this today, because as of today, "volume DDoS" comes in >> without EHs [except fragment] - but this is just a matter of time) >> >> Gert Doering >> -- NetMaster >> From nobody Thu Dec 6 02:33:24 2018 Return-Path: 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 95A48131163; Thu, 6 Dec 2018 02:33:05 -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 gZhUoarFSV1d; Thu, 6 Dec 2018 02:33:03 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 7187013114C; Thu, 6 Dec 2018 02:33:03 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id v13so22689263wrw.5; Thu, 06 Dec 2018 02:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=UG8DycDHmB6tuStatm2Hbk8k2zf2SgceK1k3+LoD7I0=; b=fA4pe9LPe1Cdp5SU0W9Q0UkUi3F5FsugiG1M1Q4c6mTSM94069+pgIfkfrqgjiKbdy 8PayRr6kGUTC/lbsu5GkjCyha1Z8umq3GmSMsMGCLdJ0FWBM8NDZO0Qpk9VLr/TywTqB PXTQ4RFsHbIS+XrWxIFxRTSj/XbHubvXeDVANpRGc1g6S/T6GQvCUDul0WAtShOaxaGM wtL7wzUe7K4xZ2wx5pH6c4wZRM4MyWedczWLJV8uPhTW4UTxIQKs1WIFh+uueYbvoRcI JJKpLtdJp2P24P1PS9kzi1aEjDMFoWLOawQ1R6bXdZM9juYT/ep91XjtdUkas6db7ziR L7NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UG8DycDHmB6tuStatm2Hbk8k2zf2SgceK1k3+LoD7I0=; b=a0AI1KmZIqjcfdM33MJeS/zDhSkns2mTPtndiI1OJ/Pdqj4nam3+8ArrlW5ESjDAbi uitHNF/iYyOhgLZufjdi+82UfxmTLXMgbLOCHv2wkJw54Zpy3aSvEVmYeKagUn2Epi1B Xpz5PWmvoG27GBiSmIW82WOcivuDq6J6CeK0varPlCUPWtDmQOpCn/ZEy8fowXTqndPM xA2URhVWLI3yk+B6J1PUSrZ1wWwHaxFUs5yDNMVK5wNXBk3v0KX4qKnQ81LCwjIOsyZ6 W72tAs9ekOPccox7N623VrfnUdTeasGAG1XqOuk6/XXxYFEQtsoVQJWv5x/WrGzcBhqI 7c0g== X-Gm-Message-State: AA+aEWaSlMgQaIrj2e5qUTfP6opnb+1viNQKV/bm4lScmWjnjirbfrnh DNKzG01zom3MxS7QD//GPIwiNohT X-Google-Smtp-Source: AFSGD/WshENEi86vsBsctmvrNxZ0WhRXS6Foh7Fh+ABzevD87gwghU0nQzZiCdDwdqU8u1AszCMScg== X-Received: by 2002:a5d:6105:: with SMTP id v5mr24210395wrt.63.1544092381462; Thu, 06 Dec 2018 02:33:01 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id x20sm720256wme.6.2018.12.06.02.33.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 02:33:00 -0800 (PST) To: Brian E Carpenter , Ole Troan , Gert Doering Cc: tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> From: Stewart Bryant Message-ID: Date: Thu, 6 Dec 2018 10:32:59 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 10:33:11 -0000 On 06/12/2018 00:34, Brian E Carpenter wrote: > > . >> Of course it still needs to step through them all to do ECMP even if >> they are all disabled. > No it doesn't. That's what the flow label, in a fixed position early in the IPv6 header, is for. A line speed IPv6 router has no need to look at the layer 4 header, even if it's doing both diffserv and ECMP. Looking at transport headers is an IPv4 concept. > > A question for the operators, how widely supported in the flow label? (a) in native IP (b) IP over MPLS Certainly in MPLS and Detnet land I hear about the five or six tuple all the time, including the inspection of them during forwarding, but I don't hear much spoken about the flow label. - Stewart From nobody Thu Dec 6 03:00:08 2018 Return-Path: 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 CC264126F72; Thu, 6 Dec 2018 02:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Kjw1DYdbdM3J; Thu, 6 Dec 2018 02:59:57 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E6F126CC7; Thu, 6 Dec 2018 02:59:57 -0800 (PST) Received: from astfgl.hanazo.no (77.16.73.20.tmi.telenormobil.no [77.16.73.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 6F0A2FECC073; Thu, 6 Dec 2018 10:59:56 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 77A96AB43B9; Thu, 6 Dec 2018 11:59:50 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Ole Troan In-Reply-To: <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> Date: Thu, 6 Dec 2018 11:59:50 +0100 Cc: Brian E Carpenter , tsv-art , opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <19869497-A363-460F-9348-B40141F7600E@employees.org> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a 43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> To: Joe Touch X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 10:59:59 -0000 Joe, I think you misunderstand. > I=E2=80=99m talking about a conflict in the text of 8200 - which has = those fields as required to support - and 7045, which says they can be = silently ignored. 8200 says: If the router is explicitly configured to process the HBH header it MUST = adhere to the option flag 2 high order bits. Otherwise it MUST forward the packet. There is no conflict. If you think a different behaviour is required, then propose that. But = preferably in 6man and on a different thread. This was discussed at length. The consequence of relaxing the processing = rules, is that an end-host can no longer use those bits to guarantee = that every router on the path implements the option. That was the = compromise we accepted. There is clearly a need for something like HBH, = where it=E2=80=99s a cheap to process for the router signal that this = packet requires further attention. The alternative is much worse, that = the router must parse deep into the packet and where the trigger to = process is a magic cookie in transport somewhere (and yes this has been = proposed).=20 Ole= From nobody Thu Dec 6 03:25:22 2018 Return-Path: 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 F209E130DFE; Thu, 6 Dec 2018 03:25:20 -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 HqZMhGTFVDQQ; Thu, 6 Dec 2018 03:25:19 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 E240C126CC7; Thu, 6 Dec 2018 03:25:18 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id n190so631814wmd.0; Thu, 06 Dec 2018 03:25:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Lx7udSXwPUThpP68XCSLVpcR37HTi2pSYTBdug986sU=; b=Hs4d2FngrSG7mA6q8xZpuLOK7mRIJ/inE9u7qi3JVzG3Mknci87HqKqVzWnh4YO2Vt IeA/2+Gh4OSYQ71QYbqee98rcnITvmY6O4+mj6RkBBxK30iuseyPDBdVgO4seTf6Am0s x9hFaNgMPuh953tE0vmvUBRYA9dlCbgJg5JpKPJNDj96P/Gq0n4nNAoN5W4R0zm/VVK4 8dKERX/BxMVF/qTTlPXgfgi2w3tj1jBveeFPrBx6S5/Blyt05Hp2CAZtaZa8zFQwVuWF WbDqwka78lp13K/7l5+bn4gNYO8qcq9JTzk/MMzUYO9TjeNAVtjs3zKsLvyv8e9TjC/j XHlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Lx7udSXwPUThpP68XCSLVpcR37HTi2pSYTBdug986sU=; b=AWWEUQeXefr9z7Pa6WPFuXo/W1vWr2CNLbf+3QwsXD/EYDxV66SoNyRWahi2F3b2rY YpKvD9+wSXE4Jkj57tejQxrSwa0IQVYPnFgSUGgwDf5vQzhG0ejGqV8LlP0/H1t/UoZq rBFE1LBGQ0KDzRpnvlCLyP6Rx2sF+J6pVlWVJ8SBR04vbCzhGEB8UJ4eo8xtUaGj8fWh vAu1kpSGLCPvMjiedqyOJ6PYtXZFfC52TYS/rlTbIlkOrK8nWKngQqQ7tD+RtzPw6ahI oDqTPWIiuKbNdCVLxTUeEuklugSSmyXer8bYRX9UENanFL2796smfzoEns57FuCS0F5j fivw== X-Gm-Message-State: AA+aEWaZOL/lcF8WziYNPYSZpZ1T1IKDYTly1qc5HkO6xYst9QCXqYzt BZCfWUcPs+BC8Dou0td0YhVOk+Oi X-Google-Smtp-Source: AFSGD/XGzmVRPWkCq45mMNknRBjBtKM/6xnj8GpH1jljd2MOrkgIAVFG4zwdkNBks5Vj8rx4wvcEFw== X-Received: by 2002:a1c:60c3:: with SMTP id u186mr20715158wmb.66.1544095516953; Thu, 06 Dec 2018 03:25:16 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id a18sm182370wrp.13.2018.12.06.03.25.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 03:25:16 -0800 (PST) To: Brian E Carpenter , Ole Troan , Gert Doering Cc: tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> From: Stewart Bryant Message-ID: <99f0a622-b1f8-cc8a-dcba-a608c37eeb0c@gmail.com> Date: Thu, 6 Dec 2018 11:25:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 11:25:21 -0000 On 06/12/2018 00:34, Brian E Carpenter wrote: > >> Of course here it is only looking for two values >> (TCP or UDP). > You too just killed SCTP ;-) Well the last time I heard about SCTP was when we were forced to include it as an option for IPFIX. How much SCTP exists in the real world? > >> If it has to look at any it has a much more complex set of tests, or a >> large vector table  given the way the EH space is fragmented. > Frankly doing it without a network processor seems wrong. You can't expect > an ASIC or FPGA based device to handle the EH structures. Something that has served the IETF well over the years is not to constrain the forwarding implementation, and I think we would be wise to continue in that mould. Also we need to remember that an NP is an application specific processor, and thus has various hardware assists. No one talks about the internals of an NP, and I am not current on any vendor's design, but it is reasonable to suggest that in addition to the s/w parser there might be a h/w parser that does the heavy lifting, i.e. if IPv6 packet of expected type, dec TTL and do what the TCAM say picking this ECMP option else parse it the hard way. Then there is something that we do not talk at all about in such designs: electrical power. There is no question that it takes more power to s/w parse a packet, and sooner of later the power burn of the Internet is going to come under scrutiny, and we will be asked to reduce its carbon footprint. - Stewart - Stewart From nobody Thu Dec 6 03:42:36 2018 Return-Path: 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 D0036130E05; Thu, 6 Dec 2018 03:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 xxpUxa1B1Npt; Thu, 6 Dec 2018 03:42:33 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46920130E98; Thu, 6 Dec 2018 03:42:30 -0800 (PST) Received: from astfgl.hanazo.no (77.16.73.20.tmi.telenormobil.no [77.16.73.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 63653FECC051; Thu, 6 Dec 2018 11:42:29 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 342AAAB4ECD; Thu, 6 Dec 2018 12:42:24 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Ole Troan In-Reply-To: <99f0a622-b1f8-cc8a-dcba-a608c37eeb0c@gmail.com> Date: Thu, 6 Dec 2018 12:42:23 +0100 Cc: Brian E Carpenter , Gert Doering , tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <99f0a622-b1f8-cc8a-dcba-a608c37eeb0c@gmail.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 11:42:35 -0000 Stewart, >>> If it has to look at any it has a much more complex set of tests, or = a >>> large vector table given the way the EH space is fragmented. >> Frankly doing it without a network processor seems wrong. You can't = expect >> an ASIC or FPGA based device to handle the EH structures. > Something that has served the IETF well over the years is not to = constrain the forwarding > implementation, and I think we would be wise to continue in that = mould. Also we need > to remember that an NP is an application specific processor, and thus = has various > hardware assists. >=20 > No one talks about the internals of an NP, and I am not current on any = vendor's design, > but it is reasonable to suggest that in addition to the s/w parser = there might > be a h/w parser that does the heavy lifting, i.e. if IPv6 packet of = expected type, dec > TTL and do what the TCAM say picking this ECMP option else parse it = the hard way. >=20 > Then there is something that we do not talk at all about in such = designs: electrical power. > There is no question that it takes more power to s/w parse a packet, = and sooner of later > the power burn of the Internet is going to come under scrutiny, and we = will be asked > to reduce its carbon footprint. So you are arguing that we need to define ULPs that are easy for routers = to parse? At arbitrary depth? Because why would the buck stop at the UDP header = when transport has moved one layer up? As opposed to the 6man argument which is that IPv6 is explicitly = designed to only require routers to need to process the first 40 bytes = (with the one exception hook). And the design of EHs is specifically done to make it hard to parse for = intermediate devices=E2=80=A6 Is that really the Internet we want? Of course it will be countered with = encryption, but I foresee a raft of problems if the IETF as a whole = would redefine the =E2=80=9Cformal Internet architecture=E2=80=9D. Cheers, Ole= From nobody Thu Dec 6 04:40:25 2018 Return-Path: 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 D4D25130DDB; Thu, 6 Dec 2018 04:40:08 -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 wwQBl9Zrek7s; Thu, 6 Dec 2018 04:40:07 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 A30801286E7; Thu, 6 Dec 2018 04:40:06 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id c126so888818wmh.0; Thu, 06 Dec 2018 04:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=cAhuA6j0wn4+04Ohh5+SStFLIHkg+7HRmXWwpphSMmE=; b=T+HCdirBI6p8x2eioMBwOc0oYsAFcQGRFAoK6nnEA1HA4eXO5eOFGdvydcltCqVQNL Gnm4ahSlMmmUHGzEa43Ki+TDlea45daacKDBR96TiYfL40m00HbfWavw+IkAcRuVqvHu bYWQSUoV0xy+CVEAlre7BjYAJLwwstXaA7uAvDX9uqggkh8u43iMXuu5AmKdWp+xXUX7 lWJVrnMQPPpYBCx979pkym8ZixfWZ2HY/z4QOvFxspm4gh0jZSb80lyuDOPtQXIOg+FF Vq5frgcHLuCLIR1KuDqKSRf8+s7D4rERZBqmh5mxaO4VrT/qnBw8hvedjOvuDQmaObXv 3ifA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=cAhuA6j0wn4+04Ohh5+SStFLIHkg+7HRmXWwpphSMmE=; b=h+f4bgRiY0F/xHoJsbid/RghX6AFi1CsLyukz/Zgl0Ue4AFHx3lx8ePE1TaqACATlR hLSSMfFenv5UvUiHdEN/rrxsF37kZIU/6yi/eOzhVSy69dTrqaOtr7Un3tjyt1nE/8fR DOpJ5Cm5lm4yYoPnQP/xAH1GByIwzxiz+IH6xFSxnc6WJNy03hXnKaOCsR2Avx6kOTRN wqgWFpRzvdcdzqvYm85XGX93TtRE18DdiJWOq2u/YTmPxpJc3qEhj894je4It4iC5ds+ 0iRStfYVqKkQCdmBcWeHTpiK5D6uSPyZ2TqzCdxX0a2I+da219+4NKzz/Bnk7EznHLOf kh5Q== X-Gm-Message-State: AA+aEWZhA+hViqNSW+/xhXqp4sym9JuyLp3lFVaCkDdoQqM3rOg0K913 PehEjB2pQOvu1t34jrLAoix9yJNniRc= X-Google-Smtp-Source: AFSGD/XR+xv40+goEyGtE6GYQYYXE5ctRYOqXGr/DOKuICT2gn7N7Iqw3ETUzYvL4YhCMGCWGatQzQ== X-Received: by 2002:a1c:cf0d:: with SMTP id f13mr18800404wmg.70.1544100004917; Thu, 06 Dec 2018 04:40:04 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id l202sm1217431wma.33.2018.12.06.04.40.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 04:40:04 -0800 (PST) To: Fernando Gont , Brian E Carpenter , Gert Doering , Christopher Morrow Cc: heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> From: Stewart Bryant Message-ID: Date: Thu, 6 Dec 2018 12:40:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 12:40:09 -0000 On 06/12/2018 02:37, Fernando Gont wrote: > On 5/12/18 21:14, Brian E Carpenter wrote: >> On 2018-12-05 21:52, Gert Doering wrote: >>> Hi, >>> >>> On Tue, Dec 04, 2018 at 10:57:43PM -0500, Christopher Morrow wrote: >>>> HA! ok. As gert/nick noted ... we have Nx100G links today (at the edge) and >>>> coming nx400G ... there's just not a reasonable story for "dpi" there. (I >>>> suppose: "yet" and "without paying the approximate value Coca-Cola >>>> Companies yearly advertising budget") >>> Indeed. >>> >>> Unfortunately, there *is* a story for being able to rate-limit incoming >>> crap by protocol type - "give me no more than 200 Mbit/s of UDP packets >>> coming from source port 53". >>> >>> Which implies that as soon as the evil guys out there find a way to >>> generate DDoS streams carrying EHs that our border routers will (have to) >>> apply very strict rate limiting to everything they do not understand. >>> >>> - pass TCP >>> - rate-limit UDP on well-known reflective attacks port >>> - pass rest of UDP >>> - rate-limit ICMP >>> - rate-limit fragments >>> - rate-limit all the rest to something which can never exceed a customer's >>> access-link >>> >>> game over, EH >> Just to point out that this is equivalent to saying "game over, any new layer 4 protocol" too. For example, you just killed SCTP. And the same goes for new protocols over IPv4. > Not exactly the same. If you are using a new transport protocols (*) > without any EHs, you have already found the upper-layer protocol. May > allow or drop, but that's it. With EHs, if you need to do packet > filtering or ECMP, you need to follow the EH chain.The later > (particularly if the EH) is normally going to cause issues, where the > former would not. I think the problem is that it is very difficult to teach the core about any new transport protocol. - Stewart From nobody Thu Dec 6 04:57:48 2018 Return-Path: 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 AA2F6130DFE for ; Thu, 6 Dec 2018 04:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 RmQEbMu4DPcY for ; Thu, 6 Dec 2018 04:57:30 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B97130DEA for ; Thu, 6 Dec 2018 04:57:28 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5C97C41B3A for ; Thu, 6 Dec 2018 13:57:26 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 49A8440B9E; Thu, 6 Dec 2018 13:57:26 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 3A589FD3B; Thu, 6 Dec 2018 13:57:26 +0100 (CET) Date: Thu, 6 Dec 2018 13:57:26 +0100 From: Gert Doering To: Stewart Bryant Cc: Brian E Carpenter , Gert Doering , Christopher Morrow , heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-ID: <20181206125726.GG1543@Space.Net> References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L+vyn3np+Um+N09T" Content-Disposition: inline In-Reply-To: <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 12:57:32 -0000 --L+vyn3np+Um+N09T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Dec 06, 2018 at 10:28:53AM +0000, Stewart Bryant wrote: > However, aren't we moving to a world where new protocols get carried=20 > over UDP anyway? Over HTTPS, you intended to say? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --L+vyn3np+Um+N09T Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwJHLMACgkQ31bAZeTO f8XAGw/5AXidFQFfN/q78pe4MLmi220ba2zyeWw5DeH6MF1zwe842HhkiCABXCNZ veYGvV2scuv9TBe+mcqYOHUpGqQT6g3ZjXYHuLvhCi/BmwFerDfWUhZWIkWXAFqK rArcE8ckc0mafoejbVOvHf53s+Zr/i0RuRAQdjVkISVCUgG2IlNTW9zE1MdCWgRI fzfC6ldlyI4egCdKV2ziYc4U8SGkKLbBql5iIvkjRrODlrfrBjfQ5DY2Z39dXygO mJvVyiVnNYZSthCzvjGjcDyB1IRQR74j3pD1t8yWuDF1gdci2MAuHG4j/lkmVcPY TXktdun5XELseVyrCtZAtG7eqBBikfQVDT1M5QY6/U3Zhr2SoMDg9LtwKAruQhps HASRNRyr653cm11ostnx28PCN4cdc8nAeoFHUp+Q/9Ul+5w5FPfMdurS5/GldUmc 0pAmmLnWbrgTnqOTrj0aQEko8KOR2Gm1KImTxs4HK/SREuSO7jNt/PmQXtd3rj7Y orVfE5YzJ7Tw8PGaakr7e4Fb5diueFRE6Tx8DAdANDWH+5IRQ4DdJN+4Ot9oERpO 78qZwuXAfok6s78fo3bYg9mIqQVTrmfh8PYa0tXX64GDfBzaDWwHhaL+GE5lq36v eVXZ2yhrCw2H02fj2oeILzY/DvEMiDn8h4QDDg4QgZo/jSSl5sM= =y9tq -----END PGP SIGNATURE----- --L+vyn3np+Um+N09T-- From nobody Thu Dec 6 05:16:56 2018 Return-Path: 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 5E2B0130E92; Thu, 6 Dec 2018 05:16:34 -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 hFQ01lD2FqBl; Thu, 6 Dec 2018 05:16:32 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 2FA15130DEA; Thu, 6 Dec 2018 05:16:32 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id r24so14122033wmh.0; Thu, 06 Dec 2018 05:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=/W8akYrSWGTHRthEChFmnyNk3AXYGHW++UbiWyQrlcw=; b=SCdimgJ+zZs+iIin9gqkOVSTBSBWwuoOqexj4MUVOmsr1wuMSavLfv2JFpF0tiQbHm LJL4IrbOxgmgQkY17vEEwP3bYOmqp0xSR2Qvdcp6nHytbLl3nKEjsm16BKL4CHZmK+Gp 07ya7UWBVTbgsewSkB46ayrPWeEslCNkhLva2oo3lN7a8YLx/GT/1el6UEJK6+i8kxTY xc3SdNAqLn3wI/jpR08eBukyw9ZJRtjqkZwi8GXvLXaz/Wbuu42Jv86ldIkBpP546fgC 8Wt13zzqw4L23qVaYo4Kb+sdZrbSX5BveBm6ne4XgNQ4haZUjk/MBYAboy7Ormpw4VQU 0LXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/W8akYrSWGTHRthEChFmnyNk3AXYGHW++UbiWyQrlcw=; b=OXUICuw4B2NKaK3XlumCQigr5nNI1TJQzfg21K+1ch8ONNkwDGl++a126GvyBBgmnU aeW73GyHSkSZ+XZKwV9o2cvSSwIfnZVbjKAWz/ut+TROTNeu+Be0RIlnBJEzmqgeCl6k yl32CV07KwxeCyKeOCxnk1s3KKUAq+AOW99Zw4crNa12/MJPrvhjtbliPtaSyn/4u/An 2VPYW3QeOfPwVrHTqaelputFgUeCalcOhc7SZFc2Y+IFFPOiycfNltIhRtqXuJD9Uyo2 jWZtvtKpWSBOxdbZzMJ6SLiNGcql+j2JwMwqVS5cWVgMRKzixgIqUpURTlYDD/PGhJMy /8gg== X-Gm-Message-State: AA+aEWYL1BwEUxEAFTK4sm+kd+SpDKNqpC8CUNxQM7Iq5omJD1zbibFt R3V10rmaWZP309r2N3Smc3AGriQD X-Google-Smtp-Source: AFSGD/V7rC0Fc3uszzskTrUqCrB4YaogK/UWij7Wv7rCaipa7ZMfKkPMzk46TMXAiESxyDAY8KRv5Q== X-Received: by 2002:a7b:c315:: with SMTP id k21mr18924873wmj.145.1544102190431; Thu, 06 Dec 2018 05:16:30 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id k15sm543240wru.8.2018.12.06.05.16.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 05:16:29 -0800 (PST) To: Joe Touch , Christopher Morrow Cc: tsv-art@ietf.org, opsec wg mailing list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ietf References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.co m> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> From: Stewart Bryant Message-ID: <16aaf3de-d020-1540-c2e5-5a570b838313@gmail.com> Date: Thu, 6 Dec 2018 13:16:28 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 13:16:42 -0000 On 06/12/2018 05:22, Joe Touch wrote: > >> On Dec 5, 2018, at 9:01 PM, Christopher Morrow wrote: >> >> How is it, for example, different to put ipv6 packets into an MPLS path doing nothing along 'many' hops (except forwarding the packets along), and then once you pop out of the tunnel start processing the packet as you (joe) would want. > The hopcount doesn’t get decremented by L2. > > Joe MPLS is not L2. MPLS has two modes, one in which the TTL of the IP payload is decremented on ingress and the TTL across the MPLS path is ignored. In the other mode, the TTL of the IP packet minus one is copied into the MPLS label which is then decremented as the packet travels across the network at egress from the MPLS layer the TTL is copied back into the the IP packet. - Stewart From nobody Thu Dec 6 05:36:12 2018 Return-Path: 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 D3ED41277D2; Thu, 6 Dec 2018 05:36:10 -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 yOfb1L_Dr6-D; Thu, 6 Dec 2018 05:36:08 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 32C0D126CC7; Thu, 6 Dec 2018 05:36:08 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id c126so1067204wmh.0; Thu, 06 Dec 2018 05:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=jBdRFRwUiyJcptaE9gUN580D0C9ECU1NekEqw2HsXvE=; b=Te6I31lXc6yw4gwSnUM01ctihLG1T5oKzq591HtRo7dmN2VbP7i+ZnagU9qsukcEZT wEow7RZFwz9FjaIPEEJ3lsZ9XXFo2UmR6jusqTVb0Eiw+2yOTjvCOZpWFomPwCQDqvt7 YNaCeatxnrS4VNuvzvPwMYk6pNk9VOrV1hZ8Jlq1YWIOU8P3AB5ROf9lq9OuvhXVIfh1 QirLLaOvv+AcpX6lDbEbhNLSBckF4l0VrPc8W9H+6Q1RNRLmNjBUXRSe8fsAGi5N35T7 dRxXwdoO577K36JkrQSBWR7FnGpdWW/SLcl+hHz5WcVjGiQSBPGNekXlZ8jN/iYyTH3n R27g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jBdRFRwUiyJcptaE9gUN580D0C9ECU1NekEqw2HsXvE=; b=FvkkXey7e1lvl7UIUjFE0bKrCE2N3MjSAdWr0uQ+j1xCM35aGid20uQz6udxu6D7UI LQZVNOoS9IIO14hKuscmnM9J9cYWp6B2tqTDAOFYfiNhr3AfPWDJCtZn3PG7oyd2KUlu LpWiXvzmk+nZ8yc0MMiKzeRJrMOZZT7Ag0IwCOM5dXjmf4JewJnWnjBkbVNn7CzLUN2/ AjDyy5x1xSx3SR7QXoKENEdlSd11xW8EmJbYbWAsZWzpE9D0EMKkovvIfS6oKltH8mLj tVmHNbc+bMPWdmvBC54sOjTEPfNtIczILLIktg4HDl0zxLQP2WqoN8q5Pk4aLX3SxrBd t28A== X-Gm-Message-State: AA+aEWaq9794g6jG2TcHfwkBIOIHho8WkiGSZNALIUlxntcvwT6AL3qf +9UtELagw9Hyms/W/qjccg561u7Ot6Y= X-Google-Smtp-Source: AFSGD/VCGtkHcxV/c0Syisam1EM6npwENl5TC1R4CMIAbrwcVgBMtaL59NrGZ6IYyTaba8xsAU23MA== X-Received: by 2002:a1c:2b45:: with SMTP id r66mr19048943wmr.7.1544103366102; Thu, 06 Dec 2018 05:36:06 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id z12sm594438wrh.35.2018.12.06.05.36.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 05:36:04 -0800 (PST) To: Ole Troan Cc: Brian E Carpenter , Gert Doering , tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <99f0a622-b1f8-cc8a-dcba-a608c37eeb0c@gmail.com> From: Stewart Bryant Message-ID: Date: Thu, 6 Dec 2018 13:36:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 13:36:11 -0000 On 06/12/2018 11:42, Ole Troan wrote: > Stewart, > >>>> If it has to look at any it has a much more complex set of tests, or a >>>> large vector table given the way the EH space is fragmented. >>> Frankly doing it without a network processor seems wrong. You can't expect >>> an ASIC or FPGA based device to handle the EH structures. >> Something that has served the IETF well over the years is not to constrain the forwarding >> implementation, and I think we would be wise to continue in that mould. Also we need >> to remember that an NP is an application specific processor, and thus has various >> hardware assists. >> >> No one talks about the internals of an NP, and I am not current on any vendor's design, >> but it is reasonable to suggest that in addition to the s/w parser there might >> be a h/w parser that does the heavy lifting, i.e. if IPv6 packet of expected type, dec >> TTL and do what the TCAM say picking this ECMP option else parse it the hard way. >> >> Then there is something that we do not talk at all about in such designs: electrical power. >> There is no question that it takes more power to s/w parse a packet, and sooner of later >> the power burn of the Internet is going to come under scrutiny, and we will be asked >> to reduce its carbon footprint. > So you are arguing that we need to define ULPs that are easy for routers to parse? I don't see how you would conclude that from the above. What is needed is that whatever the parser needs to parse needs to be easy and cheap to parse. > At arbitrary depth? Because why would the buck stop at the UDP header when transport has moved one layer up? What is the status of the flow label in practice? As I said earlier in the thread, I know the five tuple is trusted for ECMP, but I hear very little discussion of the flow label being a trusted source of entropy to feed the ECMP selector. > As opposed to the 6man argument which is that IPv6 is explicitly designed to only require routers to need to process the first 40 bytes (with the one exception hook). > And the design of EHs is specifically done to make it hard to parse for intermediate devices… That seems a fundamentally bad idea. Why would you go out of your way to make something difficult when you never know what path future protocol development will take you? > Is that really the Internet we want? Of course it will be countered with encryption, but I foresee a raft of problems if the IETF as a whole would redefine the “formal Internet architecture”. I think I have been describing the Internet architecture as it exists today regardless of the what the RFCs say. - Stewart > Cheers, > Ole From nobody Thu Dec 6 05:38:31 2018 Return-Path: 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 D26111277D2; Thu, 6 Dec 2018 05:38:28 -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 gx3eCFW8biyV; Thu, 6 Dec 2018 05:38:27 -0800 (PST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 47E7D126CC7; Thu, 6 Dec 2018 05:38:27 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id c126so1075186wmh.0; Thu, 06 Dec 2018 05:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Y7GevbI+ts6X8Ipa/Jjq5AbXzvPiRV9T70NUtDwNPgU=; b=aAUHVRgUmra9Ar01CMuWqNIV1k9EOg5Ldi1LIb8FEAQekxQaWHwf5SZG8j3nOqENUq YAu3y8Hi13K3cskIRa5qJyW6lBkMi/Lwu1fozIdQC+aLxrIxC0SEy+LREDTnAsqGT6r3 RANDmHQTktdhPqtxojwGNq1OBze2slRrNwv+4PjekvVu0muPiLsMXkhLlKG4nxFHb5Zl h/K4bgXBJX4nfV1otRuuOpHDA0DLCeFtb8a7jV6bbGlSJkh1dP6YQJzin/CEWaBAvHXV 6SaRUAabqM0rxJcSDbn9CxyDVORYcSB4oFueOyfDNcIhhd4XT/e15obz1lTWhe1iUI/Y 9MVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Y7GevbI+ts6X8Ipa/Jjq5AbXzvPiRV9T70NUtDwNPgU=; b=qLsTfNLwDdUt1+GfDWj/hZ22Qh9X3oUk7wB7a8gmlklasCMgmGVpxH3beOF3TlmEos Th3ov9gDUHSib7+1FTcxhD6pRwGqIvTR4j3OqBegD/UjHra4e7zqaR2EohxpsPc496xZ NFAJL28y6KHYlasBn3Ph90wcN7pgI/X3j8Hy7+Sv5kPZnv+0QB01qUUvMTs+e5l8AB9I tNHoTk7OIFJjN6HaZoIMcDmyj2w1RMuiChiyXLxkQYkqAoOc8sEoW8FsFcJ16/DSO5AG zb1aKx4Cc9ZYLWlxAWRy3xAsbbh7Q3/mArzIYKApi6q7SnkKdJR71u71I4HS+mh0bDHV Mxbw== X-Gm-Message-State: AA+aEWZJuilafKGQnFcp5ivftLVNfnPaxxNqJJQbsLA+DgIsDse9Ayab pJBm+ShzI/+Nf2BQ6TvOaoZaX4w7+2s= X-Google-Smtp-Source: AFSGD/XAerY7VpwLcc4x6j8+BhX7YQD1/yBODOcOlb+DEsS9/OzIRTgddWYNO1bUIF5al2UJ2J2cpA== X-Received: by 2002:a1c:f509:: with SMTP id t9mr17139882wmh.76.1544103505457; Thu, 06 Dec 2018 05:38:25 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id z17sm636054wrv.2.2018.12.06.05.38.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 05:38:24 -0800 (PST) To: Gert Doering Cc: Brian E Carpenter , Christopher Morrow , heard@pobox.com, tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> From: Stewart Bryant Message-ID: Date: Thu, 6 Dec 2018 13:38:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181206125726.GG1543@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 13:38:29 -0000 On 06/12/2018 12:57, Gert Doering wrote: > Hi, > > On Thu, Dec 06, 2018 at 10:28:53AM +0000, Stewart Bryant wrote: >> However, aren't we moving to a world where new protocols get carried >> over UDP anyway? > Over HTTPS, you intended to say? Some and some. It depends on what aspect of the stack you spend your time thinking about. - Stewart > > Gert Doering > -- NetMaster From nobody Thu Dec 6 05:40:31 2018 Return-Path: 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 80DAE12DDA3 for ; Thu, 6 Dec 2018 05:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 3qKtoCtxGrIO for ; Thu, 6 Dec 2018 05:40:28 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557E1129385 for ; Thu, 6 Dec 2018 05:40:28 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3C2F141C20 for ; Thu, 6 Dec 2018 14:40:26 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 2228841135; Thu, 6 Dec 2018 14:40:26 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 1DBD1FF72; Thu, 6 Dec 2018 14:40:26 +0100 (CET) Date: Thu, 6 Dec 2018 14:40:26 +0100 From: Gert Doering To: Ole Troan Cc: Stewart Bryant , Brian E Carpenter , Gert Doering , tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-ID: <20181206134026.GH1543@Space.Net> References: <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <99f0a622-b1f8-cc8a-dcba-a608c37eeb0c@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UUTnfQ9jwG2TLY7y" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 13:40:31 -0000 --UUTnfQ9jwG2TLY7y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Dec 06, 2018 at 12:42:23PM +0100, Ole Troan wrote: > Is that really the Internet we want?=20 Is this question relevant? (And no, the Internet we have today is very much different from the=20 Internet I *want*, in a large number of aspects. I'd *love* to be back in the friendly and cooperative Internet of the 90ies, but I lack the necessary superpowers) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --UUTnfQ9jwG2TLY7y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwJJscACgkQ31bAZeTO f8VsYw/9G+3vc4EYRpbJqa4j3LfiH+UeVQgW5sHVKCkw6RcFbUNAm0PkTZ4F7EZS Iqry6bLLbuT6sz8q8qk8Yz26xpBF8V6ZEdBaSE2jjS0OQyyOkQt8NU1w0AN+QCtK LvlOGi9dq0ZAN5g9kxkqxiUrKGrUVT2QxDFFCG8Xk5SsFibFDB3toYYqg1KGt5Jd a6iSsTAOa2VrCUGzBJCw8Yk3hUJul0TgABL6xM2JqlnjC/svso/zwuEvTQufXUyT luJQk2J3skhgFfLNU6oCRJZaEj1aFbeNTLd5bSyylE0MAytiANDQjBdUthT7p7TF eDfBswivr5fuNfxT5UGIkqy5mWukib71bSzC5PLbPRH0d9BjeMFjfwgXmqZHRjNc nh8Rc4P0tWaotHNqsUgUumAm7no8zpU8AIMQFcouK5DqZGL2nskWsIEdgzwv79a8 2OPYyTbcrGJdrfTHoUm0Dxv1tvUmBJTB15pU+Zef9hvidB642cMqMh/xf6OkCGGo xJb8xfg1kdUeXowWt8BqhVONW/My1GDEctYsguCcCwf41pkdxUXnOnOUZYaU9IHs VnE/CHubLJolPLYvsMdQ7y4tSExY9IruKTJ0c0Fu59rCuNhNDM0ePGH6psZk8h3N sYXYdFUs4qdGwfZ8msmvcrf3xIamMsO0u5Oimb9Yzk3Nfv6Rljc= =5GnZ -----END PGP SIGNATURE----- --UUTnfQ9jwG2TLY7y-- From nobody Thu Dec 6 06:00:46 2018 Return-Path: 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 C07A6126C01; Thu, 6 Dec 2018 06:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 99Aa_1JIaSVs; Thu, 6 Dec 2018 06:00:34 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F23124D68; Thu, 6 Dec 2018 06:00:34 -0800 (PST) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 04866FECC075; Thu, 6 Dec 2018 14:00:34 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id E66A3AB7454; Thu, 6 Dec 2018 15:00:28 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Ole Troan In-Reply-To: Date: Thu, 6 Dec 2018 15:00:28 +0100 Cc: Brian E Carpenter , Gert Doering , tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <99f0a622-b1f8-cc8a-dcba-a608c37eeb0c@gmail.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 14:00:37 -0000 Stewart, >> So you are arguing that we need to define ULPs that are easy for = routers to parse? > I don't see how you would conclude that from the above. What is needed = is that whatever the parser needs to parse needs to be easy and cheap to = parse. =E2=80=9Cwhat=E2=80=99s needed=E2=80=9D is clearly something which is = very contentious. There is a reason why encryption by default is a = necessity. >> At arbitrary depth? Because why would the buck stop at the UDP header = when transport has moved one layer up? > What is the status of the flow label in practice? As I said earlier in = the thread, I know the five tuple is trusted for ECMP, but I hear very = little discussion of the flow label being a trusted source of entropy to = feed the ECMP selector. I don=E2=80=99t know. I hear the situation is improving. Would be great = if someone with access to a large packet trace could tell us. That said, you will not always find the ports. fragmented packets, Non = TCP/UDP protocols (GRE, IPinIP etc). You need to tackle that case too. At least with the flow label you would be able to ECMP correctly for a = session containing both fragmented and not fragmented packets. >> As opposed to the 6man argument which is that IPv6 is explicitly = designed to only require routers to need to process the first 40 bytes = (with the one exception hook). >> And the design of EHs is specifically done to make it hard to parse = for intermediate devices=E2=80=A6 > That seems a fundamentally bad idea. Why would you go out of your way = to make something difficult when you never know what path future = protocol development will take you? It was a value desicion. Any time the network starts to dwelve deeply = into packets that prohibits innovation and end to end transparency. Of course it wasn=E2=80=99t a perfect solution. Encryption is the only = thing that can =E2=80=9Csolve=E2=80=9D it properly. >> Is that really the Internet we want? Of course it will be countered = with encryption, but I foresee a raft of problems if the IETF as a whole = would redefine the =E2=80=9Cformal Internet architecture=E2=80=9D. > I think I have been describing the Internet architecture as it exists = today regardless of the what the RFCs say. Sure. But I think the IETF=E2=80=99s signal effect is quite important. And we are doing quite a bit to rectify the current state. If everything = is encrypted. Sure, you might have a UDP header to do ECMP on, but you = would need other indicators to detect attack traffic. Cheers, Ole= From nobody Thu Dec 6 06:04:49 2018 Return-Path: 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 EA93512D4EA; Thu, 6 Dec 2018 06:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=strayalpha.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 Od0kubSQ-gdu; Thu, 6 Dec 2018 06:04:36 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89036126C01; Thu, 6 Dec 2018 06:04:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NNORlvKwXpkKNdFFAzRzHfhx5k41pSJHtQRUhraMYRc=; b=EqSqZASbzY6vASqHM5aFXJ2+C Lh0os/SQEJ5xwHL/h9/tM2w6TPPzESzHbXV15bL7D+qRLlgDGHnbmTsdKDSujoQ+KoJDt0EaPebFW /Gv56gqQ9dk/D+Wai9QHwDqgX5dH9HLhTr06yXOH9ZpNbu4G+PCGVmDV2VpP69V9yT+psxhUBCpqU 6E3cdx/32B47YkZornQWnPlNS+CK7wztJvj7EBEc+c87o/bi99zqi8L+bbXOpLM8qlAmKDl5rst50 6qGz4Id0lrYSRqUXmBm6yZt6803UtIAltQ+/8Tz52GQSoixzAVGKPRkdshxIEgSe3DBQAUSnWMia6 Z55PiZx4Q==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57444 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUuGU-0004Sg-Ja; Thu, 06 Dec 2018 09:04:35 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <16aaf3de-d020-1540-c2e5-5a570b838313@gmail.com> Date: Thu, 6 Dec 2018 06:04:30 -0800 Cc: Christopher Morrow , tsv-art@ietf.org, opsec wg mailing list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ietf Content-Transfer-Encoding: quoted-printable Message-Id: <3B4751F2-6C26-4F6E-826F-7E624AD76CE5@strayalpha.com> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.co m> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> <16aaf3de-d0 20-1540-c2e5-5a570b838313@gmail.com> To: Stewart Bryant X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 14:04:39 -0000 Your right - it=E2=80=99s a broken L2. Only routers are supposed to decrement TTLs. Links and tunnels themselves ar= en=E2=80=99t. Joe > On Dec 6, 2018, at 5:16 AM, Stewart Bryant wrot= e: >=20 >=20 >=20 >> On 06/12/2018 05:22, Joe Touch wrote: >>=20 >>> On Dec 5, 2018, at 9:01 PM, Christopher Morrow = wrote: >>>=20 >>> How is it, for example, different to put ipv6 packets into an MPLS path d= oing nothing along 'many' hops (except forwarding the packets along), and th= en once you pop out of the tunnel start processing the packet as you (joe) w= ould want. >> The hopcount doesn=E2=80=99t get decremented by L2. >>=20 >> Joe >=20 > MPLS is not L2. >=20 > MPLS has two modes, one in which the TTL of the IP payload is decremented o= n ingress and the TTL across the MPLS path is ignored. In the other mode, th= e TTL of the IP packet minus one is copied into the MPLS label which is then= decremented as the packet travels across the network at egress from the MPL= S layer the TTL is copied back into the the IP packet. >=20 > - Stewart From nobody Thu Dec 6 06:06:27 2018 Return-Path: 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 9E497126BED; Thu, 6 Dec 2018 06:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5oN6eAZA1xmC; Thu, 6 Dec 2018 06:06:11 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 434E8126C01; Thu, 6 Dec 2018 06:06:09 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id l15-v6so498829lja.9; Thu, 06 Dec 2018 06:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V2dz4DfbAGemHPilTxOTMNCxAueRnogsJweW9tHsbH8=; b=SaZPJz+jzjCIpMnBsP5L6im8RZvzBsYK42xkpjbpidP8wyBuCrjopwPclP+bPkJary dLoK7PcpgOHI4c/pfLgEQOglmeqPUoBYcaqRFIc4w7uxUNsoZncnvAFr0HWT62YPNTpv n5hxnidHx2jAKajFIWHesRR/qarjJ7RTA/sq+fiZmyXmaSRT0ZL24oOEOdWKWmybFboO fqSRwsZZKHPHu9/djiU/O0xF3+YITRj1CvZa2+c6u6LZije5fm1R722pyVspDG0tSXwo XAaI03L16+WNioQ9YUzJ89oPY6dOwRKhsB3ARXDyTtt6uTCm/iGthx7XJE2tbQvaMdGJ +kRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V2dz4DfbAGemHPilTxOTMNCxAueRnogsJweW9tHsbH8=; b=hxpEUYj4kCocznFMbQVyq5Lnsrtdyg1LvI1kF51CIxfaWvrceBDrweSg8j5tyUzflD 40SLD0nHjfhOyj9mHgWDkXi02sA5YyN2Spi72sZ9NiuTg3izI3yPO+DYJNPk8hhQNn29 uSzx5XyigGeBy1qYL7nAUoWw2AObUrF40u2XAAMTvVyR1nb2n2BFMKYEKmv1uK945IDl yDoeYumBWgj/RC5sTbhL3c7LQgf0cNmZmrLmN8Bri1OqwwIfg8x4Z6GPAbhKf9EBuAFn KVaxL/sQ5All2JZZREy5jEv4apYOLP+X3//xtqYunHMBpD5Pxis2q0784qE1RA4nMjuD rRgw== X-Gm-Message-State: AA+aEWbadGYskBujyLSYbZVG2PDE48h2t7Xs1QTEN2H4jOgXt6892gBW Jt8zmmw7Tdv+UCU7Yiso8yhfWpynSlmK7LEEoBE= X-Google-Smtp-Source: AFSGD/WbnVheTCL69RqoK6A+v2Y65Lbu7qQrOgmBpnIcHaGeQSfbz0kNSM4h6PHZhoIUGnfw/5uAKvfiAoMe3uJoY70= X-Received: by 2002:a2e:9dcb:: with SMTP id x11-v6mr20494795ljj.158.1544105167305; Thu, 06 Dec 2018 06:06:07 -0800 (PST) MIME-Version: 1.0 References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 6 Dec 2018 08:05:53 -0600 Message-ID: To: Stewart Bryant Cc: gert@space.net, IETF list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, morrowc.lists@gmail.com, opsec@ietf.org, tsv-art@ietf.org, Brian E Carpenter Content-Type: multipart/alternative; boundary="000000000000fe4306057c5aff43" Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 14:06:15 -0000 --000000000000fe4306057c5aff43 Content-Type: text/plain; charset="UTF-8" Speaking as an individual who ballots on working group charters ... On Thu, Dec 6, 2018 at 7:38 AM Stewart Bryant wrote: > > > On 06/12/2018 12:57, Gert Doering wrote: > > Hi, > > > > On Thu, Dec 06, 2018 at 10:28:53AM +0000, Stewart Bryant wrote: > >> However, aren't we moving to a world where new protocols get carried > >> over UDP anyway? > > Over HTTPS, you intended to say? > Some and some. It depends on what aspect of the stack you spend your > time thinking about. > "you're both right" :-) ... As noted earlier in this thread, we punted new transport protocols into UDP encapsulation at roughly the "we can't get SCTP deployed at scale, we can't get DCCP deployed at scale, and we don't see any reason to think that any new transport protocol will be any different" stage, at least a decade ago. So, when I see people talking about SCTP, it's usually in a context like RTCWeb, where the stack looks like SCTP/DTLS/UDP, and QUIC is only defined over UDP. (I suspect the world would have been a slightly better place if we'd done the DCCP encapsulation in UDP from day 1, because DCCP functionality could have been really useful when we started encapsulating every known network protocol in UDP, but that's not relevant to this discussion) But since QUIC's initial deliverable includes its HTTP mapping, https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ comes into play. I would oversimplify that draft as saying "we are way more excited about applications using HTTP as a substrate now, than we were in 2002", so, yes, the future smells a lot like HTTPS over (mumble) over UDP, at least to me. I don't know that's a perfect plan, but I've been balloting on working group charters for at least 3 years, assuming that it's a plan. Spencer > - Stewart > > > > > Gert Doering > > -- NetMaster > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > --000000000000fe4306057c5aff43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking as an individual who ballots on = working group charters ...=C2=A0

On Thu, Dec 6, 2018 at 7:38 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:


On 06/12/2018 12:57, Gert Doering wrote:
> Hi,
>
> On Thu, Dec 06, 2018 at 10:28:53AM +0000, Stewart Bryant wrote:
>> However, aren't we moving to a world where new protocols get c= arried
>> over UDP anyway?
> Over HTTPS, you intended to say?
Some and some.=C2=A0 It depends on what aspect of the stack you spend your =
time thinking about.

"you're b= oth right" :-) ...=C2=A0

As noted earlier in = this thread, we punted new transport protocols into UDP encapsulation at ro= ughly the "we can't get SCTP deployed at scale, we can't get D= CCP deployed at scale, and we don't see any reason to think that any ne= w transport protocol will be any different" stage, at least a decade a= go. So, when I see people talking about SCTP, it's usually in a context= like RTCWeb, where the stack looks like SCTP/DTLS/UDP, and QUIC is only de= fined over UDP.=C2=A0

(I suspect the world would h= ave been a slightly better place if we'd done the DCCP encapsulation in= UDP from day 1, because DCCP functionality could have been really useful w= hen we started encapsulating every known network protocol in UDP, but that&= #39;s not relevant to this discussion)

But since Q= UIC's initial deliverable includes its HTTP mapping,=C2=A0https://datatr= acker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ comes into play. I woul= d oversimplify that draft as saying "we are way more excited about app= lications using HTTP as a substrate now, than we were in 2002", so, ye= s, the future smells a lot like HTTPS over (mumble) over UDP, at least to m= e.

I don't know that's a perfect plan, but= I've been balloting on working group charters for at least 3 years, as= suming that it's a plan.=C2=A0

Spencer
=C2=A0
- Stewart<= br>
>
> Gert Doering
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster

_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org<= br> https://www.ietf.org/mailman/listinfo/tsv-art
--000000000000fe4306057c5aff43-- From nobody Thu Dec 6 06:12:22 2018 Return-Path: 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 0CCF9127B92; Thu, 6 Dec 2018 06:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=strayalpha.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 yWwA_7KI13sM; Thu, 6 Dec 2018 06:11:53 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6D3130E29; Thu, 6 Dec 2018 06:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QQudNOx8wyKSMcwl14YtxNR3BU8oYz8ibdmC0BL7w7s=; b=DYrnJf5sSs3eLmDA3yD1TobJ4 4Ms5Q2HeSQfoFOG5p582U1UE7bpDKnMqu5QxRDYhAeoK6lGuHI6NWTyXVuWYcfvcwwJjxkj/eN2fm h1MVlxOoJd3QtBsonygJYsgd3N36wuSArLHb8GHtVa0kMkhijKZihzvcEkUnrb2uJSPUv49/ybNsX bInOQ1Y0mEWNH+npr3jklE1BHKWPgXcOrwzwp3uR1pVUNDG0wsCJmalFXe9pUCf+g3OU4BzbcSusA gnCMHLnhYW2NzPrsseEG3IKD+rSRQ3mt4KS0bvoSOK6Cw5YZf2Y31uDXls3FN3UFcUDCGWz4heWNV p2rOoUb4Q==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57449 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUuNT-000BW9-Ke; Thu, 06 Dec 2018 09:11:48 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-1AD83D75-303F-43AA-AE9D-EB05966CAF51 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: Date: Thu, 6 Dec 2018 06:11:43 -0800 Cc: tsv-art@ietf.org, opsec wg mailing list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ietf Content-Transfer-Encoding: 7bit Message-Id: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> <811D965A-149E-4E33-A526-2CFCB7A1882B@strayalpha.com> To: Christopher Morrow X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 14:12:05 -0000 --Apple-Mail-1AD83D75-303F-43AA-AE9D-EB05966CAF51 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Dec 5, 2018, at 10:28 PM, Christopher Morrow w= rote: >=20 >=20 >=20 >> On Thu, Dec 6, 2018 at 12:31 AM Joe Touch wrote: >> Additionally, packets don=E2=80=99t emerge from different mole endpoints o= r are IP processed in any way. The mold acts like a wire, which is fine. Th= at can be done by IP tunnels too. But not routers that converge and diverge p= ackets.=20 That got mangled by autocorrect. Packets aren=E2=80=99t supposed to be IP p= rocessed by links. To the extent that MPLS does this, it is broken vs the In= ternet arch. Remember that MPLS tries to emulate a router path that can=E2=80= =99t keep up. It can - and does - fail to do so correctly in some cases. >> Again, if HBH headers are meaningless and not needed, then go through the= proper process and remove them from IPv6. If not, stop trying to hobble thi= s protocol to the point where we all realize why nobody wants to use it.=20 >>=20 >=20 > I think everyone here is actually happy to see v6 progress. As am I - in Standards. It shouldn=E2=80=99t =E2=80=98progress=E2=80=99 on o= ps. > note I'm not trying to be intentionally combative, just attempting to say:= "the best answer for the user here is PROBABLY to just have the core ignore= all the EH business entirely"=20 Again, if they=E2=80=99re not needed, fine. Remove them in Standards. However, if the role of ops is to decide what standards to ignore, then perh= aps the IESG should reconsider the area=E2=80=99s charter. Joe= --Apple-Mail-1AD83D75-303F-43AA-AE9D-EB05966CAF51 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Dec 5, 2018, at 10:28 PM, Christopher Morrow &= lt;morrowc.lists@gmail.com>= ; wrote:



On Thu, Dec 6, 201= 8 at 12:31 AM Joe Touch <touch@st= rayalpha.com> wrote:
Additiona= lly, packets don=E2=80=99t emerge from different mole endpoints or are IP&nb= sp; processed in any way. The mold acts like a wire, which is fine. That can= be done by IP tunnels too. But not routers that converge and diverge packet= s.

That g= ot mangled by autocorrect.  Packets aren=E2=80=99t supposed to be IP pr= ocessed by links. To the extent that MPLS does this, it is broken vs the Int= ernet arch.  Remember that MPLS tries to emulate a router path that can= =E2=80=99t keep up.  It can - and does - fail to do so correctly in som= e cases.

Again, if HBH headers are meaningless and not needed, then go through the pr= oper process and remove them from IPv6. If not, stop trying to hobble this p= rotocol to the point where we all realize why nobody wants to use it.

I think everyone here is actually happy t= o see v6 progress.

As am I= - in Standards.  It shouldn=E2=80=99t =E2=80=98progress=E2=80=99 on op= s.

note I'm not trying to be intentionally combative,= just attempting to say: "the best answer for the user here is PROBABLY to j= ust have the core ignore all the EH business entirely" 

Again, if they=E2=80=99re not needed, fine= . Remove them in Standards.

However, if the role of= ops is to decide what standards to ignore, then perhaps the IESG should rec= onsider the area=E2=80=99s charter.

Joe
= --Apple-Mail-1AD83D75-303F-43AA-AE9D-EB05966CAF51-- From nobody Thu Dec 6 06:13:41 2018 Return-Path: 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 A669B130E70; Thu, 6 Dec 2018 06:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 sbv7zpVJAeu9; Thu, 6 Dec 2018 06:13:27 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6178127598; Thu, 6 Dec 2018 06:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Mucae9UXLTGbe+vcSNeAp/yVrfkgl8J57JFGHhgVK1A=; b=LoN6jV36Z9ELPhWlwh8+pU7tW s6H1ndjSnNnif8MCczxlMYw2rChCc2OSt366xQUJEKqmDBQTv4GMVCiAmSq06fWKpqYYXxbZJYT53 sZ1ZIF+OnijQEBmKkrku5elkpcF0Br9vwHnTwyorxrPfCnQ5Wi6wd+PP423yx9K8RJ7QTNBWFu3hx p1Zj08pYO0Ta0wLrocMGjI4Mh1E3mkDhXG0nnz0LbjtwDo3pBAof40OlzpIg1aU4NjZHaRWKH74QC yxFBrqr1wXx2egNtA78sulNPEDaH+TpaSEZYzOYwdT8xDozM8qTt7aqAA+UqcNDfNIPWYXn/7bZD0 R7BAdLbIg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57454 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUuOy-000Cm4-Vc; Thu, 06 Dec 2018 09:13:18 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <20181206092221.GD1543@Space.Net> Date: Thu, 6 Dec 2018 06:13:16 -0800 Cc: Christopher Morrow , tsv-art@ietf.org, opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <103CB0D1-4CC3-4ABB-AF0A-4BB1A8131D51@strayalpha.com> References: <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> <811D965A-149E-4E33-A526-2CFCB7A1882B@strayalpha.com> <20181206092221.GD1543@Space.Net> To: Gert Doering X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 14:13:33 -0000 > On Dec 6, 2018, at 1:22 AM, Gert Doering wrote: >=20 > Hi, >=20 >> On Wed, Dec 05, 2018 at 09:31:32PM -0800, Joe Touch wrote: >> Again, if HBH headers are meaningless and not needed, then go through the= proper process and remove them from IPv6. If not, stop trying to hobble thi= s protocol to the point where we all realize why nobody wants to use it.=20 >=20 > I don't think "lack of extensibility" is the major showstopper in=20 > IPv6 deployment. Then remove EHs. IN STANDARDS. > have you enabled IPv6 on something today...? No, but I haven=E2=80=99d DISabled it either. Joe= From nobody Thu Dec 6 06:21:00 2018 Return-Path: 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 17653129385; Thu, 6 Dec 2018 06:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 KOLtXPWKVwAf; Thu, 6 Dec 2018 06:20:46 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06167130DFE; Thu, 6 Dec 2018 06:20:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PCQRwPVCDpqNPcHfZelSJ9/9vv7EaGtSOL5zOT97cRo=; b=oVZxtCWchY0pNkodWTiFXSLTm H9i3LDdBgu0I9HGknIhtZSG6/CnwxGTeG/M2lzve41XDWcZDmuNVJQWJjvOMyQE+Zhrzx1JfBR97S Uw5mA9ME8jgMSlYr7x+eiZ0pIzel8lESmWNLLddLzRZgKrKWpKQA0z0f7mwzbyRoeK83T9q/AHALg vGvUqXB6qJ+Lzxn1ftwepuqLowrGvtNr7UzjF921JMUovUKgRdgMfMsXOPP0oupehJzXuKmlsnVYL xCQEfrFMyUpu6Dqgklmv2LsXvU5tsVROa0fiNPevcpcnzG3ip3Cq5D5S89x0atGPyfgaIHP0e41+L 0/vosWczw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57470 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gUuW7-000Ij0-UJ; Thu, 06 Dec 2018 09:20:44 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-E858719B-C4B1-41B8-81A8-F4856C246567 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16B92) In-Reply-To: <19869497-A363-460F-9348-B40141F7600E@employees.org> Date: Thu, 6 Dec 2018 06:20:39 -0800 Cc: Brian E Carpenter , tsv-art , opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a 43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> <19869497-A363-460F-9348-B40141F7600E@employees.org> To: Ole Troan X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 14:20:58 -0000 --Apple-Mail-E858719B-C4B1-41B8-81A8-F4856C246567 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Dec 6, 2018, at 2:59 AM, Ole Troan wrote: >=20 > Joe, >=20 > I think you misunderstand. Read this text. Tell me what part of it you do not understand regarding node= s THAT DO NOT SUPPORT an option (if =E2=80=9Cskipping over=E2=80=9D isn=E2=80= =99t not supported, then what is it?): The Option Type identifiers are internally encoded such that their highest-o= rder 2 bits specify the action that must be taken if the processing IPv6 nod= e does not recognize the Option Type:=20 00 - skip over this option and continue processing the header.=20 ** 01 - discard the packet.=20 ** 10 - discard the packet and, regardless of whether or not the packet's De= stination Address was a multicast address, send an ICMP Parameter Problem, C= ode 2, message to the packet's Source Address, pointing to the unrecognized O= ption Type.=20 ** 11 - discard the packet and, only if the packet's Destination Address was= not a multicast address, send an ICMP Parameter Problem, Code 2, message to= the packet's Source Address, pointing to the unrecognized Option Type. >> I=E2=80=99m talking about a conflict in the text of 8200 - which has thos= e fields as required to support - and 7045, which says they can be silently i= gnored. >=20 > 8200 says: > If the router is explicitly configured to process the HBH header it MUST a= dhere to the option flag 2 high order bits. > Otherwise it MUST forward the packet. >=20 > There is no conflict. The conflict is in the issue of =E2=80=9Cnot supported=E2=80=9D. Skipping ov= er headers means they=E2=80=99re not supported, but it=E2=80=99s not possibl= e to =E2=80=9CNOT SUPPORT=E2=80=9D them two different ways - one silent, one= that *requires* action. Joe= --Apple-Mail-E858719B-C4B1-41B8-81A8-F4856C246567 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Dec 6, 2018, at 2:59 AM, Ole Troan <otroan@employees.org> wrote:
Joe,

I think you misunderstand.

Read this text. Tell me what part of it you do not underst= and regarding nodes THAT DO NOT SUPPORT an option (if =E2=80=9Cskipping over= =E2=80=9D isn=E2=80=99t not supported, then what is it?):

The Option T=
ype identifiers are internally encoded such that their
   highest-order 2 bits specify the action that must be taken if the
   processing IPv6 node does not recognize the Option Type: 
 00 - s=
kip over this option and continue processing the header. =

** 01 - disc=
ard the packet. 
** 10 - discard the packet and, regardless of whether=
 or not the
           packet's Destination Address was a multicast address, send an
           ICMP Parameter Problem, Code 2, message to the packet's
           Source Address, pointing to the unrecognized Option Type. 
=
** 11 - discard the packet and, only if the packet's Destination
           Address was not a multicast address, send an ICMP Parameter
           Problem, Code 2, message to the packet's Source Address,
           pointing to the unrecognized Option Type.

I=E2=80=99m talking about a conflict in the text of 8200 -= which has those fields as required to support - and 7045, which says they c= an be silently ignored.

8200 s= ays:
If the router is explicitly configured to process the H= BH header it MUST adhere to the option flag 2 high order bits.
Otherwise it MUST forward the packet.

Th= ere is no conflict.

The con= flict is in the issue of =E2=80=9Cnot supported=E2=80=9D. Skipping over head= ers means they=E2=80=99re not supported, but it=E2=80=99s not possible to =E2= =80=9CNOT SUPPORT=E2=80=9D them two different ways - one silent, one that *r= equires* action.

Joe
= --Apple-Mail-E858719B-C4B1-41B8-81A8-F4856C246567-- From nobody Thu Dec 6 06:34:51 2018 Return-Path: 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 2C3E0126BED; Thu, 6 Dec 2018 06:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Xgb9vWxt1QOj; Thu, 6 Dec 2018 06:34:36 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CFA126C7E; Thu, 6 Dec 2018 06:34:36 -0800 (PST) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id BCBF5FECC099; Thu, 6 Dec 2018 14:34:34 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 46BDFAB828B; Thu, 6 Dec 2018 15:34:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Ole Troan In-Reply-To: Date: Thu, 6 Dec 2018 15:34:31 +0100 Cc: Brian E Carpenter , tsv-art , opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A867D05-8DF5-496F-974D-EBA509E2BFA8@employees.org> References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a 43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> <19869497-A363-460F-9348-B40141F7600E@employees.org> To: Joe Touch X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 14:34:38 -0000 Joe, > Read this text. Tell me what part of it you do not understand = regarding nodes THAT DO NOT SUPPORT an option (if =E2=80=9Cskipping = over=E2=80=9D isn=E2=80=99t not supported, then what is it?): >=20 > The Option Type identifiers are internally encoded such that their = highest-order 2 bits specify the action that must be taken if the = processing IPv6 node does not recognize the Option Type:=20 > 00 - skip over this option and continue processing the header.=20 > ** 01 - discard the packet.=20 > ** 10 - discard the packet and, regardless of whether or not the = packet's Destination Address was a multicast address, send an ICMP = Parameter Problem, Code 2, message to the packet's Source Address, = pointing to the unrecognized Option Type.=20 > ** 11 - discard the packet and, only if the packet's Destination = Address was not a multicast address, send an ICMP Parameter Problem, = Code 2, message to the packet's Source Address, pointing to the = unrecognized Option Type. >=20 >>> I=E2=80=99m talking about a conflict in the text of 8200 - which has = those fields as required to support - and 7045, which says they can be = silently ignored. >>=20 >> 8200 says: >> If the router is explicitly configured to process the HBH header it = MUST adhere to the option flag 2 high order bits. >> Otherwise it MUST forward the packet. >>=20 >> There is no conflict. >=20 > The conflict is in the issue of =E2=80=9Cnot supported=E2=80=9D. = Skipping over headers means they=E2=80=99re not supported, but it=E2=80=99= s not possible to =E2=80=9CNOT SUPPORT=E2=80=9D them two different ways = - one silent, one that *requires* action. I don=E2=80=99t know where you found the use of =E2=80=9Csupport=E2=80=9D.= The text from RFC8200 is: The Option Type identifiers are internally encoded such that their highest-order 2 bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: This only apply if you are actually processing the option in the first = place. Which is a change from RFC2460. Cheers, Ole= From nobody Thu Dec 6 06:36:14 2018 Return-Path: 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 C4040126C7E; Thu, 6 Dec 2018 06:35: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 5N22HE-ZS8aI; Thu, 6 Dec 2018 06:35:54 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 E611D126BED; Thu, 6 Dec 2018 06:35:53 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id v13so719720wrw.5; Thu, 06 Dec 2018 06:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=aTUSt7jqwwtj1ew39Br/kcYtE8bOUM6ioxjIaRjNc90=; b=lamvJB1vBDBCfU7/7NIn2/8MPHHPcXICN95KATh3c753fivVyUgsXvRcca/qibhN+h 6V9jgxXo7kyiBj892LYG5zMBNX/gJRYq4FdrJ0xq1XVLYrIasA97jJKnoCJ294lY4lw8 K5FZGXu5lozifRZqw3bxdxI49MDisPj7YH7aMzmitwDmOYz3+XvwlxPyC7PAqr7kl44a ygQFbZy5dlAwS4sHSPh3LoF/aijQX+g27ZrIsznEonFjLGLPZWQnzQXuZoPHUbHDLeu2 UaJ3P6UwGJ6ASPlsvLwxIKQCqNq8WUOl1nhWc/JGAzMo9y9+tFT6fctRzU8r5aKGM5NT nvPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=aTUSt7jqwwtj1ew39Br/kcYtE8bOUM6ioxjIaRjNc90=; b=uA8ujHnEOgkYLqUMnaB10mCnQUzutYw9i9Hv9NpUu+5CwsvvyeyQ5+YRXzV6sTAuOT CSgedjXzYtHWAJ5rmvOl9jVxaqqRMmQ0uniUTI6csk9pDY2u0A9S20DBSya/q2vk+dkp 3afmskjYZVVnUHfz6B3JjpKhiD5t+vFfKlSkjAPlSPDmEyqOvcaq0BkHY+sBx6EBXnhs eGC3W3lj/TbIVYM8oWKWk/sP480/efqpikEK0wrwCjnK/yu6mDO3zayiBQ9N5Ayo9umc gaLLPvYSCvtnwWbgKoctwl44PSVdzsDcPDhhP4FG1gMmyDjtf+JoXUcceFQep0XV7qxB 3TOw== X-Gm-Message-State: AA+aEWZavs0AnSxzK5cjcRYMHNiyxIhNFY3z38Gu+z1Xp49Pd/Haphjl s+nrwCjNgcJxY32zkDdqivSHsUAEI/4= X-Google-Smtp-Source: AFSGD/V+aSbjJyUT8pgxJLfGCZyvAFmaujxkuxXM/tkdlRoXl20qj5kkvDuCHnHjDdAtyeJG2dXhbw== X-Received: by 2002:adf:cc91:: with SMTP id p17mr26383105wrj.118.1544106952150; Thu, 06 Dec 2018 06:35:52 -0800 (PST) Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id o9sm1364093wmh.3.2018.12.06.06.35.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 06:35:51 -0800 (PST) To: Joe Touch Cc: Christopher Morrow , tsv-art@ietf.org, opsec wg mailing list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ietf References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.co m> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> <16aaf3de-d020-1540-c2e5-5a570b838313@gmail.com> <3B4751F2-6C26-4F6E-826F-7E624AD76CE5@strayalpha.com> From: Stewart Bryant Message-ID: Date: Thu, 6 Dec 2018 14:35:50 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3B4751F2-6C26-4F6E-826F-7E624AD76CE5@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 14:35:56 -0000 I disagree, although I image we will never agree on this. The devices in an MPLS router are called label switching routers for a reason, and in the most common form of operation the LFIB is populated with data derived from the IGP and EGP. There are many ways of thinking of MPLS labels, but one model is to consider them IP address equivalents, hence the use of the term Forwarding Equivalence Classes. - Stewart On 06/12/2018 14:04, Joe Touch wrote: > Your right - it’s a broken L2. > > Only routers are supposed to decrement TTLs. Links and tunnels themselves aren’t. > > Joe > >> On Dec 6, 2018, at 5:16 AM, Stewart Bryant wrote: >> >> >> >>> On 06/12/2018 05:22, Joe Touch wrote: >>> >>>> On Dec 5, 2018, at 9:01 PM, Christopher Morrow wrote: >>>> >>>> How is it, for example, different to put ipv6 packets into an MPLS path doing nothing along 'many' hops (except forwarding the packets along), and then once you pop out of the tunnel start processing the packet as you (joe) would want. >>> The hopcount doesn’t get decremented by L2. >>> >>> Joe >> MPLS is not L2. >> >> MPLS has two modes, one in which the TTL of the IP payload is decremented on ingress and the TTL across the MPLS path is ignored. In the other mode, the TTL of the IP packet minus one is copied into the MPLS label which is then decremented as the packet travels across the network at egress from the MPLS layer the TTL is copied back into the the IP packet. >> >> - Stewart From nobody Thu Dec 6 07:35:32 2018 Return-Path: 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 BAEB512F18C; Thu, 6 Dec 2018 07:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 8iIt3sMcFz2K; Thu, 6 Dec 2018 07:35:13 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C8F12DD85; Thu, 6 Dec 2018 07:35:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=B+8TJsiwQT6pGbEhgzjcu9Azg5+naQlIT/D196OKXOc=; b=Emjh0/BEvPrOjiGoMZ6HqPiEL3 cgfwAav/49lSKNRdIffPvXFXmHtmq2NMotGt/78SBnEmDY6En5Wsb1ds/YBqBGq+5++lPAxp6JPy9 5WyA9TL73k0B8EFwNi6qON6AzbIgoYNyBg5D4elGSSP1t7V/9Ign+3PHXkrUnrNOS6uXW+YDd/1S1 uS/iTzikBZW4JQ8o9Ol724G32XUjlJHqD0nDsueDbCwv2NkAooNKAW5L8xKfV9+Up4BddgsbgDGtq z7fHUwxbeCeZ1AOfLtIaLEHm0bAtJJ5TcU+oGKd5a86TVdoki4+T2yQ5scFPe0WSpjpNlpiZdQqIx wRwgZBlA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:54673 helo=[192.168.1.250]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gUvgD-001SS3-9L; Thu, 06 Dec 2018 10:35:09 -0500 To: Ole Troan Cc: Brian E Carpenter , tsv-art , opsec wg mailing list , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a 43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> <19869497-A363-460F-9348-B40141F7600E@employees.org> <2A867D05-8DF5-496F-974D-EBA509E2BFA8@employees.org> From: Joe Touch Message-ID: Date: Thu, 6 Dec 2018 07:35:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2A867D05-8DF5-496F-974D-EBA509E2BFA8@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 15:35:15 -0000 OK, all, So let's try it this way: - standards people on this list claim that 8200 already allows silently ignoring HBH options - ops people on this list claim that most routers already do this So if you accept the items above, then why exactly is this document needed at all? The standards already support it and operators already do it. It clearly isn't needed, just as clearly as it isn't driven by security issues. So I would conclude that whether we agree on the logical path, we have come to the same conclusion - drop this doc and move on. Joe From nobody Thu Dec 6 09:49:55 2018 Return-Path: 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 D3DCF12870E; Thu, 6 Dec 2018 09:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 EWxlQ4UcjkVG; Thu, 6 Dec 2018 09:49:43 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C0B130EEA; Thu, 6 Dec 2018 09:49:42 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4] (unknown [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2459882B7F; Thu, 6 Dec 2018 18:49:37 +0100 (CET) To: Stewart Bryant , Ole Troan Cc: Brian E Carpenter , Gert Doering , tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <99f0a622-b1f8-cc8a-dcba-a608c37eeb0c@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <8f45ad29-feb2-110d-2a4d-92f420b8908d@si6networks.com> Date: Thu, 6 Dec 2018 14:24:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 17:49:47 -0000 On 6/12/18 10:36, Stewart Bryant wrote: > > > On 06/12/2018 11:42, Ole Troan wrote: >> Stewart, >> >>>>> If it has to look at any it has a much more complex set of tests, or a >>>>> large vector table  given the way the EH space is fragmented. >>>> Frankly doing it without a network processor seems wrong. You can't >>>> expect >>>> an ASIC or FPGA based device to handle the EH structures. >>> Something that has served the IETF well over the years is not to >>> constrain the forwarding >>> implementation, and I think we would be wise to continue in that >>> mould. Also we need >>> to remember that an NP is an application specific processor, and thus >>> has various >>> hardware assists. >>> >>> No one talks about the internals of an NP, and I am not current on >>> any vendor's design, >>> but it is reasonable to suggest that in addition to the s/w parser >>> there might >>> be a h/w parser that does the heavy lifting, i.e. if IPv6 packet of >>> expected type, dec >>> TTL and do what the TCAM say picking this ECMP option else parse it >>> the hard way. >>> >>> Then there is something that we do not talk at all about in such >>> designs: electrical power. >>> There is no question that it takes more power to s/w parse a packet, >>> and sooner of later >>> the power burn of the Internet is going to come under scrutiny, and >>> we will be asked >>> to reduce its carbon footprint. >> So you are arguing that we need to define ULPs that are easy for >> routers to parse? > I don't see how you would conclude that from the above. What is needed > is that whatever the parser needs to parse needs to be easy and cheap to > parse. At the end of the day, it ends up being the call of the folks running the net. -- see RFC7872. "I'm gonna make it hard for your to parse the packets" "OK, good. I'll just drop them. Good luck. Bye". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 6 10:00:39 2018 Return-Path: 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 DF7D9130EE9; Thu, 6 Dec 2018 10:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4N-MtJof5_ot; Thu, 6 Dec 2018 10:00:25 -0800 (PST) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B732130E4E; Thu, 6 Dec 2018 10:00:25 -0800 (PST) Received: from lxdnp04n.corp.intranet (lxdnp04n.corp.intranet [151.119.92.83]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id wB6I044D014695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 6 Dec 2018 11:00:04 -0700 Received: from lxdnp04n.corp.intranet (localhost [127.0.0.1]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6Hxxf0015367; Thu, 6 Dec 2018 10:59:59 -0700 Received: from lxomp07u.corp.intranet (lxdnp23m.corp.intranet [151.119.92.134]) by lxdnp04n.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6HxxpN015360 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Thu, 6 Dec 2018 10:59:59 -0700 Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6Hxw7J009905; Thu, 6 Dec 2018 11:59:58 -0600 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6HxwSo009891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2018 11:59:58 -0600 Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([151.119.128.28]) with mapi id 14.03.0399.000; Thu, 6 Dec 2018 10:59:58 -0700 From: "Smith, Donald" To: Gert Doering , Joe Touch CC: ietf , "draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org" , Nick Hilliard , OPSEC , Christian Huitema , tsv-art , Brian E Carpenter Thread-Topic: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 Thread-Index: AQHUhNdCbiFCjL0JakC1wd59pxI7xKVhWRaAgAAQqYCAAJBDgIAALRcAgA/pX8g= Date: Thu, 6 Dec 2018 17:59:58 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D53E5B552@PDDCWMBXEX503.ctl.intranet> References: <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com>, <20181126075746.GO72840@Space.Net> In-Reply-To: <20181126075746.GO72840@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 18:00:30 -0000 Perhaps we should push for some research to evaluate the actual impact? This is the only study I know that did something like that. It was limited = to a single router and is 2 years or so old. http://www.macrothink.org/journal/index.php/npa/article/viewFile/10190/8493 "The maximum traffic rate was reached with packets of 1518 Bytes and IPv4 protocol, and it decreases with the use= of IPv6 protocol. The router reaches higher performance when work with IPv4 traffic. The CPU = usage increases with the increase of IPv6 traffic. The use of ACL in IPv4 traffic= the CPU usage rises from 6.5% without ACL to 15% with ACL (8.5%) while for IPv6 goes from 67.5%= to 82.5%, 15%, the double. The maximum traffic rate falls 1.54 Mbps by the use of ACL= in IPv4 and 27.14 Mbps in IPv6. With IPv4 the router is able to support bidirectional t= raffic without decrease the maximum traffic rate, compared with unidirectional traffic. Bu= t for IPv6 in bidirectional traffic the maximum traffic rate is lower than for unidirecti= onal traffic in the same conditions. The use of REH in the traffic supposes an increment of the= CPU usage; this increment depends on the packets per second of the data flow. " if (initial_ttl!=3D255) then (rfc5082_compliant=3D=3D0) Donald.Smith@centurylink.com ________________________________________ From: OPSEC [opsec-bounces@ietf.org] on behalf of Gert Doering [gert@space.= net] Sent: Monday, November 26, 2018 12:57 AM To: Joe Touch Cc: ietf; draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org; Nick Hilliard; O= PSEC; Christian Huitema; tsv-art; Brian E Carpenter Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-= ipv6-eh-filtering-06 Hi, On Sun, Nov 25, 2018 at 09:16:23PM -0800, Joe Touch wrote: > I.e., most of the analysis in this document is flat out incorrect in assu= ming that merely because a packet could cause a router to do work that it i= s a security risk to handle that packet as intended. And then IETF wonders why operators do not feel like time spent on providing their input to IETF WGs is well-spent. What else can it be, on a real-world device, in today's Internet? Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Thu Dec 6 10:13:24 2018 Return-Path: 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 2CABD130F0D; Thu, 6 Dec 2018 10:13:22 -0800 (PST) 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 609DDwv0vl2L; Thu, 6 Dec 2018 10:13:20 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A171130E4E; Thu, 6 Dec 2018 10:13:20 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wB6IDFbZ061994 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2018 18:13:15 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: "Smith, Donald" Cc: ietf , "draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org" , OPSEC , tsv-art References: <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <68EFACB32CF4464298EA2779B058889D53E5B552@PDDCWMBXEX503.ctl.intranet> From: Nick Hilliard Message-ID: Date: Thu, 6 Dec 2018 18:13:13 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.6 MIME-Version: 1.0 In-Reply-To: <68EFACB32CF4464298EA2779B058889D53E5B552@PDDCWMBXEX503.ctl.intranet> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 18:13:22 -0000 Smith, Donald wrote on 06/12/2018 17:59: > This is the only study I know that did something like that. It was > limited to a single router and is 2 years or so old. this isn't a relevant study because the device in question was a software-forwarded device (i.e. no separation between control plane and forwarding plane). The devices we're talking about in this discussion are systems which have separate management planes which can be overloaded by excess traffic from the forwarding planes, unless specific mitigating configuration is used. Not sure why the authors of that report used a C1841 - that device dates from 2004. Nick From nobody Thu Dec 6 10:28:08 2018 Return-Path: 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 43E86130F0D; Thu, 6 Dec 2018 10:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 5y7H_JKR44Ar; Thu, 6 Dec 2018 10:27:57 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E4B130EEE; Thu, 6 Dec 2018 10:27:57 -0800 (PST) Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 5BD4AFECC074; Thu, 6 Dec 2018 18:27:56 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id ACA89ABBA60; Thu, 6 Dec 2018 19:27:52 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Ole Troan In-Reply-To: Date: Thu, 6 Dec 2018 19:27:52 +0100 Cc: "Smith, Donald" , tsv-art , OPSEC , ietf , "draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <68EFACB32CF4464298EA2779B058889D53E5B552@PDDCWMBXEX503.ctl.intranet> To: Nick Hilliard X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 18:27:59 -0000 >> This is the only study I know that did something like that. It was >> limited to a single router and is 2 years or so old. > this isn't a relevant study because the device in question was a = software-forwarded device (i.e. no separation between control plane and = forwarding plane). The devices we're talking about in this discussion = are systems which have separate management planes which can be = overloaded by excess traffic from the forwarding planes, unless specific = mitigating configuration is used. >=20 > Not sure why the authors of that report used a C1841 - that device = dates from 2004. The VPP project maintains lots of performance measurements for modern = Intel CPUs. = https://docs.fd.io/csit/rls1810/report/vpp_performance_tests/packet_throug= hput_graphs/index.html We haven=E2=80=99t measured extension header cost as far as I know. Ole= From nobody Thu Dec 6 10:29:38 2018 Return-Path: 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 2738D130F0D; Thu, 6 Dec 2018 10:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 YUH_Wxoh66Oo; Thu, 6 Dec 2018 10:29:33 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690CA130E4E; Thu, 6 Dec 2018 10:29:33 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4] (unknown [IPv6:2001:470:5:ac9:40bf:f212:9e4f:c1a4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 42C5E83008; Thu, 6 Dec 2018 19:29:28 +0100 (CET) To: "Smith, Donald" , Gert Doering , Joe Touch Cc: ietf , "draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org" , Nick Hilliard , OPSEC , Christian Huitema , tsv-art , Brian E Carpenter References: <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <68EFACB32CF4464298EA2779B058889D53E5B552@PDDCWMBXEX503.ctl.intranet> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <3566d939-44d8-6d51-a363-46da37747a3a@si6networks.com> Date: Thu, 6 Dec 2018 15:10:03 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <68EFACB32CF4464298EA2779B058889D53E5B552@PDDCWMBXEX503.ctl.intranet> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 18:29:36 -0000 Hello, Donald, We had this preso in the IPv6 Hackers (http://www.ipv6hackers.org/) meeting in Berlin, 6 years ago: * slides: http://www.ipv6hackers.org/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf * video: http://www.youtube.com/watch?v=umva0BxaXfM Thanks, Fernando On 6/12/18 14:59, Smith, Donald wrote: > Perhaps we should push for some research to evaluate the actual impact? > > This is the only study I know that did something like that. It was limited to a single router and is 2 years or so old. > > > http://www.macrothink.org/journal/index.php/npa/article/viewFile/10190/8493 > > "The maximum traffic rate was reached > with packets of 1518 Bytes and IPv4 protocol, and it decreases with the use of IPv6 protocol. > The router reaches higher performance when work with IPv4 traffic. The CPU usage > increases with the increase of IPv6 traffic. The use of ACL in IPv4 traffic the CPU usage rises > from 6.5% without ACL to 15% with ACL (8.5%) while for IPv6 goes from 67.5% to 82.5%, > 15%, the double. The maximum traffic rate falls 1.54 Mbps by the use of ACL in IPv4 and > 27.14 Mbps in IPv6. With IPv4 the router is able to support bidirectional traffic without > decrease the maximum traffic rate, compared with unidirectional traffic. But for IPv6 in > bidirectional traffic the maximum traffic rate is lower than for unidirectional traffic in the > same conditions. The use of REH in the traffic supposes an increment of the CPU usage; this > increment depends on the packets per second of the data flow. " > > > if (initial_ttl!=255) then (rfc5082_compliant==0) > Donald.Smith@centurylink.com > > ________________________________________ > From: OPSEC [opsec-bounces@ietf.org] on behalf of Gert Doering [gert@space.net] > Sent: Monday, November 26, 2018 12:57 AM > To: Joe Touch > Cc: ietf; draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org; Nick Hilliard; OPSEC; Christian Huitema; tsv-art; Brian E Carpenter > Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 > > Hi, > > On Sun, Nov 25, 2018 at 09:16:23PM -0800, Joe Touch wrote: >> I.e., most of the analysis in this document is flat out incorrect in assuming that merely because a packet could cause a router to do work that it is a security risk to handle that packet as intended. > > And then IETF wonders why operators do not feel like time spent on > providing their input to IETF WGs is well-spent. > > What else can it be, on a real-world device, in today's Internet? > > Gert Doering > -- Operator > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. > > > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 6 10:58:29 2018 Return-Path: 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 1618F130F29; Thu, 6 Dec 2018 10:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 QJAiZLgyeID7; Thu, 6 Dec 2018 10:58:16 -0800 (PST) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FD6130F15; Thu, 6 Dec 2018 10:58:15 -0800 (PST) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id A0820127FBA; Thu, 6 Dec 2018 13:58:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=sG3auIcXbKjEnv7+S0a2Szfcl/Q=; b=chAvN0 3orbdXqypaIart8J4FTi+6u8kw2ukGKyKvrg3GBM1+ivbdAINCH6R0MnCkVplaer e/LLH684n9/DoYNDRJ6TSq7vYGD/UPMzZq1KhVA2XQGoPUaFQisr6CUZvm+o9RBP B1nvTZ6A2Q8eZvgZy3u5MSbjr58S4qDDB5yRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=cIQvNafHyHoazDKEN3RUK+/gkwoch7TL WDkLRFEMuP5L8Agio1hm8N+EbtYz0jIfd/8xKqDIREsP/ksn4GAxxqcy9CRDowc5 /paRH92s2+4lImf1HM8ww3pHyMdBLi7Kytu1t2WpbkxCtODuxXA1a7MAVbyIvov1 Lvu0g/WXDlA= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 9880B127FB9; Thu, 6 Dec 2018 13:58:14 -0500 (EST) Received: from mail-it1-f170.google.com (unknown [209.85.166.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 239CF127FB8; Thu, 6 Dec 2018 13:58:14 -0500 (EST) Received: by mail-it1-f170.google.com with SMTP id o19so3045479itg.5; Thu, 06 Dec 2018 10:58:14 -0800 (PST) X-Gm-Message-State: AA+aEWbe7vOtphY4eJtUnIyCJAvfNfK7kVMgyvAnp+jcshmFOHv/Vm1h ua7S1LpiwmaeSrZGNAj9RgwXs8ClqsK+LEiLuOI= X-Google-Smtp-Source: AFSGD/U7N3eoxkUOKZRjOH+zdBIQ+NDZREMUuejectBAcL9TIdhqVwtCGsZjowXIJKB2Q5bPf+Z1H/ezF7mygK+mLUw= X-Received: by 2002:a02:9f96:: with SMTP id a22mr1599251jam.7.1544122693599; Thu, 06 Dec 2018 10:58:13 -0800 (PST) MIME-Version: 1.0 References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <20181206093154.GF1543@Space.Net> In-Reply-To: <20181206093154.GF1543@Space.Net> From: "C. M. Heard" Date: Thu, 6 Dec 2018 10:58:01 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Gert Doering Cc: Brian E Carpenter , Christopher Morrow , TSV-ART , OPSEC , IETF , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: E2413B34-F988-11E8-AC4A-063AD72159A7-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 18:58:19 -0000 On Thu, Dec 6, 2018 at 1:32 AM Gert Doering wrote: > On Thu, Dec 06, 2018 at 01:14:54PM +1300, Brian E Carpenter wrote: > > > Which implies that as soon as the evil guys out there find a way to > > > generate DDoS streams carrying EHs that our border routers will (have to) > > > apply very strict rate limiting to everything they do not understand. > > > > > > - pass TCP > > > - rate-limit UDP on well-known reflective attacks port > > > - pass rest of UDP > > > - rate-limit ICMP > > > - rate-limit fragments > > > - rate-limit all the rest to something which can never exceed a > > > customer's access-link > > > > > > game over, EH > > > > Just to point out that this is equivalent to saying "game over, > > any new layer 4 protocol" too. For example, you just killed SCTP. > > And the same goes for new protocols over IPv4. > > Well. Since nobody is using SCTP, it can nicely live in the > "rate-limit all the rest to something ..." bucket... > > But yes, "any new layer 4 protocol" is likely to not work in an Internet > that is basically full of hostile packets *in high volumes*. > > Trying to run large volume traffic over UDP/443 is going to be the next > excercise in "operators told you that is isn't going to work"... Is that a prediction, or a self-fulfilling prophecy? I would certainly hope that filtering UDP/443 is not done preemptively without actual evidence that it is in fact a DDoS vector. Mike Heard From nobody Thu Dec 6 11:12:14 2018 Return-Path: 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 271FF130F39; Thu, 6 Dec 2018 11:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 2wFeNu2cYn5D; Thu, 6 Dec 2018 11:12:05 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DA0130F24; Thu, 6 Dec 2018 11:12:05 -0800 (PST) Received: from [IPv6:2603:3015:3606:cbe1:24ab:5e49:fa23:e739] (unknown [IPv6:2603:3015:3606:cbe1:24ab:5e49:fa23:e739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 3E51D5404E8; Thu, 6 Dec 2018 14:12:03 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jared Mauch In-Reply-To: Date: Thu, 6 Dec 2018 14:12:02 -0500 Cc: Gert Doering , IETF , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , TSV-ART , Brian E Carpenter Content-Transfer-Encoding: quoted-printable Message-Id: References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <20181206093154.GF1543@Space.Net> To: "C. M. Heard" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 19:12:07 -0000 > On Dec 6, 2018, at 1:58 PM, C. M. Heard wrote: >=20 > On Thu, Dec 6, 2018 at 1:32 AM Gert Doering wrote: >> On Thu, Dec 06, 2018 at 01:14:54PM +1300, Brian E Carpenter wrote: >>>> Which implies that as soon as the evil guys out there find a way to >>>> generate DDoS streams carrying EHs that our border routers will = (have to) >>>> apply very strict rate limiting to everything they do not = understand. >>>>=20 >>>> - pass TCP >>>> - rate-limit UDP on well-known reflective attacks port >>>> - pass rest of UDP >>>> - rate-limit ICMP >>>> - rate-limit fragments >>>> - rate-limit all the rest to something which can never exceed a >>>> customer's access-link >>>>=20 >>>> game over, EH >>>=20 >>> Just to point out that this is equivalent to saying "game over, >>> any new layer 4 protocol" too. For example, you just killed SCTP. >>> And the same goes for new protocols over IPv4. >>=20 >> Well. Since nobody is using SCTP, it can nicely live in the >> "rate-limit all the rest to something ..." bucket... >>=20 >> But yes, "any new layer 4 protocol" is likely to not work in an = Internet >> that is basically full of hostile packets *in high volumes*. >>=20 >> Trying to run large volume traffic over UDP/443 is going to be the = next >> excercise in "operators told you that is isn't going to work"... >=20 > Is that a prediction, or a self-fulfilling prophecy? I would certainly = hope > that filtering UDP/443 is not done preemptively without actual = evidence that > it is in fact a DDoS vector. It is done as UDP is where the majority of the abuse has been. I=E2=80=99= ve been responsible for implementing these types of controls at operator = networks due to the damage it does to our infrastructure. People are very unhappy then their service is down because they=E2=80=99re= staring down a cannon that took out their country/continent with UDP = abuse. I would say I find it shocking that the transport area folks seem to = keep ignoring the feedback from operators, but this feeds into the = longstanding meme of operators don=E2=80=99t show up at the IETF because = they aren=E2=80=99t heard. I=E2=80=99ve had folks at $dayjob say they =E2=80=9CWell that network = will then have poor performance and people will switch=E2=80=9D. This = may be the case for those that have choice, but as was recently pointed = out in home net, much of the complexity perhaps isn=E2=80=99t used or = desired by the consumers. Yes, the ad networks want to serve me ads faster. I don=E2=80=99t = expect the transport area to listen to those that operate networks as = it=E2=80=99s been demonstrated the conversation about harm to the = network by these behaviors isn=E2=80=99t listened to. Let me state it clearly: UDP is filtered or policed by network operators not because they want = it, but as self-defense. Nothing personal. If you are on the end of a = long subsea circuits, you may not be able to use UDP based protocols. = If you are trying to SNMP poll over public internet because you think = you can e2e, you will become sad. No operator wants to deploy these = configurations, they must because of the problems. - jared (Feels like a broken record on this topic)= From nobody Thu Dec 6 11:20:59 2018 Return-Path: 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 1323E130F4A; Thu, 6 Dec 2018 11:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 yAzTdmaEaQ95; Thu, 6 Dec 2018 11:20:56 -0800 (PST) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181DC130E50; Thu, 6 Dec 2018 11:20:56 -0800 (PST) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 0BB4912823B; Thu, 6 Dec 2018 14:20:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=KmquSNQUOpbdUW2LUwY0pUlAx0Q=; b=BHP9O0 nBUUETreKHAMEoYHgZmZai0IzmPc1ZW16BjH5g1yTQoXKPntcHIk4a9GV4EfXTS9 XSL8U2pj0tLgHibLqJPyb79hSkU1qC/Ffj65dMAuLVzvlrKvOH1m7SEfVt13G/zb PCbhKSu72xM9nM77DtzkabwYtkuXAhEwPfqXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=D6z0b4tBm8t/ztDfDXpbElhEJJe2ZQQ4 Yfk8tDHJ3C3fmbz1Wxuzjs8Z7IBcQgmqucWSP4Q6ScHZqvEIScqtlBYGhkmmX8ag 108Lseqp1owIvz0m6Y3N8Zrv0oJSg8cFl5yAPjLBjnXMN1OTjyEhAfl9KkVFIzW2 up/jrG/gxE0= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id F420712823A; Thu, 6 Dec 2018 14:20:54 -0500 (EST) Received: from mail-it1-f182.google.com (unknown [209.85.166.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 72AA7128236; Thu, 6 Dec 2018 14:20:54 -0500 (EST) Received: by mail-it1-f182.google.com with SMTP id z7so3212400iti.0; Thu, 06 Dec 2018 11:20:54 -0800 (PST) X-Gm-Message-State: AA+aEWaN4lPshXWu2/vEG4rutojwcuKgFDTNGIVa4MzghMvwx76kQGCe 1drmog3V0bw4Zkf+mvuRRmlcPwUMUQLpi1n+sTg= X-Google-Smtp-Source: AFSGD/XjGUwK0y1VsKzMglyPmoaNDTyVEUz12lqdmx+1GdwZfjKxX77zlIgefmhUOc+EIHcEnkpfDX3lErMdirx7XKw= X-Received: by 2002:a02:b529:: with SMTP id l38mr25496248jaj.25.1544124053816; Thu, 06 Dec 2018 11:20:53 -0800 (PST) MIME-Version: 1.0 References: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> <65e96716-48d3-a26c-905a-a5e47deea683@si6networks.com> <16F94EAB-CE40-4A4A-BAB3-4DDAC44980B0@employees.org> In-Reply-To: From: "C. M. Heard" Date: Thu, 6 Dec 2018 11:20:41 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Fernando Gont Cc: OPSEC , IETF Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 0D12061A-F98C-11E8-AC3A-BFB3E64BB12D-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [OPSEC] Last Call: (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 19:20:58 -0000 On Fri, Nov 30, 2018 at 6:46 AM C. M. Heard wrote: > > As I look at the advice for specific options more carefully, I find > > some inconsistencies in the advice for certain cases [...]. > > > > I will follow up after doing a more thorough review of the specific > > advice for each option. > > Here is the promised/threatened follow up. > > Section 3.4.1.2, Specification of the Hop-by-Hop Options extension > header: the deprecated Endpoint Identification Option (Type 0x8A) > should not be listed here. The reference cited for this option states > that it is a Destination Option to convey Nimrod EIDs. Also, in the bullet for 0x4D, add the reference [RFC7731]. This will bring the section in line with the content of the registry. > Section 3.4.6.2, Specification of the Destination Options extension > header: the Performance and Diagnostic Metrics (PDM) Option should be > listed here. The reference is RFC 8250. Also, the deprecated option 0x4D should not be listed in this section. It was an erroneous early version of the MPL option 0x6D that did not have the chg bit set to 1. For details please ee: https://mailarchive.ietf.org/arch/msg/roll/blyXhjgs0d3iBdce84Z7k2PISts and related messages. Note that RFC 7731 does call this out as a deprecated version of the MPL option. > Section 4: A subsection documenting the PDM Option needs to be added. > Insofar as this is a standard option that is to be ignored by systems > that do not implement it, the advice "should not discard" would be an > appropriate default. > > Section 4: The advice for specific options is not conditioned upon > whether they are found in a Hop-by-Hop Options header or a Destination > Options header. However, every defined option (other than padding and > experimental types) is intended to appear in only one of those headers. > At a minimum this needs to be pointed out. It may be appropriate to > advise that packets with defined options that appear within the "wrong" > header should be discarded. > > Section 4: The advice for Router Alert (Type=0x05, Proposed Standard) > and SMF_DPD (Type=0x08, Experimental) is "should discard", while the > advice for Quick-Start (Type=0x26, Experimental) is "should not > discard". All of these Hop-by-Hop options are applicable only in limited > domains (RFC 6398 says so for Router Alert), and Quick Start and Router > Alert have substantial security implications. Thus, I have a hard time > wrapping my head around the fact that they do not all get the same > advice. How about something like "intermediate systems should discard > packets that contain this option, except when deployed in an > administrative domain where the option is in use" for all of them? > > Section 4: Randall Atkinson has provided detailed comments on CALIPSO. > I support those comments. Note that systems compliant with RFC 8200 > that do not implement RFC 5570 would simply ignore the option. Sections 4.3.15.1 and 4.3.15.2: note that 0x4D this was an erroneous early allocation that was replaced by 0x6D. > Sections 4.3.18.5 and 4.4.5: as I previously stated, I think the right > strategy is to remain neutral and say that operators should determine > according to their own circumstances whether to discard packets > containing these options. Reiterated only for completeness. > > Unused reference: I-D.ietf-6man-hbh-header-handling Mike Heard From nobody Thu Dec 6 11:24:44 2018 Return-Path: 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 EFD80130E50; Thu, 6 Dec 2018 11:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 nOnrI9u91MPR; Thu, 6 Dec 2018 11:24:16 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B30C131143; Thu, 6 Dec 2018 11:24:16 -0800 (PST) Received: from [IPv6:2603:3015:3606:cbe1:24ab:5e49:fa23:e739] (unknown [IPv6:2603:3015:3606:cbe1:24ab:5e49:fa23:e739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 5F9D554053C; Thu, 6 Dec 2018 14:24:14 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jared Mauch In-Reply-To: Date: Thu, 6 Dec 2018 14:24:13 -0500 Cc: Stewart Bryant , IETF list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec@ietf.org, tsv-art@ietf.org, gert@space.net Content-Transfer-Encoding: quoted-printable Message-Id: <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 19:24:30 -0000 > On Dec 6, 2018, at 9:05 AM, Spencer Dawkins at IETF = wrote: >=20 > Speaking as an individual who ballots on working group charters ...=20 >=20 > On Thu, Dec 6, 2018 at 7:38 AM Stewart Bryant = wrote: >=20 >=20 > On 06/12/2018 12:57, Gert Doering wrote: > > Hi, > > > > On Thu, Dec 06, 2018 at 10:28:53AM +0000, Stewart Bryant wrote: > >> However, aren't we moving to a world where new protocols get = carried > >> over UDP anyway? > > Over HTTPS, you intended to say? > Some and some. It depends on what aspect of the stack you spend your=20= > time thinking about. >=20 > "you're both right" :-) ...=20 >=20 > As noted earlier in this thread, we punted new transport protocols = into UDP encapsulation at roughly the "we can't get SCTP deployed at = scale, we can't get DCCP deployed at scale, and we don't see any reason = to think that any new transport protocol will be any different" stage, = at least a decade ago. So, when I see people talking about SCTP, it's = usually in a context like RTCWeb, where the stack looks like = SCTP/DTLS/UDP, and QUIC is only defined over UDP.=20 >=20 > (I suspect the world would have been a slightly better place if we'd = done the DCCP encapsulation in UDP from day 1, because DCCP = functionality could have been really useful when we started = encapsulating every known network protocol in UDP, but that's not = relevant to this discussion) >=20 > But since QUIC's initial deliverable includes its HTTP mapping, = https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ comes into = play. I would oversimplify that draft as saying "we are way more excited = about applications using HTTP as a substrate now, than we were in 2002", = so, yes, the future smells a lot like HTTPS over (mumble) over UDP, at = least to me. >=20 > I don't know that's a perfect plan, but I've been balloting on working = group charters for at least 3 years, assuming that it's a plan.=20 Yes, we=E2=80=99ve also seen the security/crypto all the things = overreach impact the routing area as well. We=E2=80=99ve not seen a = suitable option to replace TCP transport that is viable due to the = timescales involved. I=E2=80=99ve provided feedback at the mic in = London in SAAG about the problems of this for people who need very = reliable transport, some level of transport security but do not want or = require transport privacy.=20 - Jared= From nobody Thu Dec 6 11:42:01 2018 Return-Path: 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 1CD3D131134; Thu, 6 Dec 2018 11:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 1ggy6Um4QfTd; Thu, 6 Dec 2018 11:41:43 -0800 (PST) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F45129AB8; Thu, 6 Dec 2018 11:41:42 -0800 (PST) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 1ACE1128440; Thu, 6 Dec 2018 14:41:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=gxDrlRJRJix9JGipx9hHBXSyDGw=; b=GywtA/ 1b/Mn2rZRFr0s9lvSXBL2aeAc64UEta5Sxs2Qj2296Llh9znPxBPFYpOaNyR+m0j x48zs+U+ighL84wEdisHyd3Ah0UdU3tcSc6szxx0WgcH/6hmDh+ppE1xVwrQio74 0OvsYWvbVIpnT6RLsMOjV2x4fBODm3TRABSf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=sEG6iQOXtMAJ7x7D45CA9TlHQuHUvqTF nhqfV8SwYj3hX8DCbFPJBbSrEQ44krQQg/MP/UP8iBh4qtktsKPJy4aNmKySk1IX zWktFIrk5yzsNrb+cfEFjdbi6l1eOgBex9pTRscAZ16Qpw4ArITffNeruJKJFo6W pquBD27fSJQ= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 121CD12843F; Thu, 6 Dec 2018 14:41:41 -0500 (EST) Received: from mail-io1-f50.google.com (unknown [209.85.166.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 867C612843B; Thu, 6 Dec 2018 14:41:40 -0500 (EST) Received: by mail-io1-f50.google.com with SMTP id r9so1375033ioa.1; Thu, 06 Dec 2018 11:41:40 -0800 (PST) X-Gm-Message-State: AA+aEWYg0Q2y1xUX6jcERfzqQjMfHmf2DCAAP7hY+/OHbKZe54+iUpph 055BZFEVSKwx6gVWC1/gkHo7MpzhuLlinKShEuE= X-Google-Smtp-Source: AFSGD/Vaha9PAxn5GcPInfBW7MIl+QJp24kqoFqWRKTAcbYg8CTnKEx3xZZEPBKzPykpX9AN48i2PaOKD4S1do6iTXY= X-Received: by 2002:a6b:91d4:: with SMTP id t203mr26066267iod.267.1544125300035; Thu, 06 Dec 2018 11:41:40 -0800 (PST) MIME-Version: 1.0 References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <20181206093154.GF1543@Space.Net> In-Reply-To: From: "C. M. Heard" Date: Thu, 6 Dec 2018 11:41:28 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Jared Mauch Cc: Gert Doering , IETF , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , TSV-ART , Brian E Carpenter Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: F3CB10B8-F98E-11E8-945E-BFB3E64BB12D-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 19:41:44 -0000 On Thu, Dec 6, 2018 at 11:12 AM Jared Mauch wrote: > UDP is filtered or policed by network operators not because they want > it, but as self-defense. Nothing personal. If you are on the end of > a long subsea circuits, you may not be able to use UDP based > protocols. If you are trying to SNMP poll over public internet > because you think you can e2e, you will become sad. No operator wants > to deploy these configurations, they must because of the problems. I do get the need for self-defense. But ... Does this apply to all UDP or just specific UDP-based protocols? What I commented on specifically was UDP/443 (QUIC), something that people are actually trying to deploy. If you block it, is that based on evidence of actual UDP/443 attacks? Mike Heard From nobody Thu Dec 6 12:00:35 2018 Return-Path: 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 7BD721311B5; Thu, 6 Dec 2018 12:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 b6pIOwPLmysS; Thu, 6 Dec 2018 12:00:10 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693A21311A0; Thu, 6 Dec 2018 12:00:10 -0800 (PST) Received: from lxomp90v.corp.intranet (lxomp90v.corp.intranet [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id wB6K070L059813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 6 Dec 2018 14:00:07 -0600 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6K01Oq013105; Thu, 6 Dec 2018 14:00:01 -0600 Received: from lxdnp32k.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6K01sR012694 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Thu, 6 Dec 2018 14:00:01 -0600 Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6K01lR021559; Thu, 6 Dec 2018 13:00:01 -0700 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id wB6K01sx021549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2018 13:00:01 -0700 Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([151.119.128.28]) with mapi id 14.03.0399.000; Thu, 6 Dec 2018 13:00:01 -0700 From: "Smith, Donald" To: "C. M. Heard" , Jared Mauch CC: IETF , "draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org" , OPSEC , TSV-ART , Brian E Carpenter Thread-Topic: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] Thread-Index: AQHUjPjzcvm/Mjyn00OZLnlEXIoAFKVx6HMAgACeLICAAAPqAIAACDkA//+N6hw= Date: Thu, 6 Dec 2018 20:00:00 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D53E5B811@PDDCWMBXEX503.ctl.intranet> References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <20181206093154.GF1543@Space.Net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 20:00:23 -0000 In the past nearly all UPD:443 traffic was part of an attack. Frequently it= is the src port for a reflective attack towards UPD:1900, 123, =85 pick a = reflector port that amplifies well. UDP:80 same. Those are the two most common trigger packet src ports for RA attacks. It is my belief that the bad guys choose that because some (many?) filters = are port based only not protocol based. I have no evidence of that (you would have to ask a bad guy... DDoS for hir= e) but it is common. Don't take my word for it :) https://asert.arbornetworks.com/ddos-attacks-iot-botnets-dont-mean-game/ " As most (not all) UDP reflection/amplification attacks tend to target UDP= /80 or UDP/443 in order to confuse defenders who might not notice that the = attackers are using UDP instead of TCP (TCP/80 is typically used for non-en= crypted Web servers, and TCP/443 for SSL-/TLS-encrypted Web servers), " if (initial_ttl!=3D255) then (rfc5082_compliant=3D=3D0) Donald.Smith@centurylink.com ________________________________________ From: OPSEC [opsec-bounces@ietf.org] on behalf of C. M. Heard [heard@pobox.= com] Sent: Thursday, December 06, 2018 12:41 PM To: Jared Mauch Cc: IETF; draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org; OPSEC; TSV-ART; = Brian E Carpenter Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-o= psec-ipv6-eh-filtering-06] On Thu, Dec 6, 2018 at 11:12 AM Jared Mauch wrote: > UDP is filtered or policed by network operators not because they want > it, but as self-defense. Nothing personal. If you are on the end of > a long subsea circuits, you may not be able to use UDP based > protocols. If you are trying to SNMP poll over public internet > because you think you can e2e, you will become sad. No operator wants > to deploy these configurations, they must because of the problems. I do get the need for self-defense. But ... Does this apply to all UDP or just specific UDP-based protocols? What I commented on specifically was UDP/443 (QUIC), something that people are actually trying to deploy. If you block it, is that based on evidence of actual UDP/443 attacks? Mike Heard _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Thu Dec 6 12:02:53 2018 Return-Path: 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 618A31311D3 for ; Thu, 6 Dec 2018 12:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 2GoLziKYjGFb for ; Thu, 6 Dec 2018 12:02:36 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B940A1311BD for ; Thu, 6 Dec 2018 12:02:19 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8880441C37 for ; Thu, 6 Dec 2018 21:02:17 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 6A52D40B9E; Thu, 6 Dec 2018 21:02:17 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 5B9AA112A2; Thu, 6 Dec 2018 21:02:17 +0100 (CET) Date: Thu, 6 Dec 2018 21:02:17 +0100 From: Gert Doering To: "C. M. Heard" Cc: Jared Mauch , Gert Doering , IETF , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , TSV-ART , Brian E Carpenter Message-ID: <20181206200217.GI1543@Space.Net> References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <20181206093154.GF1543@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ePFeKdkqS71SfxAJ" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 20:02:46 -0000 --ePFeKdkqS71SfxAJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Dec 06, 2018 at 11:41:28AM -0800, C. M. Heard wrote: > I do get the need for self-defense. But ... >=20 > Does this apply to all UDP or just specific UDP-based protocols? >=20 > What I commented on specifically was UDP/443 (QUIC), something > that people are actually trying to deploy. We currently rate-limit NTP, DNS, memcached, LDAP/UDP and *fragments* (because LDAP and NTP usually bring along large fragments). We *currently* see no attacks on UDP/443, so we do not rate-limit that. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --ePFeKdkqS71SfxAJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwJgEYACgkQ31bAZeTO f8XJDA//S4PPgMmPWTX13tgfTjn2+esRxjyEm7VIuUk7sp1nEAsh8vbr/u5HQZwd tfnme12+aYbjOY16s7/4HilMRr9KRAnCY/Tc/ZQxgWAnfeYX8nSupzwAYu5wmJV/ jVrL4NZ1FPfsmDfZe5UcrMniIqrfKIxkhmN48Q8kZYfa5qaRzr/Vr0VOBmmEHCVy PcSvnwg8OpjfhVHFBmBKFZnAwm0vy+arqOrYCoDckJYJNGgJ/sYqauHV1Yof4jD+ 3YDlm9yAor0ZdoYH1v6cET9xEFQS213v0jb3OoO2HOCPix+mW/zCzgXfFU7/8zO2 D+Q3+iydKwOC1AcwllyCyVV/MQ8ZdrztjeZ4/pmP+k5EcnPvvlfpqq7cfVrj20F/ u+E19AchxjwotU8JqnIvV6uuVocsaZhZy6kyT2NF0XMxhxQ3OsJzVOsx5FFJOpCt Kg1pAeo1QjjLiHtrt0LErWZiLnln9i0/S9LyHtiun1x1Imq7f4IuVJnlzMAR5vDg YPfPqfr4jj9TNnFMhvd/JjwnMgTI2sLh46bsGBicTrNThGuOYKp/3S5gaQCRxWYY VeWZzhRKohAIjWPtTC5M6gnXF/vTHtv2yp7T/y50x1yP0FHJLYTkb/gMFhlEjVMr iaM/uFPS+j55NGrhca4/H2noKfLJMiBDE4SmhJQYp5G12PBqNzo= =UdBQ -----END PGP SIGNATURE----- --ePFeKdkqS71SfxAJ-- From nobody Thu Dec 6 12:03:50 2018 Return-Path: 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 6E0BF131197; Thu, 6 Dec 2018 12:03:42 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 sRJIaakek4pG; Thu, 6 Dec 2018 12:03:39 -0800 (PST) Received: from bisque.maple.relay.mailchannels.net (bisque.maple.relay.mailchannels.net [23.83.214.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0CF1311B9; Thu, 6 Dec 2018 12:03:29 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 741183E3EC0; Thu, 6 Dec 2018 20:03:28 +0000 (UTC) Received: from pdx1-sub0-mail-a69.g.dreamhost.com (unknown [100.96.36.160]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A1A3C3E46C3; Thu, 6 Dec 2018 20:03:27 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a69.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Thu, 06 Dec 2018 20:03:28 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Share-Suffer: 56639b20546e6244_1544126608181_2534840862 X-MC-Loop-Signature: 1544126608181:2602549285 X-MC-Ingress-Time: 1544126608180 Received: from pdx1-sub0-mail-a69.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a69.g.dreamhost.com (Postfix) with ESMTP id 3B13281BCE; Thu, 6 Dec 2018 12:03:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=BGdnwQwNJTeXdr XYmn2m4ca0vcU=; b=RDdnsoYNKqjfUUJfMu9x5LOEuNVNbd+218KijTLS55Lcnj 5rZ0ZnfOpqXNqWZGxkHCRAmazsP3f7jXT2kg29Mg1lCdWsd8XppX5MKhDFQDOs9+ HVOxyRMBzwiHjR6I2wxXjeP4IqUm3dXO+h2M6zt7bQW5JU37jJoWjVyrGyrjw= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a69.g.dreamhost.com (Postfix) with ESMTPSA id 458EF81BCC; Thu, 6 Dec 2018 12:03:23 -0800 (PST) Date: Thu, 6 Dec 2018 14:03:20 -0600 X-DH-BACKEND: pdx1-sub0-mail-a69 From: Nico Williams To: "C. M. Heard" Cc: Gert Doering , IETF , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , TSV-ART Message-ID: <20181206200318.GP15561@localhost> References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <20181206093154.GF1543@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefjedgudefvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [OPSEC] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 20:03:49 -0000 On Thu, Dec 06, 2018 at 10:58:01AM -0800, C. M. Heard wrote: > [...]? I would certainly hope > that filtering UDP/443 is not done preemptively without actual evidence that > it is in fact a DDoS vector. I'd expect that networks that filter / rate-limit UDP do it mostly indiscriminately, and wouldn't already have exceptions for port 443. Exceptions would mostly be for things like DNS and NTP (not filtered, obviously, but maybe rate-limited). The port number / application has a lot to do with DDoS potention. E.g., DNS has great amplification potential, so it needs rate limits. TCP has much smaller amplification potential, and more of the TCP state machine is visible to the network than any non-TCP protocol's state machine, so maybe TCP SYNs and maybe even RSTs get rate-limited, but others do not. With TCP there's no need to discriminate by port number or know what the application protocol is. With UDP all you have is port numbers to discriminate by. Without exposing that sort of detail (SYN, RST, ...) to the network, I'd expect operators to scoff, and QUIC to have trouble in the public Internet until operators / kit learn how to handle QUIC. Not that we can expect kit to understand new upper level protocols, or new UDP application protocols, in with any kind of celerity. So it's all a mess :( Also, we can run HTTP and HTTPS over TCP on any ports, not just 80 and 443. That won't be true for QUIC. Each alternative port number will have to get middlebox relaxation de novo. That could be a problem, or maybe a blessing: maybe QUIC should mux multiple apps on one port. (QUIC muxes streams, but not apps). Then again, QUIC is done, right? Nico -- From nobody Thu Dec 6 12:35:27 2018 Return-Path: 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 0F6B0130F7E; Thu, 6 Dec 2018 12:35:17 -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 axYfwYYOaXIj; Thu, 6 Dec 2018 12:35:15 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 6953C130F90; Thu, 6 Dec 2018 12:35:15 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id w6so648893pgl.6; Thu, 06 Dec 2018 12:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WINOq7C4oG5hibo3Ceh+KlL7ehasXN+hziHpDi/2Drs=; b=rQkOgS1KZNI9zZN8lvo5CUsd4TfSFMBkZqsSprW5P18IDST8DliaCyzP+h0SyWhoca urLtyZod7a/dxjHuB1QjqxHyB9PEPqB46eaIQ01+Gran3a0MWTwTZjtbQTRZFtSIEZe5 M/GtSYNom6IhiXDXY/jOWX9HxiqlNjGDpu469NIiPfc/GrguCETiuP5pe1jxlUIdmBQV 6TQTTx8b9Tyh7QL8KPpbSDbiMNs8pvV6loJexNA/N2QZYfMEImDGH693rGGm1hF8t6UL +Pxwgzu3frdekbBHUQ9qRlpoBlvOnH8DZmIe052wZPI1Q0QyM2clZ51rTfpnN9mwk701 89TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WINOq7C4oG5hibo3Ceh+KlL7ehasXN+hziHpDi/2Drs=; b=pbWQIsi6/IiijAXG/XlpEiP/bfszo0j1q981pW9Td6QfnL/kWvZun2TvviIx5rVlRl JPmdSojyGSedsHrjEAnc9kpPNOiJNeycQzuWtCZeXTV2U4AeJRZSOoRv8XRZgO+mbLn2 iKSF+A98l1GV/MZH9KBzSNps9SSCQWdkk+XpNzPbEKefFeTmf+0Q2bzfsRgYodEOiXLj qkbVgI1oBA0pSxxZcSCPSR//EUVCjM8iy4u/QBcOIcA56GjQ+tVo7YGrxn2uM1ZSyngH t4x2ZUnWchFvaYEFKIuZ1PoAnLkTpl2DLOdA8mnP0YJe8Jc/Xz6Tq0t8QIzfhB287SxQ Q/DA== X-Gm-Message-State: AA+aEWZDAIRsjzWrTCylUsTSPgy+dPNakg5yQMiHKIJeT7cZlxRu+tJr /tNSVPmz54N/Pci07MNICsvtnDe60HA= X-Google-Smtp-Source: AFSGD/VzLQ5l7GPNs+SxG8lmhCXg7M85CaFNk5mkMV4GOTe6VDs3ybMaWy6+/tc9cXkLvvf1onDlmg== X-Received: by 2002:a63:3703:: with SMTP id e3mr24902838pga.348.1544128514602; Thu, 06 Dec 2018 12:35:14 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id z8sm1076940pgg.62.2018.12.06.12.35.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 12:35:13 -0800 (PST) To: Stewart Bryant , Ole Troan , Gert Doering Cc: tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> From: Brian E Carpenter Message-ID: <3744b28c-3a5a-1ce4-9ff7-5374804d332e@gmail.com> Date: Fri, 7 Dec 2018 09:35:07 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 20:35:17 -0000 On 2018-12-06 23:32, Stewart Bryant wrote: > > > On 06/12/2018 00:34, Brian E Carpenter wrote: >> >> . >>> Of course it still needs to step through them all to do ECMP even if >>> they are all disabled. >> No it doesn't. That's what the flow label, in a fixed position early in the IPv6 header, is for. A line speed IPv6 router has no need to look at the layer 4 header, even if it's doing both diffserv and ECMP. Looking at transport headers is an IPv4 concept. >> >> > > A question for the operators, how widely supported in the flow label? But there's a preliminary question: how widely is the flow label set by sending hosts? The answer is: widely, by modern o/s releases. But not much, by legacy o/s releases. > (a) in native IP > (b) IP over MPLS > > Certainly in MPLS and Detnet land I hear about the five or six tuple all > the time, including the inspection of them during forwarding, but I > don't hear much spoken about the flow label. Why would forwarding devices bother, until a majority of traffic has the flow label set by the source? This is a long term play. As it becomes harder and harder to parse packet contents, the flow label will become more and more useful for ECMP. Brian From nobody Thu Dec 6 14:02:53 2018 Return-Path: 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 C3A69130EEC; Thu, 6 Dec 2018 14:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 nYl80elipMCB; Thu, 6 Dec 2018 14:02:49 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E44130E93; Thu, 6 Dec 2018 14:02:48 -0800 (PST) X-Envelope-To: tsv-art@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wB6M2je7089038 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2018 22:02:45 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Brian E Carpenter Cc: tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <3744b28c-3a5a-1ce4-9ff7-5374804d332e@gmail.com> From: Nick Hilliard Message-ID: <35277330-4743-4690-8ae0-9a9ab7e34f05@foobar.org> Date: Thu, 6 Dec 2018 22:02:43 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.6 MIME-Version: 1.0 In-Reply-To: <3744b28c-3a5a-1ce4-9ff7-5374804d332e@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 22:02:52 -0000 Brian E Carpenter wrote on 06/12/2018 20:35: > But there's a preliminary question: how widely is the flow label set > by sending hosts? The answer is: widely, by modern o/s releases. But not > much, by legacy o/s releases. more to the point, if you were going to implement a forwarding device, do you depend solely on the flow label? This gives end-user device control over the hashing path on a purely discretionary basis. I.e. and end user can change the flow label and consequently make their own decisions about which network path to use, without affecting any other transmission characteristic of the network flow, e.g. port numbers, IP addresses, etc. Operationally, flow labels can cause grief. APNIC had a blog posting on this a while back https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ Most devices allow the operator to selectively use flow labels as an entropy source for hashing. Nick From nobody Thu Dec 6 14:05:58 2018 Return-Path: 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 9EF11131220; Thu, 6 Dec 2018 14:05:45 -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 LtpNKxZbWp36; Thu, 6 Dec 2018 14:05:43 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 A9B1F13120B; Thu, 6 Dec 2018 14:05:42 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id y126so846692pfb.4; Thu, 06 Dec 2018 14:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bWH7oLCA3fLfF/0czKfDEN8kgeqd7lLXgYjdGXLk1DM=; b=uu3rpHf3M7UrtNGeecFEI8CHmE5/cL+BcPXOAP0GgqAZxkIirltEyu7hoI9q0fgbQU RPr8RmMiXayDV9MFW4iLeR/mitlUYPOf5fqUUC926Z4MlBi2y0c3YozH1iHYlbsdJ/HF 2dYvKaNux6fky1EIndZzJRNQ3kX1mFm4vVpkFpKQX1gB1tQ/qisJzDi2ESwzP8BRd3bE F1T3qsJ08WMWMEjtaRZVC8egSyuyxZypHyzdOtKmvlxTv7habdXqrG2WdRvIB8aDw16m /inUEU+cYahAyW6Q70Ibavasr+oG1RqpHYXJrLF6GVqVImAGcHvKpXs/7BLcuexxjeoZ okcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bWH7oLCA3fLfF/0czKfDEN8kgeqd7lLXgYjdGXLk1DM=; b=r/aR8oQEjQdD98q05qYqRJextUcrvMjxW/l/0gCuqhUlMN8QqGGdJKx5cni4wirEJV BBATNLn8kSfscskjclPVwnj5amPRGF4EKvVvsFxQc907vuvtT6eCeH4W58xWeWCAkZTM YUiGcuz3y3yVHh0bcI86qxYiQOobUXFE6jsprFV1aSUVmXG2xUg9M3yVhEK2rZo8R0mE lT9SskjxzkH2tMPOVsyBnkzUoP8SyyLIZbGOJB/4aympGtBUdk6iZTpPEDqrrhPh6D0u cMhNo/iq+BL7jmRBVV//1+lnaif75h9nfUbGTckjbfjzJiJRTFusrn10+MOChM6CwkQ3 n99w== X-Gm-Message-State: AA+aEWYmxPB9D0kQ7+tcmMN1P0QkkUK3FbzBEDHnlAcey5R34AM+v2Xf QkpN4fZ0ECvArfJctovcSa8Rd8RWK1E= X-Google-Smtp-Source: AFSGD/XNjhunlLGeDzDFrZz3MTgqOK+hYMDWt4w55oeJnZEWTx+0wNWM4R0n60ICloHFskFfA6TVkg== X-Received: by 2002:a65:4b82:: with SMTP id t2mr24521321pgq.189.1544133941640; Thu, 06 Dec 2018 14:05:41 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id d11sm1327354pgi.25.2018.12.06.14.05.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 14:05:40 -0800 (PST) To: Gert Doering Cc: Christian Huitema , Ole Troan , tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> <20181206091314.GC1543@Space.Net> From: Brian E Carpenter Message-ID: Date: Fri, 7 Dec 2018 11:05:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <20181206091314.GC1543@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 22:05:50 -0000 Gert, On 2018-12-06 22:13, Gert Doering wrote: > Hi, > > On Thu, Dec 06, 2018 at 01:48:29PM +1300, Brian E Carpenter wrote: >> And I don't think that is an oversight. The *definition* of "router" >> for IPv6 is "a node that forwards IPv6 packets not explicitly addressed >> to itself." No mention of filtering, classification, admission control,... > > This definition of a router is nice, but such a device will not be > useful in today's Internet. Are you saying that *every* router in a carrier network needs to perform filtering? I would have thought that this would be done where necessary, but intentionally avoided elsewhere, to reduce energy consumption and improve throughput. Anyway... > What do you want this draft to be? Theoretically beautiful, or useful > for people operating outside a closed and well-controlled network? I wasn't actually thinking about this draft; I was just trying to make the (obvious) point that IPv6 was designed a certain way and that is what the IPv6 standards track documents deal with. This draft is directed at the operational community and I fully agree with you that it needs to match operational reality as much as possible. (My issues with the draft were fixed before it moved to IETF Last Call.) Brian From nobody Thu Dec 6 14:10:26 2018 Return-Path: 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 B63631311E6; Thu, 6 Dec 2018 14:10:24 -0800 (PST) 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 y1uzcp3PNjr7; Thu, 6 Dec 2018 14:10:23 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0808C1311E1; Thu, 6 Dec 2018 14:10:22 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wB6MAK78089860 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2018 22:10:20 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Brian E Carpenter Cc: IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , tsv-art References: <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> <20181206091314.GC1543@Space.Net> From: Nick Hilliard Message-ID: Date: Thu, 6 Dec 2018 22:10:19 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.6 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 22:10:25 -0000 Brian E Carpenter wrote on 06/12/2018 22:05: > Are you saying that*every* router in a carrier network needs to > perform filtering? every interface to a second- or a third-party needs filter rules applied, yes. In practice, this means deploying ACLs on everything except for devices acting in a pure core role. Nick From nobody Thu Dec 6 14:16:38 2018 Return-Path: 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 613081311D9; Thu, 6 Dec 2018 14:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 ulm0VgoS6zT8; Thu, 6 Dec 2018 14:16:32 -0800 (PST) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 150A2130F4D; Thu, 6 Dec 2018 14:16:32 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id w4so824185plz.1; Thu, 06 Dec 2018 14:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XjjU7sKLClkbGTBPwy286BRU6MRh25bn89efqpBEPto=; b=PH7xlwuA2Sw4KrqDeTntULd7Sti+8OK8cHbpEb1Uw2S9yeC36XORCvL761JL/lOIjR m5ZSK6klgavZwcy+pjHvjESwx8ggTXdXsqwavhndnKlBgr/duNeq9t60WMTv5Au/+vZF nGzm0gI2GsUm/6uigr+366abJn8UXoDYCGtvMNmuJVDlaVrder4GgXInWloIbCin79Fp ZDATMJtqYkVkvNuYiDWhW+RaXxASiDlJEJZXbgL36gmCrD1dlmNKTV3/H++IT3BJSWMz g5pD/sQUGUC7futeZt4f/syy8olgHKNAseA/NnwORcBM1aj+E73xqocqok7mOcxYzPQa ve+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XjjU7sKLClkbGTBPwy286BRU6MRh25bn89efqpBEPto=; b=sboQfKL+/d9EZtI6SJBBbqO3A2uzM/AE+blNT+q3EmB4OVFw9TzTNVzb/q9RPZrT37 pFZSg/wksOuBJT8lkz9PWD1Y5briYmguxfJqF3FaXonbMIz6pwSUL90R+EHPtWCA9sIA i0nSws9qyFiN+ZTEh0m++BqQasPUFbpQQcqu7QhDt0hfx36HjY4/2mMJ9b4bn0ACJ38p /fb6lvp4MldgBiWP5x5Rj7Yuv/U04bSVRRQ8njdEzxYEWhON7C8l65OuzTfaqN2IGEGW Xn9yVqa2NPDHCdC4gVDaD1yiTjdCkgk3XR0kcgEpwmjbSL2t9zyZesmaRJ2pFVggV+eP p8cw== X-Gm-Message-State: AA+aEWYIgJEdJ4b69IJmpy3VX84XNwPSq3TBF5qNWtZidF9ceHC/JzTD RuRec2fLgsMA77CciwiokA085HBOj4g= X-Google-Smtp-Source: AFSGD/WrEjmB5+X1fYInJH1r/MsSuMmzXfElJdxGT3sfKI42K+6loDy5m455GliBXw9Mnr7jYqCAkQ== X-Received: by 2002:a17:902:82c2:: with SMTP id u2mr29918075plz.110.1544134591346; Thu, 06 Dec 2018 14:16:31 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id 78sm1671370pft.184.2018.12.06.14.16.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 14:16:30 -0800 (PST) To: Nick Hilliard Cc: tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <3744b28c-3a5a-1ce4-9ff7-5374804d332e@gmail.com> <35277330-4743-4690-8ae0-9a9ab7e34f05@foobar.org> From: Brian E Carpenter Message-ID: <3a182a82-b933-2d9b-52a8-24805717879b@gmail.com> Date: Fri, 7 Dec 2018 11:16:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <35277330-4743-4690-8ae0-9a9ab7e34f05@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 22:16:35 -0000 On 2018-12-07 11:02, Nick Hilliard wrote: > Brian E Carpenter wrote on 06/12/2018 20:35: >> But there's a preliminary question: how widely is the flow label set >> by sending hosts? The answer is: widely, by modern o/s releases. But not >> much, by legacy o/s releases. > > more to the point, if you were going to implement a forwarding device, > do you depend solely on the flow label? > > This gives end-user device control over the hashing path on a purely > discretionary basis. I.e. and end user can change the flow label and > consequently make their own decisions about which network path to use, > without affecting any other transmission characteristic of the network > flow, e.g. port numbers, IP addresses, etc. Well, ECMP would be based on the {dest, srce, flow_label} 3-tuple so it's only the layer 4+ info that's missing. That will be missing anyway when encryption takes over. And any source that plays silly games with the flow label will damage its own users more than it damages the network. > Operationally, flow labels can cause grief. APNIC had a blog posting on > this a while back > > https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ By Joel J, who generally knows what he's talking about. "By in large, this flow label changing behaviour has been traced to IPv6 supporting CPE/firewalls, which change the flow label between the initial syn and the ack." Broken middleboxes can prevent anything from working properly. > Most devices allow the operator to selectively use flow labels as an > entropy source for hashing. And that's progress. Again, the flow label is a long-term play that will become more important as encryption becomes more of a factor. Brian From nobody Thu Dec 6 14:41:00 2018 Return-Path: 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 66759131200 for ; Thu, 6 Dec 2018 14:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Js2p45otNTcf for ; Thu, 6 Dec 2018 14:40:45 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 B22CD1311F7 for ; Thu, 6 Dec 2018 14:40:41 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id v15-v6so1843365ljh.13 for ; Thu, 06 Dec 2018 14:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pONqBsPmyYROMt5oiLxkKKpeif3uHucMM7LiP4H4SN8=; b=Pu9v4knNpWfoSWSYg4TppPPMu94ZQKrA833BD5IzLNmJZnR81FZXoE4eVtWOAG7ssV IDGbpWfY+EblQn0DaRemiNP6KmM5KUt3EDjINMJY2jdBlO1USdWFfs9E6xhH47TduGqm 5kEogzXGwaMlarIs7hzKZDsK/bEuL+8uJxQq3R9NodNEJXitAUZVhmeQKhu6tVezHtBr E85/MnCD8qsEvOK/IxXNGEKxqgbY8E9UxP9EhflpY4cc4ibToRb2NEfeR2McKwpGOnnA 1yGzgtIB3rJyIFWrEmVxqUs4tWk4P4T7cXO4o30BwzrOhSXgo0xYfskd07n0PRkqeJzq VUyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pONqBsPmyYROMt5oiLxkKKpeif3uHucMM7LiP4H4SN8=; b=S/QBHHLFQyCGjAbQBuCRb4ILg9iL/1Dak5dnXmi2QQY4AKnB7sz134JSlsPRJt0exr gg2uZmS7fLnVCFQy61jzXirqIuBkAufjtUFgJAVOJAmXN4o8R/kZUDM9saWTru4or+oM uPsW3Q2Qn7nxl/5JecKjsshekiC0SIl2qAULa6BRNqurX7To1W7jHS3DPtj0S6tNELL6 4DlL38pQu9CxQFu0l3Dddh33DEcBgjrjkzLmCZC8LVuRv/FTxI68s/c5LT7xMK5Otg9U gShPbmB3u8Zu0bFG1iNPUZjuGzym0/Rh/x9xzBWo6wcULbADW5koAtEvZa9YIFG6NA5b 0GRw== X-Gm-Message-State: AA+aEWbDH8/s/fpSgqZIp4yrut6NciSdVwJWKEjwXXtlCL1o42UmpI1B Wana6JX0bBPhj9iB5glCdqoxWrWfwcz+RXmJ0qQAiQ== X-Google-Smtp-Source: AFSGD/X7WfzCe0EfHANOXmKuxazGjp2YScSuACpeIAw0AiSsIhes8C2Y0ztcDGYiLdzFZRms1CEwUBlivbN8ivYAAiA= X-Received: by 2002:a2e:9a84:: with SMTP id p4-v6mr19251212lji.73.1544136039779; Thu, 06 Dec 2018 14:40:39 -0800 (PST) MIME-Version: 1.0 References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> In-Reply-To: <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> From: Eric Rescorla Date: Thu, 6 Dec 2018 14:40:00 -0800 Message-ID: To: jared@puck.nether.net Cc: Spencer Dawkins , IETF discussion list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec@ietf.org, tsv-art@ietf.org, gert@space.net Content-Type: multipart/alternative; boundary="00000000000022e535057c6230d7" Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 22:40:49 -0000 --00000000000022e535057c6230d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 6, 2018 at 11:24 AM Jared Mauch wrote: > > > > On Dec 6, 2018, at 9:05 AM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Speaking as an individual who ballots on working group charters ... > > > > On Thu, Dec 6, 2018 at 7:38 AM Stewart Bryant > wrote: > > > > > > On 06/12/2018 12:57, Gert Doering wrote: > > > Hi, > > > > > > On Thu, Dec 06, 2018 at 10:28:53AM +0000, Stewart Bryant wrote: > > >> However, aren't we moving to a world where new protocols get carried > > >> over UDP anyway? > > > Over HTTPS, you intended to say? > > Some and some. It depends on what aspect of the stack you spend your > > time thinking about. > > > > "you're both right" :-) ... > > > > As noted earlier in this thread, we punted new transport protocols into > UDP encapsulation at roughly the "we can't get SCTP deployed at scale, we > can't get DCCP deployed at scale, and we don't see any reason to think th= at > any new transport protocol will be any different" stage, at least a decad= e > ago. So, when I see people talking about SCTP, it's usually in a context > like RTCWeb, where the stack looks like SCTP/DTLS/UDP, and QUIC is only > defined over UDP. > > > > (I suspect the world would have been a slightly better place if we'd > done the DCCP encapsulation in UDP from day 1, because DCCP functionality > could have been really useful when we started encapsulating every known > network protocol in UDP, but that's not relevant to this discussion) > > > > But since QUIC's initial deliverable includes its HTTP mapping, > https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ comes into > play. I would oversimplify that draft as saying "we are way more excited > about applications using HTTP as a substrate now, than we were in 2002", > so, yes, the future smells a lot like HTTPS over (mumble) over UDP, at > least to me. > > > > I don't know that's a perfect plan, but I've been balloting on working > group charters for at least 3 years, assuming that it's a plan. > > Yes, we=E2=80=99ve also seen the security/crypto all the things overreach= impact > the routing area as well. We=E2=80=99ve not seen a suitable option to re= place TCP > transport that is viable due to the timescales involved. I=E2=80=99ve pr= ovided > feedback at the mic in London in SAAG about the problems of this for peop= le > who need very reliable transport, some level of transport security but do > not want or require transport privacy. > Jared, I'm not entirely sure I know what you're talking about here. If I recall your comments at the microphone correctly, they were about the challenges with TCP-AO. However, I wouldn't really call TCP-AO an example of security/crypto overreach. Rather, it was an attempt to fulfill what we understood to be asks from the routing area (key agility, a stronger algorithm than MD5). And of course TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate on what you're referring to here? -Ekr > - Jared > --00000000000022e535057c6230d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Dec 6, 2018 at 11:24 AM Jared Mauch <jared@puck.nether.net> wrote:


> On Dec 6, 2018, at 9:05 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gm= ail.com> wrote:
>
> Speaking as an individual who ballots on working group charters ... >
> On Thu, Dec 6, 2018 at 7:38 AM Stewart Bryant <stewart.bryant@gmail.com> = wrote:
>
>
> On 06/12/2018 12:57, Gert Doering wrote:
> > Hi,
> >
> > On Thu, Dec 06, 2018 at 10:28:53AM +0000, Stewart Bryant wrote: > >> However, aren't we moving to a world where new protocols = get carried
> >> over UDP anyway?
> > Over HTTPS, you intended to say?
> Some and some.=C2=A0 It depends on what aspect of the stack you spend = your
> time thinking about.
>
> "you're both right" :-) ...
>
> As noted earlier in this thread, we punted new transport protocols int= o UDP encapsulation at roughly the "we can't get SCTP deployed at = scale, we can't get DCCP deployed at scale, and we don't see any re= ason to think that any new transport protocol will be any different" s= tage, at least a decade ago. So, when I see people talking about SCTP, it&#= 39;s usually in a context like RTCWeb, where the stack looks like SCTP/DTLS= /UDP, and QUIC is only defined over UDP.
>
> (I suspect the world would have been a slightly better place if we'= ;d done the DCCP encapsulation in UDP from day 1, because DCCP functionalit= y could have been really useful when we started encapsulating every known n= etwork protocol in UDP, but that's not relevant to this discussion)
>
> But since QUIC's initial deliverable includes its HTTP mapping, https://datatracker.ietf.org/doc/draft-ie= tf-httpbis-bcp56bis/ comes into play. I would oversimplify that draft a= s saying "we are way more excited about applications using HTTP as a s= ubstrate now, than we were in 2002", so, yes, the future smells a lot = like HTTPS over (mumble) over UDP, at least to me.
>
> I don't know that's a perfect plan, but I've been ballotin= g on working group charters for at least 3 years, assuming that it's a = plan.

Yes, we=E2=80=99ve also seen the security/crypto all the things overreach i= mpact the routing area as well.=C2=A0 We=E2=80=99ve not seen a suitable opt= ion to replace TCP transport that is viable due to the timescales involved.= =C2=A0 I=E2=80=99ve provided feedback at the mic in London in SAAG about th= e problems of this for people who need very reliable transport, some level = of transport security but do not want or require transport privacy.

Jared,

I'm not e= ntirely sure I know what you're talking about here. If I recall your co= mments at the microphone correctly, they were about the challenges with TCP= -AO. However, I wouldn't really call TCP-AO an example of security/cryp= to overreach. Rather, it was an attempt to fulfill what we understood to be= asks from the routing area (key agility, a stronger algorithm than MD5). A= nd of course TCP-AO doesn't attempt to provide privacy. Perhaps you can= elaborate on what you're referring to here?

-Ekr


- Jared
--00000000000022e535057c6230d7-- From nobody Thu Dec 6 16:44:16 2018 Return-Path: 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 D4925131284; Thu, 6 Dec 2018 16:44:01 -0800 (PST) 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 QV06ogakxfoy; Thu, 6 Dec 2018 16:43:59 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499C8131264; Thu, 6 Dec 2018 16:43:54 -0800 (PST) Received: from [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1] (unknown [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 7F4F2540517; Thu, 6 Dec 2018 19:43:52 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jared Mauch In-Reply-To: Date: Thu, 6 Dec 2018 19:43:51 -0500 Cc: Gert Doering , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC , Christian Huitema , tsv-art Content-Transfer-Encoding: quoted-printable Message-Id: <5FAF0628-A2B0-4AD6-A5B5-4B472F812C70@puck.nether.net> References: <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> <20181206091314.GC1543@Space.Net> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 00:44:08 -0000 > On Dec 6, 2018, at 5:05 PM, Brian E Carpenter = wrote: >=20 > Gert, >=20 > On 2018-12-06 22:13, Gert Doering wrote: >> Hi, >>=20 >> On Thu, Dec 06, 2018 at 01:48:29PM +1300, Brian E Carpenter wrote: >>> And I don't think that is an oversight. The *definition* of "router" >>> for IPv6 is "a node that forwards IPv6 packets not explicitly = addressed >>> to itself." No mention of filtering, classification, admission = control,... >>=20 >> This definition of a router is nice, but such a device will not be=20 >> useful in today's Internet. >=20 > Are you saying that *every* router in a carrier network needs to > perform filtering? I would have thought that this would be done > where necessary, but intentionally avoided elsewhere, to reduce > energy consumption and improve throughput. Anyway=E2=80=A6 Depends on how you build your network, but yes, every router needs to perform filtering and you want it done in hardware as well. >> What do you want this draft to be? Theoretically beautiful, or = useful >> for people operating outside a closed and well-controlled network? >=20 > I wasn't actually thinking about this draft; I was just trying to make > the (obvious) point that IPv6 was designed a certain way and that is > what the IPv6 standards track documents deal with. This draft is = directed > at the operational community and I fully agree with you that it needs > to match operational reality as much as possible. (My issues with the > draft were fixed before it moved to IETF Last Call.) We learned in the late 90s and early 2000=E2=80=99s about the problems = of processing things like IP options and their complexity. Most providers turn off or filter these as they are a risk to the control plane of the device and there could be loss of control of the device due to the CPU being consumed with these packets. You can=E2=80=99t have a few hundred = gigs Of traffic going to the CPU, no matter what scale you think the router is. - Jared= From nobody Thu Dec 6 19:49:32 2018 Return-Path: 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 D00AB12E043; Thu, 6 Dec 2018 19:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001] autolearn=no 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 mYqeeG5Imqgj; Thu, 6 Dec 2018 19:49:19 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0120012D4ED; Thu, 6 Dec 2018 19:49:18 -0800 (PST) Received: from [IPv6:2001:470:5:ac9:cc1f:b80c:610:c376] (unknown [IPv6:2001:470:5:ac9:cc1f:b80c:610:c376]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EE376826DD; Fri, 7 Dec 2018 04:49:12 +0100 (CET) To: Brian E Carpenter , Nick Hilliard Cc: tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <3744b28c-3a5a-1ce4-9ff7-5374804d332e@gmail.com> <35277330-4743-4690-8ae0-9a9ab7e34f05@foobar.org> <3a182a82-b933-2d9b-52a8-24805717879b@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <68b2a674-7209-09cb-2063-fd97ee11cce9@si6networks.com> Date: Thu, 6 Dec 2018 20:04:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <3a182a82-b933-2d9b-52a8-24805717879b@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 03:49:24 -0000 On 6/12/18 19:16, Brian E Carpenter wrote: > On 2018-12-07 11:02, Nick Hilliard wrote: >> Brian E Carpenter wrote on 06/12/2018 20:35: >>> But there's a preliminary question: how widely is the flow label set >>> by sending hosts? The answer is: widely, by modern o/s releases. But not >>> much, by legacy o/s releases. >> >> more to the point, if you were going to implement a forwarding device, >> do you depend solely on the flow label? >> >> This gives end-user device control over the hashing path on a purely >> discretionary basis. I.e. and end user can change the flow label and >> consequently make their own decisions about which network path to use, >> without affecting any other transmission characteristic of the network >> flow, e.g. port numbers, IP addresses, etc. > > Well, ECMP would be based on the {dest, srce, flow_label} 3-tuple so > it's only the layer 4+ info that's missing. That will be missing anyway > when encryption takes over. If crypto == TLS, that need not. > And any source that plays silly games > with the flow label will damage its own users more than it damages > the network. > >> Operationally, flow labels can cause grief. APNIC had a blog posting on >> this a while back >> >> https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ > > By Joel J, who generally knows what he's talking about. > > "By in large, this flow label changing behaviour has been traced to IPv6 supporting CPE/firewalls, which change the flow label between the initial syn and the ack." FWIW, FreeBSD had this behaviour -- without middleboxes involved ... haven't checked recently to see if that's still the case Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 6 21:10:35 2018 Return-Path: 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 C7A3D12777C; Thu, 6 Dec 2018 21:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 5ZIJqkKxz2tD; Thu, 6 Dec 2018 21:10:16 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 CDD4312008A; Thu, 6 Dec 2018 21:10:15 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id z7so5180877iti.0; Thu, 06 Dec 2018 21:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NVdZgdKjmjMPzwjnsFuUMdSaU8txxBHTG5A7Z70ynUs=; b=tnvYTVqYYWWlp68z+AqO+yU6oI63o9aBPRzg4FzgBbSUU9+CEDDNeZiMf7eX7niVN6 RZm86mf0+rz5gMA7WgaLQmeb6XB3KAOLI1UvPeDHC7llx1KjGq6okOp/4B+4SIqFnx9S lOCdZVtA0qcaRyXn/xqj3m5O4qJFfEqtI03/BUgn2+H7r+9RXPEtg33PB4d3dehk6UkP f+s+oufsKNQUQBnHt90lzxsV2j+Zec5z8cTRoLrI3UmWyQkJEilpRyrXuXXhjmc5x0YH WtibQUJPKFREIEPw/iMYCxn9T6O3UGOwE54aE8h2jPqTJueA7dL6/5rvH1TzSJPfSENW LAPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NVdZgdKjmjMPzwjnsFuUMdSaU8txxBHTG5A7Z70ynUs=; b=Az9U0kzlBXJR2wlVTLobByvyVR1wvQ16LkWjuJ4sVAaWXmPewHiwyNwMpwyU+z9sjV Bl5FlNR5WX3B7iLQnI9puDy2pnFKW4SPf+SFtI1SNylevUaBS8VfrexBlclDWiVTZybB j8IxeodSz/Bp/8gINfvSzgs00Te7L5SE6grkJ0nIjvkYVvlZCrLxd2sTFR+EgnS2bWgl 7l1OdVSdE7qzZ+dVJgyOVwN3tHxMSrK7BezMcqwz44kHnSFrnLLcMK2hbp5l4zOD8nAL mAzS95AVxATkQzpcoX0kmWeo5aPx59dde8hXv1G+4bpf1xUpIIYW4W+d5Uio6OEoQ3MZ JgQw== X-Gm-Message-State: AA+aEWYifph77tDOHyi/w0ypLEvlUDCEnV2cW9gLu+yk6FIwyUeLIHpO TwTK81RKoQKYsm9jyqM548LkdQD64dJP/xebmDw= X-Google-Smtp-Source: AFSGD/USafXbCyiapMsxR4PBaTneLnUuga4df0Jy5Kgqld0cdRbUuTPc08zKnogr6lOD466sQSkjJ55uGRHcSMmEzg4= X-Received: by 2002:a02:8244:: with SMTP id q4mr633160jag.43.1544159414914; Thu, 06 Dec 2018 21:10:14 -0800 (PST) MIME-Version: 1.0 References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> In-Reply-To: From: Christopher Morrow Date: Fri, 7 Dec 2018 00:10:02 -0500 Message-ID: To: Eric Rescorla Cc: Jared Mauch , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec wg mailing list , tsv-art@ietf.org, Gert Doering Content-Type: multipart/alternative; boundary="000000000000671211057c67a1ac" Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 05:10:21 -0000 --000000000000671211057c67a1ac Content-Type: text/plain; charset="UTF-8" On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla wrote: > > routing area (key agility, a stronger algorithm than MD5). And of course > TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate on > what you're referring to here? > >> >> "TCP-AO is a lie, there is zero deployable code anywhere that supports it" was that the gist of his comment? it'd be the whole of mine... because honestly it's the truth. --000000000000671211057c67a1ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Dec 6, 2018 at 5:41 PM Eric Rescorla <= ekr@rtfm.com> wrote:

routing area (key agility, a = stronger algorithm than MD5). And of course TCP-AO doesn't attempt to p= rovide privacy. Perhaps you can elaborate on what you're referring to h= ere?

<= /blockquote>

"TCP-AO is a lie, there is zero deploy= able code anywhere that supports it"

was that= the gist of his comment?
it'd be the whole of mine... becaus= e honestly it's the truth.=C2=A0
--000000000000671211057c67a1ac-- From nobody Thu Dec 6 21:27:48 2018 Return-Path: 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 7310012896A; Thu, 6 Dec 2018 21:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 as--4Ao8yY6d; Thu, 6 Dec 2018 21:27:44 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 664B51277C8; Thu, 6 Dec 2018 21:27:44 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id r9so2379087ioa.1; Thu, 06 Dec 2018 21:27:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AUKcOebTcBHmLn7NvNuve3zDqFjYnPJshQaGH5Yw8Jo=; b=S8TchmPJ240i9rmBg3r47z7ztXVSRGnvCoGmC75QzRBHlJwduED5jJtK8uAoRYSwyi 5ORd/+d6bG+o5qfh71vL16o+/T+BtBb4ud0t/0M0WzxymUGBjC/7D6og2b9MNWEf1O4S HG1QhDelvYUC3k1ve7BpVKV1CYz3+UUFhdJ4tp0D2QrzIAuHlv9ZQYCvecgqzYQu84Z7 zjL6hlNOBR/1PIn/neqy5wGd0R0wiZcSilBEoe3G/b2gll9XGwg8nTh7hnszjZTUyUr2 hES/nlqlid2Gb4MWjMrDQo1abv+2D5nJkalWXO6oXJnwudBX16SBtyaeplKPO330mKhh Bx0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AUKcOebTcBHmLn7NvNuve3zDqFjYnPJshQaGH5Yw8Jo=; b=eRHKl3D7Q0s9vcpX9JMe8qg4PLHoqSPe2x7x0y1MYxBRJMn+G2izJtUE8jgcmg/3Wa Ea2pqEQGKg0EqJfM4qRALypCDITFyDqvzx2LRxmSm4bll6DWO4bonrIoMZLy7Ex2fpFu 4Sa39F4gkAWFVwDOh1hFuAYnH/H4hSXEl0E0WYVOjghuvkZI7g6bkWSfbysGhJgmjOnP Dns4yZrcqTB2/b/rZrez7SqYPdK6vv5WmdZZhKr2FYmAZWl6VhVhDGOoPrDi2nl+iioC Uh62nj5xtPMOJ9VPPf1Uv6267F2Z8y8jTf46Z41fABkZ1DNGycOrjGEXBGjEweok2DZl g1Tw== X-Gm-Message-State: AA+aEWaDRl1LL3BK52GJmFDMnjamU2rW75FVvBxvm9ZnnMv4OiM0vOzp dSXQAycDwF6S2kJ2iqt4oNKcFrhyHpFXAKu0n18/zP6l X-Google-Smtp-Source: AFSGD/VfOy7XXecWtNv/HCDQt3Nxo3svvAhU/Ao12kkekxDiix4n/thh6GbaX5m/JJNjz2sTHiqCoz5V0TjnPlehIrk= X-Received: by 2002:a5d:8ac6:: with SMTP id e6mr523734iot.235.1544160463370; Thu, 06 Dec 2018 21:27:43 -0800 (PST) MIME-Version: 1.0 References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> <811D965A-149E-4E33-A526-2CFCB7A1882B@strayalpha.com> In-Reply-To: From: Christopher Morrow Date: Fri, 7 Dec 2018 00:27:32 -0500 Message-ID: To: Joe Touch , ombudsteam@ietf.org, tsv-ads@ietf.org, ops-ads@ietf.org Cc: tsv-art@ietf.org, opsec wg mailing list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ietf Content-Type: multipart/alternative; boundary="000000000000e541dd057c67dfa7" Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 05:27:46 -0000 --000000000000e541dd057c67dfa7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 6, 2018 at 9:11 AM Joe Touch wrote: > > > On Dec 5, 2018, at 10:28 PM, Christopher Morrow > wrote: > > > > On Thu, Dec 6, 2018 at 12:31 AM Joe Touch wrote: > >> Additionally, packets don=E2=80=99t emerge from different mole endpoints= or are >> IP processed in any way. The mold acts like a wire, which is fine. That >> can be done by IP tunnels too. But not routers that converge and diverge >> packets. >> > > That got mangled by autocorrect. Packets aren=E2=80=99t supposed to be I= P > processed by links. To the extent that MPLS does this, it is broken vs th= e > Internet arch. Remember that MPLS tries to emulate a router path that > can=E2=80=99t keep up. It can - and does - fail to do so correctly in so= me cases. > > Joe, frankly I'm pretty sad that your behavior here is such as this. I would like the IETF Ombudsteam to have a chat with you are your behavior and your lack of listening to reasoned input from folk who both implement and operate networks, equipment and the protocols which make up the Internet at large. You are not helping your case nor the case of the protocols in question. If the ombudsteam are unable/unwilling to interact here I'd like the responsible ADs for ops/tsv to have a chat with you about this. Again, if HBH headers are meaningless and not needed, then go through the >> proper process and remove them from IPv6. If not, stop trying to hobble >> this protocol to the point where we all realize why nobody wants to use = it. >> >> > I think everyone here is actually happy to see v6 progress. > > > As am I - in Standards. It shouldn=E2=80=99t =E2=80=98progress=E2=80=99 = on ops. > > note I'm not trying to be intentionally combative, just attempting to say= : > "the best answer for the user here is PROBABLY to just have the core igno= re > all the EH business entirely" > > > Again, if they=E2=80=99re not needed, fine. Remove them in Standards. > > However, if the role of ops is to decide what standards to ignore, then > perhaps the IESG should reconsider the area=E2=80=99s charter. > > Joe > --000000000000e541dd057c67dfa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Dec 6, 2018 at 9:11 AM Joe Touch <touch@strayalpha.com> wrote:


On Dec 5, 2018, at 10:28 PM, Christopher Morrow <morrowc.lists@gmai= l.com> wrote:



On T= hu, Dec 6, 2018 at 12:31 AM Joe Touch <touch@strayalpha.com> wrote:
Additionally, packets don=E2=80=99t emerge from d= ifferent mole endpoints or are IP=C2=A0 processed in any way. The mold acts= like a wire, which is fine. That can be done by IP tunnels too. But not ro= uters that converge and diverge packets.

That got mangled by autocorrect.=C2=A0 Pa= ckets aren=E2=80=99t supposed to be IP processed by links. To the extent th= at MPLS does this, it is broken vs the Internet arch.=C2=A0 Remember that M= PLS tries to emulate a router path that can=E2=80=99t keep up.=C2=A0 It can= - and does - fail to do so correctly in some cases.


Joe, frankly I'm pretty sad that your behavio= r here is such as this.
I would like the IETF Ombudsteam to have = a=C2=A0 chat with you are your behavior and your lack of listening to reaso= ned input from folk who both implement and operate networks, equipment and = the protocols which make up the Internet at large. You are not helping your= case nor the case of the protocols in question.
=C2=A0
If the ombudsteam are unable/unwilling to interact here I'd like the r= esponsible ADs for ops/tsv to have a chat with you about this.
Again, if HBH headers are meaningless and not needed, then go through the p= roper process and remove them from IPv6. If not, stop trying to hobble this= protocol to the point where we all realize why nobody wants to use it.

I think everyone here is actually hap= py to see v6 progress.

A= s am I - in Standards.=C2=A0 It shouldn=E2=80=99t =E2=80=98progress=E2=80= =99 on ops.

note I'm not trying to be intentio= nally combative, just attempting to say: "the best answer for the user= here is PROBABLY to just have the core ignore all the EH business entirely= "=C2=A0

Again, if they=E2=80=99re not needed, fin= e. Remove them in Standards.

However, if the role = of ops is to decide what standards to ignore, then perhaps the IESG should = reconsider the area=E2=80=99s charter.

Joe
--000000000000e541dd057c67dfa7-- From nobody Fri Dec 7 01:24:38 2018 Return-Path: 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 0197A130DDE for ; Fri, 7 Dec 2018 01:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 0nHKZR-UcaKs for ; Fri, 7 Dec 2018 01:24:26 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3AF130DE1 for ; Fri, 7 Dec 2018 01:24:22 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3C4D941C41 for ; Fri, 7 Dec 2018 10:24:20 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 22E99418E5; Fri, 7 Dec 2018 10:24:20 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 1C7F416E71; Fri, 7 Dec 2018 10:24:20 +0100 (CET) Date: Fri, 7 Dec 2018 10:24:20 +0100 From: Gert Doering To: Brian E Carpenter Cc: Gert Doering , Christian Huitema , Ole Troan , tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-ID: <20181207092420.GN1543@Space.Net> References: <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <20181205180855.GR1543@Space.Net> <6b9dac4f-4d57-7778-bbbe-78ebe399962f@huitema.net> <20181206091314.GC1543@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NeBFRwWgvjTuyTVb" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 09:24:34 -0000 --NeBFRwWgvjTuyTVb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Dec 07, 2018 at 11:05:35AM +1300, Brian E Carpenter wrote: > On 2018-12-06 22:13, Gert Doering wrote: > > On Thu, Dec 06, 2018 at 01:48:29PM +1300, Brian E Carpenter wrote: > >> And I don't think that is an oversight. The *definition* of "router" > >> for IPv6 is "a node that forwards IPv6 packets not explicitly addressed > >> to itself." No mention of filtering, classification, admission control= ,... > >=20 > > This definition of a router is nice, but such a device will not be=20 > > useful in today's Internet. >=20 > Are you saying that *every* router in a carrier network needs to > perform filtering? I would have thought that this would be done > where necessary, but intentionally avoided elsewhere, to reduce > energy consumption and improve throughput. Anyway... As of today, every border router connecting to other networks needs to be able to do inbound rate-limiting by traffic class. Networks interconnect with 10G to multiple 100G, and inbound DDoS=20 nicely utilizes these pipes. Customer connections and internal network connections get filled, so you rate-limit the obvious crap ("inbound large NTP packets with many Gbit/s") at your borders to protect the=20 customer links and the internal network infrastructure. Inside the network, you could have "pure" forwarding devices that do not need to inspect L4/EH for transit traffic - correct. (We do observe hardware being developed around merchant silicon that actually specializes more and more for the "P" role - fast, cheap, and little support for anything but "forwarding") Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --NeBFRwWgvjTuyTVb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwKPEEACgkQ31bAZeTO f8Vseg//bi8h8vY2ZNHWMFgCRqttVN8a9FbpCcd2HBzOTt2MP0nvl5N9AGxx0G1F SoHi6wEVfueWIbBIbtHR686vqkCRS415QZLOeFL2YTrmBywWrSMt6TMB5N+zuKWv p/DxZGp15xtHAa02bhmRfw2UP5ERxdi4/s1yKXVlczXpIitDOHt7Abzbb7qkfudt kM9tUpLXT0fxzYCSmXIx+qHKTl36qdtCmTufidpCycMqa8Pd75mIE1Boax6M/SNA KJYSROcrjcQ12n59841naU1MiD54QXj0S/PAkOxS54vorxTHpmdyKgYy+7+mLCjt 8N+whnry/QA5w0cWcv5sJOfq5JyqbcBfJNKs/+Jn7PIoR1665jwRc5Qomo0VdhSL zGPjHHNIyEt089A3yZ8GNVCEdmXgh9rFuWzdH6huUtS+gKE5fsi2uWa0dbI7/i7J IrgVsXG8Fe2oCqwZqDnpQIrAbOl8iYAMyhBj0Vn7tmSxzIBBKUeAkj7CQansYwbn iwrxcRXT0w5oTuX+15gwk/L8v03RLd0cKplkcKX3oL4/LZOrItOQOEFOYexJB8gj wLVw1c9ijMmZ383jbto3q6QTeqZy+Lr5VU01g3o597cTgEmkGizYEwhkFNeXMnqm cksj+s1/if/FUafu4JAhsWbAuxeDNKNwZdgSvD9VITBD0E2FoRA= =aDrj -----END PGP SIGNATURE----- --NeBFRwWgvjTuyTVb-- From nobody Fri Dec 7 05:03:16 2018 Return-Path: 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 273B6128D68 for ; Fri, 7 Dec 2018 05:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Bm8BmfkEN03f for ; Fri, 7 Dec 2018 05:02:57 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 0E38512D84D for ; Fri, 7 Dec 2018 05:02:55 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id k15-v6so3474372ljc.8 for ; Fri, 07 Dec 2018 05:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AHh9o6qH8rx1HdF8tHV7hLMjbEMhz6/faR8iGtDE5GA=; b=CqqEXi2azI3Hxm8mV8b9bYm0oNcTSlf+hxSTzG7CbUSJEg0shvpiKOHpZoCR+IW6jX 3fM2fEfLSX5WJqBOeL/nTNWpDN1LgqglES4WsF1GyZxs4d+3XYlZPBVrBLniq6GtMhX+ VVLfn1gLE8cx1OVh/uYF7jx7gHKvn707fLK2oeueSmqM9qV81wa+W8V/fTLe1BxiELVu +QIbrkPZO7jQr+VTTvXC1YGaEWl1TR0zwRIHE+vMG+7Vvz7cSHYrF/kUeJH5w1Rvk33/ 2V5ALSrlzrrhop5+5IczPMCSMdmD577ag01BQXPOKtORHYlU6C0aA50jKLmNVCTZQGrG J8OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AHh9o6qH8rx1HdF8tHV7hLMjbEMhz6/faR8iGtDE5GA=; b=rBSoieOM/gQNs6Hvad630+uuevDpN861jvr1kv98fA0xLuYDYRfxbcgcACYbt0ptIB YfOoeI5a7c161VuXU5kPp/k5PIDcj0/09egCtVQ8ReTBjgxL/Ym4dg236K9elm461MLa TCm8/PZToejYfc0OYBKVdtY6Q6wFuROXgIQT7a2lLsqrfRnyR/+hM1qNI0FLty7jwbLE O9+OpVBu38cIBj25DLHXD0ptcAEftqOUkyELhsWi7sM4o9ZYX4FaDAdTytUouIlqoP93 LsT4C42x8YpoW/cpszndlDyK0sQdlMHSksrdivf8EJmRPhlA+ceFu+1yZQqqeSDnPVlI JhjA== X-Gm-Message-State: AA+aEWbVJtGA2Cq7ul/Aj+vnAW9FMQC6aohoPZu0jThT+dHMlSJ6LUM2 zPIVM1ezZ9f/R9i3rT3nXBXDrTPe/Yta1kf3f2WwXw== X-Google-Smtp-Source: AFSGD/Xx4y8FygJJhi4qdvc9Wnmn386133oySDNtKM1D8GqKLwdUa4b1l89RFYdgDJml5R2NqG+txfEJQBieGmzaKXM= X-Received: by 2002:a2e:2d11:: with SMTP id t17-v6mr1289155ljt.159.1544187773077; Fri, 07 Dec 2018 05:02:53 -0800 (PST) MIME-Version: 1.0 References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> In-Reply-To: From: Eric Rescorla Date: Fri, 7 Dec 2018 05:02:13 -0800 Message-ID: To: morrowc.lists@gmail.com Cc: jared@puck.nether.net, IETF discussion list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec@ietf.org, tsv-art@ietf.org, gert@space.net Content-Type: multipart/alternative; boundary="000000000000ae7434057c6e3b4c" Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 13:02:59 -0000 --000000000000ae7434057c6e3b4c Content-Type: text/plain; charset="UTF-8" On Thu, Dec 6, 2018 at 9:10 PM Christopher Morrow wrote: > > > On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla wrote: > >> >> routing area (key agility, a stronger algorithm than MD5). And of course >> TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate on >> what you're referring to here? >> >>> >>> > "TCP-AO is a lie, there is zero deployable code anywhere that supports it" > > was that the gist of his comment? > A rather more elaborated version of this it'd be the whole of mine... because honestly it's the truth. > Sure, but as I said, I don't think of TCP-AO as an example of crypto overreach. It's not something that security people tried to force on the routing people, but rather something that was designed to what we understood the requirements of the routing community. It's of course possible, perhaps even likely, that we got it wrong, but that's a very different thing. -Ekr --000000000000ae7434057c6e3b4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Dec 6, 2018 at 9:10 PM Christopher Morrow <morrowc.lists@gmail.com> wrote:


On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla <ekr@rtfm.com> wrote:
=

routing area (key agility, a stronger algorithm than MD5). And of = course TCP-AO doesn't attempt to provide privacy. Perhaps you can elabo= rate on what you're referring to here?


"= ;TCP-AO is a lie, there is zero deployable code anywhere that supports it&q= uot;

was that the gist of his comment?
=

A rather more elaborated version of = this


it'd be the whole of mine= ... because honestly it's the truth.=C2=A0

Sure, but as I said, I don't think of TCP-AO as a= n example of crypto overreach. It's not something that security people = tried to force on the routing people, but rather something that was designe= d to what we understood the requirements of the routing community. It's= of course possible, perhaps even likely, that we got it wrong, but that= 9;s a very different thing.

-Ekr

--000000000000ae7434057c6e3b4c-- From nobody Fri Dec 7 12:46:23 2018 Return-Path: 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 86528130E9D; Fri, 7 Dec 2018 12:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, 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 mmOBgZ4NBUoS; Fri, 7 Dec 2018 12:46:19 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7C9129AB8; Fri, 7 Dec 2018 12:46:19 -0800 (PST) Received: from [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1] (unknown [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 02CF05408BC; Fri, 7 Dec 2018 15:46:16 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jared Mauch In-Reply-To: Date: Fri, 7 Dec 2018 15:46:15 -0500 Cc: Eric Rescorla , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec wg mailing list , tsv-art@ietf.org, Gert Doering Content-Transfer-Encoding: quoted-printable Message-Id: References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> To: Christopher Morrow X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 20:46:22 -0000 > On Dec 7, 2018, at 12:10 AM, Christopher Morrow = wrote: >=20 >=20 >=20 > On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla wrote: >=20 > routing area (key agility, a stronger algorithm than MD5). And of = course TCP-AO doesn't attempt to provide privacy. Perhaps you can = elaborate on what you're referring to here? >=20 >=20 > "TCP-AO is a lie, there is zero deployable code anywhere that supports = it" >=20 > was that the gist of his comment? > it'd be the whole of mine... because honestly it's the truth.=20 I had written out a series of concerns around the requirements operators = have.. I can=E2=80=99t find the paper around my office right now I wrote = them on, but the went roughly like this: 1) We have long-lived TCP sessions, measured in years. (Implied: many = of the transport people really prefer stable routes without = flapping/jitter/reordering from us) 2) We use protocols that are stable as a result as transports 3) Security area does review and says =E2=80=9Cwhy is MD5 still a = thing=E2=80=9D without considering #2 and #1 above 4) When doing routing things like an iBGP mesh, key rotation can be = complex in a multivendor environment when the catastrophic failure of = the network substrate is the consequence of a software bug 5) If these keys (md5) are in use, they=E2=80=99re not rotated because = we got that support much later than the ability to set/rotate them and = coordination with a network partner to rotate them is feasible but = reaches operational impossibility. 6) We need protection from tampering with the transport, not encryption = of the transport. You will know where the routes go because I assume = you=E2=80=99ve used a tool like traceroute before. There was a longer list. The point of this thread is if you do something =E2=80=9Cinteresting=E2=80= =9D with your transport, be it IP options, EH, shift your protocol into = a space that operators have policed out of necessity (not because we = want it), expect broken things to happen. =20 It=E2=80=99s not the early 90s anymore and rolling these things back is = much harder than it was. I see daily attacks of hundreds of gigs of UDP = against customers, and these won=E2=80=99t make it far because we = won=E2=80=99t build network infrastructure to carry them to their = destination. We will mitigate the issue, and as always there is = collateral damage. If your protocol uses an ephermal port from Gert=E2=80=99s list to = connect to a well known port, expect there to be problems. (Look at the = history in the early 2000=E2=80=99s why this was built =3D> = http://www.zytrax.com/books/dns/ch7/hkpng.html#avoid ) This is not a limited problem to any single protocol, network, device = role, etc. It=E2=80=99s not clear to me the IETF is presently equipped = to respond to this, but I hope people are listening. - Jared= From nobody Fri Dec 7 13:00:11 2018 Return-Path: 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 D2CD2130FEC for ; Fri, 7 Dec 2018 12:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 D51Qj-qiXZjd for ; Fri, 7 Dec 2018 12:59:56 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 0F9CC130EFC for ; Fri, 7 Dec 2018 12:59:53 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id x85-v6so4710215ljb.2 for ; Fri, 07 Dec 2018 12:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jomI0hPxOxinyfl1XtJIy5FEls0bCr502cq84ac+FYM=; b=LD5UFd3+vt26WEZQhypQ5xjDlHipI1QCoy8cU68hD7jz8NvNVumvA3R4L1H9O8965n Uk0+JLC79esi3VV1B6p3xK9ZCxUEO4SLNJ8XTCeMc4Y44bmZuLvflGT66p2lSDpWoGuZ zH9o+tLb/OL7cv4TaZEwW1cl895nxb6S5An3WWS49lAuaCHI0qeYOqient1Fky5QncI1 RAaDid4UlZGc+7gv3m7BJcKatgG57B/AtXuR4qxG/UlCtQp6+w7kgVPDOkzlRYxEVHsR dw6EE4DT/7FEH9aftwSRV1bJwMk6yV/ItyDsf9b9yq0nmaL8Nycx1P+rj+UuaGbmb+kP UNzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jomI0hPxOxinyfl1XtJIy5FEls0bCr502cq84ac+FYM=; b=EbLQ1F26s76IKfaxp7aGiDtOjSRhxzGtXUIU1rpeD940vVKQAu7h5pXPHxpLJBvR7A br32q6mK6NkcUZD5jtBLGSaieNj4OdYcr2pY29PVRRLJAomRQJAAoMPKxAr13L1fD6zi 5DplfRXZYaql8VpI8t/VFEXPpnK7B1voeHrsyl/jwOtAu6wsFlBbmeQmWThxUTSVvkuR syj4Wwl7Br+FtO2eACewXNaYa+z0BeIAEL9mSlshYqdoTk/HWXgzw/tn5f1Sx/8unkVk oFE5ZCKgQr99glN0bDPNCBDvtOmVPeTsiOTufMSDSYbl41NhLadkUYXI016c1mmhucZf LIig== X-Gm-Message-State: AA+aEWbeYl7WGgyYn3se+0rNM9XDIrMI3eQWWe9F5Otf779H4h560uvn J/AO9ts4b4C2a1DHu4MrnKbEZmskt/EQfGC/TE6+yQ== X-Google-Smtp-Source: AFSGD/WLy+b77xd7Rrv9kSyaADNSaKSB+i10FVOydBNjDeokCb62cfsdqjajgZ+Uan1i97Cz4xzjzwTdGL5s8bRE6EE= X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr2398488ljb.51.1544216391189; Fri, 07 Dec 2018 12:59:51 -0800 (PST) MIME-Version: 1.0 References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> In-Reply-To: From: Eric Rescorla Date: Fri, 7 Dec 2018 12:59:09 -0800 Message-ID: To: Jared Mauch Cc: morrowc.lists@gmail.com, IETF discussion list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec@ietf.org, tsv-art@ietf.org, Gert Doering Content-Type: multipart/alternative; boundary="00000000000074223c057c74e5da" Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 20:59:59 -0000 --00000000000074223c057c74e5da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 7, 2018 at 12:46 PM Jared Mauch wrote: > > > > On Dec 7, 2018, at 12:10 AM, Christopher Morrow > wrote: > > > > > > > > On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla wrote: > > > > routing area (key agility, a stronger algorithm than MD5). And of cours= e > TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate on > what you're referring to here? > > > > > > "TCP-AO is a lie, there is zero deployable code anywhere that supports > it" > > > > was that the gist of his comment? > > it'd be the whole of mine... because honestly it's the truth. > > I had written out a series of concerns around the requirements operators > have.. I can=E2=80=99t find the paper around my office right now I wrote = them on, > but the went roughly like this: > > 1) We have long-lived TCP sessions, measured in years. (Implied: many of > the transport people really prefer stable routes without > flapping/jitter/reordering from us) > 2) We use protocols that are stable as a result as transports > 3) Security area does review and says =E2=80=9Cwhy is MD5 still a thing= =E2=80=9D without > considering #2 and #1 above > 4) When doing routing things like an iBGP mesh, key rotation can be > complex in a multivendor environment when the catastrophic failure of the > network substrate is the consequence of a software bug > 5) If these keys (md5) are in use, they=E2=80=99re not rotated because we= got that > support much later than the ability to set/rotate them and coordination > with a network partner to rotate them is feasible but reaches operational > impossibility. > 6) We need protection from tampering with the transport, not encryption o= f > the transport. You will know where the routes go because I assume you=E2= =80=99ve > used a tool like traceroute before. > I think most of these points are reasonable (I'd quibble about #3) but they're not very actionable. If you're position is that TCP-MD5 is all you need (and maybe not even that) then OK. If what you want is some protocol with other, different, functions, then you're going to need to be a lot clearer about what it is you *do* want, not just what you *don't* want. -Ekr --00000000000074223c057c74e5da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Dec 7, 2018 at 12:46 PM Jared Mauch <jared@puck.nether.net> wrote:


> On Dec 7, 2018, at 12:10 AM, Christopher Morrow <morrowc.lists@gmail.com> = wrote:
>
>
>
> On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> routing area (key agility, a stronger algorithm than MD5). And of cour= se TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate= on what you're referring to here?
>
>
> "TCP-AO is a lie, there is zero deployable code anywhere that sup= ports it"
>
> was that the gist of his comment?
> it'd be the whole of mine... because honestly it's the truth. =

I had written out a series of concerns around the requirements operators ha= ve.. I can=E2=80=99t find the paper around my office right now I wrote them= on, but the went roughly like this:

1) We have long-lived TCP sessions, measured in years.=C2=A0 (Implied: many= of the transport people really prefer stable routes without flapping/jitte= r/reordering from us)
2) We use protocols that are stable as a result as transports
3) Security area does review and says =E2=80=9Cwhy is MD5 still a thing=E2= =80=9D without considering #2 and #1 above
4) When doing routing things like an iBGP mesh, key rotation can be complex= in a multivendor environment when the catastrophic failure of the network = substrate is the consequence of a software bug
5) If these keys (md5) are in use, they=E2=80=99re not rotated because we g= ot that support much later than the ability to set/rotate them and coordina= tion with a network partner to rotate them is feasible but reaches operatio= nal impossibility.
6) We need protection from tampering with the transport, not encryption of = the transport.=C2=A0 You will know where the routes go because I assume you= =E2=80=99ve used a tool like traceroute before.

I think most of these points are reasonable (I'd quibble about= #3) but they're not very actionable.

If you&#= 39;re position is that TCP-MD5 is all you need (and maybe not even that) th= en OK.

If what you want is some protocol with othe= r, different, functions, then you're going to need to be a lot clearer = about what it is you *do* want, not just what you *don't* want.

-Ekr



--00000000000074223c057c74e5da-- From nobody Fri Dec 7 13:10:59 2018 Return-Path: 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 1B714130FE9; Fri, 7 Dec 2018 13:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Uh0RC_EWmcFD; Fri, 7 Dec 2018 13:10:50 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51377129AB8; Fri, 7 Dec 2018 13:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hWrrpc4R7DptzRmY/LdRWOYjR7oTUMEGuBwDrxeAH58=; b=UvkKZwiBcGYXWNgrbyvbShapK u6e8vJ6s9hlGIV8N0OgnXKkZwM1XbhTBSEMThXKJUtT60ShbCmeYDpMoQHj2uvG3f1TvUpHT+PSzl FyxmfCUUDrULPEVu6tkuBCHXnZ/l2gTPokZ/JudiAAIHvlo72ejygaFJZCmGqYDWDIj29SR0uSDN8 5rWRfYhQXW5mnesfYu/BGND6HY7vq/OoaFeBWC0OzY3AnyKMf1JzRMH83s53g236KLBwNf80b0AXN U9ZW5r/J4G0EBp0nDy3PQR1KLT83NaaEw9gLTvb6Q+rK1RJdyjaUYPXeKenejIp8kNmopw3Mp8x/m E78hML4bw==; Received: from [204.140.240.55] (port=54372 helo=[172.26.51.121]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gVNOY-000gHQ-Tr; Fri, 07 Dec 2018 16:10:47 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Fri, 7 Dec 2018 13:10:33 -0800 Cc: jared@puck.nether.net, IETF discussion list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec@ietf.org, tsv-art@ietf.org, gert@space.net Content-Transfer-Encoding: quoted-printable Message-Id: <98B6E369-3F10-4755-BD57-8F12C1F865C1@strayalpha.com> References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> To: Eric Rescorla X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 21:10:52 -0000 > On Dec 6, 2018, at 2:40 PM, Eric Rescorla wrote: > ... > And of course TCP-AO doesn't attempt to provide privacy. It can, by changing the association parameters and packet processing algorit= hm, without changing the rest or the protocol.=20 See draft-touch-tcp-so-encrypt Joe From nobody Fri Dec 7 13:16:55 2018 Return-Path: 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 18DB5130FEC; Fri, 7 Dec 2018 13:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 I4lMw1pV6tu6; Fri, 7 Dec 2018 13:16:34 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCDD129AB8; Fri, 7 Dec 2018 13:16:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id BA6DE6FAB0FD; Fri, 7 Dec 2018 15:16:32 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1GfS8sKzsFW; Fri, 7 Dec 2018 15:16:30 -0600 (CST) Received: from [172.16.1.76] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 10E5A6FAB0ED; Fri, 7 Dec 2018 15:16:30 -0600 (CST) From: "Pete Resnick" To: "Christopher Morrow" Cc: "Joe Touch" , ombudsteam@ietf.org, tsv-ads@ietf.org, ops-ads@ietf.org, tsv-art@ietf.org, "opsec wg mailing list" , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ietf Date: Fri, 07 Dec 2018 15:16:29 -0600 X-Mailer: MailMate (1.12.2r5568) Message-ID: <20B602F2-5D9E-4482-9018-58D38EC98C4B@episteme.net> In-Reply-To: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> <811D965A-149E-4E33-A526-2CFCB7A1882B@strayalpha.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_A4B9BC1D-9C1D-4749-9E45-8D0F77E65FB2_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[2793, 3514], "plain":[2104, 2139], "uuid":"F1A49072-1E89-4EDB-B897-45C0B4D9BB94"}] Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 21:16:37 -0000 --=_MailMate_A4B9BC1D-9C1D-4749-9E45-8D0F77E65FB2_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit With my Ombudsperson-hat firmly on my head: If you do wish to make a report to the Ombudsteam, please do that in private email; Cc'ing a bunch of mailing lists is an inappropriate venue for such a report. That said, it's not clear that this falls under our purview. From the Introduction to RFC 7776: The IETF has general policies for managing disruptive behavior in the context of IETF activities. In particular, [RFC7154] provides a set of guidelines for personal interaction in the IETF, and [RFC2418] and [RFC3934] give guidelines for how to deal with disruptive behavior that occurs in the context of IETF working group face-to-face meetings and on mailing lists. However, there is other problematic behavior that may be more personal and that can occur in the context of IETF activities (meetings, mailing list discussions, or social events) that does not directly disrupt working group progress but nonetheless is unacceptable behavior between IETF Participants. This sort of behavior, described in the IESG Statement "IETF Anti-Harassment Policy" [Policy], is not easily dealt with by our previously existing working group guidelines and procedures. Therefore, this document sets forth procedures to deal with such harassing behavior. These procedures are intended to be used when other IETF policies and procedures do not apply or have been ineffective. Since this is all taking place on public lists, and at least at first glance does not appear to be the kind of "more personal" behavior that RFC 7776 is talking about, it seems like going to the appropriate AD, or WG chair, or IETF list sergeant-at-arms, would be the more obvious first step. But again, first glances are not always accurate, so if you (or anyone) feels that particular behavior has crossed the line into the inter-personal sort (as against simply disruptive), please do not hesitate to drop an email to the Ombudsteam; we're more than happy to discuss it and help resolve it, privately. pr On 6 Dec 2018, at 23:27, Christopher Morrow wrote: > On Thu, Dec 6, 2018 at 9:11 AM Joe Touch wrote: > >> >> >> On Dec 5, 2018, at 10:28 PM, Christopher Morrow >> >> wrote: >> >> >> >> On Thu, Dec 6, 2018 at 12:31 AM Joe Touch >> wrote: >> >>> Additionally, packets don’t emerge from different mole endpoints >>> or are >>> IP processed in any way. The mold acts like a wire, which is fine. >>> That >>> can be done by IP tunnels too. But not routers that converge and >>> diverge >>> packets. >>> >> >> That got mangled by autocorrect. Packets aren’t supposed to be IP >> processed by links. To the extent that MPLS does this, it is broken >> vs the >> Internet arch. Remember that MPLS tries to emulate a router path >> that >> can’t keep up. It can - and does - fail to do so correctly in some >> cases. >> >> > Joe, frankly I'm pretty sad that your behavior here is such as this. > I would like the IETF Ombudsteam to have a chat with you are your > behavior > and your lack of listening to reasoned input from folk who both > implement > and operate networks, equipment and the protocols which make up the > Internet at large. You are not helping your case nor the case of the > protocols in question. > > If the ombudsteam are unable/unwilling to interact here I'd like the > responsible ADs for ops/tsv to have a chat with you about this. > > Again, if HBH headers are meaningless and not needed, then go through > the >>> proper process and remove them from IPv6. If not, stop trying to >>> hobble >>> this protocol to the point where we all realize why nobody wants to >>> use it. >>> >>> >> I think everyone here is actually happy to see v6 progress. >> >> >> As am I - in Standards. It shouldn’t ‘progress’ on ops. >> >> note I'm not trying to be intentionally combative, just attempting to >> say: >> "the best answer for the user here is PROBABLY to just have the core >> ignore >> all the EH business entirely" >> >> >> Again, if they’re not needed, fine. Remove them in Standards. >> >> However, if the role of ops is to decide what standards to ignore, >> then >> perhaps the IESG should reconsider the area’s charter. >> >> Joe >> --=_MailMate_A4B9BC1D-9C1D-4749-9E45-8D0F77E65FB2_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

With my Ombudsperson-hat firmly on my head:

If you do wish to make a report to the Ombudsteam, please= do that in private email; Cc'ing a bunch of mailing lists is an inapprop= riate venue for such a report.

That said, it's not clear that this falls under our purvi= ew. From the Introduction to RFC 7776:

The IETF has gene=
ral policies for managing disruptive behavior in the
context of IETF activities.  In particular, [RFC7154] provides a set
of guidelines for personal interaction in the IETF, and [RFC2418] and
[RFC3934] give guidelines for how to deal with disruptive behavior
that occurs in the context of IETF working group face-to-face
meetings and on mailing lists.

However, there is other problematic behavior that may be more
personal and that can occur in the context of IETF activities
(meetings, mailing list discussions, or social events) that does not
directly disrupt working group progress but nonetheless is
unacceptable behavior between IETF Participants.  This sort of
behavior, described in the IESG Statement "IETF Anti-Harassment
Policy" [Policy], is not easily dealt with by our previously existing
working group guidelines and procedures.  Therefore, this document
sets forth procedures to deal with such harassing behavior.

These procedures are intended to be used when other IETF policies and
procedures do not apply or have been ineffective.

Since this is all taking place on public lists, and at le= ast at first glance does not appear to be the kind of "more personal" beh= avior that RFC 7776 is talking about, it seems like going to the appropri= ate AD, or WG chair, or IETF list sergeant-at-arms, would be the more obv= ious first step. But again, first glances are not always accurate, so if = you (or anyone) feels that particular behavior has crossed the line into = the inter-personal sort (as against simply disruptive), please do not hes= itate to drop an email to the Ombudsteam; we're more than happy to discus= s it and help resolve it, privately.

pr

On 6 Dec 2018, at 23:27, Christopher Morrow wrote:



On Thu= , Dec 6, 2018 at 9:11 AM Joe Touch <touch@strayalpha.com> wrote:

On Dec 5, 2018, at 10:28 PM, Christopher Mor= row <morr= owc.lists@gmail.com> wrote:



On Thu, Dec 6, 2018 at 12:31 AM Joe Touch <touch@strayalpha.com>= wrote:
Additionally, packets= don=E2=80=99t emerge from different mole endpoints or are IP=C2=A0 proce= ssed in any way. The mold acts like a wire, which is fine. That can be do= ne by IP tunnels too. But not routers that converge and diverge packets. =

That = got mangled by autocorrect.=C2=A0 Packets aren=E2=80=99t supposed to be I= P processed by links. To the extent that MPLS does this, it is broken vs = the Internet arch.=C2=A0 Remember that MPLS tries to emulate a router pat= h that can=E2=80=99t keep up.=C2=A0 It can - and does - fail to do so cor= rectly in some cases.


Joe= , frankly I'm pretty sad that your behavior here is such as this.
I would like the IETF Ombudsteam to have a=C2=A0 chat with you are= your behavior and your lack of listening to reasoned input from folk who= both implement and operate networks, equipment and the protocols which m= ake up the Internet at large. You are not helping your case nor the case = of the protocols in question.
=C2=A0
If the ombudstea= m are unable/unwilling to interact here I'd like the responsible ADs = for ops/tsv to have a chat with you about this.

<= div dir=3D"ltr">
Again, if HBH headers are meaningless and not needed, then go through the= proper process and remove them from IPv6. If not, stop trying to hobble = this protocol to the point where we all realize why nobody wants to use i= t.


I think everyone here is actu= ally happy to see v6 progress.
<= br>
As am I - in Standards.=C2=A0 It shouldn=E2=80=99t =E2=80=98prog= ress=E2=80=99 on ops.

=
note I'm not trying = to be intentionally combative, just attempting to say: "the best ans= wer for the user here is PROBABLY to just have the core ignore all the EH= business entirely"=C2=A0

Again, if they=E2=80=99re not needed, f= ine. Remove them in Standards.

However, if the r= ole of ops is to decide what standards to ignore, then perhaps the IESG s= hould reconsider the area=E2=80=99s charter.

Joe=
--=_MailMate_A4B9BC1D-9C1D-4749-9E45-8D0F77E65FB2_=-- From nobody Fri Dec 7 13:17:35 2018 Return-Path: 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 A8279130FF1; Fri, 7 Dec 2018 13:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, 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 BRVedMteig1U; Fri, 7 Dec 2018 13:17:15 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81ADB131038; Fri, 7 Dec 2018 13:17:15 -0800 (PST) Received: from [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1] (unknown [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 160805406C7; Fri, 7 Dec 2018 16:17:13 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jared Mauch In-Reply-To: Date: Fri, 7 Dec 2018 16:17:12 -0500 Cc: morrowc.lists@gmail.com, IETF discussion list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec@ietf.org, tsv-art@ietf.org, Gert Doering Content-Transfer-Encoding: quoted-printable Message-Id: References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 21:17:24 -0000 > On Dec 7, 2018, at 3:59 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Fri, Dec 7, 2018 at 12:46 PM Jared Mauch = wrote: >=20 >=20 > > On Dec 7, 2018, at 12:10 AM, Christopher Morrow = wrote: > >=20 > >=20 > >=20 > > On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla wrote: > >=20 > > routing area (key agility, a stronger algorithm than MD5). And of = course TCP-AO doesn't attempt to provide privacy. Perhaps you can = elaborate on what you're referring to here? > >=20 > >=20 > > "TCP-AO is a lie, there is zero deployable code anywhere that = supports it" > >=20 > > was that the gist of his comment? > > it'd be the whole of mine... because honestly it's the truth.=20 >=20 > I had written out a series of concerns around the requirements = operators have.. I can=E2=80=99t find the paper around my office right = now I wrote them on, but the went roughly like this: >=20 > 1) We have long-lived TCP sessions, measured in years. (Implied: many = of the transport people really prefer stable routes without = flapping/jitter/reordering from us) > 2) We use protocols that are stable as a result as transports > 3) Security area does review and says =E2=80=9Cwhy is MD5 still a = thing=E2=80=9D without considering #2 and #1 above > 4) When doing routing things like an iBGP mesh, key rotation can be = complex in a multivendor environment when the catastrophic failure of = the network substrate is the consequence of a software bug > 5) If these keys (md5) are in use, they=E2=80=99re not rotated because = we got that support much later than the ability to set/rotate them and = coordination with a network partner to rotate them is feasible but = reaches operational impossibility. > 6) We need protection from tampering with the transport, not = encryption of the transport. You will know where the routes go because = I assume you=E2=80=99ve used a tool like traceroute before. >=20 > I think most of these points are reasonable (I'd quibble about #3) but = they're not very actionable. >=20 > If you're position is that TCP-MD5 is all you need (and maybe not even = that) then OK. It has problems, I=E2=80=99d like something =E2=80=9Cbetter=E2=80=9D and = a path to get to that better thing. I just built a Greenfield network = and we used some better methods than my prior employer was able to use. = We often get technology lock-in when we use things for =E2=80=9Csecurity=E2= =80=9D purposes. > If what you want is some protocol with other, different, functions, = then you're going to need to be a lot clearer about what it is you *do* = want, not just what you *don't* want.=20 I=E2=80=99m speaking about the operator challenges we have. I don=E2=80=99= t have a draft that=E2=80=99s getting caught up in sec-dir review = because it still uses TCP-MD5 because there are no TCP-AO or other = implementations, or a migration path to them. What I am is an operator that has experience in running a network, = trying to be minimalist in my responses to the badness, and keep it up = so the higher protocols can do their thing. When it gets problematic is = when I can=E2=80=99t differentiate something good from something bad as = easily and people decide to shift that line. I=E2=80=99m warning you = where the guard rails are, they may get moved. This entire draft I see in the subject/cc line is part of that, here=E2=80= =99s what operators are doing. EH=E2=80=99s are a cool idea, but they = are also a security risk in that they may end up in the punt path or = significantly impact performance of the forwarding plane in a way that = could cause the networking substrate to cease to function as desired. = These are things operators will work hard to protect to ensure it=E2=80=99= s working. The network has limits and just because it works in some = hardware doesn=E2=80=99t mean it will work in it all. We are stuck today in many cases with whatever we get in a BCM Chipset = and that doesn=E2=80=99t appear to be changing (although I hope it does = change, and there continue to be options in the market). There are many protocols that need to be cleaned up, just like most = people stopped running chargen on their routers after it was used as an = attack vector. The same was done with changing the defaults around = =E2=80=9Cip directed-broadcast=E2=80=9D behavior. Expecting = intermediate network elements to honor requests in EH=E2=80=99s is not = likely to change. - Jared From nobody Fri Dec 7 13:22:50 2018 Return-Path: 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 CEA35130FEE; Fri, 7 Dec 2018 13:22:41 -0800 (PST) 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 3LQ-vp4UgBIr; Fri, 7 Dec 2018 13:22:40 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445CB130FEB; Fri, 7 Dec 2018 13:22:40 -0800 (PST) Received: from [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1] (unknown [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 4D5975408BB; Fri, 7 Dec 2018 16:22:38 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jared Mauch In-Reply-To: <98B6E369-3F10-4755-BD57-8F12C1F865C1@strayalpha.com> Date: Fri, 7 Dec 2018 16:22:37 -0500 Cc: Eric Rescorla , IETF discussion list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec@ietf.org, tsv-art@ietf.org, gert@space.net Content-Transfer-Encoding: quoted-printable Message-Id: <60D4C2CA-C6D8-46CB-908E-8446107304EF@puck.nether.net> References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> <98B6E369-3F10-4755-BD57-8F12C1F865C1@strayalpha.com> To: Joe Touch X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 21:22:42 -0000 > On Dec 7, 2018, at 4:10 PM, Joe Touch wrote: >=20 >=20 >=20 >> On Dec 6, 2018, at 2:40 PM, Eric Rescorla wrote: >> ... >> And of course TCP-AO doesn't attempt to provide privacy. This is why routing folks were sent in that direction.. > It can, by changing the association parameters and packet processing = algorithm, without changing the rest or the protocol.=20 >=20 > See draft-touch-tcp-so-encrypt Sure, the issue still is we need running code for TCP-AO and it=E2=80=99s = not yet available. - jared From nobody Fri Dec 7 13:29:29 2018 Return-Path: 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 B1237130FF2; Fri, 7 Dec 2018 13:29:27 -0800 (PST) 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 Yv08BazSEjYl; Fri, 7 Dec 2018 13:29:26 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276B0130FEE; Fri, 7 Dec 2018 13:29:26 -0800 (PST) Received: from [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1] (unknown [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 1B7555406C7; Fri, 7 Dec 2018 16:29:23 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jared Mauch In-Reply-To: Date: Fri, 7 Dec 2018 16:29:22 -0500 Cc: Ole Troan , tsv-art , opsec wg mailing list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ietf Content-Transfer-Encoding: quoted-printable Message-Id: References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a 43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> <19869497-A363-460F-9348-B40141F7600E@employees.org> <2A867D05-8DF5-496F-974D-EBA509E2BFA8@employees.org> To: Joe Touch X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 21:29:28 -0000 > On Dec 6, 2018, at 10:35 AM, Joe Touch wrote: >=20 > OK, all, >=20 > So let's try it this way: >=20 > - standards people on this list claim that 8200 already allows = silently > ignoring HBH options >=20 > - ops people on this list claim that most routers already do this >=20 > So if you accept the items above, then why exactly is this document > needed at all? The standards already support it and operators already = do it. >=20 > It clearly isn't needed, just as clearly as it isn't driven by = security > issues. I think many of us have PTSD from trying to talk about reasonable = defaults and the failure to explicitly state why some of these things = are bad and deprecating them continues to burn us to this day. = (Unrelated but perhaps relevant is some of us can=E2=80=99t get our = vendors to clean up the garbage they sold us or our = customers/peers/partners so we are bearing these costs on a daily = basis). > So I would conclude that whether we agree on the logical path, we have > come to the same conclusion - drop this doc and move on. I=E2=80=99ll let someone else decide that, chairs/ADs etc. I think the = question of additional work of eliminating these things so vendors = don=E2=80=99t feel the need to implement them is fair work. - jared= From nobody Fri Dec 7 14:30:53 2018 Return-Path: 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 AFFD2130EDA; Fri, 7 Dec 2018 14:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 u9MegHhaOwWG; Fri, 7 Dec 2018 14:30:43 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F69130ED7; Fri, 7 Dec 2018 14:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WOyIBtpVb5cBvvsPap7QyvWVK1NQ0Z3nfWNGBKqXcrw=; b=0oVeNPowfFeXvaIRoIKhSOG8X B97YpbLMF7yK1kLbnUf+thgC1ooUmdMjdtLCWIfiGNt1+Kux0ZKwegDP4b4nHEdN1lpkS3w5mJlm2 cA8XTj9B9pYNKr99kb4WB7z/KBPWJt7gdjhhPI6UZu6i7KT8s1k55ygx8Bj/HXcuOG5o0gofcpcGa 7TMmQHTxEPIo9xvPtiuTyiIB31Ee5XF05Ghv7hgdZi8vVT0h+m3sryRunAxJwAu/CMMpV7grDESrT ttw3tN/uC/N2JabsS1M8vnYuwef/amFrN0Qg4JzGT427owo6piAoMYZnnSSzbRr9kiS20eaOD1zQk aAxQ4ESbw==; Received: from [204.140.240.55] (port=54391 helo=[172.26.51.121]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gVOdt-001oJJ-IF; Fri, 07 Dec 2018 17:30:42 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16B92) In-Reply-To: <60D4C2CA-C6D8-46CB-908E-8446107304EF@puck.nether.net> Date: Fri, 7 Dec 2018 14:30:36 -0800 Cc: Eric Rescorla , IETF discussion list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec@ietf.org, tsv-art@ietf.org, gert@space.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> <98B6E369-3F10-4755-BD57-8F12C1F865C1@strayalpha.com> <60D4C2CA-C6D8-46CB-908E-8446107304EF@puck.nether.net> To: Jared Mauch X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 22:30:45 -0000 >>=20 >> See draft-touch-tcp-so-encrypt >=20 > Sure, the issue still is we need running code for TCP-AO and it=E2=80=99s n= ot yet available. Not free. Nobody wanted to pay for one.=20 Joe= From nobody Fri Dec 7 14:45:06 2018 Return-Path: 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 B0A21130E57; Fri, 7 Dec 2018 14:44:56 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 a0XK8PeTBhqD; Fri, 7 Dec 2018 14:44:55 -0800 (PST) Received: from bonobo.maple.relay.mailchannels.net (bonobo.maple.relay.mailchannels.net [23.83.214.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5DC12D4E7; Fri, 7 Dec 2018 14:44:54 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 35FEB283D02; Fri, 7 Dec 2018 22:44:53 +0000 (UTC) Received: from pdx1-sub0-mail-a35.g.dreamhost.com (unknown [100.96.26.166]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D198C283EA0; Fri, 7 Dec 2018 22:44:52 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a35.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Fri, 07 Dec 2018 22:44:53 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Company-Invention: 102a3f5046f2f2f8_1544222693045_1258654301 X-MC-Loop-Signature: 1544222693045:4187109232 X-MC-Ingress-Time: 1544222693045 Received: from pdx1-sub0-mail-a35.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTP id 7C08B7F5D3; Fri, 7 Dec 2018 14:44:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=MNjGNONkhowHRH ABnP/yVQIJSgE=; b=Ny6Z6UgCfZxe+DJ1iO6tszHiucpj7iWtFg31xdbnUxxaP7 4R8wjsa+bVPY3IL6MMoPIeru7MdtoMbRRHCelkoDMugvQDP8CfK84PG/+8mwSRwA 9fJ87BiPBmT8BGLsCRdj6gjWobiSxG7OZlGop0Sly1MGVuWEft0WWBDHJq89U= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTPSA id D99D47F5D5; Fri, 7 Dec 2018 14:44:48 -0800 (PST) Date: Fri, 7 Dec 2018 16:44:46 -0600 X-DH-BACKEND: pdx1-sub0-mail-a35 From: Nico Williams To: Jared Mauch Cc: Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec wg mailing list , tsv-art@ietf.org, Gert Doering Message-ID: <20181207224445.GZ15561@localhost> References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudegtddgtdegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 22:44:57 -0000 On Fri, Dec 07, 2018 at 03:46:15PM -0500, Jared Mauch wrote: > 1) We have long-lived TCP sessions, measured in years. (Implied: many > of the transport people really prefer stable routes without > flapping/jitter/reordering from us) I've long wondered why BGP has to be this way and why it still is after so many years. From nobody Fri Dec 7 14:49:02 2018 Return-Path: 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 7CBEA130E54; Fri, 7 Dec 2018 14:48:44 -0800 (PST) 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 F9ytXhv1QQsx; Fri, 7 Dec 2018 14:48:42 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A38EB12D4E7; Fri, 7 Dec 2018 14:48:42 -0800 (PST) Received: from [IPv6:2603:3015:3606:cbe1:2cd2:3c7:ffbc:973] (unknown [IPv6:2603:3015:3606:cbe1:2cd2:3c7:ffbc:973]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id B154C5406DA; Fri, 7 Dec 2018 17:48:40 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jared Mauch In-Reply-To: <20181207224445.GZ15561@localhost> Date: Fri, 7 Dec 2018 17:48:40 -0500 Cc: Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec wg mailing list , tsv-art@ietf.org, Gert Doering Content-Transfer-Encoding: quoted-printable Message-Id: References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> <20181207224445.GZ15561@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [OPSEC] OT: TCP session lifetime - Re: [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 22:48:45 -0000 > On Dec 7, 2018, at 5:44 PM, Nico Williams = wrote: >=20 > On Fri, Dec 07, 2018 at 03:46:15PM -0500, Jared Mauch wrote: >> 1) We have long-lived TCP sessions, measured in years. (Implied: = many >> of the transport people really prefer stable routes without >> flapping/jitter/reordering from us) >=20 > > I've long wondered why BGP has to be this way and why it still is = after > so many years. > I have seen BGP sessions up for over 7 years on some routers. One can = argue if this is a good thing or bad. It=E2=80=99s quite an interesting = thing to see and go =E2=80=9Cwow, someone forgot about this one =E2=80=A6=E2= =80=9D - jared=20 From nobody Fri Dec 7 15:03:23 2018 Return-Path: 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 57151130E1D; Fri, 7 Dec 2018 15:03:13 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 FrvC1Xy2-6gT; Fri, 7 Dec 2018 15:03:12 -0800 (PST) Received: from insect.birch.relay.mailchannels.net (insect.birch.relay.mailchannels.net [23.83.209.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5262812D4E7; Fri, 7 Dec 2018 15:03:10 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id F0545124B2F; Fri, 7 Dec 2018 23:03:09 +0000 (UTC) Received: from pdx1-sub0-mail-a35.g.dreamhost.com (unknown [100.96.33.121]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 83947123E56; Fri, 7 Dec 2018 23:03:09 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a35.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Fri, 07 Dec 2018 23:03:09 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Continue-Reaction: 45a3932519b1179f_1544223789792_3756335959 X-MC-Loop-Signature: 1544223789792:4200155336 X-MC-Ingress-Time: 1544223789791 Received: from pdx1-sub0-mail-a35.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTP id 42BF77F5D5; Fri, 7 Dec 2018 15:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=faa39iOIIZTnpjNG5mx+wAWQySE=; b=s06kFSNnbcm 0gKAZzf6sTQK9SQ7LhzaaSU3hEVS8lbGSNm7m2yH+CjSkXoufP29pfS6pjbOzT9S nWYK4OmmSM3hhxzJTOUUICPTINXIvLr/hZ877cfEGYhXwqHZwzJ8xD+1GPGWeo+M nFhPZ1zJyizeD4CF+C/jUvMm1Y0acueM= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 593887F5D3; Fri, 7 Dec 2018 15:03:05 -0800 (PST) Date: Fri, 7 Dec 2018 17:03:03 -0600 X-DH-BACKEND: pdx1-sub0-mail-a35 From: Nico Williams To: Jared Mauch Cc: Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec wg mailing list , tsv-art@ietf.org, Gert Doering Message-ID: <20181207230302.GA15561@localhost> References: <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> <20181207224445.GZ15561@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudegtddgtdekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSEC] OT: TCP session lifetime - Re: [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 23:03:13 -0000 On Fri, Dec 07, 2018 at 05:48:40PM -0500, Jared Mauch wrote: > > On Dec 7, 2018, at 5:44 PM, Nico Williams wro= te: > > On Fri, Dec 07, 2018 at 03:46:15PM -0500, Jared Mauch wrote: > >> 1) We have long-lived TCP sessions, measured in years. (Implied: ma= ny > >> of the transport people really prefer stable routes without > >> flapping/jitter/reordering from us) > >=20 > > > > I've long wondered why BGP has to be this way and why it still is aft= er > > so many years. > > >=20 > I have seen BGP sessions up for over 7 years on some routers. One can > argue if this is a good thing or bad. It=E2=80=99s quite an interestin= g thing > to see and go =E2=80=9Cwow, someone forgot about this one =E2=80=A6=E2=80= =9D What I meant is that I don't understand why resetting a connection should still cause routes to flap. Instead I'd expect session management negotiation to determine whether the thing that failed (e.g., a BGP daemon) implies that the routes are gone or not. Then RST injection would not be a problem. You'd still need integrity protection, but then that could always have been done with TLS. Basically, it feels like BGP is stuck in the stone age. I'm not asking the routing area to fix it. I'm not saying that we should not cater to their needs. My point truly was rhetorical. I do hope the routing area does improve session management in BGP some day. Nico --=20 From nobody Fri Dec 7 21:50:03 2018 Return-Path: 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 F3825131117 for ; Fri, 7 Dec 2018 21:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 VEf4E99ty1WD for ; Fri, 7 Dec 2018 21:49:57 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 038001310FE for ; Fri, 7 Dec 2018 21:49:57 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id u6-v6so5340671ljd.1 for ; Fri, 07 Dec 2018 21:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1lRroBboWIhZL52lUvt/gbQSoqZlLlVXHvAgKenCR8U=; b=uwMBdQR+XY/o2rWSjvN3iL5L8HKt67djPSrzrwunCZVFtMexD9ixpoRRGTazpThADg iG3B70AGqTMA1TBZhX+yIiCFbjZ6U9D7lobFYLFdudo+up0yC+Zjn/TiSo2EZ38hebE/ eTkBCRFMPRofQdOcN4a31gmSDPrR2/1TJOezCV9MEjCkb8OoLu1/+37U16yBxw4l/yN6 /gSpGXui6uHGWKgo+KZbHPTudgzv2bd2PUfxmPZliIEqTU6Xi58QPKjtMP53gQh6SViU xsrZD2kkP6NzsvG7G6/zSx4dHPj3DCRSBxRpisSlrTfHZFdgew99NO+/0YORaLIo5Tmw WBSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1lRroBboWIhZL52lUvt/gbQSoqZlLlVXHvAgKenCR8U=; b=rTIFVoc5VOiRrIhgXkAyXY/GfJOJIXonmXlgs8syl5EE0BVcKtpQxtWNQU9NFCCgTg s0c/ULa+tBz2Dn8wq2QXC7DeMFvRapF6E53t1kXpL8KHHWSx05jThBZUQ+HuiJp5faTm oTLiNuZr9wxkq3lUqoPSsjBVdRs2t4LkfVEyg9C6bq1mM46qjrQ1PVokQAFTquVSBq63 VyTcVW62YmrdM6xBZW354zR0KJ0b6o+BgCatrnG8JtNbsAP0YKFHvWJLlMquyGwPyYIz wqfbI+ckoRSDB/7qk6NT/639Qpx2LyNaTwL4QBQjjaocu0qzfCiDC76XAo4zE+YmbCt5 B/WQ== X-Gm-Message-State: AA+aEWb09z9MrdOELISHNRifaAQIWK3H7SNGG0BpkBnJf1yMpyAjOetu OwS2vn19DRxPsQdeY1tMWbOOsoOkb7k1zTJxDxL/+w== X-Google-Smtp-Source: AFSGD/XwRYhPzUreEyffD8r4WltYKapPNh4bhQDMAizWR2tvTHYoL/YIoRyWbvxbnv+XKuLdEauKcrG6ltJFYtrELa0= X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr3060863ljb.51.1544248195141; Fri, 07 Dec 2018 21:49:55 -0800 (PST) MIME-Version: 1.0 References: <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> In-Reply-To: From: Eric Rescorla Date: Fri, 7 Dec 2018 21:49:15 -0800 Message-ID: To: Jared Mauch Cc: morrowc.lists@gmail.com, IETF discussion list , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec@ietf.org, tsv-art@ietf.org, Gert Doering Content-Type: multipart/alternative; boundary="0000000000001df7f0057c7c4d96" Archived-At: Subject: Re: [OPSEC] [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2018 05:50:01 -0000 --0000000000001df7f0057c7c4d96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 7, 2018 at 1:17 PM Jared Mauch wrote: > > > > On Dec 7, 2018, at 3:59 PM, Eric Rescorla wrote: > > > > > > > > On Fri, Dec 7, 2018 at 12:46 PM Jared Mauch > wrote: > > > > > > > On Dec 7, 2018, at 12:10 AM, Christopher Morrow < > morrowc.lists@gmail.com> wrote: > > > > > > > > > > > > On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla wrote: > > > > > > routing area (key agility, a stronger algorithm than MD5). And of > course TCP-AO doesn't attempt to provide privacy. Perhaps you can elabora= te > on what you're referring to here? > > > > > > > > > "TCP-AO is a lie, there is zero deployable code anywhere that support= s > it" > > > > > > was that the gist of his comment? > > > it'd be the whole of mine... because honestly it's the truth. > > > > I had written out a series of concerns around the requirements operator= s > have.. I can=E2=80=99t find the paper around my office right now I wrote = them on, > but the went roughly like this: > > > > 1) We have long-lived TCP sessions, measured in years. (Implied: many > of the transport people really prefer stable routes without > flapping/jitter/reordering from us) > > 2) We use protocols that are stable as a result as transports > > 3) Security area does review and says =E2=80=9Cwhy is MD5 still a thing= =E2=80=9D without > considering #2 and #1 above > > 4) When doing routing things like an iBGP mesh, key rotation can be > complex in a multivendor environment when the catastrophic failure of the > network substrate is the consequence of a software bug > > 5) If these keys (md5) are in use, they=E2=80=99re not rotated because = we got > that support much later than the ability to set/rotate them and > coordination with a network partner to rotate them is feasible but reache= s > operational impossibility. > > 6) We need protection from tampering with the transport, not encryption > of the transport. You will know where the routes go because I assume > you=E2=80=99ve used a tool like traceroute before. > > > > I think most of these points are reasonable (I'd quibble about #3) but > they're not very actionable. > > > > If you're position is that TCP-MD5 is all you need (and maybe not even > that) then OK. > > It has problems, I=E2=80=99d like something =E2=80=9Cbetter=E2=80=9D and = a path to get to that > better thing. I just built a Greenfield network and we used some better > methods than my prior employer was able to use. We often get technology > lock-in when we use things for =E2=80=9Csecurity=E2=80=9D purposes. > > > If what you want is some protocol with other, different, functions, the= n > you're going to need to be a lot clearer about what it is you *do* want, > not just what you *don't* want. > > I=E2=80=99m speaking about the operator challenges we have. I don=E2=80= =99t have a draft > that=E2=80=99s getting caught up in sec-dir review because it still uses = TCP-MD5 > because there are no TCP-AO or other implementations, or a migration path > to them. > Well, drafts don't get stuck in sec-dir review, because those reviews are non-blocking. And I'm pretty sure that neither Ben or I are holding discusses on any such drafts. If so, can you list them, please? > What I am is an operator that has experience in running a network, trying > to be minimalist in my responses to the badness, and keep it up so the > higher protocols can do their thing. When it gets problematic is when I > can=E2=80=99t differentiate something good from something bad as easily a= nd people > decide to shift that line. I=E2=80=99m warning you where the guard rails= are, they > may get moved. > > This entire draft I see in the subject/cc line is part of that, here=E2= =80=99s > what operators are doing. EH=E2=80=99s are a cool idea, but they are als= o a > security risk in that they may end up in the punt path or significantly > impact performance of the forwarding plane in a way that could cause the > networking substrate to cease to function as desired. These are things > operators will work hard to protect to ensure it=E2=80=99s working. The = network > has limits and just because it works in some hardware doesn=E2=80=99t mea= n it will > work in it all. > I have no position on IPv6 EHs. -Ekr > We are stuck today in many cases with whatever we get in a BCM Chipset an= d > that doesn=E2=80=99t appear to be changing (although I hope it does chang= e, and > there continue to be options in the market). > > There are many protocols that need to be cleaned up, just like most peopl= e > stopped running chargen on their routers after it was used as an attack > vector. The same was done with changing the defaults around =E2=80=9Cip > directed-broadcast=E2=80=9D behavior. Expecting intermediate network ele= ments to > honor requests in EH=E2=80=99s is not likely to change. > > - Jared > > > > --0000000000001df7f0057c7c4d96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Dec 7, 2018 at 1:17 PM Jared Mauch <jared@puck.nether.net> wrote:


> On Dec 7, 2018, at 3:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Fri, Dec 7, 2018 at 12:46 PM Jared Mauch <jared@puck.nether.net> wrote: >
>
> > On Dec 7, 2018, at 12:10 AM, Christopher Morrow <morrowc.lists@gmail.com= > wrote:
> >
> >
> >
> > On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > routing area (key agility, a stronger algorithm than MD5). And of= course TCP-AO doesn't attempt to provide privacy. Perhaps you can elab= orate on what you're referring to here?
> >
> >
> > "TCP-AO is a lie, there is zero deployable code anywhere tha= t supports it"
> >
> > was that the gist of his comment?
> > it'd be the whole of mine... because honestly it's the tr= uth.
>
> I had written out a series of concerns around the requirements operato= rs have.. I can=E2=80=99t find the paper around my office right now I wrote= them on, but the went roughly like this:
>
> 1) We have long-lived TCP sessions, measured in years.=C2=A0 (Implied:= many of the transport people really prefer stable routes without flapping/= jitter/reordering from us)
> 2) We use protocols that are stable as a result as transports
> 3) Security area does review and says =E2=80=9Cwhy is MD5 still a thin= g=E2=80=9D without considering #2 and #1 above
> 4) When doing routing things like an iBGP mesh, key rotation can be co= mplex in a multivendor environment when the catastrophic failure of the net= work substrate is the consequence of a software bug
> 5) If these keys (md5) are in use, they=E2=80=99re not rotated because= we got that support much later than the ability to set/rotate them and coo= rdination with a network partner to rotate them is feasible but reaches ope= rational impossibility.
> 6) We need protection from tampering with the transport, not encryptio= n of the transport.=C2=A0 You will know where the routes go because I assum= e you=E2=80=99ve used a tool like traceroute before.
>
> I think most of these points are reasonable (I'd quibble about #3)= but they're not very actionable.
>
> If you're position is that TCP-MD5 is all you need (and maybe not = even that) then OK.

It has problems, I=E2=80=99d like something =E2=80=9Cbetter=E2=80=9D and a = path to get to that better thing.=C2=A0 I just built a Greenfield network a= nd we used some better methods than my prior employer was able to use.=C2= =A0 We often get technology lock-in when we use things for =E2=80=9Csecurit= y=E2=80=9D purposes.

> If what you want is some protocol with other, different, functions, th= en you're going to need to be a lot clearer about what it is you *do* w= ant, not just what you *don't* want.

I=E2=80=99m speaking about the operator challenges we have.=C2=A0 I don=E2= =80=99t have a draft that=E2=80=99s getting caught up in sec-dir review bec= ause it still uses TCP-MD5 because there are no TCP-AO or other implementat= ions, or a migration path to them.

Well= , drafts don't get stuck in sec-dir review, because those reviews are n= on-blocking. And I'm pretty sure that neither Ben or I are holding disc= usses on any such drafts. If so, can you list them, please?
<= br>
=C2=A0
What I am is an operator that has experience in running a network, trying t= o be minimalist in my responses to the badness, and keep it up so the highe= r protocols can do their thing.=C2=A0 When it gets problematic is when I ca= n=E2=80=99t differentiate something good from something bad as easily and p= eople decide to shift that line.=C2=A0 I=E2=80=99m warning you where the gu= ard rails are, they may get moved.

This entire draft I see in the subject/cc line is part of that, here=E2=80= =99s what operators are doing.=C2=A0 EH=E2=80=99s are a cool idea, but they= are also a security risk in that they may end up in the punt path or signi= ficantly impact performance of the forwarding plane in a way that could cau= se the networking substrate to cease to function as desired.=C2=A0 These ar= e things operators will work hard to protect to ensure it=E2=80=99s working= .=C2=A0 The network has limits and just because it works in some hardware d= oesn=E2=80=99t mean it will work in it all.

=
I have no position on IPv6 EHs.

-Ekr


We are stuck today in many cases with whatever we get in a BCM Chipset and = that doesn=E2=80=99t appear to be changing (although I hope it does change,= and there continue to be options in the market).

There are many protocols that need to be cleaned up, just like most people = stopped running chargen on their routers after it was used as an attack vec= tor.=C2=A0 The same was done with changing the defaults around =E2=80=9Cip = directed-broadcast=E2=80=9D behavior.=C2=A0 Expecting intermediate network = elements to honor requests in EH=E2=80=99s is not likely to change.

- Jared



--0000000000001df7f0057c7c4d96-- From nobody Sat Dec 8 01:26:14 2018 Return-Path: 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 B49391294D7 for ; Sat, 8 Dec 2018 01:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 tMFd1Wwo8hdn for ; Sat, 8 Dec 2018 01:25:58 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B65313111A for ; Sat, 8 Dec 2018 01:25:55 -0800 (PST) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 98E1B41C40 for ; Sat, 8 Dec 2018 10:25:53 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 7EC1E41B3A; Sat, 8 Dec 2018 10:25:53 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 6D9571F7A8; Sat, 8 Dec 2018 10:25:53 +0100 (CET) Date: Sat, 8 Dec 2018 10:25:53 +0100 From: Gert Doering To: Nico Williams Cc: Jared Mauch , Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec wg mailing list , tsv-art@ietf.org, Gert Doering Message-ID: <20181208092553.GZ1543@Space.Net> References: <20181206125726.GG1543@Space.Net> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> <20181207224445.GZ15561@localhost> <20181207230302.GA15561@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="COt1KesysQ0dNK/h" Content-Disposition: inline In-Reply-To: <20181207230302.GA15561@localhost> X-NCC-RegID: de.space User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [OPSEC] OT: TCP session lifetime - Re: [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2018 09:26:00 -0000 --COt1KesysQ0dNK/h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Dec 07, 2018 at 05:03:03PM -0600, Nico Williams wrote: > What I meant is that I don't understand why resetting a connection > should still cause routes to flap. Instead I'd expect session > management negotiation to determine whether the thing that failed (e.g., > a BGP daemon) implies that the routes are gone or not. Then RST > injection would not be a problem. You'd still need integrity > protection, but then that could always have been done with TLS. We do have BGP graceful restart. Which just causes a bit of CPU load on both ends while they walk multiple millions of VPNv4 routes to reestablish common state. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --COt1KesysQ0dNK/h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlwLjh4ACgkQ31bAZeTO f8X7uA/+Pi/2aCcR13cKuECIxzanFag6GGBZA8Nl9Q8cRERPJuJE4saOmMNGyKua RKGttTTLSb70efxFxkZth1c4x/TeW+cz5ETv2BhvpamFTKaIesYP6C6YpI7PSn6k xJnBxDdJhNyzOSKENalSJhWxIoOXeTU1kmGYY2jl0qMgaRwc3bFKoHBboLQIfNE3 wMJZd7Jbwj9juBcEYOKe42tWcNBZcTRkOUctQvXP3l1P/Pwq9fWZcCvB8QJiKPhQ A8/3MpZ3Gebnx8/Hpc6Tyayo/i08ODtB3shPm4SSbrCv/JCByR4kT71qR5bqdstZ B3uIiFaIbtyBR1D9Tc8Of9Pr99Q/GrtNUfubDI3Vf2vmMhOEhYjW8xldFIvnJv4a U5M+Cx0IDcfsFgmN6wIRQ0AigFUZLZMwvGGT5PBV7Sw0rbhLuuThq0ArxmY5tNcv IIaPxv4V2eaYk52+b93wBxD5JmRF8kyQHXA9+1cb0z7Bt+JJViLK/UTJ2bZfc7/T qRS50LHjcpAZln9GKmGpGSAY654xc2hwON9xwdEq1KlRq8d3UXjTEbXrunpxUTFK brvToU5dKURNtbBFt7IUoAJWTO6yPBCcIEocE7NeyFtgb0DaMHp9+6z1TyFW3JE1 OXQSCalGpjRMGdfG8SsR3+v1v06GbyhfCe/lVbhr/BN2ECqjdWc= =r1Xt -----END PGP SIGNATURE----- --COt1KesysQ0dNK/h-- From nobody Sat Dec 8 02:51:59 2018 Return-Path: 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 60A29128766; Sat, 8 Dec 2018 02:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=cBF5jqyh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J2Z1TI54 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 8vgI8Ky5dkAL; Sat, 8 Dec 2018 02:51:45 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151CD127133; Sat, 8 Dec 2018 02:51:44 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0C96421F67; Sat, 8 Dec 2018 05:51:44 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sat, 08 Dec 2018 05:51:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=vo9337wWGmeswEm2ZQpmSZh GhW5sT/nP4ojTNzbcgJk=; b=cBF5jqyhHtMF1JlvO7OZ5oJQlJuN5ZSq2IZq2iE OYp9XLM3W8ptsOJS3FMtkf+bYsRO/7ZLufaBy6ZT0ubD7wMDtB+/K7rBsgjvTAlN gkxtsnIRIdxlTa9iNPK8/79eiMkZFXTxBXtCNAbjEdQwv1ypE5CFQ6G2y5m6SWOq lC+tXDraPZXcDE0CtcAEOTHcKHowtNJAWoDuXI/IuyVM2mfINOhrOYa3ufeNf8A1 IRvQhar1kH3cVVUvmHwRuy5katQdC7340DbGrcoiV/QMezCt6syc55GAfDiz8HGN LgnHhPIIEKapuKKqOUjRgeAe1SNSTyexNCBCa/gtbZLuvOQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=vo9337 wWGmeswEm2ZQpmSZhGhW5sT/nP4ojTNzbcgJk=; b=J2Z1TI54JnPiIGMAXRIPVH SE76iGrLGtC/JJaFHDckThespw216tw+DAqqsEySYPRe+iG1x4qCMJ25vLalff4F mDqjb1/dikToszTAdVyMlgna38zoNUtmz7gufpyscnCN6La3ZjSJp9A19C7Z9yY3 PhOWt028AdqnaaWBF5oXTs+0RMhPKSGOvphJh+kSMGRD1UK1i5nB1w8IGm9XZ7vu rr19Wz4lEtmK4JejcMDamAfL6JQWMlvKbtLsNRDQ2HxvxxID/W42rSMcCoMT9pD+ N5zPifOu6WrFQLDHuSX5TLqNpY7uVSBcYAqhXiSfYNNsr3bGl0kjDzd53/cf4N0g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudeguddgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhkfgtggfuff gjvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlihhsshgrucevohhophgvrhcuoegr lhhishhsrgestghoohhpvghrfidrihhnqeenucfkphepuddtkedrhedurddutddurdelke enucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 7E99D102A0; Sat, 8 Dec 2018 05:51:42 -0500 (EST) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6AE410EF-E19A-401F-96C9-6357A9300277" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 8 Dec 2018 05:51:41 -0500 In-Reply-To: <20B602F2-5D9E-4482-9018-58D38EC98C4B@episteme.net> Cc: Christopher Morrow , ietf , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ombudsteam@ietf.org, opsec wg mailing list , tsv-ads@ietf.org, tsv-art@ietf.org, ops-ads@ietf.org To: Pete Resnick References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <260f1445-0690-691b-5aea-83b7a43bfdcb@gmail.com> <52009CB5-FAA4-47D6-AC05-C16049758663@strayalpha.com> <811D965A-149E-4E33-A526-2CFCB7A1882B@strayalpha.com> <20B602F2-5D9E-4482-9018-58D38EC98C4B@episteme.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [OPSEC] Engaging constructively [HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2018 10:51:49 -0000 --Apple-Mail=_6AE410EF-E19A-401F-96C9-6357A9300277 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Pete. A few days ago I was about to hit send on a mail reminding people to = keep the discussion in the last call threads about this document = constructive, but then it in fact did seem to be getting more = constructive and some new voices started chiming in. Nevertheless, = perhaps it=E2=80=99s useful for everyone to remember to ask themselves a = few questions before posting further in these threads (or other IETF = threads): - Am I offering an argument that is designed to persuade someone who I = know has a well-established view that is different from mine, or simply = to promote my own view? - Has the point I'd like to make been overtaken by events? - If I=E2=80=99ve already made my point multiple ways, might it be time = to sit back and hear from others? - Can I make my point without being condescending or demeaning? I think at this point in the discussion of this document we might also = be nearing a place where having the responsible AD summarize the = commentary thus far would be useful =E2=80=94 I=E2=80=99ll ping Warren = on that although I know he was traveling earlier in the week. Alissa > On Dec 7, 2018, at 4:16 PM, Pete Resnick wrote: >=20 > With my Ombudsperson-hat firmly on my head: >=20 > If you do wish to make a report to the Ombudsteam, please do that in = private email; Cc'ing a bunch of mailing lists is an inappropriate venue = for such a report. >=20 > That said, it's not clear that this falls under our purview. =46rom = the Introduction to RFC 7776: >=20 > The IETF has general policies for managing disruptive behavior in the > context of IETF activities. In particular, [RFC7154] provides a set > of guidelines for personal interaction in the IETF, and [RFC2418] and > [RFC3934] give guidelines for how to deal with disruptive behavior > that occurs in the context of IETF working group face-to-face > meetings and on mailing lists. >=20 > However, there is other problematic behavior that may be more > personal and that can occur in the context of IETF activities > (meetings, mailing list discussions, or social events) that does not > directly disrupt working group progress but nonetheless is > unacceptable behavior between IETF Participants. This sort of > behavior, described in the IESG Statement "IETF Anti-Harassment > Policy" [Policy], is not easily dealt with by our previously existing > working group guidelines and procedures. Therefore, this document > sets forth procedures to deal with such harassing behavior. >=20 > These procedures are intended to be used when other IETF policies and > procedures do not apply or have been ineffective. > Since this is all taking place on public lists, and at least at first = glance does not appear to be the kind of "more personal" behavior that = RFC 7776 is talking about, it seems like going to the appropriate AD, or = WG chair, or IETF list sergeant-at-arms, would be the more obvious first = step. But again, first glances are not always accurate, so if you (or = anyone) feels that particular behavior has crossed the line into the = inter-personal sort (as against simply disruptive), please do not = hesitate to drop an email to the Ombudsteam; we're more than happy to = discuss it and help resolve it, privately. >=20 > pr >=20 > On 6 Dec 2018, at 23:27, Christopher Morrow wrote: >=20 >=20 >=20 > On Thu, Dec 6, 2018 at 9:11 AM Joe Touch > wrote: >=20 >=20 > On Dec 5, 2018, at 10:28 PM, Christopher Morrow = > wrote: >=20 >>=20 >>=20 >> On Thu, Dec 6, 2018 at 12:31 AM Joe Touch > wrote: >> Additionally, packets don=E2=80=99t emerge from different mole = endpoints or are IP processed in any way. The mold acts like a wire, = which is fine. That can be done by IP tunnels too. But not routers that = converge and diverge packets.=20 >=20 > That got mangled by autocorrect. Packets aren=E2=80=99t supposed to = be IP processed by links. To the extent that MPLS does this, it is = broken vs the Internet arch. Remember that MPLS tries to emulate a = router path that can=E2=80=99t keep up. It can - and does - fail to do = so correctly in some cases. >=20 >=20 > Joe, frankly I'm pretty sad that your behavior here is such as this. > I would like the IETF Ombudsteam to have a chat with you are your = behavior and your lack of listening to reasoned input from folk who both = implement and operate networks, equipment and the protocols which make = up the Internet at large. You are not helping your case nor the case of = the protocols in question. > =20 > If the ombudsteam are unable/unwilling to interact here I'd like the = responsible ADs for ops/tsv to have a chat with you about this. >=20 >> Again, if HBH headers are meaningless and not needed, then go through = the proper process and remove them from IPv6. If not, stop trying to = hobble this protocol to the point where we all realize why nobody wants = to use it.=20 >>=20 >>=20 >> I think everyone here is actually happy to see v6 progress. >=20 > As am I - in Standards. It shouldn=E2=80=99t =E2=80=98progress=E2=80=99= on ops. >=20 >> note I'm not trying to be intentionally combative, just attempting to = say: "the best answer for the user here is PROBABLY to just have the = core ignore all the EH business entirely"=20 >=20 > Again, if they=E2=80=99re not needed, fine. Remove them in Standards. >=20 > However, if the role of ops is to decide what standards to ignore, = then perhaps the IESG should reconsider the area=E2=80=99s charter. >=20 > Joe --Apple-Mail=_6AE410EF-E19A-401F-96C9-6357A9300277 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Pete.

A few days ago I was about to hit send on a mail reminding = people to keep the discussion in the last call threads about this = document constructive, but then it in fact did seem to be getting more = constructive and some new voices started chiming in. Nevertheless, = perhaps it=E2=80=99s useful for everyone to remember to ask themselves a = few questions before posting further in these threads (or other IETF = threads):

- Am I = offering an argument that is designed to persuade someone who I know has = a well-established view that is different from mine, or simply to = promote my own view?
- Has the point I'd like to = make been overtaken by events?
- If I=E2=80=99ve = already made my point multiple ways, might it be time to sit back and = hear from others?
- Can I make my point without = being condescending or demeaning?

I think at this point in the discussion = of this document we might also be nearing a place where having the = responsible AD summarize the commentary thus far would be useful =E2=80=94= I=E2=80=99ll ping Warren on that although I know he was traveling = earlier in the week.

Alissa


On Dec = 7, 2018, at 4:16 PM, Pete Resnick <resnick@episteme.net> wrote:

With = my Ombudsperson-hat firmly on my head:

If = you do wish to make a report to the Ombudsteam, please do that in = private email; Cc'ing a bunch of mailing lists is an inappropriate venue = for such a report.

That said, it's not = clear that this falls under our purview. =46rom the Introduction to RFC = 7776:

The IETF has general policies =
for managing disruptive behavior in the
context of IETF activities.  In particular, [RFC7154] provides a set
of guidelines for personal interaction in the IETF, and [RFC2418] and
[RFC3934] give guidelines for how to deal with disruptive behavior
that occurs in the context of IETF working group face-to-face
meetings and on mailing lists.

However, there is other problematic behavior that may be more
personal and that can occur in the context of IETF activities
(meetings, mailing list discussions, or social events) that does not
directly disrupt working group progress but nonetheless is
unacceptable behavior between IETF Participants.  This sort of
behavior, described in the IESG Statement "IETF Anti-Harassment
Policy" [Policy], is not easily dealt with by our previously existing
working group guidelines and procedures.  Therefore, this document
sets forth procedures to deal with such harassing behavior.

These procedures are intended to be used when other IETF policies and
procedures do not apply or have been ineffective.

Since this is all taking place = on public lists, and at least at first glance does not appear to be the = kind of "more personal" behavior that RFC 7776 is talking about, it = seems like going to the appropriate AD, or WG chair, or IETF list = sergeant-at-arms, would be the more obvious first step. But again, first = glances are not always accurate, so if you (or anyone) feels that = particular behavior has crossed the line into the inter-personal sort = (as against simply disruptive), please do not hesitate to drop an email = to the Ombudsteam; we're more than happy to discuss it and help resolve = it, privately.

pr

On 6 Dec 2018, at 23:27, Christopher Morrow wrote:



On Thu, Dec 6, 2018 at 9:11 AM Joe Touch <touch@strayalpha.com> wrote:


On Dec 5, 2018, at 10:28 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:



On Thu, Dec 6, 2018 at = 12:31 AM Joe Touch <touch@strayalpha.com> wrote:
Additionally, packets = don=E2=80=99t emerge from different mole endpoints or are IP  = processed in any way. The mold acts like a wire, which is fine. That can = be done by IP tunnels too. But not routers that converge and diverge = packets.

That got mangled by = autocorrect.  Packets aren=E2=80=99t supposed to be IP processed by = links. To the extent that MPLS does this, it is broken vs the Internet = arch.  Remember that MPLS tries to emulate a router path that = can=E2=80=99t keep up.  It can - and does - fail to do so correctly = in some cases.


Joe, frankly I'm pretty sad that your = behavior here is such as this.
I would like the = IETF Ombudsteam to have a  chat with you are your behavior and your = lack of listening to reasoned input from folk who both implement and = operate networks, equipment and the protocols which make up the Internet = at large. You are not helping your case nor the case of the protocols in = question.
 
If the = ombudsteam are unable/unwilling to interact here I'd like the = responsible ADs for ops/tsv to have a chat with you about = this.

Again, if HBH headers are meaningless and not needed, then go through = the proper process and remove them from IPv6. If not, stop trying to = hobble this protocol to the point where we all realize why nobody wants = to use it.


I think everyone here is actually happy = to see v6 progress.

As am I - in Standards.  It = shouldn=E2=80=99t =E2=80=98progress=E2=80=99 on ops.

note I'm not trying to be intentionally combative, just = attempting to say: "the best answer for the user here is PROBABLY to = just have the core ignore all the EH business = entirely" 

Again, if = they=E2=80=99re not needed, fine. Remove them in Standards.

However, if the role of = ops is to decide what standards to ignore, then perhaps the IESG should = reconsider the area=E2=80=99s charter.

Joe

= --Apple-Mail=_6AE410EF-E19A-401F-96C9-6357A9300277-- From nobody Tue Dec 11 12:06:54 2018 Return-Path: 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 CB20D130F55; Tue, 11 Dec 2018 12:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FMfFcVrtF3wO; Tue, 11 Dec 2018 12:06:43 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB93130F5B; Tue, 11 Dec 2018 12:06:43 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 0585621DCE; Tue, 11 Dec 2018 12:06:42 -0800 (PST) From: Wes Hardaker To: Brian E Carpenter Cc: Nick Hilliard , tsv-art , OPSEC , IETF-Discussion Discussion , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <3744b28c-3a5a-1ce4-9ff7-5374804d332e@gmail.com> <35277330-4743-4690-8ae0-9a9ab7e34f05@foobar.org> <3a182a82-b933-2d9b-52a8-24805717879b@gmail.com> Date: Tue, 11 Dec 2018 12:06:41 -0800 In-Reply-To: <3a182a82-b933-2d9b-52a8-24805717879b@gmail.com> (Brian E. Carpenter's message of "Fri, 7 Dec 2018 11:16:25 +1300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 20:06:45 -0000 Brian E Carpenter writes: > "By in large, this flow label changing behaviour has been traced to > IPv6 supporting CPE/firewalls, which change the flow label between the > initial syn and the ack." > > Broken middleboxes can prevent anything from working properly. With my hat on, we have indeed run into a problem where a small (~ 2%) of IPv6 TCP sessions to us were failing due to FlowLabels being used in ECMP hashing. We had to turn off the usage of FlowLabel in the hashing because of even a small real world impact to end-users. -- Wes Hardaker USC/ISI From nobody Tue Dec 11 14:39:09 2018 Return-Path: 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 8091F128BCC; Tue, 11 Dec 2018 14:39:07 -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 Dv_EzcpHjk_3; Tue, 11 Dec 2018 14:39:05 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 5F17D124D68; Tue, 11 Dec 2018 14:39:05 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id b7so7826049pfi.8; Tue, 11 Dec 2018 14:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=S/JHE4u1MczeAhG5aBu71/3AlxvbLentof7IL7N0tAQ=; b=tKJS/icgVoDDPmG8c92Sh0fQswsK6PuL5O2Xa6UiEPUgyTY8WVQ8CrQXW9PvWFQgI+ NGWeeUmPIqZX1bAXheBMNDR4oTR/5ba3S4zkF84yXeBiOk4BwV6jpBvRle6RGEJi1Ryf IyzC8uoqtBPIRWifuEt/Fmef75E8X5MTLz+Ogb1jrO3QHqfT83fqX7TqMSYVY+4wixoC tlXeQ7P5AELurt35Y2mv5u//hHj8OrDPGEayk61kcJxYsCJ5DxDTwsVdnXKOqKzxexX/ ofvU6mwGY6lzTeTW45aXiyk9cvuejYyBxxNuBAMeICaSV4uOz9Q7O5F7qyQ0o+kwdQtd Wtdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=S/JHE4u1MczeAhG5aBu71/3AlxvbLentof7IL7N0tAQ=; b=uTggJy2P7Td/R/M7F4k65NCviqs5QhotjlSKn3d/+38a0TGQcqLULIz/ASW9JZ2R0D v3avkKV68+Hc5BxEedsItGbunBs7b4V8DVKzCrw9O+P8AGUEzWo33DTcThdu38KzG8mA YPcA8JpzsfVSsEY/d2Kt9mtx29VNA12sFIoW/bYtNWz9/APq2hv1KPbo36ds3kH+omG9 Nh3WvyAgX9Nh/ZduNRSkvxmotQjjG2dnHxP8b+TSYPepx/l56oXGYrnSpmWPV1qv6/aw pnEotb35AXinYIxvEos71y0Jd5EZ1ayfvNtulr59jRJdLYOy+Tm3lL+UO7HHvv0FzKXG 5cnQ== X-Gm-Message-State: AA+aEWbl9shSlDcC8Ds/TGvikpgPk5Z61seJqqG7zFu1BJCPogJIOifA OzCQfDttnFa9IDQkp5MG+Xcz3KroPM4= X-Google-Smtp-Source: AFSGD/Vs4g8TW1xaDFEVuZ5hU/shOovpC5HdfPZBRttGrnAYSDy31z0vISn2PXTxcUfyHt3OoO2Nlg== X-Received: by 2002:a63:2d46:: with SMTP id t67mr16636700pgt.140.1544567944740; Tue, 11 Dec 2018 14:39:04 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id i193sm27869016pgc.22.2018.12.11.14.39.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Dec 2018 14:39:03 -0800 (PST) To: Wes Hardaker Cc: Nick Hilliard , tsv-art , OPSEC , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <3744b28c-3a5a-1ce4-9ff7-5374804d332e@gmail.com> <35277330-4743-4690-8ae0-9a9ab7e34f05@foobar.org> <3a182a82-b933-2d9b-52a8-24805717879b@gmail.com> From: Brian E Carpenter Message-ID: Date: Wed, 12 Dec 2018 11:38:58 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 22:39:08 -0000 (Cc:s trimmed) On 2018-12-12 09:06, Wes Hardaker wrote: > Brian E Carpenter writes: > >> "By in large, this flow label changing behaviour has been traced to >> IPv6 supporting CPE/firewalls, which change the flow label between the >> initial syn and the ack." >> >> Broken middleboxes can prevent anything from working properly. > > With my hat on, we have indeed run into a problem where a > small (~ 2%) of IPv6 TCP sessions to us were failing due to FlowLabels > being used in ECMP hashing. We had to turn off the usage of FlowLabel > in the hashing because of even a small real world impact to end-users. It's a shame. Can you characterise those sessions in any way? (This shouldn't invalidate ECMP/LAG usage as described in RFC6438, since there it is the operator that sets the flow label.) Brian From nobody Tue Dec 11 14:56:46 2018 Return-Path: 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 450F6130F58; Tue, 11 Dec 2018 14:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rO1HR9xTyPWn; Tue, 11 Dec 2018 14:56:42 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911D8130F62; Tue, 11 Dec 2018 14:56:42 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id A20182076F; Tue, 11 Dec 2018 14:56:35 -0800 (PST) From: Wes Hardaker To: Brian E Carpenter Cc: Wes Hardaker , Nick Hilliard , tsv-art , OPSEC , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <3744b28c-3a5a-1ce4-9ff7-5374804d332e@gmail.com> <35277330-4743-4690-8ae0-9a9ab7e34f05@foobar.org> <3a182a82-b933-2d9b-52a8-24805717879b@gmail.com> Date: Tue, 11 Dec 2018 14:56:35 -0800 In-Reply-To: (Brian E. Carpenter's message of "Wed, 12 Dec 2018 11:38:58 +1300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 22:56:44 -0000 Brian E Carpenter writes: > It's a shame. Can you characterise those sessions in any way? > > (This shouldn't invalidate ECMP/LAG usage as described in RFC6438, > since there it is the operator that sets the flow label.) I had to go dig out the bug that we dealt with "way back then" (to be fair, btw, credit to Duane Wessles at Verisign who tracked down and could reproduce the issue). There were two issues: 1) The linux kernel ECMP support had a bug in that they were including the ECN bits of the flow label. But even fixing this didn't fix the problem, because 2) Some clients were sending a flowlabel for the initial TCP handshake and then zeroing it out in subsequent packets: SYN: .... .... .... 1101 0111 0101 0110 0100 = Flow Label: 0xd7564 SYNACK from server: (no label) ACK from client: .... .... .... 1101 0111 0101 0110 0100 = Flow Label: 0xd7564 First data packet: .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 Which what was causing the problem. -- Wes Hardaker USC/ISI From nobody Tue Dec 11 15:59:06 2018 Return-Path: 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 6A30D128B14 for ; Tue, 11 Dec 2018 15:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 RsC4Eih5WTmd for ; Tue, 11 Dec 2018 15:58:44 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 8FFC4128BCC for ; Tue, 11 Dec 2018 15:58:43 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id y1so3970757wmi.3 for ; Tue, 11 Dec 2018 15:58:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=zRxUlthQCLzT1undfSZzkZIQcXQ06zqS6jQahCtujfI=; b=v/3BV94DvUwbZhi2CRfuvT4TR6KcYlrv/1k7VfV3yC0e5LdhPbohJJgw5GyvltXc8+ vdUdZ+kOoR/xnPev7dqBHI2ASqlG+BZxLYETSuBbAAlKD5lJ2cvDCGzMonCxJ9UNLDr5 iXUOBbC9ZZLYsLtRtLzja9hOYPnNIR5vtwPxlR6XDn0rSzDU52m5k26YofmSn7iOBQDK hUymxfyBF643uv+bUawDPzyPRqYNQH2TkKrIDsBpY+kwTUK184Fwek9hLWq2gm1cx6eW MoQp4vDEaMMNkuNMO/E7Q8O8saK8LsqeZAbv/aMIuLBHHLlAkulZih33UYEWa/KSZWUV coTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zRxUlthQCLzT1undfSZzkZIQcXQ06zqS6jQahCtujfI=; b=VFXtuQxwsrja+Z77UnoyrphA0pAC2o7URjmkP4tV8K7awZaF7tVADk4AW9CtEpGFxQ S0ySmcY0ACcOqgHvS1Ve12oneEjMHcCTYMypskZDzsHlM6TTIDFCO3yBat0tA1Xyquom gEq2UkoMd32jrpx1dAaFUEH5NrIxQmcvrXV5oJ6+kpG8Ss/WfSz/xxE+iqxA29gYt4kZ zkaUwuX0WxMkRlxl57gsd2wu5BzBEsyz27DRiz2n9J9bzjrtYsfXO4OVxWzSLAf0TISQ 8EVtiUQWAWzXEMgCvKgX8NVOWvM6EEJ6O+L1O7R6lcmU1DCIsi76fjKPKFYlGCWZeZWn hdkg== X-Gm-Message-State: AA+aEWYyfJ1Y7aC/52xxmJCixUwPv9/wqdgpYU5K2zcAHKjJ99BvN3B4 cMva/p5Lqiu5zYC/CgpFXGoaaPjU6+Xmn7Yp9nRznA== X-Google-Smtp-Source: AFSGD/Wok8IYdbEGik9KmFd5kQszZ7lJe4FtiKJpw2Dju0vd7bpEJY6vVVK3RNEfRsuBOmiVj3i7xIKZS/CBZnZDwtQ= X-Received: by 2002:a1c:f112:: with SMTP id p18mr3969933wmh.83.1544572721553; Tue, 11 Dec 2018 15:58:41 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Tue, 11 Dec 2018 18:58:05 -0500 Message-ID: To: IETF Discuss , opsec wg mailing list , tsv-art@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000065fcca057cc7dcf4" Archived-At: Subject: [OPSEC] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 23:58:58 -0000 --00000000000065fcca057cc7dcf4 Content-Type: text/plain; charset="UTF-8" Thank you, everyone, for a spirited discussion! I've gone through the discussions and broken the emails down into a few categories - there were a number of emails on the document itself, many of them with helpful suggestions on how to improve / focus the document (thank you!). More recently the discussion has become more acrimonious, and morphed from discussion **on this document** into the larger philosophical discussions on filtering in general, if what we have designed and call IPv6 can actually be implemented / deployed in the real world on core-type devices, what it means to claim compliance with a specification, the role of ISPs, ossification caused by operational decisions, "my network, my rules", etc. The IETF LC thread on the document, and the TSVART review (and corresponding thread) both generated useful, and actionable comments, and I've asked the authors to go through them carefully and address them -- these fall into the "on the document" category. I think that once these have been done, the document itself will be in acceptable shape to proceed (but keep reading!) There has been a significant amount of additional discussion after this - and it mostly falls into the "larger discussion" category. It covers things such as: * the implications of protocol design on implementability / deployability (can protocol X be deployed at scale?). Should feasibility of implementation in hardware be a consideration? * the harms caused by filtering in the network (ossification, survivability of extensions, layering principles) * operators need to perform filtering for end-point protection / DDoS mitigation / ECMP * what it means to be compliant with a specification (if you can forward at rate X, but only filter at rate x/1,000,000 are you compliant?). If it is not possible to buy / build a device which filters at line rate, is that the fault of the vendor, the operator or the protocol design? * do intermediate devices have any right to filter / role in filtering? If operators need to be able to do X to run their service / network, and they have to choose between "protocol correctness" and "keeping the network running", is it acceptable to drop / fold / spindle / mutilate correctness to keep the network up? The discussion seems to have broken into 2 camps -- those who are saying that 1: the network / vendors should be able to do what the RFCs say, vs 2: those who say that operational reality trumps RFCs. This seems to be one of the tussles -- the other is (largely): 1: blocking unknown X is harmful to future protocols / development (blacklist approach) vs 2: I run a [network / service / system] and know what packets I'm expecting. If I don't expect X, I'm just going to drop it (whitelist approach) This same discussion has come up a number of times over the past few years -- "Why operators filter fragments" was one instance, the (multitude) of EH discussions were another. It is clear that we are fairly far apart in many instances of this discussion, and it is worth further discussing the different philosophies. I feel that we should be discussing the architectural issues separately (not in the thread on this document). I also think that there is a fair bit of distance between the "operators" view and the "architecture" view. I'm going to further investigate / discuss this, but I think that it might be worth: * having some presentations / discussions on "how X works when deployed / implementation shortcomings". As an example, at the IEPG meeting in Yokohama (IETF94) these was a presentation on "MODERN ROUTER ARCHITECTURE FOR PROTOCOL DESIGNERS" - http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf . As another example, I was recently informed of a surprising limitation in TLS libraries -- these are apparently well known to those who work in this space, but I'd certainly never heard of them. I think that we (IETF participants in general) sometimes fall into believing that we know how technology X works because we've helped design it, but don't necessarily know what happens once it escapes our clutches / flies out of the nest. * consider having a BoF on this / these topics. * perhaps something like a workshop? As for the current discussion, I'd like people to please: a: step back and decided if you are simply repeating your current position (but in a new and louder voice) or if you are bringing something new to the topic. b: move the discussion to this thread -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --00000000000065fcca057cc7dcf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you= , everyone, for a spirited discussion!

I've gone through the= discussions and broken the emails down into a few categories - there were = a number of emails on the document itself, many of them with helpful sugges= tions on how to improve / focus the document (thank you!).=C2=A0

Mor= e recently the discussion has become more acrimonious, and morphed from dis= cussion **on this document** into the larger philosophical discussions on f= iltering in general, if what we have designed and call IPv6 can actually be= implemented / deployed in the real world on core-type devices, what it mea= ns to claim compliance with a specification, the role of ISPs, ossification= caused by operational decisions, "my network, my rules", etc.
<= br>

The IETF LC thread on the docum= ent, and the TSVART review (and corresponding thread) both generated useful= , and actionable comments, and I've asked the authors to go through the= m carefully and address them -- these fall into the "on the document&q= uot; category. I think that once these have been done, the document itself = will be in acceptable=C2=A0shape to proceed (but keep reading!)=C2=A0

=

There has been a significant amoun= t of additional discussion after this - and it mostly falls into the "= larger discussion" category.
=
It covers things such as:

*= the implications of protocol design on implementability / deployability (c= an protocol X be deployed at scale?). Should feasibility of implementation = in hardware be a consideration?=C2=A0
* the harms caused by filtering in t= he network (ossification, survivability of extensions, layering principles)=
* what it means to be compliant with a specification (if yo= u can forward at rate X, but only filter at rate x/1,000,000 are you compli= ant?). If it is not possible to buy / build a device which filters at line = rate, is that the fault of the vendor, the operator or the protocol design?=



The discussion= seems to have broken into 2 camps -- those who are saying that

1: t= he network / vendors should be able to do what the RFCs say,
vs
2: those = who say that operational reality trumps RFCs.

This seems to be one = of the tussles -- the other is (largely):

1: blocking unknown X is h= armful to future protocols / development (blacklist approach)
<= div class=3D"gmail_default">vs
2: I run= a [network / service / system] and know what packets I'm expecting. If= I don't expect X, I'm just going to drop it (whitelist approach)
=


This same discussion has come up a number of times over t= he past few years -- "Why operators filter fragments" was one ins= tance, the (multitude) of EH discussions were another.

It is clear t= hat we are fairly far apart in many instances of this discussion, and it is= worth further discussing the different philosophies. I feel that we should= be discussing the architectural issues separately (not in the thread on th= is document). I also think that there is a fair bit of distance between the= "operators" view and the "architecture" view.

I= 'm going to further investigate / discuss this, but I think that it mig= ht be worth:

* having some presentations / discussions on "how = X works when deployed / implementation shortcomings". As an example, a= t the IEPG meeting in Yokohama (IETF94) these was a presentation on "M= ODERN ROUTER ARCHITECTURE FOR PROTOCOL DESIGNERS" - http://www.= iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf . As another= example, I was recently informed of a surprising limitation in TLS librari= es -- these are apparently well known to those who work in this space, but = I'd certainly never heard of them. I think that we (IETF participants i= n general) sometimes fall into believing that we know how technology X work= s because we've helped design it, but don't necessarily know what h= appens once it escapes our clutches / flies out of the nest.
* consider ha= ving a BoF on this / these topics.
* perhaps something like a workshop?
<= br>



As for the current = discussion, I'd like people to please:

a: step back and decided = if you are simply repeating your current position (but in a new and louder = voice) or if you are bringing something new to the topic.

b: move th= e discussion to this thread


--
<= div dir=3D"ltr" class=3D"gmail_signature">I don't think the execution i= s relevant when it was obviously a bad idea in the first place.
This is = like putting rabid weasels in your pants, and later expressing regret at ha= ving chosen those particular rabid weasels and that pair of pants.
=C2= =A0 =C2=A0---maf
--00000000000065fcca057cc7dcf4-- From nobody Tue Dec 11 16:21:05 2018 Return-Path: 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 332D0124D68; Tue, 11 Dec 2018 16:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 avg2JMo17k91; Tue, 11 Dec 2018 16:21:01 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE4D1293FB; Tue, 11 Dec 2018 16:21:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EDBE8BE5C; Wed, 12 Dec 2018 00:20:57 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJC49XgJpgfN; Wed, 12 Dec 2018 00:20:56 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3C758BE5B; Wed, 12 Dec 2018 00:20:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1544574056; bh=ZScPYRu/GfopXzgUDpIFezXxQlMF4oHvTakVBjkSHFg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=pfsqNiTmCHhTZqau5EI4Nc10Lof6c7XSVPtwS3EVkrFo/VJbDM39cEwCA63X+t7Gf duaB9cTWg5sV+RktGi8vQltyqGCphSlKM0ljQUuDRBrZ63/BOQ1Tz12C8ET9p6HtNi CwWQSHq2EqneKTC+SmvIBsjEgsM+M/faxkowdkR8= To: Warren Kumari , IETF Discuss , opsec wg mailing list , tsv-art@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <3661a5b9-9178-d20a-a781-ed773140c8af@cs.tcd.ie> Date: Wed, 12 Dec 2018 00:20:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BArI3sIHlGzBhWhpq42idr6fJHCevutrD" Archived-At: Subject: Re: [OPSEC] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 00:21:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BArI3sIHlGzBhWhpq42idr6fJHCevutrD Content-Type: multipart/mixed; boundary="yDlPdkay9K5C4cCK1eOhaNrFH1SI0Khzl"; protected-headers="v1" From: Stephen Farrell To: Warren Kumari , IETF Discuss , opsec wg mailing list , tsv-art@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Message-ID: <3661a5b9-9178-d20a-a781-ed773140c8af@cs.tcd.ie> Subject: Re: Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering) References: In-Reply-To: --yDlPdkay9K5C4cCK1eOhaNrFH1SI0Khzl Content-Type: multipart/mixed; boundary="------------BBB0DF2DAB3EDC569EC7EFD2" Content-Language: en-GB This is a multi-part message in MIME format. --------------BBB0DF2DAB3EDC569EC7EFD2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 11/12/2018 23:58, Warren Kumari wrote: > * having some presentations / discussions on "how X works when deployed= / > implementation shortcomings". As an example, at the IEPG meeting in > Yokohama (IETF94) these was a presentation on "MODERN ROUTER ARCHITECTU= RE > FOR PROTOCOL DESIGNERS" - > http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf .= As > another example, I was recently informed of a surprising limitation in = TLS > libraries -- these are apparently well known to those who work in this > space, but I'd certainly never heard of them. I think that we (IETF > participants in general) sometimes fall into believing that we know how= > technology X works because we've helped design it, but don't necessaril= y > know what happens once it escapes our clutches / flies out of the nest.= > * consider having a BoF on this / these topics. > * perhaps something like a workshop? Maybe consider moving IEPG to a more prime-time IETF meeting week slot? (Or any equivalent.) The couple of times I've gotten to IEPG, I was struck by how it was higher quality than average IETF presentations. For me, I always really like finding out about cases where reality !=3D theory and I bet I'm far from alone. So, I'd argue a bit against a one-off BoF or workshop and more for a recurring opportunity for fact-based detailed presentations. S. --------------BBB0DF2DAB3EDC569EC7EFD2 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------BBB0DF2DAB3EDC569EC7EFD2-- --yDlPdkay9K5C4cCK1eOhaNrFH1SI0Khzl-- --BArI3sIHlGzBhWhpq42idr6fJHCevutrD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlwQVGcACgkQWrL68XsX K+qrKQ//R75DtV+znvRHnh2cT2vVCLwZ3pYsP2DObCkuP91SJe3H8GcUukMCQZ7r wIs8E865yTrt04hduxWfkN/ftLRLJfKIoaU0xj4ZfRV6XK5CXsVScQyoCCSyf+Db tgTCzkyUxCal8CDvPRB6oiHMMofGucLxkobSpHgS7RJ0E2UwsJhWSJN24ZTmyTfs UdbagVg1v7BR+B0M9Kn5KVNvbUDyq6vJWYhFdsv78Dq9bNAVTf8jby76Brc9M/77 Nn9ZiAL5IraS6CetJxHzc5JGOglQIG+rZ+j2h2NsNedTyd0jQyjAtnsaOh9lpeNE sPkXDO3ljFiJPmWPov+VtcuFZbaU0nieyUpROHE8XPBA8Gw8BXUydy/MAkuw5FBD BvcX2R+xhRIaSe0ZLgQPnGiQO2kLNv631A/X+/DL3SduohEoeYjLThBQ5pcX6NqQ 5aNIb4mlszKZKo5Wes22H+ecwqf8P0zbeA4U1U/TWT5kSzVCOLRW0Cy6TXJUVgmv IijSEQrVE5asRHPTHV/YKwg/WWiglzAQzR9tiuUneL5tjRGa0PEZLseX5C0B/qRB V3o82ywemHGIsSr3IEkNoQxnJNbDCJt+sX/3oxYGtFb43NtSEQ5gBQfVQazzqU+c BWOe5m5hKI9cZvPnHNnXOoqag64f4W/IWQQZftp0SL8y2MetAa0= =25y2 -----END PGP SIGNATURE----- --BArI3sIHlGzBhWhpq42idr6fJHCevutrD-- From nobody Tue Dec 11 18:33:51 2018 Return-Path: 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 6959B131021; Tue, 11 Dec 2018 18:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 3Xus5wwBt-hU; Tue, 11 Dec 2018 18:33:47 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 5BE34131016; Tue, 11 Dec 2018 18:33:47 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id x6so13578843ioa.9; Tue, 11 Dec 2018 18:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cqxCTR9yvq0My9hc/VuefhE4F22/lQmKCFcZT/sSt5s=; b=K2IlQhZtre8nQtJVycFopLpXBnGSIKgJ7z9CgaynEUU+KCtHeql07GS2WR2JR4q7t0 uUwRGTmD1FGpLPnLB8Vcl+HL6RapB21188tKMaS4q7As8N/SvxXeDoE1wQ5+EB5tInRu ED72wbwKKSC742t6GgTdC04Yrno9xcCbM09ud7YB6l+nhX2NoP+kOZEpdfLdstaShs4I /Ec/8nMpjeHcI6dLZGPNTIcgSt63UksSU3dIh5OQEK1cvTAib/qhVvQV0yPY0q3lSteC nRIQpmdFpdqMQu9flp0TjEYfxsJdbAipcTMpuT8p97yrUqN+aZthZWWpKgfUyt/EQT8b Nq+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cqxCTR9yvq0My9hc/VuefhE4F22/lQmKCFcZT/sSt5s=; b=KUs1ZQM0nQwgXgYAipnMknMIrV75m4Oh9r+ULJ0nS/ZibpNbnF6bEw2H8Ni9ZZFhcz flTYFzKYECerwTrk5CcbBeI+n/C9CimvyM+xe8i983wBMeqDc6+RvE2MADsXVpUoYzaK Z0D4P1har1T+7NESHO0Fljdj0u0oCJcW/FE0yAw/gnc26G257ZYJmCOOIqn8cBVktKOm U2pC0PACZlrcorkxSgTWM69b8rxASCJNRAfgjy3Tc62ApO2dKcONG3baj8u8gO/4ZqyH tgzE+m0sFPIad2U9UM8QuvHnv8+28CrP9yI5z0e1T2ID/OL3tTizoyZaY1JB2oZqSjhA MY+g== X-Gm-Message-State: AA+aEWY27yJdA2x9DEcjA64JKwoI2AMgv4shzbQEbl+9NAUPjTNXh9OP OIWE3CO5iYUjuD45BRt1Irvgrlbc X-Google-Smtp-Source: AFSGD/WvemyQzub/5ANbs2Q2d61jPWb//nfE0JXtPstjlXQ6wniIGayEoP3JHHqb6HeP6OBTyhWKrw== X-Received: by 2002:a6b:f404:: with SMTP id i4mr13794598iog.281.1544582026460; Tue, 11 Dec 2018 18:33:46 -0800 (PST) Received: from [192.168.1.34] (184-15-162-166.dsl2.chtn.wv.frontiernet.net. [184.15.162.166]) by smtp.gmail.com with ESMTPSA id m37sm1994057iti.6.2018.12.11.18.33.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Dec 2018 18:33:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: tjw ietf X-Mailer: iPhone Mail (16C50) In-Reply-To: <3661a5b9-9178-d20a-a781-ed773140c8af@cs.tcd.ie> Date: Tue, 11 Dec 2018 21:33:45 -0500 Cc: Warren Kumari , IETF Discuss , opsec wg mailing list , tsv-art@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0F89B980-2C64-4EC7-B8A6-31D6FBE240CA@gmail.com> References: <3661a5b9-9178-d20a-a781-ed773140c8af@cs.tcd.ie> To: Stephen Farrell Archived-At: Subject: Re: [OPSEC] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 02:33:50 -0000 I can not agree with mr Farrell enough on this. =20 Tim =46rom my high tech gadget > On Dec 11, 2018, at 19:20, Stephen Farrell wro= te: >=20 >=20 > Hiya, >=20 >> On 11/12/2018 23:58, Warren Kumari wrote: >> * having some presentations / discussions on "how X works when deployed /= >> implementation shortcomings". As an example, at the IEPG meeting in >> Yokohama (IETF94) these was a presentation on "MODERN ROUTER ARCHITECTURE= >> FOR PROTOCOL DESIGNERS" - >> http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf . A= s >> another example, I was recently informed of a surprising limitation in TL= S >> libraries -- these are apparently well known to those who work in this >> space, but I'd certainly never heard of them. I think that we (IETF >> participants in general) sometimes fall into believing that we know how >> technology X works because we've helped design it, but don't necessarily >> know what happens once it escapes our clutches / flies out of the nest. >> * consider having a BoF on this / these topics. >> * perhaps something like a workshop? >=20 > Maybe consider moving IEPG to a more prime-time IETF > meeting week slot? (Or any equivalent.) The couple of > times I've gotten to IEPG, I was struck by how it was > higher quality than average IETF presentations. For > me, I always really like finding out about cases where > reality !=3D theory and I bet I'm far from alone. >=20 > So, I'd argue a bit against a one-off BoF or workshop > and more for a recurring opportunity for fact-based > detailed presentations. >=20 > S. > <0x5AB2FAF17B172BEA.asc> From nobody Wed Dec 12 00:32:11 2018 Return-Path: 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 43BF012EB11; Wed, 12 Dec 2018 00:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 Fkc3e25fIumt; Wed, 12 Dec 2018 00:32:02 -0800 (PST) Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A811294D0; Wed, 12 Dec 2018 00:32:02 -0800 (PST) Received: from astfgl.hanazo.no (77.18.55.26.tmi.telenormobil.no [77.18.55.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id DE9C5FECBFCD; Wed, 12 Dec 2018 08:32:01 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id D40C7AF3818; Wed, 12 Dec 2018 09:31:57 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Ole Troan In-Reply-To: Date: Wed, 12 Dec 2018 09:31:57 +0100 Cc: IETF Discuss , opsec wg mailing list , tsv-art@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <999BE505-0121-4298-BD02-D4B9EF436FC4@employees.org> References: To: Warren Kumari X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [OPSEC] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 08:32:03 -0000 Warren, Thank you for your note. > On 12 Dec 2018, at 00:58, Warren Kumari wrote: >=20 > The IETF LC thread on the document, and the TSVART review (and = corresponding thread) both generated useful, and actionable comments, = and I've asked the authors to go through them carefully and address them = -- these fall into the "on the document" category. I think that once = these have been done, the document itself will be in acceptable shape to = proceed (but keep reading!)=20 How do I interpret this? Are you saying you think there is IETF = consensus to publish? Cheers, Ole= From nobody Wed Dec 12 04:06:09 2018 Return-Path: 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 D8016130DDA; Wed, 12 Dec 2018 04:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 EN6sao3jSBoD; Wed, 12 Dec 2018 04:06:00 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 3DFF5130E2D; Wed, 12 Dec 2018 04:06:00 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id v5so13338608lfe.7; Wed, 12 Dec 2018 04:06:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nCN5s9IzOvJC3NFA0KLmMiot/pwF3uB7ac70+nYw+DQ=; b=lKB8DYjaOTPgPeAmiduZbCy9S0up7SDM3xtODiZRPe1DyqPVA6VmuUbdIdiaBv1FFb zq1l7sBcb94eDaK+a5I2vakbwlnWLiXrbFs+Oqu95yQY8/SS8bNEO734GlbIdTxP6zD6 WxBRihEExDXEigr5TivnnsvmnJweNBtE7wNALo7rtyTHT0mDL0QN0JHPVmrHjPUv26iI gX1/Yj0zwYJWVG5thofNlXiESk2VtOLGeYQMiAqx9iP3exHqpxXjf3GGCWGpjFYLQG/N pH4Kv8t6ukQtzcMz9wNP2+ibZ2jRywfLVhsxCZPUfKu1pShhLuPHWAt6osra9Bhf2bXt bwoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nCN5s9IzOvJC3NFA0KLmMiot/pwF3uB7ac70+nYw+DQ=; b=DqQX67oXXNx6IEEs3jkV3/SkdBwKhTK/kG/RsEhaPqYMa7NQ3mTBPFUsJkUIUlLD7V lGT5K1Al2G0sautQpLAoDtF8b+dIBtBLogD5zqti9oTIWgzjN5by08Opu7IrKaMeTR2F syGpy+GLnfAFgWpP6qYq/xS40lVA9K0JyUZtKoNzAifkLWGbJQGK2TgOrSBM0wCEa5Kh v66GzTon/QIW9QVjxxATnpgm2akhVdxGoP4v6pBPtxhMwwz1WO7Jv/lgRYLbcR+dJxxf N93uWnJLx6/0mkdEjn4UTIRx3tInZ8YOI6PWaog8UcrVsnQYm2BTxZ3ZJ7uoeqnlEriY ZdAw== X-Gm-Message-State: AA+aEWYAxDIAANkzupTj9da2TL0kyBj6qxgwt7yB7e8TtiJCYTfA6BNz 1w0W1U7wOxMvCNOODZTO4LhthbmLvG/EoNo/Ya0= X-Google-Smtp-Source: AFSGD/XoF6iLzKjABfB/u6ZJjQuELWSr41yups6vK9ZPUOnzl8BgI/OQE6KVJmh7DgGvcwFlxeoqZcNQOa8wf9it21E= X-Received: by 2002:a19:d145:: with SMTP id i66mr12175963lfg.97.1544616358241; Wed, 12 Dec 2018 04:05:58 -0800 (PST) MIME-Version: 1.0 References: <3661a5b9-9178-d20a-a781-ed773140c8af@cs.tcd.ie> <0F89B980-2C64-4EC7-B8A6-31D6FBE240CA@gmail.com> In-Reply-To: <0F89B980-2C64-4EC7-B8A6-31D6FBE240CA@gmail.com> From: Spencer Dawkins at IETF Date: Wed, 12 Dec 2018 06:05:45 -0600 Message-ID: To: Tim Wicinski Cc: Stephen Farrell , tsv-art@ietf.org, opsec wg mailing list , Warren Kumari , IETF Discuss , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000058ecf6057cd205ac" Archived-At: Subject: Re: [OPSEC] [Tsv-art] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 12:06:03 -0000 --00000000000058ecf6057cd205ac Content-Type: text/plain; charset="UTF-8" Fwiw, On Tue, Dec 11, 2018, 20:34 tjw ietf I can not agree with mr Farrell enough on this. > > Tim > > From my high tech gadget > > > On Dec 11, 2018, at 19:20, Stephen Farrell > wrote: > > > > > > Hiya, > > > >> On 11/12/2018 23:58, Warren Kumari wrote: > >> * having some presentations / discussions on "how X works when deployed > / > >> implementation shortcomings". As an example, at the IEPG meeting in > >> Yokohama (IETF94) these was a presentation on "MODERN ROUTER > ARCHITECTURE > >> FOR PROTOCOL DESIGNERS" - > >> http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf > . As > >> another example, I was recently informed of a surprising limitation in > TLS > >> libraries -- these are apparently well known to those who work in this > >> space, but I'd certainly never heard of them. I think that we (IETF > >> participants in general) sometimes fall into believing that we know how > >> technology X works because we've helped design it, but don't necessarily > >> know what happens once it escapes our clutches / flies out of the nest. > >> * consider having a BoF on this / these topics. > >> * perhaps something like a workshop? > > > > Maybe consider moving IEPG to a more prime-time IETF > > meeting week slot? (Or any equivalent.) The couple of > > times I've gotten to IEPG, I was struck by how it was > > higher quality than average IETF presentations. For > > me, I always really like finding out about cases where > > reality != theory and I bet I'm far from alone. > > > > So, I'd argue a bit against a one-off BoF or workshop > > and more for a recurring opportunity for fact-based > > detailed presentations. > I agree with Stephen, and moving IEPG off Sunday morning actually maps onto the stated intent of recent IESGs and IABs to improve communication and interaction. You know this, but others may not know that the IESG has a standing meeting on Sunday mornings each IETF week, so the IESG is less aware of IEPG discussions than most IETF participants. I don't think we have to choose between moving IEPG and having a workshop, and maybe even a BOF. If we move IEPG and the community is more aware of operator positions, workshops and BOFs might be better informed. Is it premature to ask the nice IEPG people about this? A move would need to work for them, too. Spencer > > > S. > > <0x5AB2FAF17B172BEA.asc> > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > --00000000000058ecf6057cd205ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fwiw,

On Tue, Dec 11, 2018, 20:34 tjw ietf <tjw.ietf@gmail.com wrote:
I can not agree with mr Farrell enough on this.=C2=A0

Tim

>From my high tech gadget

> On Dec 11, 2018, at 19:20, Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:
>
>
> Hiya,
>
>> On 11/12/2018 23:58, Warren Kumari wrote:
>> * having some presentations / discussions on "how X works whe= n deployed /
>> implementation shortcomings". As an example, at the IEPG meet= ing in
>> Yokohama (IETF94) these was a presentation on "MODERN ROUTER = ARCHITECTURE
>> FOR PROTOCOL DESIGNERS" -
>> http://www.= iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf . As
>> another example, I was recently informed of a surprising limitatio= n in TLS
>> libraries -- these are apparently well known to those who work in = this
>> space, but I'd certainly never heard of them. I think that we = (IETF
>> participants in general) sometimes fall into believing that we kno= w how
>> technology X works because we've helped design it, but don'= ;t necessarily
>> know what happens once it escapes our clutches / flies out of the = nest.
>> * consider having a BoF on this / these topics.
>> * perhaps something like a workshop?
>
> Maybe consider moving IEPG to a more prime-time IETF
> meeting week slot? (Or any equivalent.) The couple of
> times I've gotten to IEPG, I was struck by how it was
> higher quality than average IETF presentations. For
> me, I always really like finding out about cases where
> reality !=3D theory and I bet I'm far from alone.
>
> So, I'd argue a bit against a one-off BoF or workshop
> and more for a recurring opportunity for fact-based
> detailed presentations.
=
I agree with Stephen, and moving IEPG off Sunda= y morning actually maps onto the stated intent of recent IESGs and IABs to = improve communication and interaction. You know this, but others may not kn= ow that the IESG has a standing meeting on Sunday mornings each IETF week, = so the IESG is less aware of IEPG discussions than most IETF participants.= =C2=A0

I don't think= we have to choose between moving IEPG and having a workshop, and maybe eve= n a BOF. If we move IEPG and the community is more aware of operator positi= ons, workshops and BOFs might be better informed.
Is it premature to ask the nice IEPG people about= this? A move would need to work for them, too.

=
Spencer

>
> S.
> <0x5AB2FAF17B172BEA.asc>

_______________________________________________
Tsv-art mailing list
Ts= v-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-ar= t
--00000000000058ecf6057cd205ac-- From nobody Wed Dec 12 13:55:35 2018 Return-Path: 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 7D37B1312DB for ; Wed, 12 Dec 2018 13:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 7JZaqfO3pBgi for ; Wed, 12 Dec 2018 13:55:25 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 B77EA1312E2 for ; Wed, 12 Dec 2018 13:55:24 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id v13so19227153wrw.5 for ; Wed, 12 Dec 2018 13:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AGTF/RWJlEPV8t2Bbt5Guk+RDWg9bXqyJey3SHLpnEA=; b=CZpos+TrtEnF3kmMypVJLLz9xZmR48G5yCcojvfnl9ZY1i9E69cOrTynwjVTeOTl65 0q55Dy/N8D+dZoTdJem8B6jXof+kgFzjc0MjufAsgPYSjR+BInu049pwhal1xObBAn9p 8Xwd40mgk5zsWXINv5rjaqdxw6XVYCXrXdnpUfYL7I+QCR4Hl9s7+LeZxaRd/IekR+DU Vrumi/ijNK2W9bpO55Kk5u+74nZ16uAVun6J+GU1MsV8pUYd7ZuDZnrJpHV2NW8I+Esz e+NLnLZVcUTSzDqB2qTxhiYSsAR5VcEJ1H6d8SZy/L/CCMjOysm13Fx61Rf+H2lQBe3E ZEPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AGTF/RWJlEPV8t2Bbt5Guk+RDWg9bXqyJey3SHLpnEA=; b=FhoWQQ6x8pMS0skY+G0vio7U04YNiwV9GBxyLBZbFoNUJTKO5N+KvRBlW/07FQ/r2r 0AfWjAIVfnOvqQg+AkV2Ffo3SUxKWNdMtEueam3AfFiW1/+6UwA9QwY8KOcxn3hSRAnu 5X5uc0mBsTERqY9ic54rM6ouCRXviGYSmE8/BKnvjBWvTZI3VVVWE+zBg22Xe836XL9r P87Ds/gnDOLy04gSmlVFX61/G4OIfeySF0oZ4Ka7zHEpcq0RvsoTC03Nv2J1zVkK4CuH IMUcX4ClMxPpi6aOlr/onE12i7vS0Vc8mKLbQbNHvGv1yaAHTTa3rHzjAWouspTrf4+D RlMA== X-Gm-Message-State: AA+aEWaI574kKa8nreOq6T3Nr8RmzKPKsm9g76sVJhbHCVDl8uN1ljzJ Rv5F8CnAUKrja737/9E2IWvvlOZCDhjZovUzx/dBfg== X-Google-Smtp-Source: AFSGD/UrzwCAPXeNbKOdn2pVc+BH3qJySHLqHDr4JmiBedLxw9FpaQ+m4BJkwW5mVdvwwwIIg5l4JMMZtgu2N/yNHOI= X-Received: by 2002:adf:f0c5:: with SMTP id x5mr17949458wro.77.1544651722743; Wed, 12 Dec 2018 13:55:22 -0800 (PST) MIME-Version: 1.0 References: <999BE505-0121-4298-BD02-D4B9EF436FC4@employees.org> In-Reply-To: <999BE505-0121-4298-BD02-D4B9EF436FC4@employees.org> From: Warren Kumari Date: Wed, 12 Dec 2018 16:54:46 -0500 Message-ID: To: Ole Troan Cc: IETF Discuss , opsec wg mailing list , tsv-art@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000003c8090057cda41ae" Archived-At: Subject: Re: [OPSEC] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 21:55:28 -0000 --0000000000003c8090057cda41ae Content-Type: text/plain; charset="UTF-8" On Wed, Dec 12, 2018 at 3:32 AM Ole Troan wrote: > Warren, > > Thank you for your note. > > > On 12 Dec 2018, at 00:58, Warren Kumari wrote: > > > > The IETF LC thread on the document, and the TSVART review (and > corresponding thread) both generated useful, and actionable comments, and > I've asked the authors to go through them carefully and address them -- > these fall into the "on the document" category. I think that once these > have been done, the document itself will be in acceptable shape to proceed > (but keep reading!) > > How do I interpret this? Are you saying you think there is IETF consensus > to publish? > Yes, probably. The discussions **on the draft itself** (and not the larger, philosophical discussions on operations vs architecture / what is actually implemented vs what routers should be able to do) looks like (after the editor makes the agreed to changes) good enough rough consensus for me to progress it to IESG evaluation. It is entirely possible that it will not survive that step / will be sent back to the WG / another IETF LC on the revised document will be called for / it will be munged beyond recognition at this point... W > Cheers, > Ole -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000003c8090057cda41ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On We= d, Dec 12, 2018 at 3:32 AM Ole Troan <otroan@employees.org> wrote:
Warren,

Thank you for your note.

> On 12 Dec 2018, at 00:58, Warren Kumari <warren@kumari.net> wrote:
>
> The IETF LC thread on the document, and the TSVART review (and corresp= onding thread) both generated useful, and actionable comments, and I've= asked the authors to go through them carefully and address them -- these f= all into the "on the document" category. I think that once these = have been done, the document itself will be in acceptable shape to proceed = (but keep reading!)

How do I interpret this? Are you saying you think there is IETF consensus t= o publish?

Yes, probably.

The discussio= ns **on the draft itself** (and not the larger, philosophical discussions o= n operations vs architecture / what is actually implemented vs what routers= should be able to do) looks like (after the editor makes the agreed to cha= nges) good enough rough consensus for me to progress it to IESG evaluation.=

It is entirely possible that it will not survive that step / will be = sent back to the WG / another IETF LC on the revised document will be calle= d for / it will be munged beyond recognition at this point...
W


Cheers,
Ole


--
I don't think the execution is relevant w= hen it was obviously a bad idea in the first place.
This is like putting= rabid weasels in your pants, and later expressing regret at having chosen = those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---m= af
--0000000000003c8090057cda41ae-- From nobody Thu Dec 13 04:24:22 2018 Return-Path: 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 1E351130DD3; Thu, 13 Dec 2018 04:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 e1Zmd5ioDG8e; Thu, 13 Dec 2018 04:24:18 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52856130DD2; Thu, 13 Dec 2018 04:24:18 -0800 (PST) Received: from [192.168.0.127] (unknown [190.154.131.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C3E8981DF7; Thu, 13 Dec 2018 13:24:14 +0100 (CET) To: Wes Hardaker , Brian E Carpenter Cc: Nick Hilliard , tsv-art , OPSEC , draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com> <20181205122142.GJ1543@Space.Net> <20181205133821.GL1543@Space.Net> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net> <3744b28c-3a5a-1ce4-9ff7-5374804d332e@gmail.com> <35277330-4743-4690-8ae0-9a9ab7e34f05@foobar.org> <3a182a82-b933-2d9b-52a8-24805717879b@gmail.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Thu, 13 Dec 2018 08:27:55 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06] X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 12:24:20 -0000 On 11/12/18 19:56, Wes Hardaker wrote: > Brian E Carpenter writes: > >> It's a shame. Can you characterise those sessions in any way? >> >> (This shouldn't invalidate ECMP/LAG usage as described in RFC6438, >> since there it is the operator that sets the flow label.) > > I had to go dig out the bug that we dealt with "way back then" (to be > fair, btw, credit to Duane Wessles at Verisign who tracked down and > could reproduce the issue). [...] > > 2) Some clients were sending a flowlabel for the initial TCP handshake > and then zeroing it out in subsequent packets: > > SYN: > .... .... .... 1101 0111 0101 0110 0100 = Flow Label: 0xd7564 > > SYNACK from server: (no label) > > ACK from client: > .... .... .... 1101 0111 0101 0110 0100 = Flow Label: 0xd7564 > > First data packet: > .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000 > > Which what was causing the problem. > At least some version of FreeBSD used to do the opposite: FL set to zero during the TCP 3WHS, and non-zero afterwards. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 13 04:24:43 2018 Return-Path: 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 24D21130DD3; Thu, 13 Dec 2018 04:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 x3YR0nwboDK2; Thu, 13 Dec 2018 04:24:17 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8114C130DCB; Thu, 13 Dec 2018 04:24:17 -0800 (PST) Received: from [192.168.0.127] (unknown [190.154.131.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3D99A8365C; Thu, 13 Dec 2018 13:24:09 +0100 (CET) To: Stephen Farrell , Warren Kumari , IETF Discuss , opsec wg mailing list , tsv-art@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <3661a5b9-9178-d20a-a781-ed773140c8af@cs.tcd.ie> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <6b848396-ef2e-557d-3901-626e1f529c14@si6networks.com> Date: Thu, 13 Dec 2018 08:26:11 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <3661a5b9-9178-d20a-a781-ed773140c8af@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSEC] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 12:24:21 -0000 On 11/12/18 21:20, Stephen Farrell wrote: > > Hiya, > > On 11/12/2018 23:58, Warren Kumari wrote: >> * having some presentations / discussions on "how X works when deployed / >> implementation shortcomings". As an example, at the IEPG meeting in >> Yokohama (IETF94) these was a presentation on "MODERN ROUTER ARCHITECTURE >> FOR PROTOCOL DESIGNERS" - >> http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf . As >> another example, I was recently informed of a surprising limitation in TLS >> libraries -- these are apparently well known to those who work in this >> space, but I'd certainly never heard of them. I think that we (IETF >> participants in general) sometimes fall into believing that we know how >> technology X works because we've helped design it, but don't necessarily >> know what happens once it escapes our clutches / flies out of the nest. >> * consider having a BoF on this / these topics. >> * perhaps something like a workshop? > > Maybe consider moving IEPG to a more prime-time IETF > meeting week slot? (Or any equivalent.) The couple of > times I've gotten to IEPG, I was struck by how it was > higher quality than average IETF presentations. For > me, I always really like finding out about cases where > reality != theory and I bet I'm far from alone. > > So, I'd argue a bit against a one-off BoF or workshop > and more for a recurring opportunity for fact-based > detailed presentations. +1 -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 13 12:23:17 2018 Return-Path: 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 AFD85130E89 for ; Thu, 13 Dec 2018 12:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 XRcQ20EG_oqz for ; Thu, 13 Dec 2018 12:23:07 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 0D82E130E7D for ; Thu, 13 Dec 2018 12:23:06 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id c126so3715015wmh.0 for ; Thu, 13 Dec 2018 12:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gDWsPZOUVjpDLnEHXA8Hb0GzVGubWqaBJ4+AJhOG12M=; b=otMcNx5a2GQ2PNlsisRO3QV2LJYlcJAWANCtIDeq1KQ2vXoj6vagoOnHAywgW8K6VE PLP7SO1DKIjLhm14O1YURSmI7nGwhGf90yQwCaaO2ZsYsbHfLRmC8o/TqySgMy7cbxvk FiE9zFK6ymR0FPpCO5K1cBU23AyEjhtI9nbkQMvTitXetAb8UpY7FIoWmffqJgwCtZmg WsrmiOH+YAxuqNmAJKe0AoS5r8p2cBL047L7kfKvrx0+dS9MEP8W8Sly2FR3ASG99VRh leVjkSpe3m/G2VCNiCGiGmr9q/o5IxkONkHVv/3fUC31F2oDJXMAE1qAqBv4VM65ZgaE 5nqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gDWsPZOUVjpDLnEHXA8Hb0GzVGubWqaBJ4+AJhOG12M=; b=WJJnLOmp7lKwcOBQ0fFgVfy1p4+ycMFXBTOMaNqAyD6DKkqfRJAGltqCoqG+aV5DPb NaCqq94aQjBWWLaTae38fcMGAcEU7Nni6pRUXpI0ygY0n7wwrD0Hx9QPeQCZmT2M7lvP 8hEfbGzpjW4C22HOovsc2t4MCl5SXK2nB95C7trG7HV+8rRnNt9GWa85iiYt0TKikgtA LyncEoUNNTVhFSfqDGPFS3o8VRISc+WemCPQSmsKHHr4PBUEzjqOVSfrzq2wu21InBID YM9qlOjDQBMGaEamMh6ZlmGU5kVUE/ohCtjvTPrSWCL0gwV7boKIxEsSPX0z3JNcumLk AVag== X-Gm-Message-State: AA+aEWa1r4j4GTkbS9hXibmZANMGulRjmL5LHAuVq1eCkbujhE3EHi1/ rGRoR6VHY1tZ5aEgTcoSA77THxn3D9sZgKZgLhelUw== X-Google-Smtp-Source: AFSGD/VljfIglZXYcTEKTWufEEBWHDVQnS4SJWj1uue53GObydIUr2hXJsTmVmaxNa6TD+vZMyCvCPz2+zyzk5vDY3w= X-Received: by 2002:a7b:c853:: with SMTP id c19mr753510wml.61.1544732585027; Thu, 13 Dec 2018 12:23:05 -0800 (PST) MIME-Version: 1.0 References: <999BE505-0121-4298-BD02-D4B9EF436FC4@employees.org> In-Reply-To: From: Warren Kumari Date: Thu, 13 Dec 2018 15:22:27 -0500 Message-ID: To: Ole Troan Cc: IETF Discuss , opsec wg mailing list , tsv-art@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000000fd1b057ced150d" Archived-At: Subject: Re: [OPSEC] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 20:23:12 -0000 --00000000000000fd1b057ced150d Content-Type: text/plain; charset="UTF-8" [ Top-post, follow-up to my own mail] I've had a chat with the rest of the IESG and I'm planning on going through all of the (230+! ) emails again and classify them into: A: related to the document itself B: related to the larger "do intermediate routers have any role in filtering" / "can devices actually do what it says on the tin" / related. C: I'd already done this, but only classified them in my head -- this will be a large undertaking (and many emails fall into multiple categories) and will take some time... Also, a fair bit of the discussion felt like people talking past each other - we will continue to investigate the information sharing / "recent changes in protocol X" type sessions. While looking into this I (re)discovered the "Technical Tutorials" ( https://www.ietf.org/about/participate/tutorials/technical/ ) page, but what I hadn't known before was the https://datatracker.ietf.org/group/edu/materials/ and https://trac.ietf.org/trac/edu/wiki/Tutorial_by_IETF pages. Many of these are a good way to get quick introduction to a new protocol / sphere -- eg: https://datatracker.ietf.org/meeting/101/materials/slides-101-edu-sesse-introduction-to-oauth-20-01.pdf W On Wed, Dec 12, 2018 at 4:54 PM Warren Kumari wrote: > > > On Wed, Dec 12, 2018 at 3:32 AM Ole Troan wrote: > >> Warren, >> >> Thank you for your note. >> >> > On 12 Dec 2018, at 00:58, Warren Kumari wrote: >> > >> > The IETF LC thread on the document, and the TSVART review (and >> corresponding thread) both generated useful, and actionable comments, and >> I've asked the authors to go through them carefully and address them -- >> these fall into the "on the document" category. I think that once these >> have been done, the document itself will be in acceptable shape to proceed >> (but keep reading!) >> >> How do I interpret this? Are you saying you think there is IETF consensus >> to publish? >> > > Yes, probably. > > The discussions **on the draft itself** (and not the larger, philosophical > discussions on operations vs architecture / what is actually implemented vs > what routers should be able to do) looks like (after the editor makes the > agreed to changes) good enough rough consensus for me to progress it to > IESG evaluation. > > It is entirely possible that it will not survive that step / will be sent > back to the WG / another IETF LC on the revised document will be called for > / it will be munged beyond recognition at this point... > > W > > >> Cheers, >> Ole > > > > -- > I don't think the execution is relevant when it was obviously a bad idea > in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --00000000000000fd1b057ced150d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[ Top-post, follow-up to my own mail]

I've had= a chat with the rest of the IESG and I'm planning on going through all= of the (230+! ) emails again and classify them into:
A: related to the doc= ument itself
B: related to the larger "do intermediate routers have an= y role in filtering" / "can devices actually do what it says on t= he tin" / related.
C:=C2=A0

I'd already done this, but only c= lassified them in my head -- this will be a large undertaking (and many ema= ils fall into multiple categories) and will take some time...=C2=A0

Al= so, a fair bit of the discussion felt like people talking past each other -= we will continue to investigate the information sharing / "recent cha= nges in protocol X" type sessions.=C2=A0
While looking into= this I (re)discovered the "Technical Tutorials" (https://www.ietf.o= rg/about/participate/tutorials/technical/ ) page, but what I hadn't= known before was the=C2=A0https://datatracker.ietf.org/group/edu/materials/ and=C2= =A0https:/= /trac.ietf.org/trac/edu/wiki/Tutorial_by_IETF pages.=C2=A0
Many of thes= e are a good way to get quick introduction to a new protocol / sphere -- eg= :=C2=A0https://datatracker.ietf.or= g/meeting/101/materials/slides-101-edu-sesse-introduction-to-oauth-20-01.pd= f

W


On Wed, Dec 12, 2018 at 4:54 PM Warren Kumari <warren@kumari.net> wrote:


On Wed, Dec 12, 2018 at 3:32 AM Ole Troan <otroan@employees.org> wrote:
=
Warren,

Thank you for your note.

> On 12 Dec 2018, at 00:58, Warren Kumari <warren@kumari.net> wrote:
>
> The IETF LC thread on the document, and the TSVART review (and corresp= onding thread) both generated useful, and actionable comments, and I've= asked the authors to go through them carefully and address them -- these f= all into the "on the document" category. I think that once these = have been done, the document itself will be in acceptable shape to proceed = (but keep reading!)

How do I interpret this? Are you saying you think there is IETF consensus t= o publish?

Yes, probably.

The discus= sions **on the draft itself** (and not the larger, philosophical discussion= s on operations vs architecture / what is actually implemented vs what rout= ers should be able to do) looks like (after the editor makes the agreed to = changes) good enough rough consensus for me to progress it to IESG evaluati= on.

It is entirely possible that it will no= t survive that step / will be sent back to the WG / another IETF LC on the = revised document will be called for / it will be munged beyond recognition = at this point...

W<= /div>


Cheers,
Ole


--
I don't think= the execution is relevant when it was obviously a bad idea in the first pl= ace.
This is like putting rabid weasels in your pants, and later express= ing regret at having chosen those particular rabid weasels and that pair of= pants.
=C2=A0 =C2=A0---maf


--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--00000000000000fd1b057ced150d-- From nobody Fri Dec 14 10:31:07 2018 Return-Path: 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 6E151131213; Fri, 14 Dec 2018 10:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 C3jFrHN0-0WI; Fri, 14 Dec 2018 10:31:04 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C85131210; Fri, 14 Dec 2018 10:31:04 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 1436727A22; Fri, 14 Dec 2018 10:31:02 -0800 (PST) From: Wes Hardaker To: Stephen Farrell Cc: Warren Kumari , IETF Discuss , opsec wg mailing list , tsv-art@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org References: <3661a5b9-9178-d20a-a781-ed773140c8af@cs.tcd.ie> Date: Fri, 14 Dec 2018 10:31:01 -0800 In-Reply-To: <3661a5b9-9178-d20a-a781-ed773140c8af@cs.tcd.ie> (Stephen Farrell's message of "Wed, 12 Dec 2018 00:20:55 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [OPSEC] Architectural implications of EH / filtering X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 18:31:06 -0000 Stephen Farrell writes: > Maybe consider moving IEPG to a more prime-time IETF > meeting week slot? One huge advantage of doing this is it then falls into conflict-avoidance play; right now I can pretty much never make the IEPG meetings due to other non-movable meetings. Rotating it around the IETF schedule, with conflict avoidance especially for speakers, will mean wider attendance and variation with those that can only attend "sometimes". -- Wes Hardaker USC/ISI From nobody Mon Dec 24 08:52:53 2018 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D064D130FAE; Mon, 24 Dec 2018 08:52:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vijay Gurbani To: Cc: opsec@ietf.org, ietf@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154567035680.12799.5999926377342014157@ietfa.amsl.com> Date: Mon, 24 Dec 2018 08:52:36 -0800 Archived-At: Subject: [OPSEC] Genart last call review of draft-ietf-opsec-ipv6-eh-filtering-06 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2018 16:52:37 -0000 Reviewer: Vijay Gurbani Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-opsec-ipv6-eh-filtering-?? Reviewer: Vijay K. Gurbani Review Date: 2018-12-24 IETF LC End Date: 2018-12-03 IESG Telechat date: Not scheduled for a telechat Summary: This draft is ready for publication as an Informational RFC. It is well written and organized and I did not detect anything amiss from my reading of the draft. Major issues: 0 Minor issues: 0 Nits/editorial comments: 0