idnits 2.17.1 draft-ono-cross-media-relations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 12, 2009) is 5307 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Callee' is mentioned on line 182, but not defined -- Obsolete informational reference (is this intentional?): RFC 2426 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Ono 3 Internet-Draft H. Schulzrinne 4 Intended status: Informational Columbia University 5 Expires: April 15, 2010 October 12, 2009 7 Using Cross-Media Relations to Reduce False Positives during SPIT 8 Filtering 9 draft-ono-cross-media-relations-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 15, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Some legitimate calls are from persons or organizations connecting 48 the callee with weak social ties, such as a restaurant the callee 49 booked a table on-line. These legitimate calls are often mistakenly 50 labeled as unsolicited calls at a filtering system which uses the 51 contact list of the callee. To reduce these false positives during 52 SPIT filtering, we propose two approaches to label incoming calls 53 using cross-media relations from earlier communications. One 54 approach is that a potential caller offers the callee his contact 55 address(es) which might be used in future calls. Another is that a 56 callee provides a potential caller with weakly secret information. 57 In order to be identified as someone the callee contacted through 58 other means previously, the caller should convey the information in 59 future calls. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Using Cross-Media Relations . . . . . . . . . . . . . . . . . 4 66 4. Mechanism I: Contact Addresses of Potential Callers . . . . . 6 67 5. Mechanism II: Weakly Secret Information . . . . . . . . . . . 6 68 6. Enhanced Filtering . . . . . . . . . . . . . . . . . . . . . . 8 69 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 9 70 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 Unsolicited calls usually originate from persons or organizations, 79 whom the callee does not know their contact addresses nor met before. 80 Since an IP-based infrastructure is more vulnerable to unsolicited 81 calls or SPIT (SPam over Internet Telephony) calls, as described in 82 [RFC5039], people have recently been experiencing more SPIT calls. 84 Most legitimate calls, by contrast, have caller identifiers (IDs) 85 that the callee has seen before. Some legitimate calls, however, 86 have unknown caller IDs. Examples of these legitimate calls include 87 confirmations of appointments, reservations, or deliveries, and 88 recorded notifications of flight delays or school closing on a snowy 89 day. These legitimate calls are prone to false positives during SPIT 90 filtering. This is because their caller IDs are not found on the 91 callee's white list even if the callers have had prior contact with 92 the callee through transactions over the web or email exchanges 93 [have-i-met-u-before]. 95 This is a natural consequence of a conventional white list, which 96 usually contains the same addresses with his contact list or address 97 book. The contact list contains known or used contact addresses of 98 persons or organizations with strong ties in his or her social 99 network, such as family members, friends, and colleagues. The 100 contact list, however, rarely includes the addresses of those with 101 weak social ties [weak-ties], such as an operator at the customer 102 center of an on-line shopping site, or friends of a friend in an SNS 103 (Social Network Service) over the web. 105 Using a white list to label incoming calls requires caller ID 106 authentication. For a VoIP (Voice over IP) call using the SIP 107 (Session Initiation Protocol) [RFC3261], the SIP Identity header 108 [RFC4474] enables a callee to authenticate the caller ID. Some 109 legitimate calls, however, are sent with "unavailable" caller IDs. 110 These calls without any authenticated caller IDs limit the 111 effectiveness of labeling incoming calls based on the caller ID. 113 In summary, conventional whitelisting can hardly label the following 114 types of calls: 115 D1: Calls from persons or organizations connecting the callee with 116 weak social ties 117 D2: Calls from those connecting with strong social ties, but using 118 new, alternative, or unknown caller IDs, e.g., from a visited 119 place like a hotel 121 D3: Calls with unauthenticated caller IDs, e.g., through an 122 unauthenticated domain or using the caller ID in tel-URI 123 [RFC3966] 124 D4: Calls with blocked caller IDs 126 To cope with these difficulties of conventional whitelisting, we 127 propose to expand filter conditions with two mechanisms; both use 128 cross-media relations from earlier communications. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 This document defines the following term: 138 Cross-media relations: The information suggesting the existence of a 139 prior contact. When the information is offered by a potential 140 caller, it can be his contact address, which is in plain text 141 or hash coded. When the information is offered by the callee, 142 it needs to be a weak secret in order to be used for labeling 143 incoming call without authentication. The weakly secret 144 information is the value of the Message-ID [RFC5322] of an 145 outgoing email from the callee or random components contained 146 in the callee's customized contact address. 148 3. Using Cross-Media Relations 150 Figure 1 depicts an overview of our first mechanism. In order to 151 cope with the difficulties of D1 and D2 described above, a potential 152 caller offers the callee his contact addresses which he might use in 153 future calls. If the callee agrees, these contact addresses are 154 added to his white list. Figure 2 depicts an overview of our second 155 mechanism. In order to cope with the difficulties of D3 and D4 156 mainly, a callee provides a potential caller with weakly secret 157 information. The caller should use it in future calls in order to be 158 identified as someone the callee has had prior contact through other 159 means. The second mechanism allows to label incoming calls using the 160 weakly secret information, instead of caller IDs. 162 [Potential Caller] [Callee] 164 | HTTP Response | _____________ 165 |------------------------------>| rcv.& / \ 166 | | storep |\_____________/| 167 | |------> | White list: | 168 or | | 169 | Responded Email | | Contact addrs.| 170 |------------------------------>| rcv.& | in plain text | 171 | | store | or hash coded | 172 | |------> | | 173 ~~~ ~~~ | | 174 ~~~ ~~~ | | 175 | SIP INVITE Request |query to| | 176 | From: |label | | 177 |------------------------------>|------> \_____________/ 178 | | Filter conditions 180 Figure 1: An Overview of Mechanism I 182 [Callee] [Potential Caller] 183 ______________ | | 184 / \ generate,| | 185 |\______________/| send, | HTTP Request | 186 | Weak sercrets: | & store |------------------------------>| 187 | |<---------| | 188 | Random comp. in| or 189 | customized own | generate,| | 190 | contact addrs. | send, | Outgoing Email | 191 | & Message-IDs | & store |------------------------------>| 192 | |<---------| | 193 | | ~~~ ~~~ 194 | | ~~~ ~~~ 195 | | | SIP INITE Request | 196 | | | To: | 197 | | | or | 198 | | query to | New-References: | 199 | | label |<------------------------------| 200 \______________/ <---------| | 201 Filter conditions 203 Figure 2: An Overview of Mechanism II 205 4. Mechanism I: Contact Addresses of Potential Callers 207 Our first mechanism enables potential callers to offer their contact 208 addresses which they might use in future calls more easily and more 209 widely. 211 To make it more easily in a web transaction, we propose that an HTTP 212 response from a potential caller conveys his or her contact addresses 213 in an HTML META tag, HTTP-EQUIV [W3C.REC-html401-19991224] or a new 214 HTTP header, Correspondence-URIs [I-D.shacham-http-corr-uris]. In an 215 email exchange, the contact addresses can be contained in a vCard 216 [RFC2426] attached to an email message sent from a potential caller. 217 After the callee receives the contact addresses of a potential 218 caller, the callee adds them to his or her white list. To prevent 219 misuse, the callee should be prompted for confirmation before 220 updating his or her white list. 222 To make it more widely, we propose to convey hash-coded contact 223 addresses of potential callers. Hash-coded contact addresses are 224 suitable if potential callers prefer concealing their routable 225 address for privacy reasons. For example, in an SNS where 226 subscribers prefer not to publish their routable contact addresses, 227 subscribers should be allowed to publish their hashed contact address 228 for the limited purpose of filtering calls. 230 This first mechanism is useful in a case where the contact addresses 231 of potential callers have been determined and the number is small. 232 In other cases, our second mechanism should be used. 234 5. Mechanism II: Weakly Secret Information 236 Our second mechanism allows a callee to provide potential callers 237 with weakly secret information as cross-media relations. Potential 238 callers should use this information in future calls to be identified 239 as someone with whom the callee has had prior contact through other 240 means. 242 This mechanism is useful in the following cases. One is where the 243 previous contact was one-to-many correspondence between the callee 244 and potential callers. For example, when joining an association, the 245 callee is unwilling to receive all the contact addresses of potential 246 callers in the association. Another case is where potential callers 247 might use a different or no authenticated caller ID, due to their 248 situation such as traveling, or due to the type of communication 249 medium or service, such as two-stage dialing for international calls. 251 The information about cross-media relations depends on the 252 communication medium of a previous contact. A customized contact 253 address containing a random component or a token can be used when a 254 callee fills out contact information on a web site, or in a vCard 255 attached to an email message. The random component or token can be 256 automatically generated in correspondence to the URL (Uniform 257 Resource Locator) [RFC3986], or manually specified. In the examples 258 in Figure 3, a token, "adgs24oF", in the SIP-URI is set between the 259 user name and the domain name preceded with "+". This is the same 260 way as the email addressing practice called subaddressing [RFC5233]. 261 For tel-URI, a token, "0012", follows the E.164 number like an 262 extension. To convey this information in a later call, the caller 263 just needs to set the destination address to the customized contact 264 address, as the INVITE request shown in Figure 3. 266 Web client Web server 267 at callee at potential caller 268 | | 269 | POST /join HTTP/1.1 | 270 | HOST: ffp.airline.com | 271 | Content-Length: 128 | 272 | Conetnt-Type: application/x-www-form-urlencoded | 273 | | 274 | phone1=sip:userA+adgs24oF@example.com&phone2=tel:+121291711110012 | 275 | ... | 276 |------------------------------------------------------------------>| 277 | HTTP/1.1 200 OK | 278 |<------------------------------------------------------------------| 279 | | 280 ~~~ ~~~ 281 ~~~ ~~~ 282 | | 283 | INVITE sip:username+adgs20oF@exmale.com SIP/2.0 | 284 | To: sip:username+adgs20oF@exmale.com | 285 |<------------------------------------------------------------------| 286 | | 287 Note: To show related headers only, many mandatory headers are omitted. 289 Figure 3: Using Weak-Eecret in HTTP and SIP messages 291 Email client Email client 292 at callee at potential caller 293 | | 294 | (Message) | 295 |<------------------------------------------------------------------| 296 | Message | 297 | Message-ID:<56626454-8D6F-49FF-BFA0-1FF6A63E71EA@example.com> | 298 |------------------------------------------------------------------>| 299 | | 300 ~~~ ~~~ 301 ~~~ ~~~ 302 | | 303 | INVITE sip:username@exmale.com SIP/2.0 | 304 | New-References:<56626454-8D6F-49FF-BFA0-1FF6A63E71EA@example.com>;| 305 | type="email" | 306 |<------------------------------------------------------------------| 307 | | 308 Note: To show related headers only, many mandatory headers are omitted. 310 Figure 4: Using Weak Secret in Email and SIP messages 312 Specifically in an email exchange, as shown in Figure 4, the message 313 identifier of an email from the callee can be used. A potential 314 caller first sends a message to the callee requesting a real-time 315 communication. This message is optional. If the callee accepts the 316 request, he will respond to it by email optionally containing his 317 contact address. As a result, the message identifier of the response 318 email, which is set in the Message-ID header, can be used as weakly 319 secret information to prove the acceptance from the callee. Thus, 320 the message identifiers of outbound emails or the call identifers of 321 SIP calls can be included by the potential caller in a later call, 322 even if he uses a different caller ID or type of communication 323 medium. To convey the message identifier in a SIP call, the caller 324 should set a SIP header extension [I-D.ono-earlier-comm-references] 325 to its value. In the example message in Figure 4, a new SIP header 326 extension under discussion, New-References is used. 328 6. Enhanced Filtering 330 Our two mechanisms enhance a filtering process using caller IDs in 331 the following ways. For our first mechanism, it extends white list 332 by contain contact addresses in hash format. 334 Furthermore, sharing a white list for people within an 335 organization increases the effectiveness of the white list. A 336 remote server maintaining common white lists is also effective, if 337 it can be queried whether or not the caller ID is found on the 338 list and respond with binary, e.g., query about membership. 340 For our second mechanism, it adds conditionals using weakly secret 341 information after the conditionals checking the authenticated caller 342 ID of an incoming call on a black list nor on a white list. For 343 incoming calls of which caller ID is not found on the white list, the 344 expanded filtering process tests on two new conditionals. The first 345 one is whether it contains a valid Message-ID value in the new 346 references header under discussion [I-D.ono-earlier-comm-references]. 347 The second is whether it contains a valid subaddress of the 348 destination address, i.e., in the To header. That is, if the test 349 succeeds in either condition of the message identifier or subaddress, 350 the call request will be accepted. 352 Therefore, by enhancing existing filter conditions, our proposed 353 mechanisms enable a callee to label incoming calls, not only from 354 persons or organizations with weak ties, but also from callers who 355 change their caller IDs. As a result, they are expected to reduce 356 false positives that occur during filtering. 358 7. Security Consideration 360 TBD 362 8. IANA Consideration 364 This document requires no IANA Consideration. 366 9. References 368 9.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 374 A., Peterson, J., Sparks, R., Handley, M., and E. 375 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 376 June 2002. 378 9.2. Informative References 380 [I-D.ono-earlier-comm-references] 381 Ono, K. and H. Schulzrinne, "Referencing Earlier 382 Communications in SIP Requests", 383 draft-ono-earlier-comm-references-00 (work in progress), 384 October 2009. 386 [I-D.shacham-http-corr-uris] 387 Shacham, R. and H. Schulzrinne, "HTTP Header for Future 388 Correspondence Addresses", draft-shacham-http-corr-uris-00 389 (work in progress), May 2007. 391 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 392 RFC 2426, September 1998. 394 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 395 RFC 3966, December 2004. 397 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 398 Resource Identifier (URI): Generic Syntax", STD 66, 399 RFC 3986, January 2005. 401 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 402 Authenticated Identity Management in the Session 403 Initiation Protocol (SIP)", RFC 4474, August 2006. 405 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 406 Protocol (SIP) and Spam", RFC 5039, January 2008. 408 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 409 Extension", RFC 5233, January 2008. 411 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 412 October 2008. 414 [W3C.REC-html401-19991224] 415 Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01 416 Specification", World Wide Web Consortium 417 Recommendation REC-html401-19991224, December 1999, 418 . 420 [have-i-met-u-before] 421 Ono, K. and H. Schulzrinne, "Have I Met You Before? Using 422 Cross-Media Relations to Reduce SPIT", IPTCOMM 09, 423 July 2009. 425 [weak-ties] 426 Granovetter, M., "The Strength of Weak Ties", Amer.J.of 427 Sociology 78:1360-80, May 1973. 429 Authors' Addresses 431 Kumiko Ono 432 Columbia University 433 Department of Computer Science 434 New York, NY 10027 435 USA 437 Email: kumiko@cs.columbia.edu 439 Henning Schulzrin ne 440 Columbia University 441 Department of Computer Science 442 New York, NY 10027 443 USA 445 Email: hgs@cs.columbia.edu