Subject: Re: [MBONED] Last Call: <draft-ietf-mboned-auto-multicast-14.txt> (Automatic Multicast Tunneling) to Proposed Standard

From: Greg Bumgardner <[email-masked]>
Date: Tue, 8 Jan 2013 18:26:49 -0800

Magnus,

I would like to thank you for providing valuable feedback regarding the AMT
spec.

I would first like to state that many of your concerns and criticisms
regarding the protocol were raised during MBONED group discussions. Many
alternative solutions were identified but ultimately rejected by the group,
primarily due to the reluctance of group members to make significant
changes to the protocol after several years of slow development. My
comments are inlined below...

Thanks,

-g.b.

On Wed, Dec 26, 2012 at 5:01 AM, Magnus Westerlund <
[email-masked]> wrote:

>  Hi,
>
> Sorry for being late with this IETF last call comments. I will partly
> blame the ADs requesting this Transport Directorate review a bit late, the
> other part is all mine and the holidays. Anyway, I do hope you will
> consider these issues and comments as I believe I found some serious ones
> in addition to a number of clarifications that should be made.
>
>
> Significant Issues:
>
> 1. Congestion Control
> This is clearly a tunnel establishment protocol of something that is IP
> traffic. Thus normally the responsibility for congestion control is with
> the tunnelled traffic. However, I would like argue that this does not apply
> in this case due to the nature of the tunnelled traffic, i.e. multicast
> traffic and secondary due to limitations in the tunnel protocol.
>
> Lets start with the second part. This protocol claims to support ASM still
> don't provide a upstream delivery mechanism, i.e. an ASM receiver is not
> capable of sending as it should. This prevents several existing mechanism
> for congestion control that exist in protocols supporting multicast. The
> first is using RTCP for congestion control in ASM [RFC3550], the second is TCP-Friendly
> Multicast Congestion Control [RFC4654] that can be used in the RMT suite
> of protocols, and I know has been implemented in some NORM
> implementation. Thus only strictly receiver based mechanisms, such as Wave
> and Equation Based Rate Control [RFC3738] are available in this context.
>

You are correct, the AMT protocol provides no method for injecting
multicast traffic into a multicast enabled network, and thus does not
provide the functionality required for something like ASM RTP/RTCP
teleconferencing. The protocol is primarily intended for use in receiving
SSM traffic. Because the AMT protocol uses IGMP/MLD messages to establish
reception/subscription state, the protocol MAY be used to subscribe to ASM
broadcasts, but cannot generate them.

I should note that earlier versions of the AMT spec described a method for
broadcasting SSM via a gateway/relay tunnel, but this capability was
removed due to feasibility considerations.

> Secondly, many multicast usages are in fact deployed without any
> congestion control. This based on that the deploying entity controls the
> scope and authorization for requesting multicast delivery. However, does restrictions
> does not apply to AMT delivery of multicast. If the gateway can reach using
> unicast the relay it can be delivered the multicast group from the domain
> the relay is attached to. Thus, this protocol changes the deployment
> restrictions of multicast which many non-congestion controlled delivery
> is based on. Instead the non-congestion controlled traffic can now sent
> over an IP/UDP tunnel over Internet where neither relay nor gateway may
> have any knowledge about the path the traffic may take.
>

The AMT protocol does not attempt to address the issue of congestion
control. The group decided to treat the detection and remediation of
congestion (of encapsulated multicast packets) as an application-layer
responsibility. While we might have attempted to provide some level of QoS
control on tunnel packets by copying ToS/DS bits from inner to outer
headers, this would only occur on a packet-by-packet basis on not on the
tunnel as a whole.

> Based on this I would like to see two changes to this protocol
> specification. First a section discussing the issue of congestion control.
>

I'm not sure what, if anything, I might add to address this. I think the
spec makes it pretty clear that the tunneling is provided by best-effort
delivery of UDP packets (perhaps restricted by relay/router configuration).
Perhaps you could suggest some text.

> Secondly, I think this protocol should have an applicability statement
> limiting its deployment to restricted environments where the relay and
> gateway deployers can provide certain resource provisions between the
> entities to avoid the multicast traffic affecting other traffic sharing
> the same bottlenecks in ways not allowed by the network provider.
>

While I understand your concern, this would essentially negate the entire
reason for the protocol, which is to provide multicast transit to
non-multicast connected receivers. However, the AMT spec does not preclude
the implementation/deployment of AMT-enabled gateway devices for which AMT
support may be enabled or disabled (or blocked via a firewall).

>
>
> 2. Security
>
> This protocols is frank with it having limited security features and says
> this is similar to the IGMP and MLD protocols being used. However, I think
> this is a failure to propoerly consider the threat model. If one uses AMT
> over general Internet it will run in a network where the one deploying the
> multicast and the relays no longer control requirements on source address
> verification or possibilities for traffic separation as they can do within
> the domains where multicast currently are deployed. The security
> vulnerabilities in IGMP and MLD are much more contained and controllable in
> a LAN environment where one has chosen to deploy multicast compared to an
> Relay exposing this to the whole Internet. Once more I think there is only
> two choices here.
>
> A) Beef up the security to general Internet threat model, i.e. at a
> minimal provide a real model for gateway authentication using identities,
> not only return routability based verifications.
>
> B) Limit the applicability of AMT to managed environments and make it
> clear that the relay will need to limit which gateways are allowed to
> access the relay based on addressing.
>
> Based on the first significant issue with congestion control I expect that
> there is little meaning to do A) unless also one is willing to beef up AMT
> to provide congestion control. Which I think is not according to the design
> wishes for the protocol designers.
>

