Subject: [P2Prg] Proposed research tracks ...

From: Bill Yeager <[email-masked]>
Date: Mon, 10 Nov 2003 21:41:47 -0800

Hi,

Here is our first proposal for research tracks in our RG. Please 
comment and/or volunteer so we can get this show on the road (-:

Thanks,

Bill and Bobby

-------

In all of the research tracks below the overriding consideration is 
that we do not reinvent any wheels. Care must be taken to look for 
possible relationships with, or extrapolations of ideas in current 
RFC's.

o Overview of current P2P systems

	A short term effort to give us a baseline of current P2P system 
behavior. What is there that is relevant
          to the following research subgroups.

	Subgroup leaders: Bill and Bobby

o P2P Overlay Infrastructure

	What are the requirements of such an infrastructure to guarantee both 
end-to-end communication between
	any two peer nodes independently of the underlying real 
infrastructure? What will the UUID's be for such
	peer nodes? Will they resemble IP.V6 addresses for example? Can they 
be created in such a way as to
	make mobility implicit without any special changes to the discovery 
and routing protocols we use?

	Subgroup leaders: Bill Yeager, Jeff Altman (Is there another volunteer 
out there?)

o P2P Mobility Device Requirements

	Mobile devices have both capability and infrastructure differences 
that must be addressed so that they can
	interoperate will an Internet-wide p2p network. These special 
requirements will be outlined, and carefully
     	examined in this research track. The results of this effort will 
clearly influence the other tracks discussed below
	since mobile devices must play in any P2P space that our research 
ultimately defines.

	Subgroup leader: Frank-Uwe Andersen

o Meta-Data Strategies

	Meta-data descriptions are at the core of content distribution, and 
lookup in a P2P network. Thus, addressing various strategies
	for such descriptions is critical early on in our research. Happily, 
Sam Joseph has enthusiastically volunteered to led this effort.

	Subgroup leader: Sam Joseph

o Namespaces:  managed versus unmanaged

	Ad-hoc vrs controlled name spaces:

	A managed namespace is controlled by (at least) one authority who is
	responsible for delegating rights to subspaces within the managed
  	space.  In an unmanaged space, any principal can bind to any name,
	and an external protocol (e.g. cryptographic certificates, or trust
  	inference) is used for resolving specific references.

  	It is not clear which model is more appropriate for the P2P domain;
  	clearly, it is attractive to have the IETF (or a similar body) "own"
  	some part of the P2P namespaces (much like today's DNS), and have the
  	usual name delegation etc.  However, the P2P model may be 
decentralized
  	by definition, and thus, both approaches are appropriate, and should
	be addressed in this research track.

	Subgroup leader:  To be determined.

o Routing and routing primitives

	Everything we know about p2p routing and how it relates to the IETF 
routing protocols:

	Initially, a survey of current P2P routing techniques is a requirement 
for this research
          track. The feeling is that any overlay network we might chose 
should be routing protocol
   	agnostic since different protocols may be appropriate for different 
applications. Think about
	a P2P based file storage system that operates on pages of files versus 
straight forward
	content exchange for example. Would the same routing protocols be 
appropriate in both
	instances given the granularity and latency differences that each 
system can tolerate?

	Ultimately, another related path of exploration is to investigate how 
hints from existing Internet
	routing protocols might be used to give hints to aid in building 
application, context specific routing
	tables.

	Subgroup leader: To be determined.

o Peer Discovery/Resource Location/Presence

	Once again, there are common sub functions here that all P2P apps
   	use, and in this case, it seemed clear that some components could be
   	reused by different P2P systems.  For example, all P2P systems have
   	to solve the "first node" problem for bootstrapping new clients.
   	Different possible methods were discussed, including
   	DNS/DHCP/rendezvous point schemes. What will the super-peers
	be required to do to fulfill these requirements?

	Subgroup leader: To be determined

o Security issues

    	Security in a P2P system is extremely difficult because of the 
possible
	pure ad-hoc nature and behavior that can exhibit itself. One may and
	and often will not be able to depend on a centralized certificate 
authority
	based PKI to bootstrap secure networks. The requirements are the same:
	Privacy, Authentication, Integrity, and non-repudiation. The possible 
solutions
	are quite interesting and often point towards PGP-like Webs-of-Trust
	and reputation models.
	.
	On the other hand, in an enterprise, a very centralized, CA PKI will be
	necessary for P2P to fly there. On top of this we have the usual DoS
	attacks, the requirement to support anonymous, and autonomous
	peer nodes, etc.

	It is appropriate to begin here with a survey of the current P2P 
research
	on security to establish a foundation for discussion, and synergy with
	the IETF security efforts.

	This is a difficult and truly interesting area for research.

	Subgroup leader: To be determined.

_______________________________________________
P2prg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2prg

---

From: [email-masked]
Date: Tue, 11 Nov 2003 18:09:55 +0900

Hi Bill,

I'm happy to hear we can start focused effort from now.
Some questions at a glance on the tracks and its description.

1. I'm interested in `peer group' and standardization of peer group.
   Does the `overlay infrastructure' track covers it?
   i.e.) what operation could be applied to a peer group? what is
         minimum requirement to become a member of the group?
         is it possible to share a group-forming architecture
         as common foundation?

2. The namespace track includes identifier problem? I suppose there
   was rough consensus not to have one and ultimate shared universal
   P2P ID architecture, but not sure because no discussion is on the
   ML.

3. How will the each group proceeds? discussion on this ML or some
   face-to-face meeting? I personally hates too-many-ML-syndrome.

4. Will Terminology draft be published from overview track?

5. Is there any `official' minute of the kick-off?

Thanks,

Yusuke

At Mon, 10 Nov 2003 21:41:47 -0800,

---

From: coderman <[email-masked]>
Date: Tue, 11 Nov 2003 01:47:19 -0800

[email-masked] wrote:

>...
I think the Peer Discovery / Resource Location subgroup would be a good
fit for these interests.  Peer groups are very useful for transitive 
introduction
 and resource discovery in general.

>   P2P ID architecture, but not sure because no discussion is on the
Securely identifying resources and peers could also fall under the
security group (hash trees, secure digests, GUID's and nonces, etc)

Best regards,
     Martin Peck

[ My site hosting is online and the project I mentioned on list
  previously can be found here: http://peertech.org/alpine/ ]

---

From: "Luca Caviglione" <[email-masked]>
Date: Tue, 11 Nov 2003 12:31:47 +0100

Hi list,

The subdivision is very good and I am very interested in p2p mobility device
requirements.

Here some opinions

I find very important topics such as Peer Discovery/Resource Location
because p2p systems need to be "kickstarted".  Will be any investigation
about a possible integration of p2p with Zeroconf-like technologies
(automatic discovery within a local link to find an already running "entry
point" or assuming that first node could be a service)?  Also, I think there
are two main branches for bootstrapping p2p services: centralized (such as
peer caches) or distributed (i.e. some mediation points).  I believe that
this difference must be taken into account.

Also, I think that resource location could be analyzed jointly with mobility
requirements allowing to manage complex scenarios i.e.
affiliation/de-affiliation to a mobile peer-cache (or anything else that I
can't imagine now) allow finding a mobile "first node".

In a mobile context, maybe some techniques to hand-offs from the first node
to another maybe are useful i.e. to allow finding-synchronizing possible
entry points or make everything predictive and "looking ahead".

So list that's all for now. I'll think that my (welcome?) efforts will be
focused on p2p mobility and Peer Discovery. just for let you know and count
the heads. Hope that my thoughts will be useful.

Bye

Luca

---

From: Lucas Gonze <[email-masked]>
Date: Tue, 11 Nov 2003 15:29:33 -0500

Hi Bill and Bobby,

I'll volunteer for the namespaces track.

- Lucas Gonze

On Tuesday, Nov 11, 2003, at 00:41 America/New_York, Bill Yeager wrote:

> 	Subgroup leaders: Bill Yeager, Jeff Altman (Is there another 
> volunteer out there?)
>
> 	Initially, a survey of current P2P routing techniques is a 
> requirement for this research
> 	a P2P based file storage system that operates on pages of files 
> versus straight forward

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 11 Nov 2003 15:42:37 -0500

Hi Billy and Bobby,

We are interested in researching several aspects of peer to peer systems 
at NIST. I am personally interested in Routing, Peer Disovery and 
resource location and presence. Please let me know how I can be of help 
in these research tracks.

Regards
Ranga.

Bill Yeager wrote:

> possible relationships with, or extrapolations of ideas in current RFC's.
>
>     What are the requirements of such an infrastructure to guarantee 
> both end-to-end communication between
>     peer nodes? Will they resemble IP.V6 addresses for example? Can 
> they be created in such a way as to
>     make mobility implicit without any special changes to the 
> discovery and routing protocols we use?
>
>         examined in this research track. The results of this effort 
> will clearly influence the other tracks discussed below
>     Meta-data descriptions are at the core of content distribution, 
> and lookup in a P2P network. Thus, addressing various strategies
>     for such descriptions is critical early on in our research. 
> Happily, Sam Joseph has enthusiastically volunteered to led this effort.
>
>     Everything we know about p2p routing and how it relates to the 
> IETF routing protocols:
>
>       agnostic since different protocols may be appropriate for 
> different applications. Think about
>     Ultimately, another related path of exploration is to investigate 
> how hints from existing Internet
>     Privacy, Authentication, Integrity, and non-repudiation. The 
> possible solutions

-- 
M. Ranganathan 

Advanced Networking Technologies Divsion,
National Institute of Standards and Technology (NIST),
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 

tel:301 975 3664 , fax:301 590 0932 , http://www.antd.nist.gov/~mranga

Advanced Networking Technologies For the People!

---

From: [email-masked]
Date: Thu, 13 Nov 2003 11:48:37 -0500

I am not sure that we should have our own Security Subtrack.  The 
IRTF Group Security Research Group (chaired by Peter Dinsmore, 
Network Associates Laboratories) has been working actively in 
this area for many years.  Their work produced the Multicast 
Security Working Group approximately four years ago.  Since then 
they have been meeting regularly at IETF meetings hosting talks 
about real world applications of their technologies.  

I attended the research group meeting on Tuesday.  The 
presentations I saw were directly applicable to our efforts.  
More importantly, the GSEC RG is desperately looking for new 
problems to solve.  They had a large attendance (80 people) at 
their meeting.

Bill, Bobby.  I suggest you contact Peter and propose 
collaboration.

- Jeff

Quoting Bill Yeager <[email-masked]>:

> 	pure ad-hoc nature and behavior that can exhibit itself. One 
may
> and
> 	based PKI to bootstrap secure networks. The requirements are 
the
> same:
> 	On the other hand, in an enterprise, a very centralized, CA 
PKI
> will be
> 	necessary for P2P to fly there. On top of this we have the 
usual
> DoS

---

From: Scott Michel <[email-masked]>
Date: Fri, 14 Nov 2003 14:35:34 -0800

Bill Yeager wrote:

> Hi,
> 
> Here is our first proposal for research tracks in our RG. Please comment 
> and/or volunteer so we can get this show on the road (-:
> 
> Thanks,
> 
> Bill and Bobby
> 
> -------
> 
> In all of the research tracks below the overriding consideration is that 
> we do not reinvent any wheels. Care must be taken to look for possible 
> relationships with, or extrapolations of ideas in current RFC's.
> 

I'm more than happy to help lend a hand to overlay and infrastructure 
subgroup issues, as a subgroup leader.

>     Subgroup leader: To be determined.

I'm also more than happy to help lead up this subgroup, assuming others are 
interested in P2P routing problems (within the overlay and how the Internet 
can lend hints, etc.)

-scooter

---

From: Bill Yeager <[email-masked]>
Date: Wed, 19 Nov 2003 16:09:43 -0800

Hi Yusuke,

>    Does the `overlay infrastructure' track covers it?

Yes, I think that "peer groups" or "contexts" as we discussed them in 
them meeting are part of the overlay network infrastructure.

>          is it possible to share a group-forming architecture

These are good questions. There are others too: What is a peer group? 
How is it described in the context of the general overlay network? It 
is a subsetting operation for sure. Then your membership requirements 
apply. How is communication restricted to this context? How is it 
discovered? Etc.

I think the overlay needs to be worked out first. We need to know what 
we are going to subset.

>    P2P ID architecture, but not sure because no discussion is on the
You are correct. We wanted a purely ad-hoc namespace to begin with. 
This is related to overlay infrastructure since we need a way to lookup 
peer nodes. We also decided that what we come up with can also be 
applied to registered/owned namespaces. IANA for example. Many 
namespaces can live in parallel.

>    face-to-face meeting? I personally hates too-many-ML-syndrome.
I've been thinking about this and will talk to Vern to see if we can 
get sub-mailing lists as a way to pre-filter the email.

> 4. Will Terminology draft be published from overview track?
Published is a good question. The group can create a document for us to 
share. How much further is goes is not clear to me. Maybe an 
informational RFC?

> 5. Is there any `official' minute of the kick-off?

I'm thinking we have this month to organize. I've been quiet working on 
other things, clearing my desk, and will be quite active for the rest 
of the month. We need some kind of RG consensus/input as to the tracks 
and volunteers for each one hopefully.

Bill

---

From: Bill Yeager <[email-masked]>
Date: Wed, 19 Nov 2003 16:16:21 -0800

Hi Martin,

> and resource discovery in general.
You are right in both senses. There is overlap wrt to the research 
tracks.

Still, I think we need to define the overlay infrastructure first, see 
how peer groups are subsetted, and then the discovery/resource location 
has its part.

> security group (hash trees, secure digests, GUID's and nonces, etc)
Right again. Securing the document descriptions, creating meta-data for 
these documents so they can be looked up using hash*, etc ...

---

From: Bill Yeager <[email-masked]>
Date: Wed, 19 Nov 2003 16:43:59 -0800

Hi Jeff,

Collaboration is a great idea. Still, there are security issues that 
arrive in P2P that tend not to be discussed in the IETF: The entire 
reputation based trust research area is an example. This goes way 
beyond PGP into some pretty far out and applicable areas. The details 
will arrive when the group gets going.

This is one of Bobby's specialties, and I, and Rita Chen also have a 
strong interest here.

Bill

On Thursday, November 13, 2003, at 08:48 AM, [email-masked] wrote:

>  am not sure that we should have our own Security Subtrack.  The

---

From: Jean-Henry Morin <[email-masked]>
Date: Thu, 20 Nov 2003 18:48:01 +0100

Hi all,
I also think there is much work to be done on security with respect
to P2P. Following up on Rita's comments (
https://www1.ietf.org/mail-archive/working-groups/p2prg/current/msg00130.html )
there are certainly several issues that should be carefully studied in
identifying key security requirements in the context of P2P.
For example, considering a language approach in specifying
usage rights and policies (be it for peers, endpoints, services -be
they peer based, group based or "simply" mobile...). This leads to
a whole range of issues to be studied in the interplay between P2P
and rights/policy management - languages - as well as trust management.
Moreover provisioning such security services in highly decentralized
environments does raise some interesting challenges.
So, I gladly volunteer to help in the security track.

Cheers,
jh

---

From: Bill Yeager <[email-masked]>
Date: Thu, 20 Nov 2003 10:23:31 -0800

Hi Jean-Henry,

Great that you want to join the security track.

Bill

---

From: Lucas Gonze <[email-masked]>
Date: Thu, 20 Nov 2003 13:57:13 -0500

I have sketched out (in Spring 2002) a protocol to enhance the security  
of P2P nodes.  My strategy is to say that the security of a browser is  
adequate for users, and to look for ways that a desktop web server can  
approach that level of security.

The URL is http://www.gonze.com/http-notifications.html

-Lucas

On Thursday, Nov 20, 2003, at 12:48 America/New_York, Jean-Henry Morin

---

From: Justin Chapweske <[email-masked]>
Date: Thu, 20 Nov 2003 13:18:38 -0600

Hi Lucas,

After a quick browse, I would suggest that the the subscription duration 
be changed to a mutually negotiated lease.

So, instead of just the server's Notification-Expiration header, you 
would also add a client request header that would request a length of 
time for the subscription to last for, with -1 implying "infinity" or 
"don't care".  The server is then free to return a 
Notification-Expiriation header that is less than, but never greater 
than the amount of time that the client requests.

The addition of mutually negotiated leases is very simple, but greatly 
increases the flexibility of what you can do with such a system.

I would recommend that any P2P system contemplating pings, heart-beats, 
etc, look instead at a negotiated lease approach.

Thanks,

-Justin

-- 
Justin Chapweske, Onion Networks
http://onionnetworks.com/

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 20 Nov 2003 14:55:22 -0500

This recommendation is consistent with how the p3p wg (w3c) approached
temporal properties of data collection policies, so I'm happy with it.

...
> > adequate for users,

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 20 Nov 2003 15:01:12 -0500

Howdy Bill,

I'm interested in namespaces, and meta-data (p3p and drm).

Eric

---

From: Lucas Gonze <[email-masked]>
Date: Thu, 20 Nov 2003 15:09:09 -0500

I'm afraid I know pretty much nothing about P3P, Eric.  When you say 
temporal properties are you referring to the length of data retention?

- Lucas

On Thursday, Nov 20, 2003, at 14:55 America/New_York, Eric

---

From: Lucas Gonze <[email-masked]>
Date: Thu, 20 Nov 2003 15:27:12 -0500

Pardon, I think you're thinking of the P3P EXPIRY element.  I'll have 
to do some reading before I know how well the semantics match up.

Let's take this offlist, unless there are people who prefer otherwise.

- Lucas

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 20 Nov 2003 15:43:32 -0500

Lucas,

The general problem is how to avoid re-evaluation of a policy, with all
the fetch-and-eval overhead that entails, on a browser's url fetch. 

So no, it isn't the length of data retention, that's in the specific
domain of data collection, it is the EXPIRY and all the non-published
work we did on how to provide some temporal mechanism(s) to avoid the
problem.

Off-list is fine.

Eric

---

From: Bill Yeager <[email-masked]>
Date: Thu, 20 Nov 2003 21:29:29 -0800

Thanks for the reference Lucas. I'll check this out after I catch up 
with this mailing list...

Bill

On Thursday, November 20, 2003, at 10:57 AM, Lucas Gonze wrote:

> I have sketched out (in Spring 2002) a protocol to enhance the 
> security of P2P nodes.  My strategy is to say that the security of a 
> browser is adequate for users, and to look for ways that a desktop web 
> server can approach that level of security.
>

---

From: Bill Yeager <[email-masked]>
Date: Thu, 20 Nov 2003 21:30:57 -0800

Got it ...

Thanks,

Bill

On Thursday, November 20, 2003, at 12:01 PM, Eric Brunner-Williams in

---

From: Sergio Mendiola <[email-masked]>
Date: Fri, 21 Nov 2003 10:54:44 -0800

Hi Bill,

I was not available to attend the first meeting, so I am not sure if the 
following issues were discussed.

How is each subtrack/group going to proceed?  any particular structure, 
deliverables, life time, etc.

Assuming the same ML will be used, here is a suggestion to facilitate 
communication, specify the subtrack at the beginning off each email's 
subject, for example:
[Overview]
[Overlay]
[Mobility]
[Meta-Data]
[Namespaces]
[Routing]
[Discovery]

we can always create filters if we are not interested in a particular 
track, but still have access to them if we want.

My interests primarily are on discovery and overly infrastructure.

Sergio

---

From: Justin Chapweske <[email-masked]>
Date: Fri, 21 Nov 2003 13:01:22 -0600

I think I agree with Sergio in that I would rather not have seperate 
mailing lists for each track.  I am more of a P2P generalist and believe 
that many of the issues discussed will have concerns that overlap many 
tracks.

My 2 cents,

-Justin

---

From: Bill Yeager <[email-masked]>
Date: Fri, 21 Nov 2003 19:48:25 -0800

Hi Sergio,

Thanks for the note.

On Friday, November 21, 2003, at 10:54 AM, Sergio Mendiola wrote:

>
> I was not available to attend the first meeting, so I am not sure if 
> the following issues were discussed.
>
> How is each subtrack/group going to proceed?  any particular 
> structure, deliverables, life time, etc.
>

As independently as is possible is the proposal. Cross pollination is 
inevitable and some tracks are prerequisites for the others, e. g., 
Overlay is defines the substrate upon which the system will operate. 
I'm imagining a large participation there. Otherwise, we haven't 
formalized the structure to that extent of deliverables and life time 
yet. It is our next step, and I believe they will be subgroup 
determined.

> track, but still have access to them if we want.

I've been thinking the same thing. Still, I want to see if we can have 
multiple mailing lists. I'm not sure how the IRTF works in this case.

Bill

---

From: Bill Yeager <[email-masked]>
Date: Sun, 23 Nov 2003 18:24:52 -0800

Hi Justin,

Thanks for your note and the expression of your preference. I imagine 
we will end up with using subgroup names in the Subject lines.

But,  I still think that as long as you can subscribe to multiple 
mailing lists, the mailing lists will simplify the effort for those who 
are not generalists. If is is possible to have mailing lists, I don't 
know yet, then the fair thing to do will be to vote on it, and go with 
the RG's majority opinion.

Hope that is OK?

Bill

On Friday, November 21, 2003, at 11:01 AM, Justin Chapweske wrote:

> mailing lists for each track.  I am more of a P2P generalist and 
> believe that many of the issues discussed will have concerns that 
> overlap many tracks.
>
> My 2 cents,