draft-ietf-mboned-ambi-00.txt		draft-ietf-mboned-ambi-01.txt
	Mboned J. Holland		Mboned J. Holland
	Internet-Draft K. Rose		Internet-Draft K. Rose
	Intended status: Standards Track Akamai Technologies, Inc.		Intended status: Standards Track Akamai Technologies, Inc.
	Expires: September 11, 2020 March 10, 2020		Expires: May 3, 2021 October 30, 2020
	Asymmetric Manifest Based Integrity		Asymmetric Manifest Based Integrity
	draft-ietf-mboned-ambi-00		draft-ietf-mboned-ambi-01
	Abstract		Abstract
	This document defines Asymmetric Manifest-Based Integrity (AMBI).		This document defines Asymmetric Manifest-Based Integrity (AMBI).
	AMBI allows each receiver or forwarder of a stream of multicast		AMBI allows each receiver or forwarder of a stream of multicast
	packets to check the integrity of the contents of each packet in the		packets to check the integrity of the contents of each packet in the
	data stream. AMBI operates by passing cryptographically verifiable		data stream. AMBI operates by passing cryptographically verifiable
	hashes of the data packets inside manifest messages, and sending the		hashes of the data packets inside manifest messages, and sending the
	manifests over authenticated out-of-band communication channels.		manifests over authenticated out-of-band communication channels.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 September 11, 2020.		This Internet-Draft will expire on May 3, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Comparison with TESLA . . . . . . . . . . . . . . . . . . 4		1.1. Comparison with TESLA . . . . . . . . . . . . . . . . . . 4
	1.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
			1.4. Notes for Contributors and Reviewers . . . . . . . . . . 5
			1.4.1. Venues for Contribution and Discussion . . . . . . . 5
	2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5		2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Buffering and Validation Windows . . . . . . . . . . . . 6		2.2. Buffering and Validation Windows . . . . . . . . . . . . 6
	2.2.1. Inter-packet Gap . . . . . . . . . . . . . . . . . . 7		2.2.1. Inter-packet Gap . . . . . . . . . . . . . . . . . . 8
	2.3. Packet Digests . . . . . . . . . . . . . . . . . . . . . 8		2.3. Packet Digests . . . . . . . . . . . . . . . . . . . . . 8
	2.3.1. Digest Profile . . . . . . . . . . . . . . . . . . . 8		2.3.1. Digest Profile . . . . . . . . . . . . . . . . . . . 8
	2.3.2. Pseudoheader . . . . . . . . . . . . . . . . . . . . 11		2.3.2. Pseudoheader . . . . . . . . . . . . . . . . . . . . 10
	2.4. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 12		2.4. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 12
	2.4.1. Manifest Layout . . . . . . . . . . . . . . . . . . . 13		2.4.1. Manifest Layout . . . . . . . . . . . . . . . . . . . 12
	2.5. Transitioning to Other Manifest Streams . . . . . . . . . 14		2.5. Transitioning to Other Manifest Streams . . . . . . . . . 13
	3. Transport Considerations . . . . . . . . . . . . . . . . . . 15		3. Transport Considerations . . . . . . . . . . . . . . . . . . 14
	3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15		3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.2. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 15		3.2. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.3. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 15		3.3. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.4. DTLS + FECFRAME . . . . . . . . . . . . . . . . . . . . . 16		3.4. DTLS + FECFRAME . . . . . . . . . . . . . . . . . . . . . 15
	4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16		4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 16		5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 16		5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 15
	5.2. Module . . . . . . . . . . . . . . . . . . . . . . . . . 16		5.2. Module . . . . . . . . . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	6.1. The YANG Module Names Registry . . . . . . . . . . . . . 19		6.1. The YANG Module Names Registry . . . . . . . . . . . . . 18
	6.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 19		6.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 18
			6.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 19		7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	7.1. Predictable Packets . . . . . . . . . . . . . . . . . . . 19		7.1. Predictable Packets . . . . . . . . . . . . . . . . . . . 19
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Normative References . . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . 19
	9.2. Informative References . . . . . . . . . . . . . . . . . 21		9.2. Informative References . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	Multicast transport poses security problems that are not easily		Multicast transport poses security problems that are not easily
	addressed by the same security mechanisms used for unicast transport.		addressed by the same security mechanisms used for unicast transport.
	The "Introduction" sections of the documents describing TESLA		The "Introduction" sections of the documents describing TESLA
	[RFC4082], and TESLA in SRTP [RFC4383], and TESLA with ALC and NORM		[RFC4082], and TESLA in SRTP [RFC4383], and TESLA with ALC and NORM
	[RFC5776] present excellent overviews of the challenges unique to		[RFC5776] present excellent overviews of the challenges unique to
	multicast authentication, briefly summarized here:		multicast authentication, briefly summarized here:
	skipping to change at page 3, line 50 ¶		skipping to change at page 4, line 7 ¶
	that a UDP-based protocol might drop or reorder manifests while still		that a UDP-based protocol might drop or reorder manifests while still
	providing authentication.		providing authentication.
	Upon successful verification of a manifest and receipt of any subset		Upon successful verification of a manifest and receipt of any subset
	of the corresponding data packets, the receiver has proof of the		of the corresponding data packets, the receiver has proof of the
	integrity of the contents of the data packets that are listed in the		integrity of the contents of the data packets that are listed in the
	manifest.		manifest.
	Authenticating the integrity of the data packets depends on:		Authenticating the integrity of the data packets depends on:
	o the authenticity of the manifests; and		o the authenticity of the manifests
	o the authenticity of the digest profile used for construction of		o the authenticity of the digest profile used for construction of
	the packet digests; and		the packet digests
	o the difficulty of generating a collision for the packet digests		o the difficulty of generating a collision for the packet digests
	contained in the manifest.		contained in the manifest.
	This document defines a YANG [RFC7950] module that augments the DORMS		This document defines a YANG [RFC7950] module that augments the DORMS
	[I-D.draft-jholland-mboned-dorms-02] YANG module to provide a way to		[I-D.draft-ietf-mboned-dorms-00] YANG module to provide a way to
	communicate a digest profile, described in Section 2.3.1, for		communicate a digest profile, described in Section 2.3.1, for
	construction of the packet digests, described in Section 2.3. When		construction of the packet digests, described in Section 2.3. When
	obtaining the digest profile by using DORMS, the authenticity of the		obtaining the digest profile by using DORMS, the authenticity of the
	data stream relies on a trust relationship with the DORMS server,		data stream relies on a trust relationship with the DORMS server,
	since that anchors the authenticity of the digest profile for		since that anchors the authenticity of the digest profile for
	constructing packet digests.		constructing packet digests.
	1.1. Comparison with TESLA		1.1. Comparison with TESLA
	AMBI and TESLA [RFC4082] and [RFC5776] attempt to achieve a similar		AMBI and TESLA [RFC4082] and [RFC5776] attempt to achieve a similar
	goal of authenticating the integrity of streams of multicast packets.		goal of authenticating the integrity of streams of multicast packets.
	AMBI imposes a higher overhead, as measured in the amount of extra		AMBI imposes a higher overhead, as measured in the amount of extra
	data required, than TESLA imposes. In exchange, AMBI provides non-		data required, than TESLA imposes. In exchange, AMBI relaxes the
	repudiation (which TESLA does not), and relaxes the requirement for		requirement for establishing an upper bound on clock synchronization
	establishing an upper bound on clock synchronization between sender		between sender and receiver, and allows for the use case of
	and receiver.		authenticating multicast traffic before forwarding it through the
			network, while also allowing receivers to authenticate the same
	This tradeoff enables new capabilities for AMBI, relative to TESLA.		traffic. By contrast, this is not possible with TESLA because the
	In particular, when receiving multicast traffic from an untrusted		data packets can't be authenticated until a key is disclosed, so
	transit network, AMBI can be used by a middle box to authenticate		either the middlebox has to forward data packets without first
	packets from a trusted source before forwarding traffic through the		authenticating them so that the receiver has them prior to key
	network, and the receiver also can separately authenticate the		disclosure, or the middlebox has to hold packets until the key is
	packets it receives.		disclosed, at which point the receiver can no longer establish their
			authenticity.
	This use case is not possible with TESLA because the data packets
	can't be authenticated until a key is disclosed, so either the
	middlebox has to forward data packets without first authenticating
	them, so that the receiver has them prior to key disclosure, or the
	middlebox has to hold packets until the key is disclosed, at which
	point the receiver can no longer establish their authenticity.
	The other new capability is that because AMBI provides authentication		The other new capability is that because AMBI provides authentication
	information out of band, authentication can be retrofitted into some		information out of band, authentication can be retrofitted into some
	pre-existing deployments without changing the protocol of the data		pre-existing deployments without changing the protocol of the data
	packets, under some restrictions outlined in Section 7. By contrast,		packets, under some restrictions outlined in Section 7. By contrast,
	TESLA requires a MAC to be added to each authenticated message.		TESLA requires a MAC to be added to each authenticated message.
	1.2. Threat Model		1.2. Threat Model
	TBD: Summarize the applicable threat model this protects against. A		TBD: Summarize the applicable threat model this protects against. A
	diagram plus a cleaned-up version of the on-list explanation here is		diagram plus a cleaned-up version of the on-list explanation here is
	probably appropriate: https://mailarchive.ietf.org/arch/msg/mboned/		probably appropriate: https://mailarchive.ietf.org/arch/msg/mboned/
	CG9FLjPwuno3MtvYvgNcD5p69I4/		CG9FLjPwuno3MtvYvgNcD5p69I4/
			Reference [RFC3552] https://tools.ietf.org/html/rfc3552#section-3
	1.3. Terminology		1.3. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119] and [RFC8174] when, and only when, they appear in all		[RFC2119] and [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
			1.4. Notes for Contributors and Reviewers
			Note to RFC Editor: Please remove this section and its subsections
			before publication.
			This section is to provide references to make it easier to review the
			development and discussion on the draft so far.
			1.4.1. Venues for Contribution and Discussion
			This document is in the Github repository at:
			https://github.com/GrumpyOldTroll/ietf-dorms-cluster
			Readers are welcome to open issues and send pull requests for this
			document.
			Please note that contributions may be merged and substantially
			edited, and as a reminder, please carefully consider the Note Well
			before contributing: https://datatracker.ietf.org/submit/note-well/
			Substantial discussion of this document should take place on the
			MBONED working group mailing list (mboned@ietf.org).
			o Join: https://www.ietf.org/mailman/listinfo/mboned
			o Search: https://mailarchive.ietf.org/arch/browse/mboned/
	2. Protocol Operation		2. Protocol Operation
	2.1. Overview		2.1. Overview
	In order to authenticate a data packet, AMBI receivers need to hold		In order to authenticate a data packet, AMBI receivers need to hold
	these three pieces of information at the same time:		these three pieces of information at the same time:
	o the data packet; and		o the data packet
	o an authenticated manifest containing the packet digest for the		o an authenticated manifest containing the packet digest for the
	data packet; and		data packet
	o a digest profile defining the transformation from the data packet		o a digest profile defining the transformation from the data packet
	to its packet digest.		to its packet digest
	The manifests are delivered as a stream of manifests over an		The manifests are delivered as a stream of manifests over an
	authenticated data channel. Manifest contents MUST be authenticated		authenticated data channel. Manifest contents MUST be authenticated
	before they can be used to authenticate data packets.		before they can be used to authenticate data packets.
	The manifest stream is composed of an ordered sequence of manifests		The manifest stream is composed of an ordered sequence of manifests
	that each contain an ordered sequence of packet digests,		that each contain an ordered sequence of packet digests,
	corresponding to the original packets as sent from their origin, in		corresponding to the original packets as sent from their origin, in
	the same order.		the same order.
	Note that a manifest contains potentially many packet digests, and		Note that a manifest contains potentially many packet digests, and
	its size can be tuned to fit within a convenient PDU (Protocol Data		its size can be tuned to fit within a convenient PDU (Protocol Data
	Unit) of the manifest transport stream, so that usually, many packet		Unit) of the manifest transport stream. By doing so, many packet
	digests for the multicast data stream can be delivered per packet of		digests for the multicast data stream can be delivered per packet of
	the manifest transport. The intent is that even with unicast-based		the manifest transport. The intent is that even with unicast-based
	manifest transport, multicast-style efficiencies of scale can still		manifest transport, multicast-style efficiencies of scale can still
	be realized, with only a relatively small unicast overhead, when		be realized with only a relatively small unicast overhead, when
	manifests use a unicast transport.		manifests use a unicast transport.
	2.2. Buffering and Validation Windows		2.2. Buffering and Validation Windows
	Using different communication channels for the manifest stream and		Using different communication channels for the manifest stream and
	the data stream introduces a possibility of desynchronization in the		the data stream introduces a possibility of desynchronization in the
	timing of the received data between the different channels, so		timing of the received data between the different channels, so
	receivers hold data packets and packet digests from the manifest		receivers hold data packets and packet digests from the manifest
	stream in buffers for some duration while awaiting the arrival of		stream in buffers for some duration while awaiting the arrival of
	their counterparts.		their counterparts.
	skipping to change at page 7, line 22 ¶		skipping to change at page 8, line 5 ¶
	Receivers SHOULD follow the recommendations for hold times provided		Receivers SHOULD follow the recommendations for hold times provided
	by the sender, subject to their capabilities and any administratively		by the sender, subject to their capabilities and any administratively
	configured limits on buffer sizes at the receiver.		configured limits on buffer sizes at the receiver.
	However receivers MAY deviate from the values recommended by the		However receivers MAY deviate from the values recommended by the
	sender for a variety of reasons. Decreasing the buffering durations		sender for a variety of reasons. Decreasing the buffering durations
	recommended by the server increases the risk of losing packets, but		recommended by the server increases the risk of losing packets, but
	can be an appropriate tradeoff for specific network conditions and		can be an appropriate tradeoff for specific network conditions and
	hardware constraints on some devices.		hardware constraints on some devices.
	TBD: should there be any reordering restrictions above and beyond the
	timing constraints?
	2.2.1. Inter-packet Gap		2.2.1. Inter-packet Gap
	It's RECOMMENDED that middle boxes forwarding buffered data packets		It's RECOMMENDED that middle boxes forwarding buffered data packets
	preserve the inter-packet gap between packets, and that receiving		preserve the inter-packet gap between packets in the same data
	libraries provide mechanisms to expose the network arrival times of		stream, and that receiving libraries that perform AMBI-based
	packets to applications.		authentication provide mechanisms to expose the network arrival times
			of packets to applications.
	The purpose for this recommendation is to preserve the capability of		The purpose for this recommendation is to preserve the capability of
	receivers to use techniques for available bandwidth detection or		receivers to use techniques for available bandwidth detection or
	network congestion based on observation of packet times. Examples of		network congestion based on observation of packet times. Examples of
	such techniques include paced chirping and pathrate.		such techniques include paced chirping and pathrate.
	Note that this recommendation SHOULD NOT prevent the transmission of		Note that this recommendation SHOULD NOT prevent the transmission of
	an authenticated packet because the prior packet is unauthenticated.		an authenticated packet because the prior packet is unauthenticated.
	This recommendation only asks implementations to delay the		This recommendation only asks implementations to delay the
	transmission of an authenticated packet to correspond to the		transmission of an authenticated packet to correspond to the
	skipping to change at page 8, line 37 ¶		skipping to change at page 9, line 17 ¶
	hash value is the packet digest.		hash value is the packet digest.
	TBD: there should also be a way to specify that only packets to a		TBD: there should also be a way to specify that only packets to a
	specific UDP port are applicable. I think this is not quite right		specific UDP port are applicable. I think this is not quite right
	today and probably should be done with a grouping in the yang model,		today and probably should be done with a grouping in the yang model,
	so that the profile appears either inside a "protocol" container		so that the profile appears either inside a "protocol" container
	inside the (S,G) or inside the udp-stream inside the "protocol", but		inside the (S,G) or inside the udp-stream inside the "protocol", but
	am not sure. Follow-up on this after the first reference		am not sure. Follow-up on this after the first reference
	implementation...		implementation...
			TBD: As recommended by https://tools.ietf.org/html/rfc7696#section-
			2.2 [1], a companion document containing the mandatory-to-implement
			cipher suite should also be published separately and referenced by
			this document.
	2.3.1.1. Payload Type		2.3.1.1. Payload Type
	2.3.1.1.1. UDP vs. IP payload validation		2.3.1.1.1. UDP vs. IP payload validation
	When the digest profile indicates that UDP payloads are validated,		When the digest profile indicates that UDP payloads are validated,
	the IP protocol for the packets MUST be UDP (0x11) and the payload		the IP protocol for the packets MUST be UDP (0x11) and the payload
	used for calculating the packet digest includes only the UDP payload,		used for calculating the packet digest includes only the UDP payload,
	with length as the number of UDP payload octets, as calculated by		with length as the number of UDP payload octets, as calculated by
	subtracting the size of the UDP header from the UDP payload length.		subtracting the size of the UDP header from the UDP payload length.
	skipping to change at page 9, line 32 ¶		skipping to change at page 10, line 16 ¶
	to have the capability to authenticate such packets.		to have the capability to authenticate such packets.
	Another example: some services might need to authenticate the UDP		Another example: some services might need to authenticate the UDP
	options [I-D.ietf-tsvwg-udp-options]. When using the UDP payload,		options [I-D.ietf-tsvwg-udp-options]. When using the UDP payload,
	the UDP options would not be part of the authenticated payload, but		the UDP options would not be part of the authenticated payload, but
	would be included when using the IP payload type.		would be included when using the IP payload type.
	Lastly, since (S,G) subscription operates at the IP layer, it's		Lastly, since (S,G) subscription operates at the IP layer, it's
	possible that some non-UDP protocols will need to be authenticated.		possible that some non-UDP protocols will need to be authenticated.
	2.3.1.2. TBD: Packet contents?
	TBD: Determine whether we need to support packet contents in the
	packet digest. If so, add to above list in Section 2.3.1:
	o A set of bits from the packet contents (potentially empty)
	The packet contents are a sequence of bits composed from a sequence
	of fixed bit (offset, length) pairs, as specified in xxxxxx. A
	useful choice for packet contents is to use sequence numbers in the
	application level protocol, such as with RTP [RFC3550], but any
	contents from the packet with a fixed bit offset and length can be
	used.
	Providing variable packet contents in the packet digest increases the
	difficulty of attacking the hash by limiting the scope of legitimate
	data packets that can be matched when attempting to generate a hash
	collision.
	The basic idea is to put an encoding here so that for example the RTP
	sequence number or the sequence number in an Authentication Header
	can be provided here in bulk (you give "value starts at bit 80 and is
	16 bits long unsigned and increases by 1 per packet for the packets
	in the manifest with starting value 10", indicating that the 100
	packets in the manifest have values 10-110 in their contents at the
	given location. Now those contents are prepended to the packet
	digest, and can be verified against the packets, as well as the hash
	of the contents).
	For packet streams without a sequence number, we can instead
	incorporate a few high-entropy bits from the packet contents and NOT
	provide the value as a sequence number, but rather incorporate it in
	the digest values themselves. (Is this useful?)
	Before defining this, I want to calculate how much overhead it buys
	us- how much can we truncate a good hash algorithm if we use this to
	add collision resistance? Might not be worthwhile, it's a
	significant increase in complexity. -jake 2019-08-31
	If we need it, tentative addition to yang for the data profile looks
	like:
	list packet-contents {
	key offset;
	description "contents from the packet for the packet
	digest";
	leaf offset {
	type uint16;
	mandatory true;
	description "offset of the contents, in number of bits";
	}
	leaf length {
	type uint16;
	mandatory true;
	description "length of the contents, in number of bits";
	}
	leaf manifest-delivery {
	type enumeration {
	enum sequence;
	enum digest;
	}
	mandatory true;
	description "the way these content bits are delivered in
	the manifest";
	}
	}
	The manifest-delivery would indicate whether the bits are a sequence
	number (in which case a section for a manifest with a start+step
	would be added ahead of the digests), or digest (indicating the bits
	appear inside each digest, ahead of the hash), and they would prepend
	in order to the packet digest, with sequence number bits inserted at
	the right bit location for the digest, based on earlier-appearing
	values, if any.
	2.3.2. Pseudoheader		2.3.2. Pseudoheader
	When calculating the hash for the packet digest, the hash algorithm		When calculating the hash for the packet digest, the hash algorithm
	is applied to a pseudoheader followed by the payload from the packet.		is applied to a pseudoheader followed by the payload from the packet.
	The complete sequence of octets used to calculate the hash is		The complete sequence of octets used to calculate the hash is
	structured as follows:		structured as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 15, line 24 ¶		skipping to change at page 14, line 24 ¶
	TBD: extend the 'manifest-transport' in the YANG model to make an		TBD: extend the 'manifest-transport' in the YANG model to make an
	extensible mechanism to advertise different transport options for		extensible mechanism to advertise different transport options for
	receiving manifest streams.		receiving manifest streams.
	TBD: add ALTA to the list when and if it gets further along		TBD: add ALTA to the list when and if it gets further along
	[I-D.draft-krose-mboned-alta-01]. Sending an authenticatable		[I-D.draft-krose-mboned-alta-01]. Sending an authenticatable
	multicast stream (instead of the below unicast-based proposals) is a		multicast stream (instead of the below unicast-based proposals) is a
	worthwhile goal, else a 1% unicast authentication overhead becomes a		worthwhile goal, else a 1% unicast authentication overhead becomes a
	new unicast limit to the scalability.		new unicast limit to the scalability.
			TBD: add a recommendation about scalability, like with DORMS, when
			using a unicast hash stream. CDN or other kind of fanout solution
			that can scale the delivery, and still generally hit the time window.
	3.2. HTTPS		3.2. HTTPS
	This document defines a new media type 'application/ambi' for use		This document defines a new media type 'application/ambi' for use
	with HTTPS.		with HTTPS.
	An HTTPS stream carrying the 'application/ambi' media type is		An HTTPS stream carrying the 'application/ambi' media type is
	composed of a sequence of binary AMBI manifests. It is RECOMMENDED		composed of a sequence of binary AMBI manifests. It is RECOMMENDED
	to use Chunked encoding.		to use Chunked encoding.
	Complete packet Digests from partially received manifests MAY be used		Complete packet Digests from partially received manifests MAY be used
	skipping to change at page 15, line 48 ¶		skipping to change at page 15, line 4 ¶
	TBD: DTLS [RFC6347] can provide authentication for datagrams, so if		TBD: DTLS [RFC6347] can provide authentication for datagrams, so if
	manifests can be constructed to fit within datagrams, it is an		manifests can be constructed to fit within datagrams, it is an
	appropriate choice. (IPSec is similar-worth adding as an option?).		appropriate choice. (IPSec is similar-worth adding as an option?).
	This option provides no native redundancy or retransmission, but		This option provides no native redundancy or retransmission, but
	packet digests can be repeated in different manifests to provide some		packet digests can be repeated in different manifests to provide some
	resilience to loss. Lost manifests that result in the loss of blocks		resilience to loss. Lost manifests that result in the loss of blocks
	of packet digests can be expensive, since they would make received		of packet digests can be expensive, since they would make received
	data packets unauthenticatable. TBD: should we therefore not support		data packets unauthenticatable. TBD: should we therefore not support
	this case?		this case? (probably still worthwhile-the manifests can still contain
			redundant hashes)
	3.4. DTLS + FECFRAME		3.4. DTLS + FECFRAME
	DTLS for manifests that do not fit into single-packet payloads can		DTLS for manifests that do not fit into single-packet payloads can
	still be delivered by using FECFRAME [RFC6363], particularly Reed-		still be delivered by using FECFRAME [RFC6363], particularly Reed-
	Solomon [RFC6865] or possibly Raptor [RFC6681]. This has some		Solomon [RFC6865] or possibly Raptor [RFC6681]. This has some
	advantages compared to HTTPS because of the absence of HOL-blocking,		advantages compared to HTTPS because of the absence of HOL-blocking,
	while providing for tunable redundancy. This has some advantages		while providing for tunable redundancy. This has some advantages
	relative to DTLS because of overhead reduction and non-integer		relative to DTLS because of overhead reduction and non-integer
	redundancy tunability (e.g. 1.5 becomes a viable redundancy factor).		redundancy tunability (e.g. 1.5 becomes a viable redundancy factor).
	skipping to change at page 16, line 26 ¶		skipping to change at page 15, line 28 ¶
	4. Examples		4. Examples
	TBD: walk through some examples as soon as we have a build running.		TBD: walk through some examples as soon as we have a build running.
	Likely to need some touching up.		Likely to need some touching up.
	5. YANG Module		5. YANG Module
	5.1. Tree Diagram		5.1. Tree Diagram
			The tree diagram below follows the notation defined in [RFC8340].
	module: ietf-ambi		module: ietf-ambi
	augment /dorms:metadata/dorms:sender/dorms:group/dorms:udp-stream:		augment /dorms:metadata/dorms:sender/dorms:group/dorms:udp-stream:
	+--rw manifest-stream* [id]		+--rw manifest-stream* [id]
	+--rw id uint32		+--rw id uint32
	+--rw manifest-transport* inet:uri		+--rw manifest-transport* inet:uri
	+--rw hash-algorithm iha:hash-algorithm-type		+--rw hash-algorithm iha:hash-algorithm-type
	+--rw payload-type enumeration		+--rw payload-type enumeration
	+--rw data-hold-time-ms? uint32		+--rw data-hold-time-ms? uint32
	+--rw digest-hold-time-ms? uint32		+--rw digest-hold-time-ms? uint32
	5.2. Module		5.2. Module
	<CODE BEGINS> file ietf-ambi@2020-03-10.yang		<CODE BEGINS> file ietf-ambi@2020-10-31.yang
	module ietf-ambi {		module ietf-ambi {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-ambi";		namespace "urn:ietf:params:xml:ns:yang:ietf-ambi";
	prefix "ambi";		prefix "ambi";
	import ietf-dorms {		import ietf-dorms {
	prefix "dorms";		prefix "dorms";
	reference "I-D.jholland-mboned-dorms";		reference "I-D.jholland-mboned-dorms";
	}		}
	import ietf-inet-types {		import ietf-inet-types {
	prefix "inet";		prefix "inet";
	reference "RFC6991 Section 4";		reference "RFC6991 Section 4";
	}		}
	import iana-hash-algs {		import iana-hash-algs {
	prefix "iha";		prefix "iha";
	reference "draft-ietf-netconf-crypto-types";		reference "draft-ietf-netconf-crypto-types";
	}		}
	organization "IETF";		organization "IETF";
	contact		contact
	"Author: Jake Holland		"Author: Jake Holland
	<mailto:jholland@akamai.com>		<mailto:jholland@akamai.com>
	";		";
	description		description
	"Copyright (c) 2019 IETF Trust and the persons identified as		"Copyright (c) 2019 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(https://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC XXXX
	(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself		(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
	for full legal notices.		for full legal notices.
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
	'MAY', and 'OPTIONAL' in this document are to be interpreted as		'MAY', and 'OPTIONAL' in this document are to be interpreted as
	described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,		described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
	they appear in all capitals, as shown here.		they appear in all capitals, as shown here.
	This module contains the definition for the AMBI data types.		This module contains the definition for the AMBI data types.
	It provides metadata for authenticating SSM channels as an		It provides metadata for authenticating SSM channels as an
	augmentation to DORMS.";		augmentation to DORMS.";
	revision 2019-08-25 {		revision 2019-08-25 {
	description "Initial revision as an extension.";		description "Initial revision as an extension.";
	reference		reference
	"";		"";
	}		}
	augment		augment
	"/dorms:metadata/dorms:sender/dorms:group/dorms:udp-stream" {		"/dorms:metadata/dorms:sender/dorms:group/dorms:udp-stream" {
	description "Definition of the manifest stream providing		description "Definition of the manifest stream providing
	integrity info for the data stream";		integrity info for the data stream";
	list manifest-stream {		list manifest-stream {
	key id;		key id;
	description "Definition of a manifest stream.";		description "Definition of a manifest stream.";
	leaf id {		leaf id {
	type uint32;		type uint32;
	mandatory true;		mandatory true;
	description "The Manifest ID referenced in a manifest.";		description
	}		"The Manifest ID referenced in a manifest.";
	leaf-list manifest-transport {		}
	type inet:uri;		leaf-list manifest-transport {
	description "A URI that provides a location for the		type inet:uri;
	manifest stream";		description "A URI that provides a location for the
	}		manifest stream";
	leaf hash-algorithm {		}
	type iha:hash-algorithm-type;		leaf hash-algorithm {
	mandatory true;		type iha:hash-algorithm-type;
	description		mandatory true;
	"The hash algorithm for the packet hashes within		description
	manifests in this stream.";		"The hash algorithm for the packet hashes within
	}		manifests in this stream.";
	leaf payload-type {		}
	type enumeration {		leaf payload-type {
	enum udp {		type enumeration {
	description "The hash includes only the UDP		enum udp {
	payload.";		description "The hash includes only the UDP
	}		payload.";
	enum ip {		}
	description "The hash includes the full IP		enum ip {
	payload.";		description "The hash includes the full IP
	}		payload.";
	}		}
	mandatory true;		}
	description "The contents of the payload for the		mandatory true;
	digest profile";		description "The contents of the payload for the
	}		digest profile";
	leaf data-hold-time-ms {		}
	type uint32;		leaf data-hold-time-ms {
	default 2000;		type uint32;
	description "The number of milliseconds to hold data		default 2000;
	packets waiting for a corresponding digest before		description
	discarding";		"The number of milliseconds to hold data
	}		packets waiting for a corresponding digest before
	leaf digest-hold-time-ms {		discarding";
	type uint32;		}
	default 10000;		leaf digest-hold-time-ms {
	description "The number of milliseconds to hold packet		type uint32;
	digests waiting for a corresponding data packet		default 10000;
	before discarding";		description
	}		"The number of milliseconds to hold packet
	}		digests waiting for a corresponding data packet
	}		before discarding";
	}		}
			}
			}
			}
	<CODE ENDS>		<CODE ENDS>
	6. IANA Considerations		6. IANA Considerations
	6.1. The YANG Module Names Registry		6.1. The YANG Module Names Registry
	This document adds one YANG module to the "YANG Module Names"		This document adds one YANG module to the "YANG Module Names"
	registry maintained at <https://www.iana.org/assignments/yang-		registry maintained at <https://www.iana.org/assignments/yang-
	parameters>. The following registrations are made, per the format in		parameters>. The following registrations are made, per the format in
	Section 14 of [RFC6020]:		Section 14 of [RFC6020]:
	name: ietf-ambi		name: ietf-ambi
	namespace: urn:ietf:params:xml:ns:yang:ietf-ambi		namespace: urn:ietf:params:xml:ns:yang:ietf-ambi
	prefix: ambi		prefix: ambi
	reference: I-D.draft-jholland-mboned-ambi		reference: I-D.draft-jholland-mboned-ambi
	6.2. Media Type		6.2. The XML Registry
			This document adds the following registration to the "ns" subregistry
			of the "IETF XML Registry" defined in [RFC3688], referencing this
			document.
			URI: urn:ietf:params:xml:ns:yang:ietf-ambi
			Registrant Contact: The IESG.
			XML: N/A, the requested URI is an XML namespace.
			6.3. Media Type
	TBD: Register 'application/ambi' according to advice from:		TBD: Register 'application/ambi' according to advice from:
	https://www.iana.org/form/media-types		https://www.iana.org/form/media-types
	TBD: check guidelines in https://tools.ietf.org/html/rfc5226		TBD: check guidelines in https://tools.ietf.org/html/rfc5226
	7. Security Considerations		7. Security Considerations
	7.1. Predictable Packets		7.1. Predictable Packets
	skipping to change at page 19, line 50 ¶		skipping to change at page 19, line 20 ¶
	attacks for hash collisions against those packets. When		attacks for hash collisions against those packets. When
	authenticating a protocol that might have predictable packets, it's		authenticating a protocol that might have predictable packets, it's
	RECOMMENDED to use a hash function secure against such attacks or to		RECOMMENDED to use a hash function secure against such attacks or to
	add content to the packets to make them unpredictable, such as an		add content to the packets to make them unpredictable, such as an
	Authentication Header ([RFC4302]), or the addition of an ignored		Authentication Header ([RFC4302]), or the addition of an ignored
	field with random content to the packet payload.		field with random content to the packet payload.
	TBD: explain attack from generating malicious packets and then		TBD: explain attack from generating malicious packets and then
	looking for collisions, as opposed to having to generate a collision		looking for collisions, as opposed to having to generate a collision
	on packet contents that include a sequence number and then hitting a		on packet contents that include a sequence number and then hitting a
	match (especially expand on this if we do add Section 2.3.1.2).		match.
	TBD: follow the rest of the guidelines: https://tools.ietf.org/html/		TBD: follow the rest of the guidelines: https://tools.ietf.org/html/
	rfc3552		rfc3552
	8. Acknowledgements		8. Acknowledgements
	Many thanks to Daniel Franke, Eric Rescorla, Christian Worm		Many thanks to Daniel Franke, Eric Rescorla, Christian Worm
	Mortensen, Max Franke, and Albert Manfredi for their very helpful		Mortensen, Max Franke, and Albert Manfredi for their very helpful
	comments and suggestions.		comments and suggestions.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.draft-jholland-mboned-dorms-02]		[I-D.draft-ietf-mboned-dorms-00]
	Holland, J., "Discovery Of Restconf Metadata for Source-		Holland, J., "Discovery Of Restconf Metadata for Source-
	specific multicast", draft-jholland-mboned-dorms-02 (work		specific multicast", draft-ietf-mboned-dorms-00 (work in
	in progress), March 2020.		progress), March 2020.
	[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>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	skipping to change at page 21, line 9 ¶		skipping to change at page 20, line 24 ¶
	<https://www.rfc-editor.org/info/rfc6865>.		<https://www.rfc-editor.org/info/rfc6865>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
			BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
			<https://www.rfc-editor.org/info/rfc8340>.
	9.2. Informative References		9.2. Informative References
	[I-D.draft-krose-mboned-alta-01]		[I-D.draft-krose-mboned-alta-01]
	Rose, K. and J. Holland, "Asymmetric Loss-Tolerant		Rose, K. and J. Holland, "Asymmetric Loss-Tolerant
	Authentication", draft-krose-mboned-alta-01 (work in		Authentication", draft-krose-mboned-alta-01 (work in
	progress), July 2019.		progress), July 2019.
	[I-D.ietf-tsvwg-udp-options]		[I-D.ietf-tsvwg-udp-options]
	Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-		Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
	udp-options-08 (work in progress), September 2019.		udp-options-08 (work in progress), September 2019.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Jacobson, "RTP: A Transport Protocol for Real-Time		Text on Security Considerations", BCP 72, RFC 3552,
	Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,		DOI 10.17487/RFC3552, July 2003,
	July 2003, <https://www.rfc-editor.org/info/rfc3550>.		<https://www.rfc-editor.org/info/rfc3552>.
			[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
			DOI 10.17487/RFC3688, January 2004,
			<https://www.rfc-editor.org/info/rfc3688>.
	[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.		[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
	Briscoe, "Timed Efficient Stream Loss-Tolerant		Briscoe, "Timed Efficient Stream Loss-Tolerant
	Authentication (TESLA): Multicast Source Authentication		Authentication (TESLA): Multicast Source Authentication
	Transform Introduction", RFC 4082, DOI 10.17487/RFC4082,		Transform Introduction", RFC 4082, DOI 10.17487/RFC4082,
	June 2005, <https://www.rfc-editor.org/info/rfc4082>.		June 2005, <https://www.rfc-editor.org/info/rfc4082>.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	DOI 10.17487/RFC4302, December 2005,		DOI 10.17487/RFC4302, December 2005,
	<https://www.rfc-editor.org/info/rfc4302>.		<https://www.rfc-editor.org/info/rfc4302>.
	skipping to change at page 22, line 5 ¶		skipping to change at page 21, line 27 ¶
	the Asynchronous Layered Coding (ALC) and NACK-Oriented		the Asynchronous Layered Coding (ALC) and NACK-Oriented
	Reliable Multicast (NORM) Protocols", RFC 5776,		Reliable Multicast (NORM) Protocols", RFC 5776,
	DOI 10.17487/RFC5776, April 2010,		DOI 10.17487/RFC5776, April 2010,
	<https://www.rfc-editor.org/info/rfc5776>.		<https://www.rfc-editor.org/info/rfc5776>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
			9.3. URIs
			[1] https://tools.ietf.org/html/rfc7696#section-2.2
	Authors' Addresses		Authors' Addresses
	Jake Holland		Jake Holland
	Akamai Technologies, Inc.		Akamai Technologies, Inc.
	150 Broadway		150 Broadway
	Cambridge, MA 02144		Cambridge, MA 02144
	United States of America		United States of America
	Email: jakeholland.net@gmail.com		Email: jakeholland.net@gmail.com
End of changes. 50 change blocks.
	246 lines changed or deleted		235 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/