Re: [lisp] Wireguard and LISP [Was: Virtual meeting]

Jordi Paillissé Vilanova <jordip@ac.upc.edu> Thu, 26 March 2020 00:40 UTC

Return-Path: <jordip@ac.upc.edu>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278AF3A044F for <lisp@ietfa.amsl.com>; Wed, 25 Mar 2020 17:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yMA5N3x5Fj2 for <lisp@ietfa.amsl.com>; Wed, 25 Mar 2020 17:40:02 -0700 (PDT)
Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 965283A0123 for <lisp@ietf.org>; Wed, 25 Mar 2020 17:40:01 -0700 (PDT)
Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id 02Q0drBY009738; Thu, 26 Mar 2020 01:39:53 +0100
Received: from [10.24.57.174] (unknown [128.107.241.167]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id 4E3E3362; Thu, 26 Mar 2020 01:39:47 +0100 (CET)
User-Agent: Microsoft-MacOutlook/16.35.20030802
Date: Wed, 25 Mar 2020 17:39:40 -0700
From: Jordi Paillissé Vilanova <jordip@ac.upc.edu>
To: Dino Farinacci <farinacci@gmail.com>
CC: "Marc Portoles Comeras (mportole)" <mportole@cisco.com>, "lisp@ietf.org list" <lisp@ietf.org>
Message-ID: <B5A62AB5-C734-4128-A0DD-C0E70F4407AD@ac.upc.edu>
Thread-Topic: [lisp] Wireguard and LISP [Was: Virtual meeting]
References: <95B658E8-B629-4E44-AB99-E9E406D11FF1@cisco.com> <39E32C9F-28FF-44B4-BE28-255199CEC968@gmail.com> <8A1B78BF-7677-4D8B-9D9B-0741BD037F46@cisco.com> <6E6DACF7-0FBB-48E6-B432-3413646EC3D6@gmail.com> <bcf659e8-c380-2d3c-d27b-46b41381c82c@ac.upc.edu> <F550EC7D-65BD-4DF2-B276-F44B40E89BF4@gmail.com>
In-Reply-To: <F550EC7D-65BD-4DF2-B276-F44B40E89BF4@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/NWQ5GRCOdyuRs-_0Ro29UCt7EcY>
Subject: Re: [lisp] Wireguard and LISP [Was: Virtual meeting]
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2020 00:40:04 -0000

Hi Dino,

I agree with both of your points, my concern was that the moment the data plane traffic hits user space we degrade performance. Not a problem though if we're just prototyping __

I'm trying to think of a solution that does not need to modify WG but I can't come up with any.  For example if we want to control the src UDP port that WG puts in the packets, we need a way to specify this, and I'm not aware you can do it (from userspace).

Thanks,

Jordi

On 3/24/20, 14:32, "Dino Farinacci" <farinacci@gmail.com> wrote:

    > Yes, we considered adding an IID. However, since this means changing the WG kernel code, we discarded this option in favor of a user-space solution. I agree that it would be a nice addition though :)
    
    How about use source-port in UDP header. That can be done in user space. You lose load-balancing but you caould use 10-bits for IID and 6 bits for entropy.
    
    > From an implementation perspective I don't think it's straightforward to do LISP in WG encapsulation without substantial processing overhead. Right now we're programming the WG interface, but if we want LISP in WG we probably need handling packets in user space also.
    
    Well I would think the overhead would be the same as any other encapsulation. But to compare apples with apples, you’d have to put the LISP encapsulation in the kernel as well. So back to your first point.
    
    Are there any spare bits in the WG header. Which is the default encapsulation it uses. If its IPsec, there are plenty of usable bits in the ESP/AH header. ;-)
    
    Dino