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

[Pete McCann <[e-mail]>]

Hi, Ran,

Thanks for the responses... some replies inline.

On Wed, Dec 8, 2010 at 1:34 PM, RJ Atkinson <[e-mail]> wrote:
> 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.

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

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

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.

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

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

Please read section 4.1 of the draft.

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

IANAL so can't comment on the 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.

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 very curious to have your feedback on the approach.
>
> 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