Subject: [P2PSIP] Identity vs Identifier

From: Rubén Cuevas Rumín <[email-masked]>
Date: Thu, 15 Nov 2007 17:25:50 +0100

Hi everyone,

I have been following the list from some time ago, and finally after expose some ideas to Henry Sinnreich I decided
to participate since I think it could be useful.

Something that I miss on the discussion so far is the concept of "Identity" and "Identifier".

An identity is who I am. For instance, if we consider the Skype model  
Rubén.Cuevas is an identity which will be represented 
in the DHT in somehow. It make fully sense that in the DHT the 
hash(Ruben.Cuevas) will be stored. I think the 
WG call this /record/. Then, we have records representing identities. 
We can define identities as those things someone wants to find in the DHT.

On the other hand, we have Identifiers (I don't know if Identifiers is 
the right name) which could be paired with identities or not ( usually, 
identifiers will be paired with identities). Identifiers are representing /entities/ 
which are going to look for information in the P2PSIP systems and likely they also are storing records.

Then I (Rubén.Cuevas) can have one identifier associated.  
E.g. I am on my office with my desktop connected to the p2psip system. In 
that case we have the situation of paired identitiy and identifier.

However, I can also have several identifiers paired to an unique 
identity. For instance, I am on my office and I have my laptop, my PDA, 
my mobile phone and all of them are joined to the p2psip system. In this case maybe I don't want that all my devices were 
part from the p2psip system (since all of them would be consuming 
resources), I would like that only one of them (hopefully the most 
powefull) belongs to the DHT, then it would be a peer. The rest will be 
only clients which will be connected through my peer.

