Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS

Ian Swett <ianswett@google.com> Sun, 11 December 2016 17:08 UTC

Return-Path: <ianswett@google.com>
X-Original-To: plus@ietfa.amsl.com
Delivered-To: plus@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE3F1296A2 for <plus@ietfa.amsl.com>; Sun, 11 Dec 2016 09:08:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.596
X-Spam-Level:
X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2-Sm4LOMTcVo for <plus@ietfa.amsl.com>; Sun, 11 Dec 2016 09:08:39 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 D6D641293FF for <plus@ietf.org>; Sun, 11 Dec 2016 09:08:39 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id r204so49115003ywb.0 for <plus@ietf.org>; Sun, 11 Dec 2016 09:08:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RIj5nFLeUygoN1YGpNbogUnZlGQdd+Nc5ziKVHAiilM=; b=UXPkIDhY9EmNqzWzu5ggtMfSJmqgFG4kEo1xpjp90LK5vDO4oPJqGOn32gHKgb9ziQ 757KSO6gkg2WE5M+fCRyEOVMzQ44DqXHVY4inQBtLAo6V4rWWLiPh2P2vPBJeuEqKZnK 2hVc8I5vUSQ6AGbrHS/Ql3CwY2s3UrQZiLLBtd+p2seD6qSYGzJAmIixOO4wb+NEvbFP d7XY/xKJedgAv6OlmQKU7bJcCPPHdq+geMFoQezOASQ4qaAnBIkhPJb+g1enLTkG8k7h tcPL2IEneZH6Kiubvh3w+KafwAoV2569PwW7xfddTcGtsU3THoNIEKzw6oX+oFqVDGRv OCnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RIj5nFLeUygoN1YGpNbogUnZlGQdd+Nc5ziKVHAiilM=; b=L8qThOasy+WFdkbgt79oLfJ9yO9XClZ9Zzc0T2j3uxSZXrQ7g7tlJ93yhREn1X9sfV Wjddui6mKff4VQdMVkrHbGSDPNdJUGY83QWpqQQ72lzPUcFMQi+rhaGN7dVnmz8JjZKm 8d/e3m2Z0tOPibXe5w3FZrKj2ZQoMCoM8hA32yvnWclZ0TeM5iZjEVDGGTqXjdYlH78i rdGFIe8ihzaLoCsiq1n3AjpUzcTXawsXbPvAA3VIs8PfXaGjMLgVSxGejzuj3SmOr6uQ LmvpHnJfL96IFdBfEdCszkvKuEUYiB784jWDD1gk70JHqO4vJRVEDREqTI7VUwqpZYJP tNSQ==
X-Gm-Message-State: AKaTC02QwfzcUz17Vu0oE0Z2xREiMfRREFeLi/d96y1ihgzOH1iwNh/QQS9OyE2BPnc+UA8EIZNsGEYJJ2xKaUJF
X-Received: by 10.129.117.215 with SMTP id q206mr90944437ywc.143.1481476118931; Sun, 11 Dec 2016 09:08:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.4.88 with HTTP; Sun, 11 Dec 2016 09:08:18 -0800 (PST)
In-Reply-To: <003801d253ce$35b13520$a1139f60$@huitema.net>
References: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> <CAKcm_gMzw9Z=XnFy9vYfxOOG+eO6XJ2bSNeboQYjxW+MOUwa9g@mail.gmail.com> <E4BB21D8-9747-409C-BCF7-E62029897282@apple.com> <02ec01d25378$83799550$8a6cbff0$@huitema.net> <CAKcm_gPHUQ-EYrC1SHEXj6vpSMdEqmqZufdWLpxJxnVLZ0ZwYg@mail.gmail.com> <003801d253ce$35b13520$a1139f60$@huitema.net>
From: Ian Swett <ianswett@google.com>
Date: Sun, 11 Dec 2016 12:08:18 -0500
Message-ID: <CAKcm_gM7sHEGPkPD8HZHEgFiDfWZqUY3W8L4yGiUVMrFoehE1Q@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Content-Type: multipart/alternative; boundary=001a1147f9ced07ce505436509b2
Archived-At: <https://mailarchive.ietf.org/arch/msg/plus/xgyJlsOh6bNjylKC4Zz08XZiHxc>
Cc: Brian Trammell <ietf@trammell.ch>, Tommy Pauly <tpauly@apple.com>, plus@ietf.org
Subject: Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS
X-BeenThere: plus@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." <plus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plus>, <mailto:plus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/plus/>
List-Post: <mailto:plus@ietf.org>
List-Help: <mailto:plus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plus>, <mailto:plus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Dec 2016 17:08:41 -0000

Good point, though they'd only know it afterwards.  At which point the
connection would be torn down.

I'm not sure it's critical the receiver is unaware they're being tested or
not.  And if the connection is suddenly torn down, presumably they'll
realize they were being tested anyway?

On Sun, Dec 11, 2016 at 11:47 AM, Christian Huitema <huitema@huitema.net>
wrote:

> On Sunday, December 11, 2016 6:51 AM, Ian Swett wrote:
> > On Sun, Dec 11, 2016 at 1:33 AM, Christian Huitema <mailto:
> huitema@huitema.net> wrote:
> >> ...OTOH, there is going to be a "feature interaction" between this
> sequence+echo scheme and
> >> the senders' strategy of skipping some sequence numbers in order to
> verify that the recipients
> >> are not making up ACKS. The intermediate boxes will have no way to
> distinguish between a
> >> packet number voluntarily skipped by the sender, and a packet loss
> between the sender and
> >> the middlebox. I hope this won't affect the "wireshark diagnostics" too
> much.
> >
> > We could specify that if a peer wants to skip packet numbers, it should
> be by more than 256,
> > assuming 256 packet gaps are rare(which they are, though they do
> happen).    Or some other
> > known approach that is relatively simple to identify.
>
> If you make it easier to identify, then you defeat the purpose of the
> packet skipping. Suppose a bad receiver, intent on setting a DOS attack.
> Its strategy is to ACK as quickly as possible, regardless of losses. The
> sender detects ACK of packets that were not sent, and aborts the
> connection. But if the skipping is easy to detect by middleboxes, it is
> also easy to detect by the bad receiver, which will suspend its ACK
> everything strategy if it detects a test...
>
> -- Christian Huitema
>
>
>
>
>