Re: [nbs] [Int-area] New draft related to name-based sockets
Pete McCann <mccap@petoni.org> Fri, 10 December 2010 17:54 UTC
Return-Path: <mccap@petoni.org>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFC5628C0E5 for <nbs@core3.amsl.com>; Fri, 10 Dec 2010 09:54:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtdOzyd5N9oM for <nbs@core3.amsl.com>; Fri, 10 Dec 2010 09:54:37 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id F3D5128C0D9 for <nbs@ietf.org>; Fri, 10 Dec 2010 09:54:36 -0800 (PST)
Received: by wwa36 with SMTP id 36so3997980wwa.13 for <nbs@ietf.org>; Fri, 10 Dec 2010 09:56:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.47.19 with SMTP id s19mr2479817web.56.1292003766864; Fri, 10 Dec 2010 09:56:06 -0800 (PST)
Received: by 10.227.13.136 with HTTP; Fri, 10 Dec 2010 09:56:06 -0800 (PST)
X-Originating-IP: [64.53.131.166]
In-Reply-To: <201012101252.31660.mirja.kuehlewind@ikr.uni-stuttgart.de>
References: <AANLkTin4-uiFXoS9DaDWtTQartUb6DKEee+B8717odm5@mail.gmail.com> <72504C2E-CE17-4AE0-ACBC-E6BB4F002267@isi.edu> <AANLkTimmQ-HKJBpoqQCc9t1P=GFPFa8VojPTFh-D8Nay@mail.gmail.com> <201012101252.31660.mirja.kuehlewind@ikr.uni-stuttgart.de>
Date: Fri, 10 Dec 2010 11:56:06 -0600
Message-ID: <AANLkTi=nQH8fN3Ye7jn7SxEbs3jA0d12hAMp9fhasFML@mail.gmail.com>
From: Pete McCann <mccap@petoni.org>
To: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: nbs@ietf.org
Subject: Re: [nbs] [Int-area] New draft related to name-based sockets
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Dec 2010 17:54:39 -0000
Thanks, I will get in touch with him. I followed along with his slides remotely during his presentation in Beijing but I also don't recall seeing any test results about SYN payloads. I suspect they moved on after deciding to put most of their new information elements into TCP options. -Pete On Fri, Dec 10, 2010 at 5:52 AM, Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de> wrote: > Hi Pete, > > as far as I remember they also tested SYN packets with payload in the > Middlebox survey of Michio Honda. I couldn't find those results in the slides > he presented at the last MPTCP meeting, but maybe just contact him. > > Mirja > > > On Thursday 09 December 2010 04:43:16 Pete McCann wrote: >> Hi, Joe, >> >> Thanks - can you elucidate or send a pointer to the issues with >> putting data in the SYN? Are you worried that some middleboxes >> will have problems and drop such packets? >> >> I'd be particularly interested if you can point me at some of these >> prior proposals. >> >> -Pete >> >> On Wed, Dec 8, 2010 at 8:48 PM, Joe Touch <touch@isi.edu> wrote: >> > Hi Pete, >> > >> > Sorry - you said transport payload, which - in hindsight - is ambiguous. >> > >> > First, as my old portnames ID explained, the strings need only be in the >> > SYN. Using the data in the SYN for options has been proposed before, and >> > there are many known issues. >> > >> > FYI. >> > >> > Joe >> > >> > On Dec 8, 2010, at 8:38 PM, Pete McCann <mccap@petoni.org> wrote: >> >> Hi, Joe, >> >> >> >> I understand that ports are in the transport header. >> >> >> >> The shim I am proposing goes *after* the transport header and >> >> provides an encapsulation for the transport payload. That way, >> >> middleboxes see what looks like a standard IP/TCP header, >> >> followed by a payload which contains the new stuff. Think of >> >> it as a way to get a lot of new options space without confusing >> >> any of the middleboxes (unless they do try to parse beyond the >> >> transport header like a "transparent" HTTP proxy. The new stuff >> >> I am proposing would confuse those kinds of boxes). I only say >> >> "not backwards compatible" because both endpoints need to be >> >> upgraded to support the new extensions. Middleboxes that have >> >> not been upgraded shouldn't care; it looks like standard TCP or >> >> UDP to them. I agree that defining a new transport protocol is >> >> a non-starter in today's deployed IPv4 network. I think there will >> >> always be only TCP, UDP, and maybe ICMP (the latter shouldn't >> >> be trusted anyway) so I'm essentially trying to layer on top of them. >> >> >> >> I know the choice of a DNS TXT record for public keys is controversial, >> >> but it is very similar to the approach taken for DKIM which has been >> >> quite successful. The problem with new record types is that you have >> >> to wait for all the servers and their configuration interfaces to >> >> support them. >> >> >> >> -Pete >> >> >> >> On Wed, Dec 8, 2010 at 3:50 PM, Joe Touch <touch@isi.edu> wrote: >> >>> Hi, Pete, >> >>> >> >>> This seems a little backwards. The port is in the context of the >> >>> transport protocol, but if it's in the shim between IP and TCP it is - >> >>> at best - a parameter to IP, not the transport (TCP, UDP, or other). >> >>> >> >>> Using a transport other than TCP or UDP also puts it on the slow path >> >>> (or just blackholes it) for anything that looks beyond the IP header, >> >>> too. >> >>> >> >>> As to where to put public keys, there's an RFC regarding reasons not to >> >>> use TXT records for new DNS capabilities you might want to dig up >> >>> (sorry - I'm in the airport and can't find it quickly - it was written >> >>> by the IAB I think). >> >>> >> >>> Joe >> >>> >> >>> On 12/8/2010 9:21 AM, Pete McCann wrote: >> >>>> I've uploaded a new draft relevant to the name-based sockets >> >>>> discussion and several others that have been going on in the >> >>>> Internet Area and elsewhere: >> >>>> >> >>>> https://datatracker.ietf.org/doc/draft-mccann-picklepacket/ >> >>>> >> >>>> It describes a framework for putting DNS names into transport >> >>>> packets that is a bit different from the approaches I've seen >> >>>> advocated on the NBS list. For one thing, I wanted to work >> >>>> with IPv4 as well as IPv6, which means avoiding all IP options >> >>>> which cause packets to go on the slow path or get dropped. >> >>>> The TCP options space is too limited for carrying DNS names, >> >>>> let alone the extra authentication payloads that I wanted to >> >>>> put there. So, I'm proposing essentially extending the transport >> >>>> options space in a non-backwards compatible way by shimming >> >>>> in a magic number where the transport payload would normally >> >>>> go. This would apply to UDP as well. I've defined a new header >> >>>> which I think is relatively compact yet provides all the flexibility >> >>>> we need, and a TLV format for carrying the DNS names and >> >>>> public-key authentication tags. I'm proposing to put public keys >> >>>> into DNS TXT records so that they can be retrieved by middleboxes >> >>>> that want to verify the transport connections passing through them. >> >>>> Also, middleboxes can add their own names and authentication >> >>>> tags, which allows them to make themselves known to the endpoints. >> >>>> This enables them to be used as mobility anchor points in case the >> >>>> path changes. >> >>>> >> >>>> The focus of the introduction is on preventing denial-of-service >> >>>> attacks but I think the protocol has many other useful features. >> >>>> Names can be used to route connections such as multiple servers >> >>>> sitting behind a NAT all on the same port. Routing on names does >> >>>> require some state to be kept in the middleboxes if we don't want >> >>>> to put DNS names into every packet. So, I'm proposing that each >> >>>> middlebox choose a 32-bit cookie value that it can use to index the >> >>>> flow state. These cookies get distributed in the same round-trip as >> >>>> the initial transport connection setup. >> >>>> >> >>>> I'm very curious to have your feedback on the approach. There is a >> >>>> lot of stuff in the draft and the protocol is rather heavyweight, but >> >>>> I think it addresses a lot of different themes that I've seen being >> >>>> discussed in different working groups (TCP Auth Option, MPTCP, >> >>>> NBS, MEXT, DKIM, KEYASSURE, etc). >> >>>> >> >>>> -Pete >> >>>> _______________________________________________ >> >>>> Int-area mailing list >> >>>> Int-area@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/int-area >> >> _______________________________________________ >> nbs mailing list >> nbs@ietf.org >> https://www.ietf.org/mailman/listinfo/nbs > > > > -- > ------------------------------------------------------------------- > Dipl.-Ing. Mirja Kühlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart > > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- >
- [nbs] New draft related to name-based sockets Pete McCann
- [nbs] New draft related to name-based sockets RJ Atkinson
- Re: [nbs] New draft related to name-based sockets Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] New draft related to name-based sockets Javier Ubillos
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Mirja Kuehlewind
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch
- Re: [nbs] [Int-area] New draft related to name-ba… Pete McCann
- Re: [nbs] [Int-area] New draft related to name-ba… Joe Touch