Minutes IETF102: mboned
||Minutes IETF102: mboned
IETF 102 Montreal
Tues, Jul 17, 2018
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
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
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
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
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
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
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.
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
Widely used media player
Available on all platforms
Other VLC benefits:
Already handles most major media types
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
Finding an appropriate path/technology
Duplicating IGMP, IP protocols
Receiving data, but audio is garbled and no video rendering
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
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
AMBI Asymmetric manifest based integrity - Jake Holland Akamai
Meant to provide crypto integrity guarantees. Interdomain mcast has security
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
Single Manifest - Cryptographic that the owner of a private key knows the data
packets that were part of this data strip.
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.
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.
Analyze loss resiliency and determine optimal overlap/redundancy
Use a merkel tree like structure to combine data and authentication in the same
Looking for feedback
Improvements to protocol
Improvements to data model for anchor message
Feedback on the DNS thing
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
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
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
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
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)
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.