Subject: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP

From: Philip Matthews <[email-masked]>
Date: Sun, 11 Nov 2007 23:32:35 -0500

Eric Cooper, Alan Johnston, and I have just submitted a new draft:
     http://www.ietf.org/internet-drafts/draft-matthews-p2psip-id- 
loc-00.txt

This draft attempts to present what we feel is the most important  
concept that P2PSIP can take from HIP: the concept of the ID/Locator  
split. This draft describes the concept and how it can be  
implemented, and argues why it is so beneficial to P2PSIP. The goal  
of this draft is to focus discussion around this concept, without  
getting distracted by the other features that HIP has.

We deliberately kept this draft short to make it an easy read (only  
14 pages). We are looking forward to the discussion.

- Philip

Here is the meta-data for the draft (from the secretariat):

Filename:	 draft-matthews-p2psip-id-loc
Revision:	 00
Title:		 An ID/Locator Architecture for P2PSIP
Creation_date:	 2007-11-11
WG ID:		 Independent Submission
Number_of_pages: 14

Abstract:
This document describes an architecture where peers in an overlay use
special IP addresses to identify other peers.  Two of the advantages
of this approach are that (a) most existing applications can run in
an overlay without needing any changes and (b) peer mobility and NAT
traversal are handled in a way that is transparent to most
applications.Terminology

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

---

From: "Wang, XiaoXiao (Sherry)" <[email-masked]>
Date: Mon, 12 Nov 2007 13:54:15 -0500

Philip,

Some minor comments:
1. Since the term "identifiers" has been used by the Host Identity
Protocol (HIP) from its beginning, which has a similar meaning as yours,
would you please coin another term to avoid confusion? Though these
protocols share the same concept as you have pointed out, but they do
not perform the same functions. It is better to use another term unless
you do mean the same thing. 

2. The benefits are not clear to me why to add one more "ID" at the
network layer besides home IP address, care-of-address, and collocated
care-of-address. I had the same question to HIP. I cannot see the
benefits of using it at the network layer for routing. I need to be
educated.

Thanks a lot,
Sherry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Sunday, November 11, 2007 11:33 PM
To: P2PSIP Mailing List
Subject: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP

This draft attempts to present what we feel is the most important
concept that P2PSIP can take from HIP: the concept of the ID/Locator
split. This draft describes the concept and how it can be implemented,
and argues why it is so beneficial to P2PSIP. The goal of this draft is
to focus discussion around this concept, without getting distracted by
the other features that HIP has.

- Philip

Abstract:
This document describes an architecture where peers in an overlay use
special IP addresses to identify other peers.  Two of the advantages of
this approach are that (a) most existing applications can run in an
overlay without needing any changes and (b) peer mobility and NAT
traversal are handled in a way that is transparent to most
applications.Terminology

---

From: Philip Matthews <[email-masked]>
Date: Mon, 12 Nov 2007 14:28:18 -0500

> you do mean the same thing.

You are right. Using just the term "identifier" was probably a bad  
choice.

Until recently, we thought that our IPv6 "identifier" was the same as  
a HIT
(Host Identity Tag in HIP). It is only recently that we have started to
question that.

So think of it as "possibly a HIT, or possibly something else".

> benefits of using it at the network layer for routing. I need to be

These identifiers are not used for routing. Instead, they identify
a node independent of where it is located.

This is particularly useful for peers behind a NAT. In a large P2PSIP  
overlay,
there will probably be hundreds of peers with IP address of 10.0.0.1.
When these peers talk to nodes outside their NAT, they will be allocated
public (IP address,port) combinations, but these can be ephemeral,
and may differ based on who the peer is talking to. So addresses are  
a really
poor way of identifying peers behind a NAT.

- Philip

---

From: "Wang, XiaoXiao (Sherry)" <[email-masked]>
Date: Mon, 12 Nov 2007 14:30:23 -0500

Philip,

Thanks. It's very helpful.

Sherry 

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Monday, November 12, 2007 2:28 PM
To: Wang, XiaoXiao (Sherry)
Cc: Zheng, Harold; Cole, Robert G.; P2PSIP Mailing List
Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP

On 12-Nov-07, at 13:54 , Wang, XiaoXiao (Sherry) wrote:

> Protocol (HIP) from its beginning, which has a similar meaning as 
> yours, would you please coin another term to avoid confusion? Though 
> these protocols share the same concept as you have pointed out, but 
> they do not perform the same functions. It is better to use another 
> term unless you do mean the same thing.

Until recently, we thought that our IPv6 "identifier" was the same as a
HIT (Host Identity Tag in HIP). It is only recently that we have started
to question that.

> benefits of using it at the network layer for routing. I need to be 

These identifiers are not used for routing. Instead, they identify a
node independent of where it is located.

This is particularly useful for peers behind a NAT. In a large P2PSIP
overlay, there will probably be hundreds of peers with IP address of
10.0.0.1.
When these peers talk to nodes outside their NAT, they will be allocated
public (IP address,port) combinations, but these can be ephemeral, and
may differ based on who the peer is talking to. So addresses are a
really poor way of identifying peers behind a NAT.

- Philip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 12 Nov 2007 12:08:45 -0800

The term commonly used in the p2p communities is <nodeID> as a hash of
some data or location.

Is there a problem using <nodeID>?

Thanks, Henry

-----Original Message-----
From: Wang, XiaoXiao (Sherry) [mailto:[email-masked]] 
Sent: Monday, November 12, 2007 12:54 PM
To: Philip Matthews; P2PSIP Mailing List
Cc: Zheng, Harold; Cole,Robert G.
Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP

