sip.edu - Re: [sip.edu] Call Tomorrow - 7/20 (SPIT Prevention)
Subject: SIP in higher education
List archive
- From: Ben Teitelbaum <>
- To:
- Subject: Re: [sip.edu] Call Tomorrow - 7/20 (SPIT Prevention)
- Date: Wed, 19 Jul 2006 20:49:19 -0400
Forwarded for John who was having some trouble with the list. (It's
an interesting and elegant idea--check it out!) -- ben
John Todd
<>
writes:
> I've had some SPF-like ideas kicking around for a while, but I've not
> been particularly aggressive in doing anything about them. Here is
> some discussion from a few months ago that may be interesting to the
> group:
>
>
>>To: [some people]
>>From: John Todd
>><>
>>Subject: DNS questions/protocol questions
>>
>>
>>All -
>> I have an idea for SIP SPIT control I've been kicking around for a
>> while, and it's time that I made it into an RFC draft or at least a
>> BCP. I may have discussed it you before, but I don't remember with
>> whom I've had discussions on this topic in the last few
>> months... The three of you are well-positioned to think about this
>> topic and/or shoot holes in the specific ways that I'm going about
>> doing things. I'd like to get your input before I start to put this
>> into a more official format.
>>
>> Problem: Any IP-based device on the Internet can create calls via
>> SIP to any other SIP endpoint. The originator can claim to be from
>> any SIP domain, and the destination SIP endpoint has no way to
>> determine if the originator is "allowed" to use the originating
>> domain as part of a SIP call, much less if the user portion of the
>> URI is valid. With the proliferation of SIP URI dialing (i.e.:
>> "sip:"
>> rings my phone) this will inevitably lead to
>> unsolicited and unwanted calls from destinations who are falsifying
>> or obscuring their identity (both SIP domain and/or user identity.)
>>
>> What is needed: It would be ideal to authenticate the full
>> identity of a caller before they are allowed to create a call to an
>> end device. There are RFCs in place which provide this full
>> authentication, but their implementations are complex and have very
>> few implementations that are widely used in a complete manner, nor
>> is such a complete use foreseeable in the near or mid-term future,
>> though the threats from unsolicited communications is looming
>> large. If it were possible to even just verify that the SIP domain
>> was "valid" on an incoming call (where "valid" means that the DNS
>> administrator on the originating domain has authorized the IP
>> address in question to use that domain name) then it would be
>> possible for endpoint proxy operators to reject or accept calls
>> based on simple blacklist/whitelists or to implement some other
>> distributed method to accept or reject calls (see
>> http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-policy-00.txt
>> for a more complete concept of how such peering arrangements would
>> be communicated.)
>>
>>
>> Partial Solution 1: TLS encryption of SIP can ensure that
>> originators are who they claim they are via root certification
>> process. However, this is still some time away and is operationally
>> complex. Most SIP operators are not currently very interested in
>> the overhead of this method, and getting root certificates is
>> considered administratively complex as it requires paperwork from
>> other portions of the organization in many cases.
>>
>> Partial Solution 2: Packet filtering, or IP-to-AS-to-domain
>> mapping tricks of some sort. This is obviously not scale-able for
>> all but the smallest membership groups, and is rife with problems of
>> identification of packets, speed of lookups, etc.
>>
>> Partial Solution 3: Password based authentication. This does not
>> scale with large groups, and requires a central administration of
>> passwords. Also, many (most?) proxies do not have the ability to
>> authenticate as if they were a User-Agent.
>>
>> Partial Solution 4: Central SIP proxy in a clearinghouse that
>> provides complex authentication and authorization before relaying to
>> remote sites. This is the most viable to date, because it does not
>> rely on any new technology as most SIP proxies are in turn able to
>> relay to other SIP proxies. However, this is useful for only small
>> group memberships, and requires prior cooperation between each end
>> node and the central SIP arbiter. Currently several firms are
>> trying to operate in this mode as a commercial venture, but no clear
>> or stable leader has been identified. Additionally, this implies
>> centralization and "single point of failure" problems.
>>
>> None of these methods are operationally simple, only some are
>> scale-able, or they require both end devices to implement some
>> protocol that may not be easily available.
>>
>> My proposed solution uses DNS to at least provide a rapidly
>> implemented and non-complex solution to the authentication of
>> domains of SIP calls, which IMHO is >50% of solving the SPIT problem
>> in a fairly trivial way. (The other part is solved by Otmar's draft
>> on federations/peering policy publication via the DNS.) The method
>> is very simple to deploy from an originating domain's perspective,
>> and is fairly simple to deploy from the receiving domain's
>> perspective.
>>
>>The proposition is as follows:
>>
>> When a SIP device (typically a proxy) receives an inbound call
>> request to a destination for which it is responsible, there are
>> presented three pieces of data:
>>
>> 1) The IP address of the host originating the request (10.1.2.3)
>> 2) The SIP domain of the call being presented (typically in the
>> From: address or in the P-Asserted-Identity field) (e.g.:
>> ""
>> means "bigu.edu" as the domain)
>> 3) The protocol of the inbound SIP INVITE (TCP or UDP) (udp in
>> this example)
>>
>>
>> The proxy then performs a lookup on the SRV records of the SIP
>> domain and protocol: _sip._udp.bigu.edu. A list of zero or more
>> hostnames is returned. For each hostname (if it is not an IP
>> address already) an A record search is then performed, and if
>> "10.1.2.3" is found in any of those results, it can be assumed that
>> the originating IP address of the request is allowed to generate
>> outbound INVITEs. This means that any site that correctly
>> implements SRV records will probably "just work" in this situation,
>> without any special configuration or even knowledge that the
>> receiving proxy is performing this authentication step.
>>
>> Yes, this looks similar to, but is not quite the same as, SPF.
>>
>> I understand the downsides to this, as it may make P2P SIP more
>> difficult, and relies on "smart" devices to currently parse these
>> records. It also makes difficult any IMS-type network that forces
>> foreign proxy use. However, some additional extension of this
>> method (i.e.: use of wildcards for IP address ranges) could probably
>> solve many of those issues, and the use of the DNS means that most
>> SIP proxies and devices, even end stations with minimal processors
>> and memory space, could implement this method without a new stack or
>> any serious rework of code. I am less concerned about other
>> operational environments that do not yet exist or are purely
>> hypothetical, as I am somewhat pragmatic about the way technologies
>> are used in IP networks (KISS wins.)
>>
>>
>>My problem for which I need advice:
>>
>> It may be the case that some sites have outbound proxies that are
>> not listed in the SIP SRV records that are published for inbound
>> use, and it may be undesirable to have all of these potential
>> outbound proxies that are "authorized" to transmit for the SIP
>> domain to have bogus SRV records simply for the sake of matching for
>> this permission model. This will be probably for only a very small
>> minority of sites, but a solution is required which would allow a
>> second step of lookups to happen if no match is found on the inbound
>> call domain in the "normal" SRV list. The concept of using very
>> high-weighted SRV records was considered, but this is ultimately
>> dangerous as it might be possible for inbound requests to end up in
>> the "wrong" place. Additonally, the number of hosts in the normal
>> SRV lookups should probably be as minimal as possible to prevent
>> conflict with the maximum DNS packet sizes. Lastly, the use of
>> wildcards (still not decided on this one...) would only be possible
>> in the TXT record format.
>>
>> To avoid those problems, I'd like to use the DNS-SD extensions
>> from http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt as
>> this second step, but I am unsure of my syntax. I think it should
>> look like the example below. Any of those lines would be valid, and
>> all of them could be responses at the same time. I re-used the
>> "outproxy" value both as a new service type as well as the
>> descriptor, since that's what seems to make the most
>> sense. Suggestions are welcome if there is some better or more clear
>> way to do it.
>>
>>_outproxy._sip._udp.bigu.edu. IN TXT "outproxy=outside1.bigu.edu"
>>_outproxy._sip._udp.bigu.edu IN TXT "outproxy=outside2.bigu.edu"
>>_outproxy._sip._udp.bigu.edu IN TXT "outproxy=10.33.12.4"
>>_outproxy._sip._udp.bigu.edu IN TXT "10.33.8.21"
>>_outproxy._sip._udp.bigu.edu IN TXT "proxy.sipaggregator.com"
>>
>>
>> I include a script below that works with records that look like
>> this, and that also will work with normal SRV records as a first
>> step. I've implemented this script in Asterisk as part of my
>> dialplan on inbound calls, and it works quite well. It would also
>> be fairly trivial to implement in SER.
>>
>> I'd like to get your comments on both the tactical use of the DNS
>> for this purpose, as well as the strategic issues that are a bit
>> larger if you have the time.
>>
>> PS: I see that draft-cheshire-dnsext-dns-sd-03.txt has expired; is
>> this being extended? I think it's quite a good idea.
>>
>>JT
>>
>>
>>
>># To demo this script, try:
>>#
>># An SRV lookup on _sip._udp.loligo.com that works:
>># ./checksrv -v loligo.com 204.91.156.10
>>#
>># A TXT lookup on _outproxy._sip._udp.loligo.com that works:
>># ./checksrv -v loligo.com 192.148.252.133
>>#
>># start
>>#
>>#!/bin/sh
>>
>>defaults="no"
>>
>>if [ $1 == "-v" ]; then
>> verbose="1"
>> name=$2
>> ip=$3
>> type=$4
>>else
>> verbose="0"
>> name=$1
>> ip=$2
>> type=$3
>>fi
>>
>>if [ "x$type" == "x" ]; then
>> type="_sip._udp"
>> defaults="yes"
>>fi
>>
>>dr=`dig +short SRV $type.$name | cut -d' ' -f4`
>>
>>if [ $verbose == "1" ]; then
>> echo "Found for $type.$name:"
>>fi
>>
>>for d in $dr ; do
>>
>> ar=`dig +short $d`
>>
>> if [ $verbose == "1" ]; then
>> echo "$d: "
>> fi
>> for a in $ar; do
>> if [ $verbose == "1" ]; then
>> echo " $a"
>> fi
>> if [ "x$a" == "x$ip" ]; then
>> match=$d
>> fi
>> done
>> done
>>
>>if [ $defaults == "yes" ]; then
>> type="_outproxy._sip._udp"
>>
>> dr=`dig +short TXT $type.$name | cut -d' ' -f4|tr -d \"|sed
>> 's/outproxy=//'`
>> if [ $verbose == "1" ]; then
>> echo "Found for $type.$name:"
>> fi
>>
>> for d in $dr ; do
>>
>> ar=`dig +short $d`
>> if [ $verbose == "1" ]; then
>> echo "$d: "
>> fi
>>
>> for a in $ar; do
>> if [ $verbose == "1" ]; then
>> echo " $a"
>> fi
>> if [ "x$a" == "x$ip" ]; then
>> match=$d
>> fi
>> done done
>>fi
>>
>>
>>
>>if [ $verbose == "1" ]; then
>> echo "Match: $match"
>>else
>>
>># If you are running Asterisk and want to use this script as an AGI,
>># just comment out the first "echo" line below and uncomment the
>># Asterisk AGI "SET VARIABLE" line to replace it.
>>#
>> echo $match
>># echo "SET VARIABLE SRVMATCH $match"
>>fi
>>
>># end
>
>
--
Ben Teitelbaum http://people.internet2.edu/~ben/
- Re: [sip.edu] Call Tomorrow - 7/20, (continued)
- Re: [sip.edu] Call Tomorrow - 7/20, Candace Holman, 07/19/2006
- Re: [sip.edu] Call Tomorrow - 7/20, Jeremy George, 07/19/2006
- Re: [sip.edu] Call Tomorrow - 7/20, Candace Holman, 07/20/2006
- Re: [sip.edu] Call Tomorrow - 7/20, Jeremy George, 07/20/2006
- Re: [sip.edu] Call Tomorrow - 7/20, Duane, 07/20/2006
- Re: [sip.edu] Call Tomorrow - 7/20, Jeremy George, 07/20/2006
- Re: [sip.edu] Call Tomorrow - 7/20, Duane, 07/20/2006
- Re: [sip.edu] Call Tomorrow - 7/20, Christian Schlatter, 07/20/2006
- Re: [sip.edu] Call Tomorrow - 7/20, Duane, 07/20/2006
- Re: [sip.edu] Call Tomorrow - 7/20, Candace Holman, 07/19/2006
- Re: [sip.edu] Call Tomorrow - 7/20, Duane, 07/19/2006
- Re: [sip.edu] Call Tomorrow - 7/20 (SPIT Prevention), Duane, 07/19/2006
Archive powered by MHonArc 2.6.16.