Subject: Re: [nbs] NBS and TCP connection identification

From: Erik Nordmark <[email-masked]>
Date: Fri, 01 Oct 2010 09:02:51 -0700

On 09/27/10 03:20 PM, Christian Vogt wrote:

> a way to secure IP address changes without the help of Shim6 would be the following:
>
> - Exchange a randomly generated token at the old IP address.
>
> - Verify the peer's knowledge of this token at the new IP address.
>
> - Upon successful verification, associate the peer's new IP address with the peer's DNS name, which happens to encode the IP address that the peer had used during session initiation.
>
> This procedure would be very similar to the Mobile IPv6 care-of address check.

Explain to me how that can be used to secure the binding between the 
*name* and an IP address.

I understand the Mobile-IP approach to secure a binding between two IP 
addresses, but that isn't the problem that NBS needs to solve.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 01 Oct 2010 09:37:31 -0700

On 09/23/10 07:19 AM, Javier Ubillos wrote:

> Ok, I see your point.
> I'm going to try to make some time to describe this bit better.
> I'll have to get back to you on it.
> I think the threat analysis is a good case for a potential WG.
>
> One option could be
> Drop the resolution on the responder side.
> Let the TCB creation be limited in the same way(s) as for 'normal IP'.
> Hence, do not imply anything with the name other than as a session
> identifier.
> Later on, when some feature requires some authentication of the name (as
> proposed in draft-xu-name-shim6-00), authentication (resolution) is done
> out-of band.
>
> Consequences:
> No blocking or delaying resolution.
> No security initially, simply a session identifier.
>
> Does this make sense?

Somewhat, but there are two parts to it; what do things look like at the 
API, and how would TCP work.

If we look at the API, in the case when the application doesn't ask for 
the name (i.e., no name returned in accept, getpeername, or recvfrom) 
then clearly from the application's perspective there isn't any need to 
verify the binding of the name.

However, if the peer is using NBS and the application does ask for a 
name at the API, should that trigger a name verification? The 
alternative would be to return a name like 81.228.146.129.in-addr.arpa, 
which the application can at least use to return traffic back to the 
peer. One could envision a way to have the application specified whether 
it wants a .arpa name, or a verified 'bob.example.com' name back.

But none of that helps TCP AFAICT.

When a SYN arrives from 129.146.228.81 with a name bob.example.com, I 
think the intent is to have the TCB be associated with name name (or 
some hash of it). Is that correct?

If TCP complex the SYN exchange without any verification of the peer's 
name you'd end up with a TCB with
	remote name: bob.example.com
	remote port: 123
	remote locators: 129.146.228.81
	local name: foo.example.net
	local port: 80

Suppose we know receive a SYN from port 123 and some other IP address, 
and also claiming to be bob.example.com.
What should TCP do?

> I am hesitant to solutions that infer delays in the connection setup.

Some perspective on this might be useful.
Depending on who you ask you find that the community has thought about 
or worked on id/locator separation for 30 years, or merely 15 years.

As we've discussed this radical change to the architecture, much of the 
feedback is around "you can't change X", where different folks are 
concerned about different values of X. The result is that we haven't 
changed anything, and as a result we've made no progress.

It is pretty clear to me that if we want some form of id/locator 
separation architecture, then some things will change. We definitely 
have to be cognizant of this and understand the tradeoffs, but starting 
off with "we can't change X" for any value of X isn't likely to be a 
good approach.

 From what I understand from folks at Google a significant part of the 
"connection setup" is actually the DNS lookup, and for the case of a web 
browser doing lots of connections there are approaches to 'prefetch' and 
parallelize that part. Potentially similar approaches can be applied if 
there is a need to do some validation or other exchanges in an 
id/locator system.

    Erik

---

From: "David Harrington" <[email-masked]>
Date: Fri, 1 Oct 2010 14:38:15 -0400

Hi,

I am now the Responsible AD for this BOF. 
Let me just inject some guidance which will help the proponents
prepare for the BOF.