Philip,

Some minor comments:

Thanks a lot,
Sherry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Sunday, November 11, 2007 11:33 PM
To: P2PSIP Mailing List
Subject: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP

- Philip

Abstract:

---

From: Philip Matthews <[email-masked]>
Date: Mon, 12 Nov 2007 15:47:09 -0500

> Is there a problem using <nodeID>?

There are actually three different concepts to deal with, and the  
challenge is to figure out their relationship.

The first is the Peer ID as defined in the Concepts draft. This ID  
uniquely identifies a peer in the overlay. In many DHTs, it also  
describes where in the overlay the peer can be found (e.g., Chord  
arranges peers in a ring based on their peer ids).

The second is the local identifier used inside an application to  
refer to a remote peer. Our draft (and HIP-HOP and WITH-HIP) all  
propose to make this identifier look like an IP address, so that  
applications can continue to use the Socket API, which allows many  
existing applications to operate without change in an overlay.

The third is the Host ID as defined by HIP. This ID uniquely  
identifies a host in the Internet, and is especially useful in  
mobility situation and when nodes are behind NATs.

So what is the relationship between these three concepts?
o   Does local identifier = peer ID?  If yes, then Peer IDs probably  
need to be globally unique, not just unique within a overlay,  
otherwise you get into problems when a peer is a member of two  
different overlays. Globally unique Peer IDs are possible, but  
present some challenges.

o   Does Host ID = Peer ID?  This is what HIP-HOP-00 proposes.  
However, Eric Rescorla argues that this opens up the overlay to Sybil  
attacks.

Right now, I am personally thinking that three of these are distinct.  
However, these questions are listed in the ID/Loc document as open  
issues.

- Philip

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 12 Nov 2007 15:56:03 -0500

When you talk about making identifiers "globally unique, not just
unique within an overlay", I get a bit confused. Technically, there is
nothing that is really making most Peer-IDs or Resource-IDs, which may
just be a hash of something, truly unique. It is simply the remote
odds (1 : 2^160, for one possible case) that makes a collision very
unlikely.

Are you looking to get something stronger from these identifiers?

David (as individual)

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Nov 2007 16:00:28 -0500

The notion of using the IP stack transparently seems dubious, as this  
would require quite a few restrictions on the identifier, leaving  
issues of how to implement this aside. I'm also doubting that this is  
useful, since we really do not want to route all packets through the  
overlay, only the first one, for efficiency reasons.

On the numbering issue: The numbering space would have to exclude
- the RFC 1918 ranges
- the local address ranges (since routing would likely direct this to  
the local interface and bypass routing)
- class E addresses

The socket call would have to say "this is a real IPv4/IPv6 address,  
not an overlay address". How? If you designate this as a different  
protocol, in parallel to IPv4 and IPv6, you could just as well use a  
node ID of any length.

Thus, I'm not convinced that this is a useful goal for an overlay  
network. Even if it can be done, all it accomplishes is making packets  
take ten hops across the Internet instead of one.

Henning

On Nov 12, 2007, at 3:47 PM, Philip Matthews wrote:

> However, Eric Rescorla argues that this opens up the overlay to  
> Sybil attacks.
>
>
> Right now, I am personally thinking that three of these are  
> distinct. However, these questions are listed in the ID/Loc document  
> as open issues.
>
> - Philip
>
>
>
>
>
>
>

---

From: Ingmar Baumgart <[email-masked]>
Date: Mon, 12 Nov 2007 22:54:50 +0100

I don't get the point why using only a single ID is a problem:

- "Local identifier = peer ID": If your choose a random (or
cryptographic) 128 bit (or better 160 bit) ID, it should be globally
unique. Of course there is still the very unlikely chance of a
collision, but this can also happen if you use the ID only within one
overlay.

- "Host ID = Peer ID": To inhibit a Sybil attack you have to limit the
generation of IDs (e.g. by using a central authority). But this problem
seems to be independent from the fact "Host ID = Peer ID", or do I miss
something?

Regards,
  Ingmar

Philip Matthews wrote:
> The second is the local identifier used inside an application to refer
> to a remote peer. Our draft (and HIP-HOP and WITH-HIP) all propose to
> make this identifier look like an IP address, so that applications can
> continue to use the Socket API, which allows many existing applications
> to operate without change in an overlay.
> 
> The third is the Host ID as defined by HIP. This ID uniquely identifies
> a host in the Internet, and is especially useful in mobility situation
> and when nodes are behind NATs.
> 
> 
> need to be globally unique, not just unique within a overlay, otherwise
> you get into problems when a peer is a member of two different overlays.
> Globally unique Peer IDs are possible, but present some challenges.
> 
> o   Does Host ID = Peer ID?  This is what HIP-HOP-00 proposes. However,
> Eric Rescorla argues that this opens up the overlay to Sybil attacks.
> 
> 
> However, these questions are listed in the ID/Loc document as open issues.
> 
> - Philip
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Nov 2007 14:06:20 -0800

At Mon, 12 Nov 2007 22:54:50 +0100,
> seems to be independent from the fact "Host ID = Peer ID", or do I miss

The issue isn't a Sybil attack. It's a chosen location attack.

If you choose peer-ids by hashing public keys, then an attacker
can choose the top X bits of the peer-id by generating
2^X keys. This doesn't sound bad because the IDs are very
long, but the relevant issue isn't the SIZE of the peer
ID but rather the distance between peer-IDs as a fraction
of the size of the peer-ID space, and that's determined
solely by the number of peers.

