Subject: [nbs] NBS and TCP connection identification

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Sep 2010 15:01:12 -0700

I'm quite intriqued by name-based sockets, but I don't understand how 
things are supposed to work.
I've read draft-ubillos-name-based-sockets-03.txt and 
draft-xu-name-shim6-00.txt, but some aspects appear to be missing.

Does with NBS what identifies a TCP connection? Today it is identified 
by a pair of IP addresses and port numbers, but that wouldn't work with 
NBS since we want the TCP connection to survive renumbering the IP 
addresses. Is the intent that the connection be identified by a pair of 
names? By fixed-length hashes of the names?

What are the security issues introduced by the additional name mapping? 
(Part of that answer depends on how TCP connections are identified.) It 
might be useful to review RFC 4218 and see what threats apply to NBS.

In name-shim6-00.txt there is a suggestion to communicate the names in 
NBS, and then in addition communicate the names (or MD5-hashes of the 
names) in shim6. That seems to be overkill.

Instead of a nonce as a name I think it makes more sense to use a 
crypto-based identifier (see
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.139.4051&rep=rep1&type=pdf). 
Such a name/ID means that even a host which does not have a FQDN can 
benefit from multihoming and mobility using NBS without introducing any 
security issues.

    Erik

---

From: Christian Vogt <[email-masked]>
Date: Mon, 20 Sep 2010 18:15:29 -0700

Hi Erik:

Thanks for reviewing both documents.  A few comments; Javier will fill in the rest.

- You are right that TCP connections will be identified by a pair of DNS names.  Implementation-wise, this could be realized by hashing the DNS names into 128-bit strings.  Then, a TCP-for-IPv6 implementation could pretty much be reused.

- Security-wise, the idea is to bind DNS names to IP addresses by means of a forward lookup in the DNS.  This gives the same level of security that we have for DNS-based applications today, except that the forward lookup would not just be done by the connection initiator, but also by the connection responder.  Where higher security is required, we recommend DNSSEC.  Thus we can avoid extra cryptographic identifiers.

- Hosts that don't have a name registered in the DNS will derive a DNS name from their IP address.  This will give them session continuity, albeit no reachability.

Does this make sense?

So long,
- Christian

You wrote:

> 
> I'm quite intriqued by name-based sockets, but I don't understand how things are supposed to work.
> I've read draft-ubillos-name-based-sockets-03.txt and draft-xu-name-shim6-00.txt, but some aspects appear to be missing.
> 
> Does with NBS what identifies a TCP connection? Today it is identified by a pair of IP addresses and port numbers, but that wouldn't work with NBS since we want the TCP connection to survive renumbering the IP addresses. Is the intent that the connection be identified by a pair of names? By fixed-length hashes of the names?
> 
> What are the security issues introduced by the additional name mapping? (Part of that answer depends on how TCP connections are identified.) It might be useful to review RFC 4218 and see what threats apply to NBS.
> 
> In name-shim6-00.txt there is a suggestion to communicate the names in NBS, and then in addition communicate the names (or MD5-hashes of the names) in shim6. That seems to be overkill.
> 
> 
> Instead of a nonce as a name I think it makes more sense to use a crypto-based identifier (see
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.139.4051&rep=rep1&type=pdf). Such a name/ID means that even a host which does not have a FQDN can benefit from multihoming and mobility using NBS without introducing any security issues.
> 
>   Erik
> 
> 
> _______________________________________________
> nbs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nbs

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Sep 2010 20:30:24 -0700

On 09/20/10 06:15 PM, Christian Vogt wrote:
> - You are right that TCP connections will be identified by a pair of
> DNS names.  Implementation-wise, this could be realized by hashing
> the DNS names into 128-bit strings.  Then, a TCP-for-IPv6
> implementation could pretty much be reused.

But that requires that the hash of the DNS name be carried in the TCP 
SYN and SYN|ACK, since you can't setup that state after the connection 
is setup. This adds complexity (and the details are missing) since TCP 
needs to handle both a NBS peer and a normal TCP peer (the latter will 
create a connection based on the IP addresses.)
I don't know how this is intended to work for UDP.