The security topic was visited and revisited numerous times over the last
couple of years. The group made the decision to limit the protocol to
simple source address verification and leave it at that. An emphasis was
placed on protecting relays against simple DoS attacks but not gateways.

3. Use of Zero Checksum
>
> The AMT specification enables the use of Zero UDP checksum with IPv6, i.e.
> draft-ietf-6man-udpchecksums-06<http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/>and
> draft-ietf-6man-udpzero-08<http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/>.
> Nothing against this in principal. However, I have noticed that AMT fails
> to properly address the failure modes of using a zero-checksum. AMT is a
> typical example of a protocol that actually need active verification of
> each tunnel that zero-checksum functions. This as AMT is clearly intended
> to be deployed with its Gateway part in end-hosts and residential network
> devices or routers. This means the tunnel will pass through both firewalls
> and NATs on its path between the relay and the gateway. Unless these
> devices are not upgraded to support zero-checksum in UDP for IPv6 the
> traffic may actually become black holed. The most likely is a simple
> firewall that has a rule for IPv6/UDP which doesn't allow zero checksum as
> it is against RFC 2460. Thus all the Multicast data packets will disappear
> on route in the tunnel. There is no mechanism in the AMT protocol to detect
> this and negotiate with the relay so that it will not use the zero-checksum
> for this tunnel.
>
> This must be addressed as I see it. If not the AMT will be so brittle that
> it can't be used in a large number of its intended deployments.
>

You probably have no idea how often this issue was raised and discussed
within the group. The consensus was that there was no single solution to
the problem. The only workable solution I can suggest is to use an IPv4
tunnel to carry the IPv6 packets. The mechanism for deciding whether (or
if) to use an IPv4 tunnel is considered out of scope.

>
> 4) MTU issues
>
> This document total fails to discuss the issues of MTU blackholing. As the
> IP multicast datagrams as well as the encapsulated IGMP/MLD messages can
> with the added tunnel-overhead result in that the sent packet exceeds the
> MTU of the path, these packets could be black holed. This can potentially
> result in very intermittent transport behavior for the tunnel. Thus, some
> discussion of how do handle the MTU issues in this context should be
> introduced.
>

Yep. This could be a problem that has no easy solution. Not only might the
outer packets be fragmented, but the encapsulated packets might be
fragments. Since the protocol obviously has no control over the size of
source packets, it cannot really avoid the potential need to fragment the
tunnel packets. A gateway can only rely on the underlying UDP/IP stack to
provide the necessary reassembly of the tunnel packets. Once the tunnel
packet has been reassembled, the gateway, host IP stack or application may
still need to reassemble the contents of a sequence of tunnel packets.

>
> I am willing to discuss methods here, but I guess several alternatives
> exists and thus which is most appropriate and the level of AMT support for
> them varies I would like the protocol designers to do a first stab at
> resolving this.
>
> Other Issues
> ======================================================================
>
> A) The table of content on page 2 should include more levels of headings.
> Most likely down to 4 is needed to make the TOC usable for finding content
> in the document.
>
> B) The claimed ASM support
> I would like to better understand how one can claim to support ASM when
> one has no up stream path to inject the ASM group participants traffic.
> When one uses ASM one normally does this for a reason and needing the
> possibility to inject packets into the group. These limitations needs to be
> clarified.
>

See above. The protocol is intended for multicast reception. It makes no
assumptions about application layer use of the multicast traffic. It can
only be used to receive ASM IP traffic.

>
>
> C) Section 4:
>
> This section indicates is its figures, the ones in Section 4.1.1 and
> Section 4.1.3.1 that the Router Mode IGMP/MLD functions are outside of AMT.
> Which based on the requirements in Section 5.3.3.4 is not accurate. That
> implementation must be AMT specific to maintain the AMT tunnel to group
> membership handling
>

Yes. The overview was intended to provide a purely informative description
of the protocol. In some cases, protocol details were described in the
abstract to simplify the text.

>
> D) Not all figures have handles that can be used to reference.
>

I never noticed that before. The XML2RFC tool does not appear to generate
figure numbers if the figure is not assigned an anchor tag. Will be fixed.

>
> E) Section 4.1.5.1:
>
>    Similarly, the selection of a unicast Relay address may be source-
>    dependent, as a relay contacted by a gateway to supply multicast
>    traffic must have native multicast connectivity to the traffic source
>
> I find this statement confusing. There is no support in the protocol for
> including the multicast group(s) which the gateway like to get in the
> discovery phase of the protocol.
>
>
You are correct - the protocol does not provide any means for checking
whether a relay can join a group. The intent was to simply state the
obvious. One might encode a group address within an anycast (or unicast)
address used to locate a relay, but such a approach is out of scope for the
protocol.

> F) AMT Gateway in home router.
> One deployment scenario is that the AMT gateway is deployed in the home
> network router to provide access to multicast groups provided by the ISP.
> However, the startup procedures in this deployment is unclear. The text
> appears to indicate that one can both have a gateway implementation that as
> soon as the router boots it starts doing discovery and requests to have
> Queries to send to its internal local network. Other suggestions appears to
> be to wait until some host actually request to join a group. The protocol
> specification appears to do its best to leave very much flexibility and
> thus produce huge variance in the market.
>