To take a specific case, say you're using 160-bit IDs and the
ring has 2^10 (1024) users. On average, each peer will be a
distance of 2^150 away from the next peer. Say you want to
be between peers X and X+1. If you generate a random key pair
and hash it, your chances of getting a value between X and
X+1 is approximately 2^-10. So, in order 2^10 trials you
can get a value in between those two peers. In general,
the number of trials you need scales with the number of peers,
but consider that 2^30 is an absurdly large p2p network and
yet easily within the brute force limit.

Note that this can't be fixed purely by rate limiting at some
central authority (though puzzles can help) because
the computation is performed completely offline. The fix is
to have the central authority dispense peer-ids, but then this
breaks the binding between public keys and identities which
is one of the major attractions of HIP.

-Ekr

---

From: Ingmar Baumgart <[email-masked]>
Date: Mon, 12 Nov 2007 23:59:39 +0100

Eric Rescorla wrote:
> [...]

Thank you for clarifying this. But why does this break the binding
between public key and identity?

The central authority could generate the public key pair and sign it. In
case you don't want the central authority to posses your private key,
peers could also generate the key pair on their own - in this case the
central authority would impose some kind of online crypto puzzle on
public key generation.

Regards,
  Ingmar

-- 
Dipl.-Inform. Ingmar Baumgart
Institut für Telematik, Universität Karlsruhe (TH)
Zirkel 2, 76128 Karlsruhe, Germany
Phone: +49 721 608 8281, Fax: +49 721 608 6789

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 12 Nov 2007 15:11:27 -0800

Phil,

This is a good item to clarify: 

A node ID can be the hash of a location in the DHT space (with a name
and URL) or a hash of some data, such as a voice mail sound file or a
buddy list. 

The key is that both locations and data items are placed in the same
hash space and identified there with the node ID.

What have the authors of the concept draft and everyone else to say
here?

Some well wordsmithed text and examples would be very welcome here.

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Monday, November 12, 2007 2:47 PM
To: Henry Sinnreich
Cc: Wang, XiaoXiao (Sherry); P2PSIP Mailing List; Zheng, Harold;
Cole,Robert G.

- Philip

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Nov 2007 15:41:38 -0800

At Mon, 12 Nov 2007 23:59:39 +0100,
> central authority would impose some kind of online crypto puzzle on

So, the idea in HIP is to let the node self-generate their own identity
by generating a random cryptographic key and then using the digest of
the key as an identifier. This allows for a strong binding between
the identifier and your cryptographic keying material without any
central authority, because it's impractical for an attacker to generate
another key with the same identifier. So, as long as you can get
your hands on the identifier securely, the system doesn't need a
central authority.

The reason this doesn't work in P2P systems is that it's not
sufficient to force the attacker not to generate a *specific*
digest postimage, but rather you need to stop them from generating
a range of postimages, which radically reduces the complexity of
the problem. 

The system you describe has a central authority. At that point, there's
no value in having the peer-id derived from the key because you need
to certificate to validate the key. You might as well just shove
the peer-id in the cert. 

-Ekr

---

From: Zheng Hewen <[email-masked]>
Date: Tue, 13 Nov 2007 10:31:25 +0800

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: 2007?11?13? 5:00
To: Philip Matthews
Cc: Zheng, Harold; Henry Sinnreich; Cole, Robert G.; Wang, XiaoXiao (Sherry); P2PSIP Mailing List
Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP

The notion of using the IP stack transparently seems dubious, as this would require quite a few restrictions on the
identifier, leaving issues of how to implement this aside. I'm also doubting that this is useful, since we really do not
want to route all packets through the overlay, only the first one, for efficiency reasons.

On the numbering issue: The numbering space would have to exclude
- the RFC 1918 ranges
- the local address ranges (since routing would likely direct this to the local interface and bypass routing)
- class E addresses

The socket call would have to say "this is a real IPv4/IPv6 address, not an overlay address". How? If you designate this as
a different protocol, in parallel to IPv4 and IPv6, you could just as well use a node ID of any length.

Thus, I'm not convinced that this is a useful goal for an overlay network. Even if it can be done, all it accomplishes is
making packets take ten hops across the Internet instead of one.

Henning

On Nov 12, 2007, at 3:47 PM, Philip Matthews wrote:

>> The term commonly used in the p2p communities is <nodeID> as a hash
>> of some data or location.
>>
> continue to use the Socket API, which allows many existing
> applications to operate without change in an overlay.
>

---

From: Zheng Hewen <[email-masked]>
Date: Tue, 13 Nov 2007 10:45:26 +0800

Hi,

     Agree.
     Here is only my personal viewpoint, I think that the overhead and applicability need further consideration though I
believe that HIP can solve some problems in traditional addressing architecture.
     It would be difficult  before modifying the traditional addressing and forwarding framework until we can show strong
and obvious benefits than introduced overhead, maybe MPLS is an example.

Best regards,
Hewen

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: 2007?11?13? 5:00
To: Philip Matthews
Cc: Zheng, Harold; Henry Sinnreich; Cole, Robert G.; Wang, XiaoXiao (Sherry); P2PSIP Mailing List
Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP

Henning

---

From: Ali Fessi <[email-masked]>
Date: Tue, 13 Nov 2007 11:06:39 +0100

Eric, Ingmar, all,

the peer-ID needs to be chosen by a central authority (in order to avoid 
both Sybil attacks and "chosen location" attacks). In HIP, the public 
key needs to be chosen by the peer itself. So, if you want to use HIP, 
you *can not* use the HIT as peer-ID. You should rather append the 
peer-id in the certificate.

