Subject: [lisp] Virtual meeting

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Mar 2020 17:44:03 -0400

Vancouver has been cancelled.
We have several ways we can hold a virtual interim.  (The chairs have a 
webex available, and Fabio has offered one.)

I understand that folks want to present their work.
But what I am looking for if we are going to get folks together is 
actual engagement on the list.  Indication that there are things worth 
discussing.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Mar 2020 14:50:37 -0700

> But what I am looking for if we are going to get folks together is actual engagement on the list.  Indication that there are things worth discussing.

There are things worth discussing if we can discuss non-RFCbis material. There are many working group documents ready for last call but consensus wants to hold them until RFCbis documents are in RFC. Since that is taking a bit long, we are seeing delays unfortunately.

But more importantly, if people want to discuss, people should attend virtually. I will attend virtually when it is decided to have the virtual meeting.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Mar 2020 17:55:49 -0400

Many of the things that I believe folks would like to discuss are in 
charter.
Dino, I think you misunderstood my point.
I am looking to see discussion on the list to give me confidence that a 
virtual session will be useful.  I have been disappointed in the one-way 
nature of the last several working group meetings, and do not wish to 
waste a virtual meeting on such.

Sure, we are not going to be able to last-call things yet.  But we can 
get them ready for IETF LC.  (Whether we hold a WG LC or defer that 
probably depends upon whether there is dependency on the currently 
blocking comments for PS publication.)

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Mar 2020 15:02:56 -0700

> Many of the things that I believe folks would like to discuss are in charter.

I understood the point. But if people don’t get the opportunity to present, then there isn’t much to discuss. If members want to discuss anything they feel is important, they can always bring that up on the list. So there is nothing special about a virtual meeting that would warrant discussion.

But if there are presenters, then we should have a virtual meeting. 

> I am looking to see discussion on the list to give me confidence that a virtual session will be useful.  I have been 

It will be useful if there are presenters.

> disappointed in the one-way nature of the last several working group meetings, and do not wish to waste a virtual meeting on such.

It is less waste than having a physical meeting.

There was one-way nature in the last working group? Can you be more specific? I saw discussion at the mic.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Mar 2020 18:19:43 -0400

No, fundamentally, WG sessions are not supposed to be opportunities to 
present.  They are supposed to be opportunities to use higher bandwidth 
to resolve issues.  Even virtual meetings are supposed to be for that goal.

Of the several presentations at the last meeting, most had no comments, 
some had one or two comments (from me and Fabio if I recall, I ahve not 
checked the minutes), and I think one got some good discussion.

I expect you know of multiple issues.  I would not be surprised (and it 
is normal and acceptable) if you discuss those issues with your 
co-authors.  Bring some of those issues to the list.
     Side-note: I am not talking about the issues around the document 
advancement.  that is a different problem.

Yours,
Joel

---

From: "Alberto Rodriguez Natal (natal)" <[email-masked]>
Date: Mon, 16 Mar 2020 18:15:03 +0000

Joel, all,

I'm in favor of having a virtual interim meeting. One of the points that I have on my personal list of "things to discuss when we have time" is the aspect of (unsolicited) Map-Notifies on PubSub. I think it can benefit from some deeper discussion with the WG regarding, nonces, security associations, ITR-MS relationship, etc. If the WG is up to it, I can bring the topic for discussion and get some opinions on an interim.

Thanks,
Alberto

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 Mar 2020 11:20:53 -0700

I think a great topic to discuss. And an important problem to solve of course. ;-)

Dino

> On Mar 16, 2020, at 11:15 AM, Alberto Rodriguez Natal (natal) <natal=[email-masked]> wrote:
> 
> Joel, all,
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 16 Mar 2020 14:24:04 -0400

Thank you Alberto.  To see if folks want to engage on the topic, could 
you write a short email describing the question and, if you can, some of 
the things that you would like to discuss?

Folks, let's be clear.  I do expect we will have a virtual interim. 
Maybe even more than one.  I would really like to see groundwork on the 
email list so that any request by the chairs for folks to make time is 
for more than just some presentations.

Thank you,
Joel

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Mon, 16 Mar 2020 21:41:28 +0000

Another topic that I’ve been holding off on (in favor of finalizing publication of the RFC bis documents) is the federation of control planes. We’ve come across this requirement in many cross-organizational environments (the ones for which we started working on Uberlay). I’ll send a separate note (under a dedicated header) to the list so we can get warmed up ahead of the virtual interim.

