Subject: [P2PSIP] draft-matthews-p2psip-bootstrap-mechanisms-00

From: Cullen Jennings <[email-masked]>
Date: Sat, 10 Mar 2007 15:22:31 -0800

Imagine that a peer discovers some bootstrap nodes and successfully  
enrolls in the DHT. The next time the peer boots, it will want to  
initial try with a different bootstrap set such as the nodes it  
connected to on the previous boot. This can help disperse load off  
the initial bootstrap nodes and also allows introduction of new  
bootstrap nodes and removal of old ones over time. I don't know how  
the WG should deal with all this but I think a bootstrap draft should  
explore this.

You need to deal with the SOS Attack - (Start of Service Attack).  
Imagine a large enterprise network where 100 thousand phones re-power  
simultaneously and all start doing multicast, or the effect of of  
power-outage in a large city.

Could you define this so that you just have one or more IP addresses  
for the bootstrap nodes, and if the IP address happens to be a  
multicast address, well things work about the same as if it is unicast.

The credential mode seemed unnecessarily complicated.

In section 2, why bother with making the bootstrap server not be one  
of the peers - it significantly complicates things, introduces  
another  protocol and does not seem like it will really deduce the  
load on the bootstrap server.

Cullen <with my individual hat on>

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

---

From: Philip Matthews <[email-masked]>
Date: Mon, 12 Mar 2007 14:02:17 -0400

On 10-Mar-07, at 18:22 , Cullen Jennings wrote:

> the WG should deal with all this but I think a bootstrap draft  
> should explore this.

Yes. This bootstrap mechanism (which we called "Buddy List", though  
perhaps that name is not the best), and a fourth mechanism (called  
"Manual configuration") are mentioned in the Concepts draft and were  
discussed in some detail in the -00 version of the NATs and Overlays  
draft.
When we said in the bootstrap draft that we would add two more  
mechanisms in a future revision, these are what we were thinking of.  
We didn't have time to add these for this rev.

> Imagine a large enterprise network where 100 thousand phones re- 
> power simultaneously and all start doing multicast, or the effect  
> of of power-outage in a large city.

Good point. We need to think about this.

>
> Could you define this so that you just have one or more IP  
> addresses for the bootstrap nodes, and if the IP address happens to  
> be a multicast address, well things work about the same as if it is  
> unicast.

I guess you are talking about the Multicast mechanism here.  I think  
the answer is yes -- need to work through the details.

> The credential mode seemed unnecessarily complicated.

I assume you mean the text in the Security Considerations section.   
As we mentioned, these are just very preliminary ideas which need  
more thought.

>
> In section 2, why bother with making the bootstrap server not be  
> one of the peers - it significantly complicates things, introduces  

There are two ways to view your question.
The first way is to say "take one of the peers and also make it a  
bootstrap server". The cons with this approach is that it would  
typically require the peer to have a DNS name and, unless doing   
dynamic DNS, also a public IP address.

The second way is to say "take the bootstrap server and make it run  
the peer protocol". The cons with this approach is that the bootstrap  
server is now much more involved in the overlay. Our whole idea is to  
minimize the interaction between the bootstrap server and the  
overlay, so that a given bootstrap server can serve lots and lots of  
different overlays.

The bootstrap server is a logical role. If you want to co-locate it  
with a peer, that is fine. But personally, I am interested in cases  
where they two are NOT co-located.

- Philip