Minutes IETF102: mboned
minutes-102-mboned-00

Meeting Minutes MBONE Deployment (mboned) WG
Title Minutes IETF102: mboned
State Active
Other versions plain text
Last updated 2018-07-20

Meeting Minutes
minutes-102-mboned

   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.