In a nutshell, we have multiple providers in the Civil Aviation space who currently peer with each other in a very traditional manner (control and data plane peering). The policies enforced at these peering points are key to their business. The intent is to evolve this backbone to use LISP as the control plane and simplify the peering arrangement by focusing on enforcing the policies at the control plane level. Many benefits to pursuing this, which we can discuss as the WG gets involved.

Cheers,

-v

> On Mar 16, 2020, at 11:24 AM, Joel Halpern Direct <[email-masked]> wrote:
> 
> Thank you Alberto.  To see if folks want to engage on the topic, could you write a short email describing the question and, if you can, some of the things that you would like to discuss?
> 
> Folks, let's be clear.  I do expect we will have a virtual interim. Maybe even more than one.  I would really like to see groundwork on the email list so that any request by the chairs for folks to make time is for more than just some presentations.
> 
> Thank you,
> Joel
>

---

From: "Alberto Rodriguez Natal (natal)" <[email-masked]>
Date: Wed, 18 Mar 2020 03:56:17 +0000

Thanks Joel, I've tried to summarize my line of thought below. There may be other aspects I'm missing.

In traditional LISP, there is some shared state between a Map-Server and an ETR in order to validate Map-Notifies. First, for integrity protection Map-Notifies include some authentication data generated using a shared key between the Map-Server and the ETR. Second, to protect against replay attacks the nonce used in the Map-Register/Map-Notify exchange is incremented over time. This requires that both the Map-Server and the ETR are in synch regarding the shared key and incremental nonce.

PubSub introduces a new protocol operation where a Map-Server can send Map-Notify messages to ITRs. This departs from the traditional ETR-MS relationship stated above and introduces a few questions. How to keep a shared key at scale between ITRs and a Map-Server? The ratio of ITRs-to-MS is potentially orders of magnitude bigger than the ratio of ETRs-to-MS, are shared keys even feasible? Besides, how to handle the nonce increment when the ITR is also an ETR? Do we need to keep track of two Map-Notify nonces, one for the Map-Register exchange and another for PubSub operation?

Thanks,
Alberto

On 3/16/20, 11:24 AM, "Joel Halpern Direct" <[email-masked]> wrote:

    
    Thank you,
    Joel

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 23 Mar 2020 13:06:08 +0100

Hi all

I´d like to discuss the following topic.

We have been prototyping a LISP-based control plane for Wireguard [1] using
the Open Overlay Router implementation [2].

Wireguard is disrupting the field of VPNs by providing an easy-to-use,
high-performance and mobility-aware VPNs. Wiregard aims to replace
traditional IPsec and TLS-based VPNs, and it is open-source and available
in the Linux Kernel.

Wireguard does not have a control-plane, this means that Wireguard nodes
need to be manually configured before being able to exchange packets.
Manual configuration typically involved provisioning public keys using
out-of-band mechanisms. In this context, we have architected and prototyped
a control-plane for Wireguard using LISP, this enables automatic and secure
retrieval of public keys using LISP.

This raises -hopefully- interesting questions, how should LISP support
multiple data-planes? In this context Wireguard can be seen just as another
data-plane. Additionally, Wiregard provides a secure data-plane, can we
learn something from them?

Albert

--

[1] https://www.wireguard.com
[2] https://openoverlayrouter.org

---------- Forwarded message ---------
From: Joel M. Halpern <[email-masked]>
Date: Tue, Mar 10, 2020 at 10:44 PM
Subject: [lisp] Virtual meeting
To: [email-masked] <[email-masked]>

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 Mar 2020 14:41:57 -0700

> Wireguard does not have a control-plane, this means that Wireguard nodes need to be manually configured before being able to exchange packets. Manual configuration typically involved provisioning public keys using out-of-band mechanisms. In this context, we have architected and prototyped a control-plane for Wireguard using LISP, this enables automatic and secure retrieval of public keys using LISP.

Sounds good Albert. I have looked at Wireguard in the past and agree its great stuff.

Note the LISP-decent stuff allows the wireguard nodes to be their own mapping system. So you can continue to use and deploy Wireguard in a decentralized manner.

Also note, you can distribute public-keys using the draft-ietf-lisp-ecdsa-auth (and draft-farinacci-lisp-decent). Colin and I are working on distributing public-keys by the nodes that generate their own key-pairs without a need for a third-party trust anchor.

> This raises -hopefully- interesting questions, how should LISP support multiple data-planes? In this context Wireguard can be seen just as another data-plane. Additionally, Wiregard provides a secure data-plane, can we learn something from them? 

Use the LCAF Encap-Format Type, so an ETR, when it sends a Map-Reply (or the mapping system) to indicate which data-planes an ITR can use to encap traffic to the ETR.