I am in the process of finding chairs for the BOF. I am trying to
locate two people with good IETF process knowledge and experience, to
organize/run the BOF. I have sent requests to the TSV Directorate and
the TSV chairs. I am also open to other volunteers. I have
deliberately avoided the leading technical proponents like Christan
and Javier because I want them to be able to focus on their proposals
and the technical feedback they get from the list, not BOF
organizational issues.

If anybody on this list has not yet read "Considerations for Having a
Successful Birds-of-a-Feather (BOF) Session" (RFC5434) I recommend you
do so. Some of this information is most relevant for the chairs, but
it would help the chairs if the other proponents involved understand
what the chairs are trying to accomplish.

The IESG and IAB think some of the proposals are worthwhile but are
not yet convinced the industry would implement and deploy such
standards, and are not yet convinced some other aspects of the
proposed work are justified by its benefits, achievable within the
IETF, and deployable in a reasonable timeframe. We are looking for
feedback from the community on these proposals, and their support for
such work.

>From my perspective, given the feedback from the IESG and IAB, I do
not see a WG being formed after Beijing. If the BOF in Beijing is
successful at demonstrating community interest and and understanding
of the problems to be solved, a second BOF will likely be needed to
develop a well-focused charter with achieveable milestones to create a
WG.

The goal of the BOF is to demonstrate that the community has agreement
that:

      - there is a problem that needs solving, and the IETF is the
right
        group to attempt solving it.

      - there is a critical mass of participants willing to work on
the
        problem (e.g., write drafts, review drafts, etc.).

      - the scope of the problem is well defined and understood, that
        is, people generally understand what the WG will work on (and
        what it won't) 

      - there is agreement that the specific deliverables (i.e.,
        proposed documents) are the right set.

	- that the industry would be likely to implement and deploy
the specific deliverables.

	- that the migration from existing deployed technologies to
the proposed new technologies
	  is manageable. I recommend reading "What Makes For a
Successful Protocol?" (RFC 5218).

Of lesser importance (but not unimportant) for this BOF:

	- having a fully-detailed and word-perfect charter 

	- what the actual deliverables will be (i.e., how many drafts
and what each will contain)

      - it is believed that the WG has a reasonable probability of
        having completing the deliverables in its charter in a timely
fashion). 
	  Don't worry too much about defining specific milestones, but
you should provide
	  estimates for whether a deliverable will take 1 year, 3
years or 5 years to finish.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

---

From: Christian Vogt <[email-masked]>
Date: Mon, 4 Oct 2010 17:55:19 -0400

Erik wrote:

> Explain to me how that can be used to secure the binding between the *name* and an IP address.
> 
> I understand the Mobile-IP approach to secure a binding between two IP addresses, but that isn't the problem that NBS needs to solve.

Erik:

My email above was on verifying an address update, not on verifying a name-to-address binding.  I envision the latter to be secured in one of the following ways:

(1) The recipient operating system verifies the initiator's name by means of a forward DNS lookup.  If and only if the initiator's name is correct, it is delivered to the recipient application.  In an overload situation, the recipient operating system may instead deliver an address-derived DNS name to the recipient application.  This can serve as an identifier for the initiator throughout the session, even across address changes.

(2) Like (1), but with DNSSEC instead of DNS.  Whether to use DNSSEC is a local deployment question.

(3) The recipient operating system always delivers an address-derived DNS name for the initiator to the recipient application.  The recipient application can be provided with an API function to discover the initiator's true name, and have this verified, if so desired.

(4) The recipient operating system always delivers the initiator's name without verification to the recipient application.  The recipient application can be provided with an API function to have the initiator's name verified, if so desired.

What would be your preference among (1) through (4)?  I would be interested in your opinion.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 4 Oct 2010 18:30:45 -0400

Erik:

You are right.  We should be clear on what will change, and what does not have to change.

And I think the plan is fairly simple:  Operating system vendors will take on the burden, since they will need to add name-based sockets to their operating systems.  But they will be incentivized:  Name-based sockets will simplify application development, which has always been an objective of operating system vendors.