In addition, we should consider that in the current DHT systems my 
identity (record) and identifiers are placed in different points of the 
system, then my record does not depend on my indentifiers but in other 
identifier which I don't know who is. A question: It would be possible to 
make that my identity depends on any of my identifiers instead of a 
third party?? If this is possible, the system would be more secure. I 
have some ideas in this case, but my solution is really dependant on the 
scenario (I don't know if this makes sense for the WG).

On the other hand we can have the case of public telephones, or p2psip 
devices in a public library or in an university. These devices can be 
used to make calls and look for identities by using the p2psip. However, in this 
case there is not any identity associated to this identifier.

Regards,
                      Rubén.

-- 
Rubén Cuevas Rumín
Universidad Carlos III de Madrid
Departamento Ingeniería Telemática
Avenida de la Universidad, 30
28911-Leganés (Madrid). España
email: [email-masked]
Tlf: +34 91-6248859
Fax: +34 91-6248749
Web: http://www.it.uc3m.es/~rcuevas

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Thu, 15 Nov 2007 18:35:33 +0100

> Something that I miss on the discussion so far is the concept of "Identity" and "Identifier".

In my understanding -considering concepts document
(draft-ietf-p2psip-concepts-00), section 4- your concept of "identity"
is represented by "User Name" or "Service Name", while concept of
"Identifier" is represented by "Node-ID".

> only clients which will be connected through my peer.

In my opinion you are mixing DHT (transport and routing) and SIP
concepts (registering from 'n' UAs). It's true both peer and client
could be coupled with SIP UA, but this should be independent of their
P2P role.

Please correct me if I'm wrong,
-- 
Victor Pascual Ávila
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Rubén Cuevas Rumín <[email-masked]>
Date: Fri, 16 Nov 2007 10:52:10 +0100

> "Identifier" is represented by "Node-ID".
You are right. The identity is actually the concept referred as 
"resource" in the draft and the "Identifier" is the "Node-ID" or "Peer-ID".
My point is that in the discussion is not clear (at least for me) the 
relationship and implications of this basic parts  (from my point of view).
But, it is just my feeling .
> Please correct me if I'm wrong,
Of course, the concepts are mixed but not because I like but because  
p2psip architecture requires it.
If you have several UA associated to the same user. If I am right, it is 
pretty likely that all of them are going to use the service offered by 
the p2psip overlay which are defined in the concepts draft. And we 
should solve this problem, how several devices (i.e. UA) associated to 
the same user are going to participate/use the p2psip system.
The easiest way is that all of them becomes peers inside the p2psip 
system. But maybe ithis is not the best solution. I just proposed the 
possibility of use one of them as Peer and let the others be Clients. 
This is not new, the new part  is that I propose the Peer allowing the 
rest to access to the p2psip system is not a third one but this 
associated to the same user.

On the other hand, IMO an important problem in the p2psip overlay is 
that my "resource-ID" (or "resource-IDs") is going to be stored by 
someone I don't know and (with the solution defined so far) I cannot 
trust in. This introduce trust and security threads. It would be nice to 
define a new mechanism which allows the users to store its own 
"resource-IDs". It is something I am thinking about and I have some 
ideas if you are interested.

Rubén.

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 16 Nov 2007 09:58:46 -0500

> associated to the same user.

I think this is not the right way to layer here -- we are mixing an
application level issue (is more than one UA associated with a user)
with a routing level issue (is this a peer or client). The two should
be independent. Personally, I think as many things as possible should
be peers, and if all the devices you are associated with can be peers,
they all should act as so, rather than being clients.

There is another problem with the approach of a user with multiple
devices having one as a peer and the rest as clients. The only reasons
that I have seen presented for why a device should be a client rather
than a peer in the first place are either the device is behind a NAT
and cannot be a good peer, or has some limitation (processor, battery
life, etc.) that would motivate being a client instead. Making the
assumption that one is a peer and the rest clients assumes that the
device becoming a peer is reachable by all the devices. In a LAN this
may be true, but I might have 3 UAs, one at home, one at the office,
and one a mobile device. All may be on separate networks. Letting each
determine if it has adequate connectivity and resources to be a peer
makes better sense than imposing an application level decision, in my
mind.

> ideas if you are interested.

It would be interesting to hear what you had in mind. In proposals
like this people have made here and elsewhere over the last few years,
there are numerous problems that arise when each user becomes
responsible for their own resources as well. How do you handle
replication? How would you maintain information when the user is
offline? A meta question would be how clients would work in this
scenario, since they are, by definition, not directly accessible.
Personally, I think distributed storage, with replication and
encrypted, signed resources is the best idea, but I would be
interested to hear what you have in mind.

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 16 Nov 2007 10:48:19 -0500

Looks to me like we are having some semantic differences that are causing us
to get wrapped around the axle.

I think the concept document describes one kind of entity, a peer, which is
aware of the DHT and participates in it, and two kinds of entities: SIP UAs
and clients that do not directly participate in the DHT, but rather do so
through a peer.  The SIP UA uses SIP to communicate with the peer that
interworks SIP rendezvous operations to the DHT.  We were looking for
examples of clients that needed some other protocol to interwork their
rendezvous operations to the DHT.

It would seem that some want to redefine a client into a subset of a peer: a
entity who is aware of and participates in the DHT, but doesn't store data,
for example.  It would seem that most of the proponents of such a notion
think that a subset of the base p2p protocol is what such entities use.

I think we will have to have two terms that differentiate an entity that is
aware of, and participates directly in the DHT from an entity that does not.

I still don't see an example of a client as in my interpretation of the
definition of an entity that is not aware of, and does not directly
participate in the DHT.

Brian

> -----Original Message-----
> From: David A. Bryan [mailto:[email-masked]]
> Sent: Friday, November 16, 2007 9:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [P2PSIP] Identity vs Identifier
> 
> Comments inline:
>

---

From: Rubén Cuevas Rumín <[email-masked]>
Date: Fri, 16 Nov 2007 17:25:32 +0100

> makes better sense than imposing an application level decision, in my
I agree in almost everything.
As you said limited deviced are the candidates to not be a Peer. Then, 
imagine a simple scenario with two devices associated to the same user 
name, a non-limited device, e.g. a desktop, and a limited device, e.g. a 
mobile phone. Then, we can identify the desktop as a potential peer and 
the mobile phone as a potential client. Lets analyze the different 
situations:
1- The desktop is reachable (i.e. not firewalled or behind a NAT). It 
registers in the p2psystem and becomes a Peer. After that, the mobile 
phone registers on the p2psystems. Since this is a limited device it 
needs to lookfor a peer to conect with. Then, it can randonmly selects a 
Peer with the adequate  properties (i.e. globally reachable). However, 
why not try first to select a trustable one? I mean, the mobile phone 
can launches a search for the  resource-id associated to its user-name, 
and then, it would discover that there is a Peer associated to this user 
name already registered and which is reachable. Then it would select 
this one.

2- The desktop is behind a NAT. Then, the mobile phone could choose 
between connect to this (fully trustable) peer by using some 
NAT-Traversal strategy or connects to one offering global reachabilty 
but in principle, not trustable.

3- If it is the mobile phone who registers firstly, then it obviously 
would choose one globally reachable Peer. And maybe can develop some 
periodic discovery mechanism in order to discover if the trustable Peer 
(that is, the desktop on the example) appears at some point.

Well, it is just an idea. Why not use trustable Peers if we can do it?.

> interested to hear what you have in mind.
Let me explain my idea with an example.
If my user-name is Ruben.Cuevas, I (likely) will store in the DHT as 
resource-id the hash(Ruben.Cuevas), lets say this resource-id is X. If 
we consider the use of a DHT system, the Responsible Node for X will be 
the Peer with the closest Peer-ID to X. Then, if I want to be the 
Responsible Node for X, I have to obtain the closest Peer-ID. Thus, I 
can ask to the Central Entity (in case of use a Central Entity scheme) 
for the closest Peer-ID to the resource-key associated to Ruben.Cuevas.  
I can demonstrate I am Ruben.Cuevas (by a passwd or other credentials) 
and the Peer-ID would be assigned. It could be for instance X+1.  Then I 
becomes the Responsible Node for my own resource-id.
If all the users has to do the same and demonstrate their credentials, 
all the users obtain Peer-IDs close to their own resource-ids and anyone 
could obtain Peer-IDs with the intention to starve other resources.

As you said we have to deal with seveal issues:

Replication. You can still keep the same replication scheme than in the 
regular DHT schemes: the N closest Peer-IDs. However, in this case it is 
easier to identify the good or bad behaviour of my neighbourgs since I 
am the one which does this task. Even more, your neighbourg should be 
careful in make something wrong with your resource-id, since you also 
have stored his resource-id, then you can also make the same wrong thing.

I am off-line. Again the same. The same scheme which you use in the 
regular DHT schemes can be applied here. If in regular DHT your info is 
kept alive on the replicas, here you can do the same.

Clients: You have also the same problem as in regular DHTs. This scheme 
does not modifies anything regarding to the clients.

I have not yet going into the detail of this idea, and maybe it has 
several problems I have not yet identified. Then, it is really 
interesing to hear from you.

Cheers,
                 Rubén.

---

From: Rubén Cuevas Rumín <[email-masked]>
Date: Fri, 16 Nov 2007 17:30:53 +0100

> think that a subset of the base p2p protocol is what such entities use.
I agree with this definition of client.
In addition, it is close related to what David wrote in some recent mail 
that  Clients  only makes
sense in those devices which are in somehow limited. Then, we will allow 
them to take advantage
from the p2psip system (that is, retrive information) without 
overloading them with tasks as
storage, routing or maintenance.

Rubén.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 16 Nov 2007 14:33:38 -0800

I have changed the title, since the attached points to a new issue: 

Abusive and trustable peers and clients

Besides the fact that these terms must be better defined in some document, along with fairness, etc., it also raises the point that trustable nodes must have the software encrypted and signed by a central authority. At least Skype does it and it works well for them.

What do you think?

Henry

-----Original Message-----
From: Rubén Cuevas Rumín [mailto:[email-masked]] 
Sent: Friday, November 16, 2007 8:26 AM
To: David A. Bryan
Cc: [email-masked]
Subject: Re: [P2PSIP] Identity vs Identifier

Cheers,
                 Rubén.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Nov 2007 09:31:14 -0800

At Fri, 16 Nov 2007 14:33:38 -0800,
> Besides the fact that these terms must be better defined in some document, along with fairness, etc., it also raises the point that trustable nodes must have the software encrypted and signed by a…

How do you propose that other nodes determine whether a peer is
running such software?

-Ekr

---

From: "Marcus Leech" <[email-masked]>
Date: Sat, 17 Nov 2007 13:27:25 -0500

> How do you propose that other nodes determine whether a peer is
The snide answer would be "Why TCG/NEA/NAC/NAP or course, they fix
*everything*".

But I think that's a rat-hole that should be gone down somewhere else,
and not here.  Asking the question "how can we be sure
  the other side is running so-called good code" is not meaningful for a
sufficiently-robust definition of "meaningful".  One might
  as well ask "how can we be sure that the operator at the other end has
taken his anti-psychotics today, and thus can be
  trusted to use the software in a rational way".  The only
robustly-meaningful answer is "you can't".

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Nov 2007 10:40:29 -0800

At Sat, 17 Nov 2007 13:27:25 -0500,
> robustly-meaningful answer is "you can't".

I agree. Which is why security mechanisms which depend on the correct
behavior of peers are not OK.

-Ekr

---

From: Salman Abdul Baset <[email-masked]>
Date: Sat, 17 Nov 2007 17:26:10 -0500 (EST)

> behavior of peers are not OK.

This means that nodes should try to detect malicious behavior of other 
nodes and peer protocol should provide mechanisms for nodes to exchange 
this information.

A node that had its identifier certified by a CA can also misbehave. Think 
of a hacked version of Skype executable which allows users to obtain a 
certified ID, but prevents nodes from sharing its bandwidth. Users can 
also put a bandwidth cap on their p2p application that does not require 
any modification to the p2p executable. One such example is relay 
detect and block (RDB), developed at Columbia.
http://rdb.sourceforge.net/

There are more than one published mechanisms to detect malicious behavior 
of nodes. The question is should peer protocol incorporate those 
mechanisms, or leave it up to the overlay implementer.

-s

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Nov 2007 20:10:13 -0800

At Sat, 17 Nov 2007 17:26:10 -0500 (EST),
> nodes and peer protocol should provide mechanisms for nodes to exchange 

This opens up a whole can of worms: how do you detect false reports
of malicious behavior?! This is a persistent problem with all reputation
systems.

> mechanisms, or leave it up to the overlay implementer.

I think that trying to standardize that would be extremely inadvisable
at this time.

-Ekr

---

From: RUBEN CUEVAS RUMIN <[email-masked]>
Date: Sun, 18 Nov 2007 14:32:43 +0100

> of malicious behavior?! This is a persistent problem with all reputation

I agree that it is impossible to detect a malcious behaviour. Then, the 
only solution is to make the peers collaborate and properly behave. We 
can do it if we define the suitable incentive mechanism. For instance, 
Bittorrent works because of tit-for-tat which is a perfect strategy "as 
much as you uploads as much as you can download" (I know several people 
have implemented some free rider clients on Bittorrent by exploting 
some weaknesses).

