Subject: [P2PSIP] My notes from tonight's ad hoc

From: Spencer Dawkins <[email-masked]>
Date: Mon, 23 Jul 2007 23:56:49 -0500

Not remotely complete, but just to share with others...

Presentation materials are available at https://datatracker.ietf.org/meeting/69/materials.html (scan down to RAI-P2PSIP).

Spencer

--------------------------------

XPP

Focus in this proposal is to be extremely simple. Probably too simple - UDP transport only, for example, and using stop-and-wait strategy with no windowing.

Overlay-centric mechanism in XPP - clients don't decide to join overlays, peers in the overlay invite clients to join the overlay as peers.

DHT operations are session-oriented - why? Mostly to open ports before sending requests.

LOCSER

This protocol proposal is based on unmodified HIP. Jonathan Rosenberg does not understand how this proposal works with ICE. This is a bad sign.

In this proposal, the HIT is NOT the peer ID. EKR thinks this is a problem, not a detail.

RELOAD

This proposal evolved from dSIP proposal. He's looking to add details.

HIPHOP

Presentation is focused on the differences between HIPHOP and other protocols.

Proposal is actually to use three separate protocols (distributed transport, distributed databases, and overlay maintenance. Proposal is able to provide this functionality with few-to-no changes to the HIP API, but requires IPv6 to work correctly.

EKR is very concerned about proposals that require kernel changes.

Jonathan is concerned about the use of public keys related to HITs - it's hard to come up with an exact match to the HIT, but you don't need to guess exact matches - you just have to be able to compute a HIT that puts me closer to the target peer than any other peer is, in order to insert yourself next to the targeted peer. The more peers you have, the better the change you have to guess peer IDs, etc.

ASP

ASP proposal guards based on two threats - to storage, and to routing.

General Discussion

Everyone wants to reroute responses if a response is undeliverable because a peer ID has changed - but that's really, really hard.

Distinctions - kernel mods required, identifier selections, steps a client takes to establish a connection. whether proposal is considered complete or not, whether the proposal uses HIP or not. whether hop-by-hop security is provided, or only end-to-end security .relationship to SIP.

SIP was never designed to work with malicious proxies.

ICE inherently has "connection is coming semantics", so all these protocols probably have this model implicitly.

All the proposals probably support unmodified SIP clients, although this may not be well-fleshed out.

Nobody talked about "non-SIP clients" in these proposals. 

A couple of proposals claim "mobility", but Jonathan says this comes along with ICE restarts.

Whether you route based on HIT or route based on peer ID which may not be a HIT.
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 24 Jul 2007 13:16:45 -0400

I was not there for this session. I don't see any presentations on
P2PP/Baset+Schulzrinne. I am assuming that's still an active proposal at
this point?

On 7/24/07, Spencer Dawkins <[email-masked]> wrote:
> Presentation materials are available at
> https://datatracker.ietf.org/meeting/69/materials.html (scan down to
> RAI-P2PSIP).
>
> Spencer
>
> Focus in this proposal is to be extremely simple. Probably too simple –
> UDP transport only, for example, and using stop-and-wait strategy with no
> windowing.
>
> Overlay-centric mechanism in XPP – clients don't decide to join overlays,
> peers in the overlay invite clients to join the overlay as peers.
>
> DHT operations are session-oriented – why? Mostly to open ports before
> sending requests.
>
> LOCSER
>
> This protocol proposal is based on unmodified HIP. Jonathan Rosenberg does
> not understand how this proposal works with ICE. This is a bad sign…
>
> Proposal is actually to use three separate protocols (distributed
> transport, distributed databases, and overlay maintenance. Proposal is able
> to provide this functionality with few-to-no changes to the HIP API, but
> requires IPv6 to work correctly.
>
> Jonathan is concerned about the use of public keys related to HITs – it's
> hard to come up with an exact match to the HIT, but you don't need to guess
> exact matches – you just have to be able to compute a HIT that puts me
> closer to the target peer than any other peer is, in order to insert
> yourself next to the targeted peer. The more peers you have, the better the
> change you have to guess peer IDs, etc.
>
> ASP
>
> ASP proposal guards based on two threats – to storage, and to routing.
>
> General Discussion
>
> Everyone wants to reroute responses if a response is undeliverable because
> a peer ID has changed – but that's really, really hard.
>
> Distinctions – kernel mods required, identifier selections, steps a client
> takes to establish a connection… whether proposal is considered complete or
> not, whether the proposal uses HIP or not… whether hop-by-hop security is
> provided, or only end-to-end security …relationship to SIP.
>
> ICE inherently has "connection is coming semantics", so all these
> protocols probably have this model implicitly.
>

-- 
Medhavi Bhatia

CTO, 3CLogic
www.3clogic.com

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jul 2007 13:50:28 -0400

Yes it is.  No one from that group was available last night to present.
Salmon will be here Thursday.  Henning is on vacation.

Brian

  _____  

From: Medhavi Bhatia [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 1:17 PM
To: Spencer Dawkins
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] My notes from tonight's ad hoc

On 7/24/07, Spencer Dawkins < <mailto:[email-masked]>
[email-masked]> wrote:

Spencer

XPP

Focus in this proposal is to be extremely simple. Probably too simple - UDP
transport only, for example, and using stop-and-wait strategy with no
windowing.

Overlay-centric mechanism in XPP - clients don't decide to join overlays,
peers in the overlay invite clients to join the overlay as peers.

DHT operations are session-oriented - why? Mostly to open ports before
sending requests.

LOCSER

This protocol proposal is based on unmodified HIP. Jonathan Rosenberg does
not understand how this proposal works with ICE. This is a bad sign.

In this proposal, the HIT is NOT the peer ID. EKR thinks this is a problem,
not a detail.

RELOAD

HIPHOP

Presentation is focused on the differences between HIPHOP and other
protocols.

Proposal is actually to use three separate protocols (distributed transport,
distributed databases, and overlay maintenance. Proposal is able to provide
this functionality with few-to-no changes to the HIP API, but requires IPv6
to work correctly.

Jonathan is concerned about the use of public keys related to HITs - it's
hard to come up with an exact match to the HIT, but you don't need to guess
exact matches - you just have to be able to compute a HIT that puts me
closer to the target peer than any other peer is, in order to insert
yourself next to the targeted peer. The more peers you have, the better the
change you have to guess peer IDs, etc.

ASP

General Discussion

Everyone wants to reroute responses if a response is undeliverable because a
peer ID has changed - but that's really, really hard.

Distinctions - kernel mods required, identifier selections, steps a client
takes to establish a connection. whether proposal is considered complete or
not, whether the proposal uses HIP or not. whether hop-by-hop security is
provided, or only end-to-end security .relationship to SIP.

ICE inherently has "connection is coming semantics", so all these protocols
probably have this model implicitly.

All the proposals probably support unmodified SIP clients, although this may
not be well-fleshed out.

A couple of proposals claim "mobility", but Jonathan says this comes along
with ICE restarts.

Whether you route based on HIT or route based on peer ID which may not be a
HIT.

-- 
Medhavi Bhatia

CTO, 3CLogic
www.3clogic.com