[nbs] New draft related to name-based sockets

[RJ Atkinson <[e-mail]>]

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