Re: [P2PSIP] Trying to grasp what we really are standardizing...

["Greger V. Teigre" <[e-mail]>]

David A. Bryan wrote:
> I think there are several ways the NAT functions can be handled, just
> a few I have seen proposed are:
>
> * P2P layer == SIP layer, both use SIP functions to traverse NATs
> * P2P layer does its own NAT traversal, and is used to either
> negotiate openings or encapsulates the SIP layer traffic
> * SIP layer does the NAT traversal, and session and NAT traversal of
> the P2P is negotiated there (perhaps it is listed as an SDP stream)
> * The two layers are completely independent
Thanks, good summary. My point is that it seems that NAT handling for 
p2p networks and SIP are different enough to justify a separate analysis 
(I think draft-matthews-p2psip-nats-and-overlays-01 does a good job 
there). My interpretation is that the type of p2p network has also an 
impact on NAT handling. So, using SIP concepts to solve NAT in p2p 
networks seems to me as a classic "if you have a hammer..." case.
>
> Also people have discussed if ICE is appropriate for the P2P protocol
> negotiation, assuming it is not SIP (no one is seriously (at least I
> hope not) proposing inventing something other than ICE for the NAT
> traversal on the SIP side...)
>
What a relief! ;-)
> I agree that we should probably analyze the two NAT traversal
> mechanisms seperately, but I personally think we will find ICE is the
> answer in each case, and I really don't like the idea of having to
> implement two different NAT traversal techniques and do NAT traversal
> two times for the two protocols. 
Well, ICE is clearly not the answer to all the NAT issues. ICE is about 
detecting, while NAT has detection element, a routing element, as well 
as a traversal complexity element (i.e. ALG/firewalls). It is made for 
offer/answer protocols and is suitable to solve NAT from that point of view.

draft-matthews-p2psip-hip-hop-00 offers an alternative where NAT 
traversal is handled transparently. Deep in that draft and in the 
references, there is something interesting found (from the 
"analyze-in-layers" perspective"). Let me try to pull it forward and 
summarize from a NAT perspective (for the sake of discussion):

IPsec has over the years had a lot of trouble with NAT traversal and 
ALGs. It has gone through all the pains and with UDP-encapsulation, 
NAT-T and port floating to port 4500, it has by now fairly good NAT 
traversal characteristics. Let's say each peer establishes IPsec tunnels 
with each peer, using their certificates in IKE, and calculating a 
virtual IP address (peerID). We know IPsec mostly as a network stack 
protocol, but why not implement it on the application layer? (ref. 
ongoing draft-nikander-esp-beet-mode-07)

Implement p2p routing on top of it (HIP, dSIP, whatever you like), using 
the peerID/IP address, and you have a virtual network between all peers, 
all can establish tunnels with each other (and maybe negotiate dht to 
use etc), the p2p layer can provide the SIP UA with a non-NATed network. 
All signaling is secured and relaying can easily be offered as a service 
to the SIP layer.

The benefit of layering is that you can reuse existing software 
implementations directly, you leverage years of NAT traversal 
experience, and you avoid that p2psip enabling of existing UAs turns 
into a large software implementation project with lots of uncertain 
characteristics.

This is NOT intended as an argument in favor of hip-hop vs. dSIP, rather 
an example to show why I don't like the NAT discussion to be preempted 
as "ice will be the choice anyway." I'm afraid it will prevent us from 
looking at other approaches (or reducing ice to the subset we really need).

> This group is about making a protocol
> for P2P *specifically* for SIP, we don't need to go out our way to
> make it function in other cases, so I think reuse of ICE makes the
> most sense. 
Is that a shared understanding? It seems to me that there is a push to 
make it usable in non-SIP scenarios as well?
> There may be an IETF group to do more generic P2P someday
> (I hope so), and hopefully it will grow from our work, but this group
> is sort of a baby-step that direction for the IETF -- try to see if a
> group can make a P2P protocol work in a narrow problem space like P2P
> specifically for SIP -- before deciding about more general P2P
> protocols.
>
> As far as why we are talking about standardizing the DHT between
> peers, I'll give you my take. The IETF goal is to allow
> implementations from different vendors to work together
> interchangably. The IETF doesn't define code APIs, they standardize
> the protocols that go over the wire. It isn't about an API that every
> SIP UA can implement to call a P2P library, it is about different P2P
> devices from different vendors, scattered across the internet or
> within an organization being able work together to form a serverless
> environment. To think similarly, we aren't saying "here is a set of
> code hooks a web browser can use, and underneath developers can write
> a library to access "their" proprietery web".  Instead, we are making
> sure that all the P2PSIP devices across the internet, regardless of
> vendor, can be interchangably connected into a P2P overlay and work
> together.
Yes, I'm sorry, the API example was confusing. I was trying to emphasize 
the possibility that we don't have a p2p aware SIP UA and a SIP-aware 
p2p client, and that trying to keep them apart would be good from an 
analysis point of view, because doing so may give us better answers than 
keeping both p2p and SIP in our heads at the same time.
g-)