> - Security-wise, the idea is to bind DNS names to IP addresses by
> means of a forward lookup in the DNS.  This gives the same level of
> security that we have for DNS-based applications today, except that
> the forward lookup would not just be done by the connection
> initiator, but also by the connection responder.  Where higher
> security is required, we recommend DNSSEC.  Thus we can avoid extra
> cryptographic identifiers.

If X can predict that A will talk to B (using port1/port2), then X can 
send a SYN claiming to have A's name (and port1) destined to B/port2.
Later when A sends its SYN something on B has to be able to resolve 
things. The easy way is to verify that the initiator actually "owns" the 
name A before creating the TCP state for A/port1.

I don't understand what you mean by the forward lookup being done by the 
responder. Clearly the responder can't do a forward lookup when it 
receives a SYN packet, because that can be used to DoS the responder out 
of existence.

> - Hosts that don't have a name registered in the DNS will derive a
> DNS name from their IP address.  This will give them session
> continuity, albeit no reachability.

But that doesn't allow them to use SHIM6 to move around.
A CBID as a name allows them to move around.

    Erik

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Sep 2010 10:29:16 +0200

Le 21 sept. 2010 à 00:01, Erik Nordmark a écrit :

> Does with NBS what identifies a TCP connection? Today it is identified by a pair of IP addresses and port numbers, but that wouldn't work with NBS since we want the TCP connection to survive renumbering the IP addresses. Is the intent that the connection be identified by a pair of names?

In my understanding, this is what is consistent and clean.
For this, a TCP option seems appropriate, to convey to the server the source the destination names used by the client (when they exist).
Thus, servers may query to the direct DNS (rather than the reverse DNS) to validate the names of connection initiators. 
In the absence of such names, applications that need to identify where connections come from can refuse them.

RD 

> By fixed-length hashes of the names?
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Sep 2010 10:37:02 +0200

Le 21 sept. 2010 à 05:30, Erik Nordmark a écrit :

>> ...

In my understanding, it does: the name is just the address "that was used to initiate the connection ".
Thanks to Shim6, actual source and destination addresses may change without changing the connection ID at the socket interface. 

RD

---

From: Javier Ubillos <[email-masked]>
Date: Tue, 21 Sep 2010 13:19:10 +0200

> I don't know how this is intended to work for UDP.

Perhaps I misunderstand your concern, but I'll try to answer.
On the individual host, there is a change to the implementation in the
sense that the 4-tuple is now 
name, service (port), name service(port)
instead of the prevous
ip, port, ip port.

There are no changes to the "on the wire" protocol.

There are two ways of doing this.
1. Hashing the name into something that fits into the ip-address field.
2. Having a specialized TCP implementation.

I promote alternative 2.
In fact, we already have that bit working in the prototype.

> receives a SYN packet, because that can be used to DoS the responder out 

Hmmm, you might have a point here.
We're going to have to consider this more.

There are two ideas on the table:
a) Do nothing. 
b) When receiving a name in an option, resolve that name and compare
IP's with the just received IP.

Case a) _will_ happen if the name is not a resolvable FQDN.
Case b) ... perhaps this is an issue we need to look at.
I need to do some readingup on the subject.

> A CBID as a name allows them to move around.

It does, in the most primitive scenario, one enters an IP into the
name-based socket, and that IP is used just as a label.

// Javier

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Sep 2010 16:23:07 +0200

> name, service (port), name service(port)

Whether names can be sufficient at the socket interface, in some circumstances, has IMHO to be investigated.
For example:
- a name resolved to an SRV record doesn't need an application-provided server port.
- ports of connection initiators
  . are in general not significant to server applications
  . may be changed by NATs in IPv4

> 2. Having a specialized TCP implementation.

+1  on this choice
(as already expressed in another mail, with destination-AND-source names possibly conveyed by SYNs ).

Regards,
RD

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Sep 2010 08:54:13 -0700

> There are no changes to the "on the wire" protocol.

In my book "protocol" = "packet formats" + "behavior".

I'd agree there isn't any changes to the TCP packet formats (but you do 
have some added IP options/extension headers). But AFAICT there is a 
rather profound change to the TCP protocol behavior around connection 
establishment.

