draft-ietf-mboned-auto-multicast-17.txt   draft-ietf-mboned-auto-multicast-18.txt 
Network Working Group G. Bumgardner Network Working Group G. Bumgardner
Internet-Draft Internet-Draft
Intended status: Standards Track April 24, 2014 Intended status: Standards Track December 1, 2014
Expires: October 26, 2014 Expires: June 4, 2015
Automatic Multicast Tunneling Automatic Multicast Tunneling
draft-ietf-mboned-auto-multicast-17 draft-ietf-mboned-auto-multicast-18
Abstract Abstract
This document describes Automatic Multicast Tunneling (AMT), a This document describes Automatic Multicast Tunneling (AMT), a
protocol for delivering multicast traffic from sources in a protocol for delivering multicast traffic from sources in a
multicast-enabled network to receivers that lack multicast multicast-enabled network to receivers that lack multicast
connectivity to the source network. The protocol uses UDP connectivity to the source network. The protocol uses UDP
encapsulation and unicast replication to provide this functionality. encapsulation and unicast replication to provide this functionality.
The AMT protocol is specifically designed to support rapid deployment The AMT protocol is specifically designed to support rapid deployment
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 October 26, 2014. This Internet-Draft will expire on June 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 3, line 13 skipping to change at page 3, line 13
5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 61 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 61
5.3.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 61 5.3.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 61
5.3.2. Startup . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.2. Startup . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.3. Running . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.3. Running . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.4. Shutdown . . . . . . . . . . . . . . . . . . . . . . 73 5.3.4. Shutdown . . . . . . . . . . . . . . . . . . . . . . 73
5.3.5. Response MAC Generation . . . . . . . . . . . . . . . 73 5.3.5. Response MAC Generation . . . . . . . . . . . . . . . 73
5.3.6. Private Secret Generation . . . . . . . . . . . . . . 74 5.3.6. Private Secret Generation . . . . . . . . . . . . . . 74
6. Security Considerations . . . . . . . . . . . . . . . . . . . 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 74
6.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 76 6.2. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3. Encapsulated IP Packets . . . . . . . . . . . . . . . . . 77 6.3. Encapsulated IP Packets . . . . . . . . . . . . . . . . . 76
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77
7.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 77 7.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 77
7.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 77 7.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 77
7.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 78 7.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 77
7.2. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 78 7.2. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 78
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 78 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 78
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.1. Normative References . . . . . . . . . . . . . . . . . . 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 80
10.2. Informative References . . . . . . . . . . . . . . . . . 81 10.2. Informative References . . . . . . . . . . . . . . . . . 81
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 82
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 84
1. Introduction 1. Introduction
The advantages and benefits provided by multicast technologies are The advantages and benefits provided by multicast technologies are
well known. There are a number of application areas that are ideal well known. There are a number of application areas that are ideal
candidates for the use of multicast, including media broadcasting, candidates for the use of multicast, including media broadcasting,
video conferencing, collaboration, real-time data feeds, data video conferencing, collaboration, real-time data feeds, data
replication, and software updates. Unfortunately, many of these replication, and software updates. Unfortunately, many of these
applications lack multicast connectivity to networks that carry applications lack multicast connectivity to networks that carry
traffic generated by multicast sources. The reasons for the lack of traffic generated by multicast sources. The reasons for the lack of
skipping to change at page 8, line 49 skipping to change at page 8, line 49
IPv6/MLD (v1 or v2) protocols. The multicast reception state of the IPv6/MLD (v1 or v2) protocols. The multicast reception state of the
pseudo-interface is manipulated using the IGMP or MLD service pseudo-interface is manipulated using the IGMP or MLD service
interface. The IGMP and MLD host protocols produce IP datagrams interface. The IGMP and MLD host protocols produce IP datagrams
containing group membership messages that the gateway will send to containing group membership messages that the gateway will send to
the relay. The IGMP and MLD protocols also supply the retransmission the relay. The IGMP and MLD protocols also supply the retransmission
and timing behavior required for protocol robustness. and timing behavior required for protocol robustness.
All AMT encapsulation, decapsulation and relay interaction is assumed All AMT encapsulation, decapsulation and relay interaction is assumed
to occur within the pseudo-interface. to occur within the pseudo-interface.
A gateway host or application may create separate interfaces for IPv4 A gateway host or application may create separate interfaces for
/IGMP and IPv6/MLD. A gateway host or application may also require IPv4/IGMP and IPv6/MLD. A gateway host or application may also
additional pseudo-interfaces for each source or domain-specific relay require additional pseudo-interfaces for each source or domain-
address. specific relay address.
Within this document, the term "gateway" may be used as a generic Within this document, the term "gateway" may be used as a generic
reference to an entity executing the gateway protocol, a gateway reference to an entity executing the gateway protocol, a gateway
pseudo-interface, or a gateway device that has one or more interfaces pseudo-interface, or a gateway device that has one or more interfaces
connected to a unicast inter-network and one or more AMT gateway connected to a unicast inter-network and one or more AMT gateway
pseudo-interfaces. pseudo-interfaces.
The following diagram illustrates how an existing host IP stack The following diagram illustrates how an existing host IP stack
implementation might be used to provide AMT gateway functionality to implementation might be used to provide AMT gateway functionality to
a multicast application: a multicast application:
skipping to change at page 13, line 35 skipping to change at page 13, line 35
zero or more interfaces connected to a unicast inter-network, and one zero or more interfaces connected to a unicast inter-network, and one
or more relay pseudo-interfaces. or more relay pseudo-interfaces.
4.1.3.2. Use-Cases 4.1.3.2. Use-Cases
Use-cases for relay functionality include: Use-cases for relay functionality include:
Multicast Router Multicast Router
A multicast router that runs AMT on a downstream interface to A multicast router that runs AMT on a downstream interface to
provide gateway access to multicast traffic. A "relay router" provide gateway access to multicast traffic. A "relay router"
uses a multicast routing protocol (e.g. PIM-SM RFC4601 [RFC4601]) uses a multicast routing protocol (e.g. PIM-SM RFC4601 [RFC4601])
to construct a forwarding path for multicast traffic by sending to construct a forwarding path for multicast traffic by sending
join and prune messages to neighboring routers to join or leave join and prune messages to neighboring routers to join or leave
multicast distribution trees for a given SSM source or ASM multicast distribution trees for a given SSM source or ASM
rendezvous point. rendezvous point.
IGMP/MLD Proxy Router IGMP/MLD Proxy Router
An IGMP/MLD proxy that runs AMT on a downstream interface and An IGMP/MLD proxy that runs AMT on a downstream interface and
host-mode IGMPv3/MLDv2 on a upstream interface. This "relay host-mode IGMPv3/MLDv2 on a upstream interface. This "relay
proxy" sends group membership reports to a local, multicast- proxy" sends group membership reports to a local, multicast-
enabled router to join and leave specific SSM or ASM groups. enabled router to join and leave specific SSM or ASM groups.
skipping to change at page 16, line 50 skipping to change at page 16, line 50
Request: Request:
Sent by gateways to solicit a Membership Query message from a Sent by gateways to solicit a Membership Query message from a
relay. relay.
Membership Query: Membership Query:
Sent by relays as a response to a Request message. Used to Sent by relays as a response to a Request message. Used to
deliver an encapsulated IGMPv3 or MLDv2 query message to the deliver an encapsulated IGMPv3 or MLDv2 query message to the
gateway. gateway.
Membership Update: Membership Update:
Sent by gateways to deliver an encapsulated IGMP or MLD report/ Sent by gateways to deliver an encapsulated IGMP or MLD
leave/done message to a relay. report/leave/done message to a relay.
Multicast Data: Multicast Data:
Sent by relays to deliver an encapsulated IP multicast datagram or Sent by relays to deliver an encapsulated IP multicast datagram or
datagram fragment to a gateway. datagram fragment to a gateway.
Teardown: Teardown:
Sent by gateways to stop the delivery of Multicast Data messages Sent by gateways to stop the delivery of Multicast Data messages
requested in an earlier Membership Update message. requested in an earlier Membership Update message.
The following sections describe how these messages are exchanged to The following sections describe how these messages are exchanged to
skipping to change at page 18, line 28 skipping to change at page 18, line 28
messages that describe their current multicast reception state. messages that describe their current multicast reception state.
However, AMT does not allow relays to send unsolicited query messages However, AMT does not allow relays to send unsolicited query messages
to gateways, as the set of active gateways may be unknown to the to gateways, as the set of active gateways may be unknown to the
relay and potentially quite large. Instead, AMT requires each relay and potentially quite large. Instead, AMT requires each
gateway to periodically send a message to a relay to solicit a gateway to periodically send a message to a relay to solicit a
general-query response. A gateway accomplishes this by sending a general-query response. A gateway accomplishes this by sending a
Request message to a relay. The relay responds by sending Membership Request message to a relay. The relay responds by sending Membership
Query message back to the gateway. The Membership Query message Query message back to the gateway. The Membership Query message
carries an encapsulated general query that is processed by the IGMP carries an encapsulated general query that is processed by the IGMP
or MLD protocol implementation on the gateway to produce a membership or MLD protocol implementation on the gateway to produce a
/listener report. Each time the gateway receives a Membership Query membership/listener report. Each time the gateway receives a
message it starts a timer whose expiration will trigger the start of Membership Query message it starts a timer whose expiration will
a new Request->Membership Query message exchange. This timer-driven trigger the start of a new Request->Membership Query message
sequence is used to mimic the transmission of a periodic general exchange. This timer-driven sequence is used to mimic the
query by an IGMP/MLD router. This query cycle may continue transmission of a periodic general query by an IGMP/MLD router. This
indefinitely once started by sending the initial Request message. query cycle may continue indefinitely once started by sending the
initial Request message.
A membership update occurs when an IGMP or MLD report, leave or done A membership update occurs when an IGMP or MLD report, leave or done
message is passed to the gateway pseudo-interface. These messages message is passed to the gateway pseudo-interface. These messages
may be produced as a result of the aforementioned general-query may be produced as a result of the aforementioned general-query
processing or as a result of receiver interaction with the IGMP/MLD processing or as a result of receiver interaction with the IGMP/MLD
service interface. Each report is encapsulated and sent to the relay service interface. Each report is encapsulated and sent to the relay
after the gateway has successfully established communication with the after the gateway has successfully established communication with the
relay via a Request and Membership Query message exchange. If a relay via a Request and Membership Query message exchange. If a
report is passed to the pseudo-interface before the gateway has report is passed to the pseudo-interface before the gateway has
received a Membership Query message from the relay, the gateway may received a Membership Query message from the relay, the gateway may
skipping to change at page 20, line 14 skipping to change at page 20, line 14
The following sequence describes how the Request, Membership Query, The following sequence describes how the Request, Membership Query,
and Membership Update messages are used to report current group and Membership Update messages are used to report current group
membership state or changes in group membership state: membership state or changes in group membership state:
1. A gateway sends a Request message to the relay that contains a 1. A gateway sends a Request message to the relay that contains a
random nonce and a flag indicating whether the relay should random nonce and a flag indicating whether the relay should
return an IGMPv3 or MLDv2 general query. return an IGMPv3 or MLDv2 general query.
2. When the relay receives a Request message, it generates a 2. When the relay receives a Request message, it generates a
message authentication code (MAC) by computing a hash value from message authentication code (MAC), typically, by computing a
message source IP address, source UDP port, request nonce and a hash digest from message source IP address, source UDP port,
private secret. The relay then sends a Membership Query message request nonce and a private secret. The relay then sends a
to the gateway that contains the request nonce, the MAC, and an Membership Query message to the gateway that contains the
IGMPv3 or MLDv2 general query. request nonce, the MAC, and an IGMPv3 or MLDv2 general query.
3. When the gateway receives a Membership Query message, it 3. When the gateway receives a Membership Query message, it
verifies that the request nonce matches the one sent in the last verifies that the request nonce matches the one sent in the last
Request, and if it does, the gateway saves the request nonce and Request, and if it does, the gateway saves the request nonce and
MAC for use in sending subsequent Membership Update messages. MAC for use in sending subsequent Membership Update messages.
The gateway starts a timer whose expiration will trigger the The gateway starts a timer whose expiration will trigger the
transmission of a new Request message and extracts the transmission of a new Request message and extracts the
encapsulated general query message for processing by the IGMP or encapsulated general query message for processing by the IGMP or
MLD protocol. The query timer duration is specified by the MLD protocol. The query timer duration is specified by the
relay in the Querier's Query Interval Code (QQIC) field in the relay in the Querier's Query Interval Code (QQIC) field in the
skipping to change at page 38, line 23 skipping to change at page 38, line 23
does. A relay implementation that supports the optional teardown does. A relay implementation that supports the optional teardown
procedure (See Section 5.3.3.5) SHOULD set this flag and the Gateway procedure (See Section 5.3.3.5) SHOULD set this flag and the Gateway
Address field values. If a relay sets this flag, it MUST also Address field values. If a relay sets this flag, it MUST also
include the Gateway Address fields in the message. A gateway include the Gateway Address fields in the message. A gateway
implementation that does not support the optional teardown procedure implementation that does not support the optional teardown procedure
(See Section 5.2.3.7) MAY ignore this flag and the Gateway Address (See Section 5.2.3.7) MAY ignore this flag and the Gateway Address
fields if they are present. fields if they are present.
5.1.4.6. Response MAC 5.1.4.6. Response MAC
A 48-bit source authentication hash generated by the relay as A 48-bit source authentication value generated by the relay as
described in Section 5.3.5. The gateway echoes this value in described in Section 5.3.5. The gateway echoes this value in
subsequent Membership Update messages to allow the relay to verify subsequent Membership Update messages to allow the relay to verify
that the sender of a Membership Update message was the intended that the sender of a Membership Update message was the intended
receiver of a Membership Query sent by the relay. receiver of a Membership Query sent by the relay.
5.1.4.7. Request Nonce 5.1.4.7. Request Nonce
A 32-bit value copied from the Request Nonce field (Section 5.1.3.5) A 32-bit value copied from the Request Nonce field (Section 5.1.3.5)
carried by a Request message. The relay will have included this carried by a Request message. The relay will have included this
value in the Response MAC hash computation. The gateway echoes this value in the Response MAC computation. The gateway echoes this value
value in subsequent Membership Update messages. The gateway also in subsequent Membership Update messages. The gateway also uses this
uses this value to match a Membership Query to a Request message. value to match a Membership Query to a Request message.
5.1.4.8. Encapsulated General Query Message 5.1.4.8. Encapsulated General Query Message
An IP-encapsulated IGMP or MLD message generated by the relay. This An IP-encapsulated IGMP or MLD message generated by the relay. This
field will contain one of the following IP datagrams: field will contain one of the following IP datagrams:
IPv4:IGMPv3 Membership Query IPv4:IGMPv3 Membership Query
IPv6:MLDv2 Listener Query IPv6:MLDv2 Listener Query
skipping to change at page 66, line 26 skipping to change at page 66, line 26
o The computed checksums for the encapsulated IP datagram and its o The computed checksums for the encapsulated IP datagram and its
payload MUST match the values contained therein. Checksum payload MUST match the values contained therein. Checksum
computation and verification varies by protocol; See [RFC0791] for computation and verification varies by protocol; See [RFC0791] for
IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6). IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6).
o If processing of the encapsulated IGMP or MLD message would result o If processing of the encapsulated IGMP or MLD message would result
in an allocation of new state or a modification of existing state, in an allocation of new state or a modification of existing state,
the relay MUST authenticate the source of the Membership message the relay MUST authenticate the source of the Membership message
by verifying that the value contained in the Response MAC field by verifying that the value contained in the Response MAC field
equals the MAC value computed from the fields in the Membership equals the MAC value computed from the fields in the Membership
Update message datagram. Because the private secret used to Update message datagram. If a time-varying private secret is used
compute Response MAC values may change over time, the relay MUST in the computation of a Response MAC, the relay MUST retain the
retain the previous version of the private secret to use in previous version of the private secret for use in authenticating
authenticating Membership Updates sent during the subsequent query Membership Updates sent during the subsequent query interval. If
interval. If the first attempt at Response MAC authentication the first attempt at Response MAC authentication fails, the relay
fails, the relay MUST attempt to authenticate the Response MAC MUST attempt to authenticate the Response MAC using the previous
using the previous private secret value unless 2*query_interval private secret value unless 2*query_interval time has elapsed
time has elapsed since the private secret change. See since the private secret change. See Section 5.3.5.
Section 5.3.5. An alternative approach to Response MAC generation
that avoids repeated Response MAC computations may be found in
Appendix A.1.
A relay MAY skip source authentication to reduce the computational A relay MAY skip source authentication to reduce the computational
cost of handling Membership Update messages if the relay can make a cost of handling Membership Update messages if the relay can make a
trivial determination that the IGMP/MLD message carried by the trivial determination that the IGMP/MLD message carried by the
Membership Update message will produce no changes in group membership Membership Update message will produce no changes in group membership
or forwarding state. The relay does not need to compute and compare or forwarding state. The relay does not need to compute and compare
MAC values if it finds there are no group subscriptions for the MAC values if it finds there are no group subscriptions for the
source of the Membership Update message and either of the following source of the Membership Update message and either of the following
is true: is true:
skipping to change at page 72, line 29 skipping to change at page 72, line 29
If a per-endpoint timer is used, the relay MUST restart this timer If a per-endpoint timer is used, the relay MUST restart this timer
each time it receives a new Membership Update message from the each time it receives a new Membership Update message from the
gateway endpoint. gateway endpoint.
The endpoint timer duration MAY be computed from tunable IGMP/MLD The endpoint timer duration MAY be computed from tunable IGMP/MLD
variables as follows: variables as follows:
((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval ((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval
If IGMP/MLD default values are used for these variables, the gateway If IGMP/MLD default values are used for these variables, the gateway
will timeout after 125s * 2 + 10s = 260s. The timer duration MUST be will timeout after 125s * 2 + 10s = 260s. The timer duration MUST be
greater than the query interval suggested in the last Membership greater than the query interval suggested in the last Membership
Query message sent to the gateway endpoint. Query message sent to the gateway endpoint.
Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the
Query_Response_Interval value SHOULD be greater than or equal to 10s Query_Response_Interval value SHOULD be greater than or equal to 10s
to allow for packet loss and round-trip time in the Request/ to allow for packet loss and round-trip time in the Request/
Membership Query message exchange. Membership Query message exchange.
5.3.3.8. Relay Resource Management 5.3.3.8. Relay Resource Management
skipping to change at page 73, line 34 skipping to change at page 73, line 34
o Stop sending data messages to gateways. o Stop sending data messages to gateways.
o Delete all AMT group membership and forwarding state created on o Delete all AMT group membership and forwarding state created on
the relay, coordinating with the multicast routing protocol to the relay, coordinating with the multicast routing protocol to
update the group membership state on upstream interfaces as update the group membership state on upstream interfaces as
required. required.
5.3.5. Response MAC Generation 5.3.5. Response MAC Generation
A Response MAC is produced by a hash digest computation. A Response A Response MAC value is computed by the relay. A Response MAC
MAC computation is required in the following situations: computation is required in the following situations:
o To generate a Response MAC value from a Request message for o To generate a Response MAC value from a Request message for
inclusion in a Membership Query message. inclusion in a Membership Query message.
o To generate a Response MAC value from a Membership Update message o To generate a Response MAC value from a Membership Update message
for use in authenticating the Response MAC carried within that for use in authenticating the Response MAC carried within that
message. message.
o To generate a Response MAC value from a Teardown message to o To generate a Response MAC value from a Teardown message to
authenticate the Response MAC carried within that message. authenticate the Response MAC carried within that message.
Gateways treat the Response MAC field as an opaque value, so a relay Gateways treat the Response MAC field as an opaque value, so a relay
implementation may generate the MAC using any method available to it. implementation may generate the MAC using any method available to it.
The hash function RECOMMENDED for use in computing the Response MAC The RECOMMENDED method for computing the Response MAC is to compute a
is the MD5 hash digest [RFC1321], though hash functions or keyed-hash cryptographically-secure hash or keyed-hash digest from the following
functions of greater cryptographic strength may be used. values:
The digest MUST be computed over the following values:
o The Source IP address of the message (or Teardown Gateway IP o The Source IP address of the message (or Teardown Gateway IP
Address field) Address field)
o The Source UDP port of the message (or Teardown Gateway Port o The Source UDP port of the message (or Teardown Gateway Port
Number field) Number field)
o The Request Nonce contained in the message. o The Request Nonce contained in the message.
o A private secret known only to the relay o A private secret or key known only to the relay.
An Response MAC generation solution that satisfies these requirements
is described in Appendix A.1.
5.3.6. Private Secret Generation 5.3.6. Private Secret Generation
The private secret, or hash-key, is a random value that the relay If the relay implementation uses a private secret (or key) to compute
includes in the Response MAC hash digest computation. A relay SHOULD the Response MAC value, the relay SHOULD periodically compute a new
periodically compute a new private secret. The RECOMMENDED maximum private secret. The RECOMMENDED maximum interval is 2 hours. A
interval is 2 hours. A relay MUST retain the prior secret for use in relay MUST retain the prior secret for use in verifying MAC values
verifying MAC values that were sent to gateways just prior to the use that were sent to gateways just prior to the use of the new secret.
of the new secret.
The private secret SHOULD be computed using a cryptographically-
secure pseudo-random number generator. The private secret width
SHOULD equal that of the hash function used to compute the Response
MAC, e.g., 128-bits for an MD5 hash.
6. Security Considerations 6. Security Considerations
AMT is not intended to be a strongly secured protocol. In general, AMT is not intended to be a strongly secured protocol. In general,
the protocol provides the same level of security and robustness as is the protocol provides the same level of security and robustness as is
provided by the UDP, IGMP and MLD protocols on which it relies. The provided by the UDP, IGMP and MLD protocols on which it relies. The
lack of strong security features can largely be attributed to the lack of strong security features can largely be attributed to the
desire to make the protocol light-weight by minimizing the state and desire to make the protocol light-weight by minimizing the state and
computation required to service a single gateway, thereby allowing a computation required to service a single gateway, thereby allowing a
relay to service a larger number of gateways. relay to service a larger number of gateways.
skipping to change at page 75, line 20 skipping to change at page 75, line 12
messages and those messages that do not carry expected address values messages and those messages that do not carry expected address values
or protocol payload types or content. or protocol payload types or content.
6.1. Relays 6.1. Relays
The three-way handshake provided by the membership update message The three-way handshake provided by the membership update message
sequence (See (Section 4.2.1.2)) provides a defense against source- sequence (See (Section 4.2.1.2)) provides a defense against source-
spoofing-based resource-exhaustion attacks on a relay by requiring spoofing-based resource-exhaustion attacks on a relay by requiring
source authentication before state allocation. However, attackers source authentication before state allocation. However, attackers
may still attempt to flood a relay with Request and Membership Update may still attempt to flood a relay with Request and Membership Update
messages to force the relay to make the hash computations in an messages to force the relay to make the MAC authentication
effort to consume computational resources. Implementations may computations in an effort to consume computational resources.
choose to limit the frequency with which a relay responds to Request Implementations may choose to limit the frequency with which a relay
messages sent from a single IP address or IP address and UDP port responds to Request messages sent from a single IP address or IP
pair, but support for this functionality is not required. The three- address and UDP port pair, but support for this functionality is not
way handshake provides no defense against an eavesdropping or man-in- required. The three-way handshake provides no defense against an
the-middle attacker. eavesdropping or man-in-the-middle attacker.
Attackers that execute the gateway protocol may consume relay Attackers that execute the gateway protocol may consume relay
resources by instantiating a large number of tunnels or joining a resources by instantiating a large number of tunnels or joining a
large number of multicast streams. A relay implementation should large number of multicast streams. A relay implementation should
provide a mechanism for limiting the number of tunnels (Multicast provide a mechanism for limiting the number of tunnels (Multicast
Data message destinations) that can be created for a single gateway Data message destinations) that can be created for a single gateway
source address. Relays should also provide a means for limiting the source address. Relays should also provide a means for limiting the
number of joins per tunnel instance as a defense against these number of joins per tunnel instance as a defense against these
attacks. attacks.
skipping to change at page 81, line 23 skipping to change at page 81, line 23
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993. Anycasting Service", RFC 1546, November 1993.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
skipping to change at page 82, line 26 skipping to change at page 82, line 23
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, December 2006. Services", BCP 126, RFC 4786, December 2006.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, April 2013. UDP Checksums for Tunneled Packets", RFC 6935, April 2013.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, April 2013. RFC 6936, April 2013.
Appendix A. Implementation Notes
A.1. Response MAC Generation and Keying
This specification does not require relays to use any particular
method to compute the Response MAC field value - only that it contain
a hash of the source IP address, source UDP port, request nonce, and
a private secret known only to the relay. This allows the relay
implementor a significant amount of leeway in the computation and
structure of the value stored in the Response MAC field.
Section Section 5.3.6 states that a relay should periodically compute
a new private secret (or hash-key) for MAC generation. To prevent
the relay from rejecting Membership Update messages that contain
Response MAC values computed from an old secret, the relay is
required to retain the previous secret so that it can re-attempt
authentication using the old secret, should authentication fail after
recomputing the MAC using the new secret. However, this approach
requires a relay to do at least two hash computations for every
Membership Update message that carries an old or a invalid MAC. A
better approach would be to include information within the message
that the relay could use to choose a single secret for authentication
rather relying on sequential authentication failures to test all
possible secrets.
The solution proposed here is to compute and exchange an
"authentication cookie" rather than a simple hash value in the
Response MAC field. The authentication cookie would combine a
timestamp with a hash value. The timestamp is used to calculate the
age of the cookie, allowing the relay to reject a message if the
cookie's age is greater than some maximum allowable value. If the
cookie has not expired, the relay uses the timestamp to lookup the
secret that was in use at that time and then compute and compare the
hash portion of the cookie to authenticate the message source.
A second purpose served by including the timestamp in the MAC field
is that it allows the relay to contribute an unpredictable value to
the authentication hash. This contribution provides a defense
against attempts to use a hash reversal algorithm to determine the
relay's private secret as the hash result will change over time even
if the nonce carried by the Request message does not.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |4 or 5| Reserved | | Response MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
Figure 19: The Opaque Response MAC Field
A relay may use the opaque Response MAC field to store a cookie as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |4 or 5| Reserved | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
Figure 20: Using The Response MAC Field To Carry An Authentication
Cookie
The timestamp is an unsigned integer measured relative to the start
time of relay. The age of the MAC is computed by subtracting the MAC
timestamp from the current system timestamp. The operands must be
unsigned 16-bit integers and the subtraction must use unsigned
arithmetic to allow for timestamp wrap-around. The timestamp
resolution must provide range sufficient to handle the maximum
allowable age for a MAC, e.g., a resolution of 1 second allows a
maximum age of 18 hours. The timestamp should start at a random
value by adding a random offset, computed at startup, to the current
system time.
+-------------------------+--------------/ /-----------------+
-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |
| +-------------------------+--------------/ /-----------------+
|___________________________________________________________________
|
+-------------------------+--------------/ /-----------------+ |
-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |--
| +-------------------------+--------------/ /-----------------+
|___________________________________________________________________
|
+-------------------------+--------------/ /-----------------+ |
-->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |--
| +-------------------------+--------------/ /-----------------+
|
|__ Current
Secret
Figure 21: Private Secret Queue
The timestamp is not only used to compute the age of the MAC, but is
also used to lookup the private secret used to generate the MAC.
Each time a new private secret is computed, the value and the time at
which the value was computed is pushed into a fixed-length queue of
recent values (typically only 2-deep). The relay uses the timestamp
contained in the MAC field to lookup the appropriate secret. The
relay iterates over the list of secrets, starting with the newest
entry, until it finds the first secret with a timestamp that is older
than that contained in the MAC field. The relay then uses that
secret to compute the MAC that will be compared with that carried by
the message.
Author's Address Author's Address
Gregory Bumgardner Gregory Bumgardner
Phone: +1 541 343 6790 Phone: +1 541 343 6790
Email: gbumgard@gmail.com Email: gbumgard@gmail.com
 End of changes. 22 change blocks. 
189 lines changed or deleted 58 lines changed or added

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