Intentional. Existing implementations use both.

>
> G) Figure 3:
> I find no discussion of Membership Updates to rejoin the groups after the
> tunnel has changed its source address as seen by the relay. This I think
> should have some discussion. Yes, it reasonably clear that you will get
> traffic just by sending new membership updates over the new tunnel.
> However, some discussion of the timing between teardown and this membership
> update should be considered. Figure 3 implies it should be sent after the
> teardown, which I think is correct due to the traffic volumes to the NAT
> most likely causing the path change.
>

The basic problem is that a relay has no way of detecting a change in the
source address associated with a gateway. The group discussed several
methods for detecting source address changes to eliminate the need to
reconstruct tunnel state, but these solutions were rejected to minimize
changes to the long-standing definition of the protocol.

>
> H) Figure in Section 4.2.2.2
> Propose that the external side of the NAT should be marked as the one
> having the "e" addresses.
>

Doesn't it already?

>
> I) Seeing the figure in Section 4.2.2.3 I definitely commented on the
> Address Collision issues. It is made somewhat clearer later on this. But,
> maybe an clearer section 4 sub-section to discuss this general issue that
> multiple left side host can have the same address as other behind other
> tunnel-end-points and thus there is need in the Relay to hide this from
> upstream and accept it and use the tunnel context to track the different
> hosts.
>

I don't believe there is any unique "tunnel context" that might be used to
track individual hosts. It would have been nice to have included nonces or
session IDs in the protocol, but the long standing version of the protocol
did not.

>
> J) Section 4.2.2.3:
>
>  To avoid placing an undue burden on the relay platform, the protocol
>    specifically allows zero-valued UDP checksums on the multicast data
>    messages.  This is not an issue in UDP over IPv4 as the UDP checksum
>    field may be set to zero.  However, this is a problem for UDP over
>    IPv6 as that protocol requires a valid, non-zero checksum in UDP
>    datagrams [RFC2460].  Messages sent over IPv6 with a UDP checksum of
>    zero may fail to reach the gateway.  This is a well known issue for
>    UDP-based tunneling protocols that is described
>    [I-D.ietf-6man-udpzero].  A recommended solution is described in
>    [I-D.ietf-6man-udpchecksums].
> I think this needs reformulating and I don't understand what is intended
> with the last sentence.
>
> I'm pretty sure the wording used here was generated as the end result of
group discussion. I think you might trace this in comments on the MBONED
list. Feel free to suggest an alternative.

> K) Section 5.1.1.
> "Destination UDP Port -  The IANA-assigned AMT port number."
>
>
>
> I find it strange that the protocol is mandating that all traffic is sent
>
> to the IANA assigned port. Why can't the protocol not allow more flexible handling
> of the destination port? I find one single thing in the protocol which prevents
> usage of an other relay listener port. That is that the Relay Advertisement would
>
>
>
>
> need a port field in addition to the address.
>
> Limiting AMT to a specific port allows for firewall control over the
protocol. A secondary benefit is that it allows for automatic dissection in
tools such as Wireshark.

That said, there is nothing to prohibit use of another port number in
restricted/private deployments of AMT. I would also not be surprised to see
use of well-known UDP port numbers in an attempt to deploy AMT in a manner
that would allow gateway hosts to circumvent firewall restrictions.

>
> L) Section 5.1.1.4
> A 32-bit random value generated by the gateway and echoed by the
>    relay in a Relay Advertisement message.
>
> Should the above value make it clear that it preferably should be a
> cryptographically random value as defined in RFC 4086?
>
> If I recall, there was no perceived advantage in using a such a value.
While the spec does indicate that the gateway should generate a random
value, an implementation might use a simple sequence number for the
purposes of logging or debugging.

>
> M) There is lack of specification in Section 5.1.1 of what one does if version
>
>
> The intent in 5.1 is to simply describe message formats. All have version
zero, so...

> is different from 0. This is mentioned in Section 5.3.3.1 but not for gateways
> and not all messages types.
>
>  Added version handling text to gateway section.

>
> N) Section 5.1.4.8:
>
>    The Querier's Query Interval Code (QQIC) field in the general query
>    is used by a relay to specify the time offset a gateway should use to
>    schedule a new three-way handshake to refresh the group membership
>    state within the relay (current time + Query Interval).
> In several places the QQIC and QRV are not made clear that this is defined in
> the external references for MLD and IGMP.
>
> Added references. Result seems a little verbose.

>
> O) Section 5:
> When specifying the bit-fields, please indicate the length of each field in the
>
>
>
>
> text. This is an accessibility question. If you have impaired vision interpreting
> the figures field length correctly can be different.
>
> I made a deliberate decision to leave the field lengths out. I based this
decision on the style used in other protocol RFCs in which fixed message
formats were used.

>
> P) Section 5.2.2.4:
>
>
> This section defined what retransmission parameters that one can potentially
>
>
> configure. However, the section fails to define what the max or min values that
> are acceptable are. Wrongly configured retransmission parameters can have significant
> negative impact on the network by causing bursts or unnecessary traffic.
>
> Largely because there was no consensus as to what values to use - I just
decided to allow an implementation or deployed component to use whatever
values seem appropriate.

