IETF Logo Mail Archive

Re: [tcpinc] Revised version of TCP-ENO

Martin Thomson <martin.thomson@gmail.com> Fri, 14 August 2015 18:15 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D3B1A00F5 for <tcpinc@ietfa.amsl.com>; Fri, 14 Aug 2015 11:15:11 -0700 (PDT)
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, SPF_PASS=-0.001] autolearn=ham
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 ADM2Li7OwCk3 for <tcpinc@ietfa.amsl.com>; Fri, 14 Aug 2015 11:15:10 -0700 (PDT)
Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 462581A00E5 for <tcpinc@ietf.org>; Fri, 14 Aug 2015 11:15:10 -0700 (PDT)
Received: by ykbi184 with SMTP id i184so11558610ykb.2 for <tcpinc@ietf.org>; Fri, 14 Aug 2015 11:15:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Al9lTBvwWzJ+/HhwB09fFgFcNIYXb1Qi3cXK5UKo3HE=; b=aDi/uBCw3KPTqn/MI2zS5lZmO2dhj+62KMmRngUsd5yKYMu2FqybwW8IpkOyx8ISx+ nXYToHgDJaANfreC298ar7ix0JuZhxkavTdgqiZER8iB5VHaPldRu9Qfz3MMrhUtnslT PtkLlOcAniCjamj8wuPt0WYLN2Eip6uy5uzoM6hUb/rpyu2Io5ZQeiZDyeelJj9DR5s/ 3gIhicDklBdIyfG8frhUWePmQtocYOkGs1oJUcwQoG+8yAIRh4GpvhxucyJe9YJQtEvd wltwvx1nM8XOpWfD5uiM8WS0InxBh96+d6/FtLjaZ0Y3KXi+pnsvUuacmpmV9TffO0+J IMoA==
MIME-Version: 1.0
X-Received: by 10.129.103.5 with SMTP id b5mr27084472ywc.55.1439576109683; Fri, 14 Aug 2015 11:15:09 -0700 (PDT)
Received: by 10.129.22.211 with HTTP; Fri, 14 Aug 2015 11:15:09 -0700 (PDT)
In-Reply-To: <874mk1wxs5.fsf@ta.scs.stanford.edu>
References: <87pp2vqplu.fsf@ta.scs.stanford.edu> <CAJU8_nXAHhf6dqqs0gUEGz49bG7YUO1qaGwaLm04+vstPTyfWg@mail.gmail.com> <87h9o4rqwz.fsf@ta.scs.stanford.edu> <874mk2kj56.fsf@alice.fifthhorseman.net> <CAJU8_nVcDmCw-0KYviJ5GWZL+-YcCg3wLMJqpkuh=iN8RppA+A@mail.gmail.com> <87y4hej2vf.fsf@alice.fifthhorseman.net> <87egj67sac.fsf@ta.scs.stanford.edu> <87bnea7rr6.fsf@ta.scs.stanford.edu> <CABkgnnUF-byT2MH8mrmZJaMY2PTsspWJ8W3wJmddXdgMqGHCkQ@mail.gmail.com> <87614i7o2l.fsf@ta.scs.stanford.edu> <CABkgnnU8eeX3QV+D_g2XJqWGf9YzUZ1v-eqjg9HsioGJP8-GqQ@mail.gmail.com> <87io8hwznh.fsf@ta.scs.stanford.edu> <CABkgnnXDomgQJSiCTdxETomPB7H+n2DggZ4VX0Q8hpqvoyq=8A@mail.gmail.com> <874mk1wxs5.fsf@ta.scs.stanford.edu>
Date: Fri, 14 Aug 2015 11:15:09 -0700
Message-ID: <CABkgnnXo67ZM9Qa0-rHdNty1ewaGnn8G30Fn2WQZh6fh9-0KvA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: David Mazieres expires 2015-11-12 PST <mazieres-cngu297sbd6fa7ssnjevzpq9vi@temporary-address.scs.stanford.edu>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/7YUEDeeVNMdC7NLKBiQyt-QdB0I>
Cc: tcpinc <tcpinc@ietf.org>
Subject: Re: [tcpinc] Revised version of TCP-ENO
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2015 18:15:11 -0000

On 14 August 2015 at 11:05, David Mazieres
<dm-list-tcpcrypt@scs.stanford.edu> wrote:
> If we don't specify requirements for the session ID, then applications
> will have to be knowledgeable about what encryption spec they are using.
> That means if we get large SYN options down the line and massively
> optimize TCPINC, applications won't be able to take advantage of it
> automatically.


Sorry, I missed an important word.  I have *no* problem with
specifying requirements; I just have a problem with specifying
mechanism with a requirement for that mechanism.

If you look at this in the abstract, how the session ID is acquired
and defined can (and should) be opaque to an application using this.
At some level, the requirement you want is an API one: the application
MUST be able to acquire an identifier that is unique for the session.

Also, given the other discussion, perhaps the model in RFC 5705 is the
right one to use: don't expose a unique id, but provide an application
the ability to extract a value, with the limitation that it be
specific to that application.

v2.23.0 | Report a Bug | By Email