SIP in higher education

[(Dennis Baron)]

SIP.edu Conference Call July 20, 2006

*Attendees*

Dennis Baron, MIT
Jeremy George, Yale
Duane Groth, E164.org
Candace Holman, Harvard
Toby Murray, Kansas State
Dave Roeper, Independent Consultant
Christian Schlatter, UNC Chapel Hill
John Todd, Tello
Garret Yoshimi, Hawaii
Kurt Zogelman, Kansas State

*Discussion*

Today's call begins with Dennis talking about recent changes in the
SIP.edu calls. Many calls have been geared towards information
sharing, and Dennis would like to explore new areas or issues in a
more hands-on way. Candace suggested exploring the issue of VOIP Spam
(also known as SPIT), and suggests looking for possible future
solutions in a more proactive manner. Candace has compiled a list of
possible SPIT solutions which arose in email discussion.

Consensus among the group is that VOIP Spam is not currently a major
issue, but it could become one as internet telephony becomes more
popular. It would be preferable to work towards a solution before it
becomes as large a problem as email Spam. John Todd asks if anyone has
received unsolicited VOIP Spam; he has, but his SIP URI has been
published as an example in documentation. Dennis has also received
calls, and his URI has also been widely published.

Dave Roeper suggests using dynamically generated, limited use SIP URIs
that are only valid for a limited period of time or particular number
of calls. Others on the call believe that this would be difficult to
administer, or would require sophisticated phones for differentiation
of calls. Ben believes this idea runs counter to the idea of having
only one contact address.

Candace sends a list of possible Spam solutions to the email list, and
discussion shifts to the implementation of whitelists and blacklists,
the first item on the list. Ben uses both whitelists and blacklists to
filter calls and to provide forwarding control.

The next item on the list is the concept of a reputation system, which
would require some way for providers to verify and authenticate groups
of users. The actual implementation of such a system would be more
difficult, but it might be more of a policy that would work in
conjunction with a white or blacklist than an actual
implementation. Problems could arise with overzealous blacklisting, as
has happened with some email Spam blacklists. It can be too easy for
an organization to get onto a blacklist and too difficult to be
removed.  There would need to be a way for users to report Spam calls
to their own provider, who would then be able to pressure the
organization to crack down on errant users. This would also
effectively disable organizations such as Free World Dialup, where
anyone can sign up with just an email address and no further
authentication.

Candace shifts the conversation to Duane and John's ideas for
preventing address forgery, which would lead to a reduction of
Spam. Duane talks about a system which would register and authenticate
existing addresses, which would allow some sort of reputation system
to work. Duane and John also discuss authenticating by server or
client, using such methods as TLS.

Dennis asks if the SPIT problem would be lessened by simply knowing
that a call comes from the domain that it claims to come from. Duane
feels that if this could be accomplished, it would allow a specific
domain to know what device at the organization was used to make the
call. John feels that a first step is being able to authenticate down
to the domain level, using something like TLS or the Sender Policy
Framework which uses DNS SRV records. This would not discourage all
Spam, but would discourage it to a large degree. It would also be the
easiest to accomplish.

John has developed a method for authenticating by domain. When a SIP
proxy receives an INVITE from an IP address, it would look up the
domain listed in the From address and gather all possible SRV
records. It would then look up all the A records from these SRV
records and determine if the IP address is in this list. This is a
simplistic way to determine the validity of an IP address. The
downside is that often inbound and outbound proxies are not the
same. John suggests using an RFC draft to list additional outbound
proxies in TXT records.

Candace asks about the difference between using SPF TXT and DNS SRV
records. The SPF records can be told to use MX or A records in
addition to other criteria. John's method uses SRV records first,
which means that any site that uses them is automatically qualified
without modifying their DNS. The downside is that this requires some
sort of reputation system in order to process call after the
verification of the address.

Dennis clarifies that unlike the SIP Identity draft, the originating
school's outbound proxy does not have to do anything to the
message. Candace says that with SIP Identity headers are
cryptographically secure and therefore much harder to forge, but
it requires PKI and is harder to implement.

John asks if anyone is using TLS for external traffic. Dennis says
that MIT uses it between clients and the outbound proxy, but not for
external traffic.

Christian asks if it worth the time to work on an intermediate
solution using DNS and SPF. He would like to have call signaling
encrypted anyway, and in the future imagines using TLS for this. He
wonders if it worth working on an DNS based solution in the
meantime. John and Candace don't see them as being mutually exclusive.

Dennis feels that even if the DNS method is not perfect, it is a piece
of the solution that can be done now. Duane says that it only
addresses the problem of address forgery, and spammers can still
register domains and have valid SPF records. John feels that it also
allows easy creation of whitelists, but needs a centralized reputation
system to work effectively. A first step, for example, would be to
trust all .edu suffixes, as all SIP.edu members have them. [Oops, well
again we let our US-centricity show! - Dennis] Duane likes the idea of
a centralized whitelist, with providers entering into an agreement
about the behavior of their users.

Candace asks if SIP.edu should try to generate a system like this,
perhaps with ideas for setting up whitelists and blacklists. Duane
thinks that you need to have both a whitelist and blacklist system in
conjunction with domain verification like SPF. Candace feels that they
can be separate issues, and Dennis agrees. She sees it as a first
step, and a blacklist would be easier to set up for organizations with
limited resources.

Duane says that the published SRV records are available, and should be
used. Candace asks about an implementation, and John mentions a shell
script that he has written to do this, which should work with both SER
and Asterisk. One other thing he has considered is an encouragement
method of some sort. A call without a valid SRV record is presented
with a recording prompting users to talk to their administrator about
proper SRV records. This would be easily implemented and would not
affect existing methods for making or receiving calls.

John's shell script requires two pieces of data as inputs - the IP
address of the SIP INVITE from the UDP header. It looks up this address
and retrieves all SRV records, then looks up the A records. If the IP
address is listed, it considers it a valid call. If not, it performs an
additional lookup for TXT records and tries to find a possible outbound
proxy address that is not part of the SRV record. If there is no match
after both lookups, it returns a null string. Otherwise, it returns a
match. It takes no action, and depends on your dial plan to deal with
the call accordingly.

Dennis says that MIT has multiple proxies, so they would have to add
additional DNS records, but thinks that this would be helpful. Candace
says that this is not, however, a solution to any peer-to-peer
Spam. Duane feels that the peer's provider needs to do something,
which is again where the reputation system comes into play. John asks
how Skype, which is the model for peer-to-peer traffic, prevents
Spam. Skype is not fully peer-to-peer, as it has a central
authentication system.

Dennis asks if there needs to be another email list for this
topic. Participants believe that this is unnecessary.

Finally, Candace reminds participants that methods of Spam prevention
not discussed on this call are welcome topics for further calls.

The next call will be on July 27th.