Subject: [nbs] New draft related to name-based sockets

From: RJ Atkinson <[email-masked]>
Date: Wed, 8 Dec 2010 14:34:34 -0500

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

---

From: Pete McCann <[email-masked]>
Date: Wed, 8 Dec 2010 14:03:32 -0600

Hi, Ran,

Thanks for the responses... some replies inline.

> I'm not sure which meaning is intended.

Sorry.  My chain of reasoning was "IPv4 options cause
packets to travel the slow path or get dropped"
^ "want a solution for IPv4"
==> "don't use IPv4 options".

> IPv4 Options/IPv6 Optional Headers.

That would certainly avoid the slow path/drop problem
if true, but recent mails to the list seem to indicate that
this configuration is not common enough to prevent
problems:

http://www.ietf.org/mail-archive/web/int-area/current/msg02361.html

Also, the IPv4 options space is simply not big enough
to hold the data elements that I am contemplating.

> than being carried along the whole path.

The shim is actually where the transport *payload* would
be, and the transport *header* is completely unaffected.
This means that unless the ACL were configured to look
inside transport payload for the new magic number, there
would be no detectable difference between these packets
and normal transport packets.

One thing that might break are TCP proxies that assume
that a packet with the same sequence number must have
the same payload.  In the draft, it is assumed that sequence
numbers track the actual transport payload and are not
incremented to account for the new DNS name TLVs.
In most cases, this will lead to the same sequence numbers
being re-used for packets which apparently have different
transport payload.  But, if we are dealing with middleboxes
that munge that deep into the packets it seems there is
almost no hope to deploy new mechanisms.

> I regret that I am not crystal clear what the quoted text

Please read section 4.1 of the draft.

> might be describing in the quoted text above.

IANAL so can't comment on the above.

> defining terms more precisely would clarify things.

The assumption was: if we put names into the first few packets
of a transport connection, and use those names somehow to
choose the next hop of a packet (possibly after doing some form
of NAT), then to ensure that subsequent packets in the same
connection go to the same place we need to at least remember
the IP and transport port numbers; that is, unless we put the DNS
names into every packet of the flow.  In case we want multiple
services to reside behind the same IP address and port it would
seem to require a new identifier on which to demultiplex.  Hence
the "cookie" mechanism described in the draft.

> I'm quite happy to oblige.

Thanks again, please do read the draft and let me know if
you still have questions after that.

-Pete

---

From: Javier Ubillos <[email-masked]>
Date: Thu, 09 Dec 2010 13:13:19 +0100

> defining terms more precisely would clarify things. 

In the case where you _want_ middleboxes to make decisions based on
names:

I don't see how you can route, or make any decision based on something
that is not present, unless you have saved some state allowing you to
deduce that non-present thing.

Either you attach the name on every packet, or, the middlebox needs to
store some association.

This problem goes away if we are not intending the names to be something
middleboxes should route/make decisions on.

I like both approaches and am happy to explore them both.

// Javier