An Analysis of the Skype Peer-to-Peer Internet Telephony
Protocol
Salman A. Baset and Henning Schulzrinne
Department of Computer Science
Columbia University, New York NY 10027
{salman,hgs}@cs.columbia.edu
September 15, 2004

> -----Original Message-----
> From: Marshall Eubanks [mailto:tme@multicasttech.com]
> Sent: Wednesday, April 05, 2006 1:29 PM
> To: Reinaldo Penno
> Cc: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org
> Subject: Re: [Speermint] NATs and Firewalls
> 
> 
> On Apr 5, 2006, at 4:00 PM, Reinaldo Penno wrote:
> 
> > Oh...The "S" word. I thought that was banned or something...
> >
> > Well, Columbia people performed a recent study on Skype. It uses a
> > version of STUN to bypass firewall without the "other" user knowing
it
> > is a STUN server. There are other things it does that one would
frown
> > upon.
> 
> Can you give a reference ? I am aware of
> 
> http://saikat.guha.cc/pub/iptps06-skype.pdf and
> http://www.brynosaurus.com/pub/net/p2pnat.pdf
> 
> but no paper from Columbia.
> 
> Regards
> Marshall
> 
> >
> > On the other hand during the VON conference is San Jose I had the
> > pleasure to participate in the big Pow Wow about P2P SIP. Most of
the
> > debate was centered on Skype. The impression I had when I left the
> > room
> > was that skype's success has nothing to do with it being P2P, but
its
> > ease of use and ability to overcome NAT/Firewalls. So, making sure
our
> > peer arch works well when endpoints in different domains are behind
> > NATs, seems pretty important.
> >
> > Of all the NAT traversal methods, media relay (a typical SBC
function)
> > is one of the most foolproof. The call flow and the translation it
> > needs
> > to do are complex but it can overcome legacy NATs without any client
> > modification (maybe symmetric RTP).
> >
> > Of course a SIP traversal method in the client itself bundled with
the
> > application software (or OS) would be simpler and have a higher
> > adoption
> > (as in skype). I guess the problem today is that there is no single
> > solution. What you have is a set of methods. I guess others are
better
> > suited to talk about this topic in detail.
> >
> > Regards,
> >
> > Reinaldo
> >
> >> -----Original Message-----
> >> From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com]
> >> Sent: Wednesday, April 05, 2006 6:59 AM
> >> To: Drage, Keith (Keith); speermint@ietf.org
> >> Subject: RE: [Speermint] NATs and Firewalls
> >>
> >> Agree.  Let's avoid the term "SBC" in the speermint area.  We don't
> >> need the history lesson and the term is still evolving.  I just
> > finished
> >> a Skype call and did not use a SBC to peer with my one in 6 million
> > users.
> >>
> >> Yes, let's just define the requirements ... Edge Proxy, NAPT, Media
> > Proxy,
> >> Security Firewall and NAT/firewall traversal.
> >>
> >> /PETER MACAULAY
> >>
> >> At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote:
> >>> And to support Richard on this.
> >>>
> >>> Please avoid using the term "SBC" in the speermint area. Please
> >>> clearly identify the function of these supposed wonder boxes that
> >>> you are addressing as an area of concern or advantage. Therefore
if
> >>> you mean NAT, say NAT, if you mean firewall, say firewall, if you
> >>> mean something else, say so. These boxes contain so many features
> >>> (in the widest sense of the word) that in the absence of specific
> >>> information we get lost.
> >>>
> >>> regards
> >>>
> >>> Keith
> >>>
> >>>> -----Original Message-----
> >>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> >>>> Sent: 04 April 2006 18:15
> >>>> To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;
> >>>> speermint@ietf.org
> >>>> Subject: [Speermint] NATs and Firewalls
> >>>>
> >>>>
> >>>> I think some people out there either do not understand
> >>>> the difference between NATs and firewalls or are starting
> >>>> to believe their own propaganda
> >>>>
> >>>> NATs are NATs and firewalls are firewalls
> >>>>
> >>>> The worst misconception here is that a NAT is for providing
> >>>> you security
> >>>> against the bad Internet
> >>>>
> >>>> Private adress spaces have been introduced to save a scarce
> > ressource
> >>>> (or what some believed are a scarce ressource at some point of
> > time)
> >>>>
> >>>> You can live very safe behind a properly configured firewall
> >>>> using only
> >>>> public IP adresses.
> >>>>
> >>>> The basic idea of IPv6 was to give every device on earth and also
> >>>> within the solar system a unique public IP address
> >>>>
> >>>> But the fake security of NATs was already in the minds of
> >>>> most people, that the first things that were implemented
> >>>> in IPv6 where NATs for IPv6, which is a perversion
> >>>>
> >>>> Geoff Huston had once a nice eleborate on this in an IETF paper
> >>>>
> >>>> Richard
> >>>>
> >>>> ________________________________
> >>>>
> >>>> Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
> >>>> Gesendet: Di 04.04.2006 18:22
> >>>> An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno';
> >>>> speermint@ietf.org
> >>>> Betreff: RE: [Speermint] Reachability
> >>>>
> >>>>
> >>>>
> >>>> Hi Richard,
> >>>> And here we get to the fun stuff.  :)
> >>>>
> >>>> The idea of every serving proxy/registrar/sip-node needing to
> >>>> be publicly
> >>>> addressable is neither an Internet requirement, nor a
> >>>> requirement of the
> >>>> IETF.  Entire working groups in the IETF concern themselves
> >>>> with allowing,
> >>>> enabling, and inter-working private address spaces and VPNs.
> >>>> What's missing
> >>>> is how to join them at the application and transport layer, when
> > that
> >>>> application layer embeds addressing in itself.
> >>>>
> >>>> Most consumers on the planet Earth are in private address
> >>>> spaces at this
> >>>> point I think (i.e., 192.168.x.x), and many Enterprises are
> >>>> as well.  Entire
> >>>> networks in some countries are privately addressed, yet they
> >>>> are members of,
> >>>> and use, the Internet.  There are also now 2 disjoint address
> >>>> groups defined
> >>>> by the IETF, as you know: IPv4 and IPv6.  There are
> >>>> mechanisms to try to
> >>>> provide interoperation/migration support for them, but that
> > typically
> >>>> requires intermediaries.
> >>>>
> >>>> So I agree with you there needs to be an entity providing an
> >>>> ingress (and
> >>>> egress) point(s), either on the public network for it to be
> >>>> public, or for
> >>>> it to cross into another private address domain.  For this
> >>>> WG's purpose, I
> >>>> recommend we allow either model to work, as well as the model
> >>>> of the private
> >>>> going to public (and vice-versa) so long as the peering
> >>>> element of both
> >>>> sides are in the same public or private space.
> >>>>
> >>>> -Hadriel
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> >>>>> Sent: Tuesday, April 04, 2006 9:55 AM
> >>>>> To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan;
> >>>> speermint@ietf.org
> >>>>> Subject: Re: [Speermint] Reachability
> >>>>>
> >>>>>> The conclusion here -- every endpoint and every serving
> >>>> proxy/registrar
> >>>>>> needs to be publicly addressable.
> >>>>>
> >>>>> This was my basic assumption, and I seemed not so clear to
> >>>> everybody.
> >>>>> This was also why I had a problem with Sohel's presentation
> >>>> at the IETF,
> >>>>> because I did not see any public adressable entities AT ALL.
> >>>>>
> >>>>> For the avoidance of doubt: I have no problem if the same
> > peering
> >>>>> principles we develop here are used between some entities
> >>>> in a private
> >>>>> network,
> >>>>> but it is not out task to consider this separately. Because
> >>>> if it works
> >>>>> on the Internet, it also works in a private network
> >>>> (extranet in this
> >>>>> case)
> >>>>> (see DNS). this private network may even use public IP
> >>>> adresses, but if
> >>>>> the
> >>>>> are not routable from the public Internet, they are could as
> > well be
> >>>>> private
> >>>>> (example IPX)
> >>>>>
> >>>>> What never can work is a peering between one entity on the
> >>>> public network
> >>>>> and one on a private network. The private entities need at
> >>>> least to have
> >>>>> one
> >>>>> ingress element on the public network
> >>>>>
> >>>>> Richard
> >>>>>
> >>>>> ________________________________
> >>>>>
> >>>>> Von: Patrick Melampy [mailto:PMelampy@acmepacket.com]
> >>>>> Gesendet: Di 04.04.2006 15:29
> >>>>> An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org
> >>>>> Betreff: RE: [Speermint] Reachability
> >>>>>
> >>>>>
> >>>>>
> >>>>> Reinaldo -- I agree with your assertions.
> >>>>>
> >>>>> But I want to ensure everybody understands what your really
> >>>> saying here.
> >>>>>
> >>>>>   Before somebody mentions it...for a UA behind a NAT to be
> >>>> reachable,
> >>>>>   he/she needs a public NAT binding so that a session
> >>>> _initiated_ from the
> >>>>>   public side can be made to him/her.
> >>>>>
> >>>>> This means that for carrier to carrier peering models, each
> >>>> and every
> >>>>> customer of every carrier that wants to inter-connect needs
> >>>> to have a
> >>>>> 'public NAT binding'.
> >>>>>
> >>>>> I believe by extension, this means that a serving
> >>>> proxy/registrar for the
> >>>>> target of a communication must ALSO have either a public
> >>>> address or a
> >>>>> public
> >>>>> NAT binding.
> >>>>>
> >>>>> The conclusion here -- every endpoint and every serving
> >>>> proxy/registrar
> >>>>> needs to be publicly addressable.
> >>>>>
> >>>>> Am I correct?
> >>>>> -----Original Message-----
> >>>>> From: Reinaldo Penno [mailto:rpenno@juniper.net]
> >>>>> Sent: Tuesday, April 04, 2006 5:29 AM
> >>>>> To: Hadriel Kaplan; speermint@ietf.org
> >>>>> Subject: RE: [Speermint] Reachability
> >>>>>
> >>>>> Hello Hadriel,
> >>>>>
> >>>>> Comment inline....
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
> >>>>>> Sent: Monday, April 03, 2006 11:01 PM
> >>>>>> To: Reinaldo Penno; speermint@ietf.org
> >>>>>> Subject: RE: [Speermint] Reachability
> >>>>>>
> >>>>>> Hi Reinaldo,
> >>>>>> Comments inline...
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Reinaldo Penno [mailto:rpenno@juniper.net]
> >>>>>>>
> >>>>>>> Maybe I'm missing something, but given that this workgroup
> > is
> >>>>> interested
> >>>>>>> only in call routing (E.164 is out of scope), do we
> >>>> really need to
> >>>>> care
> >>>>>>> about that? An AoR in the end will be translated to an
> >>>> IP address,
> >>>>> and
> >>>>>>> IP addresses have a very good definition of public and
> >>>> private (in
> >>>>> IPv4
> >>>>>>> and IPv6).
> >>>>>>
> >>>>>> I don't understand fully what you mean.  An AoR is only fully
> >>>>> "translated"
> >>>>>> to an IP Address (and really to a contact URI) by the
> >>>> AoR's domain.
> >>>>> So
> >>>>>> what
> >>>>>> you're saying is if the AoR's user-part represents a
> >>>> consumer behind a
> >>>>>> home
> >>>>>> NAT (a private IP), then it is a private AoR; but for
> >>>> those consumers
> >>>>> who
> >>>>>> don't use home-NATs then it's a public AoR?
> >>>>> [[Reinaldo]]
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> Actually I'm trying to understand the whole purpose of the
> >>>> discussion,
> >>>>> that's why I gave that example. I was trying to understand why
> > it
> >>>>> matters, before getting knee deep into the classification.
> >>>> Can someone
> >>>>> refresh that for me?
> >>>>>
> >>>>> So, if SIP peering is going to get woven into the fabric of the
> >>>>> internet, the rules for domains names, DNS resolution, private
> > vs.
> >>>>> public IP address, etc should apply, right?
> >>>>>
> >>>>> I believe the current model of host to host or email
> >>>> communication is
> >>>>> not different for SIP. We could have the following main
> >>>>> situations...(correct me where I'm wrong).
> >>>>>
> >>>>> 1) The AoR (just like a traditional domain name or email),
> >>>> in the end
> >>>>> will get resolved into an IP address. Then there are only two
> >>>>> situations.
> >>>>>
> >>>>>    a) the IP address is private (RFC 1918).
> >>>>>
> >>>>>    This means the SIP endpoint is unreachable unless you
> >>>> are also in the
> >>>>> same private network. Actually I believe a private IP address
> > cannot
> >>>>> even be provisioned in a public DNS.
> >>>>>
> >>>>>    Before somebody mentions it...for a UA behind a NAT to
> >>>> be reachable,
> >>>>> he/she needs a public NAT binding so that a session
> >>>> _initiated_ from the
> >>>>> public side can be made to him/her.
> >>>>>
> >>>>>    b) the IP address is public.
> >>>>>
> >>>>>    The SIP endpoint is theoretically reachable.
> >>>>>
> >>>>> 2) The AoR cannot get translated. Again, just like the
> >>>> Internet we have
> >>>>> today, this means the domain name/user is private, does not
> >>>> exist, etc
> >>>>>
> >>>>> All this has been happening okay with just a few basic
> >>>> rules. If an AoR
> >>>>> is very similar to an email address, why it would not work with
> > the
> >>>>> current infrastructure/definitions?
> >>>>>
> >>>>> If somebody says that they have a "private" email address or
> > domain
> >>>>> name, what is your interpretation of that?
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Reinaldo
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>  And if the AoR gets
> >>>>>> translated
> >>>>>> into an IP by a registrar inside a private IP subnet, and
> >>>> somehow it
> >>>>> later
> >>>>>> gets translated into the public IP address space, that's
> >>>> also private
> >>>>>> because the AoR was translated to a private IP originally?
> >>>>>>
> >>>>>> Or maybe you mean what the domain part of the AoR resolves to?
> >>>>>>
> >>>>>>> For you to be "SIP reachable", you need to be IP
> >>>> reachable first,
> >>>>> let's
> >>>>>>> not forget about that. And if you are IP reachable, you
> > could
> >>>>>>> potentially be SIP reachable by registering to some
> >>>> free SIP service
> >>>>> (or
> >>>>>>> the SIP "domain" above you in the hierarchy...if this was
> > the
> >>>>> email/DNS
> >>>>>>> model).
> >>>>>>
> >>>>>> Actually, to be very specific ultimate target of the AoR
> >>>> can be "sip
> >>>>>> reachable" but not IP reachable.  But I think for now we
> >>>> should ignore
> >>>>> the
> >>>>>> implications of that, unless it becomes a problem.
> >>>>>>
> >>>>>> -hadriel
> >>>>>
> >>>>> _______________________________________________
> >>>>> Speermint mailing list
> >>>>> Speermint@ietf.org
> >>>>> https://www1.ietf.org/mailman/listinfo/speermint
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Speermint mailing list
> >>>>> Speermint@ietf.org
> >>>>> https://www1.ietf.org/mailman/listinfo/speermint
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Speermint mailing list
> >>>> Speermint@ietf.org
> >>>> https://www1.ietf.org/mailman/listinfo/speermint
> >>>>
> >>>
> >>> _______________________________________________
> >>> Speermint mailing list
> >>> Speermint@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/speermint
> >>
> >> _______________________________________________
> >> Speermint mailing list
> >> Speermint@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/speermint
> >
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint