[nbs] New draft related to name-based sockets

RJ Atkinson <rja.lists@gmail.com> Wed, 08 December 2010 19:33 UTC

Return-Path: <rja.lists@gmail.com>
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 99EEC3A687D for <nbs@core3.amsl.com>; Wed, 8 Dec 2010 11:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, 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 3ifk3wrIWuse for <nbs@core3.amsl.com>; Wed, 8 Dec 2010 11:33:09 -0800 (PST)
Received: from mail-qy0-f170.google.com (mail-qy0-f170.google.com [209.85.216.170]) by core3.amsl.com (Postfix) with ESMTP id 68FF03A686A for <nbs@ietf.org>; Wed, 8 Dec 2010 11:33:09 -0800 (PST)
Received: by qyk10 with SMTP id 10so6410595qyk.15 for <nbs@ietf.org>; Wed, 08 Dec 2010 11:34:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=2JpI6LEraMeqmzu+ioTdwmcaRu8pcITSI5g/BK3xEto=; b=EevmtaRYvjxyn//br/bXeqsv3HKUam16pRmOw0pNH2ez9KtwY9G9CFPS9b+U6Im9u7 XxYZUE9HV1OGOz01JH3Wsm9b5KvPlKaMuzKKMLsmg/lDECHWFSPalwvcG+hbBncMDCsO M6RocQy02vJmAy3jlccWDGb4yJupcZDy2RBFU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=rtrAdypG7/fnYSCivO+qwy3TxEefUEncs5HS7Vmqf5QnUe4y/a/OAm0jMq7Kt//+cS XOazUkmncgW5JtUY26vIr1sKE1VVYAzeraefQhFphrgIlSey0ptxxGQ+ny5/tsmowA5g O1olQW/d647UEv5942Ldz93xci5Hf49ES/ymA=
Received: by 10.224.11.67 with SMTP id s3mr7473866qas.144.1291836877226; Wed, 08 Dec 2010 11:34:37 -0800 (PST)
Received: from vi-mhowell55.leclairryan.com ([38.103.42.150]) by mx.google.com with ESMTPS id m7sm571324qck.25.2010.12.08.11.34.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Dec 2010 11:34:36 -0800 (PST)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 8 Dec 2010 14:34:34 -0500
Message-Id: <EFD35F73-F924-4942-9B18-463251097887@gmail.com>
To: nbs@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Subject: [nbs] 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: Wed, 08 Dec 2010 19:33:10 -0000

Earlier, Pete McCann wrote:
> 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.

One can parse the sentence above in more than one way.
I'm not sure which meaning is intended.

With respect to the clause "which cause packets to go 
on the slow path or get dropped", perhaps some
clarification is helpful...

Many ISP folks tell me that their deployed IPv4 (and IPv6) 
routers have been configured to *ignore* the presence of 
IPv4 Options/IPv6 Optional Headers.  

The consequence of that configuration setting is that all
IP packets are forwarded fast-path and are NOT dropped.
These ISP folks tell me that more than 1 major IP router
vendor has shipped this configuration-knob/capability
for several years now -- and that it is widely deployed
(e.g. for performance/security reasons) at least in 
ISP backbone routers.

Another consequence of that configuration setting,
which (again) is reportedly widely deployed at present,
is that an IPv4 option is likely to be handled as a
"end-to-end" option rather than as a "hop-by-hop"
option.  Similarly, IPv6 Hop-by-Hop Options might well
end up being handled by the deployed IPv6 Internet as
if they were end-to-end options.

This has some impact on the potential uses for IPv4
options and IPv6 optional headers.

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


As outlined above, multiple router vendors have shipped silicon 
that is deployed widely in the Internet that can parse/parse-past 
IP options (e.g. as part of the implementation for the above
feature).  

That silicon is also used as part of packet processing
for any ACLs that might be configured (e.g., to allow TCP/80
but perhaps deny TCP/not-80).  Such ACLs work at wire
speed and are considered important by many ISPs and
end-sites.  Often, those ACLs are configured to drop any
packets that can't be parsed at wire speed.

The shim you propose appears to break that ACL capability,
and likely would cause your new packets to be dropped
by some router along the path from the sender, rather
than being carried along the whole path.

So one might want to consider alternative engineering
approaches.

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


I regret that I am not crystal clear what the quoted text 
just above means.

(Full Disclosure)
So out of an abundance of caution, and mindful of IETF IPR
disclosure rules, one might want to take a look at
US Patent 5,511,122 which might be related to what you
might be describing in the quoted text above.

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

That claim is not obviously true, at least with respect 
to the NBS concepts and scope that were presented at IETF 
in Beijing last month.  (I wasn't present in Beijing, 
but I have scanned the presentation slides and meeting minutes 
online.)  If one thinks it is true for some special case,
then it would be helpful to clarify.  Alternatively, perhaps
defining terms more precisely would clarify things.

> I'm very curious to have your feedback on the approach.

I'm quite happy to oblige.

Yours,

Ran