This actually makes HIP less attractive for P2PSIP.

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: "Jani Hautakorpi (JO/LMF)" <[email-masked]>
Date: Tue, 13 Nov 2007 13:51:20 +0200

Hi Ali et all,

> peer-id in the certificate.

Well, you *could use* HIT as a peer-ID, because nothing (in HIP)
prevents using such private/public key pair which is generated by
someone else than the peer itself, e.g. by a central authority.

As I see the peer-ID assignment, there are two separate scenarios:

1. There is a central authority: In this case central authority can
    assign peer-IDs to peers. This is more secure way of assigning
    peer-IDs that the scenario #2, but this has one major downside: If
    there are multiple P2PSIP domains, a PKI-like structure is required.

2. There is no central authority: In this case the next-best-thing would
    be to use peer-IDs which are derived from self-generated
    private/public key pairs. It is true that this is not nearly as
    secure that scenario #1, but this eases the deployment.

-- 
Jani

---

From: Ingmar Baumgart <[email-masked]>
Date: Tue, 13 Nov 2007 14:05:40 +0100

> to certificate to validate the key. You might as well just shove

One reason to use H(Kpub) as nodeID even with a central authority is
that you can get rid of the central authority as soon as the network is
large enough. In this case the central authority is only used to
initially bootstrap the overlay.

Regards,
  Ingmar

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Nov 2007 06:42:54 -0800

At Tue, 13 Nov 2007 13:51:20 +0200,
>     there are multiple P2PSIP domains, a PKI-like structure is required.

This *still* needs a PKI-like structure because there's no way to
distinguish valid from invalid key pairs, at least for conventional
cryptographic tecniques like RSA. (You can with unconventional
techniques like IBE and IBS.)

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Nov 2007 06:44:07 -0800

At Tue, 13 Nov 2007 14:05:40 +0100,
Ingmar Baumgart wrote:
> large enough.

I don't see why this is true. Even for extraordinarily large networks
(2^32) the work factor fo finding a peer-id between two randomly chosen
peers is only the size of the network (2^32) which is quite brute
forceable.

-Ekr

---

From: Philip Matthews <[email-masked]>
Date: Tue, 13 Nov 2007 10:01:55 -0500

One of the goals of this work is to get many existing applications to  
work in an overlay without change. The vast majority of applications  
today use IPv4, so if we can make this work for IPv4, there is a huge  
win.

So for IPv4, the idea is to allocate an address from a special IPv4  
address range to identify a remote peer. (HIP implementations today  
use 1.0.0.0/8 which is currently marked "reserved"; but I suspect  
that we would only get a /14 or /16 allocated to us for this  
purpose). In the draft, we call this just an "identifier".

Because this range is so small, this identifier cannot be a Peer Id.  
Instead, this number has only local significance, and identifies a  
remote peer that the local peer is interested in talking to. The P2P  
layer stores the mapping of this identifier to the actual Peer ID of  
the remote peer, and also the real address and port that it can be  
reached at.

When an application sends a packet to the remote peer, the Shim layer  
replaces the identifier  by the real address and port of the  
destination.

For IPv6, the address range we are likely to get is much larger, so  
we can potentially use a different scheme. With IPv6, there is the  
option that the identifier could be the same as the Peer ID, or the  
same as the Host ID.

- Philip

On 12-Nov-07, at 16:54 , Ingmar Baumgart wrote:

>> refer
>> identifies
>> otherwise
>> However,

---

From: Philip Matthews <[email-masked]>
Date: Tue, 13 Nov 2007 10:09:31 -0500

On 12-Nov-07, at 16:00 , Henning Schulzrinne wrote:

> The notion of using the IP stack transparently seems dubious, as  
> this would require quite a few restrictions on the identifier,  
> leaving issues of how to implement this aside. I'm also doubting  
> that this is useful, since we really do not want to route all  
> packets through the overlay, only the first one, for efficiency  
> reasons.
>
> - the local address ranges (since routing would likely direct this  
> to the local interface and bypass routing)
> - class E addresses
>
> The socket call would have to say "this is a real IPv4/IPv6  
> address, not an overlay address". How? If you designate this as a  
> different protocol, in parallel to IPv4 and IPv6, you could just as  
> well use a node ID of any length.
>
> network. Even if it can be done, all it accomplishes is making  
> packets take ten hops across the Internet instead of one.
>
> Henning

Hi Henning:

Sorry for not being clearer in the document. The goal of this work is  
not to route all packets through the overlay. On the contrary, the  
goal is to have the vast majority of packets go directly from the  
originator to the destination, without passing through intermediate  
peers.

The signaling to set up a direct connection needs to be routed  
through the overlay in many cases. But once that direct connection is  
set up, packets can flow directly.

For IPv4, the identifier is of local significance only, and is mapped  
to the real address and port of the destination before the packet is  
transmitted.

I have already discussed the numbering issue in a separate reply. But  
the short answer is that we can probably get away with a /14 or /16  
for the IPv4 identifier.  This I think we have a reasonable chance of  
getting allocated to us.

- Philip

---

From: Ingmar Baumgart <[email-masked]>
Date: Tue, 13 Nov 2007 16:13:21 +0100

> peers is only the size of the network (2^32) which is quite brute

It depends on your attacker model. If your make your crypto puzzle hard
enough (lets say 3 hours to generate a valid nodeID on an average
desktop PC) 2^32 is hard to brute-force for most attackers.