> In fact, we already have that bit working in the prototype.

Please correct me if I'm wrong, but you are proposing that when TCP 
receives a SYN packet it checks if the packet has the IP 
option/extension to carry a name, and if so creates the TCB for the 
name/port 4-tuple, whereas if the name is not present the TCB would be 
for the IP/port 4-tuple.

That requires some care, and I don't understand how you propose to apply 
this to UDP.

> I need to do some readingup on the subject.

As I said, doing b) on the SYN is opening a huge DoS attack opportunity.

FWIW I know how to avoid this complexity if we reuse the shim6-style 
exchange from the start (with ULID replaced by the name). The I1/R1 
exchange does the initial exchange, and on I2 (which can also carry the 
TCP SYN I guess) the receiver can do the DNS lookup with less of a DoS 
concern. Doing things in that order also ensures that TCP (and UDP) 
would have a (verified) name when the first packet is received. But that 
approach has some other downsides.

> name-based socket, and that IP is used just as a label.

How do you secure the movement in that case?
Suppose the client has IP address 129.146.228.81, thus the server would 
see the client as having name 81.228.146.129.in-addr.arpa.
Then the client switches to being on IP address 36.1.2.3. How can you 
know that it is indeed the same client so that it is secure for the 
server to start sending the packets to 36.1.2.3?
You can't rely on DNS validation (unless you assume that the client can 
update the DNS records for 81.228.146.129.in-addr.arpa, which is very 
unlikely.)
Thus how do you secure this?

    Erik

---

From: Javier Ubillos <[email-masked]>
Date: Wed, 22 Sep 2010 11:47:18 +0200

Erik.
Thanks for this feedback it is very valuable to me :)

> In my book "protocol" = "packet formats" + "behavior".

Agreed.

> rather profound change to the TCP protocol behavior around connection 

So, there are changes to the protocol(s).
TCP: Applications now bind to a name+service rather than an IP+port.
This is an API change, the workings under the hood can and AFAIKT should
remain unchanged.

IP: An optional change (I'll get back to why it is optional) is to
perform the name exchange. This means adding and extension header.
It _might_ also mean that the respondent wants to do a reverse DNS
resolution. And yes, this is an area we need to explore further, more
about it below.

> That requires some care, and I don't understand how you propose to apply 

There is a change coming soon to the draft. Where the name-exchange
becomes an optional component.

This still mean that we have an opening for a potential SYN-flood.
(more below :)

> approach has some other downsides.

So, a potential SYN-flood.
We do need to deal with this.
One way of doing this could be to simply not use the name-resolution
requirement for a FQDN-name exchange, just as we do when we use a nonce
or an arbitrary label, it becomes a simple session identifier.

I would prefer to find a way of allowing it, without a blocking
hand-shake or, ofcourse, opening up to an attack. I guess this would be
an item for a potential future WG.

> Thus how do you secure this?

Movement is, in the name-based sockets + shim6, handled by shim6.
The shim6 handshake is performed out-of-band. Before that is done, no
mobility/multi-homing is available. Shim6 deals with validation. We do
add locators to be tested found in DNS, but AFAIKT shim6 deals with this
nicely, and yes, we cannot trust DNS to that extent.
If it is the case that shim6 does not deal with this as I expected, then
we'll have to find a way to do it. E.g. that shim6 (if it already
doesn't) has a validation process for each new locator which has not
been inserted by vanilla-shim6 it self.

// Javier

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Sep 2010 10:10:57 -0700

> This is an API change, the workings under the hood can and AFAIKT should

But there is also the TCP behavior change associated with connection 
establishment, where AFAICT TCP receives a SYN from IPa to IPb, but is 
supposed to create a TCB from NAMEa to NAMEb.
That is the part I'd like to understand better, and the draft doesn't 
have anything about it.

> becomes an optional component.

That still doesn't answer how TCP connection setup would work - in fact 
it raises more questions about how it could work.

> an item for a potential future WG.

It would be good to have some idea that nbs can be made to work. I guess 
we can always say that if shim6 (using names as ULID) is done first, 
then TCP can run using the names (or hashes of names) after that. Such 
an approach is suboptimal, but it at least provides an existence proof 
of a solution, which means that we can have a WG go look at ways to make 
it perform better.

> been inserted by vanilla-shim6 it self.

Sure, shim6 does that already.

The issues are around how nbs and shim6 fit together; the devil is in 
the details ;-)

