Subject: [Rucus] Comparison of disposable SIP URI and IPsec solutions to SPIT

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 19 Mar 2008 15:20:56 +0200

Hello,

Below is a comparison of disposable SIP URI and IPsec solutions to SPIT.
Comments are welcome.

1. Disposable SIP URIs

A SIP user can have many SIP URIs, called "disposable" SIP URIs.
Similarly to standard SIP URIs, disposable SIP URIs can be distributed
upon face-to-face contact through oral communication, by giving it
on a piece of paper or business card, etc. The owner of the disposable
SIP URIs can distribute a different SIP URI to each person (s)he has a
contact. If one of the SIP URIs receives SPIT, it can be disabled,
i.e. disposed of by its owner. Other SIP URIs, being different, would
not be affected. Consequently, the communication channels with legitimate
correspondents would be preserved.

The difficulty of this solution may lie in the generation and removal
of the disposable SIP URIs. The SIP URIs must be known to the SIP
architecture. One needs to locally generate disposable SIP URIs, check
for duplicates and register them to the system. Similarly when a SIP
URI receives SPIT, it should be removed from the system. The number of
SIP URIs per user may be large, consequently their generation and
removal may represent an important overhead depending on the disposable
SIP URI distribution and SPIT frequency.

Alternatively, a disposable SIP URI can be distributed along with a
Mobile IP address (for cell phones) possibly in a vCARD structure.
In this scheme, the SIP architecture i.e. SIP triangle or trapezoid
is not needed. The entity who received a disposable SIP URI already
has the target IP address. Calls can be routed to the destination host
without SIP infrastructure. The advantage of this scheme is that
disposable SIP URIs can be locally generated and disabled by the
host without informing the system.

2. IPsec

The above scheme is not secure. Disposable SIP URIs travel in the
network in clear-text and can be collected by an attacker who
installed sniffers to strategical points in the network. An entity
who were given a disposable SIP URI can easily be impersonated. An
attacker can send SPIT from a spoofed disposable SIP URI collected
from network. The attacker may have commercial purposes for sending
SPIT or may want to break existing trust relationships. In either
case, the target user would disable the impersonated SIP URI, tearing
down the communication channel with the real owner of the SIP URI.

The solution to this problem is to encrypt the SIP URIs using IPsec.
The SIP URIs would never be exchanged in clear-text, protecting them
from eavesdroppers.

As described above, disposable SIP URIs are distributed upon user
contact, i.e. face-to-face meeting. IPsec security assocations can also
be easily established upon user contact [SAS]. When an IPsec Security
Association (SA) is available between two users, disposable SIP URIs
are not needed. One can establish a different SA with each correspondent
and upon receipt of SPIT from one SA, disable that SA. IPsec SAs
act as disposable communication channels.

The limitations of using IPsec, however, are: they are hard to establish
without user contact. For example, one cannot establish an SA through
e-mail, but can send a disposable SIP URI via e-mail. When filling a
web form one can comfortably reveal a disposable SIP URIs. IPsec, however,
does not address this problem.

[SAS]      Vaudenay, S., "Secure Communications over Insecure
           Channels Based on Short Authenticated Strings", Advances
           in Cryptology, CRYPTO 2005.
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Mar 2008 14:30:45 -0400

For what it's worth, many email systems (apparently, including gmail)  
allow email addresses of the form

[email-masked]

and they are all automatically delivered to user 'foo'. Along with  
others, I use this in Internet drafts to see if putting email  
addresses in I-Ds generates spam. This seems to occur, but  
surprisingly rarely, indicating either that spam address harvesters  
don't go through plain text files or that address harvesting is not as  
common as usually believed.

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 19 Mar 2008 21:53:50 +0200

Hello,

>  common as usually believed.

I kept my gmail address secret during several months (except
for IETF ML conversations) and did not receive spam. Recently
I decided to published it on a web page. The day after I received
spam. Now I receive spam everyday. :-/

