draft-ietf-ippm-stamp-03.txt   draft-ietf-ippm-stamp-04.txt 
Network Working Group G. Mirsky Network Working Group G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Intended status: Standards Track G. Jun Intended status: Standards Track G. Jun
Expires: April 18, 2019 ZTE Corporation Expires: May 23, 2019 ZTE Corporation
H. Nydell H. Nydell
Accedian Networks Accedian Networks
R. Foote R. Foote
Nokia Nokia
October 15, 2018 November 19, 2018
Simple Two-way Active Measurement Protocol Simple Two-way Active Measurement Protocol
draft-ietf-ippm-stamp-03 draft-ietf-ippm-stamp-04
Abstract Abstract
This document describes a Simple Two-way Active Measurement Protocol This document describes a Simple Two-way Active Measurement Protocol
which enables measurement of both one-way and round-trip performance which enables the measurement of both one-way and round-trip
metrics like delay, delay variation, and packet loss. performance metrics like delay, delay variation, and packet loss.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 18, 2019. This Internet-Draft will expire on May 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Softwarization of Performance Measurement . . . . . . . . . . 3 3. Softwarization of Performance Measurement . . . . . . . . . . 3
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
4.1. Session-Sender Behavior and Packet Format . . . . . . . . 4 4.1. Session-Sender Behavior and Packet Format . . . . . . . . 4
4.1.1. Session-Sender Packet Format in Unauthenticated Mode 4 4.1.1. Session-Sender Packet Format in Unauthenticated Mode 4
4.1.2. Session-Sender Packet Format in Authenticated and 4.1.2. Session-Sender Packet Format in Authenticated Mode . 7
Encrypted Modes . . . . . . . . . . . . . . . . . . . 7
4.2. Session-Reflector Behavior and Packet Format . . . . . . 8 4.2. Session-Reflector Behavior and Packet Format . . . . . . 8
4.2.1. Session-Reflector Packet Format in Unauthenticated 4.2.1. Session-Reflector Packet Format in Unauthenticated
Mode . . . . . . . . . . . . . . . . . . . . . . . . 9 Mode . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Session-Reflector Packet Format in Authenticated and 4.2.2. Session-Reflector Packet Format in Authenticated Mode 10
Encrypted Modes . . . . . . . . . . . . . . . . . . . 10 4.3. Integrity and Confidentiality Protection in STAMP . . . . 12
4.3. Authentication and Encryption Operations on STAMP Packets 12
4.4. Interoperability with TWAMP Light . . . . . . . . . . . . 12 4.4. Interoperability with TWAMP Light . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
skipping to change at page 4, line 26 skipping to change at page 4, line 26
Figure 1: STAMP Reference Model Figure 1: STAMP Reference Model
4. Theory of Operation 4. Theory of Operation
STAMP Session-Sender transmits test packets toward STAMP Session- STAMP Session-Sender transmits test packets toward STAMP Session-
Reflector. STAMP Session-Reflector receives Session-Sender's packet Reflector. STAMP Session-Reflector receives Session-Sender's packet
and acts according to the configuration and optional control and acts according to the configuration and optional control
information communicated in the Session-Sender's test packet. STAMP information communicated in the Session-Sender's test packet. STAMP
defines two different test packet formats, one for packets defines two different test packet formats, one for packets
transmitted by the STAMP-Session-Sender and one for packets transmitted by the STAMP-Session-Sender and one for packets
transmitted by the STAMP-Session-Reflector. STAMP supports three transmitted by the STAMP-Session-Reflector. STAMP supports two
modes: unauthenticated, authenticated, and encrypted. modes: unauthenticated and authenticated. Unauthenticated STAMP test
Unauthenticated STAMP test packets are compatible on the wire with packets are compatible on the wire with unauthenticated TWAMP-Test
unauthenticated TWAMP-Test [RFC5357] packet formats. [RFC5357] packet formats.
By default, STAMP uses symmetrical packets, i.e., size of the packet By default, STAMP uses symmetrical packets, i.e., size of the packet
transmitted by Session-Reflector equals the size of the packet transmitted by Session-Reflector equals the size of the packet
received by the Session-Reflector. received by the Session-Reflector.
4.1. Session-Sender Behavior and Packet Format 4.1. Session-Sender Behavior and Packet Format
4.1.1. Session-Sender Packet Format in Unauthenticated Mode 4.1.1. Session-Sender Packet Format in Unauthenticated Mode
Because STAMP supports symmetrical test packets, STAMP Session-Sender Because STAMP supports symmetrical test packets, STAMP Session-Sender
packet has a minimum size of 44 octets in unauthenticated mode, see packet has a minimum size of 44 octets in unauthenticated mode, see
Figure 2, and 48 octets in authenticated or encrypted modes, see Figure 2, and 48 octets in the authenticated mode, see Figure 4.
Figure 4.
For unauthenticated mode: For unauthenticated mode:
0 1 2 3 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 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 | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
skipping to change at page 7, line 15 skipping to change at page 7, line 15
o Type field is two octets long. The value of the Type field is the o Type field is two octets long. The value of the Type field is the
codepoint allocated by IANA Section 5 that identifies data in the codepoint allocated by IANA Section 5 that identifies data in the
Value field. Value field.
o Length is two octets long field, and its value is the length of o Length is two octets long field, and its value is the length of
the Value field in octets. the Value field in octets.
o Value field contains the application specific information. The o Value field contains the application specific information. The
length of the Value field MUST be four octets aligned. length of the Value field MUST be four octets aligned.
4.1.2. Session-Sender Packet Format in Authenticated and Encrypted 4.1.2. Session-Sender Packet Format in Authenticated Mode
Modes
For authenticated and encrypted modes: For authenticated mode:
0 1 2 3 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 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 | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 50 skipping to change at page 7, line 49
~ Value ~ ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Comp.MBZ ~ ~ Comp.MBZ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: STAMP Session-Sender test packet format in authenticated or Figure 4: STAMP Session-Sender test packet format in authenticated
encrypted modes mode
The field definitions are the same as the unauthenticated mode, The field definitions are the same as the unauthenticated mode,
listed in Section 4.1.1. Also, Comp.MBZ field is variable length listed in Section 4.1.1. Also, Comp.MBZ field is variable length
field to align the packet on 16 octets boundary. Also, the packet field to align the packet on 16 octets boundary. Also, the packet
includes a key-hashed message authentication code (HMAC) ([RFC2104]) includes a key-hashed message authentication code (HMAC) ([RFC2104])
hash at the end of the PDU. hash at the end of the PDU.
The STAMP Session-Sender-packet format (Figure 4) is the same in
authenticated and encrypted modes. The encryption and authentication
operations are, however, different and protect the data as follows:
in the authenticated mode the Sequence Number is protected while
the Timestamp and the Error Estimate are sent in clear text;
in encrypted mode all fields, including the timestamp and Error
Estimate, are protected to provide maximum data confidentiality
and integrity protection.
Sending the Timestamp in clear text in authenticated mode allows more
consistent reading of time by a Session-Sender on the transmission of
the test packet. Reading of the time in encrypted mode must be
followed by its encryption which introduces variable delay thus
affecting calculated timing metrics.
4.2. Session-Reflector Behavior and Packet Format 4.2. Session-Reflector Behavior and Packet Format
The Session-Reflector receives the STAMP test packet, verifies it, The Session-Reflector receives the STAMP test packet, verifies it,
prepares and transmits the reflected test packet. prepares and transmits the reflected test packet.
Two modes of STAMP Session-Reflector characterize the expected Two modes of STAMP Session-Reflector characterize the expected
behavior and, consequently, performance metrics that can be measured: behavior and, consequently, performance metrics that can be measured:
o Stateless - STAMP Session-Reflector does not maintain test state o Stateless - STAMP Session-Reflector does not maintain test state
and will reflect the received sequence number without and will reflect the received sequence number without
skipping to change at page 10, line 26 skipping to change at page 10, line 22
o Session-Sender Sequence Number, Session-Sender Timestamp, and o Session-Sender Sequence Number, Session-Sender Timestamp, and
Session-Sender Error Estimate are copies of the corresponding Session-Sender Error Estimate are copies of the corresponding
fields in the STAMP test packet sent by the Session-Sender. fields in the STAMP test packet sent by the Session-Sender.
o Session-Sender TTL is one octet long field, and its value is the o Session-Sender TTL is one octet long field, and its value is the
copy of the TTL field from the received STAMP test packet. copy of the TTL field from the received STAMP test packet.
o Packet Padding (reflected) is an optional variable length field. o Packet Padding (reflected) is an optional variable length field.
The length of the Packet Padding (reflected) field MUST be equal The length of the Packet Padding (reflected) field MUST be equal
to the value of the Server Octets field (Figure 2). If the value to the value of the Server Octets field (Figure 2). If the value
is non-zero, the Session-Reflector copies octets starting with the is non-zero, the Session-Reflector MUST copy number of octets
Server Octets field. equal to the value of Server Octets field starting with the Server
Octets field.
o Comp.MBZ is variable length field used to achieve alignment on a o Comp.MBZ is variable length field used to achieve alignment on a
word boundary. Thus the length of Comp.MBZ field may be only 0, word boundary. Thus the length of Comp.MBZ field may be only 0,
1, 2 or 3 octets. The value of the field MUST be zeroed on 1, 2 or 3 octets. The value of the field MUST be zeroed on
transmission and ignored on receipt. transmission and ignored on receipt.
4.2.2. Session-Reflector Packet Format in Authenticated and Encrypted 4.2.2. Session-Reflector Packet Format in Authenticated Mode
Modes
For authenticated and encrypted modes: For the authenticated mode:
0 1 2 3 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 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 | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) | | MBZ (12 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 44 skipping to change at page 11, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Comp.MBZ ~ ~ Comp.MBZ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: STAMP Session-Reflector test packet format in authenticated Figure 6: STAMP Session-Reflector test packet format in authenticated
or encrypted modes mode
The field definitions are the same as the unauthenticated mode, The field definitions are the same as the unauthenticated mode,
listed in Section 4.2.1. Additionally, the packet MAY include listed in Section 4.2.1. Additionally, the packet MAY include
Comp.MBZ field is variable length field to align the packet on 16 Comp.MBZ field is variable length field to align the packet on 16
octets boundary. Also, STAMP Session-Reflector test packet format in octets boundary. Also, STAMP Session-Reflector test packet format in
authenticated or encrypted modes includes a key (HMAC) ([RFC2104]) authenticated mode includes a key (HMAC) ([RFC2104]) hash at the end
hash at the end of the PDU. of the PDU.
4.3. Authentication and Encryption Operations on STAMP Packets 4.3. Integrity and Confidentiality Protection in STAMP
STAMP uses a two-pronged approach to protect the confidentiality and To provide integrity protection, each STAMP message is being
integrity of the measurement information. In authenticated and authenticated by adding Hashed Message Authentication Code (HMAC).
encrypted modes each STAMP message is being authenticated by adding STAMP uses HMAC-SHA-256 truncated to 128 bits (similarly to the use
Hashed Message Authentication Code (HMAC). STAMP uses HMAC-SHA1 of it in IPSec defined in [RFC4868]); hence the length of the HMAC
truncated to 128 bits; hence the length of the HMAC field is 16 field is 16 octets. HMAC uses own key and the definition of the
octets. HMAC uses its own key. Mechanism to distribute the HMAC key mechanism to distribute the HMAC key is outside the scope of this
is outside the scope of this specification. One example is to use an specification. One example is to use an orchestrator to configure
orchestrator to configure HMAC key based on STAMP YANG data model HMAC key based on STAMP YANG data model [I-D.ietf-ippm-stamp-yang].
[I-D.ietf-ippm-stamp-yang]. HMAC MUST be verified as early as HMAC MUST be verified as early as possible to avoid using or
possible to avoid using or propagating corrupted data. propagating corrupted data.
In the authenticated mode only the first 16 octets block of the STAMP If confidentiality protection for STAMP is required, encryption at
test packet (Figure 6 and Figure 6) is encrypted using AES Electronic the higher level MUST be used.
Codebook (ECB) mode. In the encrypted mode, the whole STAMP test
packet excluding the HMAC field is encrypted. STAMP using AES-CBC
(Cipher Block Chaining) mode. Distribution and management of AES key
are outside the scope of this specification.
4.4. Interoperability with TWAMP Light 4.4. Interoperability with TWAMP Light
One of the essential requirements to STAMP is the ability to One of the essential requirements to STAMP is the ability to
interwork with TWAMP Light device. There are two possible interwork with TWAMP Light device. There are two possible
combinations for such use case: combinations for such use case:
o STAMP Session-Sender with TWAMP Light Session-Reflector; o STAMP Session-Sender with TWAMP Light Session-Reflector;
o TWAMP Light Session-Sender with STAMP Session-Reflector. o TWAMP Light Session-Sender with STAMP Session-Reflector.
skipping to change at page 13, line 16 skipping to change at page 13, line 12
reflected packet of the symmetrical size. The Session-Reflector MUST reflected packet of the symmetrical size. The Session-Reflector MUST
use the default format for its timestamps - NTP. use the default format for its timestamps - NTP.
5. IANA Considerations 5. IANA Considerations
This document doesn't have any IANA action. This section may be This document doesn't have any IANA action. This section may be
removed before the publication. removed before the publication.
6. Security Considerations 6. Security Considerations
Use of HMAC in authenticated and encrypted modes may be used to Use of HMAC-SHA-256 in the authenticated mode protects the data
simultaneously verify both the data integrity and the authentication integrity of the STAMP test packets.
of the STAMP test packets.
7. Acknowledgments 7. Acknowledgments
TBD Authors express their appreciation to Jose Ignacio Alvarez-Hamelin
and Brian Weis for their great insights into the security and
identity protection, and the most helpful and practical suggestions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[BBF.TR-390] [BBF.TR-390]
"Performance Measurement from IP Edge to Customer "Performance Measurement from IP Edge to Customer
Equipment using TWAMP Light", BBF TR-390, May 2017. Equipment using TWAMP Light", BBF TR-390, May 2017.
[I-D.ietf-ippm-port-twamp-test] [I-D.ietf-ippm-port-twamp-test]
Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port
Assignments", draft-ietf-ippm-port-twamp-test-02 (work in Assignments", draft-ietf-ippm-port-twamp-test-03 (work in
progress), October 2018. progress), November 2018.
[IEEE.1588.2008] [IEEE.1588.2008]
"Standard for a Precision Clock Synchronization Protocol "Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems", for Networked Measurement and Control Systems",
IEEE Standard 1588, March 2008. IEEE Standard 1588, March 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 14, line 41 skipping to change at page 14, line 36
[I-D.ietf-ippm-stamp-yang] [I-D.ietf-ippm-stamp-yang]
Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active
Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- Measurement Protocol (STAMP) Data Model", draft-ietf-ippm-
stamp-yang-02 (work in progress), September 2018. stamp-yang-02 (work in progress), September 2018.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
ZTE Corp. ZTE Corp.
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Guo Jun Guo Jun
ZTE Corporation ZTE Corporation
68# Zijinghua Road 68# Zijinghua Road
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
 End of changes. 25 change blocks. 
71 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/