Note that if Wireguard wants to rekey the data-plane keys, it can use RLOC-probing DH key exchange documented in RFC 8061.

Let me know if you need any help or clarification.

Dino

---

From: "Marc Portoles Comeras (mportole)" <[email-masked]>
Date: Tue, 24 Mar 2020 04:27:35 +0000

Albert, Dino,

Following this,
>Use the LCAF Encap-Format Type, so an ETR, when it sends a Map-Reply (or the mapping system) to indicate which data-planes an ITR can use to encap traffic to the ETR.

Have you given any thought to supporting segmentation when using wireguard encapsulation in the  dataplane? Could the Receiver field in the wireguard header be used for that and linked somehow to LISP IIDs?

Marc

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Mar 2020 07:53:03 -0700

Marc,

> On Mar 23, 2020, at 9:27 PM, Marc Portoles Comeras (mportole) <[email-masked]> wrote:
> 

Well since Wireguard can support multiple encapsulations, it could add support for LISP encapsulation fairly easy. And then they get segmentation with it and it can map its style of VPNs to draft-ietf-lisp-vpn. 

Dino

---

From: "Marc Portoles Comeras (mportole)" <[email-masked]>
Date: Tue, 24 Mar 2020 17:30:59 +0000

> Well since Wireguard can support multiple encapsulations, it could add support for LISP encapsulation fairly easy. And then they get segmentation with it and it can map its style of VPNs to draft-i…

Do you mean using lisp encapsulation as part of the encrypted payload? Or as an alternative to the wireguard header?
The wireguard whitepaper seems to establish the dataplane header very specifically, but since it seems to assume that the payload is an ip packet, a lisp packet could work there.

Thanks,
Marc

On 3/24/20, 7:53 AM, "Dino Farinacci" <[email-masked]> wrote:

Marc,

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Mar 2020 10:32:42 -0700

> Do you mean using lisp encapsulation as part of the encrypted payload? Or as an alternative to the wireguard header?

The former.

> The wireguard whitepaper seems to establish the dataplane header very specifically, but since it seems to assume that the payload is an ip packet, a lisp packet could work there.

Right.

Dino

---

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Tue, 24 Mar 2020 12:03:25 -0700

Hi Dino, Marc,

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 :)

 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.

Thanks,

Jordi

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Mar 2020 14:32:04 -0700

> 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

---

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Wed, 25 Mar 2020 17:39:40 -0700

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

    

    
    
    Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2020 13:36:12 -0700

> 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 __

There are various forms of UDP tunneling implemented in the kernel. So adding a LISP header is a minor addition. Then you got IIDs in the data-plane.

> 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 

I don’t know what you mean. If you want a newer form of VPN support, you have to change the code.

> 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).