Therefore, IMO instead of focusing on the detection of malicious 
behaviour, we should focus on defining an incentive mechanism which 
rewards those peers with a good behaviour. In addition, I still think 
that a secure Peer-ID assignment mechanism is essential. Without this 
mechanism the system would be highly vulnerable.

Rubén.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Nov 2007 06:49:53 -0800

At Sun, 18 Nov 2007 14:32:43 +0100,
> have implemented some free rider clients on Bittorrent by exploting

Unfortunately, incentive mechanism design is also an open research
problem.

-Ekr

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 18 Nov 2007 10:17:42 -0500

I hope we can agree on three things:

- Incentives don't deal with truly malicious users, just selfish ones.

- There is no general, assumption-free mechanism for securely  
assigning peer IDs.

- There is no general way to detect misbehaving nodes.

There may well be set of assumptions that are reasonable in certain  
circumstances and that allow you to qualify the statements above. It  
seems unlikely that this will affect the design of the protocol  
itself. Thus, I think we should declare defeat on those three items  
and move on. We just have to make sure that reasonable techniques, be  
they escrowing a million dollars, remote malicious user execution or  
just having a central enrollment server, are not prevented by our  
design.

In many cases, techniques outside the P2P system will be used to  
ensure security. For example, if you have an L3 network with strong  
admission control and strong network user authentication, you may not  
need to worry about protecting the overlay itself against malicious  
users.