>
> Q) Section 5.2.3.3:
> The gateway may continue to receive Multicast Data messages long
>    after the gateway sends a Membership Update message that deletes
>    existing group subscriptions.
>
> What is "long" in the above sentence. Are we talking some known number of seconds,
> a TCP MSL, i.e. 2 min?
>
> I'm not sure that it matters how "long" the interval is. The point is that
the gateway may continue to receive data messages. If a membership update
message fails to reach the relay, that period could equal the group timeout
period (120s?).

>
> R) Section 5.2.3.4.3
>    A gateway MAY retransmit a Relay Discovery message if it does not
>    receive a matching Relay Advertisement message within some timeout
>    period.  If the gateway retransmits the message multiple times, the
>    timeout period SHOULD be adjusted to provide an random exponential
>    back-off.  The RECOMMENDED timeout is a random value in the range
>    [initial_timeout, MIN(initial_timeout * 2^retry_count,
>    maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and
>    a RECOMMENDED maximum_timeout of 120 seconds (which is the
>    recommended minimum NAT mapping timeout described in [RFC4787]).
>
> I wonder if the above exponential backof is really what is desired. As it randomly
> picks the timeout between initial timout value and the 2^retry_count*initial_timeout it
>
>
>
>
> will be both lower biased and also capable of producing timing intervals that doesn't
> grow. If one desire to have random timeout to avoid some clock synchronization effects
> I think an algorithm that is Td = MIN(initial_timeout * 2^retry_count,
>    maximum_timeout) and where the actual timeout is random*Td and where random is a
> random value from the uniform distribution in the interval [0.5,1.5]. Will both ensure
> that the timout between two retransmissions never is less and on average grows with
>
>
>
>
> a factor two.
>
> This section is also not defining a minimal initial timout value, or any method for
> safely determine a more performant value from a safe initial value. To do a RTT
> measurement using the AMT control messages would require some extensions but
>
>
>
>
> could be a good way of deterimining a better initial value than 0.5 seconds which
> would be my recommendation for a default value.
>
> The retransmission behavior with exponential back-off was a pretty late
addition to the document. I'll have to give this more thought, though I
think it would work as-is.

> S) Section 5.2.3.4.4
>
>    If a gateway executes the relay discovery procedure at the start of
>    each membership update cycle and the relay address returned in the
>    latest Relay Advertisement message differs from the address returned
>    in a previous Relay Advertisement message, then the gateway SHOULD
>    send a Teardown message (if supported) to the old relay address,
>    using information from the last Membership Query message received
>    from that relay, as described in Section 5.2.3.7.  This behavior is
>    illustrated in the following diagram.
>
> This text and the figure after it does not appear to be consistent.
> The figure implies a timer that isn't present in the above. The textual
> description appears sensitive to flapping anycast routing. I think
> the figures indication of some higher timeout before redoing Relay discovery
> appears much more robust.
>
> OK. At some point, I had to trade off consistency for legibility. There
are several examples throughout the document where the text and figures
might not be 100% consistent. I have to assume that the document has
provided the context required to interpret the text and figures, otherwise
I could spend months attempting to describe every scenario in the text and
ASCII art. I tried my best.

> T) Section 5.2.3.5.3
> See R)
> Also this text appears redundant to previous text. Maybe generalize this
>
>
>
>
> into its own section being used in general for all messages needing retransmission
>
>
Good idea, but would require more changes than I feel comfortable making at
this point.

>
> U) Section 5.2.3.5.4
>    Querier's Query Interval Code carried by the general-query.  A
>    gateway MAY use a smaller timer duration if required to refresh a NAT
>    mapping that would otherwise timeout.
>
> Maybe the protocol would rather need a NAT keep-alive message to be sent
> from the gateway to the relay. But maybe the Request, Query cycle is light weight
> enough that this works fine.
>
> Yes.

>
>
> V) Section 5.2.3.6.1
>
> o  Insert IGMP or MLD datagrams into a queue for transmission after
>       it receives a Membership Query message.
>
> What assumptions of queue depth exist in the above. Clearly the messages in this
> queue should expire if they become to old.
>
> No assumptions made. I don't even like the idea of queuing IGMP/MLD
messages for eventual delivery. I basically treated the queuing behavior as
out of scope because I didn't want to complicate things any further.

>
> X) Section 5.2.3.7
> Gateway support for the Teardown message is OPTIONAL but RECOMMENDED.
>
>
>
>
> The above is a very strange usage of RFC 2119 keywords. IF you use the synonyms
> then maybe the error of writing it this way is clear.
> Gateway MAY support for the Teardown message but SHOULD.
>
> Will be fixed.

> Y) The usage of retransmission versus repetitions are not always clear.
>
>
>
>
> Some of the messages appears to simply need to be repeated QRV number of times with
> some interval. Others should really be matched with an answer and if not received within
> timeout retransmitted. Can these two cases be made more clear?
>
>
>
>
> Z) Section 5.3.5
>    The hash function RECOMMENDED for use in computing the Response MAC
>    is the MD5 hash digest [RFC1321], though hash functions or keyed-hash
>    functions of greater cryptographic strength may be used.
>
> I think this points to a security vulnerability. I think it needs to be made clear
> that the MAC MUST be keyed. If it is just a digest, then an attacker can calculate the
> MAC and perform an off-path attack.
>
> I don't think it matters whether one computes a hash value that includes a
private secret, or uses a private secret to compute a "keyed" hash. The end
result is the same.