The question is: If there is no central authority, what level of
security can we achieve and is this sufficient for our use case?

A completely decentralized network will never reach the same level of
security that you can achieve with a trustworthy authority.

Regards,
  Ingmar

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 13 Nov 2007 10:14:31 -0500

I read the draft, and the point you touch on below (things using the
overlay without the application knowing about it) is actually one of
the things I most confused about.

I can understand how this can help with overlay routing -- in other
words, if you want to route each and every message via the overlay,
that could be done with no change to the application. (but I don't
think we want to route all messages through the overlay -- that seems
very inefficient in cases where a direct connection can be used)

However, if the overlay is being used as storage mechanism, I don't
get how it is transparent at all. How would this work for the SIP
application, for example? It would still want to have an address of a
default proxy, would still want to send registrations to a particular
registrar, etc. You would still need to know that the
lookup/registration process is very different with a P2PSIP
deployment.

If you are doing file sharing applications, the application would
still need to know to hash/do lookup of where the file is, then get
the location to fetch the file...

I don't see how we really get any applications "for free" in this case.

David (as individual)

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

---

From: Philip Matthews <[email-masked]>
Date: Tue, 13 Nov 2007 10:17:00 -0500

> is one of the major attractions of HIP.

I have heard some counter-arguments to this, from someone who knows a  
lot more about security than I do.

Never-the-less, this is one of the reasons that I am thinking now  
that a Host ID should not be the same as the Peer ID. This would  
allow a node to use, for example, the procedures of HIP to generate a  
Host ID, but still go to a central authority to allocate a Peer ID to  
use in a particular overlay.

- Philip

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 13 Nov 2007 10:29:40 -0500

> desktop PC) 2^32 is hard to brute-force for most attackers.

I think you hit the main problem I see with crypto puzzles here. What
is an average peer? If you say an "average" desktop PC, then solving a
similar puzzle will be very hard for VoIP or wireless handset, or some
other embedded device. If you assume it is just PCs, then those of us
who have access to super computer clusters of low hundreds of machines
(and I suspect there are many people who qualify) can still do it. A
similar, and more sinister, argument applies to people who have bot
nets.

> security can we achieve and is this sufficient for our use case?

I personally think that we allow for a lower security mechanism --
perhaps a simple shared secret -- that can be used for small, ad-hoc
deployments, but would argue that finding a good secure distributed
security mechanism that assures unique user names is very difficult.
So difficult, in fact, it was explicitly excluded from our work in the
charter to ensure we were working on solvable, engineering problems.

David (as individual)

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

---

From: "Wang, XiaoXiao (Sherry)" <[email-masked]>
Date: Tue, 13 Nov 2007 10:41:22 -0500

Philip,

My understandings are:
1. security has a lifespan, we do not need a life-time protection,
instead we only need a mechanism that can update information, e.g. keys,
faster enough to keep signaling packets save for the time of a session
setup.

2. the goal or appealing feature of the P2P is de-centralize. Usually,
P2P is for networks such as ad hoc, wireless, mobile, tactical, etc. a
centralized solution is very hard to be successful.  

3. I agree with you that the overlay is just for signaling to find
peers. After that, data packets go to a direct media path, which makes
the P2P functions much clear.

Please let me know if I went to a wrong direction.

Thanks,
Sherry   

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 10:17 AM
To: Eric Rescorla
Cc: Ingmar Baumgart; Wang, XiaoXiao (Sherry); Cole, Robert G.; P2PSIP
Mailing List; Zheng, Harold; Henry Sinnreich
Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP

On 12-Nov-07, at 17:06 , Eric Rescorla wrote:

>> - "Host ID = Peer ID": To inhibit a Sybil attack you have to limit 
>> the generation of IDs (e.g. by using a central authority). But this 
>> problem seems to be independent from the fact "Host ID = Peer ID", or

>> do I miss something?
> If you choose peer-ids by hashing public keys, then an attacker can 
> choose the top X bits of the peer-id by generating 2^X keys. This 
> doesn't sound bad because the IDs are very long, but the relevant 
> issue isn't the SIZE of the peer ID but rather the distance between 
> peer-IDs as a fraction of the size of the peer-ID space, and that's 
> determined solely by the number of peers.
>
> To take a specific case, say you're using 160-bit IDs and the ring has

> 2^10 (1024) users. On average, each peer will be a distance of 2^150 
> away from the next peer. Say you want to be between peers X and X+1. 
> If you generate a random key pair and hash it, your chances of getting

> a value between X and
> can get a value in between those two peers. In general, the number of 
> trials you need scales with the number of peers, but consider that 
> 2^30 is an absurdly large p2p network and yet easily within the brute 
> force limit.
>
> Note that this can't be fixed purely by rate limiting at some central 
> authority (though puzzles can help) because the computation is 
> performed completely offline. The fix is to have the central authority

> dispense peer-ids, but then this breaks the binding between public 
> keys and identities which is one of the major attractions of HIP.
>
> -Ekr

Never-the-less, this is one of the reasons that I am thinking now that a
Host ID should not be the same as the Peer ID. This would allow a node
to use, for example, the procedures of HIP to generate a Host ID, but
still go to a central authority to allocate a Peer ID to use in a
particular overlay.

- Philip

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Nov 2007 07:37:36 -0800

At Tue, 13 Nov 2007 16:13:21 +0100,
> desktop PC) 2^32 is hard to brute-force for most attackers.

With the consequence that nobody on a limited-capability device
(like a phone handset) can do the puzzle at all

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Nov 2007 07:38:35 -0800

