Subject: [P2PSIP] Comments on draft-jennings-p2psip-security-00

From: Philip Matthews <[email-masked]>
Date: Thu, 8 Mar 2007 19:37:27 -0500

Hi Cullen:

I read your draft on security draft-jennings-p2psip-security-00.
and thought it had some interesting ideas.
Here are some comments and questions that I have.
I have adopted Spencer's style of mixing paragraphs from the document
with embedded comments prefixed by "Philip:"

- Philip

------------
[snip]
    When a client wants to store some information in a record, they sent
    a request that has:  their AOR, the record type name, the time, the
    data to store in the record, and MUST include a signature over all
    that information.  When a peer goes to store the information, it  
MUST

Philip: When you say "client" and "peer", are you using these terms as
defined in the P2PSIP Concepts document? My guess is that you
are using the word "client" in the SIP meaning, not in the P2PSIP  
meaning.

    check that the signature is correct.  It SHOULD also check that the
    data looks appropriate for this type of record given by checking
    things like the size of the data is in an appropriate range.  When a
    client retrieves data out of the DHT, it retrieves all the
    information that was signed and SHOULD verify the signature on the
    data.

Philip: This seems similar to the proposal in draft-singh-p2p-sip-01.
Can you comment on this?

    Open Issue:  how do we want to deal with checking time and also does
    the data have a Time To Live (TTL).

    Open Issue:  do we pass the certificate with the signature or do we
    provide some alternative scheme to get the certificates.  I am
    leaning towards pass the certificate along with the signature.  A
    problem with this is the message size.  A possible problem with not

Philip: Are your worried about size in sending the message or in storing
the data?  That is, if we used for example TCP transport (i.e., not  
UDP),
then would your concerns go away?

    doing it is that the signature are used to verify the constructions
    of the routing architecture and assuming that the routing
    architecture is in place before a signature can be checked may lead
    to problems.

4.  Routing Protection Architecture

    The goal of protecting the routing is stopping attacker from
    performing a DOS attack on they system by misrouting requests in the
    DHT.  The data is already protected by the data protection scheme
    above so an attacker can't tamper with the data in a way the user
    can't detect but an attacker can make it look like no data is
    available.  There are a few obvious observation to make about this.
    First, it is easy to ensure that attacker at least has to have an
    valid enrollment with this particular DHT.  Second, this is a DOS
    attack and the value of successfully executing it is fairly low.
    Third, if a larger percentage of the peers on the DHT are controlled
    by the attacker, it is probably impossible to perfectly secure this.

    When a peer sends a request that modifies the routing in the DHT, it
    MUST sign the request on behalf of a user that is currently
    responsible for the peer using that users certificate.  A peer that
    is changing the routing state based on this request to check the
    signature before performing the request.

Philip: There are a number of things I don't understand here.
Can you give some examples of what you mean by
"a request that modified the routing"?  For example, do you mean
"setting up a new Peer Protocol connection"?
And how does signing such requests help prevent DOS attacks?
I can see how it might help us catch the peer that did the attack,
but this is very much after the fact.
Finally, why sign this with a user's certificate? Why not sign this
with the certificate of the peer? (As documented in Concepts-04,
we have already agreed that peers must have certificates to
join the overlay.)

    To reduce attacks on routing, the design tries to limit the ability
    of an attacker to place peers at arbitrary locations in the DHT.
    Some possible ways to do this are:

    L1:  Limiting IP addresses:  Other systems have done this by forcing
         the peer id to be a hash of a combination of the peers IP and
         port however this approach does not work with IPv6 where the
         users have an arbitrary number of IP addresses and the  
scheme is
         also difficult to make work with IPv4 and NATs.
    L2:  Limiting by AOR:  The first step to doing this is limiting the
         number of AORs an attacker can enroll in the system.  How to do
         this is out of scope.  The next step would be forcing a peer ID
         to have the high order bits formed from an hash of the AOR and
         some low order bits chosen randomly or hashed from the IP
         address and port.  Peers would check the Peer ID was  