>
> This should be made clear also in Section 6.1 to be a requirement.
>
> AA) Section A.1:
>
> Altough this proposals has its advantages I think it might also illustrate a
>
>
>
> short-coming. First of all 48-bits is quite short for a MAC. I would prefer a
> variable length field.
>
> I agree. Unfortunately, preliminary implementations of the protocol have
been around for so long that group members did not want to change the MAC
size. That said, one negative side-effect of using a larger MAC value would
be increased fragmentation of data message packets.

>
> Secondly, doesn't this actually create more material for an attacker to determine
>
> the key used by the relay?
>
>
>
> That was all I have found.
>
>
Thanks!

>
> Cheers
>
> Magnus
>
>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>
>

-- 
Greg Bumgardner
Eugene, OR

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 9 Jan 2013 15:15:41 +0100

Hi Greg,

I'm joining the discussion as the DISCUSS holder for most of the issues 
below.

On 01/09/2013 03:26 AM, Greg Bumgardner wrote:
> Magnus,
>
> I would like to thank you for providing valuable feedback regarding the
> AMT spec.
>
> alternative solutions were identified but ultimately rejected by the
> group, primarily due to the reluctance of group members to make
> significant changes to the protocol after several years of slow
> development. My comments are inlined below...

Can you give some insights why the protocol development took so long?

Anyhow, I can understand the reluctance of changing parts of a protocol 
after such a long time. But there are a lot of rough edges in the 
protocol that need attention before moving it forward on the Standards 
Track.

>
> Thanks,
>
> -g.b.
>
>
> On Wed, Dec 26, 2012 at 5:01 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>
>     Sorry for being late with this IETF last call comments. I will
>     partly blame the ADs requesting this Transport Directorate review a
>     bit late, the other part is all mine and the holidays. Anyway, I do
>     hope you will consider these issues and comments as I believe I
>     found some serious ones in addition to a number of clarifications
>     that should be made.
>
>
>     Significant Issues:
>
>     1. Congestion Control
>     This is clearly a tunnel establishment protocol of something that is
>     IP traffic. Thus normally the responsibility for congestion control
>     is with the tunnelled traffic. However, I would like argue that this
>     does not apply in this case due to the nature of the tunnelled
>     traffic, i.e. multicast traffic and secondary due to limitations in
>     the tunnel protocol.
>
>     Lets start with the second part. This protocol claims to support ASM
>     still don't provide a upstream delivery mechanism, i.e. an ASM
>     receiver is not capable of sending as it should. This prevents
>     several existing mechanism for congestion control that exist in
>     protocols supporting multicast. The first is using RTCP for
>     congestion control in ASM [RFC3550], the second isTCP-Friendly
>     Multicast Congestion Control [RFC4654] that can be used in the RMT
>     suite of protocols, and I know has been implemented in some NORM
>     implementation. Thus onlystrictly receiver based mechanisms, such as
>     Wave and Equation Based Rate Control [RFC3738] are available in this
>     context.
>
>
> teleconferencing. The protocol is primarily intended for use in
> receiving SSM traffic. Because the AMT protocol uses IGMP/MLD messages
> to establish reception/subscription state, the protocol MAY be used to
> subscribe to ASM broadcasts, but cannot generate them.
>
> I should note that earlier versions of the AMT spec described a method
> for broadcasting SSM via a gateway/relay tunnel, but this capability was

This means that the draft should state that it does not support ASM, but 
only a subset of it. Further, it cuts away the feedback over RTCP and 
RFC 4654.

>     congestion control. This based on that the deploying entity controls
>     the scope and authorization for requesting multicast delivery.
>     However, does restrictions does not apply to AMT delivery of
>     multicast. If the gateway can reach using unicast the relay it can
>     be delivered the multicast group from the domain the relay is
>     attached to. Thus, this protocol changes the deployment restrictions
>     of multicast which many non-congestion controlled delivery is based
>     on. Instead the non-congestion controlled trafficcan now sent over
>     an IP/UDP tunnel over Internet where neither relay nor gateway may
> responsibility. While we might have attempted to provide some level of
> QoS control on tunnel packets by copying ToS/DS bits from inner to outer

What's the group's view on how the application layer is handling 
congestion control in this case when using AMT?

> delivery of UDP packets (perhaps restricted by relay/router
> configuration). Perhaps you could suggest some text.

There are multiple issues here:
- there is no feedback loop between relay and gateway so that any 
information about the tunneled multicast traffic can be sent back from 
the gateway to the relay. This feedback loop can be used for congestion 
control, but also to figure out if the non-zero IPv6/UDP traffic gets 
black holed somewhere.
- the tunneled traffic can exceed the capacity of the network path 
between relay and gateway. This needs to be monitored and acted upon any 
congestion.
- since a single relay can feed many gateways, even tunneled multicast 
flows from the same relay can compete for network path capacity. I.e., 
if the tunneled traffic shares a network path. In the worst case, an 
added multicast flow can lead to congestion for all other tunneled 
multicast flows.
- any tunneled flow can impact other traffic from other hosts in the 
Internet.

>
>     Secondly, I think this protocol should have an applicability
>     statement limiting its deployment to restricted environments where
>     the relay and gateway deployers can provide certain resource
>     provisions between the entities to avoid the multicast traffic
>     affecting other traffic sharing the same bottlenecksin ways not
>     allowed by the network provider.
>
>
> While I understand your concern, this would essentially negate the
> entire reason for the protocol, which is to provide multicast transit to
> non-multicast connected receivers. However, the AMT spec does not
> preclude the implementation/deployment of AMT-enabled gateway devices
> for which AMT support may be enabled or disabled (or blocked via a
> firewall).