> David
>
> On 6/25/07, Greger V. Teigre <[e-mail]> wrote:
>>
>>
>> Philip Matthews wrote:
>> >
>> > On 25-Jun-07, at 06:00 , Greger V. Teigre wrote:
>> >> So, based on my lack of understanding of the above, pardon my lack of
>> >> understanding on some other issues:
>> >> - How NAT is handled on the p2p layer should have nothing to do with
>> >> the SIP layer.  One should be free to make any decision, right?
>> >
>> > It seems to me that you are talking about a P2P layer architecture
>> > like the one described in
>> >     draft-matthews-p2psip-hip-hop-00
>> > which talks about a P2P layer that sits below the SIP layer and
>> > provides three main functions:
>> >    1) Distributed Database
>> >    2) Overlay Maintenance
>> >    3) Distributed Transport (e.g., routing messages around the 
>> overlay)
>> > Is this correct?
>> Well, I didn't really take a position on the actual layering, I was just
>> trying to look at the functions that must be presented to the pure SIP
>> UA. Unless I'm completely mistaken, a pure SIP UA should be able to
>> contact a SIP UA using the p2p overlay in a completely transparent
>> fashion. Those two UAs, one registered with a SIP registrar (c/s), the
>> other in a p2p overlay should be able to use ice to set up the dialog.
>> If a relay is needed, it really doesn't matter if a server in the c/s
>> domain offers the relay or if the p2p overlay offers the relay as a
>> service (or maybe both and the best is chosen).
>>
>> I would think that a pure SIP UA maybe could establish sip-outbound
>> flows both to a SIP registrar (c/s) and to a peer in the overlay (acting
>> as a registrar). This could enable emergency/disaster redundancy or even
>> be useful for service providers.
>> > With the architecture above, I don't see how you can handle NAT
>> > traversal at the SIP layer for SIP signaling. The only proposal that I
>> > have seen that handles NAT traversal at the SIP layer for SIP
>> > signaling is dSIP, and dSIP does not have a separate P2P layer but
>> > does everything in SIP. If you are going to separate the P2P layer
>> > from the SIP layer, then I think you are pretty much forced to put NAT
>> > traversal logic in the P2P layer for both P2P messages and for SIP
>> > signaling. The only thing you could leave up at the SIP layer is NAT
>> > traversal for RTP packets.
>> My point is that NAT-traversal for SIP and NAT-traversal on the P2P
>> layer really is logically two separate things, and they should be
>> analyzed separately. It may well be that the underlying p2p layer can
>> offer the SIP layer a non-NATed routing environment (indeed, it is
>> probably desirable), but in theory the p2p layer can tackle it's own
>> signaling NAT traversal without offering the SIP layer a non-NATed
>> routing environment (leaving private IP addresses in SIP messages).
>> g-)
>> >
>> >
>> >
>> > - Philip
>> >
>> >
>>
>> _______________________________________________
>> P2PSIP mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/p2psip
>>
>
>

_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip