Meeting Recording

Meeting Chat File

Attendees & Representation. Please add your name to the attendance table below.



Daniel HaveyMicrosoft
Matteo CroceMicrosoft
VM (Vicky) BrasseurWipro
Santhosh Fernandes


LF Staff:  LJ Illuzzi


  • Holiday schedule:
    • Meetings on Dec. 8, 15
    • Dec. 22 and 29th to be canceled
    • Jan 5th: Developer and Testing Forum Prep.
  • General Topics (cover as needed)

    • Use Cases

    • Roadmap

    • Project structure

      • Governance

      • Technical Steering Committee


  • PEN request

    • Raga: Schedule call after this meeting
    • Dave: What layer of the org is the PEN assigned to?
      • L3AFD project, LF, L3AFP?
    • Louis: Just put it under LFN. Ramnifications?
    • Dave: Next PEN would probably have a sub-delegation under the original PEN
      • This is how MSFT does this so that there is a single management point.
    • Lous: Difference between L3AFd and L3AFP?
      • Dave: Github organization with different GitHub repos under it.
    • Louis: PEN that covers L3AF as a project and all current and future repos?
    • Dave: Common use of PENS is for OID and PEN is inserted into the OID with arbitrary number of layers underneath.
      • OIDs are used in x.509 certificats, etc.
    • Lous: How are we going to use the PEN for L3AF? Want a PEN that covers all of L3AF, but not all of LF or LFN,
      • Raga: As part of flow exporter we will add custom field support identified with PEN number.
    • Dave: Inventing a new slot that fields are going to go in, can it be just an array of fields of integers?
    • Raga: Will dig more and find out?
    • Dave: It matters to how we will fill out the application.
    • Raga: This is a requirement for the flow_exporter. We will not need another PEN number for L3AF.
    • Lous: Will reconsult with legal and set up call with Raga. Review by email with rest of L3AF team (if this is doable).
    • Dave: It's just a simple web form and cannot be pending
    • Dave: Do we use LF, L3AFP or L3AFd for the name?
      • Lous: Will discuss with legal.
    • Dev testing forum
      • Set date and time for MSFT presentation
  • Cross platform signing
  • Matteo: No way to do cross platform signing with eBPF programs
    • Implementation that allows loading eBPF programs to kernel that takes care of relocation
    • Created patch that does this. Creates eBPF prog and adds sig to it.
    • Dave: talked about 3 peices in kernel function marketplace
      • Orchestrator pulls stuff from marketplace
      • Can you put signed programs in the marketplace
      • We are discussing an option that allows remote distribution and is compatible with L3AF.
      • The other approach does not play well with the L3AF vision that we have discussed.
    • Vicky: Do we have representation as the L3AF at the kernel level where these decisions will be made?
      • Dave: Need Karan, Chris, ect. If we had a collective decision it would carry more weight.
        • This could be a call to create new contacts.
    • Dave: This discussion is happening on the Linux kernel list
      • MSFT would like cross-platform
      • Move to the eBPF foundation (which is cross-platform)?
    • Dave: Next BPF steering committee meeting would like L3AF to present.
      • Invited Karan.
    • Dave: BSC does not officially have an answer if the meeting is open.
      • Still have time to ask. Should be a yes answer (at least for this meeting)
    • Matteo: Proposed to BPF ML & then another solution appeared from the BPF maintainer
      • Very different solution: create an approve-list of programs that can load BPF programs
      • Only allow programs loaded from progs on this approve-list
      • Suspects this solution won't be cross-platform: verification requires Linux fs verity method
        • Also allows L3AFd to install anything it wants if L3AFd is in the allow list, Could be a security flaw
      • Matteo's approach allows individual signing and allows individual verfication, reputation, etc.
      • Raga: Where is the signature exactly? Do you still have the verification step on signed programs? Use case please.
      • Matteo: XDP. SOme BPF programs take actions on packets. These can be loaded and attached to network drivers.
        • Malicious programs can mangle pacet traffic (very dnagerous). Must make sure that program is safe.
      • Dave: Big value add: signing instead of verification step.
        • Verification step can be CPU intensive. Signature check is cheap.
        • Verification and signing together does not give this benefit. This is what the patch does.
      • Raga: Does this work for UM progs also? Yes.
      • Dave: Other approach with white list? How is this different from cap BPF?
        • Matteo: Whitelist  enforces Cap BPF.
      • Dave: L3AFd pushes out both kernel function as well as a program that can use the kernel function.
        • Matteo: Whitelist is a list programs that can be loaded
      • Matteo: Sig verification is before verification check.
      • Dave: Also reduces DOS style attacks.
        • If sig check fails then verification does not run and waste cycles.
      • Santhosh: Verifier runs only once at load time.
        • Dave: Yes, but you can spin the loader.
    • Dave: That is the intro.
      • If we can get several orgs to support this then we can approach the BSC.
    • Vicky: Once the video for the call is available we can take this to the mailing list.
    • Lous: Cancelling next weeks call on the 22nd?
    • Dave: Nope, on vacation.
    • Vicky: Probably most people have made plans so Jan 5th would be better.
    • Matteo: PR is urgent for MSFT because we want a signature system.
      • It's too dangerous to load untrusted BPF programs
    • Dave: Please post opinions on Linux Kernel mailing list sooner rather than later.
    • Dave: Include signing into the BSC meeting on Jan 12th at 1PM PST.
  • Lous: Please register for Dev and Test Forum

