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
> -------------------------------------------------------------------
>