Maybe spammers don't harvest e-mail addresses from documents.
They prefer html pages perhaps.

Another related question: Would spammers harvest e-mail addresses
from the network if e-mail sessions were not secured? This would
have implications on SIP URIs. In theory, this is a much easier way
of harvesting addresses. On a public wireless network one can install
a sniffer and eavesdrop many different (because mobile) user's SIP
traffic.

pars

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Mar 2008 16:43:55 -0400

This requires physical presence and significant hardware investment. I  
have a hard time imagining spammers visiting hundreds of Starbucks,  
install multi-hundred-dollar sniffers in ways that don't raise  
suspicion immediately (where would they plug them in, say, given that  
Starbucks and other cafes make a point of having as few outlets as  
possible to increase table turnover), and then gather a few dozen  
addresses each day. In the US, they'd probably draw bomb squads within  
a few minutes. Not that I would mind sending a few spammers to  
Guantanamo.

To be honest, this is wayyy down my list of worries.

This isn't a problem for email since any sane person uses IMAP and  
SMTP over TLS, primarily to protect their passwords. SIP terminals  
will do the same thing eventually.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Mar 2008 22:59:38 +0200

To Pars: To me it seems doing things at lower layers is not really a 
good idea (if the semantic is at the higher layer). Hence, I don't see 
how this provides any help.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Mar 2008 23:05:17 +0200

To Pars: I agree with Henning that you seem to have a bit outdated 
adversary model in mind given that we had previous discussions about 
Botnets (with the ability to steal your credentials) on this list.

---

From: "Pars Mutaf" <[email-masked]>
Date: Wed, 19 Mar 2008 23:27:47 +0200

Hello,
I would imagine the owner of a shop constantly sniffing SIP URIs
and send advertisement to invite nearby users, for example.
Is there a plan for publishing a hypothetical threat model document
like security folks do?

thanks
pars

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Mar 2008 16:41:29 -0700

In a message, Henning wrote:
> For what it's worth, many email systems (apparently, 
> including gmail) allow email addresses of the form
> 
> [email-masked]
> 
> and they are all automatically delivered to user 'foo'.

Right; this means the user need not pre-configure their
mail system to understand "bar".  

Additionally, instead of just disabling foo+bar, you could
adjust the handling of SIP requests to foo+bar to only allow
those from a whitelist, or to challange them with a captcha,
etc.

In a separate message, Pars wrote:
... 
> They prefer html pages perhaps.

The HTML page http://tools.ietf.org/html/rfc5069.html contains one 
of Henning's "+" addresses.

In a separate message, Pars wrote:
> I would imagine the owner of a shop constantly sniffing SIP 
> URIs and send advertisement to invite nearby users, for 
> example.  Is there a plan for publishing a hypothetical threat 
> model document like security folks do?

That seems reasonable.  Of course, protecting your SIP 
signaling with (D)TLS would protect from such eavesdropping.

-d

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Mar 2008 10:33:49 +0200

