Hi,
The issues I had were related to characterization of
peer-to-peer applications. The draft currently says this:
Peer-to-peer applications are a restricted subset of "server
applications" (discussed in section 3.4), in which the services are
only meant to be used by well-identified peers outside the unmanaged
network. These applications are often facilitated by a server
outside the unmanaged networks. Examples of peer-to-peer
applications would be a video-conference over IP, facilitated by a
Session Invitation Protocol (SIP) server, or a distributed game
application, facilitated by a "game lobby".
Peer-to-peer applications often don't work well in unmanaged IPv4
networks. Application developers often have to enlist the help of a
"relay server", in effect restructuring the peer-to-peer connection
into a pair of back-to-back client/server connections.
The first statement implies that peer-to-peer applications
are always closed systems ("well-identified peers"). While "well-identified"
is not spelled out in detail, this doesn't seem true, even for those
facilitated by a server (think of BitTorrent, for example). Presuming
that this is the case may give you a very skewed sense of the requirements.
Calling them "a restricted subset of server applications" is also likely
to alienate that community, even if this fits into this particular conceptual
framework. The focus on the rendezvous systems might also
indicate the key problems here are on the interaction between peer
and rendezvous systems, when that's only one part of the problem space.
I'm also not sure whether the last sentence means back-to-back user
agent solutions or connections that occur one after the other (as in
"back to back wins
at Wimbledon" ).
Inside the requirements section, here's the text on naming
systems:
Peer-to-peer applications often use ad hoc naming systems, sometimes
derived from an "instant messaging" service. (Peer-to-peer
applications that rely on the DNS for name resolution have the same
naming requirements as server applications, which are discussed in
the next section.) Many of these systems are proprietary; an example
of a standard system is the session invitation protocol (SIP)
[RFC3261]. In these systems, the peers register their presence to a
"rendezvous" server, using a name specific to the service; the case
of SIP, they would use a SIP URL, of the form
"sip:user@example.com". A peer-to-peer session typically starts with
an exchange of synchronization messages through the rendezvous
servers, during which the peers exchange the addresses that will be
used for the session.
This characterization concerns me as well, as one of the common
cases is that an application has configured peers that are exchanged
out of band to the protocol or configured in "chaining" mechanisms that
don't have this hierarchy. Even where "rendezvous" servers are used,
they may not be consulted after configuration (and so aren't a constant part
of the name resolution). Referring to these "ad hoc" naming systems
and then giving an example ofa "SIP URL" also doesn't make sense to
me, since it has well-defined addresses.
On security it says:
There are multiple aspects to the security of peer-to-peer
applications, many of which relate to the security of the rendezvous
system. If we assume that the peers have been able to safely
exchange their IPv6 addresses, the main security requirement is the
capability to safely exchange data between the peers, without
interference by third parties.
The main security requirement seems to be peer authentication,
whether it comes through a rendezvous service or not. The decision
over what constitutes "safe data exchange" for a particular application
varies (confidentiality may be required or not, for example).
Private conversations by one of the authors with developers of peer-
to-peer applications suggest that many would be willing to consider
an "IPv6-only" model if they can get two guarantees:
I really question the value of the section following for this
draft; the draft is supposed to be describing transition scenarios for
unmanaged networks, not describing how peer-to-peer applications
might drive v6 deployment.
On the whole, I found the characterization of peer-to-peer
systems to be weak, and I suspect that the right answer is to punt
most of it, concentrating on the aspects which relate closely to the
unmanaged network aspect.
Peer to Peer applications with participants off the unmanaged
network clearly need 1) global connectivity, 2) access to the naming services
required to identify peers, and 3) sufficient base security services
to verify the
security of those naming services (which might mean something like
secured time to check certificates). I think the details of 2 might
be a rat-hole
(rendezvous services, address of record, etc.), since I don't think these
actually change the scenarios below in any fundamental way (though there
may, obviously, be a second kind of name resolution after the DNS resolution
that is a focus, it seems likely to be layered in a way that leaves the stages
as they are).
regards,
Ted
At 8:04 PM +0200 7/10/03, Randy Bush wrote:
> my notes say that allison and ted were worried. Ted?
thanks! i have allison's issues. i need ted's.
randy