I still don't see how using names like 81.228.146.129.in-addr.arpa in 
nbs solves any problem, since they can't be secured AFAICT.

    Erik

---

From: Javier Ubillos <[email-masked]>
Date: Thu, 23 Sep 2010 16:19:12 +0200

> That is the part I'd like to understand better, and the draft doesn't 

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?

> of a solution, which means that we can have a WG go look at ways to make 

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

> nbs solves any problem, since they can't be secured AFAICT.

It's not about securing them, but about using them as a session
identifier.
Consider using a randomly generated string.
Using the canonical ".arpa" is just that with a small difference, it
gives you the information of from where the connection was initiated.
I do admit that this is not a big deal, which is why we wanted to leave
it open.

// Javier

---

From: Christian Vogt <[email-masked]>
Date: Mon, 27 Sep 2010 18:16:50 -0400

Erik Nordmark wrote:

> Clearly the responder can't do a forward lookup when it receives a SYN packet, because that can be used to DoS the responder out of existence.

We thought about this and figured that one could approach the problem in one of the following two ways:

- Have the responder perform a forward DNS lookup as long as the responder has the resources to do so -- i.e., as long as the responder is not under attack.  If the responder does not have the resources, it will deliver a synthesized DNS name, not the initiator's real DNS name, to the application.  This synthesized DNS name will encode the initiator's IP address.

- Have the responder always deliver a synthesized DNS name to the application.  The API could additionally give the responder the possibility to translate this synthesized DNS name to the initiator's real DNS name, if one is registered in the DNS.  Since the latter would be an application-triggered action, it wouldn't imply the security threat in question.

Do you have a preference on one of these two approaches?

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 27 Sep 2010 18:17:55 -0400

> nicely, and yes, we cannot trust DNS to that extent.

Erik,

let me add that the selection of Shim6 for mobility management was an implementation decision, not a conceptual decision:  We had an existing Shim6 implementation and people familiar with this implementation, so it seemed naturally to build upon it.  Conceptually, one could devise name-based sockets to work without Shim6.

Specifically, we are re-using Shim6's mechanisms for movement detection and address updating.  We do not re-use Shim6's mechanisms for binding IP addresses together, since with name-based sockets, IP addresses are bound to DNS names rather than to each other.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 27 Sep 2010 18:20:24 -0400

Erik,

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.

- Christian

---

From: Steven Blake <[email-masked]>
Date: Mon, 27 Sep 2010 18:46:29 -0400

> This procedure would be very similar to the Mobile IPv6 care-of address check.

Also very similar to the principle behind the ILNP nonce option:

http://tools.ietf.org/html/draft-rja-ilnp-nonce-06

Regards,

/////////////////////////////////////////////
Steven Blake       [email-masked]
Extreme Networks              +1 919-884-3211

---

From: Christian Vogt <[email-masked]>
Date: Mon, 27 Sep 2010 18:47:56 -0400

> http://tools.ietf.org/html/draft-rja-ilnp-nonce-06

Correct!

- Christian

---

From: Rémi Després <[email-masked]>
Date: Tue, 28 Sep 2010 11:40:33 +0200

Hi Christian,

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?

RD

---

From: Javier Ubillos <[email-masked]>
Date: Tue, 28 Sep 2010 14:51:15 +0200

> Does this make sense to you?

Not being Christian, I'm still taking the liberty to comment ;)

I think this makes perfect sense.

It would be nice if one could verify the name immediately, but not to
have it as a requirement.

If the verification of the name is important for some feature, it could
very well be done by that feature whenever it kicks-in. E.g. shim6 does
begin to negotiate until 50(?) packets have been exchanged.

// Javier

---

From: Christian Vogt <[email-masked]>
Date: Wed, 29 Sep 2010 14:47:53 -0400

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

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.

Is this summary accurate?

- Christian