Once operating systems support name-based sockets, we are good.  Of course, we want applications to adopt the new API -- and they eventually will because this will make the life of application developers simpler.  But there is no time pressure.

Finally, we won't change routers, neither will be require new infrastructure.

- Christian

---

From: Rémi Després <[email-masked]>
Date: Tue, 5 Oct 2010 10:08:27 +0200

Hi Christian,

Sorry for so late an answer.
More below.

Le 29 sept. 2010 à 20:47, Christian Vogt a écrit :

> 
> Remi wrote:
> 
>> In my understanding NBS and address changes can remain independent, and therefore should remain so.
>> - A connection initiation starts with the source and destination names chosen by the initiator (and with valid addresses for them at that time).
>> The acceptor advertises at the NBS the names it received.
>> It may have before that checked, with a direct a DNS query, that source address and source name are consistent, or do it after signaling the incoming connection, or never, at its own choice. 
>> - Shim6, if present, works as before.
>> 
>> Does this make sense to you?
> 
> 
> I think it does.  So let me summarize:  
> 
> You are proposing that the responder should present the initiator's name as received to the responding application, without verification.  It is then up to the responding application to verify the initiator's name if needed.  Correct?

To be more precise, the proposal could be:
- For backward compatibility, the API permits the application to indicate whether or not it wants, for incoming connections, names at the API (by default, it doesn't).
- If it does, it also indicates whether it wants name-address consistencies, for sources and/or destinations, to be checked BEFORE or AFTER signaling the incoming connection at the API.
- For source names that are are provided in connection-initiating packets, direct DNS lookups are sufficient. Otherwise, reverse lookups are necessary.

RD

> Needless to say, if the initiator does not provide a name -- e.g., because it does not have a name registered in the DNS --, the responder would generate a name for the initiator based on the initiator's IP address.  Such a "synthesized" name does not have to be verified; it already provides the same level of security that we have today.

It isn't clear to me that synthesized names are needed. 
NBS APIs could instead continue to provide, in their binary format, addresses found in session originating packets, and let application ignore them if they aren't interested.

> 
> Is this summary accurate?
> 
> - Christian
>

---

From: "David Harrington" <[email-masked]>
Date: Tue, 5 Oct 2010 07:21:00 -0400

Hi,

If consensus is that this is the goal, then the BOF should have
participation from OS vendors indicating an interest in taking on this
burden. 

The BOF will also need to explain why this work belongs in IETF,
rather than in other SDOs.

Christian's paper proposed changes to protocols, such as transport
protocol handshakes.
The BOF should explain in detail how the changes proposed would happen
only on hosts, not on routers, switches, etc.

dbh

> And I think the plan is fairly simple:  Operating system 
> vendors will take on the burden, since they will need to add 
> name-based sockets to their operating systems.  But they will 
> be incentivized:  Name-based sockets will simplify 
> application development, which has always been an objective 
> of operating system vendors.
> 
> Once operating systems support name-based sockets, we are 
> good.  Of course, we want applications to adopt the new API 
> -- and they eventually will because this will make the life 
> of application developers simpler.  But there is no time pressure.
> 
> _______________________________________________
> nbs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nbs
>

---

From: Javier Ubillos <[email-masked]>
Date: Tue, 05 Oct 2010 13:29:37 +0200

Sorry for the delayed answer.
I'll reply in two different e-mails.

On Fri, 2010-10-01 at 09:37 -0700, Erik Nordmark wrote:
<snip>
> off with "we can't change X" for any value of X isn't likely to be a 

I'm not saying that this way is better (we'll actually I am, but a
healthy approach is to presume that I'm wrong ;).

There are a lot of preexisting solutions to ID/Locator split.

What we do have so far however is this either splits further down in the
stack as shimming layer at the network layer of the stack (e.g. HIP), or
in the network (e.g. LISP).

What we are suggesting is a different deployment approach.

Doing stuff in the network requires that we change the network.
Doing stuff in a shimming layer is fine, but how does the application
know what it gets?
Doing stuff in a higher layer allows us to 
a. Explicitly declare what you want/assume
b. Be able to deploy the solution in the OS _or_ in user-space.

Option b here I think is what makes NBS very different.
(I'm now representing a very personal opinion, there is no consensus
about this)
We may very well have a scenario where name-based sockets are
distributed as a library, which gives preference to OS implementations.
This way, applications will for sure know what they are getting, and may
be distributed without concern about which OS-version they will be
deployed on. Historically, user-space libraries tend to gravitate
towards becoming part of the OS:es.

So, why am I hesitant to delays in the connection setup?
Because, for an ID/Loc split to be deployed, it has to make stuff
better.
E.g. logging on to g-mail, you have several of "first packets".
These are sometimes also sequential, so that one connection has to
finish before the next can start.

What I envision is something that _starts_ as a legacy communication,
and then builds up surrounding features, very much as shim6 does when it
waits for 50 packets to be exchanged before it kicks-in.

Note that this is orthogonal to name-based sockets being or not.
It is just the way I would like to see things happen.
I want it to be good _and_ deployable :)

