IETF Logo Mail Archive

Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt

Joe Touch <touch@isi.edu> Mon, 23 May 2016 16:05 UTC

Return-Path: <touch@isi.edu>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF5E12B004 for <spud@ietfa.amsl.com>; Mon, 23 May 2016 09:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.325
X-Spam-Level:
X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 69V-yEsjaxRs for <spud@ietfa.amsl.com>; Mon, 23 May 2016 09:05:57 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 2B25E12D97D for <spud@ietf.org>; Mon, 23 May 2016 09:05:54 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u4NG5PMW018411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 May 2016 09:05:27 -0700 (PDT)
To: Phillip Hallam-Baker <phill@hallambaker.com>, Toerless Eckert <eckert@cisco.com>
References: <20160519175701.17290.47241.idtracker@ietfa.amsl.com> <CALx6S377qRfq7ufRVUx6Yn7ec4=EmK_=FL14PWT_qf4g840mbQ@mail.gmail.com> <20160519185943.GM12994@cisco.com> <CALx6S37qPpKpCT6ZpVQwRWf1XFKESYasOBcz26To9zw0GRyz5Q@mail.gmail.com> <20160519202134.GP12994@cisco.com> <CAMm+LwiPGgTyLqOtY21zo7M9ZRwQnH7CZg+j87YBiQqVXS+D1w@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <57432A45.7050608@isi.edu>
Date: Mon, 23 May 2016 09:05:25 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CAMm+LwiPGgTyLqOtY21zo7M9ZRwQnH7CZg+j87YBiQqVXS+D1w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040701000401040501070905"
X-MailScanner-ID: u4NG5PMW018411
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/P1rOlL39SH2db2UzJ0HpFqTj4dE>
Cc: Tom Herbert <tom@herbertland.com>, spud <spud@ietf.org>
Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2016 16:05:58 -0000


On 5/21/2016 9:21 PM, Phillip Hallam-Baker wrote:
>
>
> On Thu, May 19, 2016 at 4:21 PM, Toerless Eckert <eckert@cisco.com
> <mailto:eckert@cisco.com>> wrote:
>
>
>     TLS should not be attackable this way. Isn't this fixed in 1.3 ?
>     You don't want
>     to be a baby sitter for TLS. TLS has to be a standalone
>     babysitter. That why we
>     hired it ;-)
>
>
> There is nothing in TLS to stop it being attacked. All TLS can do is
> to prevent certain attacks from succeeding and it is only designed to
> prevent Confidentiality or Integrity attacks.
>
> TLS isn't at all good at stopping denial of service attacks. When an
> attack occurs, there isn't much that can be done apart from closing
> the socket and trying again. 
>
> If you want to add in robustness, you need to be able to detect which
> of your TCP packets were mangled and that really isn't possible in
> user space.

You can detect anything in user space that the OS allows access to,
including link, network, and transport errors.

If you delegate demuxing to the OS and don't have an override, then
*that* is what stands in your way, not any property of the Internet
stack or its protocols.

Joe

v2.23.0 | Report a Bug | By Email