Re: [nbs] [Int-area] New draft related to name-based sockets

[Mirja Kuehlewind <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> nbs mailing list
> [e-mail]
> 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: [phone]
email: [e-mail]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------