I wonder how a shop owner can do that given the available SIP security 
mechanisms. The shop owner (let's assume a WLAN hotspot) would not be 
able to see anything other than TLS protected traffic.

Nobody so far wanted to write a threats document. I am also not sure 
whether the threats aren't already sufficiently documented in the 
various SIP specifications already

Ciao
Hannes

---

From: "Pars Mutaf" <[email-masked]>
Date: Thu, 20 Mar 2008 10:59:53 +0200

>  able to see anything other than TLS protected traffic.

That's right. SIP URIs MUST be protected from eavesdroppers.

>  various SIP specifications already

OK

Thanks,
pars

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 20 Mar 2008 10:12:37 +0100

> various SIP specifications already

I agree, the threats to SIP security are sufficently documented already.

What's IMHO missing is a discussion on what properties of SIP
deployments are critical for a SPIT threat to materialize.

e.g. if two large telcos switch their peering link from TDM/SS7 to SIP
via a private IP connection between their session border elements, then
I don't see how this affects the SPIT threat assessment.

Or, if a PBX uses SIP inside an office to talk to the phones, but
ISDN to the outside world, I don't see a realistic SPIT threat.

In other words, SIP per se isn't the problem. It's how you deploy it
and what connections you allow. 

/ol
-- 
-=-  Otmar Lendl  --  [email-masked]  -=-
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: "Pars Mutaf" <[email-masked]>
Date: Thu, 20 Mar 2008 12:03:43 +0200

Hello,

>  signaling with (D)TLS would protect from such eavesdropping.

I am curious, why one would use Datagram TLS and not IPsec.

thanks,

pars

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Mar 2008 09:25:15 -0700

> I am curious, why one would use Datagram TLS and not IPsec.

TLS is specified in RFC3261, and DTLS is specified in an individual
draft (draft-jennings-sip-dtls-05.txt).  RFC3261 explicitly says
that IPsec isn't described in RFC3261 (see end of page 238).  And,
due to IPsec's lack of an API to verify that traffic is protected
with IPsec, an application (such as SIP) cannot verify that its
communications are IPsec protected.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Mar 2008 11:25:18 -0700

> and what connections you allow. 

Both of the above example scenarios involve connections to the PSTN.

If you are originating or terminating calls to/from the PSTN, there
is no SPam over Internet Telephony with those calls.  It is, instead,
just "plain old" PSTN spam.

I agree we don't care much about that; we cannot do anything to 
reduce such traffic to/from the PSTN.

-d

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Mar 2008 13:54:02 -0500

Dan Wing wrote:
> And, due to IPsec's lack of an API to verify that traffic is
> protected with IPsec, an application (such as SIP) cannot verify that
> its communications are IPsec protected.

There is some work going on in btns WG on the creation of such
an API.

An abstract API (interface) is defined in:
   http://tools.ietf.org/html/draft-ietf-btns-abstract-api-01
and a C binding is defined in:
   http://tools.ietf.org/html/draft-ietf-btns-c-api-03

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 21 Mar 2008 11:58:54 +0100

> reduce such traffic to/from the PSTN.

Let me expand a bit on that thought:

Imagine for a moment that the NGN efforts take off and all SS7
interconnections between PSTN operators are magically converted to SIP
trunks. On one hand, this is still the PSTN, as the interconnection
structure, pricing, adminssion control, regulation, ... stays the same.
On the other hand, this is now a SIP based network.

Is SPIT in this (hypothetical) scenario still "plain old" PSTN spam,
and as such out of scope for RUCUS?

(IMHO: yes)

Is the crucial distinction here "voice over IP" versus "voice over the
Internet" which brings RUCUS into play?

In other words, only if you

 * accept calls from other entities without prior signed agreements
or
 * have "free providers" which accept anonymous signups via the web
   (the hotmai/yahoo/gmail equivalents for VoIP)

then you may run into a spit problem which is similar to the SPAM
problem.

I'm still not sure whether we're all on the same page with regards
to which scenario we will actually consider.

/ol

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Mar 2008 13:44:11 +0200

Ah. The widely implemented BTNS work....

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 21 Mar 2008 08:23:41 -0500

> Ah. The widely implemented BTNS work....

Yes, I agree.  Deployment is a long way off.  But I thought it
was interesting to see any work in this area at all (unless I am
missing something germane; I do not have the same background
context on this work as you may have.  As such, I am evaluating
it based on solely the existence of the draft...)

- vijay

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 21 Mar 2008 09:02:12 -0700

... 
> then you may run into a spit problem which is similar to the SPAM

Today, even with signed agreements, you can still receive email
spam.  For example, I could have an agreement with a cable provider
to not send me spam.  But, sometimes, due to no fault of their own,
some cable subscriber would decide it is Really Important to "get
the word out" about some environmental cause (for example).  The 
subscriber might try to send 1,000,000 of their spams and only be
detected as a spammer around 1,000 or 10,000.  So 1,000 or 10,000
unlucky people will receive spams.  

One might imagine a trojan horse, or other software, could 
learn the user's SIP login credentials and use those credentials
to send spam, unbeknownst to the user.

As for free providers, yes, they could be a hotbed for SPIT, much
as they are a hotbed for today's email spam.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Mar 2008 12:57:35 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Pars Mutaf
> Sent: Thursday, March 20, 2008 5:00 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Rucus] Comparison of disposable SIP URI and IPsec solutions
> to SPIT
>

