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

[Joe Touch <[e-mail]>]

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