At Tue, 13 Nov 2007 10:17:00 -0500,
Philip Matthews wrote:
> >> the

Well, I'd certainly be interested in hearing them. I could of
course be wrong but it's not exactly a complicated line of
reasoning.

-Ekr

---

From: Ingmar Baumgart <[email-masked]>
Date: Tue, 13 Nov 2007 16:50:53 +0100

> (like a phone handset) can do the puzzle at all

You could generate the nodeID on a desktop PC and then transfer the key
pair to your phone.

Regards,
  Ingmar

---

From: Philip Matthews <[email-masked]>
Date: Tue, 13 Nov 2007 11:00:08 -0500

> I don't see how we really get any applications "for free" in this  

Hi David:

First of all, just to be clear, I absolutely DO NOT want to route  
every packet through the overlay. In fact, I believe that the most  
common case, by far, will be to set up a direct connection to the  
remote peer and send packets over that direct connection. The packets  
I see as being routed through the overlay are: (a) Put and Get  
operations on the distributed database, (b) other searches (e.g., for  
the admitting peer), (c) signaling packets to set up direct  
connections (when other approaches don't work), and (d) perhaps SOME  
application data in cases where only a small number of packets are  
needed (details TBD).  So the general idea that we had in "NAT  
Traversal for dSIP" still applies.

Second, applications that take advantage of special services that the  
overlay provides (e.g., the distributed database) will probably need  
to be modified. In particular, if SIP wants to use the distributed  
location service, your SIP UA code probably needs modifications  
(though there may be ways to avoid this).

To illustrate an application that would not require any modification,  
consider the following variation on the example given in the  
document.  In the example, there are three machines (names "venus",  
"earth", and "mars") which are part of a larger overlay (called  
"solar-system.p2p"). Assume all three machines are located behind  
different NATs. Now imagine a web browser on venus and a web server  
on mars. Ordinarily, the web browser would have no way to contact the  
web server without using something like dynamic DNS, and even with  
dynamic DNS, mars's NAT has to have the 'endpoint-independent  
filtering' property.

But with the scheme described in the document, a user on venus can  
type in "http://mars.solar-system.p2p" into her web browser to  
contact the web server on mars. No modification to the web browser  
code is required. The call flow to make this work is very similar to  
that given in the example.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Tue, 13 Nov 2007 11:15:42 -0500

> course be wrong but it's not exactly a complicated line of

It was Marcus Leech who I was having this discussion with. I have  
copied him so he can chime in.

His arguments as I recall went roughly as follows.

Even having a central authority to allocate peer ids doesn't prevent  
this attack. An attacker can go to the central authority, ask for a  
peer id, and if he doesn't like the results, generate a new identity  
and go back and ask for a new peer id.

The root of the question is: how to you positively identify someone  
who wants to join? In a large open P2P system, you cannot possibly  
know the actual identities of everyone who is trying to join. For  
Skype, for example, all an attacker needs to do is think up a new  
Skype login name. For other systems, you need a valid e-mail address,  
but generating lots of e-mail addresses isn't hard either.

There was more, but this was the part that I remember.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Tue, 13 Nov 2007 11:25:35 -0500

You can ignore this comment.
I see that Marcus has already replied in a separate thread.

- Philip

On 13-Nov-07, at 11:15 , Philip Matthews wrote:

> Even having a central authority to allocate peer ids doesn't  
> prevent this attack. An attacker can go to the central authority,  
> ask for a peer id, and if he doesn't like the results, generate a  
> new identity and go back and ask for a new peer id.
>
> Skype login name. For other systems, you need a valid e-mail  
> address, but generating lots of e-mail addresses isn't hard either.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 Nov 2007 11:25:08 -0500

This is probably less of concern for this application. Mobile, low- 
power devices are not likely to make good peers, except in small ad- 
hoc style networks, where PoW probably isn't the right approach in any  
event. (Not that I'm defending use of PoW, as per my previous note.)

---

From: "Marcus Leech" <[email-masked]>
Date: Tue, 13 Nov 2007 11:17:56 -0500

I sent a message a few messages back on this.

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 11:16 AM
To: Eric Rescorla
Cc: P2PSIP Mailing List; Leech, Marcus (CAR:1A12)
Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP

> Well, I'd certainly be interested in hearing them. I could of course 
> be wrong but it's not exactly a complicated line of reasoning.

It was Marcus Leech who I was having this discussion with. I have copied
him so he can chime in.

Even having a central authority to allocate peer ids doesn't prevent
this attack. An attacker can go to the central authority, ask for a peer
id, and if he doesn't like the results, generate a new identity and go
back and ask for a new peer id.

The root of the question is: how to you positively identify someone who
wants to join? In a large open P2P system, you cannot possibly know the
actual identities of everyone who is trying to join. For Skype, for
example, all an attacker needs to do is think up a new Skype login name.
For other systems, you need a valid e-mail address, but generating lots
of e-mail addresses isn't hard either.

- Philip

---

From: "Wang, XiaoXiao (Sherry)" <[email-masked]>
Date: Tue, 13 Nov 2007 11:30:08 -0500

How about a tank? 

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 11:25 AM
To: Eric Rescorla
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP

This is probably less of concern for this application. Mobile, low-
power devices are not likely to make good peers, except in small ad- hoc
style networks, where PoW probably isn't the right approach in any
event. (Not that I'm defending use of PoW, as per my previous note.)

> With the consequence that nobody on a limited-capability device (like 
> a phone handset) can do the puzzle at all
>
> -Ekr
>
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 13 Nov 2007 08:30:37 -0800

Philip,

I had a few comments on your draft:

>       OPEN ISSUE: What is the scope of this identifier (e.g., local
node
>       only, overlay-wide, or global)?  The IPv4 identifiers probably
>       have to be local, since are not enough to be global and maybe
not
>       enough to be overlay-wide.  The IPv6 identifiers could be global
>       (and be either identical to, or similar to, HIP's Host Identity
>       Tags (HITs)) or they could be just overlay-wide, however, either
>       would introduce a difference between the IPv4 and IPv6
identifiers
>       which might be undesirable.

It seems to me that the question of what should be the scope of the
identifier is determined by its usage and not its size.  If they are
identifying other peers in this system, I would think that they have to
be global (in the context of this system) and not local?

>    If either X or Y change their real address, then an ICE exchange is
>    required to determine a new 5-tuple for each connection.  For UDP,
>    this new 5-tuple is simply used in place of the old.
>
>       OPEN ISSUE: For TCP, this doesn't work, since generating the new
>       5-tuple requires a new TCP handshake.  This seems to imply that
>       the TCP layer has to be aware of the change in address.  So what
>       do we do?  Do we just say "don't use null encapsulation for TCP
if
>       you want mobility to work"?  Or do we figure out how to make
this
>       work?

The above (requiring TCP to resend a SYN exchange) seems to be fairly
problematic from a deployment perspective.

>    Briefly, the idea is to define a new top-level domain, called
".p2p".
>    This domain is reserved for use in peer-to-peer overlays.  An
overlay
>    is then given a name underneath this top-level domain:
>
>       <overlay-name>.p2p
>

During recent review of our HIP applications draft* (which, by the way,
discusses a lot of issues raised by this draft regarding the usage of
identifiers by legacy applications), the above technique (creating a new
private TLD) was frowned upon by the DNS directorate because it may
cause root queries when leaked out of the system.  Thomas Narten
suggested that a prefix (rather than suffix) that was terminated by
another special character than the dot (such as "p2p-") would be
preferable, and we are going with that approach in the revision that
will be published shortly.   

* https://datatracker.ietf.org/drafts/draft-ietf-hip-applications/

>    The fundamental concept in this document, that of an identifier for
a
>    node which is distinct from the node's real addresses, has been
>    adopted from HIP.  In HIP, this identifier (known as a HIT
>    [HIP-Base])is always an IPv6 identifier, and has global scope and
>    cryptographic properties, making it computationally hard for an
>    second node to steal a node's identity.  (Current HIP
implementations
>    also implement an IPv4 identifier as a local identifier, but the
>    properties of this IPv4 identifier are not currently specified
>    anywhere).

The IPv4 identifier in HIP (the Local Scope Identifier) is just a 32-bit
quantity that can be used as a local alias for a HIT.  It should never
be sent on the wire but can be used in the APIs and kernel data
structures.  It is possible also to have the same for IPv6 (a 128-bit
LSI) but one might as well use the HIT, and when a HIT is used instead,
one can basically support IPsec channel bindings to the application
layer, as defined by the BTNS working group. 

>    HIP also introduces a number of other concepts, whose applicability
>    to p2p overlays is less obvious.
>
>    The first is the use of ESP.  In HIP, all data packets flowing
>    between two nodes use ESP to encrypt and integrity protect the
>    traffic [HIP-ESP].  At present, this is done for all traffic, even
if
>    the traffic is already protected at a higher layer (e.g., using TLS
>    or application-level encryption).  Does we want to encrypt and
>    integrity-protect *all* traffic, or should this decision be made on
a
>    per-application basis?  Do we want some way to avoid double
>    encryption: if so, how is this done?

There have been previous suggestions to define an SRTP encapsulation for
HIP, but not yet taken as a charter item for HIP WG:
https://datatracker.ietf.org/drafts/draft-tschofenig-hiprg-hip-srtp/

>    The second is the use of computational puzzles to prevent denial of
>    service attacks.  Since all traffic is encrypted, when setting up a
>    HIP connection the two endpoints do a Diffie-Hellman exchange to
>    agree on a shared encryption key.  Since this is computationally
>    expensive, the node initiating the connection must first solve a
>    computational puzzle generated by the destination, in order to make
>    it more difficult for a hostile initiator to cause the destination
to
>    do a lot of work.  However, it is not immediately clear how to
extend
>    this concept to a peer-to-peer overlay where there are many more
>    connections involved and the different ways of launching denial-of-
>    service attacks seem larger.

I think the above is mixing the discussion of two separate mechanisms:
D-H exchange and client puzzles.  The client (initiator) puzzles can be
easily disabled if the server (responder) does not care about
rate-limiting the clients.  

>    Finally, HIP has its own signaling protocol (also called HIP), and
>    the proper relationship of that protocol to the Peer Protocol is
not
>    immediately clear.  Should the functionality of HIP simply be added
>    to the Peer Protocol?  Should HIP signaling be kept as a distinct
>    protocol and carried inside Peer Protocol messages (as proposed in
>    [WITH-HIP])?  Or should HIP signaling be used to create connections
>    in the overlay instead of the Peer Protocol (as proposed in
>    [HIP-HOP])?

My view is that the HIP protocol is a means to an end of getting two
peers into a state where they have mutually authenticated one another
(if they care to do so) and have enough shared secrets to prevent
attacks on their network-layer mechanisms.  If there is some other
preferred means by which to get to this state that makes sense for
particular applications, I would not have a problem with adapting or
avoiding HIP signalling.

However, the property of HIP that seems to have been lost in this
proposal is the property that these identifiers cannot be hijacked.  It
seems like this approach is abandoning the good (security) aspects of
HITs while leaving the bad (that they are pseudo-random bit fields and
therefore difficult to aggregate, to look up in a hierarchical database,
and to type in or remember).  In other words, if you want to abandon the
crypto properties of HITs, why not have applications use readable
strings such as URIs as identifiers and simply define a way to hash such
strings to address-sized values for use at the legacy socket APIs?  (I
think others have been providing similar feedback)

Another question I have is what are the incremental deployment
considerations of this approach?  Does the P2PSIP app have to be able to
work on a host that does not implement this shim?  If not, could you
make the assumption that the P2PSIP app is required to support IPv6
socket API and forget about IPv4?

Regards,
Tom

---

From: Philip Matthews <[email-masked]>
Date: Tue, 13 Nov 2007 11:18:41 -0500

> techniques like IBE and IBS.)

Can you provide more detail on this? What do you mean by a valid vs  
invalid key pair?  If I encrypt something with someone's public key,  
and that person proves to me that he can decrypt it (say by  
decrypting it and then re-encrypting it with my public key), then  
doesn't that show the key pair is valid?

- Philip

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 13 Nov 2007 08:43:56 -0800

> Sent: Monday, November 12, 2007 1:00 PM
> To: Philip Matthews
> Cc: Zheng, Harold; Henry Sinnreich; Cole,Robert G.; 
> Wang,XiaoXiao (Sherry); P2PSIP Mailing List

I did not read that the proposal was to make all packets traverse the
overlay.  Only the initial-contact and rendezvous-related packets need
to traverse the overlay, but ICE is used to find the right addresses and
ports to later avoid the overlay.

FWIW, HIP implementations work this way and there have been other
overlay implementations such as i3, TESLA, and UIP that have
successfully worked in this manner.

> the local interface and bypass routing)

