Re: [Udp35] TAPS BOF and moving the transport API forward

Eliot Lear <lear@cisco.com> Mon, 26 May 2014 17:39 UTC

Return-Path: <lear@cisco.com>
X-Original-To: udp35@ietfa.amsl.com
Delivered-To: udp35@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F8B1A01EB for <udp35@ietfa.amsl.com>; Mon, 26 May 2014 10:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.152
X-Spam-Level:
X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 WlCbuu9_SOBU for <udp35@ietfa.amsl.com>; Mon, 26 May 2014 10:39:06 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2A21A0146 for <udp35@ietf.org>; Mon, 26 May 2014 10:39:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1017; q=dns/txt; s=iport; t=1401125943; x=1402335543; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fgwLooy3SpfE12GZMuxWL+KirJVgH3QEN+blQ7ODofg=; b=coRUwwMujy09k0ecLI9yAjmVM/vNjpNRamRwVQG+NJZgrNkI+YQwP7+b Cbm1B2fFVF6d5BpywjefI3ntQ0h7hx+KOTJkSh6B4ynwBo2EmQlbmNHxy dzzwR1Y3YDdT9F3N7Dgw2lVpeB0UG2Jjua1yDCDDHOCs2Emj+AkdA+Q4X A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIEAIl7g1OtJssW/2dsb2JhbABZDocNvyYBgSt0giUBAQEEI1YQCw4KAgIFIQICDwJGBgEMAQcBAYg+rx+lYheBKo0oB4J1gUsBA5lzkyeCeEI7
X-IronPort-AV: E=Sophos;i="4.98,914,1392163200"; d="scan'208";a="59250767"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 26 May 2014 17:39:01 +0000
Received: from ELEAR-M-C3ZS.CISCO.COM (ams3-vpn-dhcp6985.cisco.com [10.61.91.72]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4QHd0NB006589; Mon, 26 May 2014 17:39:00 GMT
Message-ID: <53837C33.80209@cisco.com>
Date: Mon, 26 May 2014 19:38:59 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Brian Trammell <ietf@trammell.ch>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
References: <537B6932.9050809@erg.abdn.ac.uk> <537BA5CF.4000602@gmail.com> <2f67fd4139a3a40a2df96f1e7db57a95.squirrel@www.erg.abdn.ac.uk> <537DD281.5030408@gmail.com> <A8BF265F-DAEB-426C-9616-0A60AAD6A35F@ifi.uio.no> <966E90E6-5DD3-4897-8891-9ABBB3203274@trammell.ch> <AF068429-8094-4558-9038-A443377B02DD@ifi.uio.no> <8EC8A658-5FA9-464B-8B09-6D3A94222B13@trammell.ch> <6B4A2FF8-E4BA-4355-B792-F99D8970D9C8@ifi.uio.no> <A2BE43E7-5635-4CA2-9F3A-9CEFD277F283@ifi.uio.no> <64EA69DB-0643-4485-84B6-7440533878E2@trammell.ch> <9c49932c616d4c5ae7195ad035874b82.squirrel@www.erg.abdn.ac.uk> <D2D82A97-5892-45D2-B703-8AA8B5AF071F@trammell.ch>
In-Reply-To: <D2D82A97-5892-45D2-B703-8AA8B5AF071F@trammell.ch>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/udp35/yWyKi0qATKXXn1HVD3yjoZ8b0f4
Cc: Martin Stiemerling <mls.ietf@gmail.com>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, Michael Welzl <michawe@ifi.uio.no>, udp35@ietf.org
Subject: Re: [Udp35] TAPS BOF and moving the transport API forward
X-BeenThere: udp35@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Life beyond UDP <udp35.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/udp35>, <mailto:udp35-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/udp35/>
List-Post: <mailto:udp35@ietf.org>
List-Help: <mailto:udp35-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/udp35>, <mailto:udp35-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 17:39:07 -0000

Hi,

On 5/26/14, 5:48 PM, Brian Trammell wrote:
>
>
> (2) We need to look into ways we can rescue "roll-it-yourself over UDP" from creeping middlebox breakage. Happy/angry* eyeballs is one approach here, but there may be things that can be done in a UDP shim layer that can help too.

Perhaps I misunderstand, but IMHO angry eyeballs requires that there be
the UDP way and The Better Way<tm>.  I have my own definition of The 
Better Way, which includes among other things, NAT friendliness,
directionality detection, and something that doesn't need a blasted UDP
header.  Security in the transport layer (as opposed to TLS) would be a
really cool nice-to-have, as well.

The reason this doesn't simply fit into the Department of Obvious Things
To Say is that it's all about middle boxes, and finding the appropriate
characteristics they feel comfortable both implementing and allowing to
be deployed (e.g., directionality and (don't choke) NAT friendliness
probably being a requirement).

Eliot