Re: [tcpm] rfc5961 and suggested updates.

"Smith, Donald" <Donald.Smith@CenturyLink.com> Fri, 05 October 2018 16:40 UTC

Return-Path: <Donald.Smith@CenturyLink.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE1E130E55 for <tcpm@ietfa.amsl.com>; Fri, 5 Oct 2018 09:40:49 -0700 (PDT)
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=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 nGoYv7IajND9 for <tcpm@ietfa.amsl.com>; Fri, 5 Oct 2018 09:40:48 -0700 (PDT)
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 E19AB130E51 for <tcpm@ietf.org>; Fri, 5 Oct 2018 09:40:47 -0700 (PDT)
Received: from lxomp90v.corp.intranet (emailout.qintra.com [151.117.203.59]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id w95GeiFa025431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 Oct 2018 10:40:45 -0600
Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id w95Gedab056842; Fri, 5 Oct 2018 11:40:39 -0500
Received: from lxdnp31k.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id w95GedDg056831 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Fri, 5 Oct 2018 11:40:39 -0500
Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id w95GecOV042102; Fri, 5 Oct 2018 10:40:38 -0600
Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id w95Gect7042094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2018 10:40:38 -0600
Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([151.119.128.28]) with mapi id 14.03.0339.000; Fri, 5 Oct 2018 10:40:38 -0600
From: "Smith, Donald" <Donald.Smith@CenturyLink.com>
To: Joe Touch <touch@strayalpha.com>, Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>
CC: Eric Dumazet <edumazet@google.com>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] rfc5961 and suggested updates.
Thread-Index: AQHUO7PXINhfy3iY1ka1dkXbKt8YOaUMYO0AgAJ6EZOAARTMAIAAgpOAgACfKdw=
Date: Fri, 5 Oct 2018 16:40:37 +0000
Message-ID: <68EFACB32CF4464298EA2779B058889D53E3759D@PDDCWMBXEX503.ctl.intranet>
References: <CAOp4FwQqfJh6QiNbtcaH83gbZm+iPK5zpTCvje0W+Tpz+fjNng@mail.gmail.com> <DDE6A9C1-3FED-4F0A-84F1-355FA2EBFCF1@tik.ee.ethz.ch> <CAOp4FwQ26SChQtPZ84aGZSYx6kfBChHkff54sqWNy4iMbeHg-Q@mail.gmail.com> <CALvgte-JDaKczpa_WYHNxzDJ7m2Yz3KRGxBgEuj2k0x76p2XTw@mail.gmail.com> <CAOp4FwRWmuh=RtHA9mULOt3XBGN_thK3FiTVRkBLK1XWKH4N+g@mail.gmail.com> <CADVnQymo0GD-K9QdOcTHZ2X6D-JozXV4_sX06U1Q=UjCoaSuWg@mail.gmail.com>, <91E0378A-354A-41A0-A1A9-C888AD4E0178@strayalpha.com>
In-Reply-To: <91E0378A-354A-41A0-A1A9-C888AD4E0178@strayalpha.com>
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: <https://mailarchive.ietf.org/arch/msg/tcpm/ycoY3mBJ_HxIuwIyo4EnZC-etWw>
Subject: Re: [tcpm] rfc5961 and suggested updates.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2018 16:40:50 -0000

Has anyone done the math to show this wouldn't be a 64k increase in counters/buffers/challenge ACKs?
Intuitively I know it isn't, in most cases you only have a few open ports/services, so probably 2x, 3x... ?

Is there any value to saying only OPEN sockets, ports or services or is that implied?
Is open socket the same as if it would have been allowed by a filter?
Clearly the OS doesn't know if a middle box would have filtered it, but it could in theory know if a host based filter would have stopped it.

"2.  Recommendation for ACK throttling mechanism
An implementation SHOULD have a per-socket ACK throttling mechanism
which is not shared across the system."

Socket implies open port/service, but if a port is open at the OS level but closed or limited to a specific set of source addresses via ACL, Iptables, IPF  (HFW)… or even a middle box should that be taken into account Packet could be filtered at a higher level than basic OS socket creation so no challenge ack nor counter needed unless it could have been allowed?

If you only send challenge acks for open ports/services would this provide a way to do negative scans?
The src is spoofed, so I don't think so, as the blind reset sender isn't seeing the challenges.

Metric System < +000 > -000
Extra People's Terribly Good Meals Kept mY uNCLE    Ned   Purring For     Ages
Exa   Peta        Tera     Giga   Mega  Kilo milli Micro(u) Nano Pico    Femto Atto
Donald.Smith@centurylink.com



From: tcpm [tcpm-bounces@ietf.org] on behalf of Joe Touch [touch@strayalpha.com]
Sent: Thursday, October 04, 2018 6:30 PM
To: Neal Cardwell
Cc: Eric Dumazet; tcpm@ietf.org
Subject: Re: [tcpm] rfc5961 and suggested updates.


FWIW, that makes the most sense to me.



On Oct 4, 2018, at 9:42 AM, Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org> wrote:


Re:
 https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03

I would support the suggestion to publish these recommendations (for
per-connection rather than per-IP-address rate limiting) as an errata
to RFC5961.

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