IETF Logo Mail Archive

Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-02.txt

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Thu, 16 April 2015 06:45 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DB71B2A42; Wed, 15 Apr 2015 23:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.215
X-Spam-Level: **
X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 KA1IjhksROY9; Wed, 15 Apr 2015 23:45:36 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE24C1B2A2A; Wed, 15 Apr 2015 23:45:35 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2E526278068; Thu, 16 Apr 2015 15:45:33 +0900 (JST)
Received: by wizk4 with SMTP id k4so182077863wiz.1; Wed, 15 Apr 2015 23:45:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.89.227 with SMTP id br3mr4894298wib.67.1429166730875; Wed, 15 Apr 2015 23:45:30 -0700 (PDT)
Received: by 10.194.41.167 with HTTP; Wed, 15 Apr 2015 23:45:30 -0700 (PDT)
In-Reply-To: <552F339A.3000605@mti-systems.com>
References: <20150415175805.17797.49699.idtracker@ietfa.amsl.com> <552EA990.5000207@isi.edu> <552F339A.3000605@mti-systems.com>
Date: Wed, 15 Apr 2015 23:45:30 -0700
Message-ID: <CAO249ydt0hSOfaOph0GQ1X0q3nP+-95usRGxo_dFp+kUCL08AA@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: Wesley Eddy <wes@mti-systems.com>
Content-Type: multipart/alternative; boundary="e89a8f23550f519b270513d1cf0b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpm/0x0nLLTtN3Biaf6GZ-rDzs4Yb9U>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, i-d-announce@ietf.org, internet-drafts@ietf.org, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-02.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 16 Apr 2015 06:45:37 -0000

Hi,

On Wed, Apr 15, 2015 at 8:59 PM, Wesley Eddy <wes@mti-systems.com> wrote:

> On 4/15/2015 2:10 PM, Joe Touch wrote:
> > It includes a variant that indicates the TCP segment length to detect
> > when coalescing that might interfere with EDO occurs.
>
> This is one thing that I think we particularly want feedback from
> the group on.
>
> I think it's a very low-impact way (compared to adding checksums,
> using AO, using IPsec, etc) in order to reasonably detect an
> accidental pollution of the user data due to resegmentation.
>

>> When an endpoint receives a segment using the 6-byte EDO
   Extension option, it MUST validate the Segment_Length field with the
   length of the segment as indicated in the TCP pseudoheader. If the
   segment lengths do not match, the segment MUST be discarded and an
   error SHOULD be logged in a rate-limited manner.


I am wondering if discarding a segment is safe enough.

Once resegmentation happens, I think we are not very sure how to recover it.

I guess it would be better to reset a connection.


Thanks,

--

Yoshi

v2.23.0 | Report a Bug | By Email