There has already been an IPv6 prefix assigned for these types of
identifiers (see ORCHIDs in RFC 4843).

> protocol, in parallel to IPv4 and IPv6, you could just as well use a  

Either the socket API has to be extended, or the API could be kept the
same if such "addresses" can be distinguished from other IPv6 addresses,
such as ORCHIDs.

Tom

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 13 Nov 2007 12:02:19 -0500

This severely limits the size of the overlay; this also requires  
modifying the kernel in rather significant ways, which seems to be a  
lot harder to deploy than a new application. I admit that I find the  
DNS model, namely treating the DHT as a naming translator, to be far  
more general than a NAT model. Given the presentations about address  
shortages, I also don't share your enthusiasm that the RIRs will hand  
out address blocks for non-routing applications.

I admit that I find this whole approach to be a hack, since you're  
making something look like something that it is not. Since routing  
packets is only a small fraction of what an IP stack does, you now  
have to worry about interactions with ipfilter, DHCP, ICMP, ARP and a  
host of other protocols and stack assumptions.

If we want to treat this as equivalent of a VPN, using an IPv6 range  
seems far more productive.

Henning

On Nov 13, 2007, at 10:09 AM, Philip Matthews wrote:

>
> Hi Henning:
>
> Sorry for not being clearer in the document. The goal of this work  
> is not to route all packets through the overlay. On the contrary,  
> the goal is to have the vast majority of packets go directly from  
> the originator to the destination, without passing through  
> intermediate peers.
>
> through the overlay in many cases. But once that direct connection  
> is set up, packets can flow directly.
>
> For IPv4, the identifier is of local significance only, and is  
> mapped to the real address and port of the destination before the  
> packet is transmitted.
>
> I have already discussed the numbering issue in a separate reply.  
> But the short answer is that we can probably get away with a /14 or / 
> 16 for the IPv4 identifier.  This I think we have a reasonable  
> chance of getting allocated to us.
>
> - Philip
>
>
>

