1
2
3
4
5
6
7Internet Engineering Task Force (IETF) R. Clayton
8Request for Comments: 6692 University of Cambridge
9Updates: 6591 M. Kucherawy
10Category: Standards Track Cloudmark, Inc.
11ISSN: 2070-1721 July 2012
12
13
14 Source Ports in Abuse Reporting Format (ARF) Reports
15
16Abstract
17
18 This document defines an additional header field for use in Abuse
19 Reporting Format (ARF) reports to permit the identification of the
20 source port of the connection involved in an abuse incident.
21
22 This document updates RFC 6591.
23
24Status of This Memo
25
26 This is an Internet Standards Track document.
27
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 Internet Standards is available in Section 2 of RFC 5741.
33
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 http://www.rfc-editor.org/info/rfc6692.
37
38Copyright Notice
39
40 Copyright (c) 2012 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
42
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
52
53
54
55
56
57
58Clayton & Kucherawy Standards Track [Page 1]
59
60RFC 6692 ARF Source Ports July 2012
61
62
63Table of Contents
64
65 1. Introduction ....................................................2
66 2. Keywords ........................................................2
67 3. Source-Port Field Definition ....................................2
68 4. Time Accuracy ...................................................3
69 5. IANA Considerations .............................................3
70 6. Security Considerations .........................................3
71 7. References ......................................................4
72 7.1. Normative References .......................................4
73 7.2. Informative References .....................................4
74 Appendix A. Acknowledgements .......................................5
75
761. Introduction
77
78 [ARF] defined the Abuse Reporting Format, an extensible message
79 format for Email Feedback Reports. These reports are used to report
80 incidents of email abuse. ARF was extended by [AUTHFAILURE-REPORT]
81 to enable the reporting of email authentication failures. These
82 specifications provided for the source IP address to be included in a
83 report. As explained in [LOG], the deployment of IP address sharing
84 techniques requires the source port values to be included in reports
85 if unambiguous identification of the origin of abuse is to be
86 achieved.
87
88 This document defines an ARF reporting field to contain this
89 information and provides guidance for its use.
90
912. Keywords
92
93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
95 document are to be interpreted as described in [KEYWORDS].
96
973. Source-Port Field Definition
98
99 A new ARF header field called "Source-Port" is defined. When present
100 in a report, it MUST contain the client port of the TCP connection
101 from which the reported message originated, corresponding to the
102 "Source-IP" field that contains the client address of that same
103 connection, thereby describing completely the origin of the abuse
104 incident.
105
106 Per, [ABNF], the formal syntax is:
107
108 source-port = "Source-Port:" [CFWS] 1*5DIGIT [CFWS] CRLF
109
110
111
112
113
114Clayton & Kucherawy Standards Track [Page 2]
115
116RFC 6692 ARF Source Ports July 2012
117
118
119 "CFWS", which represents email-style comments or folding white space,
120 is imported from [MAIL].
121
122 When any report is generated that includes the "Source-IP" field (see
123 Section 3.2 of [ARF]), this field SHOULD also be present, unless the
124 port number is unavailable.
125
126 Use of this field is RECOMMENDED for reports generated per
127 [AUTHFAILURE-REPORT] (see Section 3.1 of that document).
128
1294. Time Accuracy
130
131 [LOG] underscores the importance of accurate clocks when generating
132 reports that include source port information because of the fact that
133 source ports can be recycled very quickly in Internet Service
134 Provider environments. The same considerations described there apply
135 here.
136
137 Report generators that include an Arrival-Date report field MAY
138 choose to express the value of that date in Universal Coordinated
139 Time (UTC) to enable simpler correlation with local records at sites
140 that are following the provisions of [LOG].
141
1425. IANA Considerations
143
144 IANA has added the following entry to the "Feedback Report Header
145 Fields" registry:
146
147 Field Name: Source-Port
148
149 Description: TCP source port from which the original message was
150 received
151
152 Multiple Appearances: No
153
154 Related "Feedback-Type": any
155
156 Reference: [RFC6692]
157
158 Status: current
159
1606. Security Considerations
161
162 This extension introduces no new security considerations not already
163 covered in [ARF].
164
165 Some security considerations related to the general topic of source
166 port logging can be found in [LOG].
167
168
169
170Clayton & Kucherawy Standards Track [Page 3]
171
172RFC 6692 ARF Source Ports July 2012
173
174
1757. References
176
1777.1. Normative References
178
179 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
180 Specifications: ABNF", STD 68, RFC 5234, January 2008.
181
182 [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
183 Extensible Format for Email Feedback Reports", RFC 5965,
184 August 2010.
185
186 [AUTHFAILURE-REPORT]
187 Fontana, H., "Authentication Failure Reporting Using the
188 Abuse Reporting Format", RFC 6591, April 2012.
189
190 [KEYWORDS]
191 Bradner, S., "Key words for use in RFCs to Indicate
192 Requirement Levels", BCP 14, RFC 2119, March 1997.
193
194 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
195 October 2008.
196
1977.2. Informative References
198
199 [LOG] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
200 "Logging Recommendations for Internet-Facing Servers",
201 BCP 162, RFC 6302, June 2011.
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226Clayton & Kucherawy Standards Track [Page 4]
227
228RFC 6692 ARF Source Ports July 2012
229
230
231Appendix A. Acknowledgements
232
233 The authors wish to acknowledge the following for their review and
234 constructive criticism of this proposal: Steve Atkins, Scott
235 Kitterman, John Levine, and Doug Otis.
236
237 The idea for this work originated within the Messaging Anti-Abuse
238 Working Group (MAAWG).
239
240Authors' Addresses
241
242 Richard Clayton
243 University of Cambridge
244 Computer Laboratory
245 JJ Thomson Avenue
246 Cambridge CB3 0FD
247 United Kingdom
248
249 Phone: +44 1223 763570
250 EMail: richard.clayton@cl.cam.ac.uk
251
252
253 Murray S. Kucherawy
254 Cloudmark, Inc.
255 128 King St., 2nd Floor
256 San Francisco, CA 94107
257 US
258
259 Phone: +1 415 946 3800
260 EMail: superuser@gmail.com
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282Clayton & Kucherawy Standards Track [Page 5]
283
284