For SPIT protection? Why?  "Harvesting" is not necessary for common SIP URI usage, because it's commonly based on phone numbers.  One does not need to harvest phone numbers by sniffing anything, or looking through documents, or web mining.  You can buy a white-pages database with all of them ahead of time, or you can simply auto-dial - it's a constrained number space.  And even for alphabetic usernames, the ship has sailed, because they're often the same as the email address.

-hadriel

---

From: "Pars Mutaf" <[email-masked]>
Date: Fri, 21 Mar 2008 19:20:10 +0200

On Fri, Mar 21, 2008 at 6:57 PM, Hadriel Kaplan <[email-masked]> wrote:
>  For SPIT protection? Why?  "Harvesting" is not necessary for common SIP URI usage, because it's commonly based on phone
> numbers.  One does not need to harvest phone numbers by sniffing anything, or looking through documents, or web mining.  You can
> buy a white-pages database with all of them ahead of time, or you can simply auto-dial - it's a constrained number space.  And even for
> alphabetic usernames, the ship has sailed, because they're often the same as the email address.

In the initial text that I sended, I reviewed the disposable SIP URIs.
This defense is weakened if it is vulnerable to eavesdroppers.
Moreover, if all other doors are closed, SPAMmers may attack
in that way i.e. by eavesdropping on SIP traffic. In another hypothetical
attack (that makes a lot of sense to me), the owner of a shop
may install a snifer and automatically send advertisements to
nearby mobile phone users' sniffed SIP URIs. Note that my IETF
experience is limited to Internet Area, where this kind of models
are not considered marginal (Wi-FI, WiMax, Mobile IPv6 etc).

Excuse my ignorance. The SIP URIs never appear in clear-text
when protected with TLS? What about end2 messages e.g F12?

Again sorry I missed  something obvious.

pars

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Mar 2008 14:22:16 -0400

> From: Pars Mutaf [mailto:[email-masked]]
>
> in that way i.e. by eavesdropping on SIP traffic.

Right, but my point is traditional "SPAMmers" would not bother to do so, because they wouldn't need to - they already know or can easily guess the SIP AoR's to use.  A "local SPAMer" maybe, but that's like a drop in the bucket compared to general SPAM.

> In another hypothetical

Well, it should be considered marginal, imho.  The impact of eavesdropping is far more severe for things other than SPAM.  SPAM would be one of the more benign issues for that case, frankly.  A shop owner has no incentive to do this, because the customer backlash would be severe.  Another eavesdropper on the same broadcast domain may have such incentive, but that's why protection mechanisms are available to prevent eavesdropping.

> when protected with TLS? What about end2 messages e.g F12?

It depends on some registration behavior, but no normally the SIP URI's would not appear in cleartext on the local broadcast domain if TLS is used.  (whether it actually is used is another matter, but it's available)
I don't know what "F12" is.

-hadriel

---

From: "Pars Mutaf" <[email-masked]>
Date: Fri, 21 Mar 2008 20:40:47 +0200

On Fri, Mar 21, 2008 at 8:22 PM, Hadriel Kaplan <[email-masked]> wrote:
>  Well, it should be considered marginal, imho.  The impact of eavesdropping is far more severe for things other than SPAM.  SPAM
> would be one of the more benign issues for that case, frankly.  A shop owner has no incentive to do this, because the customer backlash > would be severe.

:-) I hope you are right.

>Another eavesdropper on the same broadcast domain may have such
incentive, but that's why protection mechanisms are available to
>prevent eavesdropping.

