draft-ietf-sipping-spam-00.txt   draft-ietf-sipping-spam-01.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft C. Jennings Internet-Draft C. Jennings
Expires: August 14, 2005 Cisco Expires: January 18, 2006 Cisco
J. Peterson J. Peterson
Neustar Neustar
February 13, 2005 July 17, 2005
The Session Initiation Protocol (SIP) and Spam The Session Initiation Protocol (SIP) and Spam
draft-ietf-sipping-spam-00 draft-ietf-sipping-spam-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 14, 2005. This Internet-Draft will expire on January 18, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
Spam, defined as the transmission of bulk unsolicited messages, has Spam, defined as the transmission of bulk unsolicited messages, has
plagued Internet email. Unfortunately, spam is not limited to email. plagued Internet email. Unfortunately, spam is not limited to email.
It can affect any system that enables user to user communications. It can affect any system that enables user to user communications.
skipping to change at page 5, line 26 skipping to change at page 5, line 26
typical broadband Internet connection that provides 500Kbps of typical broadband Internet connection that provides 500Kbps of
upstream bandwidth. Initiating a call requires just a single INVITE upstream bandwidth. Initiating a call requires just a single INVITE
message. Assuming, for simplicity's sake, that this is 1kB, a message. Assuming, for simplicity's sake, that this is 1kB, a
500Kbps upstream DSL or cable modem connection will allow about 62 500Kbps upstream DSL or cable modem connection will allow about 62
call attempts per second. A successful call requires enough call attempts per second. A successful call requires enough
bandwidth to transmit a message to the receiver. Assuming a low bandwidth to transmit a message to the receiver. Assuming a low
compression codec (say, G.723.1 at 5.6 Kbps), as many as 90 compression codec (say, G.723.1 at 5.6 Kbps), as many as 90
simultaneous calls can be in progress. With 10s of content per call, simultaneous calls can be in progress. With 10s of content per call,
that allows for 9 successful call attempts per second. This means that allows for 9 successful call attempts per second. This means
that a system could deliver a voice message successfully to users at that a system could deliver a voice message successfully to users at
a rate of around 9 per second. If broadband access is around a rate of around 9 per second. If broadband access is around $50/
$50/month, the cost per successful voice spam is about 215 microcents month, the cost per successful voice spam is about 215 microcents
each. This assumes that calls can be made 24 hours a day, which may each. This assumes that calls can be made 24 hours a day, which may
or may not be the case. or may not be the case.
These figures indicate that SIP call spam is roughly three orders of These figures indicate that SIP call spam is roughly three orders of
magntiude cheaper to send than traditional circuit-based telemarketer magntiude cheaper to send than traditional circuit-based telemarketer
calls. This low cost is certainly going to be very attractive to calls. This low cost is certainly going to be very attractive to
spammers. Indeed, many spammers utilize computational and bandwidth spammers. Indeed, many spammers utilize computational and bandwidth
resources provided by others, by infecting their machines with resources provided by others, by infecting their machines with
viruses that turn them into "zombies" that can be used to generate viruses that turn them into "zombies" that can be used to generate
spam. This can reduce the cost of call spam to nearly zero. spam. This can reduce the cost of call spam to nearly zero.
skipping to change at page 8, line 41 skipping to change at page 8, line 41
the content will be in the form of recorded audio or video. Speech the content will be in the form of recorded audio or video. Speech
and video recognition technology is not likely to be good enough to and video recognition technology is not likely to be good enough to
analyze the content and determine whether or not it is spam. Indeed, analyze the content and determine whether or not it is spam. Indeed,
if a system tried to perform speech recognition on a recording in if a system tried to perform speech recognition on a recording in
order to perform such an analysis, it would be easy for the spammers order to perform such an analysis, it would be easy for the spammers
to make calls with background noises, poor grammar and varied to make calls with background noises, poor grammar and varied
accents, all of which will throw off recognition systems. Video accents, all of which will throw off recognition systems. Video
recognition is even harder to do and remains primarily an area of recognition is even harder to do and remains primarily an area of
research. research.
Therefore, our conclusion is that the most successful form of Therefore, our conclusion is that the most successful form of anti-
anti-spam measures used in email are almost useless for call spam. spam measures used in email are almost useless for call spam.
IM spam, due to its similarity to email, can be countered with IM spam, due to its similarity to email, can be countered with
content analysis tools. Indeed, the same tools and techniques used content analysis tools. Indeed, the same tools and techniques used
for email will directly work for IM spam. for email will directly work for IM spam.
3.2 Black Lists 3.2 Black Lists
Black listing is an approach whereby the spam filter maintains a list Black listing is an approach whereby the spam filter maintains a list
of addresses that identify spammers. These addresses include both of addresses that identify spammers. These addresses include both
usernames (spammer@domain.com) and entire domains (spammers.com). usernames (spammer@domain.com) and entire domains (spammers.com).
skipping to change at page 18, line 37 skipping to change at page 18, line 37
is, domain B can know that messages are received from domain A. In is, domain B can know that messages are received from domain A. In
SIP, this is readily provided by usage of the mutually authenticated SIP, this is readily provided by usage of the mutually authenticated
TLS between providers. Email does not have this kind of secure TLS between providers. Email does not have this kind of secure
domain identification, although new techniques are being investigated domain identification, although new techniques are being investigated
to add it using reverse DNS checks (see below). to add it using reverse DNS checks (see below).
This kind of technique works well for small domains or small sets of This kind of technique works well for small domains or small sets of
providers, where these policies can be easily enforced. However, it providers, where these policies can be easily enforced. However, it
is unclear how well it scales up. Could a very large domain truly is unclear how well it scales up. Could a very large domain truly
prevent its users from spamming? Would a very large enterprise just prevent its users from spamming? Would a very large enterprise just
pay the fine? How would the pricing be structured to allow both small pay the fine? How would the pricing be structured to allow both
and large domains alike to participate? small and large domains alike to participate?
3.13 Centralized SIP Providers 3.13 Centralized SIP Providers
In this technique, a small number of providers get established as In this technique, a small number of providers get established as
"inter-domain SIP providers". These providers act as a "inter-domain SIP providers". These providers act as a SIP-
SIP-equivalent to the interexchange carriers in the PSTN. Every equivalent to the interexchange carriers in the PSTN. Every
enterprise, consumer SIP provider or other SIP network (call these enterprise, consumer SIP provider or other SIP network (call these
the local SIP providers) connects to one of these inter-domain the local SIP providers) connects to one of these inter-domain
providers. The local SIP providers only accept SIP messages from providers. The local SIP providers only accept SIP messages from
their chosen inter-domain provider. The inter-domain provider their chosen inter-domain provider. The inter-domain provider
charges the local provider, per SIP message, for the delivery of SIP charges the local provider, per SIP message, for the delivery of SIP
messages to other local providers. The local provider can choose to messages to other local providers. The local provider can choose to
pass on this cost to its own customers if it so chooses. pass on this cost to its own customers if it so chooses.
The inter-domain SIP providers then form bi-lateral agreements with The inter-domain SIP providers then form bi-lateral agreements with
each other, exchanging SIP messages according to strict contracts. each other, exchanging SIP messages according to strict contracts.
skipping to change at page 19, line 22 skipping to change at page 19, line 22
The result of such a system is that a fixed cost can be associated The result of such a system is that a fixed cost can be associated
with sending a SIP message, and that this cost does not require with sending a SIP message, and that this cost does not require
micro-payments to be exchanged between local providers, as it does in micro-payments to be exchanged between local providers, as it does in
Section 3.10. Since all of the relationships are pre-established and Section 3.10. Since all of the relationships are pre-established and
negotiated, cheaper techniques for monetary transactions (such as negotiated, cheaper techniques for monetary transactions (such as
monthly post-paid transactions) can be used. monthly post-paid transactions) can be used.
This technique can be made to work in SIP, whereas it cannot in This technique can be made to work in SIP, whereas it cannot in
email, because inter-domain SIP connectivity has not yet been email, because inter-domain SIP connectivity has not yet been
established. In email, there already exists a no-cost form of established. In email, there already exists a no-cost form of inter-
inter-domain connectivity that cannot be eliminated without domain connectivity that cannot be eliminated without destroying the
destroying the utility of email. If, however, SIP inter-domain utility of email. If, however, SIP inter-domain communications get
communications get established from the start using this structure, established from the start using this structure, there is a path to
there is a path to deployment. deployment.
This structure is more or less the same as the one in place for the This structure is more or less the same as the one in place for the
PSTN today, and since there is relatively little spam on the PSTN PSTN today, and since there is relatively little spam on the PSTN
(compared to email!), there is some proof that this kind of (compared to email!), there is some proof that this kind of
arrangement can work. However, it puts back into SIP much of the arrangement can work. However, it puts back into SIP much of the
complexity and monopolistic structures that SIP promised to complexity and monopolistic structures that SIP promised to
eliminate. As such, it is a solution that the authors find eliminate. As such, it is a solution that the authors find
distasteful and contrary to the SIP design and architecture. distasteful and contrary to the SIP design and architecture.
3.14 Sender Checks 3.14 Sender Checks
In email, there has been a lot of interest in defining new DNS In email, there has been a lot of interest in defining new DNS
resource records that will allow a domain that receives a message to resource records that will allow a domain that receives a message to
verify that the sender is a valid MTA for the sending domain verify that the sender is a valid MTA for the sending domain [18]
[18][16]. [16].
Are these techniques useful for SIP? They can be used for SIP but are Are these techniques useful for SIP? They can be used for SIP but
not necessary. In email, there are no standards established for are not necessary. In email, there are no standards established for
securely identifying the identity of the sending domain of a message. securely identifying the identity of the sending domain of a message.
In SIP, however, TLS with mutual authentication can be used In SIP, however, TLS with mutual authentication can be used inter-
inter-domain. A provider receiving a message can then reject any domain. A provider receiving a message can then reject any message
message coming from a domain that does not match the asserted coming from a domain that does not match the asserted identity of the
identity of the sender of the message. Such a policy only works in sender of the message. Such a policy only works in the "trapezoid"
the "trapezoid" model of SIP, whereby there are only two domains in model of SIP, whereby there are only two domains in any call - the
any call - the sending domain, which is where the originator resides, sending domain, which is where the originator resides, and the
and the receiving domain. These techniques are discussed in Section receiving domain. These techniques are discussed in Section 26.3.2.2
26.3.2.2 of RFC 3261 [2]. These techinques, however, are only of RFC 3261 [2]. These techinques, however, are only applicable in
applicable in the trapezoid model where there is a sending and a the trapezoid model where there is a sending and a receiving domain
receiving domain only. In forwarding situations, the assumption no only. In forwarding situations, the assumption no longer holds and
longer holds and these techniques no longer work. these techniques no longer work.
Thus, instead of creating DNS entries containing the IP address of Thus, instead of creating DNS entries containing the IP address of
each legitimate relay for a domain, the provider can give each each legitimate relay for a domain, the provider can give each
legitimate relay a certificate that allows them to authenticate legitimate relay a certificate that allows them to authenticate
themselves as coming from that domain. Such a technique would work themselves as coming from that domain. Such a technique would work
even in the face of IP address spoofing, which the marid techniques even in the face of IP address spoofing, which the marid techniques
are susceptible to. are susceptible to.
4. Authenticated Identity in SIP 4. Authenticated Identity in SIP
skipping to change at page 20, line 42 skipping to change at page 20, line 42
technique, which is also documented in RFC 3261, is very secure but technique, which is also documented in RFC 3261, is very secure but
not widely deployed yet. In the long term, this approach will be not widely deployed yet. In the long term, this approach will be
necessary for the security properties needed to prevent SIP spam. necessary for the security properties needed to prevent SIP spam.
Once a domain has authenticated the identity of a user, when it Once a domain has authenticated the identity of a user, when it
relays a message from that user to another domain, the sending domain relays a message from that user to another domain, the sending domain
can assert the identity of the sender, and include a signature to can assert the identity of the sender, and include a signature to
validate that assertion. This is done using the SIP identity validate that assertion. This is done using the SIP identity
mechanism [17]. mechanism [17].
A weaker form of identity assertion is possible using the A weaker form of identity assertion is possible using the P-Asserted-
P-Asserted-Identity header field [6], but this technique requires Identity header field [6], but this technique requires mutual trust
mutual trust among all domains. Unfortunately, this becomes among all domains. Unfortunately, this becomes expontentially harder
expontentially harder to provide as the number of interconnected to provide as the number of interconnected domains grows. As that
domains grows. As that happens, the value of the identity assertion happens, the value of the identity assertion becomes equal to the
becomes equal to the trustworthiness of the least trustworthy domain. trustworthiness of the least trustworthy domain. Since spam is a
Since spam is a consequence of untrusted domains and users that get consequence of untrusted domains and users that get connected to the
connected to the network, the P-Asserted-Identity technique becomes network, the P-Asserted-Identity technique becomes ineffective at
ineffective at exactly the same levels of interconnectness that exactly the same levels of interconnectness that introduce spam.
introduce spam.
A further weakness of P-Asserted-ID is that the actual domain which A further weakness of P-Asserted-ID is that the actual domain which
asserted the identity cannot be known. If that domain could be asserted the identity cannot be known. If that domain could be
reliably known, then its assertions could be tempered based on user reliably known, then its assertions could be tempered based on user
or domain-wide policiies. This weakness is not present in [17], or domain-wide policiies. This weakness is not present in [17],
which allows the recipient of a message to cryptographically which allows the recipient of a message to cryptographically
determine the identity of the asserting domain. determine the identity of the asserting domain.
SIP also defines the usage of TLS between domains, using mutual SIP also defines the usage of TLS between domains, using mutual
authentication, as part of the base specification. This technique authentication, as part of the base specification. This technique
skipping to change at page 21, line 47 skipping to change at page 21, line 47
problem. problem.
Leverage What Email has to Offer: With the consent framework in Leverage What Email has to Offer: With the consent framework in
place, spammers have only a small window through which they can place, spammers have only a small window through which they can
introduce content to recipients. Fortunately, that problem is introduce content to recipients. Fortunately, that problem is
similar to traditional email spam, and can be addressed using the similar to traditional email spam, and can be addressed using the
various email-based anti-spam techniques. Providers of SIP various email-based anti-spam techniques. Providers of SIP
services should keep tabs on solutions in email as they evolve, services should keep tabs on solutions in email as they evolve,
and utilize the best of what those techniques have to offer. But and utilize the best of what those techniques have to offer. But
perhaps most importantly, providers should not ignore the spam perhaps most importantly, providers should not ignore the spam
problem until it happens! That is the pitfall email fell into. As problem until it happens! That is the pitfall email fell into.
soon as a provider inter-connects with other providers, or allows As soon as a provider inter-connects with other providers, or
SIP messages from the open Internet, that provider must consider allows SIP messages from the open Internet, that provider must
how they will deal with spam. consider how they will deal with spam.
6. Additional Work 6. Additional Work
Though the above framework serves as a good foundation on which to Though the above framework serves as a good foundation on which to
deal with spam in SIP, there are gaps, some of which can be addressed deal with spam in SIP, there are gaps, some of which can be addressed
by additional work that has yet to be undertaken. by additional work that has yet to be undertaken.
One of the difficulties with the strong identity techniques is that a One of the difficulties with the strong identity techniques is that a
receiver of a SIP request without an authenticated identity cannot receiver of a SIP request without an authenticated identity cannot
know whether the request lacked such an identity because the know whether the request lacked such an identity because the
skipping to change at page 22, line 41 skipping to change at page 22, line 41
SIP services on the Internet. SIP services on the Internet.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Rohan Mahy for providing information The authors would like to thank Rohan Mahy for providing information
on Habeas, Baruch Sterman for providing costs on VoIP termination on Habeas, Baruch Sterman for providing costs on VoIP termination
services, and Gonzalo Camarillo for his review. Useful comments and services, and Gonzalo Camarillo for his review. Useful comments and
feedback were provided by Nils Ohlmeir, Tony Finch, Randy Gellens and feedback were provided by Nils Ohlmeir, Tony Finch, Randy Gellens and
Yakov Shafranovich. Yakov Shafranovich.
9 Informative References 9. Informative References
[1] Campbell, B., "The Message Session Relay Protocol", [1] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-09 (work in progress), draft-ietf-simple-message-sessions-10 (work in progress),
October 2004. February 2005.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002. Instant Messaging", RFC 3428, December 2002.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation [5] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002. Protocol (SIP)", RFC 3323, November 2002.
[6] Jennings, C., Peterson, J. and M. Watson, "Private Extensions [6] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002. within Trusted Networks", RFC 3325, November 2002.
[7] Rosenberg, J., "A Presence Event Package for the Session [7] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] Rosenberg, J., "A Watcher Information Event Template-Package [8] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", RFC 3857, August for the Session Initiation Protocol (SIP)", RFC 3857,
2004. August 2004.
[9] Rosenberg, J., "An Extensible Markup Language (XML) Based [9] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information", RFC 3858, August 2004. Format for Watcher Information", RFC 3858, August 2004.
[10] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource [10] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004. Application (ENUM)", RFC 3761, April 2004.
[11] Rosenberg, J., "The Extensible Markup Language (XML) [11] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-05 (work in progress), November 2004. draft-ietf-simple-xcap-07 (work in progress), June 2005.
[12] Rosenberg, J., "Presence Authorization Rules", [12] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-01 (work in progress), October draft-ietf-simple-presence-rules-02 (work in progress),
2004. February 2005.
[13] Rosenberg, J., "A Framework for Consent-Based Communications in [13] Rosenberg, J., "A Framework for Consent-Based Communications in
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sipping-consent-framework-00 (work in progress), draft-ietf-sipping-consent-framework-01 (work in progress),
October 2004. February 2005.
[14] Rosenberg, J., "A Framework for Application Interaction in the [14] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-ietf-sipping-app-interaction-framework-03 (work in draft-ietf-sipping-app-interaction-framework-04 (work in
progress), October 2004. progress), February 2005.
[15] Burger, E., "A Session Initiation Protocol (SIP) Event Package [15] Burger, E., "A Session Initiation Protocol (SIP) Event Package
for Key Press Stimulus (KPML)", draft-ietf-sipping-kpml-07 for Key Press Stimulus (KPML)", draft-ietf-sipping-kpml-07
(work in progress), December 2004. (work in progress), December 2004.
[16] Lyon, J., "Sender ID: Authenticating E-Mail", [16] Lyon, J., "Sender ID: Authenticating E-Mail",
draft-ietf-marid-core-03 (work in progress), August 2004. draft-ietf-marid-core-03 (work in progress), August 2004.
[17] Peterson, J., "Enhancements for Authenticated Identity [17] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-03 (work in progress), September 2004. draft-ietf-sip-identity-05 (work in progress), May 2005.
[18] Danisch, H., "The RMX DNS RR and method for lightweight SMTP [18] Danisch, H., "The RMX DNS RR and method for lightweight SMTP
sender authorization", draft-danisch-dns-rr-smtp-04 (work in sender authorization", draft-danisch-dns-rr-smtp-04 (work in
progress), May 2004. progress), May 2004.
[19] Abadi, M., Burrows, M., Manasse, M. and T. Wobber, "Moderately [19] Abadi, M., Burrows, M., Manasse, M., and T. Wobber, "Moderately
Hard, Memory Bound Functions, NDSS 2003", February 2003. Hard, Memory Bound Functions, NDSS 2003", February 2003.
[20] Abadi, M., Burrows, M., Birrell, A., Dabek, F. and T. Wobber, [20] Abadi, M., Burrows, M., Birrell, A., Dabek, F., and T. Wobber,
"Bankable Postage for Network Services, Proceedings of the 8th "Bankable Postage for Network Services, Proceedings of the 8th
Asian Computing Science Conference, Mumbai, India", December Asian Computing Science Conference, Mumbai, India",
2003. December 2003.
[21] Clayton, R. and B. Laurie, "Proof of Work Proves not to Work, [21] Clayton, R. and B. Laurie, "Proof of Work Proves not to Work,
Third Annual Workshop on Economics and Information Security", Third Annual Workshop on Economics and Information Security",
May 2004. May 2004.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
Cisco Cisco
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
EMail: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Cullen Jennings Cullen Jennings
Cisco Cisco
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +1 408 527-9132 Phone: +1 408 527-9132
EMail: fluffy@cisco.com Email: fluffy@cisco.com
Jon Peterson Jon Peterson
Neustar Neustar
1800 Sutter Street 1800 Sutter Street
Suite 570 Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Phone: +1 925 363-8720 Phone: +1 925 363-8720
EMail: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
URI: http://www.neustar.biz URI: http://www.neustar.biz
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/