Automatic Multicast Tunneling
Note: This ballot was opened for revision 14 and is now closed.
(Ron Bonica) Yes
(Joel Jaeggli) Yes
Comment (2013-03-26 for -14)
While I'm happy to work to document or ameliorate the Transport area's concern that unicast encapsulation is not sensitive to to congestion control, fundamentally multicast encapsulation never has been. While some applications that leverage multicast are adaptive to loss most are not. AMT doesn't really change that situation.
(Jari Arkko) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
Benoit Claise (was Discuss) No Objection
Comment (2013-07-16 for -17)
1. From this figure ... Isolated Site | Unicast Network | Native Multicast | (Internet) | | | | | | Group Membership | +-------+ ===========================> +-------+ Multicast +------+ |Gateway| | | | Relay |<----//----|Source| +-------+ <=========================== +-------+ +------+ | Multicast Data | | | | | Figure 1: Basic AMT Architecture ... I was not sure whether the left part of the gateway was IP unicast of multicast. It's only when I saw the following figure that I understood. Gateway Relay General _____ _____ ___________ Query | | | | Query ___________ | |<------| | | |<------| | | Host Mode | | AMT | | AMT | |Router Mode| | IGMP/MLD | | | UDP | | | IGMP/MLD | |___________|------>| |<----->| |------>|___________| Report | | | | Report Leave/Done | | | | Leave/Done | | | | IP Multicast <------| | | |<------ IP Multicast |_____| |_____| Multicast Reception State Managed By IGMP/MLD It might be better to clarify it earlier in the draft
Spencer Dawkins No Objection
(Ralph Droms) No Objection
Comment (2013-01-09 for -14)
I have one small clarification to ask about. In section 184.108.40.206, in reference to the text: The IGMP and MLD protocol specifications indicate that senders SHOULD use a link-local source IP address in message datagrams. This requirement must be relaxed for AMT because gateways and relays do not share a common subnet. is the requirement being relaxed that senders use a source IP address of greater than link-scope or that the the relay IGMP and MLD implementations accept a message with a link-local source IP address from a sender that is not on-link?
(Wesley Eddy) No Objection
Comment (2013-01-09 for -14)
I fully agree with the issues in Martin's DISCUSS.
(Adrian Farrel) No Objection
Comment (2013-01-07 for -14)
I have no objeciton ot the publication of this document as an RFC, but some comments from the Routing Directorate review by Dimitri Papadimitriou are included below. I agree with these comments and have updated the text with my own queries. You may be able to address these comments with email or small changes to the text. --- Section 4.1 states A gateway or relay implementation does not necessarily require a fully-functional, conforming implementation of IGMP or MLD to adhere to this specification, but the protocol description that appears in this document assumes that this is the case. I am not sure what this statement intends to actually say. Similar statement is made in Section 5.2.1 --- Section 220.127.116.11. Figure seem to imply only PIM-SM can be used? Is this the intention? if so, it might be a good idea to call it out in the text. If not, maybe make clear that the figure is only an example. --- Section 18.104.22.168 Any specific reason to impose a "provider-specific relay discovery mechanism" or "a private anycast address" to obtain access to these relays. What prevents making them "publically accessible"? --- Section 22.214.171.124 The concept of "unicast Relay" and "unicast Relay address" appears for the first time but isn't yet defined. --- Section 126.96.36.199 Means by which the "Relay Discovery Address" is being advertised should be documented or referenced. --- Section 188.8.131.52 point 2 How can the GTW verify that the responder (or the entity responding on behalf of it) is the actually the RELAY it pretends to be? --- Section 184.108.40.206 This section doesn't provide any details concerning timing, error situations (what happens when a message is lost?), and means to overcome such situations. Further down the text (Section 5.2.X/5.3.X) these details are provided so maybe just add a forward pointer. --- Section 220.127.116.11 What is the default setting for the timer mentioned in "Each time the gateway receives a Membership Query message it starts a timer..." --- Section 18.104.22.168 point 3 Expand the acronym QQIC --- Section 22.214.171.124 point 10 Usually one refers to a stream of mcast messages, so does the relay encaspulate messages 1 by 1? What happens if the incoming message is too long to be transmitted towards the gateway? --- Section 126.96.36.199 Where you say "or the relay receives a valid Teardown message from the gateway" please at a pointer to the next section. --- Section 188.8.131.52 The text seems to imply that the message SHALL only be used in the conditions described in that Section, but prevents other usage e.g. sending a Teardown without prior Membership Query/Update message. Is this really the intent? --- Section 184.108.40.206 The philosophy seems to be that a GTW may receive incoming mcast traffic from the Relay after a long waiting period, but in this case all listeners might have "left". How comfortable are you that this type of asynchronous mode will be effective? --- Section 5.1.3 It looks really odd to put the P flag in the middle of the two reserved fields. I can see you intend one byte of flags (with seven flags reserved) and two bytes of pure reserved field. If this was your intent, I think you should label the first reserved field as "Flags" and set up an IANA registry (including allocation policy) for the rest of the flags. OTOH if you want the reserved fields to be completely available for any future use, then perhaps you should put the P flag in bit 8. --- Section 220.127.116.11 Should you be concerned about traffic ordering issues in the exchange between Relay downward to the GTW as there is intermediate processing on both entities? --- Section 6 You say AMT is not intended to be a strongly secured protocol and give the argument to make the protocol light-weight You could enhance the security with minimal cost by including a key (cf. e.g. RFC 2890) in the IP multicast traffic encapsulation format to prevent network relays resulting in unwanted traffic to the end-user. --- Section 6.2 The AMT protocol provides no means for detecting or defending against a man-in-the-middle attack - any such functionality must be provided by multicast receiver applications through independent detection and validation of incoming multicast datagrams. You might at least tell us what action you recommend if the receiver detects such a problem.
(Stephen Farrell) (was Discuss) No Objection
Thanks for handling my discuss points (and apologies for being slow to check the new text before you posted -18). I didn't check if these comments are still relevant for -18 but have left them here just in case. - 11 years. Wow! Kudos for being persistent! - p11, in the figure (my ascii-art sympathies btw;-), why is the application dealing with multicast data via UDP only? - Its not that common to have a field called a nonce and yet have that sent in multiple messages. Maybe this is more a kind of session id? - 5.1.2 - it'd have been nicer to have a length field for the nonce or relay address so that you could vary the nonce length without confusing matters. Seems like there're enough unused bits to do that if you wanted. - 5.1.5/5.1.6: What if the encapsulated packet is bigger than the MTU, isn't that a problem? - 5.1.6: Oughtn't you say something about congestion and being TCP friendly? - Section 6: I always think that trying to be "as secure as <<some insecure thing>>" is a bad goal to select. - A.1 and 5.3.5 show MD5 inputs in different orders. They ought be the same.
(Brian Haberman) (was Discuss) No Objection
(Russ Housley) No Objection
Comment (2012-12-17 for -14)
The reference to RFC 1321 should be informative (not normative). Please consider the editorial suggestions in the Gen-ART Review by Mary Barnes on 14-Dec-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07993.html
(Barry Leiba) (was Discuss) No Objection
Comment (2013-01-01 for -14)
This is an exceptionally well written document, and was generally easy to understand. Ron, thanks for fixing my DISCUSS point in an RFC Editor note. What remain are a few non-blocking comments. I think that addressing these will make the document a little better; feel free to chat with me about them if you like. -- Section 4 -- This may be implicit in what the paragraph in Section 4 says, and perhaps Sections 4.x and 5.x are entirely consistent and no one will find any errata, but there's a lot here, and just in case there's something we don't catch... ...might it be reasonable to add a sentence such as this to the paragraph in Section 4?: "If anything in Section 4 is inconsistent with or contradictory to something in Section 5, the text in Section 5 is definitive." -- Throughout Section 5 -- You've mostly consistently used the phrase "IANA-assigned AMT port number" to represent port 2268 [Section 7.3]. Mostly, except for the following: 5.1.5 uses "IANA-assigned AMT UDP port number" (adds "UDP") 18.104.22.168.2 uses "IANA-assigned UDP port number" (omits "AMT" and adds "UDP") 22.214.171.124 uses "IANA-assigned port" (omits "AMT" and "number") It's probably useful to fix those three so that all uses are exactly the same. Also, a "(see Section 7.3)" at the first instance, in Section 5.1.1, wouldn't be bad. -- Sections 126.96.36.199.5, 188.8.131.52.6, and 5.3.6 -- These all refer to "a cryptographically secure pseudo random number generator." Would they benefit from an informative reference to RFC 4086? -- Section 5.3.5 -- A Response MAC is produced by a hash digest computation. A Response MAC value is computed from a Request message for inclusion in a Membership Query message, is computed from a Membership Update message to authenticate the Response MAC carried within that message, and is computed from fields in a Teardown message to authenticate the Response MAC carried within that message. I had to read this a few times to parse it correctly. Once I got it, I found that there's nothing wrong with it... but maybe we can make people work less hard this way?: NEW A Response MAC is produced by a hash digest computation. A Response MAC value is computed in three situations: from a Request message, for inclusion in a Membership Query message; from a Membership Update message, to authenticate the Response MAC carried within that message; and from fields in a Teardown message, to authenticate the Response MAC carried within that message. END Gateways treat the Response MAC field as an opaque value, so a relay implementation may generate the MAC using any method available to it. 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. Why is this a 2119 "RECOMMENDED"? Is there any reason the *protocol* cares what hash algorithm is used? -- Section 184.108.40.206 -- If a relay supports the Teardown message, it MUST set the G-flag in the Membership Query message and return the source IP address and UDP port carried by the Request message in the corresponding Gateway IP Address and Gateway Port Number fields. If the relay does not support the Teardown message it SHOULD NOT set these fields as this may cause the gateway to generate unnecessary Teardown messages. What reason might a relay have for violating that SHOULD NOT? Why would a relay that does not support Teardown sometimes need to set those fields, such that "SHOULD NOT" (rather than "MUST NOT") is necessary? -- Section 220.127.116.11 -- A relay MUST maintain some form of group membership database for each endpoint. The per-endpoint databases are used update a forwarding table containing entries that map an (*,G) or (S,G) subscription to a list of tunnel endpoints. A relay MUST maintain some form of group membership database representing a merger of the group membership databases of all endpoints. The merged group membership database is used to update upstream multicast forwarding state. A relay MUST maintain a forwarding table that maps each unique (*,G) and (S,G) subscription to a list of tunnel endpoints. A relay uses this forwarding table to provide the destination address when performing UDP/IP encapsulation of the incoming multicast IP datagrams to form Multicast Data messages. I don't really want to pick on these too much, mostly because I can't imagine how *else* you might do this other than maintaining databases/tables, but... Strictly speaking, the 2119 keywords should be calling out protocol requirements, not implementation methods. It seems that the requirements are actually in the second sentence of each paragraph, and the MUSTs should be attached to those. I'll use the second one as an example; perhaps this?: NEW-maybe A relay MUST be able to update the upstream multicast forwarding state [a little more is needed here]. This is typically done by having the relay maintain some form of group membership database representing a merger of the group membership databases of all endpoints. END I would prefer it if you could re-cast each of these three paragraphs to attach the MUST to the actual protocol requirement, and talk about databases and forwarding tables as exemplary implementations (rather than attaching the MUST to the implementation). That said, I'll remind you that this is a non-blocking comment, and if you think it will make the spec more awkward or less clear, then please don't do that.
Kathleen Moriarty No Objection
Comment (2014-06-26 for -17)
I didn't have time to do a full review, but did check on previous comments from Sean Turner to see if they were addressed. I think it would be very helpful to address them, so a little additional info is given here on sections. I think they were meant to fit in with Stephen's #2 discuss, I think. From Sean: a. [RFC6151] recommends against the use of MD5 as you've documented it. If you need any kind of collision resistance MD5 is inappropriate to use. If you don't care about collisions resistance, then I think you need to explicitly state that in the security considerations. MD5 is okay to use in an HMAC though, but there are better choices out there for "new" protocols. Reference to Sean's comment with sections: b. It doesn't appear that Sean Turner's comment on nonce creation was addressed in 18.104.22.168.5 and 22.214.171.124.6 A reference to the RFC he mentioned would be helpful. Here is Sean's comment: [RFC4949]: $ nonce (I) A random or non-repeating value that is included in data exchanged by a protocol, usually for the purpose of guaranteeing liveness and thus detecting and protecting against replay attacks. (See: fresh.) c. Again, from Sean's review, it looks like protections of the secret key were not added in section 5.3.6. I think this is important. Sean's #4: I don't see a reference to RFC4086?
(Pete Resnick) No Objection
(Robert Sparks) No Objection
Comment (2013-01-09 for -14)
I couldn't find where the document explicitly calls out how to represent the IP addresses in the binary fields - you almost certainly intend for them to be in network-byte-order, but if it's not already explicit in the document, please make it so. Are there any considerations that the document should call out for administrators for making the transition when the network from which hosts had been using AMT to reach content is given native multicast connectivity?
(Sean Turner) No Objection
Comment (2013-01-09 for -14)
0) I agree with Martin's 4th discuss (the security one). 1) I agree with Stephen's 1st discuss also. 2) I also agree with Stephen's 2nd discuss, but I've got a bit more: a) [RFC6151] recommends against the use of MD5 as you've documented it. If you need any kind of collision resistance MD5 is inappropriate to use. If you don't care about collisions resistance, then I think you need to explicitly state that in the security considerations. MD5 is okay to use in an HMAC though, but there are better choices out there for "new" protocols. b) If you're going to retain the secret key, then some words about protecting the secret are needed. We can revisit this after the dust has settled on Stephen's discusses. 3) And on his "nonce" comment, yeah I really think it's not much of a nonce [RFC4949]: $ nonce (I) A random or non-repeating value that is included in data exchanged by a protocol, usually for the purpose of guaranteeing liveness and thus detecting and protecting against replay attacks. (See: fresh.) 4) s126.96.36.199.5/s188.8.131.52.6 and s5.3.6: Add a normative reference to RFC 4086 for randomness requirements. Put it in the sentence that talks about the pseudo-random number generator. It's pretty much the standard motherhood and apple pie statement when it comes to PRNGs. 5) s184.108.40.206: r/is a architectural/is an architectural 6) s220.127.116.11 and elsewhere: r/private secret/secret (secrets are private :) 7) s18.104.22.168: So this is probably nit picking, but isn't I-D.ietf-6man-udpchecksums "the" solution not "a" solution as it's about to be a PS? 8) s22.214.171.124.2/s126.96.36.199.2: Would be good to provide a pointer to the state timers so folks will know how long they need to keep the nonce. 9) s5.3.6: WRT retention, shouldn't the prior secret key be kept until after you start using the new key? App A talks about reauthenticating with the old key? 10) References: a) Normative: Pretty sure that in addition to 1321 being normative the following should also be normative: I-D.ietf-6man-udpchecksums, 2336, 2710 - Even if these are SHOULD/MAY then it's a normative reference. And, you place requirements on IGMPv2 MLD. See IESG statement on informative/normative references. Or, were you thinking the IGMPv3 implementation must support v2 Membership Report & v2 Leave Group in 3376 so you'd leave it information here? I guess same for MLDv2 saying which bits of MLDv1 must be supported?. RFC 2119 - Pretty sure this is always normative when used. b) Unused references: == Unused Reference: 'RFC0768' is defined on line 3366, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 3385, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 3418, but no explicit reference was found in the text == Unused Reference: 'RFC3053' is defined on line 3439, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 3442, but no explicit reference was found in the text == Unused Reference: 'RFC3068' is defined on line 3445, but no explicit reference was found in the text == Unused Reference: 'RFC3973' is defined on line 3452, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 3464, but no explicit reference was found in the text
(Martin Stiemerling) (was Discuss) Abstain
Comment (2014-06-23 for -17)
I am moving to Abstain, as some issues have been addressed, namely 2 and 3 (partly), but others such as 1) are not addressed and will probably not be solved by this draft. I still do not see that this protocol is safe for operations across the public Internet, as the major point 1) isn't solved. Therefore, I would appreciate very much to emphasize the point "- Limit the scope of this to wallened gardens and adding operational consinderations describing the limits of it." *************************************** The old DISCUSS as reference: I have no general objection to the AMT protocol as such, but the below DISCUSS issues. The overall description of the protocol and its framework is well done. The current AMT protocol has these DISCUSS issues that must be addressed: 1) lack of congestion control of the AMT traffic between relay and gateway -- Then tunnel multicast traffic can exceed a path's capacity. Further, such a relay will send out a number of tunnelled multicast flows to a huge number of destinations, either competing with themselves or with other flows. 2) lack of MTU handling -- There absolutely no mentioning of MTU issues in the draft. However, tunnelled packets can easily exceed the path MTU. How does AMT react to this? 3) Use of zero IPv6/UDP checksum and failure handling, if any middlebox enroute is not allowing zero UDP checksum packets to traverse. This is also a question on what happens, if the traffic is black holed for any other reasons, i.e., when no ICMP error message is returned at all. 4) Security: There is a change in the threat model, i.e., multicast requires LAN access but with AMT almost anybody can access the multicast feed. I can understand that this is not needed in certain deployments, e.g., a mobile phone network, but this is not well documented in any part of the draft. 5) NAT traversal and the IANA-assigned port. Section 188.8.131.52 assumes a simple NAPT with translation from IPv4 to IPv4. However there can be other NATs than even change the source IP address for incoming flows and potentially also the port number. Is there any specific reason to nail down the source port of the relay? The discovery mechanism could also return an arbitrary port number. 6) Section 184.108.40.206.4, start of page 58: NAT timer. The NAT timer is independent of any other time, as this really depends on the NAT on the path. 7) The current AMT specification cuts away the possibility to return ASM receiver feedback to the source. This is not documented nor described. Magnus did an excellent summary of the above points in his review: http://www.ietf.org/mail-archive/web/ietf/current/msg76475.html I can see three potential ways forward for this draft: - Address the above topics to make the draft ready for the Standards Track and thus safely deployable in the public Internet - Reclassify it as experimental and figure out all missing parts. - Limit the scope of this to wallened gardens and adding operational consinderations describing the limits of it.