> there is a need to do some validation or other exchanges in an 

Intresting.
I have so far presumed that if an application uses DNS-resolution
anyway, that name-based sockets would be equal.
Perhaps some method of pre-feeding resolutions would be nice?
E.g. where name-based sockets can provide applications with a
local /etc/hosts or dns-proxy which can be fed with good assumptions
(such as prefetches).

Optimizing this now is a bit premature, but what kind of nerds would we
be if we abstained?

// Javier

---

From: Javier Ubillos <[email-masked]>
Date: Tue, 05 Oct 2010 13:32:51 +0200

For what it's worth:
I think having implementations in non-OS libraries/frameworks is an
option.
E.g. Java, .NET or as a library for C/C++.

// Javier

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Oct 2010 09:28:40 +1300

On 2010-10-06 00:29, Javier Ubillos wrote:

>> "connection setup" is actually the DNS lookup,

This isn't news. Many years ago, Christian Huitema did a survey of
where the time went in fetching web pages. In 1996, the DNS lookup
was 13% of the total time to load a page, and establishing the actual
connection was only 12%. The full data that he gave:

DNS 13%
Connect 12%
Prepare 33% (i.e. the pause between sending the GET and starting to receive the reply)
Transmit 42%

Data presented at Interop (Paris) in early 1997, but has this really changed?

If we can still learn from this: optimising the lookup/connect phase is
only optimising 25% of the total time as far as the user is concerned.
And half that time is DNS lookup in every possible scenario. Optimising
the connect phase is only optimising 12% of the total time.

    Brian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 12 Oct 2010 12:58:26 -0400

> NBS APIs could instead continue to provide, in their binary format, addresses found in session originating packets, and let application ignore them if they aren't interested.

Remi:

The reason why I think we do need synthesized names is because of their semantics:  They name the host that was located at the encoded IP address at the time of session initiation.  Unlike the semantics of an IP address, which can name the host that /currently/ is located at the address, a synthesized name could be stable across a session.

Does this make sense?

- Christian

---

From: Jan M <[email-masked]>
Date: Tue, 12 Oct 2010 21:22:30 +0300

Hi Christian,

First of all I'm new to the list so maybe this has been asked already but hopefully somebody could clarify also to me.

How will a host with a RFC1918 address be able to synthesize its name or will all RFC1918 hosts have the same name? How will NBS separate these hosts or is it assumed that server will always sees the same name? Or do the end hosts see different names e.g. server sees the synthesized name of NAT and client sees the name of RFC1918?

If there was a host at certain IP A (obtained via DHCP) with synthesized name A when the next host (different) gets the same IP A from DHCP will it have the same name A? What should the peer be able to determine from this name and how will it know that it is different or same instance as the previous?

 Regards,
   Jan

---

From: Christian Vogt <[email-masked]>
Date: Wed, 13 Oct 2010 14:19:58 -0400

> First of all I'm new to the list so maybe this has been asked already but hopefully somebody could clarify also to me.

Welcome to the list, Jan.