The point is that it is not safe to operate in the public Internet with 
the current protocol. Either with fix the issues in the protocol or we 
limit the applicability.

>
>
>
>     2. Security
>
>     This protocols is frank with it having limited security features and
>     says this is similar to the IGMP and MLD protocols being used.
>     However, I think this is a failure to propoerly consider the threat
>     model. If one uses AMT over general Internet it will run in a
>     network where the one deploying the multicast and the relays no
>     longer control requirements on source address verification or
>     possibilities for traffic separation as they can do within the
>     domains where multicast currently are deployed. The security
>     vulnerabilities in IGMP and MLD are much more contained and
>     controllable in a LAN environment where one has chosen to deploy
>     multicast compared to an Relay exposing this to the whole Internet.
>     Once more I think there is only two choices here.
>
>     minimal provide a real model for gateway authentication using
>     identities, not only return routability based verifications.
>
>     B) Limit the applicability of AMT to managed environments and make
>     it clear that the relay will need to limit which gateways are
>     allowed to access the relay based on addressing.
>
>     Based on the first significant issue with congestion control I
>     expect that there is little meaning to do A) unless also one is
>     willing to beef up AMT to provide congestion control. Which I think
>     is not according to the design wishes for the protocol designers.
>
>
> The security topic was visited and revisited numerous times over the
> last couple of years. The group made the decision to limit the protocol
> to simple source address verification and leave it at that. An emphasis
> was placed on protecting relays against simple DoS attacks but not gateways.

I can see the point, but I assume that most people are just looking to 
closed environments, e.g., multicast in access networks, such as xDSL or 
3GPP. However, AMT assumes to run across the public Internet and threats 
are extremely different there. Magnus made a good proposal that is 
relatively easy to implement.

>     draft-ietf-6man-udpchecksums-06
>     <http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/> and
>     draft-ietf-6man-udpzero-08
>     <http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/>. Nothing
>     against this in principal. However, I have noticed that AMT fails to
>     properly address the failure modes of using a zero-checksum. AMT is
>     a typical example of a protocol that actually need active
>     verification of each tunnel that zero-checksum functions. This as
>     AMT is clearly intended to be deployed with its Gateway part in
>     end-hosts and residential network devices or routers. This means the
>     tunnel will pass through both firewalls and NATs on its path between
>     the relay and the gateway. Unless these devices are not upgraded to
>     support zero-checksum in UDP for IPv6 the traffic may actually
>     become black holed. The most likely is a simple firewall that has a
>     rule for IPv6/UDP which doesn't allow zero checksum as it is against
>     RFC 2460. Thus all the Multicast data packets will disappear on
>     route in the tunnel. There is no mechanism in the AMT protocol to
>     detect this and negotiate with the relay so that it will not use the
>     zero-checksum for this tunnel.
>
>     This must be addressed as I see it. If not the AMT will be so
>     brittle that it can't be used in a large number of its intended
>     deployments.
>
>

There is a solution, as mentioned above: feedback loop. If the relay 
says "sending you x packets" and the gateway sees zero, there is an 
issue. In the easiest case, a log file entry is generate saying that the 
tunneled traffic couldn't reach this particular gateway.

>
>
>     4) MTU issues
>
>     This document total fails to discuss the issues of MTU blackholing.
>     As the IP multicast datagrams as well as the encapsulated IGMP/MLD
>     messages can with the added tunnel-overhead result in that the sent
>     packet exceeds the MTU of the path, these packets could be black
>     holed. This can potentially result in very intermittent transport
>     behavior for the tunnel. Thus, some discussion of how do handle the
>     MTU issues in this context should be introduced.
>
>
> Yep. This could be a problem that has no easy solution. Not only might
> the outer packets be fragmented, but the encapsulated packets might be
> source packets, it cannot really avoid the potential need to fragment
> the tunnel packets. A gateway can only rely on the underlying UDP/IP
> stack to provide the necessary reassembly of the tunnel packets. Once
> the tunnel packet has been reassembled, the gateway, host IP stack or
> application may still need to reassemble the contents of a sequence of
> tunnel packets.

In the case the WG doesn't have any solution, which I couldn't believe, 
it is worth to document the issues. One operational solution can be to 
limit the MTU in the native multicast network, if this part and the 
relay are under the same administrative control. However, this would 
require that the AMT relay logs any issue with the MTU accross the tunnel.
Further, Magnus point is about that the tunneled packets can get 
fragmented, less about the inner parts of the tunnel.

Addressing the MTU issue will increase the viability of this a lot.

>
>
>     I am willing to discuss methods here, but I guess several
>     alternatives exists and thus which is most appropriate and the level
>     of AMT support for them varies I would like the protocol designers
>     to do a first stab at resolving this.
>
>     Other Issues
>     A) The table of content on page 2 should include more levels of
>     headings. Most likely down to 4 is needed to make the TOC usable for
>     finding content in the document.
>
>     I would like to better understand how one can claim to support ASM
>     when one has no up stream path to inject the ASM group participants
>     traffic. When one uses ASM one normally does this for a reason and
>     needing the possibility to inject packets into the group. These
>     limitations needs to be clarified.
>
>

Document it, please. Otherwise, the draft is incomplete.

Thank you,

   Martin