Henning

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 18 Nov 2007 14:05:45 -0800

>>trustable nodes must have the software encrypted and signed by a 
>>central authority

>How do you propose that other nodes determine whether a peer is

My assumption is the p2p overlay is run by an owner with a vested
interest of protecting the overlay, just like Skype does. 

For Interdomain p2p security some work must be done on "the security of
"peering", though "peering" would have here a very different meaning
from what is meant at present.

This may fall under such specific design assumptions that Henning has
mentioned in this thread.

Henry

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Saturday, November 17, 2007 9:31 AM
To: Henry Sinnreich
Cc: [email-masked]; David A. Bryan; [email-masked]
Subject: Re: [P2PSIP] Abusive and trustable peers and clients

Henry Sinnreich wrote:
> Besides the fact that these terms must be better defined in some
document, along with fairness, etc., it also raises the point that
trustable nodes must have the software encrypted and signed by a central
authority. At least Skype does it and it works well for them.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Nov 2007 18:03:38 -0800

At Sun, 18 Nov 2007 14:05:45 -0800,
> interest of protecting the overlay, just like Skype does. 

But this only works for Skype because Skype's protocol and
implementation are closed and therefore it's very difficult
for an attacker to implement the protocol themselves and/or
extract the keying material used by Skype clients to
authenticate. The first property will clearly not be true
of any P2PSIP imploemetnation and the second is not going
to be true of any open source implementation.

-Ekr

---

From: JiangXingFeng <[email-masked]>
Date: Mon, 19 Nov 2007 10:40:37 +0800

> need to worry about protecting the overlay itself against malicious

Maybe you point another direction to the solution of the security of P2P
system. If the service providers of P2P system would collaborate with
Network operators, some advantages may be got:
1. Through the agreement between ISP and its subscribers, p2p system may
know who the peers or clients really are and where they are with the help of
the ISP. 
2. P2P service providers may delegate the ISP to enforce some security
mechanisms. 
3. If the ISP could bill for the P2P system, it will be a proof by which ISP
and P2P service provider could incent the peer to share resources. 

These are just my two cents. It must be outside the scope of P2PSIP WG. But
it may be the future work of the P2P community. 

Regards!
----------------
JiangXingFeng

---

From: Ali Fessi <[email-masked]>
Date: Mon, 19 Nov 2007 13:18:33 +0100

Hi Henning, all,

IMHO, I think it is not reasonable to rely on some security services on 
a different layer. This would limit the practicability of P2PSIP.

The IMS, e.g., implements its own security mechanisms independently of 
the underlying layer.

Also, if you are in Europe, and u want to join your P2P network in US, 
you may not want to do any VPN, or something like this, to be able to 
join your "home" P2P network.

However, for the P2PSIP WG, it is probably reasonable to assume that the 
assignment of a node-id is done by means out-of-scope. For real 
deployment scenario, you might have 2 use-cases:

- large-scale P2PSIP networks, where u need a central authority that 
provides the IDs.