F12 is the end2end ACK message in the Figure 1 of Session Initiation
Protocol document (rfc3261). I couln't figure out if there is a risk.

Thanks,
pars

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 21 Mar 2008 21:14:29 +0100

> unlucky people will receive spams.  

Correct, but is this in any way different to what can happen on the old
fashioned PSTN? If the provider limits the number of concurrent
calls a single subscriber can make, what difference does it make that
this is a SIP-based provider and not a POTS-based one?

In other words, is this really a new threat?

> to send spam, unbeknownst to the user.

Yes, that is something new. A softphone on a PC, or even a hardphone
using SIP is more vulnerable than a good old steam-powered POTS phone.

> as they are a hotbed for today's email spam.

Good, we found a good scenario against which to judge anti-SPIT proposals.

/ol

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Mar 2008 16:29:04 -0400

Is this statement based on data or hearsay? From what I can tell, spam  
actually originating from Yahoo, Google or Hotmail is exceedingly rare  
(as opposed to spam claiming to come from these organizations).

---

From: John Levine <[email-masked]>
Date: 21 Mar 2008 21:22:08 -0000

>(as opposed to spam claiming to come from these organizations).

They tend to have outbreaks of spam when someone either breaks their
signup CAPTCHA, uses a mechanical Turk to sign up a lot of accounts,
or finds some other chink in their armor.

For example, Yahoo currently has an outbound spam problem that appears
to be due to a bug that lets free accounts use the outbound SMTP
servers intended for their paid accounts.

obSPIT: The main thing that keeps webmail systems from being a
constant spam problem is that they rate limit outgoing mail.  I would
expect rate limits to be fairly effective against SPIT since it is a
rare individual who really needs to talk (for free) to more than one
person at a time.

R's,
John

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Mar 2008 17:40:42 -0400

> John Levine

Indeed, such call rate limiting already occurs in lots of SIP provider deployments, including throttles per subscriber/IAD/phone and dynamic blacklisting and more - the concern (for me) isn't those, the concern is inbound throttling on the inter-provider peering side, which is also very common today.  The problem with that is if large volume of SPIT gets into the peers through whatever means, it either fills up the inbound throttles and thus denies legitimate traffic, or stays below the throttles but for which identification of the traffic as SPIT is exceedingly difficult.

Identification is far harder than email, because there is a lot less info to go on for detecting it in the message.  For example I don't see a single anti-spam technique on your wiki that would work for SIP today or in the foreseeable future.  Well, a few would work but I strongly doubt would be acceptable to users or providers.

-hadriel

---

From: John R Levine <[email-masked]>
Date: Fri, 21 Mar 2008 18:07:06 -0400 (EDT)

> Identification is far harder than email, because there is a lot less 
> info to go on for detecting it in the message.  For example I don't see 
> a single anti-spam technique on your wiki that would work for SIP today or 
> in the foreseeable future.  Well, a few would work but I strongly doubt 
> would be acceptable to users or providers.

Most of them don't work so great for spam either.  I think there's a few 
that are applicable.  DNSBLs listing IP ranges that should never be trying 
to connect directly work quite well for spam and would probably work well 
for SIP, too.  ISPs now typically require that their customers use SMTP 
AUTH to send mail via a fixed relay, and I expect we'll have similar rules 
for SIP.

On the other hand, challenge/response is awful for mail but widely used 
for voice calls today.  ("For service in English, dial 39474.  Para 
servicio en espanol, marque el 04958.  Pour service en francais, faites le 
67589 ...")

Given that most SIP systems, unlike mail systems, default to rejecting 
unknown calls, I suspect that the most useful technique will be shared 
whitelists of IPs or domains that are known to behave themselves.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Mar 2008 15:28:32 -0400

> From: John R Levine [mailto:[email-masked]]
>
> for SIP, too.

I don't see how?  I mean that's already the case in a way - many providers (if not most) do not just allow any IP to connect directly.  At least in my market, but there are many SIP-use markets.

> servicio en espanol, marque el 04958.  Pour service en francais, faites le

That's only acceptable for certain call types, mostly ones to systems (IVR's, Voicemail, etc.).  Some of those call types happen to be not very attractive for spammers to begin with.  Although for voicemail it would be good, to prevent Voice-Mail SPIT (VoMIT? :)