Action Items

  • Schdule Dev & Testing Forum L3AF session (LJ/Daniel/Poorna)
  • Schedule call with Raga to fill out the PEN application. (LJ/Raga)
  • Ask BSC if the meeting can be open to the public (Dave)
  • Vicky: Will post to mailing list so that people can discuss signing on list after watching video.

Future Agenda Items

***** Minutes from previous call *****

  • Abhi Patil: Where is the L3AF project at currently? (high level overview)
    • Orchestration across any eBPF platform in order to solve business problems
    • L3AFd which runs on any host.
    • Many eBPF programs - see wiki
    • Create marketplace/repo of eBPF programs
    • Simplify chaining of eBPF programs
    • extend eBPF programs to Kubernetes
  • Abhi P:
    • Targeting DDOS programs
    • Lead for DDOS initiative
      • Peraton Labs and Georgia tech working on their project
  • Karan: More details on the and use case yo move forward
  • General Topics (cover as needed)

    • Use Cases
    • eBPF program (soon to be open sourced)
      • export records in IBPF format
      • Enterprise number will be needed for this
      • Dave T: eBPF programs that will be put into marketplace

        • L3AF could include signed programs
        • samples
        • Include other programs that are not signed by L3AF
      • Is L3AF a framework for marketplace?
      • Vicky B: Peel off marketplace from L3AF?
        • Handled by different team that works with L3AF so it can support different project such as Polycube 
      • Dave T: Is the PEN for L3AF
      • Karan: L3AF team is contributing programs and that is what the PEN is for.
    • Jason: Agree with Dave, be careful with diluting L3AF
      • Wallmart added programs should not be natively part of L3AF itself, but rather the Wallmart contribution to L3AF
    • Dave T: Could you use a Wallmart PEN and contribute that to L3AF?
    • Karan: Once the eBPF program is OSSed then we should use the Wallmart PEN and it should be under the LF after OSSing
      • What kind of signing are we looking for?
        • Verification that the eBPF programs are compatible with the L3AF platform
          • For instance chaining.
          • Need deeper dive.
    • Dave T: Whose PEN do you use. Whoever the signer is going to be?
      • Karan: For now we don't have a clear bifurcation. It's just one L3AF.
        • We should consider how to do this.
      • Louis: IPfix program, is this a one time sign off or every time it is used?
        • Dave T: Whenever there is a change to the program it must be resigned. Not a one time thing.
        • PEN is a one time number. The signature changes with updates and revs.
      • Karan: If someone wants to use IPfix and change the PEN they can do this. Not tying anyone to the existing PEN.
      • Dave T: Then it would be a different program. Stars and other marketplace artifacet would be invalidated.
      • Christopher L: Maintainer of the code should sign the code. The org that controls the commit bit.
      • Raga P: planning to use PEN on IPfix to define custom fields. If there is no PEN then it would be an unknown field.
      • Karan: Anyone could pass a PEN into these fields and change things. If you don't change things then you get the predefined custom fields.
        • Term L3AF has been overloaded. L3AF team, platform, project, marketplace
      • Dave T: L3AF is the foundation. The more we put programs into it the more it becomes the L3A instead of L3AF.
      • Karan: If L3AF is the platform (L3AFd) how do we want to structure the remaining components?
        • Keep L3AF marketplace as a separate project? Should we drop the L3AF branding on it?
      • Vicky: Makes sense to have the marketplace be a separate thing with separate branding that is closely tied into L3AF.
        • L3AF becomes the initial consumer of this, but we plan for other consumers.
      • Louis: Consider breaking off separate projects under L3AF to ensure that the output of these is compatible with L3AF.
        • Common in OSS world for Project Tech Leads to spin off other projects in this manner.
      • Vicky: Makes a lot of sense to have things under L3AF initially. Perhaps move them later (eBPF Foundation).
      • Jason: Small set of programs provided by L3AF itself and make sure they are compatible to help get things started in the begining.
      • Vicky: This will help to get L3AF off the ground with a small set of programs that are useful and work.
      • Jason: Yeah, these could be examples and building blocks that others can use.
      • Karan: Definitely a good thing.
      • Dave T: 3 catergories of stuff: core daemon, marketplace, programs
        • Which one should be in different projects?
        • Are they all under the L3AF?
        • Where do the programs go?
        • Is the marketplace part of the L3AF repo?
        • Multiple marketplaces (Google, Apple, etc.). Is the marketplace part of the foundation?
        • Does L3AF just contain samples? Leaning towards this one?
      • Vicky: If marketplace is separate this is incredibly valuable because orgs can run their own marketplace. Should be a separate project.
      • LJ: are any programs in the marketplace paid for items?
      • DaveT: Yes, Vicky: leave door open
      • LJ: Not sure it should be OSS?
      • DaveT: Marketplace is not the programs. Paid programs can be distributed by on open source marketplace.
      • Vicky: cannot confuse monitization strategy with the licensing strategy. For pay programs should not be excluded from an OSS project. It's the licensing.
      • Brian M: This is good. Will take all these thoughts and work them into paper. Available this month(?), when we reconvene.
      • Karan: Better to leave it open so that it is an attractive proposition for folks to contribute. We need to iterate on this a little more.
      • Vicky: Brian's paper will help us to create a parallel working group to address this.
      • Jason: Start them in the base and then move when available.
    • Housekeeping: Next meeting is the 15th. Dec 22 and 29th are cancelled, reconvene on January 5th for Dev and testing forum prep