- small P2PSIP networks, where self-signed certificates (with the 
node-id in the certificate) can be sufficient and u don't need all the 
burden with setting up a CA

Also, i agree with the point, that there is no general way to detect 
misbehaving nodes, in particular it is not possible to exclude attacks 
on the routing in the P2PSIP network.

hope this help to move forward.

Cheers,
  Ali

-- 
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [email-masked]
Web: http://net.informatik.uni-tuebingen.de/~fessi/

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 19 Nov 2007 09:15:06 -0600

Hi, Eric,

From: "Eric Rescorla" <[email-masked]>

> to be true of any open source implementation.

When you say "extract the keying material", do you mean "extract the keying 
material from a packet that you overhear", or something else?

I'm trying to grok the last half of the last sentence. I know it's the 
morning of I-D cutoff, so I'm probably not at the top of my game (and we can 
talk about what that might mean in Vancouver :-) ... but I'm not connecting 
all the dots.

Thanks,

Spencer

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 19 Nov 2007 09:22:05 -0600

>interest of protecting the overlay, just like Skype does.

I note that 
http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt 
explicitly calls this application scenario out in Section 4.4.1 (and the 
associated attributes in Table 1).

The authors of this draft would love to see some discussion of this 
particular scenario on-list, since it seems that some people are assuming 
this scenario while others are assuming other scenarios.

And if we can't frame the discussion in a specific scenario, this turns into 
a "baby beauty contest" where everyone says "MY baby is the most 
beautiful"...

Thanks,

Spencer

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 19 Nov 2007 07:48:16 -0800

Eric,

>The first property will clearly not be true
Eric,

>to be true of any open source implementation.

I would like to arm wrestle you on these statements. Can you elaborate?

1. Trustable nodes must have the software encrypted and signed be a
central authority, the same that provides the strong authentications for
the peers.

Please help me understand why this "will clearly not be true of any
P2PSIP implementation".

2. The encrypted software is not compatible with open source
implementations.

Please help me understand why open source code with some added "salt"
cannot be encrypted.

>This is fundamentally incompatible with either open protocols or open
source (in your companion message).

This post is really for a better understanding of these issues, so I
would appreciate some more clarification from you and any other folks
who would like to pitch in.

>But this only works for Skype because Skype's protocol
Same: It would help if this can be explained: Why does encryption and
signing work only for Skype and some similar and _creative_ approach
would not work for P2PSIP, no matter if it is OS or commercial.

Henry

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Sunday, November 18, 2007 8:04 PM
To: Henry Sinnreich
Cc: Eric Rescorla; [email-masked]; David A. Bryan;
[email-masked]

-Ekr

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 19 Nov 2007 07:56:11 -0800

Spencer,

Thanks for the question!
The section is actually: "4.1.1.  Public P2P VoIP Service Providers".

As mentioned, why can encryption and signing of the software in the
device or endpoint work only for a proprietary protocol like Skype and
not for P2PSIP, even when the SW is OS?

Henry

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Monday, November 19, 2007 9:22 AM
To: [email-masked]
Subject: Re: [P2PSIP] Abusive and trustable peers and clients

I note that 

The authors of this draft would love to see some discussion of this 
particular scenario on-list, since it seems that some people are
assuming 
this scenario while others are assuming other scenarios.

And if we can't frame the discussion in a specific scenario, this turns
into 
a "baby beauty contest" where everyone says "MY baby is the most 
beautiful"...

Thanks,

Spencer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Nov 2007 07:53:03 -0800

At Mon, 19 Nov 2007 09:15:06 -0600,
> talk about what that might mean in Vancouver :-) ... but I'm not connecting 

OK, let's take a step back:
You're the operator of some service. It could be a P2P network, but
actually the context in which this comes up the most is DRM for
digital media.  Your customers use your software to access the service
and part of your security depends on the software functioning
correctly.  In the case of a P2P network this may mean storing
whatever data it's supposed to store. In the case of DRM, it generally
means not exporting the media in raw form. In order to enforce this,
you write your own software that behaves the way you want and this is
the only software you allow on your network.

Now, when the operator's server receives a message/connection/PDU
from a client, it needs to determine whether the client is running 
the right software. Otherwise, the user can simply download software
which *pretends* to be your software but actually cheats (doesn't
store data, exports media in raw form, whatever). So, you need
one way to verify the software running on the other end. This 
problem is called attestation, and it's believed to be quite
difficult. All the known solutions that really work involve trusted
hardware on the client side. (cf. TCG).

If you're not going to use trusted hardware, then you end up falling
back on obfuscation. There are two things you can obfuscate:

- The protocol.
- The program binary.

If you use a proprietary protocol, then you make it difficult for
a third party to pretend to be one of your clients because the
first thing they need to do is reverse engineer your protocol.
The implicit theory here is that anyone who speaks your protocol
is one of your clients.