If you bind a UDP socket, you can select the source-port. And then you use that socket to send from. So for instance:

   sock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
   iid = port = 13000
   sock.bind((“0.0.0.0", int(port)))

And when you send a packet to RLOC 1.1.1.1:

   rloc = “1.1.1.1"
   sock.sendto(packet, (rloc, 4341))

Dino

---

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Thu, 26 Mar 2020 16:25:45 -0700

Hi Dino, 

Sorry, I was thinking of using the WG code, ie. tell wireguard to use a specific UDP src port. I understand that this is straightforward  if you open the socket, but not if this socket is handled by the wireguard kernel. 

Jordi

    

    

    
    
       rloc = “1.1.1.1"
    
    Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Mar 2020 08:48:53 -0400

thinking about Alberto's request, and reading the document, I wondered 
if the security could be improved by sending the first notify back via 
the ETR, and coupling it to LISP-SEC to protect the information and 
provide needed keys for further messages?  It seems like we do need a 
way to protect the notifications, and requiring associations from every 
ITR to every MS who may provide notifications seems impossible.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 31 Mar 2020 10:33:01 -0700

> thinking about Alberto's request, and reading the document, I wondered if the security could be improved by sending the first notify back via the ETR, and coupling it to LISP-SEC to protect the information and provide needed keys for further messages? It seems like we do need a way to protect the notifications, and requiring associations from every ITR to every MS who may provide notifications seems impossible.

You can’t use LISP-SEC because the transactional nature of it starts with an ITR and a one-time-key, that is used to signed Map-Replies returning to it. 

For Map-Notify messages send from Map-Server via ETR, there would be no ITR one-time-key. And if the Map-Server used its own one-time-key, the ITR couldn’t derive it. Note with LISP-SEC the map-server one-time-key is derived from the ITR’s one-time-key in the Map-Request.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Mar 2020 15:14:13 -0400

I may have missed something, but I think that in the case of the first 
notify, it does actually start at the Itr.  Specifically, it starts with 
an ItR sending a subscribe request.  The MS responds to that with a 
notify.  What I am suggesting is that (when security is desired) the Itr 
includes the same kind of information in its subscribe that goes into 
lisp-sec.  And that the reply, instead of going directly from the MS 
back to the ITR goes through the ETR so that the rest of the lisp-sec 
procedures can be applied.

I would then use that as a bootstrap, putting necessary secrets to 
create the key information so that the MS can sign and the ITR can 
verify future notifies that go directly from the MS to the ITR.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 31 Mar 2020 16:27:18 -0700

> I may have missed something, but I think that in the case of the first notify, it does actually start at the Itr. 
>  Specifically, it starts with an ItR sending a subscribe request.  The MS responds to that with a notify.  What I am suggesting is that (when security is desired) the Itr includes the same kind of information in its subscribe that goes into lisp-sec.  And that the reply, instead of going directly from the MS back to the ITR goes through the ETR so that the rest of the lisp-sec procedures can be applied.

Yes, and in that Subscribe-Request you can include an OTK. But that one-time-key would be used more than one time. To send the Map-Notify to reply with the RLOC-set to the ITR as well as acknowledger from the Map-Server that subscription has been accepted. But then the one-time-key would have to be *stored* in the Map-Server and then used later when the RLOC-set changes to send an unsolicited Map-Notify. So the one-time-key would be “two time” and we would set a precedent to make it no longer ephemeral. In previous cases, the OTK was not stored anywhere.

> I would then use that as a bootstrap, putting necessary secrets to create the key information so that the MS can sign and the ITR can verify future notifies that go directly from the MS to the ITR.

If the working group believes that the OTK should be stored and then used again, then both the Map-Server and ITR would have to store it. In the original case, the ITR stores the OTK only until the time a Map-Reply or Map-Notify is received. But the Map-Server would have to store it indefinintely (per ITR that subscribes).

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Mar 2020 19:58:55 -0400

We could reuse the OTK directly.  My actual inclination would be for the 
MR to send back (via the ETR) some data which, when combined with the 
OTK, produced a separate key for use with the notify messages.  Clearly, 
the MR would have to store whatever security key we want it to use as 
long as the subscription persisted.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 31 Mar 2020 17:01:06 -0700

Yes, but that’s a new precedent requiring the MR to store state. We should try to make it lighter weight. And you can’t do what you want on the MR, because its the MS’s OTK as spec’ed today that is passed to the ETR.

Dino

> On Mar 31, 2020, at 4:58 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> We could reuse the OTK directly.  My actual inclination would be for the MR to send back (via the ETR) some data which, when combined with the OTK, produced a separate key for use with the notify messages.  Clearly, the MR would have to store whatever security key we want it to use as long as the subscription persisted.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Mar 2020 20:03:12 -0400

Sorry, yes, it is the MS, not the MR, who provides the information to 
construct the key, since it is the MS who is generating the notifies. 
Sorry I still cross them up.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 31 Mar 2020 17:27:12 -0700

> Sorry, yes, it is the MS, not the MR, who provides the information to construct the key, since it is the MS who is generating the notifies. Sorry I still cross them up.

Oh good. That is more clear now. So if you are saying this:

(1) Use LISP-sec as defined today.
(2) Have the MS wrap some new key material with the MS-OTK and pass it to the ETR.
(3) The ETR replies as it does today but we have new protected key material in the Map-Reply.
(4) The MS stores the new key-material.
(5) The ITR generates the new key-material because it can unwrap the MS-OTK that is derived from the ITR-OTK.
(6) Any subsequent unsolicited Map-Notify messages from the MS (for an RLOC-change) are signed with the new key-material. Which the ITR can verify since it has the new key-material from step (5).

That is a shared-key created with the pair of OTKs. I think that can work. Fabio needs to verify.

I know you didn’t say all these details but I’m progressing your point, for discussion.

Dino

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 31 Mar 2020 20:31:31 -0400

Yep, that fills in the details nicely.  I started from "we should be 
able to bootstrap the security through lisp-sec".

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 31 Mar 2020 17:38:00 -0700

Yes, you did. Great. Let’s get some opinions from the list and from the LISP-SEC experts. Fabio would have to comment on how flexible the Map-Reply Authentication Data field is to add the pubsub key-material.

Map-Request:

Map-Reply:

Dino

> On Mar 31, 2020, at 5:31 PM, Joel Halpern Direct <[email-masked]> wrote:
> 
> Yep, that fills in the details nicely.  I started from "we should be able to bootstrap the security through lisp-sec".
> 
> Yours,
> Joel
>