-- 
IETF Transport Area Director

[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 10 Jan 2013 08:35:33 -0800

> Can you give some insights why the protocol development took so long?

Yes, I can, though I'm not sure how relevant the incubation period is
to its adoption. And since I've breaking multicast networks for 15+
years now, asking a question like this may get you more than you were
expecting :)

The need for multicast transition services is as old as multicast
itself. Deering's first work - DVMRP - had to assume there was no
'native' path and so incorporated encapsulation as an integral part of
the protocol. I believe DVMRP may be the first use of overlay
encapsulation in the IETF, but I welcome you to dig for your self and
back with me. It's the earliest I've been able to find.

Once we moved to PIM, encapsulation for receiver delivery was thrown
out and we all pushed to "go native". The reality was - and still is -
that those most wanting end-to-end native multicast (content owners)
had no way to motivate network operators to enable multicast services.
Deployment experience with PIM revealed to many the need for
encapsulation overlay mechanism, and from this several drafts were
introduced.

In 2003 we held a BOF at IETF57 with the intention of agreeing on a
list of requirements and consolidating the efforts into a single
draft. We selected the AMT draft as being the closest fit, though
significant changes still need to be addressed. You see the list of
drafts and read the BOF minutes here:

http://www.ietf.org/meeting/57/session/mlm.txt

Authors came and went.. Progress was slow, until ATT picked up the
torch, demonstrated running code, and outlined their deployment plans.
Greg Bumgardner also wrote a java Gateway implementation and took over
as primary author. Finally we had solid industry support and a
qualified and motivated set of contributors.

Last year we finally reached WG consensus, along with at least three
shipping implementations of both the Relay and the Gateway , and at
least one active and growing commercial deployment of a
IPMulticast/AMT service. I doubt many drafts in the editors' queue can
claim that much support. :)

> after such a long time. But there are a lot of rough edges in the protocol
> that need attention before moving it forward on the Standards Track.

Time is irrelevant to any reluctance to change - commercial
implementations and deployments are, however quite relevant.

Cheers,
Greg

> only a subset of it. Further, it cuts away the feedback over RTCP and RFC
> 4654.
>
>>
>>
> What's the group's view on how the application layer is handling congestion
> control in this case when using AMT?
>
>
>>
>>
> information about the tunneled multicast traffic can be sent back from the
> gateway to the relay. This feedback loop can be used for congestion control,
> but also to figure out if the non-zero IPv6/UDP traffic gets black holed
> somewhere.
> - the tunneled traffic can exceed the capacity of the network path between
> relay and gateway. This needs to be monitored and acted upon any congestion.
> - since a single relay can feed many gateways, even tunneled multicast flows
> from the same relay can compete for network path capacity. I.e., if the
> tunneled traffic shares a network path. In the worst case, an added
> multicast flow can lead to congestion for all other tunneled multicast
> flows.
> The point is that it is not safe to operate in the public Internet with the
> current protocol. Either with fix the issues in the protocol or we limit the
> applicability.
>
>
>>
>>
>>
>>     2. Security
>>
> 3GPP. However, AMT assumes to run across the public Internet and threats are
> extremely different there. Magnus made a good proposal that is relatively
> easy to implement.
>
>>
>>
>>     3. Use of Zero Checksum
>>
> There is a solution, as mentioned above: feedback loop. If the relay says
> "sending you x packets" and the gateway sees zero, there is an issue. In the
> easiest case, a log file entry is generate saying that the tunneled traffic
> couldn't reach this particular gateway.
>
>
>>
>>
>>     4) MTU issues
>>
> In the case the WG doesn't have any solution, which I couldn't believe, it
> is worth to document the issues. One operational solution can be to limit
> the MTU in the native multicast network, if this part and the relay are
> under the same administrative control. However, this would require that the
> AMT relay logs any issue with the MTU accross the tunnel.
> Further, Magnus point is about that the tunneled packets can get fragmented,
> less about the inner parts of the tunnel.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Jan 2013 09:53:57 +0100

Hi,

I think the major question here, are anyone really objecting to
restricting the applicability of AMT to managed environments, i.e. where
the full path between relay and client are in domains that are
explicitly aware that they will have AMT traffic and approve of it. The
comments appears to indicate that this is where it is deployed. If one
makes such an applicability statement most of the significant comments
can be more easily resolved.

Cheers

Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 16 Jan 2013 06:04:07 -0800

Why would you require such restriction? If your concern is about
support for RTCP we already have RFC 5760 to address this. It's an
application layer problem.

Greg

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 16 Jan 2013 07:19:20 -0800

On Wed, Jan 16, 2013 at 7:11 AM, Eggert, Lars <[email-masked]> wrote:
> Hi,
>
> On Jan 16, 2013, at 16:04, Greg Shepherd <[email-masked]> wrote:
>> So some MUST have congestion control text in the spec would be
>> sufficient?
>
> Or an applicability statement that limits AMT to managed environments, as Magnus has pointed out.

That is far from the target deployment. I think an applicability
statement requiring the use of an application-layer CG mechanism
should be enough. It would carry no less weight than a 'managed env'
statement and would actually be more helpful.

>> How would you suggest detecting this without overloading
>> the protocol?
>
> I don't know what you mean with "overloading the protocol." Obviously, you'll need to have some mechanism that detects loss and some mechanism that tracks the bandwidth use of the tunneled flow. It's going to need some protocol machinery. And, I guess TSVWG would really want to review that algorithm in detail.