If you want to use an open protocol, then you can't use this method,
so you end up falling back on cryptography. You use an open 
protocol but then somehow issue each client a cryptographic key
which it uses to authenticate. But of course the client needs
access to the key, so the attacker can reverse engineer the client
to extract the key. And since the protocol is open, they can then
write their own implementation using the key. In order to block
this, you generally obfuscate/encrypt the program binary to make 
key extraction more difficult. But this is obviously incompatible
with the client program being open source.

Skype uses both of these techniques: the protocol is proprietary
*and* each client is issued a key at startup which is used by
an obfuscated binary. Nevertheless, both countermeasures have been
successfully attacked. Again, there is no known way of solving
this problem without using trusted hardware.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Nov 2007 07:57:16 -0800

Oh, I forgot to mention, there's one more thing you can do: constantly
change the protocol and force users to download new clients with
different obfuscation. This creates an arms race with the attacker,
because each time you change the protocol, the fake clients break and
the attacker has to reverse engineer your implementation anew. This
means that people using the attackers software get a lower quality of
service because there are outage periods with each software release.

A related (though slightly different) example of this type of situation
is the repeated cracking and then fixing of the iPhone.

-Ekr

At Mon, 19 Nov 2007 07:53:03 -0800,

---

From: Rubén Cuevas Rumín <[email-masked]>
Date: Mon, 19 Nov 2007 17:14:02 +0100

> not for P2PSIP, even when the SW is OS?
In this case I agree with Eric. He possed some argument I support. I 
would like to add a new argument.

We are trying to standarize a p2psip protocol. However, if latter we are 
going to allow every ISP or other company using their own p2psip overlay
to encrypt and obfuscate the code we cannot assure if this code is or 
not compliant with the defined standard. Then the standard would not be 
anymore
an standard but a set of rule to follow.

And now imagine two different ISPs deploy their softwares and encrypt 
them and at some point the want to make inter-domain communications, if 
they are
using different encryption schemes (and what would be worse, they have 
slightly modified the standard) how their clients are going to communicate?.

I think encryption/obfuscation works for private solution as Skype, but 
IMO is an error consider this as part of a standard protocol.

What do you think?

Rubén.

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 19 Nov 2007 14:05:59 -0600

----- Original Message ----- 
From: "Rubén Cuevas Rumín" <[email-masked]>
To: "Henry Sinnreich" <[email-masked]>
Cc: "Spencer Dawkins" <[email-masked]>; <[email-masked]>
Sent: Monday, November 19, 2007 10:14 AM
Subject: Re: [P2PSIP] Abusive and trustable peers and clients

> In this case I agree with Eric. He possed some argument I support. I would 
> like to add a new argument.
>
> to encrypt and obfuscate the code we cannot assure if this code is or not 
> compliant with the defined standard. Then the standard would not be 
> anymore
> And now imagine two different ISPs deploy their softwares and encrypt them 
> and at some point the want to make inter-domain communications, if they 
> are

The thing is, IETF standardizes protocols, and you're including a protocol 
implementation as part of the standard. For IETF, the standard IS a set of 
rules to follow, in a protocol implementation, not the protocol 
implementation itself.

So I don't think we're in any danger of standardizing this in IETF. We don't 
even standardize APIs (in most protocols), much less the applications that 
would use those APIs.

Thanks,

Spencer

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 19 Nov 2007 14:06:55 -0600

Hi, Eric,

This was a great help - thanks for taking the time to write it down.

Spencer

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 19 Nov 2007 18:20:37 -0800

Thanks Eric and Spencer for taking time to discuss this.

> Again, there is no known way of solving

I agree. Thanks again,

Henry

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Monday, November 19, 2007 2:07 PM
To: Eric Rescorla
Cc: [email-masked]
Subject: Re: [P2PSIP] Abusive and trustable peers and clients

Hi, Eric,

Spencer

>> morning of I-D cutoff, so I'm probably not at the top of my game (and
we 
>> can

---

From: "Marcus Leech" <[email-masked]>
Date: Mon, 19 Nov 2007 21:28:57 -0500

> this problem without using trusted hardware.
Even then, I'm not convinced that the problem can be solved for a
sufficiently robust definition of "solved".

In the TCG approach, a tiny little piece of *something* runs in the TPM,
and it has to rely on a very large,
  complicated, inherently-untrustable "blob" (the OS and all its
applications) to hand it things to attest to.
 Dicey.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Nov 2007 18:39:03 -0800

At Mon, 19 Nov 2007 21:28:57 -0500,
Marcus Leech wrote:
> 
> [1  <text/plain; ISO-8859-1 (quoted-printable)>]
> Eric Rescorla wrote:
> >

Yes, I'm not convinced as well, but I figured it was easier to
withhold judgement on that point, since I don't expect us to
require trusted hardware.

-Ekr

---

From: "Marcus Leech" <[email-masked]>
Date: Mon, 19 Nov 2007 22:15:13 -0500

> require trusted hardware.
Fair enough.    I shall not mention it again.

---

From: "Jan Seedorf" <[email-masked]>
Date: Tue, 20 Nov 2007 14:33:54 +0100

Dear Ruben,

> If my user-name is Ruben.Cuevas, I (likely) will store in the 
> DHT as resource-id the hash(Ruben.Cuevas), lets say this 
> resource-id is X. If we consider the use of a DHT system, the 
> Responsible Node for X will be the Peer with the closest 
> Peer-ID to X. Then, if I want to be the Responsible Node for 
> X, I have to obtain the closest Peer-ID. Thus, I can ask to 
> the Central Entity (in case of use a Central Entity scheme) 
> I can demonstrate I am Ruben.Cuevas (by a passwd or other 
> credentials) and the Peer-ID would be assigned. It could be 
> for instance X+1.  Then I becomes the Responsible Node for my 
> own resource-id.
> If all the users has to do the same and demonstrate their 
> credentials, all the users obtain Peer-IDs close to their own 
> resource-ids and anyone could obtain Peer-IDs with the 
> intention to starve other resources.

I see a couple of problems with what you propose above:

- first, if the user can choose its user-ID (the identity), in your proposal the user could indirectly choose the location of the node-ID (the identifier). As discussed on this list, chosen-location attacks are a threat that needs to be avoided (as much as possible). I see the problem that an attacker could generate an "identity" specifically to target (e.g., cut off) some other "identity" in the network. In your example, assuming that Chord is used as the DHT, I would need to generate an identity Y such that hash(Y) would be smaller but very close to hash(Ruben.Cuevas) to be able to deny any request for the resource object (transport address) stored for your identity in the DHT.

- second, your scheme assumes that there is an equal number of peers (identifiers) and users (identities). This may or may not be the case. If not, the question arises where to store my second identity if I only have one peer?

 - Jan

> Sent: Friday, November 16, 2007 5:26 PM
> To: David A. Bryan
> >> If you have several UA associated to the same user. If I 
> am right, it 
> >> is pretty likely that all of them are going to use the service 
> >> offered by the p2psip overlay which are defined in the concepts 
> >> draft. And we should solve this problem, how several devices (i.e. 
> >> UA) associated to the same user are going to 
> participate/use the p2psip system.
> >> This is not new, the new part  is that I propose the Peer allowing 
> >> the rest to access to the p2psip system is not a third one 
> but this 
> As you said limited deviced are the candidates to not be a 
> Peer. Then, imagine a simple scenario with two devices 
> associated to the same user name, a non-limited device, e.g. 
> a desktop, and a limited device, e.g. a mobile phone. Then, 
> we can identify the desktop as a potential peer and the 
> mobile phone as a potential client. Lets analyze the different
> situations:
> 1- The desktop is reachable (i.e. not firewalled or behind a 
> NAT). It registers in the p2psystem and becomes a Peer. After 
> that, the mobile phone registers on the p2psystems. Since 
> this is a limited device it needs to lookfor a peer to conect 
> with. Then, it can randonmly selects a Peer with the adequate 
>  properties (i.e. globally reachable). However, why not try 
> first to select a trustable one? I mean, the mobile phone can 
> launches a search for the  resource-id associated to its 
> user-name, and then, it would discover that there is a Peer 
> associated to this user name already registered and which is 
> reachable. Then it would select this one.
> 
> 2- The desktop is behind a NAT. Then, the mobile phone could 
> choose between connect to this (fully trustable) peer by 
> using some NAT-Traversal strategy or connects to one offering 
> global reachabilty but in principle, not trustable.
> 
> 3- If it is the mobile phone who registers firstly, then it 
> obviously would choose one globally reachable Peer. And maybe 
> can develop some periodic discovery mechanism in order to 
> discover if the trustable Peer (that is, the desktop on the 
> example) appears at some point.
> 
> >> trust in. This introduce trust and security threads. It 
> would be nice 
> >> to define a new mechanism which allows the users to store its own 
> If my user-name is Ruben.Cuevas, I (likely) will store in the 
> DHT as resource-id the hash(Ruben.Cuevas), lets say this 
> resource-id is X. If we consider the use of a DHT system, the 
> Responsible Node for X will be the Peer with the closest 
> Peer-ID to X. Then, if I want to be the Responsible Node for 
> X, I have to obtain the closest Peer-ID. Thus, I can ask to 
> the Central Entity (in case of use a Central Entity scheme) 
> I can demonstrate I am Ruben.Cuevas (by a passwd or other 
> credentials) and the Peer-ID would be assigned. It could be 
> for instance X+1.  Then I becomes the Responsible Node for my 
> own resource-id.
> If all the users has to do the same and demonstrate their 
> credentials, all the users obtain Peer-IDs close to their own 
> resource-ids and anyone could obtain Peer-IDs with the 
> intention to starve other resources.
> 
> Replication. You can still keep the same replication scheme 
> than in the regular DHT schemes: the N closest Peer-IDs. 
> However, in this case it is easier to identify the good or 
> bad behaviour of my neighbourgs since I am the one which does 
> this task. Even more, your neighbourg should be careful in 
> make something wrong with your resource-id, since you also 
> I am off-line. Again the same. The same scheme which you use 
> in the regular DHT schemes can be applied here. If in regular 
> DHT your info is kept alive on the replicas, here you can do the same.
> 
> Clients: You have also the same problem as in regular DHTs. 
> This scheme does not modifies anything regarding to the clients.
> 
> I have not yet going into the detail of this idea, and maybe 
> it has several problems I have not yet identified. Then, it 
> is really interesing to hear from you.
> 
> Cheers,
>                  Rubén.
> 
> >> Rubén.
> >>
> >> --
> >> Rubén Cuevas Rumín

