SIP in higher education

[Ben Teitelbaum <>]

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/