AMT is architected to minimize the load on the Relay, so that current
router equipment can provide Relay services with minimum impact.
Having to monitor every flow to detect CG would be a ridiculous amount
of overloading and render the protocol useless.

> Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Jan 2013 17:52:26 +0100

> statement and would actually be more helpful.

Yes, the restriction can also be on the application layer to require
them to congestion controlled. But frankly how many of the multicast
deployed applications actually are congestion controlled? IPTV using
MPEG transport streams over UDP is definitely not congestion controlled.

Sure, they should be congestion controlled, however IPTV is deployed in
managed networks where the operator deploying the IPTV has the full
control and responsibility for the path. With AMT I can start breaking
this by having the AMT client be located far from the network the relay
belongs to.

With AMT not supporting ASM, the solutions for congestion control that
can function are the receiver driven ones and the ones that uses its own
unicast feedback to deal with SSM.

> 
>>> How would you suggest detecting this without overloading the
>>> protocol?
>> 
>> I don't know what you mean with "overloading the protocol."
>> Obviously, you'll need to have some mechanism that detects loss and
>> some mechanism that tracks the bandwidth use of the tunneled flow.
>> It's going to need some protocol machinery. And, I guess TSVWG
>> would really want to review that algorithm in detail.
> 
> AMT is architected to minimize the load on the Relay, so that
> current router equipment can provide Relay services with minimum
> impact. Having to monitor every flow to detect CG would be a
> ridiculous amount of overloading and render the protocol useless.

Might be so. But AMT is creating the issue of moving likely
non-congestion controlled traffic into the general Internet without
making any attempt to address that aspect. That is not acceptable in a
standards track protocol. Not even in an experimental one that hasn't
have limited applicability. Especially as we are talking about
applications that commonly include multi mbps packet streams such as HD
TV etc.

Cheers

Magnus Westerlund

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 16 Jan 2013 14:49:15 +0000

> application layer problem.

AMT is a tunneling scheme that can cause non-congestion controlled traffic to be tunneled over the wider Internet. Internet flows need to implement a congestion control mechanism (RFC2914). Because AMT can be used transparently, i.e., without the application knowing, this makes it AMT's problem and not the application's. (In other words, without AMT, that traffic would not hit the wider Internet.)

The only scenario where it's OK to run non-congestion-controlled flows over the wider Internet is if the path capacity has been provisioned accordingly (i.e., in a managed environment).

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 16 Jan 2013 15:24:59 +0000

Hi,

> statement and would actually be more helpful.

is there a multicast CC algorithm that can be pointed to as an existence proof?

> of overloading and render the protocol useless.

So maybe the requirements that have been placed on AMT cannot be met under the principles that we all have come to consensus on for the Internet. In that case, those principles win. RFC2914 predates (even) the first AMT draft, so this shouldn't really be news.

Lars

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 16 Jan 2013 12:22:52 -0800

On Wed, Jan 16, 2013 at 8:52 AM, Magnus Westerlund
<[email-masked]> wrote:
> them to congestion controlled.

Excellent.

> But frankly how many of the multicast

Is the absolute count of solutions relevant? I can get you a count if
that is deemed necessary. With the expanding deployment of AMT and the
above CG requirement I'd expect many more solutions to develop.

> this by having the AMT client be located far from the network the relay

..and IPTV is within a managed env where there is also end-to-end
network control so mcast discontinuity is less of an issue, and AMT is
not required. If IPTV is to expand beyond the managed env and adopt
AMT to address mcast discontinuity then the content originator will
need to adopt an application layer CG mechanism as required by the
spec.

> With AMT not supporting ASM,..

AMT does not support sourcing from the Gateway - it does support ASM
joins. Just a nit here, but I understand your point.

>..the solutions for congestion control that

Agreed. And they exist. Specifying the need to use one is an excellent
suggestion, thanks.

Greg

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 17 Jan 2013 16:16:24 +0100

> application layer problem.

RFC 5760 has some nice security considerations, e.g., possible attacks 
on the Receiver-to-Distribution-Source Communication. It might be also 
good to document how AMT in conjunction with RFC 5760 is handled in 
actual deployments. E.g., AMT can introduce new issues, as the multicast 
source is located in a firewall protected network that blocks RTCP 
traffic coming from receivers somewhere else in the Internet.

AMT should discuss and document the changes in the deployment model as 
described in RFC 5760.

   Martin

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 17 Jan 2013 07:22:09 -0800

On Thu, Jan 17, 2013 at 7:16 AM, Martin Stiemerling
<[email-masked]> wrote:
> RFC 5760 has some nice security considerations, e.g., possible attacks on
> the Receiver-to-Distribution-Source Communication. It might be also good to
> document how AMT in conjunction with RFC 5760 is handled in actual
> deployments. E.g., AMT can introduce new issues, as the multicast source is
> located in a firewall protected network that blocks RTCP traffic coming from
> receivers somewhere else in the Internet.

Sourcing SSM content services behind a RTCP-blocking firewall while
expecting RTCP feedback from receivers is a massive operator error.

> AMT should discuss and document the changes in the deployment model as

Wouldn't this be more suited for an AMT BCP draft?

Greg

>>>>> protocol
>>>>> RFC
>>>>> the
>>>>> between
>>>>> flows
>>>>> the
>>>>> says
>>>>> it
>>>>> fragmented,