---

From: Rubén Cuevas Rumín <[email-masked]>
Date: Tue, 20 Nov 2007 16:19:01 +0100

Dear Jan,
thanks for your response.
Some coments in line

> - first, if the user can choose its user-ID (the identity), in your proposal the user could indirectly choose the location of the node-ID (the identifier). As discussed on this list, chosen-locatio…
You are right. In some scenarios the user-name can be freely  selected.  
However,  how long takes the obtention of a user-id? This is the key 
point. In other proposals we had to evaluate how long takes to get a 
Peer-ID from a CA or how long takes to autogenarete a Peer-ID. IMHO, the 
obtention of a user-id would consume more time than the other cases. 
E.g. if we suppose some of the current registration processes  where you 
ask for a user name and you have to wait until receive some confirmation 
in your email address and then confirmate the registration. I think, 
this takes more time than obtaining a Peer-ID from a CA or 
autogenerating a Peer-ID.
If the time on the assignment of the User-ID is enough large (dozens of 
seconds), since the attack cannot be automatized, I think  we are 
increasing the /security/ (the difficulty) of the attack.
> - second, your scheme assumes that there is an equal number of peers (identifiers) and users (identities). This may or may not be the case. If not, the question arises where to store my second iden…
Again you are right. As I said this is for the moment just an idea and I 
have to go into more detail. For the moment, the only thing I observe 
you can do is to register yourshelf as many peers as identities you 
have. If the number of identites that you have is reduced (two or three) 
this could be ok. However, if the number of identites you have is large 
(100 or 1000) this solution is not valid.
In addition, we can consider the possibility to have a Peer and some 
clients to solve the problem.

Another open issue is what happens if you only want to participate as a 
Peer (identifier) but not as a Resource-ID (identity) in the p2psip 
system. That is, if you only wants to look for information but not to be 
reachable.
For this cases, a possible solution is that those nodes which don't have 
an associated user-id are not going to store Resource-IDs to avoid 
security problems.

>  - Jan
I would appreciate your (Jan and all the WG) comments about this idea.

Thanks in advance.

Rubén.
>>>> The easiest way is that all of them becomes peers inside 
>>>>         
>> the p2psip 
>>     
>>>> system. But maybe ithis is not the best solution. I just 
>>>>         
>> proposed the 
>>     
>>>> possibility of use one of them as Peer and let the others 
>>>>         
>> be Clients.
>>     
>>> application level issue (is more than one UA associated 
>>>       
>> with a user) 
>>     
>>> with a routing level issue (is this a peer or client). The 
>>>       
>> two should 
>>     
>>> be independent. Personally, I think as many things as 
>>>       
>> possible should 
>>     
>>> be peers, and if all the devices you are associated with 
>>>       
>> can be peers, 
>>     
>>> devices having one as a peer and the rest as clients. The 
>>>       
>> only reasons 
>>     
>>> that I have seen presented for why a device should be a 
>>>       
>> client rather 
>>     
>>> than a peer in the first place are either the device is 
>>>       
>> behind a NAT 
>>     
>>> and cannot be a good peer, or has some limitation 
>>>       
>> (processor, battery 
>>     
>>> device becoming a peer is reachable by all the devices. In 
>>>       
>> a LAN this 
>>     
>>> may be true, but I might have 3 UAs, one at home, one at 
>>>       
>> the office, 
>>     
>>> and one a mobile device. All may be on separate networks. 
>>>       
>> Letting each 
>>     
>>> determine if it has adequate connectivity and resources to 
>>>       
>> be a peer 
>>     
>>> makes better sense than imposing an application level 
>>>       
>> decision, in my 
>>     
>>> mind.
>>>
>>>   
>>>       
>>>> On the other hand, IMO an important problem in the p2psip 
>>>>         
>> overlay is 
>>     
>>>> someone I don't know and (with the solution defined so 
>>>>         
>> far) I cannot 
>>     
>>>> "resource-IDs". It is something I am thinking about and I 
>>>>         
>> have some 
>>     
>>> like this people have made here and elsewhere over the last 
>>>       
>> few years, 
>>