appropriate
         for the given users that signed the request.

Philip: What do you see as the AOR of a peer? Are you thinking of
the scheme you, Bruce, and David are using in the dSIP draft?
If so, I don't quite see how this would work. It seems that your peer-id
would depend on itself.
[For other readers of this message, those URIs look like:
           peer@<hostport>; peer-id=<peerid>
where <hostport> is an IP address and port and <peerid> is a peer-id].
Moreover, the other unique part is the <hostport>, so this falls back to
option L1.

    L3:  Limited by assignment at enrollment:  When enrolling, the user
         would be given a small set of peer IDs for their use.  This is
         effectively equivalent to Limited by AOR but has the addition
         complexity of the certificates become more complex as a peer
         would need to sign with the appropriate peer id as well as the
         AOR.

5.  Mapping to SIP

    There are several ways this could be mapped to SIP.

Philip: Is this section making the assumption that the Peer Protocol
is SIP? Otherwise, I don't understand what this has to do with SIP.

Jennings                 Expires August 28, 2007                [Page 6]
Internet-Draft               P2PSIP Security               February 2007

Full Copyright Statement

    Copyright (C) The IETF Trust (2007).

    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights.

    This document and the information contained herein are provided  
on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE  
REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST  
AND
    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE  
USE OF
    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be  
claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.   
Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the  
use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR  
repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    [email-masked].

Acknowledgment

    Funding for the RFC Editor function is provided by the IETF
    Administrative Support Activity (IASA).

Jennings                 Expires August 28, 2007                [Page 7]

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

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 9 Mar 2007 12:36:18 -0800

> with embedded comments prefixed by "Philip:"

I was trying to stay consistent with the Concepts document but I'm  
sure I messed up in places. Any help fixing up my terminology would  
be much appreciated.

> Philip: This seems similar to the proposal in draft-singh-p2p-sip-01.
Uh, no comment :-) seriously - I have not read latest version of  
singh yet but I will read it  before the meeting - I'm not at all  
surprised that they would have same thing - we talked about this at  
some of the prior meetings

> then would your concerns go away?

Well there are many ways we could skin this cat - in the end I  
suspect that the what works best for NAT traversal will be the  
dominating factor for choosing the design.

> Philip: There are a number of things I don't understand here.
yah - it is poorly written

> "setting up a new Peer Protocol connection"?
I mean a peer protocol messages that changes the finger table (or  
whatever that's DHTs equivalent is for the things the DHT uses to  
decide how to route requests and DHT update messages)

> but this is very much after the fact.
I think the after the fact sill has significant value - particularly  
if you have a way of slowly revoking the account. You can also do  
things where nodes can detect one user trying to be many things at  
once when it actually should only be one things and this makes it  
harder to hijack large portions of the DHT search space.

> we have already agreed that peers must have certificates to

Uh agree and disagree here. I have not heard anyone explain why we  
need both peer and users certificates so I am assuming that where you  
need a peer certificate, you just use the user certificate for some  
users that is authorizing the peer to use it. The problem with peer  
certificates has to do do with what their names are.  If we don't  
need to introduce a whole new security namespace for peers, it is  
easier to just have users certificates.

> Philip: What do you see as the AOR of a peer?
I have no idea which is exactly one of the reason I would rather not  
have peer certificates if we don't need them.

> Are you thinking of
no - I don't see that as consistent with this draft (it could easily  
be changed to be consistent with this but I don't think it is yet).

