IETF-69 Meeting of the MBONED Working Group The audio recording of this meeting is available at http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch8-wed-am.mp3 The meeting started with agenda bashing. Marshall Eubanks and Hiroshi Ohta briefly discussed the 4 drafts in AD evaluation : draft-ietf-mboned-addrarch-05 draft-ietf-mboned-routingarch-07 draft-ietf-mboned-ip-mcast-mib-05 draft-ietf-mboned-maccnt-req-04 The Multicast MIB, draft-ietf-mboned-ip-mcast-mib-05, will require minor up dates based on review, the two architecture drafts were discussed later in the session, and a new version of the MACCNT draft should be ready soon. Report on AMT interoperability testing Dave Thaler discussed AMT interoperability testing of draft-07. This draft has just expired and will be updated. They updated their implementation to version-07 and found some issues : The current draft provides no guidance on the minimum requirements for MAC generation, which means that a constant value of zero would be compliant. Dave recommended that HMAC-MD5-48 should become a SHOULD. The specification is contradictory as to when a discovery message should be sent, Section 5.1.3 says that this should be done when a join be received, Section 7.1 at startup and periodically thereafter, implying that timer and state are necessary. He proposes that they both be legal and that both sections mention that both are legal. John Zwiebel suggested that this should only be done when the join is received, and that state should not be kept (the Section 5.1.3 solution). He said that they had implemented this and that it had worked. There was consensus in the room to adopt John's suggestion. The third issue was relay discovery (Section 7.1) synchronization, where the proposal was to put some jitter into the relay discovery, to avoid synchronized queries. The current implementation jitters it by a random interval from 0 to 10% of the timer. There was no objection to that proposal. The fourth issue is how long the response MAC in an AMT Membership Query valid ? Section 5.1.3 and 7.3 are somewhat contradictory regarding this point. Dave pointed out that MTU issues already require that response MACs be reused, and the proposal was that triggered reports also use the same response MACs. There was no objection to that proposal. The fifth issue was the lifetime of the secret key. If the key never changes, then a host that moves to another network location could spoof stuff coming from that address. The proposal is that the secret key must be changed periodically, with some transition time where the old key is accepted. The sixth issue is that Sections 9.2.1 and 7.2.1 disagree as to the prefix list. Dave's preference is for a /16, as opposed to a /18. Marshall Eubanks suggested that IANA be polled to see their response, although obtaining an assignment will require IESG approval of the draft. Dave also described some textual updates to the draft. In response to a question from the Chairs, Dave said that he thought that the draft was ready to go to WG Last Call as soon as Draft 08 comes out. Report on Automatic Multicast Tunneling Open Source Development Sachin Karisiddappa reported on AMT implementation work at the University of Texas at Dallas. The initial code they used was the code developed by Tom Pusateri, which had no support for IGMPv3 and was based on version 03 of the draft. They ported this to Linux, added support for IGMPv3 and made it compliant with draft version 07. Only receiving multicast in the AMT site is supported, sourcing multicast is not supported. They also ported the IGMP proxy developed by Lahmadi Abdelkader of Loria, France. This is compliant with RFC4605 except there is no MLD support. The AMT Gateway and the IGMP proxy run as two different daemons, with the IGMP proxy using a TUN interface for the upstream interface, with the TUN interface being the means of communication between the IGMP proxy and the AMT gateway, with IGMP reports being sent to the gateway over the TUN. They verifies interoperability with the Cisco Relay and the Open Source Relay using the Video Lan Client (VLC) as a source and receiver. This code and documentation is available at www.cs.utdallas.edu/amt. DCOS/Linux Interoperability Testing John Zwiebel of CISCO described his interoperability testing, which was based on both Linux and the new Cisco DCOS operating system. He said that a number of interoperability issues had been discovered. Questions include - The overlapping request problem : IGMPv3 says to send out several unsolicited reports in short order, and their implementation would send back to back requests to the relay, the first for (*,G), the second for (S,G). The second NONCE is cached, but the second membership report received is for the first NONCE, so it throws away the membership report, which closes the transaction, so the second membership request is also thrown away. Dino Farinacci pointed out that this only happens for unsolicited reports, not for periodic reports. Dave Thaler asked why it was necessary to cache the NONCE. John said that it was actually necessary to cache the response MAC. Dave suggested that neither the NONCE or the response MAC should be cached. Dino agreed that this would be a good suggestion, and that this mean that the updates would not be dropped. John described issues with the combined gateway and router. The current gateway cannot separate the RPFs for the AMT interface and internal PIM interfaces, so it cannot receive from internal PIM interfaces. There was a discussion of the use of the anycast prefix address in the AMT implementation, which lead to a discussion of which addresses were needed and for what purpose. John pointed out that the Linux implementation uses the source address of _any_ interface when it encapsulates the IGMP report, apparently without causing any problems. Dino pointed out that the basic problem was that things were too confusing because there are too many addresses and headers in the packet. He pointed out that the internal IP header was not necessary and that it caused complexity because it has a checksum, TTL, possible options, etc., all of which need to be accounted for. This conversation had to stopped due to lack of time. draft-ietf-mboned-ssmping-01 Stig Venaas described the SSMPING status, which is now in version 1. The only major change was that the padding option has been removed, as this could be used for reflection attacks. Now, the client needs to pad the request to increase the size of the replies. There are a number of outstanding issues. Minor ones include : Should the server be able to detect that pings cross an admin scope boundary and, if so, how ? Should the client be able to ask for TTL and DSCP values for multicast ? In IPv6 should the client be able to query the results from Path MTU Discovery? Should the Version number in protocol messages? There are also two major issues : Should client port be standardized? For security, a fixed port on the client would be useful. The problem with this is that it makes it hard or impossible to have multiple concurrent clients on the same host. Stig would like to relax this and allow for the use of multiple ports. What group addresses to use? Currently, for SSM, there is a fixed group, which means that all clients receive all reports from every other ping. For ASM the client has to be able to select the group. It has been suggested that the server could tell the client what group to use. One way out of this is to start a ping with a handshake, sharing group addresses. For client control, the client should be able to use a group range. John Zweibel said that if he was going to use it, he would be only interested in pinging a group that he was using. Stig replied that a fixed client port could help, but that he would rather not do that, and that the client should be able to ask the server for a group range or a specific group. Dino asked if the ping could use ICMP. Stig responded that that might require the client running as root, which would be problematic. Dino replied that if a UDP socket is open for some group then it should accept an incoming ICMP packet. Bill Fenner pointed out that most modern OSs did not respond to multicast ICMP packets. Stig said that he liked the idea a unicast handshake between the client and the server to start the session. He also feels that these various issues will be much easier or will not arise in IPv6, as a fixed group-ID could be chosen. He requested advice from the WG on this. Gorry Fairhurst asked if part of the problem was that different people wanted different tools (checking multicast routing, specific groups, etc.) and so it might be necessary to have different tools for different uses. John Zweibel stated that he wanted to be able to specify the group. Stig said that this could be made dependent on the implementation or the administrator. draft-ietf-mboned-lightweight-igmpv3-mldv2-01 Hitoshi Asaeda described version -01 of the draft. The only protocol change with Version -01 charged two record types to the supported list, TO_EX() being changed to IS_EX(). The advantage to this is that the light weight version no longer needs to use any current state record, with their being no side effect. They are working to produce a host side implementation in NetBSD. He hopes that the LW-IGMPv3 implementation will be ready around the end of August, and that the MLDv2 implementation will be ready before the next IETF. He asked to be informed of any other implementation efforts. An audience member asked if he was aware of MultiMob (multicast mobility) BOF at the Chicago IETF, which maybe could use this lightweight protocol, and Hitoshi said that he was planning to attend. Dave Thaler asked if the light weight implementation could support (*,G) reports. The answer was that it could. Hitoshi then talked about Router-Side Implementation. This work is being done by Huawei, with the IGMPv3 implementation being done and the MPDv2 implementation being done soon. Hitoshi asked to know of any other implementation, and in response to a question stated that, while this code was not currently available, he expected it to be made available soon. Implementation tests are proceeding. In questions, John Zweibel expressed the opinion that he felt that this protocol still wasn't lightweight enough. draft-ietf-mboned-mcast-arpa-01 Peter Koch described how this document is supposed to set s policy for name registration in mcast.arpa once everything is migrated from mcast.net. Draft version 01 is now available, with comments received in Prague. This document is now aimed at BCP as an updatge to RFC 3171. Eligible will be 224.0.0/24 and 224.0.1/24, as a flat name space, with no sub-domains. The reverse mapping for 224/8 will only contain the PRT records for the records that appear in the 224.0.0 and 224.0.1 domains, and the rest will remain empty. The IANA considerations have been updated. IPv6 reverse mapping needs to be covered and remains an open issue, and Peter request consideration by the group of this issue. Peter described migration issues connected with going from mcast.net to mcast.arpa. Since this domain is under the control of the IAB, he will inform the IAB chair soon. Once the open issues are dealt with, he feels that version -02 will be ready for WGLC. In response to a question from the Chair, Peter stated that it should be possible to go to WGLC before the Fall Vancouver meeting. draft-ietf-mboned-multiaaa-framework-04 Hiroaki Satou described updates to the AAA Frame for Multicasting. With version 04 there were some major changes. There was a separation into a AAA enabled model (with AAA but without QOS and a fully enabled model (with AAA and QOS). The terminology has been aligned to agree with the RACS (Resource admission and control System) terminology. Hiroaki also described various minor textual changes and clarifications in the -04 draft. Hiroaki asked the group for discussion on the draft. The authors feel that this work should be pursued under MBONED, but there is a related draft is draft-maglione-ancp-mcast-00.txt, presented to the ANCP WG. The Chairs requested attention by the group to the AAA issues emerging. Individual Drafts ----------------- draft-sarikaya-mboned-mldauth-ps-00 Liu Ya described a problem statement draft for MLD user authentication. There is a widespread feeling that the lack of accounting and access control in IP multicast makes it difficult to be widely deployed. The functional requirements related to AAA for IP multicasting have been stated in draft-ietf-mboned-maccnt-req. This draft is intended to add mobility requirements to the framework described in draft-ietf-mboned-multiaaa-framework. MLD v2 does not support any user join authentication. In the draft, the Home Agent (HA) will be responsible for the authentication of the mobile station (MS). The requirements for mobility are - the authentication must support MS mobility and roaming. They suggest EAP (Extensible Authentication Protocol) as a candidate for this requirement. MSEC will probably not be acceptable for MLD authentication, and there will probably be 2 different authentication schemes running on different layers. The combination of encryption key authentication and multicast traffic authentication would be desirable and presents some issues. The author's requested that this draft be accepted as a WG draft. There was a suggestion that this work be merged with the draft-ietf-mboned-multiaaa-framework-04 draft. Architecture for "well managed" multicast Bill Atwoood described work that is ongoing in his research group. They feel that the MAC accounting and AAA framework documents need to be placed in a wide context. The AAA framework has three sets of participants - content providers (CPs), network service providers (NSPs) and end users (EUs). They believe that confining the interactions to these groups are incomplete. They feel that the sequence of events will be as follows : - the content provider gives content information to a merchant (MR) - the end users negotiate with Financial Institutions (FIs) for some sort of "electronic cash" - the EU visits the MR, say through a web browser, and purchases the product. - the MR checks with the FI to ensure payment - the EU received some sort of token from the MR - the EU presents his token to the NSP (using, they feel, IGMP or MLD extensions) - the NSP validates the token against policy - the NSP delivers the multicast to the EU The content provider is likely to be uninterested in the details, so the NSP has an opportunity to offer a new service - delivery of data on authentication, accounting of use, and dealing with the financial institution. Clearly, the IETF is not interested in standardizing the e-commerce solutions. However, they believe that the IETF should worry about solutions where the interface with the e-commerce solutions are smooth. This should be done by isolating the CI and the FI from the details of the solution, with a policy database collocated with the database services. In questions, Dave Thaler asked if they were envisioning a world where the NSP only provides multicasts to users except from CPs that it has a relationship with, as that is the only way to check against policy. Bill responded that "this is going to be a secure group, because you need the security in order to exclude the customers who aren't going to pay." Thaler asked, to rephrase his question, how does the system know that a new group is a secure group or an unsecure group. The answer was that you would join this as an unsecure group. Lenny Giuliano asked, more basically, that as we do not use unicast protocols to restrict unicast access, why should we use multicast protocols to restrict multicast access ? Bill answered that in the unicast there is a one to one relationship between the provider and the user, which does not exist in multicast. He feels that in the case of very large groups, there will be a need for the NSP to handle this. Dino Farinacci pointed out that there are existing subscription mechanisms that have that number of users, and that it may not be appropriate to do this at the network layer. He doesn't see why the model is any different from the unicast problems as Lenny suggested. End user identification issues Bill Atwood described the design of a solution to the end user identification problem using IGMP with EAP embedded inside it. Rather than having a separate authentication and authorization of users, these functions are combined. If the group doesn't need security, the standard IGMP interactions will continue to work. One means of differentiating between secured and unsecured group is through address assignments, with allocation of a secure group address range. The proposed solution has the end user requesting a group using IGMP-AC, with authentication/authorization information in the IGMP-AC packet. The access router forwards this information inside a Diameter packet to the AAA server. The result may be authorization, denial, or authorization with a request for accounting. This solution requires 3 new IGMP messages and 3 new Diameter messages. A simplified initial version of this was tested using state diagrams and SPIN and a more detailed version using IKEv2 has been validated using AVISPA. They realized as part of this that is not efficient to load up routers with policy information, so this information is pushed to the policy AAA server, and the access router just forwards any such information to the policy server. On the sender site, the problem is worse as there is no "sender join" in IP multicast. Therefore, they trigger sender authentication by starting with an initial, possibly empty, packet to the group. An exchange with the senders AAAS is used to validate the sender. The implications of doing this across multiple domains is still under investigation, but he feels that the current I-D should be broadened to include IGMP and MLD and address sender issues. John Zweibel asked if this wouldn't be simpler if this was just implemented for SSM, given that the topologies being discussed were IPTV like environments with Bill responded that he had always envisioned this as an SSM. John then asked if authentication could just be done on the source address, and Bill said that that was true as long as you could trust the source address. Dave Thaler said that this was similar to earlier meetings, such as in the November 2002 MAGMA media. If you are on a shared media, you have this idea of of freeloaders, which you can't block once one customer authenticates without using DRM, which doesn't need this. Conversely, if you are on a point to point media, you can do layer 2 authentication and regular IGMP. Bill responded that he was not familiar with this earlier work. In response to a question from the Chairs, Bill said that he would be willing to work with the previous draft's authors or create a new draft, as the group felt was necessary. draft-guo-mboned-mfec-framework-00.txt Leon described this draft about the multicast Forwarding Equivalence Class (MFEC) framework. In actual applications of multicast like IPTV the provider has bundles of multicast groups that are deployed centrally. For example, IPTV providers may want to push all programs to the last hop router by configuring an IGMP static join. Most of the multicast traffic in these cases will have the same distribution tree, but the router will have separate (S,G) and (*,G) for each S, and G in the tree. This degrades route convergence, can take up too much memory in the router, which can lead to attacks on the router. The purpose of the draft is to provide a generalized framework for merging these redundant states. This will reduce the state information and maintenance cost in the core or intermediate routers. The basic idea is that a set of data packets that use the same multicast distribution tree or sub-tree will receive the same forwarding processing - the mfec becomes the minimum unit for routing multicast. The basic framework mapping from (S/*,G) to the MFEC is done by the Ingress router, and the inverse mapping is done by the egress router. In the multicast routing or forwarding table, the MFEC replaces the (S/*,G) with (S/*,G,M). The egress router replaces a IGMP/MLD (S/*,G) report with a (S/*,G,M) join, which propagates to the source and the ingress router. he multicast data is then sent down the aggregated tree using forwarding based on (S/*,G,M). In PIM-SM (ASM) in one case the source DR is the ingress router, and unicasts a (S/*,G,M) register message to the RP. In the second case, the RP is the ingress router and it does the conversion between (S,G) and (S,M). The implementation of a prototype is underway. These same ideas can be adopted to other applications, such as multicast VPN. While some discussion on the mailing list said that static routes are out of scope for IETF work, MFEC trees are in general built dynamically. Lenny Giuliano stated that typical push models only push a few hundreds to a few thousand groups, which seems like a fairly trivial amount of state for modern routers. He also stated that the push model is used to reduce join latency, but there are existing deployments where join latency has been reduced. In general, if join latency is a problem, he feels that this problem should be addressed directly, and not indirectly through something like MFEC. The presenter asked that the WG consider adopting this draft. draft-asaeda-mboned-mtrace-v2-00 Hitoshi Asaeda described Mtrace Version 2, a traceroute for IP Multicast. This is a new version of Mtrace, integrating Bill Fenner's original Mtrace and the Mtrace6. The receiver sends a Mtrace2 query, which is forwarded towards the source, which sends a response directly back to the receiver. The IPv4 protocol uses IGMP while IPv6 uses the ICMPv6 type. Dino Farinacci asked why the protocol didn't use UDP, as then both versions could use the same protocol. Bill Fenner reminded the group that there is a huge deployed base, and that this idea would break backwards compatibility with the deployed base. Dino suggested that both v4 and v6 support UDP, with IPv4 support of IGMP be used to keep interoperability. Bill suggested that that could be done in two drafts, the current one for UDP, and a resurrection of the old Mtrace document for the other. Steve Casner agreed, saying that going forward there would have to be changes for IPv6 anyway, and that the statistics collected in the old Mtrace might no longer be appropriate, and so he supported using UDP going forward. Stig Venaas said that it would be useful to get a draft documenting the old Mtrace. Hitoshi continued, pointing out that in IPv6 there were link local addresses and global addresses, and some routers might not have global addresses. In that case, can the link-local address be filled in ? Is there some other method to uniquely identify the router using the interface ID and the An audience member requested that both IPv4 and v6 counters be extended to 64 bits from 32 bits. Open issues include whether historical protocols such as DVMRP should still be supported, what sort of support should be provided to BiDir PIM, and whether functionality should be extended with variable length packets. Multicast address assignment issues Marshall Eubanks described progress in Multicast address assignments. He and Dave Meyer ]submitted proposals to ARIN, RIPE and APNIC to instantiate the e-GLOP proposal (RFC 3138). It rapidly became apparent that getting all of the RIRs to adopt these proposals would be a multi-year effort. However, at the same time Eubanks started working with IANA in address assignments, and succeeded Dave Meyer as the IESG Expert to IANA for Multicast addressing. After a review of recent proposals there appear to be at least three basic types of address requests : Edge device developers that want one address Financial services (such as stock exchanges) IPTV He stated that he was worried about a possible "land rush" of IPTV address requests, and there could conceivably be 10,000's of such requests, each of the size of a /24 or larger. As the eGLOP space represents 1024 /24's of multicast addresses, this raises the issue of whether RFC 3138 should be updated to allow IANA to assign addresses from this space. There was a discussion about IPv4 unicast-prefix-based addressing, which draft had gone dormant for lack of interest. After discussion, there seemed to be interest in the room for this proposal, and the author (Dave Thaler) volunteered to revive it.