Mboned J. Holland
Internet-Draft K. Rose
Intended status: Experimental Akamai Technologies, Inc.
Expires: April 26, 2019 October 23, 2018
Asymmetric Manifest-Based Integrity
draft-jholland-mboned-ambi-01
Abstract
This document introduces Asymmetric Manifest-Based Integrity (AMBI).
AMBI allows each receiver of a stream of multicast packets to check
the integrity of the contents of each packet in the data stream.
AMBI operates by employing a cryptographically-verifiable, loss-
resilient sequence of manifests containing integrity information for
both data and integrity packet payloads.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) 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
Holland & Rose Expires April 26, 2019 [Page 1]
Internet-Draft AMBI October 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Comparison with TESLA . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Specification . . . . . . . . . . . . . . . . . . . 4
2.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 4
2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. RTP Sequence Number . . . . . . . . . . . . . . . . . 5
2.1.3. SRTP Sequence Number . . . . . . . . . . . . . . . . 6
2.1.4. UDP Option . . . . . . . . . . . . . . . . . . . . . 6
2.2. Anchor Message . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. DNS-based Anchor URI Bootstrap . . . . . . . . . . . 6
2.2.3. Anchor Message YANG model . . . . . . . . . . . . . . 7
2.2.4. Example Anchor Message . . . . . . . . . . . . . . . 14
2.3. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2. Example Manifest Layout . . . . . . . . . . . . . . . 16
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
4.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 18
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Normative References . . . . . . . . . . . . . . . . . . 18
5.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Multicast transport poses security problems that are not easily
addressed by the same security mechanisms used for unicast transport.
The "Introduction" sections of the documents describing TESLA
[RFC4082], and TESLA in SRTP [RFC4383], and TESLA with ALC and NORM
[RFC5776] present excellent overviews of the challenges unique to
multicast authentication, briefly summarized here:
o A MAC based on a symmetric shared secret cannot be used because
each packet has multiple receivers that do not trust each other.
o Asymmetric per-packet signatures can handle only very low bit-
rates because of the computational overhead.
o An asymmetric signature of a larger message comprising multiple
packets requires reliable receipt of all such packets, something
Holland & Rose Expires April 26, 2019 [Page 2]
Internet-Draft AMBI October 2018
that cannot be guaranteed in a timely manner even for protocols
that do provide reliable delivery, and the retransmission of which
may anyway exceed the useful lifetime for data formats that can
otherwise tolerate some degree of loss.
Aymmetric Manifest-Based Integrity (AMBI) specifies a method for
receivers or middle boxes to cryptographically authenticate and
verify the integrity of a stream of data packets by communicating
integrity-protecting hashes chained from an asymmetrically-signed
root in a way that is robust to packet loss.
Integrity-protecting hashes are assembled into discrete "manifests"
that are 1:1 with data packets and have a fixed maximum size that is
a function only of the hash output size, packet identifier size, and
(for the root manifest) asymmetric signature length. Each hash is
computed over the contents of a specific data payload and associated
manifest. Manifests may be communicated either in-band (e.g.,
appended to or otherwise incorporated into the payload of the
associated data packet) or out-of-band (in an associated channel with
similar or better reliability characteristics).
TBD: It would be really nice if the signature were not in the root
manifest itself, as that potentially complicates in-band integrity
protection.
To achieve robustness of integrity information in the face of packet
loss, we employ a variant of the scheme described in [STRAUTH] to
structure the manifests. Manifests are described in more detail in
Section 2.3.
A root manifest is authenticated by a signature in an "anchor
message", itself authenticated using some pre-established trust
relationship. Anchor messages are described in greater detail in
Section 2.2.
The use of a single signature to authenticate a large sequence of
data packets allows the sender and receiver to amortize the
computational overhead of asymmetric authentication across enough
data packets to sustain high data rates. Furthermore, the use of
asymmetric authentication allows for asynchronous distribution of
authentication information, something not possible with TESLA.
Upon successful authentication of a root manifest and verification of
the chain of hashes required to establish the integrity of a
particular data payload, the corresponding payload may be delivered
to the application (in the case of a client) or relayed to the next
hop (in the case of a middle box).
Holland & Rose Expires April 26, 2019 [Page 3]
Internet-Draft AMBI October 2018
Authenticating the integrity of the data packets depends on:
o authentication of the anchor message that provides the linkage
between the data stream, the manifest channel, and the root
manifest authentication key;
o the secrecy and cryptographic strength of private keys used for
signing the root manifests; and
o the difficulty of generating a collision for the hashes in the
manifests.
1.1. Comparison with TESLA
AMBI and TESLA [RFC4082] and [RFC5776] attempt to achieve a similar
goal of authenticating the integrity of streams of multicast packets.
AMBI imposes a higher overhead, as measured in the amount of extra
data required, than TESLA imposes. In exchange, AMBI provides non-
repudiation (which TESLA does not), and relaxes the requirement for
establishing an upper bound on clock synchronization between sender
and receiver.
This tradeoff enables new capabilities for AMBI, relative to TESLA.
In particular, when receiving multicast traffic from an untrusted
transit network, AMBI can be used by a middle box to authenticate
packets from a trusted source before forwarding traffic through the
network, and the receiver also can separately authenticate the
packets. 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 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.
1.2. Terminology
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 [RFC2119].
2. Protocol Specification
2.1. Packet Identifiers
Holland & Rose Expires April 26, 2019 [Page 4]
Internet-Draft AMBI October 2018
2.1.1. Overview
A packet identifier is a sequence number contained within the
authenticated payload of a packet. The packet identifier is used in
a manifest to associate each integrity-protecting hash with a
specific data payload and integrity manifest.
Every packet containing either data or manifest MUST contain a packet
identifier. If a data payload and its associated manifest are
contained in separate packets, this packet identifier MUST be the
same in both packets.
This document defines a new UDP option in Section 2.1.4 for use as a
packet identifier.
Some multicast-capable transport protocols have a sequence number
embedded in data packets in the protocol. The sequence numbers in
these protocols MAY be used instead of the new UDP option, to avoid
introducing extra overhead in the authenticated data packets.
In Section 2.1.2, Section 2.1.3, and Section 2.1.4, this document
defines some sample ways to specify packet identifiers based on such
sequence numbers embedded in existing protocols.
Other appropriate sequence number systems may exist, such as the
anti-replay Sequence Number field in Section 3.1 of [RFC6584], when
NORM or FLUTE operates with an authentication profile that uses it
(however, since that example already provides authentication, it is
not added as an option in this document). The AMBI anchor message
format can be extended in future documents to support those or other
suitable schemes by adding values to the registry defined in
Section 3.
In some deployments, in contrast to using the new UDP option, the
approach of using an existing sequence number as packet identifier
may carry a benefit because, in combination with out-of-band
manifests, it requires no change to the data stream, possibly
enabling interoperability with legacy receivers.
2.1.2. RTP Sequence Number
Sequence number from Section 5.1 of [RFC3550].
TBD: discussion of security consequences of using 16 bits- recommend
a bigger hash in manifests for this case?
Holland & Rose Expires April 26, 2019 [Page 5]
Internet-Draft AMBI October 2018
2.1.3. SRTP Sequence Number
Packet Index from Section 3.3.1 of [RFC3711].
2.1.4. UDP Option
Define a new UDP option [I-D.ietf-tsvwg-udp-options] (TBD2).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Kind=TBD2 | Length=6 | 32-bit packet identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2. Anchor Message
2.2.1. Overview
An anchor message provides the information that makes it possible to
authenticate root manifests for a stream. An anchor message MAY be
discovered and transmitted by any means providing adequate source
authentication and data integrity to meet the security needs of the
receiver.
In order to support middle-box authentication, it is RECOMMENDED that
senders arrange to distribute anchor messages according to the method
outlined in Section 2.2.2.
2.2.2. DNS-based Anchor URI Bootstrap
TBD: This section needs to be updated for [STRAUTH].
When a middle box tries to process a join for a specific source, if
it is configured to perform authentication on SSM multicast channels
it can forward, it SHOULD make a DNS request for ambi.(reverse-
source-ip).ip6.arpa or ambi.(reverse-source-ip).in-addr.arpa, for
IPv6 or IPv4 source addresses.
When AMBI is provided to authenticate traffic from this source IP,
this domain name SHOULD be configured with a TXT field which contains
a URI that can be used to securely fetch an anchor message that
describes all the AMBI- authenticatable traffic from this source IP.
Other methods MAY be used to discover and transfer an anchor message.
The description of alternate methods is out of scope for this
document.
Holland & Rose Expires April 26, 2019 [Page 6]
Internet-Draft AMBI October 2018
TBD: consider breaking up anchor message to avoid large, frequently
changing anchors for sources with many groups.
TBD: consider graceful rollover for anchors, instead of synchronized
update of anchor hash.
2.2.3. Anchor Message YANG model
TBD: This section needs to be updated for [STRAUTH].
<CODE BEGINS> file "ietf-ambi-anchor.yang"
module ietf-ambi-anchor {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ambi-anchor";
prefix "ambi";
import ietf-yang-types {
prefix "yang";
reference "RFC6991 Section 3";
}
import ietf-inet-types {
prefix "inet";
reference "RFC6991 Section 4";
}
import ietf-routing-types {
prefix "rt-types";
reference "RFC8294";
}
organization "IETF";
contact
"Author: Jake Holland
<mailto:jholland@akamai.com>
Author: Kyle Rose
<mailto:krose@akamai.com>
";
description
"This module contains the definition for the AMBI anchor
message data type.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Holland & Rose Expires April 26, 2019 [Page 7]
Internet-Draft AMBI October 2018
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of
draft-jholland-mboned-ambi,
see the internet draft itself for full legal notices.";
revision 2018-06-27 {
description "Initial revision.";
reference
"";
}
/* TBD: copied some from https://tools.ietf.org/html/rfc8177,
but the model doesn't seem to match what I want. is there another
I can import instead of making these here? Or a registry
to reference? */
identity crypto-hash {
description
"Base identity of cryptographic hash options. ";
}
identity sha-256 {
base crypto-hash;
description
"The SHA-256 algorithm.";
}
identity blake2b {
base crypto-hash;
description
"The BLAKE2b algorithm.";
}
identity crypto-signature {
description
"Base identity of cryptographic asymmetric signature
options.";
}
identity ed25519 {
base crypto-signature;
description
"The Ed25519 algorithm.";
Holland & Rose Expires April 26, 2019 [Page 8]
Internet-Draft AMBI October 2018
}
identity rsa {
base crypto-signature;
description
"The RSA algorithm.";
}
identity sequence-type {
description
"Base identity for sequence number type options.";
}
identity rtp {
base sequence-type;
description
"The sequence number from RTP.";
}
identity srtp {
base sequence-type;
description
"The sequence number from SRTP.";
}
identity udp {
base sequence-type;
description
"The sequence number from UDP.";
}
typedef key-identifier {
type uint16 {
range 1..65535;
}
description "Key identifier within a manifest";
}
typedef bitrate {
type string {
pattern '[1-9][0-9]*[GMK]?bps';
}
description "Bit-rate of a data stream";
}
typedef packetrate {
type string {
pattern '[1-9][0-9]*[GMK]?pps';
}
Holland & Rose Expires April 26, 2019 [Page 9]
Internet-Draft AMBI October 2018
description "Packet rate of a data stream";
}
typedef manifest-transport {
type union {
type leafref {
path "/anchor/data_stream/id";
}
type inet:uri;
}
description "Transport method for a manifest stream";
}
container anchor {
container self {
presence "An anchor message exists";
description
"Self-referential properties about the anchor message";
leaf uri {
type inet:uri;
mandatory true;
description
"The canonical URI for this anchor message.";
}
leaf version {
type uint16;
mandatory true;
description
"The version number for this anchor message.";
}
leaf hash_algorithm {
type identityref {
base crypto-hash;
}
mandatory true;
description
"The algorithm for the anchor message hash provided
in a manifest.";
}
leaf hash_bits {
type uint16;
mandatory true;
description
"The number of bits for the anchor's hash provided
in a manifest.";
}
leaf expires {
type yang:date-and-time;
Holland & Rose Expires April 26, 2019 [Page 10]
Internet-Draft AMBI October 2018
mandatory true;
description
"The expiration time for this anchor message.";
}
}
description "Anchor message for AMBI";
list public_key {
key id;
description "Public key for non-recursive manifest";
leaf id {
type key-identifier;
mandatory true;
description
"The key identifier referenced in a manifest.";
}
leaf algorithm {
type identityref {
base crypto-signature;
}
mandatory true;
description
"The signature algorithm for use with this key.";
}
leaf signature_bits {
type uint16;
mandatory true;
description
"The length of the signature provided in manifests
signed with this key.";
}
leaf value {
type string;
mandatory true;
description
"The base64-encoded value of the public key.";
}
}
list data_stream {
key id;
unique "source destination port";
description "Stream of data packets to be authenticated";
leaf id {
type uint16;
mandatory true;
description
"The datastream_id referenced by a
Holland & Rose Expires April 26, 2019 [Page 11]
Internet-Draft AMBI October 2018
manifest_stream.";
}
leaf source {
type inet:ip-address;
mandatory true;
description
"The source IP address of the authenticated data
stream.";
}
leaf destination {
type rt-types:ip-multicast-group-address;
mandatory true;
description
"The destination group IP address of the
authenticated data stream.";
}
leaf port {
type uint16;
mandatory true;
description
"The destination UDP port of the authenticated data
stream.";
}
leaf max_bitrate {
type bitrate;
mandatory true;
description
"The maximum bitrate expected for this data
stream.";
}
leaf max_packetrate {
type packetrate;
mandatory true;
description
"The maximum packetrate expected for this data
stream.";
}
list authenticator {
key manifest_id;
description
"A manifest stream that authenticates this data";
leaf manifest_id {
type leafref {
path "/anchor/manifest_stream/id";
}
mandatory true;
description
"The ID of a manifest stream that provides
Holland & Rose Expires April 26, 2019 [Page 12]
Internet-Draft AMBI October 2018
authentication for this data stream.";
}
}
}
list manifest_stream {
key id;
description "Stream of manifests";
leaf id {
type uint16;
mandatory true;
description "The Manifest ID referenced in a manifest.";
}
leaf transport {
type manifest-transport;
mandatory true;
description
"The ID of the data stream that carries this
manifest stream or a uri that provides a websocket
with the stream of manifests.";
}
leaf hash_algorithm {
type identityref {
base crypto-hash;
}
mandatory true;
description
"The hash algorithm for the packet hashes within
manifests in this stream.";
}
leaf hash_bits {
type uint16;
mandatory true;
description
"The number of bits of hash provided for packet
hashes.";
}
leaf sequence_type {
type identityref {
base sequence-type;
}
mandatory true;
description
"The linkage to the data packet sequence numbers in
the manifest.";
}
}
}
Holland & Rose Expires April 26, 2019 [Page 13]
Internet-Draft AMBI October 2018
}
<CODE ENDS>
Figure 1: Anchor Message YANG model
2.2.4. Example Anchor Message
TBD: This section needs to be updated for [STRAUTH].
{
"ietf-ambi-anchor:anchor": {
"self": {
"uri": "https://example.com/ambi/anchor/example_1.json",
"version": 1,
"hash_algorithm": "blake2b",
"hash_bits": 256,
"expires": "2018-03-05T23:59:59Z"
},
"public_key": [
{
"id": 1,
"algorithm": "ed25519",
"signature_bits": 256,
"value": "VGhpcyBpcyBub3QgYSBnb29kIGtleSB0byB1c2UuLi4NCg=="
}
],
"data_stream": [
{
"id": 10,
"source": "192.0.2.10",
"destination": "232.10.10.1",
"port": 18001,
"max_bitrate": "10Mbps",
"max_packetrate": "1Kpps",
"authenticator": [
{
"manifest_id": 1
}
]
},
{
"id": 20,
"source": "192.0.2.10",
"destination": "232.10.10.1",
"port": 18002,
"max_bitrate": "400Kbps",
"max_packetrate": "40pps",
"authenticator": [
Holland & Rose Expires April 26, 2019 [Page 14]
Internet-Draft AMBI October 2018
{
"manifest_id": 2
}
]
}
],
"manifest_stream": [
{
"id": 1,
"transport": 20,
"hash_algorithm": "blake2b",
"hash_bits": 80,
"sequence_type": "udp"
},
{
"id": 2,
"transport": "https://example.com/ambi/manifest_stream/3",
"hash_algorithm": "blake2b",
"hash_bits": 80,
"sequence_type": "udp"
}
]
}
}
Figure 2: Example Anchor Message
2.3. Manifests
2.3.1. Overview
A manifest contains a sequence of hashes of data and corresponding
manifest payloads according to the DAG schema defined in section 3 of
[STRAUTH]. Additionally, a root manifest contains a public key
signature to allow for authentication against an anchor message.
o TBD: insert more details about the construction here
* Constructive description of scheme for p=1 and p>1
* How to choose the packets according to different settings of p
* Hash construction H(data,manifest)
* Possible hash algorithms and truncation
A manifest M_j cannot be interpreted except in the context of a known
anchor message authenticating a root manifest M_0, and a sequence of
Holland & Rose Expires April 26, 2019 [Page 15]
Internet-Draft AMBI October 2018
hashes h_i, manifests M_i, and data payloads D_i for 1 <= i <= j such
that h_i is contained in the manifest M_{i-1} and such that
h_i=H(D_i,M_i).
For a root manifest to be considered authentic, the anchor version in
the manifest MUST match the value in a known unexpired anchor message
and the signature of the root manifest MUST be authentic according to
the public key in the anchor message.
A manifest MAY omit the packet identifier associated with a
particular hash if the underlying packet stream employs packet
identifiers that are implicit from the structure of the integrity DAG
scheme and from the offset within the augmented chain. For example,
packet identifiers that increment by exactly one in successive data
packets and which overflow to zero would have this property.
2.3.2. Example Manifest Layout
The following describes the manifest layout for an integrity scheme
employing a hash with an output of 256 bits and an explicit packet
identifier space of 32 bits. This can be extended to other hash
ranges and packet identifier spaces in the obvious way. With a
sufficiently-strong hash function, the packet identifier may also be
safely truncated to the maximum possible window size for useful in-
flight data to save bits while avoiding trial hash comparison.
Given: * Manifest packet identifier i_0 * Augmented chain offset f *
k <= 5 * k is implicit from the chosen DAG scheme and from offset f
Holland & Rose Expires April 26, 2019 [Page 16]
Internet-Draft AMBI October 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=0 | Reserved | f | Anchor Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Identifier i_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash H(D_{i_1},M_{i_1}) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Identifier i_k |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash H(D_{i_k},M_{i_k}) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cryptographic Signature (if a root manifest) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. IANA Considerations
TBD1: Request a "Specification Required" registry for Packet
identifier methods, from https://tools.ietf.org/html/rfc5226#section-
4.1 . Reserve anything beginning with "experimental:"?
TBD2: Add a new entry to the "UDP Option Kind" numbers registry:
https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-
02#section-14
TBD: check guidelines in https://tools.ietf.org/html/rfc5226 and
remove this paragraph
Example from: https://tools.ietf.org/html/rfc5226#section-5.1
[TO BE REMOVED: Please add the yang model in Section 2.2.3 to:
https://www.iana.org/assignments/yang-parameters/yang-
parameters.xhtml
Name:ietf-ambi-anchor Maintained by IANA: N Namespace:
urn:ietf:params:xml:ns:yang:ietf-ambi-anchor Prefix: anchor
Reference: I-D.draft-jholland-mboned-ambi Notes: ]
Holland & Rose Expires April 26, 2019 [Page 17]
Internet-Draft AMBI October 2018
4. Security Considerations
4.1. Packet Identifiers
TBD: explain attack from generating malicious packets and then
looking for collisions, as opposed to having to generate a collision
including a packet identifier and then hitting a match
TBD: DNSSEC vis-a-vis anchor url discovery. (we need a diagram about
for middle-box handling of a revers-path propagated join?) Explain
why malicious DNS could deny service, but cannot cause accepting
attack packets.
TBD: follow the rest of the guidelines: https://tools.ietf.org/html/
rfc3552
5. References
5.1. Normative References
[I-D.ietf-tsvwg-udp-options]
Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
udp-options-05 (work in progress), July 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
5.2. Informative References
[DIGSIGN] Rohatgi, P., "How to Sign Digital Streams", 1997,
<https://link.springer.com/content/pdf/10.1007/
BFb0052235.pdf>.
Published in CRYPTO '97 "Proceedings of the 17th Annual
International Cryptology Conference on Advances in
Cryptology", Pages 180-197
Holland & Rose Expires April 26, 2019 [Page 18]
Internet-Draft AMBI October 2018
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, DOI 10.17487/RFC4082,
June 2005, <https://www.rfc-editor.org/info/rfc4082>.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383,
DOI 10.17487/RFC4383, February 2006,
<https://www.rfc-editor.org/info/rfc4383>.
[RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed
Efficient Stream Loss-Tolerant Authentication (TESLA) in
the Asynchronous Layered Coding (ALC) and NACK-Oriented
Reliable Multicast (NORM) Protocols", RFC 5776,
DOI 10.17487/RFC5776, April 2010,
<https://www.rfc-editor.org/info/rfc5776>.
[RFC6584] Roca, V., "Simple Authentication Schemes for the
Asynchronous Layered Coding (ALC) and NACK-Oriented
Reliable Multicast (NORM) Protocols", RFC 6584,
DOI 10.17487/RFC6584, April 2012,
<https://www.rfc-editor.org/info/rfc6584>.
[STRAUTH] Modadugu, N., "Authenticating Streamed Data in the
Presence of Random Packet Loss", 2001,
<https://crypto.stanford.edu/~pgolle/papers/auth.pdf>.
ISOC Network and Distributed System Security Symposium
Authors' Addresses
Jake Holland
Akamai Technologies, Inc.
150 Broadway
Cambridge, MA 02144
United States of America
Email: jakeholland.net@gmail.com
Holland & Rose Expires April 26, 2019 [Page 19]
Internet-Draft AMBI October 2018
Kyle Rose
Akamai Technologies, Inc.
150 Broadway
Cambridge, MA 02144
United States of America
Email: krose@krose.org
Holland & Rose Expires April 26, 2019 [Page 20]