> If so, I don't quite see how this would work.
(uh, yah, I don't see how having the peers have AOR will work either :-)

> It seems that your peer-id
> would depend on itself.

I should have made this clearer - the whole document before this  
section apples to any peer protocol. This section only applies if the  
peer protocol is SIP.

---

From: Philip Matthews <[email-masked]>
Date: Fri, 9 Mar 2007 16:19:10 -0500

Folks:

In this reply to my comments on his draft, Cullen raises a point that
I think would be useful to discuss on the mailing list.
When I did the Concepts-04 revision, I implicitly assumed that there  
would
be two sets of certificates: peer certificates and user certificates.
But Cullen is questioning this.
See more below.

On 9-Mar-07, at 15:36 , Cullen Jennings wrote:

> need both peer and users certificates so I am assuming that where  
> you need a peer certificate, you just use the user certificate for  
> some users that is authorizing the peer to use it. The problem with  
> peer certificates has to do do with what their names are.  If we  
> don't need to introduce a whole new security namespace for peers,  
> it is easier to just have users certificates.

Perhaps I am wrong, but my view is that we need both user  
certificates and peer certificates.
First of all, peer certificates are checked when the peer joins the  
network,
which may be some time before the peer registers any users associated  
with it.

Second, what about peers that  do not have any associated users?
For example, a peer offering just STUN service;
Or a peer offering voicemail service but no user has signed up  for  
the service yet;
Or even a peer acting as a SIP proxy?
What certificates do these phones use?

Third, what if a peer has multiple associated users (with different  
levels of permission)?
Which set of credentials does it use?

For these reasons, I cannot see how we can get away with just user  
certificates.
I think we need both peer certificates and user certificates.
But perhaps I am missing something?

Comments?

- Philip

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 Mar 2007 15:23:47 -0600

On Mar 9, 2007, at 3:19 PM, Philip Matthews wrote:

> which may be some time before the peer registers any users  
> associated with it.
>

But why do peer and user certificates belong in different namespaces?  
What's different about them?

Could a peer that does not having any users still have a unique name  
within the overlay?

Could the peer with multiple associated users use one name for its  
"peer" behavior and another for each "user" behavior?

--
Dean

---

From: EdPimentl <[email-masked]>
Date: Fri, 9 Mar 2007 16:33:38 -0500

comments inline... good points from both...

> > certificates and peer certificates.

<ed> yes agree </ed>

> What's different about them?

<ed> the  use of  peer  and  user  certificate, should not require a
different namespace </ed>

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Fri, 9 Mar 2007 16:53:39 -0500

> What's different about them?

A peer certificate is going to be in PeerID space (160 bit identifier
for most DHTs).  A user/resource certificate is going to be in URI
space.  Presumably there is a mapping into ID space defined by the dht
algorithm, but they're still in different spaces.  Technically a
resource can map to exactly the same ID that a completely unrelated
peer has for its PeerID and there is no problem.

I think one of the proposals in Cullen's draft was to allow a user
certificate to give their peer control of the ID space that their name
maps to (which has some very nice security properties), or of the
region around a prefix of their own ID.  That works as long as there
are no collisions and gets only a little bit hairy if you have a peer
with != 1 user.

In the dsip-security draft, our approach was to have combined user and
peer certificates using subjectAltName, where the typical certificate
would be 1 user and n peerIDs (for multiple devices), but peer- or
user-only certificates would also work easily.

> Could a peer that does not having any users still have a unique name

I don't think there is a problem with this in most of the approaches.

> "peer" behavior and another for each "user" behavior?

Yes.  At least in the dSIP drafts, the "peer" operations and the
"user" operations are totally distinct, so it is easy to identify
which identity should be used for each, even when the same certificate
is being used for both.

Bruce

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 Mar 2007 16:29:51 -0600

> peer has for its PeerID and there is no problem.

But does the name presented in the peer's cert need to be in the  
PeerID space, or can it be in URI-space in such a way that it maps  
into the PeerID space?

This is starting to sound something like identity-based encryption,  
in a left-handed sort of way.

--
dean

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Fri, 9 Mar 2007 18:05:12 -0500

As long as you're willing to ignore the 1 in 2^160 possibility of
collisions in the URI->ID mapping space, then I think the Peer
certificate could be in URI space.  I think you need to use the first
n bits (where n is large) from hashing the URI and the last m bits
(where m is small) on some uuid-type info from the particular peer if
you want a single user to be able to use multiple peers with the same
URI.

Whatever scheme you choose, preventing a user from acquiring more than
a single portion of the ID space is the most important characteristic
of a good peerID assignment scheme.  I prefer assigning them
separately rather than hashing because it eliminates the small chance
of collision (which increases the more bits you allow for the uuid in
the other scheme), and the peerID needs to be either stored in the
certificate anyway (in which case the cert does specify the peerID in
peerID space) or hashed each time (which seems like a small, but
needless, computation).

Bruce

---

From: "David A. Bryan" <[email-masked]>
Date: Sun, 18 Mar 2007 19:57:09 +0100

Forgot to reply this...also possibly the wrong thread for this, should
maybe have posted in the other thread about certificates.

There may be cases where we need a seperate peerID in the sense that
the device has no associated user. I'm thinking things like gateways,
or even a bootstrap if you have a persistent box somewhere to help you
bootstrap on.

May only be corner cases, however. Maybe a user "bootstrap" or something...

David

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

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 18 Mar 2007 23:56:40 +0100

I think one of the key consideration here has to do with what you are  
using the peer certificate for. In the end it has to do with  
assigning some trust and traceability about the operator of the  
device. A device ID is sort of lousy for this - what you actually  
want to know is something more about the user that is operating the  
device. Think about, what do you think might end up being more  
useful, "the MAC address of the machine that is hijacking your calls  
is 123456" or "the operator of the machine that is hijacking your  
calls is [email-masked]". What I am suggesting here is that all  
peer software is operated and run by some users. And that user has to  
has to be enrolled on the DHT and the uses that users credentials for  
describing what user that devices is operating the device. I  
understand that you could have a device with no users, but why? It  
greatly complicates making assertion about the device if you have to  
be able to do that independent of any user. Even a bootstrap node is  
run by some user.

Let me flip the questions around, what security feature can you  
provide by having two types of certificates?

Cullen <with my individual hat on>

On Mar 18, 2007, at 7:57 PM, David A. Bryan wrote:

> There may be cases where we need a separate peerID in the sense that
> > >    performing a DOS attack on they system by misrouting  
> requests in
> > > the
> you

---

From: "Turner, Jim \(NBC Universal\)" <[email-masked]>
Date: Sun, 18 Mar 2007 17:10:40 -0700

I would be interested to know a scenario where a device isn't operating as a "proxy"
for a real user? In my experience, even set-top boxes are associated with "customers".

It's easy to think of a device as being "detached", but in practice, if the device is
attempting to access a "service", it is usually associated with some user "entity".

Jim

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Mon, 19 Mar 2007 02:51:09 -0400

I definitely agree that you always want to be able to associate a
"real" identity with a peer, but there are still times when you don't
want to base the peerids on that one identity.  For example, if a
service provider is providing 5 peers to provision a network with,
those should probably be evenly distributed around the ID space,
whereas the multiple devices of a single regular user should be in one
spot in ID space to protect against certain attacks.

You can obviously accomplish the same thing with names like
[email-masked] so whether the problem is solved with separate
peer certificates or through synthentic email addresses isn't that
important, but peer id certificates (that still have to reference
[email-masked]) strike me as a bit less of a hack.

Bruce

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 19 Mar 2007 07:58:32 +0100

Well, my thoughts were more toward someone using P2PSIP, but using it
for a commercial deployment. Bootstrap nodes, PSTN gateways and the
like might not have an associated user, but likely should be certified
to enter the network.

Now maybe the answer is simply that the user is "sysadmin" or something.

Also to answer Cullen's question -- not sure we gain a security
property with two certs, but perhaps a configuration ease one. If we
want to allow a user to have multiple devices, and we want to assign
PeerIDs (possible again in a system that is a commercial deployment if
they want to ensure evenly distributed PeerIDs). Might also be a sybil
issue...if I have one user ID, and want to prevent sybil attacks, we
need to make sure I as a user can't start too many devices...one way
seems to be limit me to having to get a cert for each device. I have
always assumed each Peer certificate could still be traced to the user
who requested it, but is different. If I search the overlay for a user
certificate, I want to find a unique one for  user so I can encrypt
and send them messages.

Obviously either way could work. We need to think about the tradeoffs.

David

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

---

From: Dean Willis <[email-masked]>
Date: Mon, 19 Mar 2007 03:28:04 -0500

> May only be corner cases, however. Maybe a user "bootstrap" or  

Do we need to be able to tell by examination of the peerID that this  
is a userless node?

--
Dean

---

From: Philip Matthews <[email-masked]>
Date: Mon, 19 Mar 2007 09:50:43 +0100

I haven't given this a huge amount of thought, but I tend to agree  
with David.

If my organization is running a  P2PSIP overlay as a local  
communication system,
then it might well want to run a STUN relay server or voicemail  
server to provide
services for peers. Various sysadmin types might be responsible for  
keeping these
servers running, but I think it logically makes more sense to think  
of the PeerID
certificate as being associated with the organization, and not with a  
single person.
After all, the person running the server might not be a user of the  
P2PSIP overlay
(e.g, he/she provides an e-mail address or some other method of  
contact him/her).

However, I repeat that I have not thought a lot about this, and I  
have no problem
indicating that this is an open issue in the next version of the  
Concepts draft.

- Philip

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 19 Mar 2007 09:52:14 +0100

Seems making this an open issue is a good idea. I could likely be
convinced either way on this, but we need to get a good discussion
going and all think a bit...

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

---

From: Philip Matthews <[email-masked]>
Date: Mon, 19 Mar 2007 09:53:10 +0100

On 19-Mar-07, at 09:28 , Dean Willis wrote:

>
> Do we need to be able to tell by examination of the peerID that  
> this is a userless node?

Right now, I don't know any reason to be able to do this.

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 19 Mar 2007 09:57:12 +0100

Agree...I see some possible use to having them separate, but not sure
we need to be able to identify a peer that has no associated user...

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Mar 2007 10:06:02 +0100

sure - I would imagine that in the same way email has users like  
"postmaster" that there might be "users" like that but logically they  
would be treated the same as any other user.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Mar 2007 10:06:43 +0100

Ah, I see what how you are thinking about this. I think I now  
understand why you and I had come up with different views on this.  
This basically depends on how you allocate peer ids and user id. If  
peer id are centrally allocated, then I see why you would have a peer  
certificate this but if they are locally generated then you would  
probably not want a peer certificate.

---

From: <[email-masked]>
Date: Mon, 19 Mar 2007 12:24:37 +0200

Hi,

I agree with Cullen. Every device has an owner (an individual person or
an organization). A device typically do not behave maliciously. This is
the owner that may try to attack a system using the device. And even if
there are many admins, they typically belong to the same organization
(they represent the organization).

Can a peerID change? If the peerID is based on an IP address then the
peerID changes when the device moves from one subnet to another.

PeerID can also be designed so it includes location information.

Marcin

>From: ext Cullen Jennings [mailto:[email-masked]] 
>Sent: 19 March, 2007 00:57
>To: David Bryan
>I think one of the key consideration here has to do with what 
>you are using the peer certificate for. In the end it has to 
>do with assigning some trust and traceability about the 
>operator of the device. A device ID is sort of lousy for this 
>- what you actually want to know is something more about the 
>user that is operating the device. Think about, what do you 
>think might end up being more useful, "the MAC address of the 
>machine that is hijacking your calls is 123456" or "the 
>operator of the machine that is hijacking your calls is 
>[email-masked]". What I am suggesting here is that all 
>peer software is operated and run by some users. And that user 
>has to has to be enrolled on the DHT and the uses that users 
>credentials for describing what user that devices is operating 
>the device. I understand that you could have a device with no 
>users, but why? It greatly complicates making assertion about 
>the device if you have to be able to do that independent of 
>any user. Even a bootstrap node is run by some user.
>
>Let me flip the questions around, what security feature can 
>you provide by having two types of certificates?
>
>> > >    When a client wants to store some information in a 
>record, they 
>> > > sent
>> > > defined in the P2PSIP Concepts document? My guess is 
>that you are 
>> > > using the word "client" in the SIP meaning, not in the P2PSIP 
>> > > meaning.
>> >
>> > >    Open Issue:  how do we want to deal with checking 
>time and also 
>> > > does
>> > > Philip: Are your worried about size in sending the message or in 
>> > > storing the data?  That is, if we used for example TCP transport 
>> > > (i.e.,
>> not
>> > > UDP),
>> > >    by the attacker, it is probably impossible to 
>perfectly secure 
>> > > this.
>> > >
>> > > Can you give some examples of what you mean by "a request that 
>> > > modified the routing"?  For example, do you mean 
>"setting up a new 
>> > > we have already agreed that peers must have certificates to join 
>> > > the overlay.)
>> >
>> > >         number of AORs an attacker can enroll in the 
>system.  How 
>> > > to do
>> > >           peer@<hostport>; peer-id=<peerid> where 
><hostport> is an 
>> > > IP address and port and <peerid> is a
>> peer-id].
>> > > Moreover, the other unique part is the <hostport>, so this falls 
>> > > back to option L1.
>> > >

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 19 Mar 2007 18:28:28 +0100

