[EMAIL PROTECTED] 写道:
Send P2PSIP mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/p2psip
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of P2PSIP digest..."
Today's Topics:
1. Re: HIP for P2P SIP (Bruce Lowekamp)
2. Re: HIP for P2P SIP (Ari Keranen)
3. Re: Should draft-bryan-p2psip-reload-04 be adopted as a
workgroup item? (Brian Rosen)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Jun 2008 16:03:38 -0400
From: Bruce Lowekamp <[EMAIL PROTECTED]>
Subject: Re: [P2PSIP] HIP for P2P SIP
To: Ari Keranen <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], Henry Sinnreich
<[EMAIL PROTECTED]>, P2PSIP WG <[email protected]>, [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Ari Keranen wrote:
Bruce Lowekamp wrote:
Henry Sinnreich wrote:
On 6/27/08 11:07 AM, "Eric Rescorla" <[EMAIL PROTECTED]> wrote:
As Bruce indicated in a previous message, HIP needs a rendezvous
service,
and a generic P2P overlay like RELOAD can provide such a service. In
that
respect, HIP would be a client of RELOAD, even if RELOAD itself ran
over ordinary IP.
-Ekr
HIP has been defined with a rendezvous server (RVS) in the HIP
Rendezvous
Extension RFC 5204. Actually, one of the nicer properties is the
flexibility, since any node can act as a rendezvous server; that's
more than
SIP can do.
What am I missing?
Locating a capable (non-NATed) rendezvous server in a distributed
environment without a centralized service provider is itself a
non-trivial problem.
Additionally, even if you have obtained a rendezvous server, you still
need a registration server (RFC5203).
Actually, in HIP you don't need a separate "registration server" to get
rendezvous service but you use the registration extension (RFC5203) to
register to the service. And for the NATed case you should use HIP relay
service, i.e., instead of forwarding just the I1 as in RVS, whole base
exchange is done trough the relaying service. This service can be
provided by a relay server [1] or, e.g., a P2PSIP overlay [2].
I think we must be in violent agreement, modulo a bit of terminology.
Labeling 5203 as defining a "registration server" is a bit of an
oversimplification, but I think accurately identifies one of the roles
the overlay would have to fulfill. And draft-ietf-hip-nat-traversal
merely identifies HIP relay as another role (ice aware) for a rendezvous
server.
I probably should have pointed to rfc5205 as well.
Anyway, the entire purpose of my email was to point out that something
needs to fulfill these two roles, and as suggested by hip-bone and
others, a p2psip overlay is well-suited for the job, particularly in an
ad hoc environment (no provisioned servers or dns). I think we both
agree on that.
Bruce
------------------------------
Message: 2
Date: Tue, 01 Jul 2008 06:57:05 +0300
From: Ari Keranen <[EMAIL PROTECTED]>
Subject: Re: [P2PSIP] HIP for P2P SIP
To: Bruce Lowekamp <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], Henry Sinnreich
<[EMAIL PROTECTED]>, P2PSIP WG <[email protected]>, [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Bruce Lowekamp wrote:
Ari Keranen wrote:
Bruce Lowekamp wrote:
Henry Sinnreich wrote:
On 6/27/08 11:07 AM, "Eric Rescorla" <[EMAIL PROTECTED]> wrote:
As Bruce indicated in a previous message, HIP needs a rendezvous
service,
and a generic P2P overlay like RELOAD can provide such a service.
In that
respect, HIP would be a client of RELOAD, even if RELOAD itself ran
over ordinary IP.
-Ekr
HIP has been defined with a rendezvous server (RVS) in the HIP
Rendezvous
Extension RFC 5204. Actually, one of the nicer properties is the
flexibility, since any node can act as a rendezvous server; that's
more than
SIP can do.
What am I missing?
Locating a capable (non-NATed) rendezvous server in a distributed
environment without a centralized service provider is itself a
non-trivial problem.
Additionally, even if you have obtained a rendezvous server, you
still need a registration server (RFC5203).
Actually, in HIP you don't need a separate "registration server" to
get rendezvous service but you use the registration extension
(RFC5203) to register to the service. And for the NATed case you
should use HIP relay service, i.e., instead of forwarding just the I1
as in RVS, whole base exchange is done trough the relaying service.
This service can be provided by a relay server [1] or, e.g., a P2PSIP
overlay [2].
I think we must be in violent agreement, modulo a bit of terminology.
Labeling 5203 as defining a "registration server" is a bit of an
oversimplification, but I think accurately identifies one of the roles
the overlay would have to fulfill. And draft-ietf-hip-nat-traversal
merely identifies HIP relay as another role (ice aware) for a rendezvous
server.
I probably should have pointed to rfc5205 as well.
Anyway, the entire purpose of my email was to point out that something
needs to fulfill these two roles, and as suggested by hip-bone and
others, a p2psip overlay is well-suited for the job, particularly in an
ad hoc environment (no provisioned servers or dns). I think we both
agree on that.
Yes, we fully agree on that. I was just worried that some people on the
list might get the impression that you need two different servers just
to get the rendezvous service. Thanks for clarifying.
Cheers,
Ari
------------------------------
Message: 3
Date: Tue, 1 Jul 2008 00:07:54 -0400
From: "Brian Rosen" <[EMAIL PROTECTED]>
Subject: Re: [P2PSIP] Should draft-bryan-p2psip-reload-04 be adopted
as a workgroup item?
To: "Rosen, Brian" <[EMAIL PROTECTED]>, "'P2PSIP Mailing List'"
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
There being no objections, draft-bryan-p2psip-reload is hereby adopted as a
working group item against our p2psip peer protocol charter item.
Thanks to the authors for addressing the concerns of the work group.
Chairs will be announcing an editor in Dublin if not before.
As has been stated several times, and in keeping with IETF practice,
adoption of this draft DOES NOT MEAN that all the ideas in it stay as they
are, or the current authors decide what goes in or out. The working group
now controls the document and we have plenty of room and time to mold it to
meet all of our needs within our charter and milestone constraints.
Brian & David (as chairs)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Rosen, Brian
Sent: Tuesday, June 24, 2008 7:49 AM
To: P2PSIP Mailing List
Subject: [P2PSIP] Should draft-bryan-p2psip-reload-04 be adopted as a
workgroup item?
As we discussed in Philly, the authors have addressed the concerns about
the readability and clarity of the prior version of the document. List
discussion so far has been confined to technical discussions on various
aspects of the protocol.
Who objects to making this draft a work group item, and reload, as
currently defined the protocol upon which to base our work?
If you do object, would you please state your reasons and what you would
prefer we do in furtherance of our charter item.
Brian (as chair)
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
------------------------------
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
End of P2PSIP Digest, Vol 19, Issue 1
*************************************
Actually, i do not think both the RELOAD & HIP did not solve all the
technical issue. I work for in system security level, and it is belived
by most of users that a system which is not secured should not be
downloaded and used. May be i make a example.
Several internet draft propose a certificate-based security solution. It
does solved some problems. However, it is not enough for protecting
privacy. In the decentralized system, one malicious peer may become
malicious when it receives the certificate and joins the overlay. That
means he can act as an intermediate peer that read the incoming P2PSIP
request and record a profile of the source and destination privacy.
Later, he can do many malicious things, e.g. send the SPAM, DoS attack,
etc. So, in the decentralized system, currently, there is no solution to
protect the privacy.
And in order to protect privacy, which is the basic servie P2PSIP system
should do, we may need to consider to revise a little bit in revising
the protocol, ..... and so on. That is why i thought the internet drafts
are not enough and powerful currently.
Most of the engineers consider the accessibiliy and availability too
much so that some times they did not think of the security, privacy, and
some basic things. I did when i was working in the network application
field, but now i work more in the system security.
So, i do suggest that we might re-consider the security and privacy
field of P2PSIP before we set some standard to avoid some mistake. This
is my own feeling. Thank you.
Best Regards,
Xianghan Zheng
begin:vcard
fn:Xianghan Zheng
n:Zheng;Xianghan
org:University of Agder;ICT
adr;dom:;;;Grimstad
email;internet:[EMAIL PROTECTED]
title:PHD Student
tel;work:+47 37253441
url:www.uia.no
version:2.1
end:vcard
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