---

From: Philip Matthews <[email-masked]>
Date: Tue, 13 Nov 2007 12:55:20 -0500

This doesn't limit the size of the overlay, since a peer only needs  
to assign identifiers to remote peers that it wants to talk to. This  
is why I think the IPv4 identifier needs to be distinct from the Peer  
ID.

Though a kernel implementation is clearly a desirable long-term  
approach, two other short-term approaches are possible. One is an  
approach where the packet is intercepted below the IP layer and sent  
to a user-space process for modification. Tom Henderson's group at  
Boeing has implemented HIP on both OS X and Windows using this  
technique.
The other is to use a library implementation of TCP/UDP/...

But I agree that IPv6 offers the possibility of a much more  
architecturally pure solution, and supporting IPv4 identifiers is a  
bit of a hack. But the IPv4 hacks seem very attractive because of the  
potential gains.

- Philip

On 13-Nov-07, at 12:02 , Henning Schulzrinne wrote:

> modifying the kernel in rather significant ways, which seems to be  
> a lot harder to deploy than a new application. I admit that I find  
> the DNS model, namely treating the DHT as a naming translator, to  
> be far more general than a NAT model. Given the presentations about  
> address shortages, I also don't share your enthusiasm that the RIRs  
> will hand out address blocks for non-routing applications.
>
> have to worry about interactions with ipfilter, DHCP, ICMP, ARP and  
> a host of other protocols and stack assumptions.
>
> If we want to treat this as equivalent of a VPN, using an IPv6  
> range seems far more productive.
>
> Henning
>
>> But the short answer is that we can probably get away with a /14  
>> or /16 for the IPv4 identifier.  This I think we have a reasonable