IETF 102 Montreal MBONED Minutes Tues, Jul 17, 2018 1:30PM-3:30PM Notre Dame Note taker: Mike McBride Jabber Log: https://www.ietf.org/jabber/logs/mboned/2018-07-17.html Audio log: https://ietf.org/audio/ietf102/ietf102-notredame-20180717-1330.mp3 Video log: https://www.youtube.com/watch?v=-MP1YiMICBo Dale Carder, Jake Holland, Kerry Meyer, Lorenzo Minero, Lucas Pardue, Natalie Landsberg on meetecho   Chairs: Lenny & Greg mtrace draft stuck for a while with security issues at iesg. Hitoshi will discuss today. deprecate doc call for adoption ongoing. Please reply on list. Toerless to provide update today.   Draft-ietf-mboned-mtrace-v2-22 Hitoshi Asaeda Version is 24 now actually. Started iesg review on Jan. 2018 on v.22 Revised based on several previous comments then created v23 In April 2018 we addressed all comments, normative wordings, iana related things, etc Version 24 created in Jun 2018 to address Mirjas’s and Eric’s comments. Mirja approved. Eric didn’t. Next step as of this morning: Eric approved so we will submit revision. Updated the forgery of responses based upon Eric’s comments. Also filtering of clients and peers. A router providing mtrace2 functionality must support a configurable packet filtering mechanism to drop queries from clients and requests from peer router or client addresses that are unauthorized or that are beyond a specified administrative boundary. This filtering could, for example, be specified via a list of allowed/disallowed client and peer addresses or subnets for a given mtrace2 message type sent to the mtrace2 protocol port. If a query or request is received from an unauthorized address or one beyond the specified administrative boundary, the query/request must not be processed. The router may, however, perform rate limited logging of such events. This is what Eric required. Stig: does the filtering need to happen only on the mtrace client or does a router, that’s on the path to ip destination, need to do filtering? Hitoshi: The client and host can only request the query, not the request or reply. The router may send the reply or request and could be an attack. You may need to upgrade all the routers to support this mtracev2. Stig: It’s hard to enforce that all routers need to support mtrace filtering. Can’t expect that to happen. Each router along the path needs to support mtrace. But also needs router between client and those routers and wonder if they also need to support filtering. Will take to the list. Kerry: there’s standard functionality, that is supplementary to acl’s, that’s provided by vendors that provides generic packet filtering. Could be mtrace message type. Not required by mtrace implementation.   Toerless: everyone supports some number of bytes of the header.   Kerry: right, we can differentiate. A per interface required configuration on routers used for mtrace. The filtering only needs to be on routers participating in mtrace.   Stig: when you process the mtrace message you can make the decision.   Toerless: are these packet needed at the process level or hw forwarding plane?   Kerry: we want to prevent them from being punted. Don’t want to interrupt the cpu with disallowed packets like this. Need to take this further to the list.   Hitoshi: amplification attack is related to the filtering mechanism. The intent of 9.7.2 text is to prevent non router endpoints from injecting request messages. Implementations of non PIM protocols SHOULD employ some other mechanism to prevent this attack.   Stig: make sure the wg is comfortable with the new security requirements of what was agreed with Eric.   Lenny: agree that the wg needs to agree to these changes.   Mike: mvpn based bier entropy draft Presenting in mboned because it’s a multicast in the data center consideration. This document describes how BIER Entropy is to be applied to DC CLOS networks. Entropy is a technique used in BIER (and other protocols such as SR, MPLS) to support load-balancing. Isolating faults in the network with multiple parallel paths and ECMP based routing is non trivial due to lack of determinism. Traffic flowing from server to server is load balanced over all available paths using ECMP. When BIER is deployed in a multi-tenant data center network for efficient delivery of BUM, an operator may want a deterministic path. It is possible that some deployments will have more BFERs in a given sub-domain than there are bits in the bitstring. To accommodate this case, the BIER encapsulation includes both the bitstring and a ‘set identifier’ (SI). It is the bitstring and the SI together that determine the set of BFERs to which a given packet will be delivered. If one wants to get a deterministic path from the equal cost paths one can use part of the 20 bit entropy field. A 20 bit entropy label can be used by routers in different tiers to select a deterministic path independently by using different parts of the 20 bit entropy label, and form an end to end deterministic path. Greg: good that you are presenting in bier as it may belong there.   AMT Gateway integrated with VLC Natalie Landsberg Juniper remote presentation Goal: Build an amt gateway implementation for widest possible usage. Candidate platforms: Web browser implementation was initial hope, but webrtc has no multicast support. Web Assembly has no udp support. Plugin – deprecated Extension – no UDP support Progressive web app: no udp support VLC integration: Supports multicast Widely used media player Available on all platforms Other VLC benefits: Already handles most major media types Modular Runs on almost any platform Fairly easy to use Started on an VLC AMT access module that opens ports and sends correct messages and passes multicast data onto a demuxer. Credits: UTDallas, Jake Holland, Cisco – SSMAMTTools library, Concordia Challenges: Finding an appropriate path/technology Duplicating IGMP, IP protocols Understanding AMT Receiving data, but audio is garbled and no video rendering Easier Tasks: Compiling VLC Writing a module To do list: Add full igmpv2 support Resolve/verify no memory leaks Periodic query/update timers Future: VLC has a browser plugin Successfully stream full video and audio from relay at TJ Submit a patch request/feature request to VLC Impressions: AMT was moderately easy to understand/implement. Great for solving chicken/egg problem. RFC 7450 was good. VLC documentation is good. IRC chat/forums was somewhat helpful. Easy to start developing.   AMBI Asymmetric manifest based integrity - Jake Holland Akamai Meant to provide crypto integrity guarantees. Interdomain mcast has security issues. Why multicast? Same data to many clients, loss is okay, data with a deadline. Live video to a wide audience is the use case. Integrity scheme requirements: Line rate verification Asymmetric crypto Single Manifest - Cryptographic that the owner of a private key knows the data packets that were part of this data strip. Manifest tree: Knew it would have scaling problems. 40-100 hashes per packet. Not sure how big the signature needs to be with RSA. By making a tree we can have the signature at the root of the tree which provides integrity for child manifests. Still provides similar integrity guarantees.   Rolling root manifest Can either retransmit the manifest or resend the data hashes.   Example threat model Intermediate nodes can provide authentication as well with AMBI. An attacker, as a man on a side, can spoof the traffic and when a receiver joins a stream, you are attacking, you can make a congestion attack. Anchor discovery: Intermediate AMBI system gets the anchor and processes the packets and authenticate before forwarding. An s,g join is issued, as the rpf signal goes back to the ambi node and it can now do a dns lookup on the reverse source ip. Next steps: Analyze loss resiliency and determine optimal overlap/redundancy Use a merkel tree like structure to combine data and authentication in the same packet? Reopen msec? Looking for feedback Improvements to protocol Improvements to data model for anchor message Feedback on the DNS thing Issues/pull requests: https://github.com/GrumpyOldTroll/ietf-ambi   Greg: is there a gap analysis to show what ball msec may have dropped?   Jake: Tesla use case described.   Lenny: amt relay discovery is a long overdue topic. Att guys came up with draft using dns. 15 years ago someone from sprint came up with a similar way of using dns. Worth knowing how to pick a relay, the only closest to you or to the source? Worth looking at. dns can play a role.   Deprecating ASM for interdomain multicast: Toerless Draft-acg-mboned-deprecate-interdomain-asm-02   IETF 101 discussed revised new draft that came out of prior draft and deprecated ASM in the interdomain and not the intradomain on the enterprise. Key use case: SP IPTV going to homes: every home user is a separate operator, even though they only operate IGMP proxy home gateways (but not PIM routers). So operationally this is a very fair definition, and it’s a key use case where we want to get rid of ASM. Adding text to also suggest to prefer SSM intradomain when possible. Application dependencies discussed. How can we get the classification of our standards in shape. Upgrading IGMPv3/MLDv2 to full STANDARD, deprecating older versions. Fully deprecate MSDP only after enhancing 4610 so that nobody would have to rely on MSDP for intradomain anycaset RP.   Lenny: in London hands were raised in favor. No replies on list need list responses. Will retake a poll.   Mike: what does it mean in the IETF to deprecate?   Lenny: BCP to operators. Give clear direction to application providers. RFC officially states. Helps give clear direction. Can’t enforce anything as internet police.   5 people in support of this draft. 0 against.   Please send email to list to say support or not.   Toerless: evolution of igmp/mld standars status. No draft. Problem statement. IGMPv1/IGMPv2/IGMPv3,MLDv1/MLDv2 and more Trying to adopt the best protocol standard. Can’t use ipv6 which is only proposed standard.   Stig: this is a natural process of how ietf works. igmpv1 has indeed been around a long time. What happens when you come up with new versions, do you make previous versions historical? Should talk to ADs to find out. For a standard you need to get through implementation requirements etc.   Operators think they don’t need to go to igmpv3 if they don’t go to SSM. But they also get benefits of igmpv3/mldv2 such as explicit tracking. We could write this down in an informational draft in mboned.   Stig: people think igmpv3 is ssm only.   Greg: igmpv3 supports ASM. Its backward compatible. Not changing ASM in this work Should not touch full internet standard status of ASM in this work Parallel effort: draft-acg-mboned-multicast-models Just make sure that demoting ASM for interdomain is released as RFC so that it supersedes anything else we do here. Important, business critical deployments of intradomain ASM exist Toerless: RFC1112 (IPv4 ASM + IGMPv1) full standard. ASM service model. Problem: we cannot downgrade this because it does not only specify IGMpv1 but also ipv4 asm service model (joingroup/leavegroup) Possible solution: New rfc that supersedes RFC1112, keeps specifying the ASM service interface, removes IGMP. TBD: Check how easily.   Stig: when you want to make something an internet standard you look for what parts have widespread interoperability. You then take out stuff that don’t have any deployments. You may need to rev the existing documents and do an implementation report and take stuff out like we did with 4601. Jeffrey: if we move igmpv3/mldv2 to full standard, we may need to remove excluding sources. The exclude list must be empty perhaps. Stig: its up to us on what to deprecate. Mankamana: igmp snooping should be added to the list. It’s also informational. Should be standard.