1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
|
<pre>Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7820 Marvell
Category: Experimental March 2016
ISSN: 2070-1721
<span class="h1">UDP Checksum Complement in</span>
<span class="h1">the One-Way Active Measurement Protocol (OWAMP) and</span>
<span class="h1">Two-Way Active Measurement Protocol (TWAMP)</span>
Abstract
The One-Way Active Measurement Protocol (OWAMP) and the Two-Way
Active Measurement Protocol (TWAMP) are used for performance
monitoring in IP networks. Delay measurement is performed in these
protocols by using timestamped test packets. Some implementations
use hardware-based timestamping engines that integrate the accurate
transmission time into every outgoing OWAMP/TWAMP test packet during
transmission. Since these packets are transported over UDP, the UDP
Checksum field is then updated to reflect this modification. This
document proposes to use the last 2 octets of every test packet as a
Checksum Complement, allowing timestamping engines to reflect the
checksum modification in the last 2 octets rather than in the UDP
Checksum field. The behavior defined in this document is completely
interoperable with existing OWAMP/TWAMP implementations.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7820">http://www.rfc-editor.org/info/rfc7820</a>.
<span class="grey">Mizrahi Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. Terminology ................................................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Abbreviations ..............................................<a href="#page-5">5</a>
<a href="#section-3">3</a>. Using the UDP Checksum Complement in OWAMP and TWAMP ............<a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. Overview ...................................................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. OWAMP/TWAMP Test Packets with Checksum Complement ..........<a href="#page-6">6</a>
3.2.1. Transmission of OWAMP/TWAMP with Checksum
Complement .........................................<a href="#page-10">10</a>
3.2.2. Intermediate Updates of OWAMP/TWAMP with
Checksum Complement ................................<a href="#page-10">10</a>
<a href="#section-3.2.3">3.2.3</a>. Reception of OWAMP/TWAMP with Checksum Complement ..10
<a href="#section-3.3">3.3</a>. Interoperability with Existing Implementations ............<a href="#page-10">10</a>
3.4. Using the Checksum Complement with or without
Authentication ............................................<a href="#page-11">11</a>
<a href="#section-3.4.1">3.4.1</a>. Checksum Complement in Authenticated Mode ..........<a href="#page-11">11</a>
<a href="#section-3.4.2">3.4.2</a>. Checksum Complement in Encrypted Mode ..............<a href="#page-11">11</a>
<a href="#section-4">4</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-5">5</a>. References .....................................................<a href="#page-12">12</a>
<a href="#section-5.1">5.1</a>. Normative References ......................................<a href="#page-12">12</a>
<a href="#section-5.2">5.2</a>. Informative References ....................................<a href="#page-13">13</a>
<a href="#appendix-A">Appendix A</a>. Checksum Complement Usage Example .....................<a href="#page-14">14</a>
Acknowledgments ...................................................<a href="#page-15">15</a>
Author's Address ..................................................<a href="#page-15">15</a>
<span class="grey">Mizrahi Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The One-Way Active Measurement Protocol [<a href="#ref-OWAMP" title=""A One-way Active Measurement Protocol (OWAMP)"">OWAMP</a>] and the Two-Way
Active Measurement Protocol [<a href="#ref-TWAMP" title=""A Two-Way Active Measurement Protocol (TWAMP)"">TWAMP</a>] are used for performance
monitoring in IP networks.
Delay and delay variation are two of the metrics that OWAMP/TWAMP can
measure. Measurement is performed using timestamped test packets.
In some use cases, such as carrier networks, these two metrics are an
essential aspect of the Service Level Agreement (SLA) and therefore
must be measured with a high degree of accuracy. If packets are
timestamped in hardware as they exit the host, then greater accuracy
is possible in comparison to higher-layer timestamps (as explained
further below).
The accuracy of delay measurements relies on the timestamping method
and its implementation. In order to facilitate accurate
timestamping, an implementation can use a hardware-based timestamping
engine, as shown in Figure 1. In such cases, the OWAMP/TWAMP packets
are sent and received by a software layer, whereas the timestamping
engine modifies every outgoing test packet by incorporating its
accurate transmission time into the Timestamp field in the packet.
<span class="grey">Mizrahi Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
OWAMP/TWAMP-enabled Node
+-------------------+
| |
| +-----------+ |
Software | |OWAMP/TWAMP| |
| | protocol | |
| +-----+-----+ |
| | | +-----------------------+
| +-----+-----+ | / Intermediate entity |
| | Accurate | | / in charge of: |
ASIC/FPGA | | Timestamp | | /__ - Timestamping |
| | engine | | |- Updating checksum or |
| +-----------+ | | Checksum Complement |
| | | +-----------------------+
+---------+---------+
|
|test packets
|
___ v _
/ \_/ \__
/ \_
/ IP /
\_ Network /
/ \
\__/\_ ___/
\_/
ASIC: Application-Specific Integrated Circuit
FPGA: Field-Programmable Gate Array
Figure 1: Accurate Timestamping in OWAMP/TWAMP
OWAMP/TWAMP test packets are transported over UDP. When the UDP
payload is changed by an intermediate entity such as the timestamping
engine, the UDP Checksum field must be updated to reflect the new
payload. When using UDP over IPv4 [<a href="#ref-UDP" title=""User Datagram Protocol"">UDP</a>], an intermediate entity that
cannot update the value of the UDP Checksum has no choice except to
assign a value of zero to the Checksum field, causing the receiver to
ignore the Checksum field and potentially accept corrupted packets.
UDP over IPv6, as defined in [<a href="#ref-IPv6" title=""Internet Protocol, Version 6 (IPv6) Specification"">IPv6</a>], does not allow a zero checksum,
except in specific cases [<a href="#ref-ZeroChecksum">ZeroChecksum</a>]. As discussed in
[<a href="#ref-ZeroChecksum">ZeroChecksum</a>], the use of a zero checksum is generally not
recommended and should be avoided to the extent possible.
Since an intermediate entity only modifies a specific field in the
packet, i.e., the Timestamp field, the UDP Checksum update can be
performed incrementally, using the concepts presented in [<a href="#ref-Checksum" title=""Computation of the Internet Checksum via Incremental Update"">Checksum</a>].
<span class="grey">Mizrahi Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
A similar problem is addressed in Annex E of [<a href="#ref-IEEE1588" title=""IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems"">IEEE1588</a>]. When the
Precision Time Protocol (PTP) is transported over IPv6, 2 octets are
appended to the end of the PTP payload for UDP Checksum updates. The
value of these 2 octets can be updated by an intermediate entity,
causing the value of the UDP Checksum field to remain correct.
This document defines a similar concept for [<a href="#ref-OWAMP" title=""A One-way Active Measurement Protocol (OWAMP)"">OWAMP</a>] and [<a href="#ref-TWAMP" title=""A Two-Way Active Measurement Protocol (TWAMP)"">TWAMP</a>],
allowing intermediate entities to update OWAMP/TWAMP test packets and
maintain the correctness of the UDP Checksum by modifying the last
2 octets of the packet.
The term "Checksum Complement" is used throughout this document and
refers to the 2 octets at the end of the UDP payload, used for
updating the UDP Checksum by intermediate entities.
The usage of the Checksum Complement can in some cases simplify the
implementation, because if the packet data is processed in serial
order, it is simpler to first update the Timestamp field and then
update the Checksum Complement, rather than to update the timestamp
and then update the UDP Checksum residing at the UDP header.
The Checksum Complement mechanism is also defined for the Network
Time Protocol in [<a href="./rfc7821" title=""UDP Checksum Complement in the Network Time Protocol (NTP)"">RFC7821</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="#ref-KEYWORDS" title=""Key words for use in RFCs to Indicate Requirement Levels"">KEYWORDS</a>].
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Abbreviations</span>
HMAC Hashed Message Authentication Code
OWAMP One-Way Active Measurement Protocol
PTP Precision Time Protocol
TWAMP Two-Way Active Measurement Protocol
UDP User Datagram Protocol
<span class="grey">Mizrahi Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Using the UDP Checksum Complement in OWAMP and TWAMP</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Overview</span>
The UDP Checksum Complement is a 2-octet field that is piggybacked at
the end of the test packet. It resides in the last 2 octets of the
UDP payload.
+----------------------------------+
| IPv4/IPv6 Header |
+----------------------------------+
| UDP Header |
+----------------------------------+
^ | |
| | OWAMP/TWAMP |
UDP | packet |
Payload +----------------------------------+
| |UDP Checksum Complement (2 octets)|
v +----------------------------------+
Figure 2: Checksum Complement in OWAMP/TWAMP Test Packets
The Checksum Complement is used to compensate for changes performed
in the packet by intermediate entities, as described in the
Introduction (<a href="#section-1">Section 1</a>). An example of the usage of the Checksum
Complement is provided in <a href="#appendix-A">Appendix A</a>.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. OWAMP/TWAMP Test Packets with Checksum Complement</span>
The One-Way Active Measurement Protocol [<a href="#ref-OWAMP" title=""A One-way Active Measurement Protocol (OWAMP)"">OWAMP</a>] and the Two-Way
Active Measurement Protocol [<a href="#ref-TWAMP" title=""A Two-Way Active Measurement Protocol (TWAMP)"">TWAMP</a>] both make use of timestamped test
packets. A Checksum Complement MAY be used in the following cases:
o In OWAMP test packets sent by the sender to the receiver.
o In TWAMP test packets sent by the sender to the reflector.
o In TWAMP test packets sent by the reflector to the sender.
OWAMP/TWAMP test packets are transported over UDP, either over IPv4
or over IPv6. This document applies to both OWAMP and TWAMP over
IPv4 and over IPv6.
<span class="grey">Mizrahi Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
OWAMP/TWAMP test packets contain a Packet Padding field. This
document proposes to use the last 2 octets of the Packet Padding
field as the Checksum Complement. In this case, the Checksum
Complement is always the last 2 octets of the UDP payload, and thus
the field is located at (UDP Length - 2 octets) after the beginning
of the UDP header.
Figure 3 illustrates the OWAMP test packet format, including the UDP
Checksum Complement.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. Packet Padding .
. .
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Checksum Complement in OWAMP Test Packets
<span class="grey">Mizrahi Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
Figure 4 illustrates the TWAMP test packet format, including the UDP
Checksum Complement. ("TTL" means "Time to Live", and "MBZ" refers
to the "MUST be zero" field [<a href="#ref-IPPMIPsec" title=""IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)"">IPPMIPsec</a>].)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | |
+-+-+-+-+-+-+-+-+ +
| |
. .
. Packet Padding .
. .
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Checksum Complement in TWAMP Test Packets
The length of the Packet Padding field in test packets is announced
during the session initiation through the <Padding Length> field in
the Request-Session message [<a href="#ref-OWAMP" title=""A One-way Active Measurement Protocol (OWAMP)"">OWAMP</a>] or in the Request-TW-Session
message [<a href="#ref-TWAMP" title=""A Two-Way Active Measurement Protocol (TWAMP)"">TWAMP</a>].
<span class="grey">Mizrahi Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
When a Checksum Complement is included, the padding length MUST be
sufficiently long to include the Checksum Complement:
o In OWAMP, the padding length is at least 2 octets, allowing the
sender to incorporate the Checksum Complement in the last 2 octets
of the padding.
o In TWAMP, the padding length is at least 29 octets in
unauthenticated mode and at least 58 octets in authenticated mode.
The additional padding is required, since the header of reflector
test packets is longer than the header of sender test packets.
The difference between the sender packet and the reflector packet
is 27 octets in unauthenticated mode and 56 octets in
authenticated mode. Thus, the padding in reflector test packets
is shorter than the padding in sender packets. Using at least
29 octets of padding (58 in authenticated mode) in sender test
packets allows both the sender and the reflector to use a 2-octet
Checksum Complement. Note: If the minimal length requirement is
not met, the reflector cannot use a Checksum Complement in the
reflected test packets, but the sender can use a Checksum
Complement in the test packets it transmits.
o Two optional TWAMP features are defined in [<a href="#ref-TWAMP-Reflect">TWAMP-Reflect</a>]:
octet reflection and symmetrical size. When at least one of these
features is enabled, the Request-TW-Session message includes the
<Padding Length> field, as well as a <Length of padding to
reflect> field. In this case, both fields must be sufficiently
long to allow at least 2 octets of padding in both sender test
packets and reflector test packets. Specifically, when octet
reflection is enabled, the two Length fields must be defined such
that the padding expands at least 2 octets beyond the end of the
reflected octets.
As described in <a href="#section-1">Section 1</a>, the extensions described in this document
are implemented by two logical layers -- a protocol layer and a
timestamping layer. It is assumed that the two layers are
synchronized regarding whether the usage of the Checksum Complement
is enabled or not; since both logical layers reside in the same
network device, it is assumed that there is no need for a protocol
that synchronizes this information between the two layers. When
Checksum Complement usage is enabled, the protocol layer must take
care to verify that test packets include the necessary padding,
thereby avoiding the need for the timestamping layer to verify that
en-route test packets include the necessary padding.
<span class="grey">Mizrahi Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Transmission of OWAMP/TWAMP with Checksum Complement</span>
The transmitter of an OWAMP/TWAMP test packet MAY include a Checksum
Complement field, incorporated in the last 2 octets of the padding.
A transmitter that includes a Checksum Complement in its outgoing
test packets MUST include a Packet Padding field in these packets,
the length of which MUST be sufficient to include the Checksum
Complement. The length of the Packet Padding field is negotiated
during session initiation, as described in <a href="#section-3.2">Section 3.2</a>.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Intermediate Updates of OWAMP/TWAMP with Checksum Complement</span>
An intermediate entity that receives and alters an OWAMP/TWAMP
test packet can alter either the UDP Checksum field or the Checksum
Complement field in order to maintain the correctness of the
UDP Checksum value.
<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>. Reception of OWAMP/TWAMP with Checksum Complement</span>
This document does not impose new requirements on the receiving end
of an OWAMP/TWAMP test packet.
The UDP layer at the receiving end verifies the UDP Checksum of
received test packets, and the OWAMP/TWAMP layer should treat the
Checksum Complement as part of the padding.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Interoperability with Existing Implementations</span>
The behavior defined in this document does not impose new
requirements on the reception behavior of OWAMP/TWAMP test packets.
The protocol stack of the receiving host performs the conventional
UDP Checksum verification; thus, from the perspective of the
receiving host, the existence of the Checksum Complement is
transparent. Therefore, the functionality described in this document
allows interoperability with existing implementations that comply
with [<a href="#ref-OWAMP" title=""A One-way Active Measurement Protocol (OWAMP)"">OWAMP</a>] or [<a href="#ref-TWAMP" title=""A Two-Way Active Measurement Protocol (TWAMP)"">TWAMP</a>].
<span class="grey">Mizrahi Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Using the Checksum Complement with or without Authentication</span>
Both OWAMP and TWAMP may use authentication or encryption, as defined
in [<a href="#ref-OWAMP" title=""A One-way Active Measurement Protocol (OWAMP)"">OWAMP</a>] and [<a href="#ref-TWAMP" title=""A Two-Way Active Measurement Protocol (TWAMP)"">TWAMP</a>].
<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Checksum Complement in Authenticated Mode</span>
OWAMP and TWAMP test packets can be authenticated using an HMAC
(Hashed Message Authentication Code). The HMAC covers some of the
fields in the test packet header. The HMAC does not cover the
Timestamp field and the Packet Padding field.
A Checksum Complement MAY be used when authentication is enabled. In
this case, an intermediate entity can timestamp test packets and
update their Checksum Complement field without modifying the HMAC.
<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Checksum Complement in Encrypted Mode</span>
When OWAMP and TWAMP are used in encrypted mode, the Timestamp field
is encrypted.
A Checksum Complement SHOULD NOT be used in encrypted mode. The
Checksum Complement is effective in both unauthenticated mode and
authenticated mode, allowing the intermediate entity to perform
serial processing of the packet without storing and forwarding it.
On the other hand, in encrypted mode, an intermediate entity that
timestamps a test packet must also re-encrypt the packet accordingly.
Re-encryption typically requires the intermediate entity to store the
packet, re-encrypt it, and then forward it. Thus, from an
implementer's perspective, the Checksum Complement has very little
value in encrypted mode, as it does not necessarily simplify the
implementation.
Note: While [<a href="#ref-OWAMP" title=""A One-way Active Measurement Protocol (OWAMP)"">OWAMP</a>] and [<a href="#ref-TWAMP" title=""A Two-Way Active Measurement Protocol (TWAMP)"">TWAMP</a>] include an inherent security
mechanism, these protocols can be secured by other measures, e.g.,
[<a href="#ref-IPPMIPsec" title=""IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)"">IPPMIPsec</a>]. For reasons similar to those described above, a
Checksum Complement SHOULD NOT be used in this case.
<span class="grey">Mizrahi Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This document describes how a Checksum Complement extension can be
used for maintaining the correctness of the UDP Checksum.
The purpose of this extension is to ease the implementation of
accurate timestamping engines, as illustrated in Figure 1. The
extension is intended to be used internally in an OWAMP/TWAMP-enabled
node, and not intended to be used by intermediate switches and
routers that reside between the sender and the receiver/reflector.
Any modification of a test packet by intermediate switches or routers
should be considered a malicious man-in-the-middle (MITM) attack.
It is important to emphasize that the scheme described in this
document does not increase the protocol's vulnerability to MITM
attacks; a MITM attacker who maliciously modifies a packet and its
Checksum Complement is logically equivalent to a MITM attacker who
modifies a packet and its UDP Checksum field.
The concept described in this document is intended to be used only in
unauthenticated mode or authenticated mode. As described in
<a href="#section-3.4.2">Section 3.4.2</a>, using the Checksum Complement in encrypted mode does
not simplify the implementation compared to using the conventional
checksum, and therefore the Checksum Complement should not be used.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. References</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Normative References</span>
[<a id="ref-Checksum">Checksum</a>] Rijsinghani, A., Ed., "Computation of the Internet
Checksum via Incremental Update", <a href="./rfc1624">RFC 1624</a>,
DOI 10.17487/RFC1624, May 1994,
<<a href="http://www.rfc-editor.org/info/rfc1624">http://www.rfc-editor.org/info/rfc1624</a>>.
[<a id="ref-IPv6">IPv6</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, DOI 10.17487/RFC2460,
December 1998, <<a href="http://www.rfc-editor.org/info/rfc2460">http://www.rfc-editor.org/info/rfc2460</a>>.
[<a id="ref-KEYWORDS">KEYWORDS</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-OWAMP">OWAMP</a>] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", <a href="./rfc4656">RFC 4656</a>, DOI 10.17487/RFC4656, September 2006,
<<a href="http://www.rfc-editor.org/info/rfc4656">http://www.rfc-editor.org/info/rfc4656</a>>.
<span class="grey">Mizrahi Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
[<a id="ref-TWAMP">TWAMP</a>] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
<a href="./rfc5357">RFC 5357</a>, DOI 10.17487/RFC5357, October 2008,
<<a href="http://www.rfc-editor.org/info/rfc5357">http://www.rfc-editor.org/info/rfc5357</a>>.
[<a id="ref-TWAMP-Reflect">TWAMP-Reflect</a>]
Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", <a href="./rfc6038">RFC 6038</a>, DOI 10.17487/RFC6038, October 2010,
<<a href="http://www.rfc-editor.org/info/rfc6038">http://www.rfc-editor.org/info/rfc6038</a>>.
[<a id="ref-UDP">UDP</a>] Postel, J., "User Datagram Protocol", STD 6, <a href="./rfc768">RFC 768</a>,
DOI 10.17487/RFC768, August 1980,
<<a href="http://www.rfc-editor.org/info/rfc768">http://www.rfc-editor.org/info/rfc768</a>>.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Informative References</span>
[<a id="ref-IEEE1588">IEEE1588</a>] IEEE, "IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", IEEE Std 1588-2008,
DOI 10.1109/IEEESTD.2008.4579760, July 2008.
[<a id="ref-IPPMIPsec">IPPMIPsec</a>] Pentikousis, K., Ed., Zhang, E., and Y. Cui,
"IKEv2-Derived Shared Secret Key for the One-Way Active
Measurement Protocol (OWAMP) and Two-Way Active
Measurement Protocol (TWAMP)", <a href="./rfc7717">RFC 7717</a>,
DOI 10.17487/RFC7717, December 2015,
<<a href="http://www.rfc-editor.org/info/rfc7717">http://www.rfc-editor.org/info/rfc7717</a>>.
[<a id="ref-RFC7821">RFC7821</a>] Mizrahi, T., "UDP Checksum Complement in the Network Time
Protocol (NTP)", <a href="./rfc7821">RFC 7821</a>, DOI 10.17487/RFC7821,
March 2016, <<a href="http://www.rfc-editor.org/info/rfc7821">http://www.rfc-editor.org/info/rfc7821</a>>.
[<a id="ref-ZeroChecksum">ZeroChecksum</a>]
Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums",
<a href="./rfc6936">RFC 6936</a>, DOI 10.17487/RFC6936, April 2013,
<<a href="http://www.rfc-editor.org/info/rfc6936">http://www.rfc-editor.org/info/rfc6936</a>>.
<span class="grey">Mizrahi Experimental [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Checksum Complement Usage Example</span>
Consider a session between an OWAMP sender and an OWAMP receiver, in
which the sender transmits test packets to the receiver.
The sender's software layer generates an OWAMP test packet with a
timestamp T and a UDP Checksum value U. The value of U is the
checksum of the UDP header, UDP payload, and pseudo-header. Thus,
U is equal to:
U = Const + checksum(T) (1)
Where "Const" is the checksum of all the fields that are covered by
the checksum, except the timestamp T.
Recall that the sender's software emits the test packet with a
Checksum Complement field, which is simply the last 2 octets of the
padding. In this example, it is assumed that the sender initially
assigns zero to these 2 octets.
The sender's timestamping engine updates the Timestamp field to the
accurate time, changing its value from T to T'. The sender also
updates the Checksum Complement field from zero to a new value C,
such that:
checksum(C) = checksum(T) - checksum(T') (2)
When the test packet is transmitted by the sender's timestamping
engine, the value of the checksum remains U as before:
U = Const + checksum(T) = Const + checksum(T) + checksum(T') -
checksum(T') = Const + checksum(T') + checksum(C) (3)
Thus, after the timestamping engine has updated the timestamp,
U remains the correct checksum of the packet.
When the test packet reaches the receiver, the receiver performs a
conventional UDP Checksum computation, and the computed value is U.
Since the Checksum Complement is part of the padding, the value of
checksum(C) is transparently included in the computation, as per
Equation (3), without requiring special treatment by the receiver.
<span class="grey">Mizrahi Experimental [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7820">RFC 7820</a> OWAMP and TWAMP Checksum Complement March 2016</span>
Acknowledgments
The author gratefully acknowledges Al Morton, Greg Mirsky, Steve
Baillargeon, Brian Haberman, and Spencer Dawkins for their helpful
comments.
Author's Address
Tal Mizrahi
Marvell
6 Hamada St.
Yokneam, 20692
Israel
Email: talmi@marvell.com
Mizrahi Experimental [Page 15]
</pre>
|