But most people simply won't accept having to wait and pass a turing test to reach someone direct, and the people being "protected" won't like it either.  They'll just switch back to the PSTN.  There's also a problem for such tests with billing, since billing frequently starts on 200 ok or bi-directional media.

> whitelists of IPs or domains that are known to behave themselves.

Only certain SIP systems default that way - many don't, fwiw.
But yes, a federation model I think will work, because that is the PSTN model essentially - but for PSTN it's under regulatory control which keeps the federation membership fairly closed, and it costs money and physical access to the federation.  The problem (and advantage) of SIP is it has no such control or physical barriers in place - it has federations and closed peering, but my worry is the chain of trust in such a model could someday be broken by domains joining the federations that don't configure correctly or have as tight a control.

-hadriel

---

From: John Levine <[email-masked]>
Date: 22 Mar 2008 20:41:32 -0000

In case it's not obvious, I'm not suggesting there's a magic bullet
for spit any more than there is for spam.  Different setups will use
different combinations of techniques.

>I don't see how?  I mean that's already the case in a way - many
>providers (if not most) do not just allow any IP to connect directly. 
>At least in my market, but there are many SIP-use markets.

Again, it's part of a toolkit.  If you know you can safely ignore
attempts from vast swaths of IP space, you can afford to work harder
checking the attempts from what's left.  This is quite common and
effective in spam filtering.

>> for voice calls today. ...
>That's only acceptable for certain call types, mostly ones to systems
>(IVR's, Voicemail, etc.).

 ... and most large organizations.  When's the last time you called an
800 number and a person answered?  Again, useful some places, less
useful other places.  It also might be useful as part of a more
complex system, e.g., whitelist callers who pass the challenge a
couple of times.

>Only certain SIP systems default that way - many don't, fwiw.

(Huh?  Three paragraphs back you said "many providers (if not most) do
not just allow any IP to connect directly.")

> my worry is the chain of trust in such a model could someday be
>broken by domains joining the federations that don't configure
>correctly or have as tight a control.

Well, here's a time saver from the anti-spam world.  You can be 100%
sure than any sort of web-of-trust that depends on members
self-certifying or FOAF certifying won't work, because any such group
that's large enough to be interesting will be large enough to attract
lying sleazeballs, and one or two sloppy members letting people in
will ruin the whole thing.  BTDT.

A model that works better is organizations that publish certification
lists of senders (or callers) who've paid to be certified.  Despite
the rants from certain quarters that it's just pay to spam, my
experience with them has been pretty good.  The certifiers have an
incentive to keep their lists clean so that receivers will continue to
use them, and the senders pay because it's cheaper to pay once to be
certified than to negotiate separately with all of a list's users that
they might want to contact.

Another similar approach is organizations or regulators publishing
certification lists of their members.  For example, if the FDIC
published a list of its member banks' domains, a lot of people would
figure that if it's a call from a real bank, it's worth accepting.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Mar 2008 22:24:07 -0400

> From: John Levine [mailto:[email-masked]]
>

Nope, I wasn't thinking you did. :)

> not just allow any IP to connect directly.")

You said "systems" here, whereas in the earlier section (not in this email) I was talking about providers (who have many systems).  Also in the earlier section you were talking about IP Addresses, whereas in this section it's "unknown calls".  Providers have SIP systems that do block based on source IP, and systems that reject relayed requests if the domain isn't known, but most SIP systems don't, afaik.  It was a minor nit comment, anyway.

> will ruin the whole thing.  BTDT.

Yup, that's my concern.

-hadriel