I think the case where having distinct ones is likely most useful when
they are issued, so the case of the changing IP isn't likely to matter
in this case, but yep, we need to think about that too.

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

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 19 Mar 2007 19:41:10 +0100

Wouldn't a peerID change be the same as a leave plus a join?

From: <[email-masked]>

Can a peerID change?

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 20 Mar 2007 01:34:15 -0400

It depends on how PeerIDs are allocated.
If we consider centrally generated peer certificate, PeerIDs should not
change because of leave and join.
Thanks.

Eunsoo

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 20 Mar 2007 08:30:57 +0100

Eunsoo,

I understand this, I'm asking the other question - if a peer ID DOES change, does it look like a leave plus a join.

Spencer
  ----- Original Message ----- 
  From: Eunsoo Shim 
  To: Spencer Dawkins 
  Cc: [email-masked] 
  Sent: Tuesday, March 20, 2007 6:34 AM
  Subject: Re: [P2PSIP] Re: Comments on draft-jennings-p2psip-security-00

  It depends on how PeerIDs are allocated.
  If we consider centrally generated peer certificate, PeerIDs should not change because of leave and join.
  Thanks.

  Eunsoo

    Can a peerID change?

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 20 Mar 2007 13:53:17 +0100

I don't know of any reason a peer ID would change at runtime, unless
you're hashing IP addresses and using those as your peer ID.  In that
case, you have to join anyway so that your neighbors have some idea of
where to find you.

If it did change, I don't know how it could be accomplished other than
through a leave and a join (at least, I would not want to design a
protocol that has an explicit changeMyID operation).

The slightly similar challenge in getting the protocol to work is in a
certificate-based system when a peer has a fixed peerID but changes IP
address, it needs to update its IP address with its neighbors
(effectively a re-join).  The implementations just need to allow for
that to happen (and of course need to be error-tolerant to handle
ungraceful leave where a peer disappears without explicitly leaving).

Bruce

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 20 Mar 2007 09:46:46 -0400

Yes, it looks like a leave of a peer and a join of another peer.

Eunsoo

On 3/20/07, Spencer Dawkins <[email-masked]> wrote:
>
>  Eunsoo,
>
> I understand this, I'm asking the other question - if a peer ID DOES
> change, does it look like a leave plus a join.
>
> Spencer
>
> *From:* Eunsoo Shim <[email-masked]>
> *To:* Spencer Dawkins <[email-masked]>
> *Cc:* [email-masked]
> *Sent:* Tuesday, March 20, 2007 6:34 AM
> *Subject:* Re: [P2PSIP] Re: Comments on draft-jennings-p2psip-security-00
>