Subject: [p2p-sip] SIP, ICE, and an Overlay Network

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Sat, 18 Mar 2006 08:56:19 -0800

Though, with cost of time and bandwidth, predictive or probabilistic
port-scan can shoot msg to a node behind a nat eventually, is it possible
that such port-scan can interfere other nodes or existing sessions behind
enterprise firewalls which often have many nodes (sessions) any time so that
have created many "penetratable" holes on the firewalls?

That is, even if an inward probing msg can penetrate a firewall after some
attempts, it might visit many wrong peers (sessions) before it reaches the
right one.

Also, if there are N nodes behind firewall A and N nodes behind firewall B
scan (shoot) each other simultaneously trying to setup N 1-to-1 sessions,
the match can have N*N combinations. Will p2p-sip WG define some protocol to
resolve the possible N*(N-1) "ill-matched" connections?

Or, these are another stupid questions besides the one which questioned how
to interoperate nodes of a p2p-sip Chord overlay with those of a p2p-sip
Kademlia overlay -- peered or bridged???

peter
----- Original Message -----
From: "Peter Pan" <huang-ming.pan at comcast.net>
To: "David Barrett" <dbarrett at quinthar.com>; "'Roy, Radhika R.'"
<RADHIKA.R.ROY at saic.com>; "'Michael Slavitch'" <slavitch at objectworld.com>;
"'Greg Daley'" <gregd at research.panasonic.com>; "'Michael Slavitch'"
<slavitch at gmail.com>
Cc: "'P2P-SIP'" <p2p-sip at cs.columbia.edu>
Sent: Friday, March 17, 2006 1:44 PM
Subject: Re: [p2p-sip] SIP, ICE, and an Overlay Network

>
> For p2p-sip to be accepted by enterprises where there are often hundreds
of
> nodes behind (normally symmetric) nats, do we need to standardize the
> "radius" of probabilistic port-scan so that their network administrators
> won't treat port scanning by p2p-sip nodes as a security threat?
>
> Does it seem also better to recognize the multiplexing media streams with
> SIP signaling stream as a valid and encouraged option in next RFC for
> (non-p2p) SIP/3.0 :-)
>
> peter
> ----- Original Message -----
> From: "David Barrett" <dbarrett at quinthar.com>
> To: "'Peter Pan'" <huang-ming.pan at comcast.net>; "'Roy, Radhika R.'"
> <RADHIKA.R.ROY at saic.com>; "'Michael Slavitch'" <slavitch at objectworld.com>;
> "'Greg Daley'" <gregd at research.panasonic.com>; "'Michael Slavitch'"
> <slavitch at gmail.com>
> Cc: "'P2P-SIP'" <p2p-sip at cs.columbia.edu>
> Sent: Friday, March 17, 2006 1:03 PM
> Subject: RE: [p2p-sip] SIP, ICE, and an Overlay Network
>
>
> > > -----Original Message-----
> > > From: Peter Pan [mailto:huang-ming.pan at comcast.net]
> > > Subject: Re: [p2p-sip] SIP, ICE, and an Overlay Network
> > >
> > > Maybe my limited knowledge of nat penetration leaves us on different
> > > pages.
> > >
> > > Just few questions:
> > >
> > > 1. If peers behind all types of nats can establish direct connection
> > > between
> > > each other *easily or anyway", why TURN comes up? (even Skype seems
> using
> > > some kind of TURN relay)
> >
> > Even the best NAT penetration isn't 100% reliable, so the TURN service
is
> > the fall back plan.  But NAT penetration over 75% is straightforward,
and
> > high 90% is possible -- even >99% has been claimed.
> >
> >
> > > 2. If using two internal ports doubles risk of failure of connection
> > > establishment, does it mean that, for two hosts behind a nat, after
one
> > > host
> > > gets connected (inward or outward), another will be double harder to
get
> > > connected??
> >
> > Ah, no I'm referring to the prospect of partial failure.  For example,
in
> > iGlance you can text-chat, voice-chat, videoconference, screen share,
and
> > send files.  Were each of these using a different connection, the risk
> that
> > at least one of these channels fails to penetrate the NAT goes up.  And
> then
> > you're faced with the problem where your video channel is direct P2P,
> while
> > your audio channel is relayed through a TURN server.  This leads to all
> > sorts of odd behavior for the user.
> >
> > By having everything either completely work or completely fail, it gives
a
> > cleaner experience for the user.
> >
> >
> > > 3. If the overhead to open a udp socket can be ignored (it can be
> > > usually),
> > > does it need double cpu/bandwidth to use the udp socket to communicate
> > > with
> > > two peers?
> >
> > The setup cost isn't so much in creating UDP sockets, it's in conducting
> the
> > connection process.  In the worst case of symmetric NATs, this can
involve
> > doing a probabilistic port-scan of the remote host.  Thus setting up one
> > connection between two peers could conceivably involve hundreds of
packets
> > going back and forth over many seconds time.
> >
> >
> > > 4. From the sentence, "I *love* the idea of standardizing this
behavior.
> > > It
> > > works great for me and my users", I thought one-port approach will
loved
> > > to
> > > be standardized. Sorry, I misunderstood your *love* :-)
> > >
> > > I do (+ did) *love* the idea of port convergence, though. Actually
when
> a
> > > secure transport layer is necessarily beneath all packet streams for
p2p
> > > security, one-port approach is indeed as sweet as you love to suggest.
> >
> > Heh, I guess what I meant is I'd like my beloved approach to be
recognized
> > as a valid and encouraged option, but by no means the only option.
> >
> > -david
> >
>