> How will a host with a RFC1918 address be able to synthesize its name or will all RFC1918 hosts have the same name? How will NBS separate these hosts or is it assumed that server will always sees t…

Yes, synthesized names are derived from the IP address seen by the recipient.  Therefore, if multiple legacy hosts are behind a NAT, their synthetic names will be the same.

An alternative could be to also encode the initiator's port number into a synthesized name, in addition to the initiator's IP address.  In this case, the synthetic names of multiple legacy hosts are behind a NAT would differ.  I am yet unconvinced whether this would be useful, though.  Thoughts?

> If there was a host at certain IP A (obtained via DHCP) with synthesized name A when the next host (different) gets the same IP A from DHCP will it have the same name A?  What should the peer be ab…

Yes, if DHCP hands out the same IP address to different hosts sequentially, and if those hosts are both legacy, the hosts' synthesized names will look the same.  But this is in line with the semantics of a synthesized name:  A synthesized name refers to the host that used the encoded IP address at the time of session initiation.  By implication, synthesized names are good only throughout a session -- for session identification across address changes.  Synthesized names cannot be used to re-identify a host across sessions.

Does this make sense?

- Christian

---

From: Jan M <[email-masked]>
Date: Thu, 14 Oct 2010 08:45:35 +0300

Hi Christian,

> Yes, if DHCP hands out the same IP address to different hosts sequentially, and if those hosts are both legacy, the hosts' synthesized names will look the same.  But this is in line with the semant…

Actually I don't see how this could work for either session identification. If the host initiates the session with RFC1918 address behind the NAT then the peer sees synthesized name NAT.in-addr.arpa and client thinks it is RFC1918.in-addr.arpa. Now it tries to use this name on the other interface it has and it sends to the peer "Hi, I'm RFC1918.in-addr.arpa I would like to add V.X.Y.Z. address to the existing RFC1918.in-addr.arpa session" but the peer has only session NAT.in-addr.arpa so it wont be able to identify the session or am I missing something? So I guess you need some network support to resolve that the name of the session is actually NAT.in-addr.arpa not RFC1918.in-addr.arpa?

Additionally the session identification comes even more complex when you have multiple hosts behind the as not all can identify themselves as NAT.example.com or how do you plan to avoid situation where multiple hosts are saying that "Hi I'm NAT.in-addr.arpa and I would like to add address to address on port 80" so how would the peer know which session to associate new address as the source port is probably not usable as you can't count on it to be same all session to be added?

   Regards,
    Jan

---

From: Rémi Després <[email-masked]>
Date: Thu, 14 Oct 2010 09:12:19 +0200

Christian,

The semantics of the IP address at the socket API can, and IMHO should, remain unchanged during the connection.
I see no need to invent synthetic names just for the application to be able to find again the initial address.
If the name of the connection initiator is not given received in the connection-accepting host, this one should not accept the connection if it imposes to have the initiator's name (one that can be checked in the DNS).

Regards,
RD

---

From: Javier Ubillos <[email-masked]>
Date: Thu, 14 Oct 2010 14:07:53 +0200

Hi Erik, please excuse me for taking so long to answer.

> and also claiming to be bob.example.com.

How to prevent SYN-floods.
I.e. how should a syn-cookie work with name-based sockets.

I don't have a great solution for this (yet).
These are the lines of thought I have followed so far.

a. Let the 24bit hash which previously included srcIP, dstIP, srcPort
and dstPort also include srcName and dstName.
This means that a single host, which before could create 65k cookies by
changing the source-port (assuming no IPspoofing) can now create
65k*2^(8*255).
Not entirely true, there are only 24bits for the result of the hash, so
in essence, it would be 2^24 (about 16M). It is still not a good
solution.

b. Don't change anything.
If a packet from IP(B), PORT(B1), NAME(B1) comes, a normal TCP handshake
is done.
If another packet arrives from IP(B), PORT(B1), NAME(B2) within the same
64time frame, the cookie should still be there, and a connection will be
immediatly accepted.
We don't have the same problem with saturating the
syn-cookie-hash-space. But now all of a sudden, a single malicious host
can create 2^(255*8) TCBs. Not cool.

c. Don't let a single IP+port map to multiple TCBs.
In other words, don't make the name part of the TCP-internal tuple.
We'll still let the application bind to a name, but internally to TCP,
this would simply be an indirection to a IP+port 4-tuple.
This is not architecturally clean, but I believe this is the most viable
way to go.

I would very much appreciate more comments on this as I think this is
one of those details where Mr.Devil resides, and we need to find an
acceptable solution.

// Javier

---

From: Javier Ubillos <[email-masked]>
Date: Thu, 14 Oct 2010 17:28:51 +0200

> Additionally the session identification comes even more complex when you have multiple hosts behind the as not all can identify themselves as NAT.example.com or how do you plan to avoid situation w…

Consider the synthesized name an arbitrary label. Completely irrelevant
for the communication.

Assume that host A is behind a NAT,
and assume that we're talking TCP.

Host A has  |  Host B has
IP(A)       |  IP(B)
Port(A)     |  Port(B)
Name(A)     |  Name(B)

When Host A sends a packet to B, and only receives Bs address in a
literal manner, the packet on the network is still sent to
IP(B):TcpPort(B). The names Name(A) & Name(B) are added in an extension
header, but for the network, it is considered payload only.

When it arrives at Host B, Name(A) will be used as a sessionlabel with
no particular semantics. The label will never be derived to an IP, hence
there is no risk that the IP changes owner. This is all managed by
name-based sockets (e.g. by the shim6 extension).

Conversely, when the reply from Host B to A is sent, it follows normal
IP+NAT protocol. The names are, from a network perspective, just
payload.

What _could_ be an issue to be solved, is what happens when labels
collide. But I don't think this will be a major problem, as long as each
socket is well isolated from other sockets.

// Javier

---

From: Javier Ubillos <[email-masked]>
Date: Thu, 14 Oct 2010 17:34:36 +0200

> The semantics of the IP address at the socket API can, and IMHO should, remain unchanged during the connection.

I agree, and the issue of synthesize names is not directly associated to
this. Synthesized names can very be hidden from the application if one
wants that. If a literal IP is provided, this data structure can very
well become the anchor point of the application.
However, it would be a little bit awkward, if you open a socket, with
address family AF_NAME, and then encode a literal IP into name field.
But it wouldn't be a major technical hurdle.

// Javier

---

From: Rémi Després <[email-masked]>
Date: Thu, 14 Oct 2010 17:40:06 +0200

> But it wouldn't be a major technical hurdle.

The idea is rather to keep the address field as is with previous AFs, and leave the name field empty if none is available?
It is the up to the application to decide whether it accepts connections with blank names.

Does that make sense?

RD

---

From: Javier Ubillos <[email-masked]>
Date: Thu, 14 Oct 2010 18:08:34 +0200

> It is the up to the application to decide whether it accepts connections with blank names.

I think it does.
I would very much like to get rid of sockaddr at all, but there is no
reason to why we wouldn't be able to have a thin layer which accepts a
traditional INET/INET6 type of sockaddr to a AF_NAME socket and then
simply "under the hood" convert it to something more 

From the user perspective, it would be a completely ordinary socket call
with a different address family.

The current API suggestion (which will most likely be heavily modified)
allows the responder to accept from any name, which I think would be
fine for the "blank name" scenario.

Conceptually, it would be as you describe it: legacy-sockaddr (IP) + an
ignored (empty?) name.

// Javier

---

From: Jan M <[email-masked]>
Date: Thu, 14 Oct 2010 20:47:26 +0300

Hi,

See the question at the bottom....

> socket is well isolated from other sockets.

Are you saying that the labels wouldn't be derived from the addresses? Earlier Christian said that they would? If not then how do you generate the label and ensure that it is unique enough? Is the label a hash of something or what are the semantics? 

Is the plan to generate this session label also in the case where the peer has a FQDN or not? If not then again I guess that would mean that you have two different ways of naming sockets depending whether the FQDN was know or not when the socket was bound?

    Jan