Date: Wed, 16 Jul 2003 09:56:40 +0200
To: Randy Bush <randy@psg.com>, Harald Tveit Alvestrand <harald@alvestrand.no>
From: hardie@qualcomm.com
Subject: Re: draft-ietf-v6ops-unman-scenarios-02.txt
Cc: iesg <iesg@ietf.org>

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

To: iesg@ietf.org
Subject: Comment: draft-ietf-v6ops-unman-scenarios-02.txt
Cc: iesg-secretary@ietf.org
Date: Thu, 26 Jun 2003 06:47:21 -0700
From: Allison Mankin <mankin@psg.com>

The Security Considerations of this document largely say that security will be
covered in a companion document, but there is a short list of topics covered in
this document.  This list should add one that is very important to the
unmanaged scenarios (related to the recommendation in Section 5.1.2):


  Security considerations are discussed as part of the applications'
  requirements. They include:
 
  - the guarantee that local applications are only used locally,
  - the protection of the privacy of clients
  - the requirement that peer-to-peer connections are only used by
  authorized peers.

Applications in the unmanaged scenarios also need to be protected from
risks associated with the transition tools, for example, access to their
net through an opportunistic tunnel if the IPv6-over-UDP service is not
well-designed.  So I think that it would be reasonable to add to Section
5.1.2 and to the Security Considerations some statement about securing the
recommended tunneling approaches.  Here's some suggested words for the
Security Considerations:

  - the requirement that tunneling protocols used for IPv6 access over
    IPv4 be designed for secure use; the related requirement that servers in
    in the infrastructure supporting this tunneling be designed not to be
    vulnerable to abuse.

(Or something like that).


Nit:

                            In practice, updating
  the DNS can be slow, which implies that server applications will
  have a better chance of being deployed if the IPv6 addresses remain
  stable for a long period.

Oversimplified operational statement.  Does it belong in this document?

From: Pekka Savola <pekkas@netcore.fi>
To: Randy Bush <randy@psg.com>, Bert Wijnen <bwijnen@lucent.com>
Subject: Request to Advance "Unmanaged Networks IPv6 Transition Scenarios"

Hi,

On behalf of the v6ops WG, we request that the following document be
published as an Informational RFC:

Title          : Unmanaged Networks IPv6 Transition Scenarios
Author(s)      : C. Huitema, R. Austein, S. Satapati, R. van der Pol
Filename        : draft-ietf-v6ops-unman-scenarios-02.txt
Pages          : 19
Date            : 2003-6-17

A working group last call for this document was completed on March 2nd,
2003, and the two subsequent revisions of the draft have resolved the
issues raised during the last call.